1 This is doc/gccint.info, produced by makeinfo version 4.13 from 2 /Volumes/androidtc/androidtoolchain/./src/build/../gcc/gcc-4.6/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, 2006, 2007, 2008, 2010 Free 6 Software Foundation, Inc. 7 8 Permission is granted to copy, distribute and/or modify this document 9 under the terms of the GNU Free Documentation License, Version 1.3 or 10 any later version published by the Free Software Foundation; with the 11 Invariant Sections being "Funding Free Software", the Front-Cover Texts 12 being (a) (see below), and with the Back-Cover Texts being (b) (see 13 below). A copy of the license is included in the section entitled "GNU 14 Free Documentation License". 15 16 (a) The FSF's Front-Cover Text is: 17 18 A GNU Manual 19 20 (b) The FSF's Back-Cover Text is: 21 22 You have freedom to copy and modify this GNU Manual, like GNU 23 software. Copies published by the Free Software Foundation raise 24 funds for GNU development. 25 26 INFO-DIR-SECTION Software development 27 START-INFO-DIR-ENTRY 28 * gccint: (gccint). Internals of the GNU Compiler Collection. 29 END-INFO-DIR-ENTRY 30 This file documents the internals of the GNU compilers. 31 32 Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 33 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2010 Free 34 Software Foundation, Inc. 35 36 Permission is granted to copy, distribute and/or modify this document 37 under the terms of the GNU Free Documentation License, Version 1.3 or 38 any later version published by the Free Software Foundation; with the 39 Invariant Sections being "Funding Free Software", the Front-Cover Texts 40 being (a) (see below), and with the Back-Cover Texts being (b) (see 41 below). A copy of the license is included in the section entitled "GNU 42 Free Documentation License". 43 44 (a) The FSF's Front-Cover Text is: 45 46 A GNU Manual 47 48 (b) The FSF's Back-Cover Text is: 49 50 You have freedom to copy and modify this GNU Manual, like GNU 51 software. Copies published by the Free Software Foundation raise 52 funds for GNU development. 53 54 55 56 File: gccint.info, Node: Top, Next: Contributing, Up: (DIR) 57 58 Introduction 59 ************ 60 61 This manual documents the internals of the GNU compilers, including how 62 to port them to new targets and some information about how to write 63 front ends for new languages. It corresponds to the compilers 64 (GCC) version 4.6.x-google. The use of the GNU compilers is documented 65 in a separate manual. *Note Introduction: (gcc)Top. 66 67 This manual is mainly a reference manual rather than a tutorial. It 68 discusses how to contribute to GCC (*note Contributing::), the 69 characteristics of the machines supported by GCC as hosts and targets 70 (*note Portability::), how GCC relates to the ABIs on such systems 71 (*note Interface::), and the characteristics of the languages for which 72 GCC front ends are written (*note Languages::). It then describes the 73 GCC source tree structure and build system, some of the interfaces to 74 GCC front ends, and how support for a target system is implemented in 75 GCC. 76 77 Additional tutorial information is linked to from 78 `http://gcc.gnu.org/readings.html'. 79 80 * Menu: 81 82 * Contributing:: How to contribute to testing and developing GCC. 83 * Portability:: Goals of GCC's portability features. 84 * Interface:: Function-call interface of GCC output. 85 * Libgcc:: Low-level runtime library used by GCC. 86 * Languages:: Languages for which GCC front ends are written. 87 * Source Tree:: GCC source tree structure and build system. 88 * Testsuites:: GCC testsuites. 89 * Options:: Option specification files. 90 * Passes:: Order of passes, what they do, and what each file is for. 91 * GENERIC:: Language-independent representation generated by Front Ends 92 * GIMPLE:: Tuple representation used by Tree SSA optimizers 93 * Tree SSA:: Analysis and optimization of GIMPLE 94 * RTL:: Machine-dependent low-level intermediate representation. 95 * Control Flow:: Maintaining and manipulating the control flow graph. 96 * Loop Analysis and Representation:: Analysis and representation of loops 97 * Machine Desc:: How to write machine description instruction patterns. 98 * Target Macros:: How to write the machine description C macros and functions. 99 * Host Config:: Writing the `xm-MACHINE.h' file. 100 * Fragments:: Writing the `t-TARGET' and `x-HOST' files. 101 * Collect2:: How `collect2' works; how it finds `ld'. 102 * Header Dirs:: Understanding the standard header file directories. 103 * Type Information:: GCC's memory management; generating type information. 104 * Plugins:: Extending the compiler with plugins. 105 * LTO:: Using Link-Time Optimization. 106 107 * Funding:: How to help assure funding for free software. 108 * GNU Project:: The GNU Project and GNU/Linux. 109 110 * Copying:: GNU General Public License says 111 how you can copy and share GCC. 112 * GNU Free Documentation License:: How you can copy and share this manual. 113 * Contributors:: People who have contributed to GCC. 114 115 * Option Index:: Index to command line options. 116 * Concept Index:: Index of concepts and symbol names. 117 118 119 File: gccint.info, Node: Contributing, Next: Portability, Prev: Top, Up: Top 120 121 1 Contributing to GCC Development 122 ********************************* 123 124 If you would like to help pretest GCC releases to assure they work well, 125 current development sources are available by SVN (see 126 `http://gcc.gnu.org/svn.html'). Source and binary snapshots are also 127 available for FTP; see `http://gcc.gnu.org/snapshots.html'. 128 129 If you would like to work on improvements to GCC, please read the 130 advice at these URLs: 131 132 `http://gcc.gnu.org/contribute.html' 133 `http://gcc.gnu.org/contributewhy.html' 134 135 for information on how to make useful contributions and avoid 136 duplication of effort. Suggested projects are listed at 137 `http://gcc.gnu.org/projects/'. 138 139 140 File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top 141 142 2 GCC and Portability 143 ********************* 144 145 GCC itself aims to be portable to any machine where `int' is at least a 146 32-bit type. It aims to target machines with a flat (non-segmented) 147 byte addressed data address space (the code address space can be 148 separate). Target ABIs may have 8, 16, 32 or 64-bit `int' type. `char' 149 can be wider than 8 bits. 150 151 GCC gets most of the information about the target machine from a 152 machine description which gives an algebraic formula for each of the 153 machine's instructions. This is a very clean way to describe the 154 target. But when the compiler needs information that is difficult to 155 express in this fashion, ad-hoc parameters have been defined for 156 machine descriptions. The purpose of portability is to reduce the 157 total work needed on the compiler; it was not of interest for its own 158 sake. 159 160 GCC does not contain machine dependent code, but it does contain code 161 that depends on machine parameters such as endianness (whether the most 162 significant byte has the highest or lowest address of the bytes in a 163 word) and the availability of autoincrement addressing. In the 164 RTL-generation pass, it is often necessary to have multiple strategies 165 for generating code for a particular kind of syntax tree, strategies 166 that are usable for different combinations of parameters. Often, not 167 all possible cases have been addressed, but only the common ones or 168 only the ones that have been encountered. As a result, a new target 169 may require additional strategies. You will know if this happens 170 because the compiler will call `abort'. Fortunately, the new 171 strategies can be added in a machine-independent fashion, and will 172 affect only the target machines that need them. 173 174 175 File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top 176 177 3 Interfacing to GCC Output 178 *************************** 179 180 GCC is normally configured to use the same function calling convention 181 normally in use on the target system. This is done with the 182 machine-description macros described (*note Target Macros::). 183 184 However, returning of structure and union values is done differently on 185 some target machines. As a result, functions compiled with PCC 186 returning such types cannot be called from code compiled with GCC, and 187 vice versa. This does not cause trouble often because few Unix library 188 routines return structures or unions. 189 190 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes 191 long in the same registers used for `int' or `double' return values. 192 (GCC typically allocates variables of such types in registers also.) 193 Structures and unions of other sizes are returned by storing them into 194 an address passed by the caller (usually in a register). The target 195 hook `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. 196 197 By contrast, PCC on most target machines returns structures and unions 198 of any size by copying the data into an area of static storage, and then 199 returning the address of that storage as if it were a pointer value. 200 The caller must copy the data from that memory area to the place where 201 the value is wanted. This is slower than the method used by GCC, and 202 fails to be reentrant. 203 204 On some target machines, such as RISC machines and the 80386, the 205 standard system convention is to pass to the subroutine the address of 206 where to return the value. On these machines, GCC has been configured 207 to be compatible with the standard compiler, when this method is used. 208 It may not be compatible for structures of 1, 2, 4 or 8 bytes. 209 210 GCC uses the system's standard convention for passing arguments. On 211 some machines, the first few arguments are passed in registers; in 212 others, all are passed on the stack. It would be possible to use 213 registers for argument passing on any machine, and this would probably 214 result in a significant speedup. But the result would be complete 215 incompatibility with code that follows the standard convention. So this 216 change is practical only if you are switching to GCC as the sole C 217 compiler for the system. We may implement register argument passing on 218 certain machines once we have a complete GNU system so that we can 219 compile the libraries with GCC. 220 221 On some machines (particularly the SPARC), certain types of arguments 222 are passed "by invisible reference". This means that the value is 223 stored in memory, and the address of the memory location is passed to 224 the subroutine. 225 226 If you use `longjmp', beware of automatic variables. ISO C says that 227 automatic variables that are not declared `volatile' have undefined 228 values after a `longjmp'. And this is all GCC promises to do, because 229 it is very difficult to restore register variables correctly, and one 230 of GCC's features is that it can put variables in registers without 231 your asking it to. 232 233 234 File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top 235 236 4 The GCC low-level runtime library 237 *********************************** 238 239 GCC provides a low-level runtime library, `libgcc.a' or `libgcc_s.so.1' 240 on some platforms. GCC generates calls to routines in this library 241 automatically, whenever it needs to perform some operation that is too 242 complicated to emit inline code for. 243 244 Most of the routines in `libgcc' handle arithmetic operations that the 245 target processor cannot perform directly. This includes integer 246 multiply and divide on some machines, and all floating-point and 247 fixed-point operations on other machines. `libgcc' also includes 248 routines for exception handling, and a handful of miscellaneous 249 operations. 250 251 Some of these routines can be defined in mostly machine-independent C. 252 Others must be hand-written in assembly language for each processor 253 that needs them. 254 255 GCC will also generate calls to C library routines, such as `memcpy' 256 and `memset', in some cases. The set of routines that GCC may possibly 257 use is documented in *note Other Builtins: (gcc)Other Builtins. 258 259 These routines take arguments and return values of a specific machine 260 mode, not a specific C type. *Note Machine Modes::, for an explanation 261 of this concept. For illustrative purposes, in this chapter the 262 floating point type `float' is assumed to correspond to `SFmode'; 263 `double' to `DFmode'; and `long double' to both `TFmode' and `XFmode'. 264 Similarly, the integer types `int' and `unsigned int' correspond to 265 `SImode'; `long' and `unsigned long' to `DImode'; and `long long' and 266 `unsigned long long' to `TImode'. 267 268 * Menu: 269 270 * Integer library routines:: 271 * Soft float library routines:: 272 * Decimal float library routines:: 273 * Fixed-point fractional library routines:: 274 * Exception handling routines:: 275 * Miscellaneous routines:: 276 277 278 File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc 279 280 4.1 Routines for integer arithmetic 281 =================================== 282 283 The integer arithmetic routines are used on platforms that don't provide 284 hardware support for arithmetic operations on some modes. 285 286 4.1.1 Arithmetic functions 287 -------------------------- 288 289 -- Runtime Function: int __ashlsi3 (int A, int B) 290 -- Runtime Function: long __ashldi3 (long A, int B) 291 -- Runtime Function: long long __ashlti3 (long long A, int B) 292 These functions return the result of shifting A left by B bits. 293 294 -- Runtime Function: int __ashrsi3 (int A, int B) 295 -- Runtime Function: long __ashrdi3 (long A, int B) 296 -- Runtime Function: long long __ashrti3 (long long A, int B) 297 These functions return the result of arithmetically shifting A 298 right by B bits. 299 300 -- Runtime Function: int __divsi3 (int A, int B) 301 -- Runtime Function: long __divdi3 (long A, long B) 302 -- Runtime Function: long long __divti3 (long long A, long long B) 303 These functions return the quotient of the signed division of A and 304 B. 305 306 -- Runtime Function: int __lshrsi3 (int A, int B) 307 -- Runtime Function: long __lshrdi3 (long A, int B) 308 -- Runtime Function: long long __lshrti3 (long long A, int B) 309 These functions return the result of logically shifting A right by 310 B bits. 311 312 -- Runtime Function: int __modsi3 (int A, int B) 313 -- Runtime Function: long __moddi3 (long A, long B) 314 -- Runtime Function: long long __modti3 (long long A, long long B) 315 These functions return the remainder of the signed division of A 316 and B. 317 318 -- Runtime Function: int __mulsi3 (int A, int B) 319 -- Runtime Function: long __muldi3 (long A, long B) 320 -- Runtime Function: long long __multi3 (long long A, long long B) 321 These functions return the product of A and B. 322 323 -- Runtime Function: long __negdi2 (long A) 324 -- Runtime Function: long long __negti2 (long long A) 325 These functions return the negation of A. 326 327 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned 328 int B) 329 -- Runtime Function: unsigned long __udivdi3 (unsigned long A, 330 unsigned long B) 331 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 332 A, unsigned long long B) 333 These functions return the quotient of the unsigned division of A 334 and B. 335 336 -- Runtime Function: unsigned long __udivmoddi3 (unsigned long A, 337 unsigned long B, unsigned long *C) 338 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 339 A, unsigned long long B, unsigned long long *C) 340 These functions calculate both the quotient and remainder of the 341 unsigned division of A and B. The return value is the quotient, 342 and the remainder is placed in variable pointed to by C. 343 344 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned 345 int B) 346 -- Runtime Function: unsigned long __umoddi3 (unsigned long A, 347 unsigned long B) 348 -- Runtime Function: unsigned long long __umodti3 (unsigned long long 349 A, unsigned long long B) 350 These functions return the remainder of the unsigned division of A 351 and B. 352 353 4.1.2 Comparison functions 354 -------------------------- 355 356 The following functions implement integral comparisons. These functions 357 implement a low-level compare, upon which the higher level comparison 358 operators (such as less than and greater than or equal to) can be 359 constructed. The returned values lie in the range zero to two, to allow 360 the high-level operators to be implemented by testing the returned 361 result using either signed or unsigned comparison. 362 363 -- Runtime Function: int __cmpdi2 (long A, long B) 364 -- Runtime Function: int __cmpti2 (long long A, long long B) 365 These functions perform a signed comparison of A and B. If A is 366 less than B, they return 0; if A is greater than B, they return 2; 367 and if A and B are equal they return 1. 368 369 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B) 370 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned 371 long long B) 372 These functions perform an unsigned comparison of A and B. If A 373 is less than B, they return 0; if A is greater than B, they return 374 2; and if A and B are equal they return 1. 375 376 4.1.3 Trapping arithmetic functions 377 ----------------------------------- 378 379 The following functions implement trapping arithmetic. These functions 380 call the libc function `abort' upon signed arithmetic overflow. 381 382 -- Runtime Function: int __absvsi2 (int A) 383 -- Runtime Function: long __absvdi2 (long A) 384 These functions return the absolute value of A. 385 386 -- Runtime Function: int __addvsi3 (int A, int B) 387 -- Runtime Function: long __addvdi3 (long A, long B) 388 These functions return the sum of A and B; that is `A + B'. 389 390 -- Runtime Function: int __mulvsi3 (int A, int B) 391 -- Runtime Function: long __mulvdi3 (long A, long B) 392 The functions return the product of A and B; that is `A * B'. 393 394 -- Runtime Function: int __negvsi2 (int A) 395 -- Runtime Function: long __negvdi2 (long A) 396 These functions return the negation of A; that is `-A'. 397 398 -- Runtime Function: int __subvsi3 (int A, int B) 399 -- Runtime Function: long __subvdi3 (long A, long B) 400 These functions return the difference between B and A; that is `A 401 - B'. 402 403 4.1.4 Bit operations 404 -------------------- 405 406 -- Runtime Function: int __clzsi2 (int A) 407 -- Runtime Function: int __clzdi2 (long A) 408 -- Runtime Function: int __clzti2 (long long A) 409 These functions return the number of leading 0-bits in A, starting 410 at the most significant bit position. If A is zero, the result is 411 undefined. 412 413 -- Runtime Function: int __ctzsi2 (int A) 414 -- Runtime Function: int __ctzdi2 (long A) 415 -- Runtime Function: int __ctzti2 (long long A) 416 These functions return the number of trailing 0-bits in A, starting 417 at the least significant bit position. If A is zero, the result is 418 undefined. 419 420 -- Runtime Function: int __ffsdi2 (long A) 421 -- Runtime Function: int __ffsti2 (long long A) 422 These functions return the index of the least significant 1-bit in 423 A, or the value zero if A is zero. The least significant bit is 424 index one. 425 426 -- Runtime Function: int __paritysi2 (int A) 427 -- Runtime Function: int __paritydi2 (long A) 428 -- Runtime Function: int __parityti2 (long long A) 429 These functions return the value zero if the number of bits set in 430 A is even, and the value one otherwise. 431 432 -- Runtime Function: int __popcountsi2 (int A) 433 -- Runtime Function: int __popcountdi2 (long A) 434 -- Runtime Function: int __popcountti2 (long long A) 435 These functions return the number of bits set in A. 436 437 -- Runtime Function: int32_t __bswapsi2 (int32_t A) 438 -- Runtime Function: int64_t __bswapdi2 (int64_t A) 439 These functions return the A byteswapped. 440 441 442 File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc 443 444 4.2 Routines for floating point emulation 445 ========================================= 446 447 The software floating point library is used on machines which do not 448 have hardware support for floating point. It is also used whenever 449 `-msoft-float' is used to disable generation of floating point 450 instructions. (Not all targets support this switch.) 451 452 For compatibility with other compilers, the floating point emulation 453 routines can be renamed with the `DECLARE_LIBRARY_RENAMES' macro (*note 454 Library Calls::). In this section, the default names are used. 455 456 Presently the library does not support `XFmode', which is used for 457 `long double' on some architectures. 458 459 4.2.1 Arithmetic functions 460 -------------------------- 461 462 -- Runtime Function: float __addsf3 (float A, float B) 463 -- Runtime Function: double __adddf3 (double A, double B) 464 -- Runtime Function: long double __addtf3 (long double A, long double 465 B) 466 -- Runtime Function: long double __addxf3 (long double A, long double 467 B) 468 These functions return the sum of A and B. 469 470 -- Runtime Function: float __subsf3 (float A, float B) 471 -- Runtime Function: double __subdf3 (double A, double B) 472 -- Runtime Function: long double __subtf3 (long double A, long double 473 B) 474 -- Runtime Function: long double __subxf3 (long double A, long double 475 B) 476 These functions return the difference between B and A; that is, 477 A - B. 478 479 -- Runtime Function: float __mulsf3 (float A, float B) 480 -- Runtime Function: double __muldf3 (double A, double B) 481 -- Runtime Function: long double __multf3 (long double A, long double 482 B) 483 -- Runtime Function: long double __mulxf3 (long double A, long double 484 B) 485 These functions return the product of A and B. 486 487 -- Runtime Function: float __divsf3 (float A, float B) 488 -- Runtime Function: double __divdf3 (double A, double B) 489 -- Runtime Function: long double __divtf3 (long double A, long double 490 B) 491 -- Runtime Function: long double __divxf3 (long double A, long double 492 B) 493 These functions return the quotient of A and B; that is, A / B. 494 495 -- Runtime Function: float __negsf2 (float A) 496 -- Runtime Function: double __negdf2 (double A) 497 -- Runtime Function: long double __negtf2 (long double A) 498 -- Runtime Function: long double __negxf2 (long double A) 499 These functions return the negation of A. They simply flip the 500 sign bit, so they can produce negative zero and negative NaN. 501 502 4.2.2 Conversion functions 503 -------------------------- 504 505 -- Runtime Function: double __extendsfdf2 (float A) 506 -- Runtime Function: long double __extendsftf2 (float A) 507 -- Runtime Function: long double __extendsfxf2 (float A) 508 -- Runtime Function: long double __extenddftf2 (double A) 509 -- Runtime Function: long double __extenddfxf2 (double A) 510 These functions extend A to the wider mode of their return type. 511 512 -- Runtime Function: double __truncxfdf2 (long double A) 513 -- Runtime Function: double __trunctfdf2 (long double A) 514 -- Runtime Function: float __truncxfsf2 (long double A) 515 -- Runtime Function: float __trunctfsf2 (long double A) 516 -- Runtime Function: float __truncdfsf2 (double A) 517 These functions truncate A to the narrower mode of their return 518 type, rounding toward zero. 519 520 -- Runtime Function: int __fixsfsi (float A) 521 -- Runtime Function: int __fixdfsi (double A) 522 -- Runtime Function: int __fixtfsi (long double A) 523 -- Runtime Function: int __fixxfsi (long double A) 524 These functions convert A to a signed integer, rounding toward 525 zero. 526 527 -- Runtime Function: long __fixsfdi (float A) 528 -- Runtime Function: long __fixdfdi (double A) 529 -- Runtime Function: long __fixtfdi (long double A) 530 -- Runtime Function: long __fixxfdi (long double A) 531 These functions convert A to a signed long, rounding toward zero. 532 533 -- Runtime Function: long long __fixsfti (float A) 534 -- Runtime Function: long long __fixdfti (double A) 535 -- Runtime Function: long long __fixtfti (long double A) 536 -- Runtime Function: long long __fixxfti (long double A) 537 These functions convert A to a signed long long, rounding toward 538 zero. 539 540 -- Runtime Function: unsigned int __fixunssfsi (float A) 541 -- Runtime Function: unsigned int __fixunsdfsi (double A) 542 -- Runtime Function: unsigned int __fixunstfsi (long double A) 543 -- Runtime Function: unsigned int __fixunsxfsi (long double A) 544 These functions convert A to an unsigned integer, rounding toward 545 zero. Negative values all become zero. 546 547 -- Runtime Function: unsigned long __fixunssfdi (float A) 548 -- Runtime Function: unsigned long __fixunsdfdi (double A) 549 -- Runtime Function: unsigned long __fixunstfdi (long double A) 550 -- Runtime Function: unsigned long __fixunsxfdi (long double A) 551 These functions convert A to an unsigned long, rounding toward 552 zero. Negative values all become zero. 553 554 -- Runtime Function: unsigned long long __fixunssfti (float A) 555 -- Runtime Function: unsigned long long __fixunsdfti (double A) 556 -- Runtime Function: unsigned long long __fixunstfti (long double A) 557 -- Runtime Function: unsigned long long __fixunsxfti (long double A) 558 These functions convert A to an unsigned long long, rounding 559 toward zero. Negative values all become zero. 560 561 -- Runtime Function: float __floatsisf (int I) 562 -- Runtime Function: double __floatsidf (int I) 563 -- Runtime Function: long double __floatsitf (int I) 564 -- Runtime Function: long double __floatsixf (int I) 565 These functions convert I, a signed integer, to floating point. 566 567 -- Runtime Function: float __floatdisf (long I) 568 -- Runtime Function: double __floatdidf (long I) 569 -- Runtime Function: long double __floatditf (long I) 570 -- Runtime Function: long double __floatdixf (long I) 571 These functions convert I, a signed long, to floating point. 572 573 -- Runtime Function: float __floattisf (long long I) 574 -- Runtime Function: double __floattidf (long long I) 575 -- Runtime Function: long double __floattitf (long long I) 576 -- Runtime Function: long double __floattixf (long long I) 577 These functions convert I, a signed long long, to floating point. 578 579 -- Runtime Function: float __floatunsisf (unsigned int I) 580 -- Runtime Function: double __floatunsidf (unsigned int I) 581 -- Runtime Function: long double __floatunsitf (unsigned int I) 582 -- Runtime Function: long double __floatunsixf (unsigned int I) 583 These functions convert I, an unsigned integer, to floating point. 584 585 -- Runtime Function: float __floatundisf (unsigned long I) 586 -- Runtime Function: double __floatundidf (unsigned long I) 587 -- Runtime Function: long double __floatunditf (unsigned long I) 588 -- Runtime Function: long double __floatundixf (unsigned long I) 589 These functions convert I, an unsigned long, to floating point. 590 591 -- Runtime Function: float __floatuntisf (unsigned long long I) 592 -- Runtime Function: double __floatuntidf (unsigned long long I) 593 -- Runtime Function: long double __floatuntitf (unsigned long long I) 594 -- Runtime Function: long double __floatuntixf (unsigned long long I) 595 These functions convert I, an unsigned long long, to floating 596 point. 597 598 4.2.3 Comparison functions 599 -------------------------- 600 601 There are two sets of basic comparison functions. 602 603 -- Runtime Function: int __cmpsf2 (float A, float B) 604 -- Runtime Function: int __cmpdf2 (double A, double B) 605 -- Runtime Function: int __cmptf2 (long double A, long double B) 606 These functions calculate a <=> b. That is, if A is less than B, 607 they return -1; if A is greater than B, they return 1; and if A 608 and B are equal they return 0. If either argument is NaN they 609 return 1, but you should not rely on this; if NaN is a 610 possibility, use one of the higher-level comparison functions. 611 612 -- Runtime Function: int __unordsf2 (float A, float B) 613 -- Runtime Function: int __unorddf2 (double A, double B) 614 -- Runtime Function: int __unordtf2 (long double A, long double B) 615 These functions return a nonzero value if either argument is NaN, 616 otherwise 0. 617 618 There is also a complete group of higher level functions which 619 correspond directly to comparison operators. They implement the ISO C 620 semantics for floating-point comparisons, taking NaN into account. Pay 621 careful attention to the return values defined for each set. Under the 622 hood, all of these routines are implemented as 623 624 if (__unordXf2 (a, b)) 625 return E; 626 return __cmpXf2 (a, b); 627 628 where E is a constant chosen to give the proper behavior for NaN. 629 Thus, the meaning of the return value is different for each set. Do 630 not rely on this implementation; only the semantics documented below 631 are guaranteed. 632 633 -- Runtime Function: int __eqsf2 (float A, float B) 634 -- Runtime Function: int __eqdf2 (double A, double B) 635 -- Runtime Function: int __eqtf2 (long double A, long double B) 636 These functions return zero if neither argument is NaN, and A and 637 B are equal. 638 639 -- Runtime Function: int __nesf2 (float A, float B) 640 -- Runtime Function: int __nedf2 (double A, double B) 641 -- Runtime Function: int __netf2 (long double A, long double B) 642 These functions return a nonzero value if either argument is NaN, 643 or if A and B are unequal. 644 645 -- Runtime Function: int __gesf2 (float A, float B) 646 -- Runtime Function: int __gedf2 (double A, double B) 647 -- Runtime Function: int __getf2 (long double A, long double B) 648 These functions return a value greater than or equal to zero if 649 neither argument is NaN, and A is greater than or equal to B. 650 651 -- Runtime Function: int __ltsf2 (float A, float B) 652 -- Runtime Function: int __ltdf2 (double A, double B) 653 -- Runtime Function: int __lttf2 (long double A, long double B) 654 These functions return a value less than zero if neither argument 655 is NaN, and A is strictly less than B. 656 657 -- Runtime Function: int __lesf2 (float A, float B) 658 -- Runtime Function: int __ledf2 (double A, double B) 659 -- Runtime Function: int __letf2 (long double A, long double B) 660 These functions return a value less than or equal to zero if 661 neither argument is NaN, and A is less than or equal to B. 662 663 -- Runtime Function: int __gtsf2 (float A, float B) 664 -- Runtime Function: int __gtdf2 (double A, double B) 665 -- Runtime Function: int __gttf2 (long double A, long double B) 666 These functions return a value greater than zero if neither 667 argument is NaN, and A is strictly greater than B. 668 669 4.2.4 Other floating-point functions 670 ------------------------------------ 671 672 -- Runtime Function: float __powisf2 (float A, int B) 673 -- Runtime Function: double __powidf2 (double A, int B) 674 -- Runtime Function: long double __powitf2 (long double A, int B) 675 -- Runtime Function: long double __powixf2 (long double A, int B) 676 These functions convert raise A to the power B. 677 678 -- Runtime Function: complex float __mulsc3 (float A, float B, float 679 C, float D) 680 -- Runtime Function: complex double __muldc3 (double A, double B, 681 double C, double D) 682 -- Runtime Function: complex long double __multc3 (long double A, long 683 double B, long double C, long double D) 684 -- Runtime Function: complex long double __mulxc3 (long double A, long 685 double B, long double C, long double D) 686 These functions return the product of A + iB and C + iD, following 687 the rules of C99 Annex G. 688 689 -- Runtime Function: complex float __divsc3 (float A, float B, float 690 C, float D) 691 -- Runtime Function: complex double __divdc3 (double A, double B, 692 double C, double D) 693 -- Runtime Function: complex long double __divtc3 (long double A, long 694 double B, long double C, long double D) 695 -- Runtime Function: complex long double __divxc3 (long double A, long 696 double B, long double C, long double D) 697 These functions return the quotient of A + iB and C + iD (i.e., (A 698 + iB) / (C + iD)), following the rules of C99 Annex G. 699 700 701 File: gccint.info, Node: Decimal float library routines, Next: Fixed-point fractional library routines, Prev: Soft float library routines, Up: Libgcc 702 703 4.3 Routines for decimal floating point emulation 704 ================================================= 705 706 The software decimal floating point library implements IEEE 754-2008 707 decimal floating point arithmetic and is only activated on selected 708 targets. 709 710 The software decimal floating point library supports either DPD 711 (Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as 712 selected at configure time. 713 714 4.3.1 Arithmetic functions 715 -------------------------- 716 717 -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32 718 B) 719 -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32 720 B) 721 -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64 722 B) 723 -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64 724 B) 725 -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A, 726 _Decimal128 B) 727 -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A, 728 _Decimal128 B) 729 These functions return the sum of A and B. 730 731 -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32 732 B) 733 -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32 734 B) 735 -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64 736 B) 737 -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64 738 B) 739 -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A, 740 _Decimal128 B) 741 -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A, 742 _Decimal128 B) 743 These functions return the difference between B and A; that is, 744 A - B. 745 746 -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32 747 B) 748 -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32 749 B) 750 -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64 751 B) 752 -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64 753 B) 754 -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A, 755 _Decimal128 B) 756 -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A, 757 _Decimal128 B) 758 These functions return the product of A and B. 759 760 -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32 761 B) 762 -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32 763 B) 764 -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64 765 B) 766 -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64 767 B) 768 -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A, 769 _Decimal128 B) 770 -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A, 771 _Decimal128 B) 772 These functions return the quotient of A and B; that is, A / B. 773 774 -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A) 775 -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A) 776 -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A) 777 -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A) 778 -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A) 779 -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A) 780 These functions return the negation of A. They simply flip the 781 sign bit, so they can produce negative zero and negative NaN. 782 783 4.3.2 Conversion functions 784 -------------------------- 785 786 -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A) 787 -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A) 788 -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A) 789 -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A) 790 -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A) 791 -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A) 792 -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A) 793 -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A) 794 -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A) 795 -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A) 796 -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A) 797 -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A) 798 These functions convert the value A from one decimal floating type 799 to another. 800 801 -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A) 802 -- Runtime Function: _Decimal64 __bid_extendsfdd (float A) 803 -- Runtime Function: _Decimal128 __dpd_extendsftd (float A) 804 -- Runtime Function: _Decimal128 __bid_extendsftd (float A) 805 -- Runtime Function: _Decimal128 __dpd_extenddftd (double A) 806 -- Runtime Function: _Decimal128 __bid_extenddftd (double A) 807 -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A) 808 -- Runtime Function: _Decimal128 __bid_extendxftd (long double A) 809 -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A) 810 -- Runtime Function: _Decimal32 __bid_truncdfsd (double A) 811 -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A) 812 -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A) 813 -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A) 814 -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A) 815 -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A) 816 -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A) 817 -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A) 818 -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A) 819 These functions convert the value of A from a binary floating type 820 to a decimal floating type of a different size. 821 822 -- Runtime Function: float __dpd_truncddsf (_Decimal64 A) 823 -- Runtime Function: float __bid_truncddsf (_Decimal64 A) 824 -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A) 825 -- Runtime Function: float __bid_trunctdsf (_Decimal128 A) 826 -- Runtime Function: double __dpd_extendsddf (_Decimal32 A) 827 -- Runtime Function: double __bid_extendsddf (_Decimal32 A) 828 -- Runtime Function: double __dpd_trunctddf (_Decimal128 A) 829 -- Runtime Function: double __bid_trunctddf (_Decimal128 A) 830 -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A) 831 -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A) 832 -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A) 833 -- Runtime Function: long double __bid_extendddxf (_Decimal64 A) 834 -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A) 835 -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A) 836 -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A) 837 -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A) 838 -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A) 839 -- Runtime Function: long double __bid_extendddtf (_Decimal64 A) 840 These functions convert the value of A from a decimal floating type 841 to a binary floating type of a different size. 842 843 -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A) 844 -- Runtime Function: _Decimal32 __bid_extendsfsd (float A) 845 -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A) 846 -- Runtime Function: _Decimal64 __bid_extenddfdd (double A) 847 -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A) 848 -- Runtime Function: _Decimal128 __bid_extendtftd (long double A) 849 -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A) 850 -- Runtime Function: float __bid_truncsdsf (_Decimal32 A) 851 -- Runtime Function: double __dpd_truncdddf (_Decimal64 A) 852 -- Runtime Function: double __bid_truncdddf (_Decimal64 A) 853 -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A) 854 -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A) 855 These functions convert the value of A between decimal and binary 856 floating types of the same size. 857 858 -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A) 859 -- Runtime Function: int __bid_fixsdsi (_Decimal32 A) 860 -- Runtime Function: int __dpd_fixddsi (_Decimal64 A) 861 -- Runtime Function: int __bid_fixddsi (_Decimal64 A) 862 -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A) 863 -- Runtime Function: int __bid_fixtdsi (_Decimal128 A) 864 These functions convert A to a signed integer. 865 866 -- Runtime Function: long __dpd_fixsddi (_Decimal32 A) 867 -- Runtime Function: long __bid_fixsddi (_Decimal32 A) 868 -- Runtime Function: long __dpd_fixdddi (_Decimal64 A) 869 -- Runtime Function: long __bid_fixdddi (_Decimal64 A) 870 -- Runtime Function: long __dpd_fixtddi (_Decimal128 A) 871 -- Runtime Function: long __bid_fixtddi (_Decimal128 A) 872 These functions convert A to a signed long. 873 874 -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A) 875 -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A) 876 -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A) 877 -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A) 878 -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A) 879 -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A) 880 These functions convert A to an unsigned integer. Negative values 881 all become zero. 882 883 -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A) 884 -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A) 885 -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A) 886 -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A) 887 -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A) 888 -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A) 889 These functions convert A to an unsigned long. Negative values 890 all become zero. 891 892 -- Runtime Function: _Decimal32 __dpd_floatsisd (int I) 893 -- Runtime Function: _Decimal32 __bid_floatsisd (int I) 894 -- Runtime Function: _Decimal64 __dpd_floatsidd (int I) 895 -- Runtime Function: _Decimal64 __bid_floatsidd (int I) 896 -- Runtime Function: _Decimal128 __dpd_floatsitd (int I) 897 -- Runtime Function: _Decimal128 __bid_floatsitd (int I) 898 These functions convert I, a signed integer, to decimal floating 899 point. 900 901 -- Runtime Function: _Decimal32 __dpd_floatdisd (long I) 902 -- Runtime Function: _Decimal32 __bid_floatdisd (long I) 903 -- Runtime Function: _Decimal64 __dpd_floatdidd (long I) 904 -- Runtime Function: _Decimal64 __bid_floatdidd (long I) 905 -- Runtime Function: _Decimal128 __dpd_floatditd (long I) 906 -- Runtime Function: _Decimal128 __bid_floatditd (long I) 907 These functions convert I, a signed long, to decimal floating 908 point. 909 910 -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I) 911 -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I) 912 -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I) 913 -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I) 914 -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I) 915 -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I) 916 These functions convert I, an unsigned integer, to decimal 917 floating point. 918 919 -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I) 920 -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I) 921 -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I) 922 -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I) 923 -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I) 924 -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I) 925 These functions convert I, an unsigned long, to decimal floating 926 point. 927 928 4.3.3 Comparison functions 929 -------------------------- 930 931 -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B) 932 -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B) 933 -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B) 934 -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B) 935 -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B) 936 -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B) 937 These functions return a nonzero value if either argument is NaN, 938 otherwise 0. 939 940 There is also a complete group of higher level functions which 941 correspond directly to comparison operators. They implement the ISO C 942 semantics for floating-point comparisons, taking NaN into account. Pay 943 careful attention to the return values defined for each set. Under the 944 hood, all of these routines are implemented as 945 946 if (__bid_unordXd2 (a, b)) 947 return E; 948 return __bid_cmpXd2 (a, b); 949 950 where E is a constant chosen to give the proper behavior for NaN. 951 Thus, the meaning of the return value is different for each set. Do 952 not rely on this implementation; only the semantics documented below 953 are guaranteed. 954 955 -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B) 956 -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B) 957 -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B) 958 -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B) 959 -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B) 960 -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B) 961 These functions return zero if neither argument is NaN, and A and 962 B are equal. 963 964 -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B) 965 -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B) 966 -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B) 967 -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B) 968 -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B) 969 -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B) 970 These functions return a nonzero value if either argument is NaN, 971 or if A and B are unequal. 972 973 -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B) 974 -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B) 975 -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B) 976 -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B) 977 -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B) 978 -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B) 979 These functions return a value greater than or equal to zero if 980 neither argument is NaN, and A is greater than or equal to B. 981 982 -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B) 983 -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B) 984 -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B) 985 -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B) 986 -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B) 987 -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B) 988 These functions return a value less than zero if neither argument 989 is NaN, and A is strictly less than B. 990 991 -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B) 992 -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B) 993 -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B) 994 -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B) 995 -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B) 996 -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B) 997 These functions return a value less than or equal to zero if 998 neither argument is NaN, and A is less than or equal to B. 999 1000 -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B) 1001 -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B) 1002 -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B) 1003 -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B) 1004 -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B) 1005 -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B) 1006 These functions return a value greater than zero if neither 1007 argument is NaN, and A is strictly greater than B. 1008 1009 1010 File: gccint.info, Node: Fixed-point fractional library routines, Next: Exception handling routines, Prev: Decimal float library routines, Up: Libgcc 1011 1012 4.4 Routines for fixed-point fractional emulation 1013 ================================================= 1014 1015 The software fixed-point library implements fixed-point fractional 1016 arithmetic, and is only activated on selected targets. 1017 1018 For ease of comprehension `fract' is an alias for the `_Fract' type, 1019 `accum' an alias for `_Accum', and `sat' an alias for `_Sat'. 1020 1021 For illustrative purposes, in this section the fixed-point fractional 1022 type `short fract' is assumed to correspond to machine mode `QQmode'; 1023 `unsigned short fract' to `UQQmode'; `fract' to `HQmode'; 1024 `unsigned fract' to `UHQmode'; `long fract' to `SQmode'; 1025 `unsigned long fract' to `USQmode'; `long long fract' to `DQmode'; and 1026 `unsigned long long fract' to `UDQmode'. Similarly the fixed-point 1027 accumulator type `short accum' corresponds to `HAmode'; 1028 `unsigned short accum' to `UHAmode'; `accum' to `SAmode'; 1029 `unsigned accum' to `USAmode'; `long accum' to `DAmode'; 1030 `unsigned long accum' to `UDAmode'; `long long accum' to `TAmode'; and 1031 `unsigned long long accum' to `UTAmode'. 1032 1033 4.4.1 Arithmetic functions 1034 -------------------------- 1035 1036 -- Runtime Function: short fract __addqq3 (short fract A, short fract 1037 B) 1038 -- Runtime Function: fract __addhq3 (fract A, fract B) 1039 -- Runtime Function: long fract __addsq3 (long fract A, long fract B) 1040 -- Runtime Function: long long fract __adddq3 (long long fract A, long 1041 long fract B) 1042 -- Runtime Function: unsigned short fract __adduqq3 (unsigned short 1043 fract A, unsigned short fract B) 1044 -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A, 1045 unsigned fract B) 1046 -- Runtime Function: unsigned long fract __addusq3 (unsigned long 1047 fract A, unsigned long fract B) 1048 -- Runtime Function: unsigned long long fract __addudq3 (unsigned long 1049 long fract A, unsigned long long fract B) 1050 -- Runtime Function: short accum __addha3 (short accum A, short accum 1051 B) 1052 -- Runtime Function: accum __addsa3 (accum A, accum B) 1053 -- Runtime Function: long accum __addda3 (long accum A, long accum B) 1054 -- Runtime Function: long long accum __addta3 (long long accum A, long 1055 long accum B) 1056 -- Runtime Function: unsigned short accum __adduha3 (unsigned short 1057 accum A, unsigned short accum B) 1058 -- Runtime Function: unsigned accum __addusa3 (unsigned accum A, 1059 unsigned accum B) 1060 -- Runtime Function: unsigned long accum __adduda3 (unsigned long 1061 accum A, unsigned long accum B) 1062 -- Runtime Function: unsigned long long accum __adduta3 (unsigned long 1063 long accum A, unsigned long long accum B) 1064 These functions return the sum of A and B. 1065 1066 -- Runtime Function: short fract __ssaddqq3 (short fract A, short 1067 fract B) 1068 -- Runtime Function: fract __ssaddhq3 (fract A, fract B) 1069 -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B) 1070 -- Runtime Function: long long fract __ssadddq3 (long long fract A, 1071 long long fract B) 1072 -- Runtime Function: short accum __ssaddha3 (short accum A, short 1073 accum B) 1074 -- Runtime Function: accum __ssaddsa3 (accum A, accum B) 1075 -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B) 1076 -- Runtime Function: long long accum __ssaddta3 (long long accum A, 1077 long long accum B) 1078 These functions return the sum of A and B with signed saturation. 1079 1080 -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short 1081 fract A, unsigned short fract B) 1082 -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A, 1083 unsigned fract B) 1084 -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long 1085 fract A, unsigned long fract B) 1086 -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned 1087 long long fract A, unsigned long long fract B) 1088 -- Runtime Function: unsigned short accum __usadduha3 (unsigned short 1089 accum A, unsigned short accum B) 1090 -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A, 1091 unsigned accum B) 1092 -- Runtime Function: unsigned long accum __usadduda3 (unsigned long 1093 accum A, unsigned long accum B) 1094 -- Runtime Function: unsigned long long accum __usadduta3 (unsigned 1095 long long accum A, unsigned long long accum B) 1096 These functions return the sum of A and B with unsigned saturation. 1097 1098 -- Runtime Function: short fract __subqq3 (short fract A, short fract 1099 B) 1100 -- Runtime Function: fract __subhq3 (fract A, fract B) 1101 -- Runtime Function: long fract __subsq3 (long fract A, long fract B) 1102 -- Runtime Function: long long fract __subdq3 (long long fract A, long 1103 long fract B) 1104 -- Runtime Function: unsigned short fract __subuqq3 (unsigned short 1105 fract A, unsigned short fract B) 1106 -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A, 1107 unsigned fract B) 1108 -- Runtime Function: unsigned long fract __subusq3 (unsigned long 1109 fract A, unsigned long fract B) 1110 -- Runtime Function: unsigned long long fract __subudq3 (unsigned long 1111 long fract A, unsigned long long fract B) 1112 -- Runtime Function: short accum __subha3 (short accum A, short accum 1113 B) 1114 -- Runtime Function: accum __subsa3 (accum A, accum B) 1115 -- Runtime Function: long accum __subda3 (long accum A, long accum B) 1116 -- Runtime Function: long long accum __subta3 (long long accum A, long 1117 long accum B) 1118 -- Runtime Function: unsigned short accum __subuha3 (unsigned short 1119 accum A, unsigned short accum B) 1120 -- Runtime Function: unsigned accum __subusa3 (unsigned accum A, 1121 unsigned accum B) 1122 -- Runtime Function: unsigned long accum __subuda3 (unsigned long 1123 accum A, unsigned long accum B) 1124 -- Runtime Function: unsigned long long accum __subuta3 (unsigned long 1125 long accum A, unsigned long long accum B) 1126 These functions return the difference of A and B; that is, `A - B'. 1127 1128 -- Runtime Function: short fract __sssubqq3 (short fract A, short 1129 fract B) 1130 -- Runtime Function: fract __sssubhq3 (fract A, fract B) 1131 -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B) 1132 -- Runtime Function: long long fract __sssubdq3 (long long fract A, 1133 long long fract B) 1134 -- Runtime Function: short accum __sssubha3 (short accum A, short 1135 accum B) 1136 -- Runtime Function: accum __sssubsa3 (accum A, accum B) 1137 -- Runtime Function: long accum __sssubda3 (long accum A, long accum B) 1138 -- Runtime Function: long long accum __sssubta3 (long long accum A, 1139 long long accum B) 1140 These functions return the difference of A and B with signed 1141 saturation; that is, `A - B'. 1142 1143 -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short 1144 fract A, unsigned short fract B) 1145 -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A, 1146 unsigned fract B) 1147 -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long 1148 fract A, unsigned long fract B) 1149 -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned 1150 long long fract A, unsigned long long fract B) 1151 -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short 1152 accum A, unsigned short accum B) 1153 -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A, 1154 unsigned accum B) 1155 -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long 1156 accum A, unsigned long accum B) 1157 -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned 1158 long long accum A, unsigned long long accum B) 1159 These functions return the difference of A and B with unsigned 1160 saturation; that is, `A - B'. 1161 1162 -- Runtime Function: short fract __mulqq3 (short fract A, short fract 1163 B) 1164 -- Runtime Function: fract __mulhq3 (fract A, fract B) 1165 -- Runtime Function: long fract __mulsq3 (long fract A, long fract B) 1166 -- Runtime Function: long long fract __muldq3 (long long fract A, long 1167 long fract B) 1168 -- Runtime Function: unsigned short fract __muluqq3 (unsigned short 1169 fract A, unsigned short fract B) 1170 -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A, 1171 unsigned fract B) 1172 -- Runtime Function: unsigned long fract __mulusq3 (unsigned long 1173 fract A, unsigned long fract B) 1174 -- Runtime Function: unsigned long long fract __muludq3 (unsigned long 1175 long fract A, unsigned long long fract B) 1176 -- Runtime Function: short accum __mulha3 (short accum A, short accum 1177 B) 1178 -- Runtime Function: accum __mulsa3 (accum A, accum B) 1179 -- Runtime Function: long accum __mulda3 (long accum A, long accum B) 1180 -- Runtime Function: long long accum __multa3 (long long accum A, long 1181 long accum B) 1182 -- Runtime Function: unsigned short accum __muluha3 (unsigned short 1183 accum A, unsigned short accum B) 1184 -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A, 1185 unsigned accum B) 1186 -- Runtime Function: unsigned long accum __muluda3 (unsigned long 1187 accum A, unsigned long accum B) 1188 -- Runtime Function: unsigned long long accum __muluta3 (unsigned long 1189 long accum A, unsigned long long accum B) 1190 These functions return the product of A and B. 1191 1192 -- Runtime Function: short fract __ssmulqq3 (short fract A, short 1193 fract B) 1194 -- Runtime Function: fract __ssmulhq3 (fract A, fract B) 1195 -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B) 1196 -- Runtime Function: long long fract __ssmuldq3 (long long fract A, 1197 long long fract B) 1198 -- Runtime Function: short accum __ssmulha3 (short accum A, short 1199 accum B) 1200 -- Runtime Function: accum __ssmulsa3 (accum A, accum B) 1201 -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B) 1202 -- Runtime Function: long long accum __ssmulta3 (long long accum A, 1203 long long accum B) 1204 These functions return the product of A and B with signed 1205 saturation. 1206 1207 -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short 1208 fract A, unsigned short fract B) 1209 -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A, 1210 unsigned fract B) 1211 -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long 1212 fract A, unsigned long fract B) 1213 -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned 1214 long long fract A, unsigned long long fract B) 1215 -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short 1216 accum A, unsigned short accum B) 1217 -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A, 1218 unsigned accum B) 1219 -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long 1220 accum A, unsigned long accum B) 1221 -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned 1222 long long accum A, unsigned long long accum B) 1223 These functions return the product of A and B with unsigned 1224 saturation. 1225 1226 -- Runtime Function: short fract __divqq3 (short fract A, short fract 1227 B) 1228 -- Runtime Function: fract __divhq3 (fract A, fract B) 1229 -- Runtime Function: long fract __divsq3 (long fract A, long fract B) 1230 -- Runtime Function: long long fract __divdq3 (long long fract A, long 1231 long fract B) 1232 -- Runtime Function: short accum __divha3 (short accum A, short accum 1233 B) 1234 -- Runtime Function: accum __divsa3 (accum A, accum B) 1235 -- Runtime Function: long accum __divda3 (long accum A, long accum B) 1236 -- Runtime Function: long long accum __divta3 (long long accum A, long 1237 long accum B) 1238 These functions return the quotient of the signed division of A 1239 and B. 1240 1241 -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short 1242 fract A, unsigned short fract B) 1243 -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A, 1244 unsigned fract B) 1245 -- Runtime Function: unsigned long fract __udivusq3 (unsigned long 1246 fract A, unsigned long fract B) 1247 -- Runtime Function: unsigned long long fract __udivudq3 (unsigned 1248 long long fract A, unsigned long long fract B) 1249 -- Runtime Function: unsigned short accum __udivuha3 (unsigned short 1250 accum A, unsigned short accum B) 1251 -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A, 1252 unsigned accum B) 1253 -- Runtime Function: unsigned long accum __udivuda3 (unsigned long 1254 accum A, unsigned long accum B) 1255 -- Runtime Function: unsigned long long accum __udivuta3 (unsigned 1256 long long accum A, unsigned long long accum B) 1257 These functions return the quotient of the unsigned division of A 1258 and B. 1259 1260 -- Runtime Function: short fract __ssdivqq3 (short fract A, short 1261 fract B) 1262 -- Runtime Function: fract __ssdivhq3 (fract A, fract B) 1263 -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B) 1264 -- Runtime Function: long long fract __ssdivdq3 (long long fract A, 1265 long long fract B) 1266 -- Runtime Function: short accum __ssdivha3 (short accum A, short 1267 accum B) 1268 -- Runtime Function: accum __ssdivsa3 (accum A, accum B) 1269 -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B) 1270 -- Runtime Function: long long accum __ssdivta3 (long long accum A, 1271 long long accum B) 1272 These functions return the quotient of the signed division of A 1273 and B with signed saturation. 1274 1275 -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short 1276 fract A, unsigned short fract B) 1277 -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A, 1278 unsigned fract B) 1279 -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long 1280 fract A, unsigned long fract B) 1281 -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned 1282 long long fract A, unsigned long long fract B) 1283 -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short 1284 accum A, unsigned short accum B) 1285 -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A, 1286 unsigned accum B) 1287 -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long 1288 accum A, unsigned long accum B) 1289 -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned 1290 long long accum A, unsigned long long accum B) 1291 These functions return the quotient of the unsigned division of A 1292 and B with unsigned saturation. 1293 1294 -- Runtime Function: short fract __negqq2 (short fract A) 1295 -- Runtime Function: fract __neghq2 (fract A) 1296 -- Runtime Function: long fract __negsq2 (long fract A) 1297 -- Runtime Function: long long fract __negdq2 (long long fract A) 1298 -- Runtime Function: unsigned short fract __neguqq2 (unsigned short 1299 fract A) 1300 -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A) 1301 -- Runtime Function: unsigned long fract __negusq2 (unsigned long 1302 fract A) 1303 -- Runtime Function: unsigned long long fract __negudq2 (unsigned long 1304 long fract A) 1305 -- Runtime Function: short accum __negha2 (short accum A) 1306 -- Runtime Function: accum __negsa2 (accum A) 1307 -- Runtime Function: long accum __negda2 (long accum A) 1308 -- Runtime Function: long long accum __negta2 (long long accum A) 1309 -- Runtime Function: unsigned short accum __neguha2 (unsigned short 1310 accum A) 1311 -- Runtime Function: unsigned accum __negusa2 (unsigned accum A) 1312 -- Runtime Function: unsigned long accum __neguda2 (unsigned long 1313 accum A) 1314 -- Runtime Function: unsigned long long accum __neguta2 (unsigned long 1315 long accum A) 1316 These functions return the negation of A. 1317 1318 -- Runtime Function: short fract __ssnegqq2 (short fract A) 1319 -- Runtime Function: fract __ssneghq2 (fract A) 1320 -- Runtime Function: long fract __ssnegsq2 (long fract A) 1321 -- Runtime Function: long long fract __ssnegdq2 (long long fract A) 1322 -- Runtime Function: short accum __ssnegha2 (short accum A) 1323 -- Runtime Function: accum __ssnegsa2 (accum A) 1324 -- Runtime Function: long accum __ssnegda2 (long accum A) 1325 -- Runtime Function: long long accum __ssnegta2 (long long accum A) 1326 These functions return the negation of A with signed saturation. 1327 1328 -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short 1329 fract A) 1330 -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A) 1331 -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long 1332 fract A) 1333 -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned 1334 long long fract A) 1335 -- Runtime Function: unsigned short accum __usneguha2 (unsigned short 1336 accum A) 1337 -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A) 1338 -- Runtime Function: unsigned long accum __usneguda2 (unsigned long 1339 accum A) 1340 -- Runtime Function: unsigned long long accum __usneguta2 (unsigned 1341 long long accum A) 1342 These functions return the negation of A with unsigned saturation. 1343 1344 -- Runtime Function: short fract __ashlqq3 (short fract A, int B) 1345 -- Runtime Function: fract __ashlhq3 (fract A, int B) 1346 -- Runtime Function: long fract __ashlsq3 (long fract A, int B) 1347 -- Runtime Function: long long fract __ashldq3 (long long fract A, int 1348 B) 1349 -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short 1350 fract A, int B) 1351 -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int 1352 B) 1353 -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long 1354 fract A, int B) 1355 -- Runtime Function: unsigned long long fract __ashludq3 (unsigned 1356 long long fract A, int B) 1357 -- Runtime Function: short accum __ashlha3 (short accum A, int B) 1358 -- Runtime Function: accum __ashlsa3 (accum A, int B) 1359 -- Runtime Function: long accum __ashlda3 (long accum A, int B) 1360 -- Runtime Function: long long accum __ashlta3 (long long accum A, int 1361 B) 1362 -- Runtime Function: unsigned short accum __ashluha3 (unsigned short 1363 accum A, int B) 1364 -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int 1365 B) 1366 -- Runtime Function: unsigned long accum __ashluda3 (unsigned long 1367 accum A, int B) 1368 -- Runtime Function: unsigned long long accum __ashluta3 (unsigned 1369 long long accum A, int B) 1370 These functions return the result of shifting A left by B bits. 1371 1372 -- Runtime Function: short fract __ashrqq3 (short fract A, int B) 1373 -- Runtime Function: fract __ashrhq3 (fract A, int B) 1374 -- Runtime Function: long fract __ashrsq3 (long fract A, int B) 1375 -- Runtime Function: long long fract __ashrdq3 (long long fract A, int 1376 B) 1377 -- Runtime Function: short accum __ashrha3 (short accum A, int B) 1378 -- Runtime Function: accum __ashrsa3 (accum A, int B) 1379 -- Runtime Function: long accum __ashrda3 (long accum A, int B) 1380 -- Runtime Function: long long accum __ashrta3 (long long accum A, int 1381 B) 1382 These functions return the result of arithmetically shifting A 1383 right by B bits. 1384 1385 -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short 1386 fract A, int B) 1387 -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int 1388 B) 1389 -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long 1390 fract A, int B) 1391 -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned 1392 long long fract A, int B) 1393 -- Runtime Function: unsigned short accum __lshruha3 (unsigned short 1394 accum A, int B) 1395 -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int 1396 B) 1397 -- Runtime Function: unsigned long accum __lshruda3 (unsigned long 1398 accum A, int B) 1399 -- Runtime Function: unsigned long long accum __lshruta3 (unsigned 1400 long long accum A, int B) 1401 These functions return the result of logically shifting A right by 1402 B bits. 1403 1404 -- Runtime Function: fract __ssashlhq3 (fract A, int B) 1405 -- Runtime Function: long fract __ssashlsq3 (long fract A, int B) 1406 -- Runtime Function: long long fract __ssashldq3 (long long fract A, 1407 int B) 1408 -- Runtime Function: short accum __ssashlha3 (short accum A, int B) 1409 -- Runtime Function: accum __ssashlsa3 (accum A, int B) 1410 -- Runtime Function: long accum __ssashlda3 (long accum A, int B) 1411 -- Runtime Function: long long accum __ssashlta3 (long long accum A, 1412 int B) 1413 These functions return the result of shifting A left by B bits 1414 with signed saturation. 1415 1416 -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short 1417 fract A, int B) 1418 -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A, 1419 int B) 1420 -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long 1421 fract A, int B) 1422 -- Runtime Function: unsigned long long fract __usashludq3 (unsigned 1423 long long fract A, int B) 1424 -- Runtime Function: unsigned short accum __usashluha3 (unsigned short 1425 accum A, int B) 1426 -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A, 1427 int B) 1428 -- Runtime Function: unsigned long accum __usashluda3 (unsigned long 1429 accum A, int B) 1430 -- Runtime Function: unsigned long long accum __usashluta3 (unsigned 1431 long long accum A, int B) 1432 These functions return the result of shifting A left by B bits 1433 with unsigned saturation. 1434 1435 4.4.2 Comparison functions 1436 -------------------------- 1437 1438 The following functions implement fixed-point comparisons. These 1439 functions implement a low-level compare, upon which the higher level 1440 comparison operators (such as less than and greater than or equal to) 1441 can be constructed. The returned values lie in the range zero to two, 1442 to allow the high-level operators to be implemented by testing the 1443 returned result using either signed or unsigned comparison. 1444 1445 -- Runtime Function: int __cmpqq2 (short fract A, short fract B) 1446 -- Runtime Function: int __cmphq2 (fract A, fract B) 1447 -- Runtime Function: int __cmpsq2 (long fract A, long fract B) 1448 -- Runtime Function: int __cmpdq2 (long long fract A, long long fract 1449 B) 1450 -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned 1451 short fract B) 1452 -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B) 1453 -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned 1454 long fract B) 1455 -- Runtime Function: int __cmpudq2 (unsigned long long fract A, 1456 unsigned long long fract B) 1457 -- Runtime Function: int __cmpha2 (short accum A, short accum B) 1458 -- Runtime Function: int __cmpsa2 (accum A, accum B) 1459 -- Runtime Function: int __cmpda2 (long accum A, long accum B) 1460 -- Runtime Function: int __cmpta2 (long long accum A, long long accum 1461 B) 1462 -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned 1463 short accum B) 1464 -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B) 1465 -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned 1466 long accum B) 1467 -- Runtime Function: int __cmputa2 (unsigned long long accum A, 1468 unsigned long long accum B) 1469 These functions perform a signed or unsigned comparison of A and B 1470 (depending on the selected machine mode). If A is less than B, 1471 they return 0; if A is greater than B, they return 2; and if A and 1472 B are equal they return 1. 1473 1474 4.4.3 Conversion functions 1475 -------------------------- 1476 1477 -- Runtime Function: fract __fractqqhq2 (short fract A) 1478 -- Runtime Function: long fract __fractqqsq2 (short fract A) 1479 -- Runtime Function: long long fract __fractqqdq2 (short fract A) 1480 -- Runtime Function: short accum __fractqqha (short fract A) 1481 -- Runtime Function: accum __fractqqsa (short fract A) 1482 -- Runtime Function: long accum __fractqqda (short fract A) 1483 -- Runtime Function: long long accum __fractqqta (short fract A) 1484 -- Runtime Function: unsigned short fract __fractqquqq (short fract A) 1485 -- Runtime Function: unsigned fract __fractqquhq (short fract A) 1486 -- Runtime Function: unsigned long fract __fractqqusq (short fract A) 1487 -- Runtime Function: unsigned long long fract __fractqqudq (short 1488 fract A) 1489 -- Runtime Function: unsigned short accum __fractqquha (short fract A) 1490 -- Runtime Function: unsigned accum __fractqqusa (short fract A) 1491 -- Runtime Function: unsigned long accum __fractqquda (short fract A) 1492 -- Runtime Function: unsigned long long accum __fractqquta (short 1493 fract A) 1494 -- Runtime Function: signed char __fractqqqi (short fract A) 1495 -- Runtime Function: short __fractqqhi (short fract A) 1496 -- Runtime Function: int __fractqqsi (short fract A) 1497 -- Runtime Function: long __fractqqdi (short fract A) 1498 -- Runtime Function: long long __fractqqti (short fract A) 1499 -- Runtime Function: float __fractqqsf (short fract A) 1500 -- Runtime Function: double __fractqqdf (short fract A) 1501 -- Runtime Function: short fract __fracthqqq2 (fract A) 1502 -- Runtime Function: long fract __fracthqsq2 (fract A) 1503 -- Runtime Function: long long fract __fracthqdq2 (fract A) 1504 -- Runtime Function: short accum __fracthqha (fract A) 1505 -- Runtime Function: accum __fracthqsa (fract A) 1506 -- Runtime Function: long accum __fracthqda (fract A) 1507 -- Runtime Function: long long accum __fracthqta (fract A) 1508 -- Runtime Function: unsigned short fract __fracthquqq (fract A) 1509 -- Runtime Function: unsigned fract __fracthquhq (fract A) 1510 -- Runtime Function: unsigned long fract __fracthqusq (fract A) 1511 -- Runtime Function: unsigned long long fract __fracthqudq (fract A) 1512 -- Runtime Function: unsigned short accum __fracthquha (fract A) 1513 -- Runtime Function: unsigned accum __fracthqusa (fract A) 1514 -- Runtime Function: unsigned long accum __fracthquda (fract A) 1515 -- Runtime Function: unsigned long long accum __fracthquta (fract A) 1516 -- Runtime Function: signed char __fracthqqi (fract A) 1517 -- Runtime Function: short __fracthqhi (fract A) 1518 -- Runtime Function: int __fracthqsi (fract A) 1519 -- Runtime Function: long __fracthqdi (fract A) 1520 -- Runtime Function: long long __fracthqti (fract A) 1521 -- Runtime Function: float __fracthqsf (fract A) 1522 -- Runtime Function: double __fracthqdf (fract A) 1523 -- Runtime Function: short fract __fractsqqq2 (long fract A) 1524 -- Runtime Function: fract __fractsqhq2 (long fract A) 1525 -- Runtime Function: long long fract __fractsqdq2 (long fract A) 1526 -- Runtime Function: short accum __fractsqha (long fract A) 1527 -- Runtime Function: accum __fractsqsa (long fract A) 1528 -- Runtime Function: long accum __fractsqda (long fract A) 1529 -- Runtime Function: long long accum __fractsqta (long fract A) 1530 -- Runtime Function: unsigned short fract __fractsquqq (long fract A) 1531 -- Runtime Function: unsigned fract __fractsquhq (long fract A) 1532 -- Runtime Function: unsigned long fract __fractsqusq (long fract A) 1533 -- Runtime Function: unsigned long long fract __fractsqudq (long fract 1534 A) 1535 -- Runtime Function: unsigned short accum __fractsquha (long fract A) 1536 -- Runtime Function: unsigned accum __fractsqusa (long fract A) 1537 -- Runtime Function: unsigned long accum __fractsquda (long fract A) 1538 -- Runtime Function: unsigned long long accum __fractsquta (long fract 1539 A) 1540 -- Runtime Function: signed char __fractsqqi (long fract A) 1541 -- Runtime Function: short __fractsqhi (long fract A) 1542 -- Runtime Function: int __fractsqsi (long fract A) 1543 -- Runtime Function: long __fractsqdi (long fract A) 1544 -- Runtime Function: long long __fractsqti (long fract A) 1545 -- Runtime Function: float __fractsqsf (long fract A) 1546 -- Runtime Function: double __fractsqdf (long fract A) 1547 -- Runtime Function: short fract __fractdqqq2 (long long fract A) 1548 -- Runtime Function: fract __fractdqhq2 (long long fract A) 1549 -- Runtime Function: long fract __fractdqsq2 (long long fract A) 1550 -- Runtime Function: short accum __fractdqha (long long fract A) 1551 -- Runtime Function: accum __fractdqsa (long long fract A) 1552 -- Runtime Function: long accum __fractdqda (long long fract A) 1553 -- Runtime Function: long long accum __fractdqta (long long fract A) 1554 -- Runtime Function: unsigned short fract __fractdquqq (long long 1555 fract A) 1556 -- Runtime Function: unsigned fract __fractdquhq (long long fract A) 1557 -- Runtime Function: unsigned long fract __fractdqusq (long long fract 1558 A) 1559 -- Runtime Function: unsigned long long fract __fractdqudq (long long 1560 fract A) 1561 -- Runtime Function: unsigned short accum __fractdquha (long long 1562 fract A) 1563 -- Runtime Function: unsigned accum __fractdqusa (long long fract A) 1564 -- Runtime Function: unsigned long accum __fractdquda (long long fract 1565 A) 1566 -- Runtime Function: unsigned long long accum __fractdquta (long long 1567 fract A) 1568 -- Runtime Function: signed char __fractdqqi (long long fract A) 1569 -- Runtime Function: short __fractdqhi (long long fract A) 1570 -- Runtime Function: int __fractdqsi (long long fract A) 1571 -- Runtime Function: long __fractdqdi (long long fract A) 1572 -- Runtime Function: long long __fractdqti (long long fract A) 1573 -- Runtime Function: float __fractdqsf (long long fract A) 1574 -- Runtime Function: double __fractdqdf (long long fract A) 1575 -- Runtime Function: short fract __fracthaqq (short accum A) 1576 -- Runtime Function: fract __fracthahq (short accum A) 1577 -- Runtime Function: long fract __fracthasq (short accum A) 1578 -- Runtime Function: long long fract __fracthadq (short accum A) 1579 -- Runtime Function: accum __fracthasa2 (short accum A) 1580 -- Runtime Function: long accum __fracthada2 (short accum A) 1581 -- Runtime Function: long long accum __fracthata2 (short accum A) 1582 -- Runtime Function: unsigned short fract __fracthauqq (short accum A) 1583 -- Runtime Function: unsigned fract __fracthauhq (short accum A) 1584 -- Runtime Function: unsigned long fract __fracthausq (short accum A) 1585 -- Runtime Function: unsigned long long fract __fracthaudq (short 1586 accum A) 1587 -- Runtime Function: unsigned short accum __fracthauha (short accum A) 1588 -- Runtime Function: unsigned accum __fracthausa (short accum A) 1589 -- Runtime Function: unsigned long accum __fracthauda (short accum A) 1590 -- Runtime Function: unsigned long long accum __fracthauta (short 1591 accum A) 1592 -- Runtime Function: signed char __fracthaqi (short accum A) 1593 -- Runtime Function: short __fracthahi (short accum A) 1594 -- Runtime Function: int __fracthasi (short accum A) 1595 -- Runtime Function: long __fracthadi (short accum A) 1596 -- Runtime Function: long long __fracthati (short accum A) 1597 -- Runtime Function: float __fracthasf (short accum A) 1598 -- Runtime Function: double __fracthadf (short accum A) 1599 -- Runtime Function: short fract __fractsaqq (accum A) 1600 -- Runtime Function: fract __fractsahq (accum A) 1601 -- Runtime Function: long fract __fractsasq (accum A) 1602 -- Runtime Function: long long fract __fractsadq (accum A) 1603 -- Runtime Function: short accum __fractsaha2 (accum A) 1604 -- Runtime Function: long accum __fractsada2 (accum A) 1605 -- Runtime Function: long long accum __fractsata2 (accum A) 1606 -- Runtime Function: unsigned short fract __fractsauqq (accum A) 1607 -- Runtime Function: unsigned fract __fractsauhq (accum A) 1608 -- Runtime Function: unsigned long fract __fractsausq (accum A) 1609 -- Runtime Function: unsigned long long fract __fractsaudq (accum A) 1610 -- Runtime Function: unsigned short accum __fractsauha (accum A) 1611 -- Runtime Function: unsigned accum __fractsausa (accum A) 1612 -- Runtime Function: unsigned long accum __fractsauda (accum A) 1613 -- Runtime Function: unsigned long long accum __fractsauta (accum A) 1614 -- Runtime Function: signed char __fractsaqi (accum A) 1615 -- Runtime Function: short __fractsahi (accum A) 1616 -- Runtime Function: int __fractsasi (accum A) 1617 -- Runtime Function: long __fractsadi (accum A) 1618 -- Runtime Function: long long __fractsati (accum A) 1619 -- Runtime Function: float __fractsasf (accum A) 1620 -- Runtime Function: double __fractsadf (accum A) 1621 -- Runtime Function: short fract __fractdaqq (long accum A) 1622 -- Runtime Function: fract __fractdahq (long accum A) 1623 -- Runtime Function: long fract __fractdasq (long accum A) 1624 -- Runtime Function: long long fract __fractdadq (long accum A) 1625 -- Runtime Function: short accum __fractdaha2 (long accum A) 1626 -- Runtime Function: accum __fractdasa2 (long accum A) 1627 -- Runtime Function: long long accum __fractdata2 (long accum A) 1628 -- Runtime Function: unsigned short fract __fractdauqq (long accum A) 1629 -- Runtime Function: unsigned fract __fractdauhq (long accum A) 1630 -- Runtime Function: unsigned long fract __fractdausq (long accum A) 1631 -- Runtime Function: unsigned long long fract __fractdaudq (long accum 1632 A) 1633 -- Runtime Function: unsigned short accum __fractdauha (long accum A) 1634 -- Runtime Function: unsigned accum __fractdausa (long accum A) 1635 -- Runtime Function: unsigned long accum __fractdauda (long accum A) 1636 -- Runtime Function: unsigned long long accum __fractdauta (long accum 1637 A) 1638 -- Runtime Function: signed char __fractdaqi (long accum A) 1639 -- Runtime Function: short __fractdahi (long accum A) 1640 -- Runtime Function: int __fractdasi (long accum A) 1641 -- Runtime Function: long __fractdadi (long accum A) 1642 -- Runtime Function: long long __fractdati (long accum A) 1643 -- Runtime Function: float __fractdasf (long accum A) 1644 -- Runtime Function: double __fractdadf (long accum A) 1645 -- Runtime Function: short fract __fracttaqq (long long accum A) 1646 -- Runtime Function: fract __fracttahq (long long accum A) 1647 -- Runtime Function: long fract __fracttasq (long long accum A) 1648 -- Runtime Function: long long fract __fracttadq (long long accum A) 1649 -- Runtime Function: short accum __fracttaha2 (long long accum A) 1650 -- Runtime Function: accum __fracttasa2 (long long accum A) 1651 -- Runtime Function: long accum __fracttada2 (long long accum A) 1652 -- Runtime Function: unsigned short fract __fracttauqq (long long 1653 accum A) 1654 -- Runtime Function: unsigned fract __fracttauhq (long long accum A) 1655 -- Runtime Function: unsigned long fract __fracttausq (long long accum 1656 A) 1657 -- Runtime Function: unsigned long long fract __fracttaudq (long long 1658 accum A) 1659 -- Runtime Function: unsigned short accum __fracttauha (long long 1660 accum A) 1661 -- Runtime Function: unsigned accum __fracttausa (long long accum A) 1662 -- Runtime Function: unsigned long accum __fracttauda (long long accum 1663 A) 1664 -- Runtime Function: unsigned long long accum __fracttauta (long long 1665 accum A) 1666 -- Runtime Function: signed char __fracttaqi (long long accum A) 1667 -- Runtime Function: short __fracttahi (long long accum A) 1668 -- Runtime Function: int __fracttasi (long long accum A) 1669 -- Runtime Function: long __fracttadi (long long accum A) 1670 -- Runtime Function: long long __fracttati (long long accum A) 1671 -- Runtime Function: float __fracttasf (long long accum A) 1672 -- Runtime Function: double __fracttadf (long long accum A) 1673 -- Runtime Function: short fract __fractuqqqq (unsigned short fract A) 1674 -- Runtime Function: fract __fractuqqhq (unsigned short fract A) 1675 -- Runtime Function: long fract __fractuqqsq (unsigned short fract A) 1676 -- Runtime Function: long long fract __fractuqqdq (unsigned short 1677 fract A) 1678 -- Runtime Function: short accum __fractuqqha (unsigned short fract A) 1679 -- Runtime Function: accum __fractuqqsa (unsigned short fract A) 1680 -- Runtime Function: long accum __fractuqqda (unsigned short fract A) 1681 -- Runtime Function: long long accum __fractuqqta (unsigned short 1682 fract A) 1683 -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short 1684 fract A) 1685 -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned 1686 short fract A) 1687 -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned 1688 short fract A) 1689 -- Runtime Function: unsigned short accum __fractuqquha (unsigned 1690 short fract A) 1691 -- Runtime Function: unsigned accum __fractuqqusa (unsigned short 1692 fract A) 1693 -- Runtime Function: unsigned long accum __fractuqquda (unsigned short 1694 fract A) 1695 -- Runtime Function: unsigned long long accum __fractuqquta (unsigned 1696 short fract A) 1697 -- Runtime Function: signed char __fractuqqqi (unsigned short fract A) 1698 -- Runtime Function: short __fractuqqhi (unsigned short fract A) 1699 -- Runtime Function: int __fractuqqsi (unsigned short fract A) 1700 -- Runtime Function: long __fractuqqdi (unsigned short fract A) 1701 -- Runtime Function: long long __fractuqqti (unsigned short fract A) 1702 -- Runtime Function: float __fractuqqsf (unsigned short fract A) 1703 -- Runtime Function: double __fractuqqdf (unsigned short fract A) 1704 -- Runtime Function: short fract __fractuhqqq (unsigned fract A) 1705 -- Runtime Function: fract __fractuhqhq (unsigned fract A) 1706 -- Runtime Function: long fract __fractuhqsq (unsigned fract A) 1707 -- Runtime Function: long long fract __fractuhqdq (unsigned fract A) 1708 -- Runtime Function: short accum __fractuhqha (unsigned fract A) 1709 -- Runtime Function: accum __fractuhqsa (unsigned fract A) 1710 -- Runtime Function: long accum __fractuhqda (unsigned fract A) 1711 -- Runtime Function: long long accum __fractuhqta (unsigned fract A) 1712 -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned 1713 fract A) 1714 -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned 1715 fract A) 1716 -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned 1717 fract A) 1718 -- Runtime Function: unsigned short accum __fractuhquha (unsigned 1719 fract A) 1720 -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A) 1721 -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract 1722 A) 1723 -- Runtime Function: unsigned long long accum __fractuhquta (unsigned 1724 fract A) 1725 -- Runtime Function: signed char __fractuhqqi (unsigned fract A) 1726 -- Runtime Function: short __fractuhqhi (unsigned fract A) 1727 -- Runtime Function: int __fractuhqsi (unsigned fract A) 1728 -- Runtime Function: long __fractuhqdi (unsigned fract A) 1729 -- Runtime Function: long long __fractuhqti (unsigned fract A) 1730 -- Runtime Function: float __fractuhqsf (unsigned fract A) 1731 -- Runtime Function: double __fractuhqdf (unsigned fract A) 1732 -- Runtime Function: short fract __fractusqqq (unsigned long fract A) 1733 -- Runtime Function: fract __fractusqhq (unsigned long fract A) 1734 -- Runtime Function: long fract __fractusqsq (unsigned long fract A) 1735 -- Runtime Function: long long fract __fractusqdq (unsigned long fract 1736 A) 1737 -- Runtime Function: short accum __fractusqha (unsigned long fract A) 1738 -- Runtime Function: accum __fractusqsa (unsigned long fract A) 1739 -- Runtime Function: long accum __fractusqda (unsigned long fract A) 1740 -- Runtime Function: long long accum __fractusqta (unsigned long fract 1741 A) 1742 -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned 1743 long fract A) 1744 -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long 1745 fract A) 1746 -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned 1747 long fract A) 1748 -- Runtime Function: unsigned short accum __fractusquha (unsigned long 1749 fract A) 1750 -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract 1751 A) 1752 -- Runtime Function: unsigned long accum __fractusquda (unsigned long 1753 fract A) 1754 -- Runtime Function: unsigned long long accum __fractusquta (unsigned 1755 long fract A) 1756 -- Runtime Function: signed char __fractusqqi (unsigned long fract A) 1757 -- Runtime Function: short __fractusqhi (unsigned long fract A) 1758 -- Runtime Function: int __fractusqsi (unsigned long fract A) 1759 -- Runtime Function: long __fractusqdi (unsigned long fract A) 1760 -- Runtime Function: long long __fractusqti (unsigned long fract A) 1761 -- Runtime Function: float __fractusqsf (unsigned long fract A) 1762 -- Runtime Function: double __fractusqdf (unsigned long fract A) 1763 -- Runtime Function: short fract __fractudqqq (unsigned long long 1764 fract A) 1765 -- Runtime Function: fract __fractudqhq (unsigned long long fract A) 1766 -- Runtime Function: long fract __fractudqsq (unsigned long long fract 1767 A) 1768 -- Runtime Function: long long fract __fractudqdq (unsigned long long 1769 fract A) 1770 -- Runtime Function: short accum __fractudqha (unsigned long long 1771 fract A) 1772 -- Runtime Function: accum __fractudqsa (unsigned long long fract A) 1773 -- Runtime Function: long accum __fractudqda (unsigned long long fract 1774 A) 1775 -- Runtime Function: long long accum __fractudqta (unsigned long long 1776 fract A) 1777 -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned 1778 long long fract A) 1779 -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long 1780 fract A) 1781 -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long 1782 long fract A) 1783 -- Runtime Function: unsigned short accum __fractudquha (unsigned long 1784 long fract A) 1785 -- Runtime Function: unsigned accum __fractudqusa (unsigned long long 1786 fract A) 1787 -- Runtime Function: unsigned long accum __fractudquda (unsigned long 1788 long fract A) 1789 -- Runtime Function: unsigned long long accum __fractudquta (unsigned 1790 long long fract A) 1791 -- Runtime Function: signed char __fractudqqi (unsigned long long 1792 fract A) 1793 -- Runtime Function: short __fractudqhi (unsigned long long fract A) 1794 -- Runtime Function: int __fractudqsi (unsigned long long fract A) 1795 -- Runtime Function: long __fractudqdi (unsigned long long fract A) 1796 -- Runtime Function: long long __fractudqti (unsigned long long fract 1797 A) 1798 -- Runtime Function: float __fractudqsf (unsigned long long fract A) 1799 -- Runtime Function: double __fractudqdf (unsigned long long fract A) 1800 -- Runtime Function: short fract __fractuhaqq (unsigned short accum A) 1801 -- Runtime Function: fract __fractuhahq (unsigned short accum A) 1802 -- Runtime Function: long fract __fractuhasq (unsigned short accum A) 1803 -- Runtime Function: long long fract __fractuhadq (unsigned short 1804 accum A) 1805 -- Runtime Function: short accum __fractuhaha (unsigned short accum A) 1806 -- Runtime Function: accum __fractuhasa (unsigned short accum A) 1807 -- Runtime Function: long accum __fractuhada (unsigned short accum A) 1808 -- Runtime Function: long long accum __fractuhata (unsigned short 1809 accum A) 1810 -- Runtime Function: unsigned short fract __fractuhauqq (unsigned 1811 short accum A) 1812 -- Runtime Function: unsigned fract __fractuhauhq (unsigned short 1813 accum A) 1814 -- Runtime Function: unsigned long fract __fractuhausq (unsigned short 1815 accum A) 1816 -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned 1817 short accum A) 1818 -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short 1819 accum A) 1820 -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned 1821 short accum A) 1822 -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned 1823 short accum A) 1824 -- Runtime Function: signed char __fractuhaqi (unsigned short accum A) 1825 -- Runtime Function: short __fractuhahi (unsigned short accum A) 1826 -- Runtime Function: int __fractuhasi (unsigned short accum A) 1827 -- Runtime Function: long __fractuhadi (unsigned short accum A) 1828 -- Runtime Function: long long __fractuhati (unsigned short accum A) 1829 -- Runtime Function: float __fractuhasf (unsigned short accum A) 1830 -- Runtime Function: double __fractuhadf (unsigned short accum A) 1831 -- Runtime Function: short fract __fractusaqq (unsigned accum A) 1832 -- Runtime Function: fract __fractusahq (unsigned accum A) 1833 -- Runtime Function: long fract __fractusasq (unsigned accum A) 1834 -- Runtime Function: long long fract __fractusadq (unsigned accum A) 1835 -- Runtime Function: short accum __fractusaha (unsigned accum A) 1836 -- Runtime Function: accum __fractusasa (unsigned accum A) 1837 -- Runtime Function: long accum __fractusada (unsigned accum A) 1838 -- Runtime Function: long long accum __fractusata (unsigned accum A) 1839 -- Runtime Function: unsigned short fract __fractusauqq (unsigned 1840 accum A) 1841 -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A) 1842 -- Runtime Function: unsigned long fract __fractusausq (unsigned accum 1843 A) 1844 -- Runtime Function: unsigned long long fract __fractusaudq (unsigned 1845 accum A) 1846 -- Runtime Function: unsigned short accum __fractusauha2 (unsigned 1847 accum A) 1848 -- Runtime Function: unsigned long accum __fractusauda2 (unsigned 1849 accum A) 1850 -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned 1851 accum A) 1852 -- Runtime Function: signed char __fractusaqi (unsigned accum A) 1853 -- Runtime Function: short __fractusahi (unsigned accum A) 1854 -- Runtime Function: int __fractusasi (unsigned accum A) 1855 -- Runtime Function: long __fractusadi (unsigned accum A) 1856 -- Runtime Function: long long __fractusati (unsigned accum A) 1857 -- Runtime Function: float __fractusasf (unsigned accum A) 1858 -- Runtime Function: double __fractusadf (unsigned accum A) 1859 -- Runtime Function: short fract __fractudaqq (unsigned long accum A) 1860 -- Runtime Function: fract __fractudahq (unsigned long accum A) 1861 -- Runtime Function: long fract __fractudasq (unsigned long accum A) 1862 -- Runtime Function: long long fract __fractudadq (unsigned long accum 1863 A) 1864 -- Runtime Function: short accum __fractudaha (unsigned long accum A) 1865 -- Runtime Function: accum __fractudasa (unsigned long accum A) 1866 -- Runtime Function: long accum __fractudada (unsigned long accum A) 1867 -- Runtime Function: long long accum __fractudata (unsigned long accum 1868 A) 1869 -- Runtime Function: unsigned short fract __fractudauqq (unsigned long 1870 accum A) 1871 -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum 1872 A) 1873 -- Runtime Function: unsigned long fract __fractudausq (unsigned long 1874 accum A) 1875 -- Runtime Function: unsigned long long fract __fractudaudq (unsigned 1876 long accum A) 1877 -- Runtime Function: unsigned short accum __fractudauha2 (unsigned 1878 long accum A) 1879 -- Runtime Function: unsigned accum __fractudausa2 (unsigned long 1880 accum A) 1881 -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned 1882 long accum A) 1883 -- Runtime Function: signed char __fractudaqi (unsigned long accum A) 1884 -- Runtime Function: short __fractudahi (unsigned long accum A) 1885 -- Runtime Function: int __fractudasi (unsigned long accum A) 1886 -- Runtime Function: long __fractudadi (unsigned long accum A) 1887 -- Runtime Function: long long __fractudati (unsigned long accum A) 1888 -- Runtime Function: float __fractudasf (unsigned long accum A) 1889 -- Runtime Function: double __fractudadf (unsigned long accum A) 1890 -- Runtime Function: short fract __fractutaqq (unsigned long long 1891 accum A) 1892 -- Runtime Function: fract __fractutahq (unsigned long long accum A) 1893 -- Runtime Function: long fract __fractutasq (unsigned long long accum 1894 A) 1895 -- Runtime Function: long long fract __fractutadq (unsigned long long 1896 accum A) 1897 -- Runtime Function: short accum __fractutaha (unsigned long long 1898 accum A) 1899 -- Runtime Function: accum __fractutasa (unsigned long long accum A) 1900 -- Runtime Function: long accum __fractutada (unsigned long long accum 1901 A) 1902 -- Runtime Function: long long accum __fractutata (unsigned long long 1903 accum A) 1904 -- Runtime Function: unsigned short fract __fractutauqq (unsigned long 1905 long accum A) 1906 -- Runtime Function: unsigned fract __fractutauhq (unsigned long long 1907 accum A) 1908 -- Runtime Function: unsigned long fract __fractutausq (unsigned long 1909 long accum A) 1910 -- Runtime Function: unsigned long long fract __fractutaudq (unsigned 1911 long long accum A) 1912 -- Runtime Function: unsigned short accum __fractutauha2 (unsigned 1913 long long accum A) 1914 -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long 1915 accum A) 1916 -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long 1917 long accum A) 1918 -- Runtime Function: signed char __fractutaqi (unsigned long long 1919 accum A) 1920 -- Runtime Function: short __fractutahi (unsigned long long accum A) 1921 -- Runtime Function: int __fractutasi (unsigned long long accum A) 1922 -- Runtime Function: long __fractutadi (unsigned long long accum A) 1923 -- Runtime Function: long long __fractutati (unsigned long long accum 1924 A) 1925 -- Runtime Function: float __fractutasf (unsigned long long accum A) 1926 -- Runtime Function: double __fractutadf (unsigned long long accum A) 1927 -- Runtime Function: short fract __fractqiqq (signed char A) 1928 -- Runtime Function: fract __fractqihq (signed char A) 1929 -- Runtime Function: long fract __fractqisq (signed char A) 1930 -- Runtime Function: long long fract __fractqidq (signed char A) 1931 -- Runtime Function: short accum __fractqiha (signed char A) 1932 -- Runtime Function: accum __fractqisa (signed char A) 1933 -- Runtime Function: long accum __fractqida (signed char A) 1934 -- Runtime Function: long long accum __fractqita (signed char A) 1935 -- Runtime Function: unsigned short fract __fractqiuqq (signed char A) 1936 -- Runtime Function: unsigned fract __fractqiuhq (signed char A) 1937 -- Runtime Function: unsigned long fract __fractqiusq (signed char A) 1938 -- Runtime Function: unsigned long long fract __fractqiudq (signed 1939 char A) 1940 -- Runtime Function: unsigned short accum __fractqiuha (signed char A) 1941 -- Runtime Function: unsigned accum __fractqiusa (signed char A) 1942 -- Runtime Function: unsigned long accum __fractqiuda (signed char A) 1943 -- Runtime Function: unsigned long long accum __fractqiuta (signed 1944 char A) 1945 -- Runtime Function: short fract __fracthiqq (short A) 1946 -- Runtime Function: fract __fracthihq (short A) 1947 -- Runtime Function: long fract __fracthisq (short A) 1948 -- Runtime Function: long long fract __fracthidq (short A) 1949 -- Runtime Function: short accum __fracthiha (short A) 1950 -- Runtime Function: accum __fracthisa (short A) 1951 -- Runtime Function: long accum __fracthida (short A) 1952 -- Runtime Function: long long accum __fracthita (short A) 1953 -- Runtime Function: unsigned short fract __fracthiuqq (short A) 1954 -- Runtime Function: unsigned fract __fracthiuhq (short A) 1955 -- Runtime Function: unsigned long fract __fracthiusq (short A) 1956 -- Runtime Function: unsigned long long fract __fracthiudq (short A) 1957 -- Runtime Function: unsigned short accum __fracthiuha (short A) 1958 -- Runtime Function: unsigned accum __fracthiusa (short A) 1959 -- Runtime Function: unsigned long accum __fracthiuda (short A) 1960 -- Runtime Function: unsigned long long accum __fracthiuta (short A) 1961 -- Runtime Function: short fract __fractsiqq (int A) 1962 -- Runtime Function: fract __fractsihq (int A) 1963 -- Runtime Function: long fract __fractsisq (int A) 1964 -- Runtime Function: long long fract __fractsidq (int A) 1965 -- Runtime Function: short accum __fractsiha (int A) 1966 -- Runtime Function: accum __fractsisa (int A) 1967 -- Runtime Function: long accum __fractsida (int A) 1968 -- Runtime Function: long long accum __fractsita (int A) 1969 -- Runtime Function: unsigned short fract __fractsiuqq (int A) 1970 -- Runtime Function: unsigned fract __fractsiuhq (int A) 1971 -- Runtime Function: unsigned long fract __fractsiusq (int A) 1972 -- Runtime Function: unsigned long long fract __fractsiudq (int A) 1973 -- Runtime Function: unsigned short accum __fractsiuha (int A) 1974 -- Runtime Function: unsigned accum __fractsiusa (int A) 1975 -- Runtime Function: unsigned long accum __fractsiuda (int A) 1976 -- Runtime Function: unsigned long long accum __fractsiuta (int A) 1977 -- Runtime Function: short fract __fractdiqq (long A) 1978 -- Runtime Function: fract __fractdihq (long A) 1979 -- Runtime Function: long fract __fractdisq (long A) 1980 -- Runtime Function: long long fract __fractdidq (long A) 1981 -- Runtime Function: short accum __fractdiha (long A) 1982 -- Runtime Function: accum __fractdisa (long A) 1983 -- Runtime Function: long accum __fractdida (long A) 1984 -- Runtime Function: long long accum __fractdita (long A) 1985 -- Runtime Function: unsigned short fract __fractdiuqq (long A) 1986 -- Runtime Function: unsigned fract __fractdiuhq (long A) 1987 -- Runtime Function: unsigned long fract __fractdiusq (long A) 1988 -- Runtime Function: unsigned long long fract __fractdiudq (long A) 1989 -- Runtime Function: unsigned short accum __fractdiuha (long A) 1990 -- Runtime Function: unsigned accum __fractdiusa (long A) 1991 -- Runtime Function: unsigned long accum __fractdiuda (long A) 1992 -- Runtime Function: unsigned long long accum __fractdiuta (long A) 1993 -- Runtime Function: short fract __fracttiqq (long long A) 1994 -- Runtime Function: fract __fracttihq (long long A) 1995 -- Runtime Function: long fract __fracttisq (long long A) 1996 -- Runtime Function: long long fract __fracttidq (long long A) 1997 -- Runtime Function: short accum __fracttiha (long long A) 1998 -- Runtime Function: accum __fracttisa (long long A) 1999 -- Runtime Function: long accum __fracttida (long long A) 2000 -- Runtime Function: long long accum __fracttita (long long A) 2001 -- Runtime Function: unsigned short fract __fracttiuqq (long long A) 2002 -- Runtime Function: unsigned fract __fracttiuhq (long long A) 2003 -- Runtime Function: unsigned long fract __fracttiusq (long long A) 2004 -- Runtime Function: unsigned long long fract __fracttiudq (long long 2005 A) 2006 -- Runtime Function: unsigned short accum __fracttiuha (long long A) 2007 -- Runtime Function: unsigned accum __fracttiusa (long long A) 2008 -- Runtime Function: unsigned long accum __fracttiuda (long long A) 2009 -- Runtime Function: unsigned long long accum __fracttiuta (long long 2010 A) 2011 -- Runtime Function: short fract __fractsfqq (float A) 2012 -- Runtime Function: fract __fractsfhq (float A) 2013 -- Runtime Function: long fract __fractsfsq (float A) 2014 -- Runtime Function: long long fract __fractsfdq (float A) 2015 -- Runtime Function: short accum __fractsfha (float A) 2016 -- Runtime Function: accum __fractsfsa (float A) 2017 -- Runtime Function: long accum __fractsfda (float A) 2018 -- Runtime Function: long long accum __fractsfta (float A) 2019 -- Runtime Function: unsigned short fract __fractsfuqq (float A) 2020 -- Runtime Function: unsigned fract __fractsfuhq (float A) 2021 -- Runtime Function: unsigned long fract __fractsfusq (float A) 2022 -- Runtime Function: unsigned long long fract __fractsfudq (float A) 2023 -- Runtime Function: unsigned short accum __fractsfuha (float A) 2024 -- Runtime Function: unsigned accum __fractsfusa (float A) 2025 -- Runtime Function: unsigned long accum __fractsfuda (float A) 2026 -- Runtime Function: unsigned long long accum __fractsfuta (float A) 2027 -- Runtime Function: short fract __fractdfqq (double A) 2028 -- Runtime Function: fract __fractdfhq (double A) 2029 -- Runtime Function: long fract __fractdfsq (double A) 2030 -- Runtime Function: long long fract __fractdfdq (double A) 2031 -- Runtime Function: short accum __fractdfha (double A) 2032 -- Runtime Function: accum __fractdfsa (double A) 2033 -- Runtime Function: long accum __fractdfda (double A) 2034 -- Runtime Function: long long accum __fractdfta (double A) 2035 -- Runtime Function: unsigned short fract __fractdfuqq (double A) 2036 -- Runtime Function: unsigned fract __fractdfuhq (double A) 2037 -- Runtime Function: unsigned long fract __fractdfusq (double A) 2038 -- Runtime Function: unsigned long long fract __fractdfudq (double A) 2039 -- Runtime Function: unsigned short accum __fractdfuha (double A) 2040 -- Runtime Function: unsigned accum __fractdfusa (double A) 2041 -- Runtime Function: unsigned long accum __fractdfuda (double A) 2042 -- Runtime Function: unsigned long long accum __fractdfuta (double A) 2043 These functions convert from fractional and signed non-fractionals 2044 to fractionals and signed non-fractionals, without saturation. 2045 2046 -- Runtime Function: fract __satfractqqhq2 (short fract A) 2047 -- Runtime Function: long fract __satfractqqsq2 (short fract A) 2048 -- Runtime Function: long long fract __satfractqqdq2 (short fract A) 2049 -- Runtime Function: short accum __satfractqqha (short fract A) 2050 -- Runtime Function: accum __satfractqqsa (short fract A) 2051 -- Runtime Function: long accum __satfractqqda (short fract A) 2052 -- Runtime Function: long long accum __satfractqqta (short fract A) 2053 -- Runtime Function: unsigned short fract __satfractqquqq (short fract 2054 A) 2055 -- Runtime Function: unsigned fract __satfractqquhq (short fract A) 2056 -- Runtime Function: unsigned long fract __satfractqqusq (short fract 2057 A) 2058 -- Runtime Function: unsigned long long fract __satfractqqudq (short 2059 fract A) 2060 -- Runtime Function: unsigned short accum __satfractqquha (short fract 2061 A) 2062 -- Runtime Function: unsigned accum __satfractqqusa (short fract A) 2063 -- Runtime Function: unsigned long accum __satfractqquda (short fract 2064 A) 2065 -- Runtime Function: unsigned long long accum __satfractqquta (short 2066 fract A) 2067 -- Runtime Function: short fract __satfracthqqq2 (fract A) 2068 -- Runtime Function: long fract __satfracthqsq2 (fract A) 2069 -- Runtime Function: long long fract __satfracthqdq2 (fract A) 2070 -- Runtime Function: short accum __satfracthqha (fract A) 2071 -- Runtime Function: accum __satfracthqsa (fract A) 2072 -- Runtime Function: long accum __satfracthqda (fract A) 2073 -- Runtime Function: long long accum __satfracthqta (fract A) 2074 -- Runtime Function: unsigned short fract __satfracthquqq (fract A) 2075 -- Runtime Function: unsigned fract __satfracthquhq (fract A) 2076 -- Runtime Function: unsigned long fract __satfracthqusq (fract A) 2077 -- Runtime Function: unsigned long long fract __satfracthqudq (fract A) 2078 -- Runtime Function: unsigned short accum __satfracthquha (fract A) 2079 -- Runtime Function: unsigned accum __satfracthqusa (fract A) 2080 -- Runtime Function: unsigned long accum __satfracthquda (fract A) 2081 -- Runtime Function: unsigned long long accum __satfracthquta (fract A) 2082 -- Runtime Function: short fract __satfractsqqq2 (long fract A) 2083 -- Runtime Function: fract __satfractsqhq2 (long fract A) 2084 -- Runtime Function: long long fract __satfractsqdq2 (long fract A) 2085 -- Runtime Function: short accum __satfractsqha (long fract A) 2086 -- Runtime Function: accum __satfractsqsa (long fract A) 2087 -- Runtime Function: long accum __satfractsqda (long fract A) 2088 -- Runtime Function: long long accum __satfractsqta (long fract A) 2089 -- Runtime Function: unsigned short fract __satfractsquqq (long fract 2090 A) 2091 -- Runtime Function: unsigned fract __satfractsquhq (long fract A) 2092 -- Runtime Function: unsigned long fract __satfractsqusq (long fract A) 2093 -- Runtime Function: unsigned long long fract __satfractsqudq (long 2094 fract A) 2095 -- Runtime Function: unsigned short accum __satfractsquha (long fract 2096 A) 2097 -- Runtime Function: unsigned accum __satfractsqusa (long fract A) 2098 -- Runtime Function: unsigned long accum __satfractsquda (long fract A) 2099 -- Runtime Function: unsigned long long accum __satfractsquta (long 2100 fract A) 2101 -- Runtime Function: short fract __satfractdqqq2 (long long fract A) 2102 -- Runtime Function: fract __satfractdqhq2 (long long fract A) 2103 -- Runtime Function: long fract __satfractdqsq2 (long long fract A) 2104 -- Runtime Function: short accum __satfractdqha (long long fract A) 2105 -- Runtime Function: accum __satfractdqsa (long long fract A) 2106 -- Runtime Function: long accum __satfractdqda (long long fract A) 2107 -- Runtime Function: long long accum __satfractdqta (long long fract A) 2108 -- Runtime Function: unsigned short fract __satfractdquqq (long long 2109 fract A) 2110 -- Runtime Function: unsigned fract __satfractdquhq (long long fract A) 2111 -- Runtime Function: unsigned long fract __satfractdqusq (long long 2112 fract A) 2113 -- Runtime Function: unsigned long long fract __satfractdqudq (long 2114 long fract A) 2115 -- Runtime Function: unsigned short accum __satfractdquha (long long 2116 fract A) 2117 -- Runtime Function: unsigned accum __satfractdqusa (long long fract A) 2118 -- Runtime Function: unsigned long accum __satfractdquda (long long 2119 fract A) 2120 -- Runtime Function: unsigned long long accum __satfractdquta (long 2121 long fract A) 2122 -- Runtime Function: short fract __satfracthaqq (short accum A) 2123 -- Runtime Function: fract __satfracthahq (short accum A) 2124 -- Runtime Function: long fract __satfracthasq (short accum A) 2125 -- Runtime Function: long long fract __satfracthadq (short accum A) 2126 -- Runtime Function: accum __satfracthasa2 (short accum A) 2127 -- Runtime Function: long accum __satfracthada2 (short accum A) 2128 -- Runtime Function: long long accum __satfracthata2 (short accum A) 2129 -- Runtime Function: unsigned short fract __satfracthauqq (short accum 2130 A) 2131 -- Runtime Function: unsigned fract __satfracthauhq (short accum A) 2132 -- Runtime Function: unsigned long fract __satfracthausq (short accum 2133 A) 2134 -- Runtime Function: unsigned long long fract __satfracthaudq (short 2135 accum A) 2136 -- Runtime Function: unsigned short accum __satfracthauha (short accum 2137 A) 2138 -- Runtime Function: unsigned accum __satfracthausa (short accum A) 2139 -- Runtime Function: unsigned long accum __satfracthauda (short accum 2140 A) 2141 -- Runtime Function: unsigned long long accum __satfracthauta (short 2142 accum A) 2143 -- Runtime Function: short fract __satfractsaqq (accum A) 2144 -- Runtime Function: fract __satfractsahq (accum A) 2145 -- Runtime Function: long fract __satfractsasq (accum A) 2146 -- Runtime Function: long long fract __satfractsadq (accum A) 2147 -- Runtime Function: short accum __satfractsaha2 (accum A) 2148 -- Runtime Function: long accum __satfractsada2 (accum A) 2149 -- Runtime Function: long long accum __satfractsata2 (accum A) 2150 -- Runtime Function: unsigned short fract __satfractsauqq (accum A) 2151 -- Runtime Function: unsigned fract __satfractsauhq (accum A) 2152 -- Runtime Function: unsigned long fract __satfractsausq (accum A) 2153 -- Runtime Function: unsigned long long fract __satfractsaudq (accum A) 2154 -- Runtime Function: unsigned short accum __satfractsauha (accum A) 2155 -- Runtime Function: unsigned accum __satfractsausa (accum A) 2156 -- Runtime Function: unsigned long accum __satfractsauda (accum A) 2157 -- Runtime Function: unsigned long long accum __satfractsauta (accum A) 2158 -- Runtime Function: short fract __satfractdaqq (long accum A) 2159 -- Runtime Function: fract __satfractdahq (long accum A) 2160 -- Runtime Function: long fract __satfractdasq (long accum A) 2161 -- Runtime Function: long long fract __satfractdadq (long accum A) 2162 -- Runtime Function: short accum __satfractdaha2 (long accum A) 2163 -- Runtime Function: accum __satfractdasa2 (long accum A) 2164 -- Runtime Function: long long accum __satfractdata2 (long accum A) 2165 -- Runtime Function: unsigned short fract __satfractdauqq (long accum 2166 A) 2167 -- Runtime Function: unsigned fract __satfractdauhq (long accum A) 2168 -- Runtime Function: unsigned long fract __satfractdausq (long accum A) 2169 -- Runtime Function: unsigned long long fract __satfractdaudq (long 2170 accum A) 2171 -- Runtime Function: unsigned short accum __satfractdauha (long accum 2172 A) 2173 -- Runtime Function: unsigned accum __satfractdausa (long accum A) 2174 -- Runtime Function: unsigned long accum __satfractdauda (long accum A) 2175 -- Runtime Function: unsigned long long accum __satfractdauta (long 2176 accum A) 2177 -- Runtime Function: short fract __satfracttaqq (long long accum A) 2178 -- Runtime Function: fract __satfracttahq (long long accum A) 2179 -- Runtime Function: long fract __satfracttasq (long long accum A) 2180 -- Runtime Function: long long fract __satfracttadq (long long accum A) 2181 -- Runtime Function: short accum __satfracttaha2 (long long accum A) 2182 -- Runtime Function: accum __satfracttasa2 (long long accum A) 2183 -- Runtime Function: long accum __satfracttada2 (long long accum A) 2184 -- Runtime Function: unsigned short fract __satfracttauqq (long long 2185 accum A) 2186 -- Runtime Function: unsigned fract __satfracttauhq (long long accum A) 2187 -- Runtime Function: unsigned long fract __satfracttausq (long long 2188 accum A) 2189 -- Runtime Function: unsigned long long fract __satfracttaudq (long 2190 long accum A) 2191 -- Runtime Function: unsigned short accum __satfracttauha (long long 2192 accum A) 2193 -- Runtime Function: unsigned accum __satfracttausa (long long accum A) 2194 -- Runtime Function: unsigned long accum __satfracttauda (long long 2195 accum A) 2196 -- Runtime Function: unsigned long long accum __satfracttauta (long 2197 long accum A) 2198 -- Runtime Function: short fract __satfractuqqqq (unsigned short fract 2199 A) 2200 -- Runtime Function: fract __satfractuqqhq (unsigned short fract A) 2201 -- Runtime Function: long fract __satfractuqqsq (unsigned short fract 2202 A) 2203 -- Runtime Function: long long fract __satfractuqqdq (unsigned short 2204 fract A) 2205 -- Runtime Function: short accum __satfractuqqha (unsigned short fract 2206 A) 2207 -- Runtime Function: accum __satfractuqqsa (unsigned short fract A) 2208 -- Runtime Function: long accum __satfractuqqda (unsigned short fract 2209 A) 2210 -- Runtime Function: long long accum __satfractuqqta (unsigned short 2211 fract A) 2212 -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short 2213 fract A) 2214 -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned 2215 short fract A) 2216 -- Runtime Function: unsigned long long fract __satfractuqqudq2 2217 (unsigned short fract A) 2218 -- Runtime Function: unsigned short accum __satfractuqquha (unsigned 2219 short fract A) 2220 -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short 2221 fract A) 2222 -- Runtime Function: unsigned long accum __satfractuqquda (unsigned 2223 short fract A) 2224 -- Runtime Function: unsigned long long accum __satfractuqquta 2225 (unsigned short fract A) 2226 -- Runtime Function: short fract __satfractuhqqq (unsigned fract A) 2227 -- Runtime Function: fract __satfractuhqhq (unsigned fract A) 2228 -- Runtime Function: long fract __satfractuhqsq (unsigned fract A) 2229 -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A) 2230 -- Runtime Function: short accum __satfractuhqha (unsigned fract A) 2231 -- Runtime Function: accum __satfractuhqsa (unsigned fract A) 2232 -- Runtime Function: long accum __satfractuhqda (unsigned fract A) 2233 -- Runtime Function: long long accum __satfractuhqta (unsigned fract A) 2234 -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned 2235 fract A) 2236 -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned 2237 fract A) 2238 -- Runtime Function: unsigned long long fract __satfractuhqudq2 2239 (unsigned fract A) 2240 -- Runtime Function: unsigned short accum __satfractuhquha (unsigned 2241 fract A) 2242 -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A) 2243 -- Runtime Function: unsigned long accum __satfractuhquda (unsigned 2244 fract A) 2245 -- Runtime Function: unsigned long long accum __satfractuhquta 2246 (unsigned fract A) 2247 -- Runtime Function: short fract __satfractusqqq (unsigned long fract 2248 A) 2249 -- Runtime Function: fract __satfractusqhq (unsigned long fract A) 2250 -- Runtime Function: long fract __satfractusqsq (unsigned long fract A) 2251 -- Runtime Function: long long fract __satfractusqdq (unsigned long 2252 fract A) 2253 -- Runtime Function: short accum __satfractusqha (unsigned long fract 2254 A) 2255 -- Runtime Function: accum __satfractusqsa (unsigned long fract A) 2256 -- Runtime Function: long accum __satfractusqda (unsigned long fract A) 2257 -- Runtime Function: long long accum __satfractusqta (unsigned long 2258 fract A) 2259 -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned 2260 long fract A) 2261 -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long 2262 fract A) 2263 -- Runtime Function: unsigned long long fract __satfractusqudq2 2264 (unsigned long fract A) 2265 -- Runtime Function: unsigned short accum __satfractusquha (unsigned 2266 long fract A) 2267 -- Runtime Function: unsigned accum __satfractusqusa (unsigned long 2268 fract A) 2269 -- Runtime Function: unsigned long accum __satfractusquda (unsigned 2270 long fract A) 2271 -- Runtime Function: unsigned long long accum __satfractusquta 2272 (unsigned long fract A) 2273 -- Runtime Function: short fract __satfractudqqq (unsigned long long 2274 fract A) 2275 -- Runtime Function: fract __satfractudqhq (unsigned long long fract A) 2276 -- Runtime Function: long fract __satfractudqsq (unsigned long long 2277 fract A) 2278 -- Runtime Function: long long fract __satfractudqdq (unsigned long 2279 long fract A) 2280 -- Runtime Function: short accum __satfractudqha (unsigned long long 2281 fract A) 2282 -- Runtime Function: accum __satfractudqsa (unsigned long long fract A) 2283 -- Runtime Function: long accum __satfractudqda (unsigned long long 2284 fract A) 2285 -- Runtime Function: long long accum __satfractudqta (unsigned long 2286 long fract A) 2287 -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned 2288 long long fract A) 2289 -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long 2290 long fract A) 2291 -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned 2292 long long fract A) 2293 -- Runtime Function: unsigned short accum __satfractudquha (unsigned 2294 long long fract A) 2295 -- Runtime Function: unsigned accum __satfractudqusa (unsigned long 2296 long fract A) 2297 -- Runtime Function: unsigned long accum __satfractudquda (unsigned 2298 long long fract A) 2299 -- Runtime Function: unsigned long long accum __satfractudquta 2300 (unsigned long long fract A) 2301 -- Runtime Function: short fract __satfractuhaqq (unsigned short accum 2302 A) 2303 -- Runtime Function: fract __satfractuhahq (unsigned short accum A) 2304 -- Runtime Function: long fract __satfractuhasq (unsigned short accum 2305 A) 2306 -- Runtime Function: long long fract __satfractuhadq (unsigned short 2307 accum A) 2308 -- Runtime Function: short accum __satfractuhaha (unsigned short accum 2309 A) 2310 -- Runtime Function: accum __satfractuhasa (unsigned short accum A) 2311 -- Runtime Function: long accum __satfractuhada (unsigned short accum 2312 A) 2313 -- Runtime Function: long long accum __satfractuhata (unsigned short 2314 accum A) 2315 -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned 2316 short accum A) 2317 -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short 2318 accum A) 2319 -- Runtime Function: unsigned long fract __satfractuhausq (unsigned 2320 short accum A) 2321 -- Runtime Function: unsigned long long fract __satfractuhaudq 2322 (unsigned short accum A) 2323 -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short 2324 accum A) 2325 -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned 2326 short accum A) 2327 -- Runtime Function: unsigned long long accum __satfractuhauta2 2328 (unsigned short accum A) 2329 -- Runtime Function: short fract __satfractusaqq (unsigned accum A) 2330 -- Runtime Function: fract __satfractusahq (unsigned accum A) 2331 -- Runtime Function: long fract __satfractusasq (unsigned accum A) 2332 -- Runtime Function: long long fract __satfractusadq (unsigned accum A) 2333 -- Runtime Function: short accum __satfractusaha (unsigned accum A) 2334 -- Runtime Function: accum __satfractusasa (unsigned accum A) 2335 -- Runtime Function: long accum __satfractusada (unsigned accum A) 2336 -- Runtime Function: long long accum __satfractusata (unsigned accum A) 2337 -- Runtime Function: unsigned short fract __satfractusauqq (unsigned 2338 accum A) 2339 -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A) 2340 -- Runtime Function: unsigned long fract __satfractusausq (unsigned 2341 accum A) 2342 -- Runtime Function: unsigned long long fract __satfractusaudq 2343 (unsigned accum A) 2344 -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned 2345 accum A) 2346 -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned 2347 accum A) 2348 -- Runtime Function: unsigned long long accum __satfractusauta2 2349 (unsigned accum A) 2350 -- Runtime Function: short fract __satfractudaqq (unsigned long accum 2351 A) 2352 -- Runtime Function: fract __satfractudahq (unsigned long accum A) 2353 -- Runtime Function: long fract __satfractudasq (unsigned long accum A) 2354 -- Runtime Function: long long fract __satfractudadq (unsigned long 2355 accum A) 2356 -- Runtime Function: short accum __satfractudaha (unsigned long accum 2357 A) 2358 -- Runtime Function: accum __satfractudasa (unsigned long accum A) 2359 -- Runtime Function: long accum __satfractudada (unsigned long accum A) 2360 -- Runtime Function: long long accum __satfractudata (unsigned long 2361 accum A) 2362 -- Runtime Function: unsigned short fract __satfractudauqq (unsigned 2363 long accum A) 2364 -- Runtime Function: unsigned fract __satfractudauhq (unsigned long 2365 accum A) 2366 -- Runtime Function: unsigned long fract __satfractudausq (unsigned 2367 long accum A) 2368 -- Runtime Function: unsigned long long fract __satfractudaudq 2369 (unsigned long accum A) 2370 -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned 2371 long accum A) 2372 -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long 2373 accum A) 2374 -- Runtime Function: unsigned long long accum __satfractudauta2 2375 (unsigned long accum A) 2376 -- Runtime Function: short fract __satfractutaqq (unsigned long long 2377 accum A) 2378 -- Runtime Function: fract __satfractutahq (unsigned long long accum A) 2379 -- Runtime Function: long fract __satfractutasq (unsigned long long 2380 accum A) 2381 -- Runtime Function: long long fract __satfractutadq (unsigned long 2382 long accum A) 2383 -- Runtime Function: short accum __satfractutaha (unsigned long long 2384 accum A) 2385 -- Runtime Function: accum __satfractutasa (unsigned long long accum A) 2386 -- Runtime Function: long accum __satfractutada (unsigned long long 2387 accum A) 2388 -- Runtime Function: long long accum __satfractutata (unsigned long 2389 long accum A) 2390 -- Runtime Function: unsigned short fract __satfractutauqq (unsigned 2391 long long accum A) 2392 -- Runtime Function: unsigned fract __satfractutauhq (unsigned long 2393 long accum A) 2394 -- Runtime Function: unsigned long fract __satfractutausq (unsigned 2395 long long accum A) 2396 -- Runtime Function: unsigned long long fract __satfractutaudq 2397 (unsigned long long accum A) 2398 -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned 2399 long long accum A) 2400 -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long 2401 long accum A) 2402 -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned 2403 long long accum A) 2404 -- Runtime Function: short fract __satfractqiqq (signed char A) 2405 -- Runtime Function: fract __satfractqihq (signed char A) 2406 -- Runtime Function: long fract __satfractqisq (signed char A) 2407 -- Runtime Function: long long fract __satfractqidq (signed char A) 2408 -- Runtime Function: short accum __satfractqiha (signed char A) 2409 -- Runtime Function: accum __satfractqisa (signed char A) 2410 -- Runtime Function: long accum __satfractqida (signed char A) 2411 -- Runtime Function: long long accum __satfractqita (signed char A) 2412 -- Runtime Function: unsigned short fract __satfractqiuqq (signed char 2413 A) 2414 -- Runtime Function: unsigned fract __satfractqiuhq (signed char A) 2415 -- Runtime Function: unsigned long fract __satfractqiusq (signed char 2416 A) 2417 -- Runtime Function: unsigned long long fract __satfractqiudq (signed 2418 char A) 2419 -- Runtime Function: unsigned short accum __satfractqiuha (signed char 2420 A) 2421 -- Runtime Function: unsigned accum __satfractqiusa (signed char A) 2422 -- Runtime Function: unsigned long accum __satfractqiuda (signed char 2423 A) 2424 -- Runtime Function: unsigned long long accum __satfractqiuta (signed 2425 char A) 2426 -- Runtime Function: short fract __satfracthiqq (short A) 2427 -- Runtime Function: fract __satfracthihq (short A) 2428 -- Runtime Function: long fract __satfracthisq (short A) 2429 -- Runtime Function: long long fract __satfracthidq (short A) 2430 -- Runtime Function: short accum __satfracthiha (short A) 2431 -- Runtime Function: accum __satfracthisa (short A) 2432 -- Runtime Function: long accum __satfracthida (short A) 2433 -- Runtime Function: long long accum __satfracthita (short A) 2434 -- Runtime Function: unsigned short fract __satfracthiuqq (short A) 2435 -- Runtime Function: unsigned fract __satfracthiuhq (short A) 2436 -- Runtime Function: unsigned long fract __satfracthiusq (short A) 2437 -- Runtime Function: unsigned long long fract __satfracthiudq (short A) 2438 -- Runtime Function: unsigned short accum __satfracthiuha (short A) 2439 -- Runtime Function: unsigned accum __satfracthiusa (short A) 2440 -- Runtime Function: unsigned long accum __satfracthiuda (short A) 2441 -- Runtime Function: unsigned long long accum __satfracthiuta (short A) 2442 -- Runtime Function: short fract __satfractsiqq (int A) 2443 -- Runtime Function: fract __satfractsihq (int A) 2444 -- Runtime Function: long fract __satfractsisq (int A) 2445 -- Runtime Function: long long fract __satfractsidq (int A) 2446 -- Runtime Function: short accum __satfractsiha (int A) 2447 -- Runtime Function: accum __satfractsisa (int A) 2448 -- Runtime Function: long accum __satfractsida (int A) 2449 -- Runtime Function: long long accum __satfractsita (int A) 2450 -- Runtime Function: unsigned short fract __satfractsiuqq (int A) 2451 -- Runtime Function: unsigned fract __satfractsiuhq (int A) 2452 -- Runtime Function: unsigned long fract __satfractsiusq (int A) 2453 -- Runtime Function: unsigned long long fract __satfractsiudq (int A) 2454 -- Runtime Function: unsigned short accum __satfractsiuha (int A) 2455 -- Runtime Function: unsigned accum __satfractsiusa (int A) 2456 -- Runtime Function: unsigned long accum __satfractsiuda (int A) 2457 -- Runtime Function: unsigned long long accum __satfractsiuta (int A) 2458 -- Runtime Function: short fract __satfractdiqq (long A) 2459 -- Runtime Function: fract __satfractdihq (long A) 2460 -- Runtime Function: long fract __satfractdisq (long A) 2461 -- Runtime Function: long long fract __satfractdidq (long A) 2462 -- Runtime Function: short accum __satfractdiha (long A) 2463 -- Runtime Function: accum __satfractdisa (long A) 2464 -- Runtime Function: long accum __satfractdida (long A) 2465 -- Runtime Function: long long accum __satfractdita (long A) 2466 -- Runtime Function: unsigned short fract __satfractdiuqq (long A) 2467 -- Runtime Function: unsigned fract __satfractdiuhq (long A) 2468 -- Runtime Function: unsigned long fract __satfractdiusq (long A) 2469 -- Runtime Function: unsigned long long fract __satfractdiudq (long A) 2470 -- Runtime Function: unsigned short accum __satfractdiuha (long A) 2471 -- Runtime Function: unsigned accum __satfractdiusa (long A) 2472 -- Runtime Function: unsigned long accum __satfractdiuda (long A) 2473 -- Runtime Function: unsigned long long accum __satfractdiuta (long A) 2474 -- Runtime Function: short fract __satfracttiqq (long long A) 2475 -- Runtime Function: fract __satfracttihq (long long A) 2476 -- Runtime Function: long fract __satfracttisq (long long A) 2477 -- Runtime Function: long long fract __satfracttidq (long long A) 2478 -- Runtime Function: short accum __satfracttiha (long long A) 2479 -- Runtime Function: accum __satfracttisa (long long A) 2480 -- Runtime Function: long accum __satfracttida (long long A) 2481 -- Runtime Function: long long accum __satfracttita (long long A) 2482 -- Runtime Function: unsigned short fract __satfracttiuqq (long long A) 2483 -- Runtime Function: unsigned fract __satfracttiuhq (long long A) 2484 -- Runtime Function: unsigned long fract __satfracttiusq (long long A) 2485 -- Runtime Function: unsigned long long fract __satfracttiudq (long 2486 long A) 2487 -- Runtime Function: unsigned short accum __satfracttiuha (long long A) 2488 -- Runtime Function: unsigned accum __satfracttiusa (long long A) 2489 -- Runtime Function: unsigned long accum __satfracttiuda (long long A) 2490 -- Runtime Function: unsigned long long accum __satfracttiuta (long 2491 long A) 2492 -- Runtime Function: short fract __satfractsfqq (float A) 2493 -- Runtime Function: fract __satfractsfhq (float A) 2494 -- Runtime Function: long fract __satfractsfsq (float A) 2495 -- Runtime Function: long long fract __satfractsfdq (float A) 2496 -- Runtime Function: short accum __satfractsfha (float A) 2497 -- Runtime Function: accum __satfractsfsa (float A) 2498 -- Runtime Function: long accum __satfractsfda (float A) 2499 -- Runtime Function: long long accum __satfractsfta (float A) 2500 -- Runtime Function: unsigned short fract __satfractsfuqq (float A) 2501 -- Runtime Function: unsigned fract __satfractsfuhq (float A) 2502 -- Runtime Function: unsigned long fract __satfractsfusq (float A) 2503 -- Runtime Function: unsigned long long fract __satfractsfudq (float A) 2504 -- Runtime Function: unsigned short accum __satfractsfuha (float A) 2505 -- Runtime Function: unsigned accum __satfractsfusa (float A) 2506 -- Runtime Function: unsigned long accum __satfractsfuda (float A) 2507 -- Runtime Function: unsigned long long accum __satfractsfuta (float A) 2508 -- Runtime Function: short fract __satfractdfqq (double A) 2509 -- Runtime Function: fract __satfractdfhq (double A) 2510 -- Runtime Function: long fract __satfractdfsq (double A) 2511 -- Runtime Function: long long fract __satfractdfdq (double A) 2512 -- Runtime Function: short accum __satfractdfha (double A) 2513 -- Runtime Function: accum __satfractdfsa (double A) 2514 -- Runtime Function: long accum __satfractdfda (double A) 2515 -- Runtime Function: long long accum __satfractdfta (double A) 2516 -- Runtime Function: unsigned short fract __satfractdfuqq (double A) 2517 -- Runtime Function: unsigned fract __satfractdfuhq (double A) 2518 -- Runtime Function: unsigned long fract __satfractdfusq (double A) 2519 -- Runtime Function: unsigned long long fract __satfractdfudq (double 2520 A) 2521 -- Runtime Function: unsigned short accum __satfractdfuha (double A) 2522 -- Runtime Function: unsigned accum __satfractdfusa (double A) 2523 -- Runtime Function: unsigned long accum __satfractdfuda (double A) 2524 -- Runtime Function: unsigned long long accum __satfractdfuta (double 2525 A) 2526 The functions convert from fractional and signed non-fractionals to 2527 fractionals, with saturation. 2528 2529 -- Runtime Function: unsigned char __fractunsqqqi (short fract A) 2530 -- Runtime Function: unsigned short __fractunsqqhi (short fract A) 2531 -- Runtime Function: unsigned int __fractunsqqsi (short fract A) 2532 -- Runtime Function: unsigned long __fractunsqqdi (short fract A) 2533 -- Runtime Function: unsigned long long __fractunsqqti (short fract A) 2534 -- Runtime Function: unsigned char __fractunshqqi (fract A) 2535 -- Runtime Function: unsigned short __fractunshqhi (fract A) 2536 -- Runtime Function: unsigned int __fractunshqsi (fract A) 2537 -- Runtime Function: unsigned long __fractunshqdi (fract A) 2538 -- Runtime Function: unsigned long long __fractunshqti (fract A) 2539 -- Runtime Function: unsigned char __fractunssqqi (long fract A) 2540 -- Runtime Function: unsigned short __fractunssqhi (long fract A) 2541 -- Runtime Function: unsigned int __fractunssqsi (long fract A) 2542 -- Runtime Function: unsigned long __fractunssqdi (long fract A) 2543 -- Runtime Function: unsigned long long __fractunssqti (long fract A) 2544 -- Runtime Function: unsigned char __fractunsdqqi (long long fract A) 2545 -- Runtime Function: unsigned short __fractunsdqhi (long long fract A) 2546 -- Runtime Function: unsigned int __fractunsdqsi (long long fract A) 2547 -- Runtime Function: unsigned long __fractunsdqdi (long long fract A) 2548 -- Runtime Function: unsigned long long __fractunsdqti (long long 2549 fract A) 2550 -- Runtime Function: unsigned char __fractunshaqi (short accum A) 2551 -- Runtime Function: unsigned short __fractunshahi (short accum A) 2552 -- Runtime Function: unsigned int __fractunshasi (short accum A) 2553 -- Runtime Function: unsigned long __fractunshadi (short accum A) 2554 -- Runtime Function: unsigned long long __fractunshati (short accum A) 2555 -- Runtime Function: unsigned char __fractunssaqi (accum A) 2556 -- Runtime Function: unsigned short __fractunssahi (accum A) 2557 -- Runtime Function: unsigned int __fractunssasi (accum A) 2558 -- Runtime Function: unsigned long __fractunssadi (accum A) 2559 -- Runtime Function: unsigned long long __fractunssati (accum A) 2560 -- Runtime Function: unsigned char __fractunsdaqi (long accum A) 2561 -- Runtime Function: unsigned short __fractunsdahi (long accum A) 2562 -- Runtime Function: unsigned int __fractunsdasi (long accum A) 2563 -- Runtime Function: unsigned long __fractunsdadi (long accum A) 2564 -- Runtime Function: unsigned long long __fractunsdati (long accum A) 2565 -- Runtime Function: unsigned char __fractunstaqi (long long accum A) 2566 -- Runtime Function: unsigned short __fractunstahi (long long accum A) 2567 -- Runtime Function: unsigned int __fractunstasi (long long accum A) 2568 -- Runtime Function: unsigned long __fractunstadi (long long accum A) 2569 -- Runtime Function: unsigned long long __fractunstati (long long 2570 accum A) 2571 -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short 2572 fract A) 2573 -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short 2574 fract A) 2575 -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short 2576 fract A) 2577 -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short 2578 fract A) 2579 -- Runtime Function: unsigned long long __fractunsuqqti (unsigned 2580 short fract A) 2581 -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A) 2582 -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A) 2583 -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A) 2584 -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A) 2585 -- Runtime Function: unsigned long long __fractunsuhqti (unsigned 2586 fract A) 2587 -- Runtime Function: unsigned char __fractunsusqqi (unsigned long 2588 fract A) 2589 -- Runtime Function: unsigned short __fractunsusqhi (unsigned long 2590 fract A) 2591 -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract 2592 A) 2593 -- Runtime Function: unsigned long __fractunsusqdi (unsigned long 2594 fract A) 2595 -- Runtime Function: unsigned long long __fractunsusqti (unsigned long 2596 fract A) 2597 -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long 2598 fract A) 2599 -- Runtime Function: unsigned short __fractunsudqhi (unsigned long 2600 long fract A) 2601 -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long 2602 fract A) 2603 -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long 2604 fract A) 2605 -- Runtime Function: unsigned long long __fractunsudqti (unsigned long 2606 long fract A) 2607 -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short 2608 accum A) 2609 -- Runtime Function: unsigned short __fractunsuhahi (unsigned short 2610 accum A) 2611 -- Runtime Function: unsigned int __fractunsuhasi (unsigned short 2612 accum A) 2613 -- Runtime Function: unsigned long __fractunsuhadi (unsigned short 2614 accum A) 2615 -- Runtime Function: unsigned long long __fractunsuhati (unsigned 2616 short accum A) 2617 -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A) 2618 -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A) 2619 -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A) 2620 -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A) 2621 -- Runtime Function: unsigned long long __fractunsusati (unsigned 2622 accum A) 2623 -- Runtime Function: unsigned char __fractunsudaqi (unsigned long 2624 accum A) 2625 -- Runtime Function: unsigned short __fractunsudahi (unsigned long 2626 accum A) 2627 -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum 2628 A) 2629 -- Runtime Function: unsigned long __fractunsudadi (unsigned long 2630 accum A) 2631 -- Runtime Function: unsigned long long __fractunsudati (unsigned long 2632 accum A) 2633 -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long 2634 accum A) 2635 -- Runtime Function: unsigned short __fractunsutahi (unsigned long 2636 long accum A) 2637 -- Runtime Function: unsigned int __fractunsutasi (unsigned long long 2638 accum A) 2639 -- Runtime Function: unsigned long __fractunsutadi (unsigned long long 2640 accum A) 2641 -- Runtime Function: unsigned long long __fractunsutati (unsigned long 2642 long accum A) 2643 -- Runtime Function: short fract __fractunsqiqq (unsigned char A) 2644 -- Runtime Function: fract __fractunsqihq (unsigned char A) 2645 -- Runtime Function: long fract __fractunsqisq (unsigned char A) 2646 -- Runtime Function: long long fract __fractunsqidq (unsigned char A) 2647 -- Runtime Function: short accum __fractunsqiha (unsigned char A) 2648 -- Runtime Function: accum __fractunsqisa (unsigned char A) 2649 -- Runtime Function: long accum __fractunsqida (unsigned char A) 2650 -- Runtime Function: long long accum __fractunsqita (unsigned char A) 2651 -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned 2652 char A) 2653 -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A) 2654 -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned 2655 char A) 2656 -- Runtime Function: unsigned long long fract __fractunsqiudq 2657 (unsigned char A) 2658 -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned 2659 char A) 2660 -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A) 2661 -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned 2662 char A) 2663 -- Runtime Function: unsigned long long accum __fractunsqiuta 2664 (unsigned char A) 2665 -- Runtime Function: short fract __fractunshiqq (unsigned short A) 2666 -- Runtime Function: fract __fractunshihq (unsigned short A) 2667 -- Runtime Function: long fract __fractunshisq (unsigned short A) 2668 -- Runtime Function: long long fract __fractunshidq (unsigned short A) 2669 -- Runtime Function: short accum __fractunshiha (unsigned short A) 2670 -- Runtime Function: accum __fractunshisa (unsigned short A) 2671 -- Runtime Function: long accum __fractunshida (unsigned short A) 2672 -- Runtime Function: long long accum __fractunshita (unsigned short A) 2673 -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned 2674 short A) 2675 -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A) 2676 -- Runtime Function: unsigned long fract __fractunshiusq (unsigned 2677 short A) 2678 -- Runtime Function: unsigned long long fract __fractunshiudq 2679 (unsigned short A) 2680 -- Runtime Function: unsigned short accum __fractunshiuha (unsigned 2681 short A) 2682 -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A) 2683 -- Runtime Function: unsigned long accum __fractunshiuda (unsigned 2684 short A) 2685 -- Runtime Function: unsigned long long accum __fractunshiuta 2686 (unsigned short A) 2687 -- Runtime Function: short fract __fractunssiqq (unsigned int A) 2688 -- Runtime Function: fract __fractunssihq (unsigned int A) 2689 -- Runtime Function: long fract __fractunssisq (unsigned int A) 2690 -- Runtime Function: long long fract __fractunssidq (unsigned int A) 2691 -- Runtime Function: short accum __fractunssiha (unsigned int A) 2692 -- Runtime Function: accum __fractunssisa (unsigned int A) 2693 -- Runtime Function: long accum __fractunssida (unsigned int A) 2694 -- Runtime Function: long long accum __fractunssita (unsigned int A) 2695 -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned 2696 int A) 2697 -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A) 2698 -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int 2699 A) 2700 -- Runtime Function: unsigned long long fract __fractunssiudq 2701 (unsigned int A) 2702 -- Runtime Function: unsigned short accum __fractunssiuha (unsigned 2703 int A) 2704 -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A) 2705 -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int 2706 A) 2707 -- Runtime Function: unsigned long long accum __fractunssiuta 2708 (unsigned int A) 2709 -- Runtime Function: short fract __fractunsdiqq (unsigned long A) 2710 -- Runtime Function: fract __fractunsdihq (unsigned long A) 2711 -- Runtime Function: long fract __fractunsdisq (unsigned long A) 2712 -- Runtime Function: long long fract __fractunsdidq (unsigned long A) 2713 -- Runtime Function: short accum __fractunsdiha (unsigned long A) 2714 -- Runtime Function: accum __fractunsdisa (unsigned long A) 2715 -- Runtime Function: long accum __fractunsdida (unsigned long A) 2716 -- Runtime Function: long long accum __fractunsdita (unsigned long A) 2717 -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned 2718 long A) 2719 -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A) 2720 -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned 2721 long A) 2722 -- Runtime Function: unsigned long long fract __fractunsdiudq 2723 (unsigned long A) 2724 -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned 2725 long A) 2726 -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A) 2727 -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned 2728 long A) 2729 -- Runtime Function: unsigned long long accum __fractunsdiuta 2730 (unsigned long A) 2731 -- Runtime Function: short fract __fractunstiqq (unsigned long long A) 2732 -- Runtime Function: fract __fractunstihq (unsigned long long A) 2733 -- Runtime Function: long fract __fractunstisq (unsigned long long A) 2734 -- Runtime Function: long long fract __fractunstidq (unsigned long 2735 long A) 2736 -- Runtime Function: short accum __fractunstiha (unsigned long long A) 2737 -- Runtime Function: accum __fractunstisa (unsigned long long A) 2738 -- Runtime Function: long accum __fractunstida (unsigned long long A) 2739 -- Runtime Function: long long accum __fractunstita (unsigned long 2740 long A) 2741 -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned 2742 long long A) 2743 -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long 2744 long A) 2745 -- Runtime Function: unsigned long fract __fractunstiusq (unsigned 2746 long long A) 2747 -- Runtime Function: unsigned long long fract __fractunstiudq 2748 (unsigned long long A) 2749 -- Runtime Function: unsigned short accum __fractunstiuha (unsigned 2750 long long A) 2751 -- Runtime Function: unsigned accum __fractunstiusa (unsigned long 2752 long A) 2753 -- Runtime Function: unsigned long accum __fractunstiuda (unsigned 2754 long long A) 2755 -- Runtime Function: unsigned long long accum __fractunstiuta 2756 (unsigned long long A) 2757 These functions convert from fractionals to unsigned 2758 non-fractionals; and from unsigned non-fractionals to fractionals, 2759 without saturation. 2760 2761 -- Runtime Function: short fract __satfractunsqiqq (unsigned char A) 2762 -- Runtime Function: fract __satfractunsqihq (unsigned char A) 2763 -- Runtime Function: long fract __satfractunsqisq (unsigned char A) 2764 -- Runtime Function: long long fract __satfractunsqidq (unsigned char 2765 A) 2766 -- Runtime Function: short accum __satfractunsqiha (unsigned char A) 2767 -- Runtime Function: accum __satfractunsqisa (unsigned char A) 2768 -- Runtime Function: long accum __satfractunsqida (unsigned char A) 2769 -- Runtime Function: long long accum __satfractunsqita (unsigned char 2770 A) 2771 -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned 2772 char A) 2773 -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char 2774 A) 2775 -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned 2776 char A) 2777 -- Runtime Function: unsigned long long fract __satfractunsqiudq 2778 (unsigned char A) 2779 -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned 2780 char A) 2781 -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char 2782 A) 2783 -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned 2784 char A) 2785 -- Runtime Function: unsigned long long accum __satfractunsqiuta 2786 (unsigned char A) 2787 -- Runtime Function: short fract __satfractunshiqq (unsigned short A) 2788 -- Runtime Function: fract __satfractunshihq (unsigned short A) 2789 -- Runtime Function: long fract __satfractunshisq (unsigned short A) 2790 -- Runtime Function: long long fract __satfractunshidq (unsigned short 2791 A) 2792 -- Runtime Function: short accum __satfractunshiha (unsigned short A) 2793 -- Runtime Function: accum __satfractunshisa (unsigned short A) 2794 -- Runtime Function: long accum __satfractunshida (unsigned short A) 2795 -- Runtime Function: long long accum __satfractunshita (unsigned short 2796 A) 2797 -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned 2798 short A) 2799 -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short 2800 A) 2801 -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned 2802 short A) 2803 -- Runtime Function: unsigned long long fract __satfractunshiudq 2804 (unsigned short A) 2805 -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned 2806 short A) 2807 -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short 2808 A) 2809 -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned 2810 short A) 2811 -- Runtime Function: unsigned long long accum __satfractunshiuta 2812 (unsigned short A) 2813 -- Runtime Function: short fract __satfractunssiqq (unsigned int A) 2814 -- Runtime Function: fract __satfractunssihq (unsigned int A) 2815 -- Runtime Function: long fract __satfractunssisq (unsigned int A) 2816 -- Runtime Function: long long fract __satfractunssidq (unsigned int A) 2817 -- Runtime Function: short accum __satfractunssiha (unsigned int A) 2818 -- Runtime Function: accum __satfractunssisa (unsigned int A) 2819 -- Runtime Function: long accum __satfractunssida (unsigned int A) 2820 -- Runtime Function: long long accum __satfractunssita (unsigned int A) 2821 -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned 2822 int A) 2823 -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A) 2824 -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned 2825 int A) 2826 -- Runtime Function: unsigned long long fract __satfractunssiudq 2827 (unsigned int A) 2828 -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned 2829 int A) 2830 -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A) 2831 -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned 2832 int A) 2833 -- Runtime Function: unsigned long long accum __satfractunssiuta 2834 (unsigned int A) 2835 -- Runtime Function: short fract __satfractunsdiqq (unsigned long A) 2836 -- Runtime Function: fract __satfractunsdihq (unsigned long A) 2837 -- Runtime Function: long fract __satfractunsdisq (unsigned long A) 2838 -- Runtime Function: long long fract __satfractunsdidq (unsigned long 2839 A) 2840 -- Runtime Function: short accum __satfractunsdiha (unsigned long A) 2841 -- Runtime Function: accum __satfractunsdisa (unsigned long A) 2842 -- Runtime Function: long accum __satfractunsdida (unsigned long A) 2843 -- Runtime Function: long long accum __satfractunsdita (unsigned long 2844 A) 2845 -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned 2846 long A) 2847 -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long 2848 A) 2849 -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned 2850 long A) 2851 -- Runtime Function: unsigned long long fract __satfractunsdiudq 2852 (unsigned long A) 2853 -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned 2854 long A) 2855 -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long 2856 A) 2857 -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned 2858 long A) 2859 -- Runtime Function: unsigned long long accum __satfractunsdiuta 2860 (unsigned long A) 2861 -- Runtime Function: short fract __satfractunstiqq (unsigned long long 2862 A) 2863 -- Runtime Function: fract __satfractunstihq (unsigned long long A) 2864 -- Runtime Function: long fract __satfractunstisq (unsigned long long 2865 A) 2866 -- Runtime Function: long long fract __satfractunstidq (unsigned long 2867 long A) 2868 -- Runtime Function: short accum __satfractunstiha (unsigned long long 2869 A) 2870 -- Runtime Function: accum __satfractunstisa (unsigned long long A) 2871 -- Runtime Function: long accum __satfractunstida (unsigned long long 2872 A) 2873 -- Runtime Function: long long accum __satfractunstita (unsigned long 2874 long A) 2875 -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned 2876 long long A) 2877 -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long 2878 long A) 2879 -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned 2880 long long A) 2881 -- Runtime Function: unsigned long long fract __satfractunstiudq 2882 (unsigned long long A) 2883 -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned 2884 long long A) 2885 -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long 2886 long A) 2887 -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned 2888 long long A) 2889 -- Runtime Function: unsigned long long accum __satfractunstiuta 2890 (unsigned long long A) 2891 These functions convert from unsigned non-fractionals to 2892 fractionals, with saturation. 2893 2894 2895 File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Fixed-point fractional library routines, Up: Libgcc 2896 2897 4.5 Language-independent routines for exception handling 2898 ======================================================== 2899 2900 document me! 2901 2902 _Unwind_DeleteException 2903 _Unwind_Find_FDE 2904 _Unwind_ForcedUnwind 2905 _Unwind_GetGR 2906 _Unwind_GetIP 2907 _Unwind_GetLanguageSpecificData 2908 _Unwind_GetRegionStart 2909 _Unwind_GetTextRelBase 2910 _Unwind_GetDataRelBase 2911 _Unwind_RaiseException 2912 _Unwind_Resume 2913 _Unwind_SetGR 2914 _Unwind_SetIP 2915 _Unwind_FindEnclosingFunction 2916 _Unwind_SjLj_Register 2917 _Unwind_SjLj_Unregister 2918 _Unwind_SjLj_RaiseException 2919 _Unwind_SjLj_ForcedUnwind 2920 _Unwind_SjLj_Resume 2921 __deregister_frame 2922 __deregister_frame_info 2923 __deregister_frame_info_bases 2924 __register_frame 2925 __register_frame_info 2926 __register_frame_info_bases 2927 __register_frame_info_table 2928 __register_frame_info_table_bases 2929 __register_frame_table 2930 2931 2932 File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc 2933 2934 4.6 Miscellaneous runtime library routines 2935 ========================================== 2936 2937 4.6.1 Cache control functions 2938 ----------------------------- 2939 2940 -- Runtime Function: void __clear_cache (char *BEG, char *END) 2941 This function clears the instruction cache between BEG and END. 2942 2943 4.6.2 Split stack functions and variables 2944 ----------------------------------------- 2945 2946 -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void 2947 *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void 2948 **INITIAL_SP) 2949 When using `-fsplit-stack', this call may be used to iterate over 2950 the stack segments. It may be called like this: 2951 void *next_segment = NULL; 2952 void *next_sp = NULL; 2953 void *initial_sp = NULL; 2954 void *stack; 2955 size_t stack_size; 2956 while ((stack = __splitstack_find (next_segment, next_sp, 2957 &stack_size, &next_segment, 2958 &next_sp, &initial_sp)) 2959 != NULL) 2960 { 2961 /* Stack segment starts at stack and is 2962 stack_size bytes long. */ 2963 } 2964 2965 There is no way to iterate over the stack segments of a different 2966 thread. However, what is permitted is for one thread to call this 2967 with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT, 2968 NEXT_SP, and INITIAL_SP to a different thread, and then to suspend 2969 one way or another. A different thread may run the subsequent 2970 `__splitstack_find' iterations. Of course, this will only work if 2971 the first thread is suspended while the second thread is calling 2972 `__splitstack_find'. If not, the second thread could be looking 2973 at the stack while it is changing, and anything could happen. 2974 2975 -- Variable: __morestack_segments 2976 -- Variable: __morestack_current_segment 2977 -- Variable: __morestack_initial_sp 2978 Internal variables used by the `-fsplit-stack' implementation. 2979 2980 2981 File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top 2982 2983 5 Language Front Ends in GCC 2984 **************************** 2985 2986 The interface to front ends for languages in GCC, and in particular the 2987 `tree' structure (*note GENERIC::), was initially designed for C, and 2988 many aspects of it are still somewhat biased towards C and C-like 2989 languages. It is, however, reasonably well suited to other procedural 2990 languages, and front ends for many such languages have been written for 2991 GCC. 2992 2993 Writing a compiler as a front end for GCC, rather than compiling 2994 directly to assembler or generating C code which is then compiled by 2995 GCC, has several advantages: 2996 2997 * GCC front ends benefit from the support for many different target 2998 machines already present in GCC. 2999 3000 * GCC front ends benefit from all the optimizations in GCC. Some of 3001 these, such as alias analysis, may work better when GCC is 3002 compiling directly from source code then when it is compiling from 3003 generated C code. 3004 3005 * Better debugging information is generated when compiling directly 3006 from source code than when going via intermediate generated C code. 3007 3008 Because of the advantages of writing a compiler as a GCC front end, 3009 GCC front ends have also been created for languages very different from 3010 those for which GCC was designed, such as the declarative 3011 logic/functional language Mercury. For these reasons, it may also be 3012 useful to implement compilers created for specialized purposes (for 3013 example, as part of a research project) as GCC front ends. 3014 3015 3016 File: gccint.info, Node: Source Tree, Next: Testsuites, Prev: Languages, Up: Top 3017 3018 6 Source Tree Structure and Build System 3019 **************************************** 3020 3021 This chapter describes the structure of the GCC source tree, and how 3022 GCC is built. The user documentation for building and installing GCC 3023 is in a separate manual (`http://gcc.gnu.org/install/'), with which it 3024 is presumed that you are familiar. 3025 3026 * Menu: 3027 3028 * Configure Terms:: Configuration terminology and history. 3029 * Top Level:: The top level source directory. 3030 * gcc Directory:: The `gcc' subdirectory. 3031 3032 3033 File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree 3034 3035 6.1 Configure Terms and History 3036 =============================== 3037 3038 The configure and build process has a long and colorful history, and can 3039 be confusing to anyone who doesn't know why things are the way they are. 3040 While there are other documents which describe the configuration process 3041 in detail, here are a few things that everyone working on GCC should 3042 know. 3043 3044 There are three system names that the build knows about: the machine 3045 you are building on ("build"), the machine that you are building for 3046 ("host"), and the machine that GCC will produce code for ("target"). 3047 When you configure GCC, you specify these with `--build=', `--host=', 3048 and `--target='. 3049 3050 Specifying the host without specifying the build should be avoided, as 3051 `configure' may (and once did) assume that the host you specify is also 3052 the build, which may not be true. 3053 3054 If build, host, and target are all the same, this is called a 3055 "native". If build and host are the same but target is different, this 3056 is called a "cross". If build, host, and target are all different this 3057 is called a "canadian" (for obscure reasons dealing with Canada's 3058 political party and the background of the person working on the build 3059 at that time). If host and target are the same, but build is 3060 different, you are using a cross-compiler to build a native for a 3061 different system. Some people call this a "host-x-host", "crossed 3062 native", or "cross-built native". If build and target are the same, 3063 but host is different, you are using a cross compiler to build a cross 3064 compiler that produces code for the machine you're building on. This 3065 is rare, so there is no common way of describing it. There is a 3066 proposal to call this a "crossback". 3067 3068 If build and host are the same, the GCC you are building will also be 3069 used to build the target libraries (like `libstdc++'). If build and 3070 host are different, you must have already built and installed a cross 3071 compiler that will be used to build the target libraries (if you 3072 configured with `--target=foo-bar', this compiler will be called 3073 `foo-bar-gcc'). 3074 3075 In the case of target libraries, the machine you're building for is the 3076 machine you specified with `--target'. So, build is the machine you're 3077 building on (no change there), host is the machine you're building for 3078 (the target libraries are built for the target, so host is the target 3079 you specified), and target doesn't apply (because you're not building a 3080 compiler, you're building libraries). The configure/make process will 3081 adjust these variables as needed. It also sets `$with_cross_host' to 3082 the original `--host' value in case you need it. 3083 3084 The `libiberty' support library is built up to three times: once for 3085 the host, once for the target (even if they are the same), and once for 3086 the build if build and host are different. This allows it to be used 3087 by all programs which are generated in the course of the build process. 3088 3089 3090 File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree 3091 3092 6.2 Top Level Source Directory 3093 ============================== 3094 3095 The top level source directory in a GCC distribution contains several 3096 files and directories that are shared with other software distributions 3097 such as that of GNU Binutils. It also contains several subdirectories 3098 that contain parts of GCC and its runtime libraries: 3099 3100 `boehm-gc' 3101 The Boehm conservative garbage collector, used as part of the Java 3102 runtime library. 3103 3104 `config' 3105 Autoconf macros and Makefile fragments used throughout the tree. 3106 3107 `contrib' 3108 Contributed scripts that may be found useful in conjunction with 3109 GCC. One of these, `contrib/texi2pod.pl', is used to generate man 3110 pages from Texinfo manuals as part of the GCC build process. 3111 3112 `fixincludes' 3113 The support for fixing system headers to work with GCC. See 3114 `fixincludes/README' for more information. The headers fixed by 3115 this mechanism are installed in `LIBSUBDIR/include-fixed'. Along 3116 with those headers, `README-fixinc' is also installed, as 3117 `LIBSUBDIR/include-fixed/README'. 3118 3119 `gcc' 3120 The main sources of GCC itself (except for runtime libraries), 3121 including optimizers, support for different target architectures, 3122 language front ends, and testsuites. *Note The `gcc' 3123 Subdirectory: gcc Directory, for details. 3124 3125 `gnattools' 3126 Support tools for GNAT. 3127 3128 `include' 3129 Headers for the `libiberty' library. 3130 3131 `intl' 3132 GNU `libintl', from GNU `gettext', for systems which do not 3133 include it in `libc'. 3134 3135 `libada' 3136 The Ada runtime library. 3137 3138 `libcpp' 3139 The C preprocessor library. 3140 3141 `libdecnumber' 3142 The Decimal Float support library. 3143 3144 `libffi' 3145 The `libffi' library, used as part of the Java runtime library. 3146 3147 `libgcc' 3148 The GCC runtime library. 3149 3150 `libgfortran' 3151 The Fortran runtime library. 3152 3153 `libgo' 3154 The Go runtime library. The bulk of this library is mirrored from 3155 the master Go repository (http://code.google.com/p/go/). 3156 3157 `libgomp' 3158 The GNU OpenMP runtime library. 3159 3160 `libiberty' 3161 The `libiberty' library, used for portability and for some 3162 generally useful data structures and algorithms. *Note 3163 Introduction: (libiberty)Top, for more information about this 3164 library. 3165 3166 `libjava' 3167 The Java runtime library. 3168 3169 `libmudflap' 3170 The `libmudflap' library, used for instrumenting pointer and array 3171 dereferencing operations. 3172 3173 `libobjc' 3174 The Objective-C and Objective-C++ runtime library. 3175 3176 `libssp' 3177 The Stack protector runtime library. 3178 3179 `libstdc++-v3' 3180 The C++ runtime library. 3181 3182 `lto-plugin' 3183 Plugin used by `gold' if link-time optimizations are enabled. 3184 3185 `maintainer-scripts' 3186 Scripts used by the `gccadmin' account on `gcc.gnu.org'. 3187 3188 `zlib' 3189 The `zlib' compression library, used by the Java front end, as 3190 part of the Java runtime library, and for compressing and 3191 uncompressing GCC's intermediate language in LTO object files. 3192 3193 The build system in the top level directory, including how recursion 3194 into subdirectories works and how building runtime libraries for 3195 multilibs is handled, is documented in a separate manual, included with 3196 GNU Binutils. *Note GNU configure and build system: (configure)Top, 3197 for details. 3198 3199 3200 File: gccint.info, Node: gcc Directory, Prev: Top Level, Up: Source Tree 3201 3202 6.3 The `gcc' Subdirectory 3203 ========================== 3204 3205 The `gcc' directory contains many files that are part of the C sources 3206 of GCC, other files used as part of the configuration and build 3207 process, and subdirectories including documentation and a testsuite. 3208 The files that are sources of GCC are documented in a separate chapter. 3209 *Note Passes and Files of the Compiler: Passes. 3210 3211 * Menu: 3212 3213 * Subdirectories:: Subdirectories of `gcc'. 3214 * Configuration:: The configuration process, and the files it uses. 3215 * Build:: The build system in the `gcc' directory. 3216 * Makefile:: Targets in `gcc/Makefile'. 3217 * Library Files:: Library source files and headers under `gcc/'. 3218 * Headers:: Headers installed by GCC. 3219 * Documentation:: Building documentation in GCC. 3220 * Front End:: Anatomy of a language front end. 3221 * Back End:: Anatomy of a target back end. 3222 3223 3224 File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory 3225 3226 6.3.1 Subdirectories of `gcc' 3227 ----------------------------- 3228 3229 The `gcc' directory contains the following subdirectories: 3230 3231 `LANGUAGE' 3232 Subdirectories for various languages. Directories containing a 3233 file `config-lang.in' are language subdirectories. The contents of 3234 the subdirectories `cp' (for C++), `lto' (for LTO), `objc' (for 3235 Objective-C) and `objcp' (for Objective-C++) are documented in 3236 this manual (*note Passes and Files of the Compiler: Passes.); 3237 those for other languages are not. *Note Anatomy of a Language 3238 Front End: Front End, for details of the files in these 3239 directories. 3240 3241 `config' 3242 Configuration files for supported architectures and operating 3243 systems. *Note Anatomy of a Target Back End: Back End, for 3244 details of the files in this directory. 3245 3246 `doc' 3247 Texinfo documentation for GCC, together with automatically 3248 generated man pages and support for converting the installation 3249 manual to HTML. *Note Documentation::. 3250 3251 `ginclude' 3252 System headers installed by GCC, mainly those required by the C 3253 standard of freestanding implementations. *Note Headers Installed 3254 by GCC: Headers, for details of when these and other headers are 3255 installed. 3256 3257 `po' 3258 Message catalogs with translations of messages produced by GCC into 3259 various languages, `LANGUAGE.po'. This directory also contains 3260 `gcc.pot', the template for these message catalogues, `exgettext', 3261 a wrapper around `gettext' to extract the messages from the GCC 3262 sources and create `gcc.pot', which is run by `make gcc.pot', and 3263 `EXCLUDES', a list of files from which messages should not be 3264 extracted. 3265 3266 `testsuite' 3267 The GCC testsuites (except for those for runtime libraries). 3268 *Note Testsuites::. 3269 3270 3271 File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory 3272 3273 6.3.2 Configuration in the `gcc' Directory 3274 ------------------------------------------ 3275 3276 The `gcc' directory is configured with an Autoconf-generated script 3277 `configure'. The `configure' script is generated from `configure.ac' 3278 and `aclocal.m4'. From the files `configure.ac' and `acconfig.h', 3279 Autoheader generates the file `config.in'. The file `cstamp-h.in' is 3280 used as a timestamp. 3281 3282 * Menu: 3283 3284 * Config Fragments:: Scripts used by `configure'. 3285 * System Config:: The `config.build', `config.host', and 3286 `config.gcc' files. 3287 * Configuration Files:: Files created by running `configure'. 3288 3289 3290 File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration 3291 3292 6.3.2.1 Scripts Used by `configure' 3293 ................................... 3294 3295 `configure' uses some other scripts to help in its work: 3296 3297 * The standard GNU `config.sub' and `config.guess' files, kept in 3298 the top level directory, are used. 3299 3300 * The file `config.gcc' is used to handle configuration specific to 3301 the particular target machine. The file `config.build' is used to 3302 handle configuration specific to the particular build machine. 3303 The file `config.host' is used to handle configuration specific to 3304 the particular host machine. (In general, these should only be 3305 used for features that cannot reasonably be tested in Autoconf 3306 feature tests.) *Note The `config.build'; `config.host'; and 3307 `config.gcc' Files: System Config, for details of the contents of 3308 these files. 3309 3310 * Each language subdirectory has a file `LANGUAGE/config-lang.in' 3311 that is used for front-end-specific configuration. *Note The 3312 Front End `config-lang.in' File: Front End Config, for details of 3313 this file. 3314 3315 * A helper script `configure.frag' is used as part of creating the 3316 output of `configure'. 3317 3318 3319 File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration 3320 3321 6.3.2.2 The `config.build'; `config.host'; and `config.gcc' Files 3322 ................................................................. 3323 3324 The `config.build' file contains specific rules for particular systems 3325 which GCC is built on. This should be used as rarely as possible, as 3326 the behavior of the build system can always be detected by autoconf. 3327 3328 The `config.host' file contains specific rules for particular systems 3329 which GCC will run on. This is rarely needed. 3330 3331 The `config.gcc' file contains specific rules for particular systems 3332 which GCC will generate code for. This is usually needed. 3333 3334 Each file has a list of the shell variables it sets, with 3335 descriptions, at the top of the file. 3336 3337 FIXME: document the contents of these files, and what variables should 3338 be set to control build, host and target configuration. 3339 3340 3341 File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration 3342 3343 6.3.2.3 Files Created by `configure' 3344 .................................... 3345 3346 Here we spell out what files will be set up by `configure' in the `gcc' 3347 directory. Some other files are created as temporary files in the 3348 configuration process, and are not used in the subsequent build; these 3349 are not documented. 3350 3351 * `Makefile' is constructed from `Makefile.in', together with the 3352 host and target fragments (*note Makefile Fragments: Fragments.) 3353 `t-TARGET' and `x-HOST' from `config', if any, and language 3354 Makefile fragments `LANGUAGE/Make-lang.in'. 3355 3356 * `auto-host.h' contains information about the host machine 3357 determined by `configure'. If the host machine is different from 3358 the build machine, then `auto-build.h' is also created, containing 3359 such information about the build machine. 3360 3361 * `config.status' is a script that may be run to recreate the 3362 current configuration. 3363 3364 * `configargs.h' is a header containing details of the arguments 3365 passed to `configure' to configure GCC, and of the thread model 3366 used. 3367 3368 * `cstamp-h' is used as a timestamp. 3369 3370 * If a language `config-lang.in' file (*note The Front End 3371 `config-lang.in' File: Front End Config.) sets `outputs', then the 3372 files listed in `outputs' there are also generated. 3373 3374 The following configuration headers are created from the Makefile, 3375 using `mkconfig.sh', rather than directly by `configure'. `config.h', 3376 `bconfig.h' and `tconfig.h' all contain the `xm-MACHINE.h' header, if 3377 any, appropriate to the host, build and target machines respectively, 3378 the configuration headers for the target, and some definitions; for the 3379 host and build machines, these include the autoconfigured headers 3380 generated by `configure'. The other configuration headers are 3381 determined by `config.gcc'. They also contain the typedefs for `rtx', 3382 `rtvec' and `tree'. 3383 3384 * `config.h', for use in programs that run on the host machine. 3385 3386 * `bconfig.h', for use in programs that run on the build machine. 3387 3388 * `tconfig.h', for use in programs and libraries for the target 3389 machine. 3390 3391 * `tm_p.h', which includes the header `MACHINE-protos.h' that 3392 contains prototypes for functions in the target `.c' file. FIXME: 3393 why is such a separate header necessary? 3394 3395 3396 File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory 3397 3398 6.3.3 Build System in the `gcc' Directory 3399 ----------------------------------------- 3400 3401 FIXME: describe the build system, including what is built in what 3402 stages. Also list the various source files that are used in the build 3403 process but aren't source files of GCC itself and so aren't documented 3404 below (*note Passes::). 3405 3406 3407 File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory 3408 3409 6.3.4 Makefile Targets 3410 ---------------------- 3411 3412 These targets are available from the `gcc' directory: 3413 3414 `all' 3415 This is the default target. Depending on what your 3416 build/host/target configuration is, it coordinates all the things 3417 that need to be built. 3418 3419 `doc' 3420 Produce info-formatted documentation and man pages. Essentially it 3421 calls `make man' and `make info'. 3422 3423 `dvi' 3424 Produce DVI-formatted documentation. 3425 3426 `pdf' 3427 Produce PDF-formatted documentation. 3428 3429 `html' 3430 Produce HTML-formatted documentation. 3431 3432 `man' 3433 Generate man pages. 3434 3435 `info' 3436 Generate info-formatted pages. 3437 3438 `mostlyclean' 3439 Delete the files made while building the compiler. 3440 3441 `clean' 3442 That, and all the other files built by `make all'. 3443 3444 `distclean' 3445 That, and all the files created by `configure'. 3446 3447 `maintainer-clean' 3448 Distclean plus any file that can be generated from other files. 3449 Note that additional tools may be required beyond what is normally 3450 needed to build GCC. 3451 3452 `srcextra' 3453 Generates files in the source directory that are not 3454 version-controlled but should go into a release tarball. 3455 3456 `srcinfo' 3457 `srcman' 3458 Copies the info-formatted and manpage documentation into the source 3459 directory usually for the purpose of generating a release tarball. 3460 3461 `install' 3462 Installs GCC. 3463 3464 `uninstall' 3465 Deletes installed files, though this is not supported. 3466 3467 `check' 3468 Run the testsuite. This creates a `testsuite' subdirectory that 3469 has various `.sum' and `.log' files containing the results of the 3470 testing. You can run subsets with, for example, `make check-gcc'. 3471 You can specify specific tests by setting `RUNTESTFLAGS' to be the 3472 name of the `.exp' file, optionally followed by (for some tests) 3473 an equals and a file wildcard, like: 3474 3475 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*" 3476 3477 Note that running the testsuite may require additional tools be 3478 installed, such as Tcl or DejaGnu. 3479 3480 The toplevel tree from which you start GCC compilation is not the GCC 3481 directory, but rather a complex Makefile that coordinates the various 3482 steps of the build, including bootstrapping the compiler and using the 3483 new compiler to build target libraries. 3484 3485 When GCC is configured for a native configuration, the default action 3486 for `make' is to do a full three-stage bootstrap. This means that GCC 3487 is built three times--once with the native compiler, once with the 3488 native-built compiler it just built, and once with the compiler it 3489 built the second time. In theory, the last two should produce the same 3490 results, which `make compare' can check. Each stage is configured 3491 separately and compiled into a separate directory, to minimize problems 3492 due to ABI incompatibilities between the native compiler and GCC. 3493 3494 If you do a change, rebuilding will also start from the first stage 3495 and "bubble" up the change through the three stages. Each stage is 3496 taken from its build directory (if it had been built previously), 3497 rebuilt, and copied to its subdirectory. This will allow you to, for 3498 example, continue a bootstrap after fixing a bug which causes the 3499 stage2 build to crash. It does not provide as good coverage of the 3500 compiler as bootstrapping from scratch, but it ensures that the new 3501 code is syntactically correct (e.g., that you did not use GCC extensions 3502 by mistake), and avoids spurious bootstrap comparison failures(1). 3503 3504 Other targets available from the top level include: 3505 3506 `bootstrap-lean' 3507 Like `bootstrap', except that the various stages are removed once 3508 they're no longer needed. This saves disk space. 3509 3510 `bootstrap2' 3511 `bootstrap2-lean' 3512 Performs only the first two stages of bootstrap. Unlike a 3513 three-stage bootstrap, this does not perform a comparison to test 3514 that the compiler is running properly. Note that the disk space 3515 required by a "lean" bootstrap is approximately independent of the 3516 number of stages. 3517 3518 `stageN-bubble (N = 1...4, profile, feedback)' 3519 Rebuild all the stages up to N, with the appropriate flags, 3520 "bubbling" the changes as described above. 3521 3522 `all-stageN (N = 1...4, profile, feedback)' 3523 Assuming that stage N has already been built, rebuild it with the 3524 appropriate flags. This is rarely needed. 3525 3526 `cleanstrap' 3527 Remove everything (`make clean') and rebuilds (`make bootstrap'). 3528 3529 `compare' 3530 Compares the results of stages 2 and 3. This ensures that the 3531 compiler is running properly, since it should produce the same 3532 object files regardless of how it itself was compiled. 3533 3534 `profiledbootstrap' 3535 Builds a compiler with profiling feedback information. In this 3536 case, the second and third stages are named `profile' and 3537 `feedback', respectively. For more information, see *note 3538 Building with profile feedback: (gccinstall)Building. 3539 3540 `restrap' 3541 Restart a bootstrap, so that everything that was not built with 3542 the system compiler is rebuilt. 3543 3544 `stageN-start (N = 1...4, profile, feedback)' 3545 For each package that is bootstrapped, rename directories so that, 3546 for example, `gcc' points to the stageN GCC, compiled with the 3547 stageN-1 GCC(2). 3548 3549 You will invoke this target if you need to test or debug the 3550 stageN GCC. If you only need to execute GCC (but you need not run 3551 `make' either to rebuild it or to run test suites), you should be 3552 able to work directly in the `stageN-gcc' directory. This makes 3553 it easier to debug multiple stages in parallel. 3554 3555 `stage' 3556 For each package that is bootstrapped, relocate its build directory 3557 to indicate its stage. For example, if the `gcc' directory points 3558 to the stage2 GCC, after invoking this target it will be renamed 3559 to `stage2-gcc'. 3560 3561 3562 If you wish to use non-default GCC flags when compiling the stage2 and 3563 stage3 compilers, set `BOOT_CFLAGS' on the command line when doing 3564 `make'. 3565 3566 Usually, the first stage only builds the languages that the compiler 3567 is written in: typically, C and maybe Ada. If you are debugging a 3568 miscompilation of a different stage2 front-end (for example, of the 3569 Fortran front-end), you may want to have front-ends for other languages 3570 in the first stage as well. To do so, set `STAGE1_LANGUAGES' on the 3571 command line when doing `make'. 3572 3573 For example, in the aforementioned scenario of debugging a Fortran 3574 front-end miscompilation caused by the stage1 compiler, you may need a 3575 command like 3576 3577 make stage2-bubble STAGE1_LANGUAGES=c,fortran 3578 3579 Alternatively, you can use per-language targets to build and test 3580 languages that are not enabled by default in stage1. For example, 3581 `make f951' will build a Fortran compiler even in the stage1 build 3582 directory. 3583 3584 ---------- Footnotes ---------- 3585 3586 (1) Except if the compiler was buggy and miscompiled some of the files 3587 that were not modified. In this case, it's best to use `make restrap'. 3588 3589 (2) Customarily, the system compiler is also termed the `stage0' GCC. 3590 3591 3592 File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory 3593 3594 6.3.5 Library Source Files and Headers under the `gcc' Directory 3595 ---------------------------------------------------------------- 3596 3597 FIXME: list here, with explanation, all the C source files and headers 3598 under the `gcc' directory that aren't built into the GCC executable but 3599 rather are part of runtime libraries and object files, such as 3600 `crtstuff.c' and `unwind-dw2.c'. *Note Headers Installed by GCC: 3601 Headers, for more information about the `ginclude' directory. 3602 3603 3604 File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory 3605 3606 6.3.6 Headers Installed by GCC 3607 ------------------------------ 3608 3609 In general, GCC expects the system C library to provide most of the 3610 headers to be used with it. However, GCC will fix those headers if 3611 necessary to make them work with GCC, and will install some headers 3612 required of freestanding implementations. These headers are installed 3613 in `LIBSUBDIR/include'. Headers for non-C runtime libraries are also 3614 installed by GCC; these are not documented here. (FIXME: document them 3615 somewhere.) 3616 3617 Several of the headers GCC installs are in the `ginclude' directory. 3618 These headers, `iso646.h', `stdarg.h', `stdbool.h', and `stddef.h', are 3619 installed in `LIBSUBDIR/include', unless the target Makefile fragment 3620 (*note Target Fragment::) overrides this by setting `USER_H'. 3621 3622 In addition to these headers and those generated by fixing system 3623 headers to work with GCC, some other headers may also be installed in 3624 `LIBSUBDIR/include'. `config.gcc' may set `extra_headers'; this 3625 specifies additional headers under `config' to be installed on some 3626 systems. 3627 3628 GCC installs its own version of `<float.h>', from `ginclude/float.h'. 3629 This is done to cope with command-line options that change the 3630 representation of floating point numbers. 3631 3632 GCC also installs its own version of `<limits.h>'; this is generated 3633 from `glimits.h', together with `limitx.h' and `limity.h' if the system 3634 also has its own version of `<limits.h>'. (GCC provides its own header 3635 because it is required of ISO C freestanding implementations, but needs 3636 to include the system header from its own header as well because other 3637 standards such as POSIX specify additional values to be defined in 3638 `<limits.h>'.) The system's `<limits.h>' header is used via 3639 `LIBSUBDIR/include/syslimits.h', which is copied from `gsyslimits.h' if 3640 it does not need fixing to work with GCC; if it needs fixing, 3641 `syslimits.h' is the fixed copy. 3642 3643 GCC can also install `<tgmath.h>'. It will do this when `config.gcc' 3644 sets `use_gcc_tgmath' to `yes'. 3645 3646 3647 File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory 3648 3649 6.3.7 Building Documentation 3650 ---------------------------- 3651 3652 The main GCC documentation is in the form of manuals in Texinfo format. 3653 These are installed in Info format; DVI versions may be generated by 3654 `make dvi', PDF versions by `make pdf', and HTML versions by `make 3655 html'. In addition, some man pages are generated from the Texinfo 3656 manuals, there are some other text files with miscellaneous 3657 documentation, and runtime libraries have their own documentation 3658 outside the `gcc' directory. FIXME: document the documentation for 3659 runtime libraries somewhere. 3660 3661 * Menu: 3662 3663 * Texinfo Manuals:: GCC manuals in Texinfo format. 3664 * Man Page Generation:: Generating man pages from Texinfo manuals. 3665 * Miscellaneous Docs:: Miscellaneous text files with documentation. 3666 3667 3668 File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation 3669 3670 6.3.7.1 Texinfo Manuals 3671 ....................... 3672 3673 The manuals for GCC as a whole, and the C and C++ front ends, are in 3674 files `doc/*.texi'. Other front ends have their own manuals in files 3675 `LANGUAGE/*.texi'. Common files `doc/include/*.texi' are provided 3676 which may be included in multiple manuals; the following files are in 3677 `doc/include': 3678 3679 `fdl.texi' 3680 The GNU Free Documentation License. 3681 3682 `funding.texi' 3683 The section "Funding Free Software". 3684 3685 `gcc-common.texi' 3686 Common definitions for manuals. 3687 3688 `gpl.texi' 3689 `gpl_v3.texi' 3690 The GNU General Public License. 3691 3692 `texinfo.tex' 3693 A copy of `texinfo.tex' known to work with the GCC manuals. 3694 3695 DVI-formatted manuals are generated by `make dvi', which uses 3696 `texi2dvi' (via the Makefile macro `$(TEXI2DVI)'). PDF-formatted 3697 manuals are generated by `make pdf', which uses `texi2pdf' (via the 3698 Makefile macro `$(TEXI2PDF)'). HTML formatted manuals are generated by 3699 `make html'. Info manuals are generated by `make info' (which is run 3700 as part of a bootstrap); this generates the manuals in the source 3701 directory, using `makeinfo' via the Makefile macro `$(MAKEINFO)', and 3702 they are included in release distributions. 3703 3704 Manuals are also provided on the GCC web site, in both HTML and 3705 PostScript forms. This is done via the script 3706 `maintainer-scripts/update_web_docs_svn'. Each manual to be provided 3707 online must be listed in the definition of `MANUALS' in that file; a 3708 file `NAME.texi' must only appear once in the source tree, and the 3709 output manual must have the same name as the source file. (However, 3710 other Texinfo files, included in manuals but not themselves the root 3711 files of manuals, may have names that appear more than once in the 3712 source tree.) The manual file `NAME.texi' should only include other 3713 files in its own directory or in `doc/include'. HTML manuals will be 3714 generated by `makeinfo --html', PostScript manuals by `texi2dvi' and 3715 `dvips', and PDF manuals by `texi2pdf'. All Texinfo files that are 3716 parts of manuals must be version-controlled, even if they are generated 3717 files, for the generation of online manuals to work. 3718 3719 The installation manual, `doc/install.texi', is also provided on the 3720 GCC web site. The HTML version is generated by the script 3721 `doc/install.texi2html'. 3722 3723 3724 File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation 3725 3726 6.3.7.2 Man Page Generation 3727 ........................... 3728 3729 Because of user demand, in addition to full Texinfo manuals, man pages 3730 are provided which contain extracts from those manuals. These man 3731 pages are generated from the Texinfo manuals using 3732 `contrib/texi2pod.pl' and `pod2man'. (The man page for `g++', 3733 `cp/g++.1', just contains a `.so' reference to `gcc.1', but all the 3734 other man pages are generated from Texinfo manuals.) 3735 3736 Because many systems may not have the necessary tools installed to 3737 generate the man pages, they are only generated if the `configure' 3738 script detects that recent enough tools are installed, and the 3739 Makefiles allow generating man pages to fail without aborting the 3740 build. Man pages are also included in release distributions. They are 3741 generated in the source directory. 3742 3743 Magic comments in Texinfo files starting `@c man' control what parts 3744 of a Texinfo file go into a man page. Only a subset of Texinfo is 3745 supported by `texi2pod.pl', and it may be necessary to add support for 3746 more Texinfo features to this script when generating new man pages. To 3747 improve the man page output, some special Texinfo macros are provided 3748 in `doc/include/gcc-common.texi' which `texi2pod.pl' understands: 3749 3750 `@gcctabopt' 3751 Use in the form `@table @gcctabopt' for tables of options, where 3752 for printed output the effect of `@code' is better than that of 3753 `@option' but for man page output a different effect is wanted. 3754 3755 `@gccoptlist' 3756 Use for summary lists of options in manuals. 3757 3758 `@gol' 3759 Use at the end of each line inside `@gccoptlist'. This is 3760 necessary to avoid problems with differences in how the 3761 `@gccoptlist' macro is handled by different Texinfo formatters. 3762 3763 FIXME: describe the `texi2pod.pl' input language and magic comments in 3764 more detail. 3765 3766 3767 File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation 3768 3769 6.3.7.3 Miscellaneous Documentation 3770 ................................... 3771 3772 In addition to the formal documentation that is installed by GCC, there 3773 are several other text files in the `gcc' subdirectory with 3774 miscellaneous documentation: 3775 3776 `ABOUT-GCC-NLS' 3777 Notes on GCC's Native Language Support. FIXME: this should be 3778 part of this manual rather than a separate file. 3779 3780 `ABOUT-NLS' 3781 Notes on the Free Translation Project. 3782 3783 `COPYING' 3784 `COPYING3' 3785 The GNU General Public License, Versions 2 and 3. 3786 3787 `COPYING.LIB' 3788 `COPYING3.LIB' 3789 The GNU Lesser General Public License, Versions 2.1 and 3. 3790 3791 `*ChangeLog*' 3792 `*/ChangeLog*' 3793 Change log files for various parts of GCC. 3794 3795 `LANGUAGES' 3796 Details of a few changes to the GCC front-end interface. FIXME: 3797 the information in this file should be part of general 3798 documentation of the front-end interface in this manual. 3799 3800 `ONEWS' 3801 Information about new features in old versions of GCC. (For recent 3802 versions, the information is on the GCC web site.) 3803 3804 `README.Portability' 3805 Information about portability issues when writing code in GCC. 3806 FIXME: why isn't this part of this manual or of the GCC Coding 3807 Conventions? 3808 3809 FIXME: document such files in subdirectories, at least `config', `cp', 3810 `objc', `testsuite'. 3811 3812 3813 File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory 3814 3815 6.3.8 Anatomy of a Language Front End 3816 ------------------------------------- 3817 3818 A front end for a language in GCC has the following parts: 3819 3820 * A directory `LANGUAGE' under `gcc' containing source files for 3821 that front end. *Note The Front End `LANGUAGE' Directory: Front 3822 End Directory, for details. 3823 3824 * A mention of the language in the list of supported languages in 3825 `gcc/doc/install.texi'. 3826 3827 * A mention of the name under which the language's runtime library is 3828 recognized by `--enable-shared=PACKAGE' in the documentation of 3829 that option in `gcc/doc/install.texi'. 3830 3831 * A mention of any special prerequisites for building the front end 3832 in the documentation of prerequisites in `gcc/doc/install.texi'. 3833 3834 * Details of contributors to that front end in 3835 `gcc/doc/contrib.texi'. If the details are in that front end's 3836 own manual then there should be a link to that manual's list in 3837 `contrib.texi'. 3838 3839 * Information about support for that language in 3840 `gcc/doc/frontends.texi'. 3841 3842 * Information about standards for that language, and the front end's 3843 support for them, in `gcc/doc/standards.texi'. This may be a link 3844 to such information in the front end's own manual. 3845 3846 * Details of source file suffixes for that language and `-x LANG' 3847 options supported, in `gcc/doc/invoke.texi'. 3848 3849 * Entries in `default_compilers' in `gcc.c' for source file suffixes 3850 for that language. 3851 3852 * Preferably testsuites, which may be under `gcc/testsuite' or 3853 runtime library directories. FIXME: document somewhere how to 3854 write testsuite harnesses. 3855 3856 * Probably a runtime library for the language, outside the `gcc' 3857 directory. FIXME: document this further. 3858 3859 * Details of the directories of any runtime libraries in 3860 `gcc/doc/sourcebuild.texi'. 3861 3862 * Check targets in `Makefile.def' for the top-level `Makefile' to 3863 check just the compiler or the compiler and runtime library for the 3864 language. 3865 3866 If the front end is added to the official GCC source repository, the 3867 following are also necessary: 3868 3869 * At least one Bugzilla component for bugs in that front end and 3870 runtime libraries. This category needs to be added to the 3871 Bugzilla database. 3872 3873 * Normally, one or more maintainers of that front end listed in 3874 `MAINTAINERS'. 3875 3876 * Mentions on the GCC web site in `index.html' and `frontends.html', 3877 with any relevant links on `readings.html'. (Front ends that are 3878 not an official part of GCC may also be listed on 3879 `frontends.html', with relevant links.) 3880 3881 * A news item on `index.html', and possibly an announcement on the 3882 <gcc-announce (a] gcc.gnu.org> mailing list. 3883 3884 * The front end's manuals should be mentioned in 3885 `maintainer-scripts/update_web_docs_svn' (*note Texinfo Manuals::) 3886 and the online manuals should be linked to from 3887 `onlinedocs/index.html'. 3888 3889 * Any old releases or CVS repositories of the front end, before its 3890 inclusion in GCC, should be made available on the GCC FTP site 3891 `ftp://gcc.gnu.org/pub/gcc/old-releases/'. 3892 3893 * The release and snapshot script `maintainer-scripts/gcc_release' 3894 should be updated to generate appropriate tarballs for this front 3895 end. 3896 3897 * If this front end includes its own version files that include the 3898 current date, `maintainer-scripts/update_version' should be 3899 updated accordingly. 3900 3901 * Menu: 3902 3903 * Front End Directory:: The front end `LANGUAGE' directory. 3904 * Front End Config:: The front end `config-lang.in' file. 3905 * Front End Makefile:: The front end `Make-lang.in' file. 3906 3907 3908 File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End 3909 3910 6.3.8.1 The Front End `LANGUAGE' Directory 3911 .......................................... 3912 3913 A front end `LANGUAGE' directory contains the source files of that 3914 front end (but not of any runtime libraries, which should be outside 3915 the `gcc' directory). This includes documentation, and possibly some 3916 subsidiary programs built alongside the front end. Certain files are 3917 special and other parts of the compiler depend on their names: 3918 3919 `config-lang.in' 3920 This file is required in all language subdirectories. *Note The 3921 Front End `config-lang.in' File: Front End Config, for details of 3922 its contents 3923 3924 `Make-lang.in' 3925 This file is required in all language subdirectories. *Note The 3926 Front End `Make-lang.in' File: Front End Makefile, for details of 3927 its contents. 3928 3929 `lang.opt' 3930 This file registers the set of switches that the front end accepts 3931 on the command line, and their `--help' text. *Note Options::. 3932 3933 `lang-specs.h' 3934 This file provides entries for `default_compilers' in `gcc.c' 3935 which override the default of giving an error that a compiler for 3936 that language is not installed. 3937 3938 `LANGUAGE-tree.def' 3939 This file, which need not exist, defines any language-specific tree 3940 codes. 3941 3942 3943 File: gccint.info, Node: Front End Config, Next: Front End Makefile, Prev: Front End Directory, Up: Front End 3944 3945 6.3.8.2 The Front End `config-lang.in' File 3946 ........................................... 3947 3948 Each language subdirectory contains a `config-lang.in' file. In 3949 addition the main directory contains `c-config-lang.in', which contains 3950 limited information for the C language. This file is a shell script 3951 that may define some variables describing the language: 3952 3953 `language' 3954 This definition must be present, and gives the name of the language 3955 for some purposes such as arguments to `--enable-languages'. 3956 3957 `lang_requires' 3958 If defined, this variable lists (space-separated) language front 3959 ends other than C that this front end requires to be enabled (with 3960 the names given being their `language' settings). For example, the 3961 Java front end depends on the C++ front end, so sets 3962 `lang_requires=c++'. 3963 3964 `subdir_requires' 3965 If defined, this variable lists (space-separated) front end 3966 directories other than C that this front end requires to be 3967 present. For example, the Objective-C++ front end uses source 3968 files from the C++ and Objective-C front ends, so sets 3969 `subdir_requires="cp objc"'. 3970 3971 `target_libs' 3972 If defined, this variable lists (space-separated) targets in the 3973 top level `Makefile' to build the runtime libraries for this 3974 language, such as `target-libobjc'. 3975 3976 `lang_dirs' 3977 If defined, this variable lists (space-separated) top level 3978 directories (parallel to `gcc'), apart from the runtime libraries, 3979 that should not be configured if this front end is not built. 3980 3981 `build_by_default' 3982 If defined to `no', this language front end is not built unless 3983 enabled in a `--enable-languages' argument. Otherwise, front ends 3984 are built by default, subject to any special logic in 3985 `configure.ac' (as is present to disable the Ada front end if the 3986 Ada compiler is not already installed). 3987 3988 `boot_language' 3989 If defined to `yes', this front end is built in stage1 of the 3990 bootstrap. This is only relevant to front ends written in their 3991 own languages. 3992 3993 `compilers' 3994 If defined, a space-separated list of compiler executables that 3995 will be run by the driver. The names here will each end with 3996 `\$(exeext)'. 3997 3998 `outputs' 3999 If defined, a space-separated list of files that should be 4000 generated by `configure' substituting values in them. This 4001 mechanism can be used to create a file `LANGUAGE/Makefile' from 4002 `LANGUAGE/Makefile.in', but this is deprecated, building 4003 everything from the single `gcc/Makefile' is preferred. 4004 4005 `gtfiles' 4006 If defined, a space-separated list of files that should be scanned 4007 by `gengtype.c' to generate the garbage collection tables and 4008 routines for this language. This excludes the files that are 4009 common to all front ends. *Note Type Information::. 4010 4011 4012 4013 File: gccint.info, Node: Front End Makefile, Prev: Front End Config, Up: Front End 4014 4015 6.3.8.3 The Front End `Make-lang.in' File 4016 ......................................... 4017 4018 Each language subdirectory contains a `Make-lang.in' file. It contains 4019 targets `LANG.HOOK' (where `LANG' is the setting of `language' in 4020 `config-lang.in') for the following values of `HOOK', and any other 4021 Makefile rules required to build those targets (which may if necessary 4022 use other Makefiles specified in `outputs' in `config-lang.in', 4023 although this is deprecated). It also adds any testsuite targets that 4024 can use the standard rule in `gcc/Makefile.in' to the variable 4025 `lang_checks'. 4026 4027 `all.cross' 4028 `start.encap' 4029 `rest.encap' 4030 FIXME: exactly what goes in each of these targets? 4031 4032 `tags' 4033 Build an `etags' `TAGS' file in the language subdirectory in the 4034 source tree. 4035 4036 `info' 4037 Build info documentation for the front end, in the build directory. 4038 This target is only called by `make bootstrap' if a suitable 4039 version of `makeinfo' is available, so does not need to check for 4040 this, and should fail if an error occurs. 4041 4042 `dvi' 4043 Build DVI documentation for the front end, in the build directory. 4044 This should be done using `$(TEXI2DVI)', with appropriate `-I' 4045 arguments pointing to directories of included files. 4046 4047 `pdf' 4048 Build PDF documentation for the front end, in the build directory. 4049 This should be done using `$(TEXI2PDF)', with appropriate `-I' 4050 arguments pointing to directories of included files. 4051 4052 `html' 4053 Build HTML documentation for the front end, in the build directory. 4054 4055 `man' 4056 Build generated man pages for the front end from Texinfo manuals 4057 (*note Man Page Generation::), in the build directory. This target 4058 is only called if the necessary tools are available, but should 4059 ignore errors so as not to stop the build if errors occur; man 4060 pages are optional and the tools involved may be installed in a 4061 broken way. 4062 4063 `install-common' 4064 Install everything that is part of the front end, apart from the 4065 compiler executables listed in `compilers' in `config-lang.in'. 4066 4067 `install-info' 4068 Install info documentation for the front end, if it is present in 4069 the source directory. This target should have dependencies on 4070 info files that should be installed. 4071 4072 `install-man' 4073 Install man pages for the front end. This target should ignore 4074 errors. 4075 4076 `install-plugin' 4077 Install headers needed for plugins. 4078 4079 `srcextra' 4080 Copies its dependencies into the source directory. This generally 4081 should be used for generated files such as Bison output files 4082 which are not version-controlled, but should be included in any 4083 release tarballs. This target will be executed during a bootstrap 4084 if `--enable-generated-files-in-srcdir' was specified as a 4085 `configure' option. 4086 4087 `srcinfo' 4088 `srcman' 4089 Copies its dependencies into the source directory. These targets 4090 will be executed during a bootstrap if 4091 `--enable-generated-files-in-srcdir' was specified as a 4092 `configure' option. 4093 4094 `uninstall' 4095 Uninstall files installed by installing the compiler. This is 4096 currently documented not to be supported, so the hook need not do 4097 anything. 4098 4099 `mostlyclean' 4100 `clean' 4101 `distclean' 4102 `maintainer-clean' 4103 The language parts of the standard GNU `*clean' targets. *Note 4104 Standard Targets for Users: (standards)Standard Targets, for 4105 details of the standard targets. For GCC, `maintainer-clean' 4106 should delete all generated files in the source directory that are 4107 not version-controlled, but should not delete anything that is. 4108 4109 `Make-lang.in' must also define a variable `LANG_OBJS' to a list of 4110 host object files that are used by that language. 4111 4112 4113 File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory 4114 4115 6.3.9 Anatomy of a Target Back End 4116 ---------------------------------- 4117 4118 A back end for a target architecture in GCC has the following parts: 4119 4120 * A directory `MACHINE' under `gcc/config', containing a machine 4121 description `MACHINE.md' file (*note Machine Descriptions: Machine 4122 Desc.), header files `MACHINE.h' and `MACHINE-protos.h' and a 4123 source file `MACHINE.c' (*note Target Description Macros and 4124 Functions: Target Macros.), possibly a target Makefile fragment 4125 `t-MACHINE' (*note The Target Makefile Fragment: Target 4126 Fragment.), and maybe some other files. The names of these files 4127 may be changed from the defaults given by explicit specifications 4128 in `config.gcc'. 4129 4130 * If necessary, a file `MACHINE-modes.def' in the `MACHINE' 4131 directory, containing additional machine modes to represent 4132 condition codes. *Note Condition Code::, for further details. 4133 4134 * An optional `MACHINE.opt' file in the `MACHINE' directory, 4135 containing a list of target-specific options. You can also add 4136 other option files using the `extra_options' variable in 4137 `config.gcc'. *Note Options::. 4138 4139 * Entries in `config.gcc' (*note The `config.gcc' File: System 4140 Config.) for the systems with this target architecture. 4141 4142 * Documentation in `gcc/doc/invoke.texi' for any command-line 4143 options supported by this target (*note Run-time Target 4144 Specification: Run-time Target.). This means both entries in the 4145 summary table of options and details of the individual options. 4146 4147 * Documentation in `gcc/doc/extend.texi' for any target-specific 4148 attributes supported (*note Defining target-specific uses of 4149 `__attribute__': Target Attributes.), including where the same 4150 attribute is already supported on some targets, which are 4151 enumerated in the manual. 4152 4153 * Documentation in `gcc/doc/extend.texi' for any target-specific 4154 pragmas supported. 4155 4156 * Documentation in `gcc/doc/extend.texi' of any target-specific 4157 built-in functions supported. 4158 4159 * Documentation in `gcc/doc/extend.texi' of any target-specific 4160 format checking styles supported. 4161 4162 * Documentation in `gcc/doc/md.texi' of any target-specific 4163 constraint letters (*note Constraints for Particular Machines: 4164 Machine Constraints.). 4165 4166 * A note in `gcc/doc/contrib.texi' under the person or people who 4167 contributed the target support. 4168 4169 * Entries in `gcc/doc/install.texi' for all target triplets 4170 supported with this target architecture, giving details of any 4171 special notes about installation for this target, or saying that 4172 there are no special notes if there are none. 4173 4174 * Possibly other support outside the `gcc' directory for runtime 4175 libraries. FIXME: reference docs for this. The `libstdc++' 4176 porting manual needs to be installed as info for this to work, or 4177 to be a chapter of this manual. 4178 4179 If the back end is added to the official GCC source repository, the 4180 following are also necessary: 4181 4182 * An entry for the target architecture in `readings.html' on the GCC 4183 web site, with any relevant links. 4184 4185 * Details of the properties of the back end and target architecture 4186 in `backends.html' on the GCC web site. 4187 4188 * A news item about the contribution of support for that target 4189 architecture, in `index.html' on the GCC web site. 4190 4191 * Normally, one or more maintainers of that target listed in 4192 `MAINTAINERS'. Some existing architectures may be unmaintained, 4193 but it would be unusual to add support for a target that does not 4194 have a maintainer when support is added. 4195 4196 4197 File: gccint.info, Node: Testsuites, Next: Options, Prev: Source Tree, Up: Top 4198 4199 7 Testsuites 4200 ************ 4201 4202 GCC contains several testsuites to help maintain compiler quality. 4203 Most of the runtime libraries and language front ends in GCC have 4204 testsuites. Currently only the C language testsuites are documented 4205 here; FIXME: document the others. 4206 4207 * Menu: 4208 4209 * Test Idioms:: Idioms used in testsuite code. 4210 * Test Directives:: Directives used within DejaGnu tests. 4211 * Ada Tests:: The Ada language testsuites. 4212 * C Tests:: The C language testsuites. 4213 * libgcj Tests:: The Java library testsuites. 4214 * LTO Testing:: Support for testing link-time optimizations. 4215 * gcov Testing:: Support for testing gcov. 4216 * profopt Testing:: Support for testing profile-directed optimizations. 4217 * compat Testing:: Support for testing binary compatibility. 4218 * Torture Tests:: Support for torture testing using multiple options. 4219 4220 4221 File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites 4222 4223 7.1 Idioms Used in Testsuite Code 4224 ================================= 4225 4226 In general, C testcases have a trailing `-N.c', starting with `-1.c', 4227 in case other testcases with similar names are added later. If the 4228 test is a test of some well-defined feature, it should have a name 4229 referring to that feature such as `FEATURE-1.c'. If it does not test a 4230 well-defined feature but just happens to exercise a bug somewhere in 4231 the compiler, and a bug report has been filed for this bug in the GCC 4232 bug database, `prBUG-NUMBER-1.c' is the appropriate form of name. 4233 Otherwise (for miscellaneous bugs not filed in the GCC bug database), 4234 and previously more generally, test cases are named after the date on 4235 which they were added. This allows people to tell at a glance whether 4236 a test failure is because of a recently found bug that has not yet been 4237 fixed, or whether it may be a regression, but does not give any other 4238 information about the bug or where discussion of it may be found. Some 4239 other language testsuites follow similar conventions. 4240 4241 In the `gcc.dg' testsuite, it is often necessary to test that an error 4242 is indeed a hard error and not just a warning--for example, where it is 4243 a constraint violation in the C standard, which must become an error 4244 with `-pedantic-errors'. The following idiom, where the first line 4245 shown is line LINE of the file and the line that generates the error, 4246 is used for this: 4247 4248 /* { dg-bogus "warning" "warning in place of error" } */ 4249 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */ 4250 4251 It may be necessary to check that an expression is an integer constant 4252 expression and has a certain value. To check that `E' has value `V', 4253 an idiom similar to the following is used: 4254 4255 char x[((E) == (V) ? 1 : -1)]; 4256 4257 In `gcc.dg' tests, `__typeof__' is sometimes used to make assertions 4258 about the types of expressions. See, for example, 4259 `gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact 4260 rules for the types of conditional expressions in the C standard; see, 4261 for example, `gcc.dg/c99-intconst-1.c'. 4262 4263 It is useful to be able to test that optimizations are being made 4264 properly. This cannot be done in all cases, but it can be done where 4265 the optimization will lead to code being optimized away (for example, 4266 where flow analysis or alias analysis should show that certain code 4267 cannot be called) or to functions not being called because they have 4268 been expanded as built-in functions. Such tests go in 4269 `gcc.c-torture/execute'. Where code should be optimized away, a call 4270 to a nonexistent function such as `link_failure ()' may be inserted; a 4271 definition 4272 4273 #ifndef __OPTIMIZE__ 4274 void 4275 link_failure (void) 4276 { 4277 abort (); 4278 } 4279 #endif 4280 4281 will also be needed so that linking still succeeds when the test is run 4282 without optimization. When all calls to a built-in function should 4283 have been optimized and no calls to the non-built-in version of the 4284 function should remain, that function may be defined as `static' to 4285 call `abort ()' (although redeclaring a function as static may not work 4286 on all targets). 4287 4288 All testcases must be portable. Target-specific testcases must have 4289 appropriate code to avoid causing failures on unsupported systems; 4290 unfortunately, the mechanisms for this differ by directory. 4291 4292 FIXME: discuss non-C testsuites here. 4293 4294 4295 File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites 4296 4297 7.2 Directives used within DejaGnu tests 4298 ======================================== 4299 4300 * Menu: 4301 4302 * Directives:: Syntax and descriptions of test directives. 4303 * Selectors:: Selecting targets to which a test applies. 4304 * Effective-Target Keywords:: Keywords describing target attributes. 4305 * Add Options:: Features for `dg-add-options' 4306 * Require Support:: Variants of `dg-require-SUPPORT' 4307 * Final Actions:: Commands for use in `dg-final' 4308 4309 4310 File: gccint.info, Node: Directives, Next: Selectors, Up: Test Directives 4311 4312 7.2.1 Syntax and Descriptions of test directives 4313 ------------------------------------------------ 4314 4315 Test directives appear within comments in a test source file and begin 4316 with `dg-'. Some of these are defined within DejaGnu and others are 4317 local to the GCC testsuite. 4318 4319 The order in which test directives appear in a test can be important: 4320 directives local to GCC sometimes override information used by the 4321 DejaGnu directives, which know nothing about the GCC directives, so the 4322 DejaGnu directives must precede GCC directives. 4323 4324 Several test directives include selectors (*note Selectors::) which 4325 are usually preceded by the keyword `target' or `xfail'. 4326 4327 7.2.1.1 Specify how to build the test 4328 ..................................... 4329 4330 `{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }' 4331 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 4332 is executed. It is one of: 4333 4334 `preprocess' 4335 Compile with `-E' to run only the preprocessor. 4336 4337 `compile' 4338 Compile with `-S' to produce an assembly code file. 4339 4340 `assemble' 4341 Compile with `-c' to produce a relocatable object file. 4342 4343 `link' 4344 Compile, assemble, and link to produce an executable file. 4345 4346 `run' 4347 Produce and run an executable file, which is expected to 4348 return an exit code of 0. 4349 4350 The default is `compile'. That can be overridden for a set of 4351 tests by redefining `dg-do-what-default' within the `.exp' file 4352 for those tests. 4353 4354 If the directive includes the optional `{ target SELECTOR }' then 4355 the test is skipped unless the target system matches the SELECTOR. 4356 4357 If DO-WHAT-KEYWORD is `run' and the directive includes the 4358 optional `{ xfail SELECTOR }' and the selector is met then the 4359 test is expected to fail. The `xfail' clause is ignored for other 4360 values of DO-WHAT-KEYWORD; those tests can use directive 4361 `dg-xfail-if'. 4362 4363 7.2.1.2 Specify additional compiler options 4364 ........................................... 4365 4366 `{ dg-options OPTIONS [{ target SELECTOR }] }' 4367 This DejaGnu directive provides a list of compiler options, to be 4368 used if the target system matches SELECTOR, that replace the 4369 default options used for this set of tests. 4370 4371 `{ dg-add-options FEATURE ... }' 4372 Add any compiler options that are needed to access certain 4373 features. This directive does nothing on targets that enable the 4374 features by default, or that don't provide them at all. It must 4375 come after all `dg-options' directives. For supported values of 4376 FEATURE see *note Add Options::. 4377 4378 7.2.1.3 Modify the test timeout value 4379 ..................................... 4380 4381 The normal timeout limit, in seconds, is found by searching the 4382 following in order: 4383 4384 * the value defined by an earlier `dg-timeout' directive in the test 4385 4386 * variable TOOL_TIMEOUT defined by the set of tests 4387 4388 * GCC,TIMEOUT set in the target board 4389 4390 * 300 4391 4392 `{ dg-timeout N [{target SELECTOR }] }' 4393 Set the time limit for the compilation and for the execution of 4394 the test to the specified number of seconds. 4395 4396 `{ dg-timeout-factor X [{ target SELECTOR }] }' 4397 Multiply the normal time limit for compilation and execution of 4398 the test by the specified floating-point factor. 4399 4400 7.2.1.4 Skip a test for some targets 4401 .................................... 4402 4403 `{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4404 Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each 4405 element is a string of zero or more GCC options. Skip the test if 4406 all of the following conditions are met: 4407 * the test system is included in SELECTOR 4408 4409 * for at least one of the option strings in INCLUDE-OPTS, every 4410 option from that string is in the set of options with which 4411 the test would be compiled; use `"*"' for an INCLUDE-OPTS list 4412 that matches any options; that is the default if INCLUDE-OPTS 4413 is not specified 4414 4415 * for each of the option strings in EXCLUDE-OPTS, at least one 4416 option from that string is not in the set of options with 4417 which the test would be compiled; use `""' for an empty 4418 EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not 4419 specified 4420 4421 For example, to skip a test if option `-Os' is present: 4422 4423 /* { dg-skip-if "" { *-*-* } { "-Os" } { "" } } */ 4424 4425 To skip a test if both options `-O2' and `-g' are present: 4426 4427 /* { dg-skip-if "" { *-*-* } { "-O2 -g" } { "" } } */ 4428 4429 To skip a test if either `-O2' or `-O3' is present: 4430 4431 /* { dg-skip-if "" { *-*-* } { "-O2" "-O3" } { "" } } */ 4432 4433 To skip a test unless option `-Os' is present: 4434 4435 /* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */ 4436 4437 To skip a test if either `-O2' or `-O3' is used with `-g' but not 4438 if `-fpic' is also present: 4439 4440 /* { dg-skip-if "" { *-*-* } { "-O2 -g" "-O3 -g" } { "-fpic" } } */ 4441 4442 `{ dg-require-effective-target KEYWORD [{ SELECTOR }] }' 4443 Skip the test if the test target, including current multilib flags, 4444 is not covered by the effective-target keyword. If the directive 4445 includes the optional `{ SELECTOR }' then the effective-target 4446 test is only performed if the target system matches the SELECTOR. 4447 This directive must appear after any `dg-do' directive in the test 4448 and before any `dg-additional-sources' directive. *Note 4449 Effective-Target Keywords::. 4450 4451 `{ dg-require-SUPPORT args }' 4452 Skip the test if the target does not provide the required support. 4453 These directives must appear after any `dg-do' directive in the 4454 test and before any `dg-additional-sources' directive. They 4455 require at least one argument, which can be an empty string if the 4456 specific procedure does not examine the argument. *Note Require 4457 Support::, for a complete list of these directives. 4458 4459 7.2.1.5 Expect a test to fail for some targets 4460 .............................................. 4461 4462 `{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4463 Expect the test to fail if the conditions (which are the same as 4464 for `dg-skip-if') are met. This does not affect the execute step. 4465 4466 `{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4467 Expect the execute step of a test to fail if the conditions (which 4468 are the same as for `dg-skip-if') are met. 4469 4470 7.2.1.6 Expect the test executable to fail 4471 .......................................... 4472 4473 `{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }' 4474 Expect the test executable to return a nonzero exit status if the 4475 conditions (which are the same as for `dg-skip-if') are met. 4476 4477 7.2.1.7 Verify compiler messages 4478 ................................ 4479 4480 `{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4481 This DejaGnu directive appears on a source line that is expected 4482 to get an error message, or else specifies the source line 4483 associated with the message. If there is no message for that line 4484 or if the text of that message is not matched by REGEXP then the 4485 check fails and COMMENT is included in the `FAIL' message. The 4486 check does not look for the string `error' unless it is part of 4487 REGEXP. 4488 4489 `{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4490 This DejaGnu directive appears on a source line that is expected 4491 to get a warning message, or else specifies the source line 4492 associated with the message. If there is no message for that line 4493 or if the text of that message is not matched by REGEXP then the 4494 check fails and COMMENT is included in the `FAIL' message. The 4495 check does not look for the string `warning' unless it is part of 4496 REGEXP. 4497 4498 `{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4499 The line is expected to get a message other than an error or 4500 warning. If there is no message for that line or if the text of 4501 that message is not matched by REGEXP then the check fails and 4502 COMMENT is included in the `FAIL' message. 4503 4504 `{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4505 This DejaGnu directive appears on a source line that should not 4506 get a message matching REGEXP, or else specifies the source line 4507 associated with the bogus message. It is usually used with `xfail' 4508 to indicate that the message is a known problem for a particular 4509 set of targets. 4510 4511 `{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }' 4512 This DejaGnu directive indicates that the test is expected to fail 4513 due to compiler messages that are not handled by `dg-error', 4514 `dg-warning' or `dg-bogus'. For this directive `xfail' has the 4515 same effect as `target'. 4516 4517 `{ dg-prune-output REGEXP }' 4518 Prune messages matching REGEXP from the test output. 4519 4520 7.2.1.8 Verify output of the test executable 4521 ............................................ 4522 4523 `{ dg-output REGEXP [{ target/xfail SELECTOR }] }' 4524 This DejaGnu directive compares REGEXP to the combined output that 4525 the test executable writes to `stdout' and `stderr'. 4526 4527 7.2.1.9 Specify additional files for a test 4528 ........................................... 4529 4530 `{ dg-additional-files "FILELIST" }' 4531 Specify additional files, other than source files, that must be 4532 copied to the system where the compiler runs. 4533 4534 `{ dg-additional-sources "FILELIST" }' 4535 Specify additional source files to appear in the compile line 4536 following the main test file. 4537 4538 7.2.1.10 Add checks at the end of a test 4539 ........................................ 4540 4541 `{ dg-final { LOCAL-DIRECTIVE } }' 4542 This DejaGnu directive is placed within a comment anywhere in the 4543 source file and is processed after the test has been compiled and 4544 run. Multiple `dg-final' commands are processed in the order in 4545 which they appear in the source file. *Note Final Actions::, for 4546 a list of directives that can be used within `dg-final'. 4547 4548 4549 File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives 4550 4551 7.2.2 Selecting targets to which a test applies 4552 ----------------------------------------------- 4553 4554 Several test directives include SELECTORs to limit the targets for 4555 which a test is run or to declare that a test is expected to fail on 4556 particular targets. 4557 4558 A selector is: 4559 * one or more target triplets, possibly including wildcard characters 4560 4561 * a single effective-target keyword (*note Effective-Target 4562 Keywords::) 4563 4564 * a logical expression 4565 4566 Depending on the context, the selector specifies whether a test is 4567 skipped and reported as unsupported or is expected to fail. Use 4568 `*-*-*' to match any target. 4569 4570 A selector expression appears within curly braces and uses a single 4571 logical operator: one of `!', `&&', or `||'. An operand is another 4572 selector expression, an effective-target keyword, a single target 4573 triplet, or a list of target triplets within quotes or curly braces. 4574 For example: 4575 4576 { target { ! "hppa*-*-* ia64*-*-*" } } 4577 { target { powerpc*-*-* && lp64 } } 4578 { xfail { lp64 || vect_no_align } } 4579 4580 4581 File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives 4582 4583 7.2.3 Keywords describing target attributes 4584 ------------------------------------------- 4585 4586 Effective-target keywords identify sets of targets that support 4587 particular functionality. They are used to limit tests to be run only 4588 for particular targets, or to specify that particular sets of targets 4589 are expected to fail some tests. 4590 4591 Effective-target keywords are defined in `lib/target-supports.exp' in 4592 the GCC testsuite, with the exception of those that are documented as 4593 being local to a particular test directory. 4594 4595 The `effective target' takes into account all of the compiler options 4596 with which the test will be compiled, including the multilib options. 4597 By convention, keywords ending in `_nocache' can also include options 4598 specified for the particular test in an earlier `dg-options' or 4599 `dg-add-options' directive. 4600 4601 7.2.3.1 Data type sizes 4602 ....................... 4603 4604 `ilp32' 4605 Target has 32-bit `int', `long', and pointers. 4606 4607 `lp64' 4608 Target has 32-bit `int', 64-bit `long' and pointers. 4609 4610 `llp64' 4611 Target has 32-bit `int' and `long', 64-bit `long long' and 4612 pointers. 4613 4614 `double64' 4615 Target has 64-bit `double'. 4616 4617 `double64plus' 4618 Target has `double' that is 64 bits or longer. 4619 4620 `int32plus' 4621 Target has `int' that is at 32 bits or longer. 4622 4623 `int16' 4624 Target has `int' that is 16 bits or shorter. 4625 4626 `large_double' 4627 Target supports `double' that is longer than `float'. 4628 4629 `large_long_double' 4630 Target supports `long double' that is longer than `double'. 4631 4632 `ptr32plus' 4633 Target has pointers that are 32 bits or longer. 4634 4635 `size32plus' 4636 Target supports array and structure sizes that are 32 bits or 4637 longer. 4638 4639 `4byte_wchar_t' 4640 Target has `wchar_t' that is at least 4 bytes. 4641 4642 7.2.3.2 Fortran-specific attributes 4643 ................................... 4644 4645 `fortran_integer_16' 4646 Target supports Fortran `integer' that is 16 bytes or longer. 4647 4648 `fortran_large_int' 4649 Target supports Fortran `integer' kinds larger than `integer(8)'. 4650 4651 `fortran_large_real' 4652 Target supports Fortran `real' kinds larger than `real(8)'. 4653 4654 7.2.3.3 Vector-specific attributes 4655 .................................. 4656 4657 `vect_condition' 4658 Target supports vector conditional operations. 4659 4660 `vect_double' 4661 Target supports hardware vectors of `double'. 4662 4663 `vect_float' 4664 Target supports hardware vectors of `float'. 4665 4666 `vect_int' 4667 Target supports hardware vectors of `int'. 4668 4669 `vect_long' 4670 Target supports hardware vectors of `long'. 4671 4672 `vect_long_long' 4673 Target supports hardware vectors of `long long'. 4674 4675 `vect_aligned_arrays' 4676 Target aligns arrays to vector alignment boundary. 4677 4678 `vect_hw_misalign' 4679 Target supports a vector misalign access. 4680 4681 `vect_no_align' 4682 Target does not support a vector alignment mechanism. 4683 4684 `vect_no_int_max' 4685 Target does not support a vector max instruction on `int'. 4686 4687 `vect_no_int_add' 4688 Target does not support a vector add instruction on `int'. 4689 4690 `vect_no_bitwise' 4691 Target does not support vector bitwise instructions. 4692 4693 `vect_char_mult' 4694 Target supports `vector char' multiplication. 4695 4696 `vect_short_mult' 4697 Target supports `vector short' multiplication. 4698 4699 `vect_int_mult' 4700 Target supports `vector int' multiplication. 4701 4702 `vect_extract_even_odd' 4703 Target supports vector even/odd element extraction. 4704 4705 `vect_extract_even_odd_wide' 4706 Target supports vector even/odd element extraction of vectors with 4707 elements `SImode' or larger. 4708 4709 `vect_interleave' 4710 Target supports vector interleaving. 4711 4712 `vect_strided' 4713 Target supports vector interleaving and extract even/odd. 4714 4715 `vect_strided_wide' 4716 Target supports vector interleaving and extract even/odd for wide 4717 element types. 4718 4719 `vect_perm' 4720 Target supports vector permutation. 4721 4722 `vect_shift' 4723 Target supports a hardware vector shift operation. 4724 4725 `vect_widen_sum_hi_to_si' 4726 Target supports a vector widening summation of `short' operands 4727 into `int' results, or can promote (unpack) from `short' to `int'. 4728 4729 `vect_widen_sum_qi_to_hi' 4730 Target supports a vector widening summation of `char' operands 4731 into `short' results, or can promote (unpack) from `char' to 4732 `short'. 4733 4734 `vect_widen_sum_qi_to_si' 4735 Target supports a vector widening summation of `char' operands 4736 into `int' results. 4737 4738 `vect_widen_mult_qi_to_hi' 4739 Target supports a vector widening multiplication of `char' operands 4740 into `short' results, or can promote (unpack) from `char' to 4741 `short' and perform non-widening multiplication of `short'. 4742 4743 `vect_widen_mult_hi_to_si' 4744 Target supports a vector widening multiplication of `short' 4745 operands into `int' results, or can promote (unpack) from `short' 4746 to `int' and perform non-widening multiplication of `int'. 4747 4748 `vect_sdot_qi' 4749 Target supports a vector dot-product of `signed char'. 4750 4751 `vect_udot_qi' 4752 Target supports a vector dot-product of `unsigned char'. 4753 4754 `vect_sdot_hi' 4755 Target supports a vector dot-product of `signed short'. 4756 4757 `vect_udot_hi' 4758 Target supports a vector dot-product of `unsigned short'. 4759 4760 `vect_pack_trunc' 4761 Target supports a vector demotion (packing) of `short' to `char' 4762 and from `int' to `short' using modulo arithmetic. 4763 4764 `vect_unpack' 4765 Target supports a vector promotion (unpacking) of `char' to `short' 4766 and from `char' to `int'. 4767 4768 `vect_intfloat_cvt' 4769 Target supports conversion from `signed int' to `float'. 4770 4771 `vect_uintfloat_cvt' 4772 Target supports conversion from `unsigned int' to `float'. 4773 4774 `vect_floatint_cvt' 4775 Target supports conversion from `float' to `signed int'. 4776 4777 `vect_floatuint_cvt' 4778 Target supports conversion from `float' to `unsigned int'. 4779 4780 7.2.3.4 Thread Local Storage attributes 4781 ....................................... 4782 4783 `tls' 4784 Target supports thread-local storage. 4785 4786 `tls_native' 4787 Target supports native (rather than emulated) thread-local storage. 4788 4789 `tls_runtime' 4790 Test system supports executing TLS executables. 4791 4792 7.2.3.5 Decimal floating point attributes 4793 ......................................... 4794 4795 `dfp' 4796 Targets supports compiling decimal floating point extension to C. 4797 4798 `dfp_nocache' 4799 Including the options used to compile this particular test, the 4800 target supports compiling decimal floating point extension to C. 4801 4802 `dfprt' 4803 Test system can execute decimal floating point tests. 4804 4805 `dfprt_nocache' 4806 Including the options used to compile this particular test, the 4807 test system can execute decimal floating point tests. 4808 4809 `hard_dfp' 4810 Target generates decimal floating point instructions with current 4811 options. 4812 4813 7.2.3.6 ARM-specific attributes 4814 ............................... 4815 4816 `arm32' 4817 ARM target generates 32-bit code. 4818 4819 `arm_eabi' 4820 ARM target adheres to the ABI for the ARM Architecture. 4821 4822 `arm_hard_vfp_ok' 4823 ARM target supports `-mfpu=vfp -mfloat-abi=hard'. Some multilibs 4824 may be incompatible with these options. 4825 4826 `arm_iwmmxt_ok' 4827 ARM target supports `-mcpu=iwmmxt'. Some multilibs may be 4828 incompatible with this option. 4829 4830 `arm_neon' 4831 ARM target supports generating NEON instructions. 4832 4833 `arm_neon_hw' 4834 Test system supports executing NEON instructions. 4835 4836 `arm_neon_ok' 4837 ARM Target supports `-mfpu=neon -mfloat-abi=softfp' or compatible 4838 options. Some multilibs may be incompatible with these options. 4839 4840 `arm_neon_fp16_ok' 4841 ARM Target supports `-mfpu=neon-fp16 -mfloat-abi=softfp' or 4842 compatible options. Some multilibs may be incompatible with these 4843 options. 4844 4845 `arm_thumb1_ok' 4846 ARM target generates Thumb-1 code for `-mthumb'. 4847 4848 `arm_thumb2_ok' 4849 ARM target generates Thumb-2 code for `-mthumb'. 4850 4851 `arm_vfp_ok' 4852 ARM target supports `-mfpu=vfp -mfloat-abi=softfp'. Some 4853 multilibs may be incompatible with these options. 4854 4855 7.2.3.7 MIPS-specific attributes 4856 ................................ 4857 4858 `mips64' 4859 MIPS target supports 64-bit instructions. 4860 4861 `nomips16' 4862 MIPS target does not produce MIPS16 code. 4863 4864 `mips16_attribute' 4865 MIPS target can generate MIPS16 code. 4866 4867 `mips_loongson' 4868 MIPS target is a Loongson-2E or -2F target using an ABI that 4869 supports the Loongson vector modes. 4870 4871 `mips_newabi_large_long_double' 4872 MIPS target supports `long double' larger than `double' when using 4873 the new ABI. 4874 4875 `mpaired_single' 4876 MIPS target supports `-mpaired-single'. 4877 4878 7.2.3.8 PowerPC-specific attributes 4879 ................................... 4880 4881 `powerpc64' 4882 Test system supports executing 64-bit instructions. 4883 4884 `powerpc_altivec' 4885 PowerPC target supports AltiVec. 4886 4887 `powerpc_altivec_ok' 4888 PowerPC target supports `-maltivec'. 4889 4890 `powerpc_fprs' 4891 PowerPC target supports floating-point registers. 4892 4893 `powerpc_hard_double' 4894 PowerPC target supports hardware double-precision floating-point. 4895 4896 `powerpc_ppu_ok' 4897 PowerPC target supports `-mcpu=cell'. 4898 4899 `powerpc_spe' 4900 PowerPC target supports PowerPC SPE. 4901 4902 `powerpc_spe_nocache' 4903 Including the options used to compile this particular test, the 4904 PowerPC target supports PowerPC SPE. 4905 4906 `powerpc_spu' 4907 PowerPC target supports PowerPC SPU. 4908 4909 `spu_auto_overlay' 4910 SPU target has toolchain that supports automatic overlay 4911 generation. 4912 4913 `powerpc_vsx_ok' 4914 PowerPC target supports `-mvsx'. 4915 4916 `powerpc_405_nocache' 4917 Including the options used to compile this particular test, the 4918 PowerPC target supports PowerPC 405. 4919 4920 `vmx_hw' 4921 PowerPC target supports executing AltiVec instructions. 4922 4923 7.2.3.9 Other hardware attributes 4924 ................................. 4925 4926 `avx' 4927 Target supports compiling `avx' instructions. 4928 4929 `avx_runtime' 4930 Target supports the execution of `avx' instructions. 4931 4932 `cell_hw' 4933 Test system can execute AltiVec and Cell PPU instructions. 4934 4935 `coldfire_fpu' 4936 Target uses a ColdFire FPU. 4937 4938 `hard_float' 4939 Target supports FPU instructions. 4940 4941 `sse' 4942 Target supports compiling `sse' instructions. 4943 4944 `sse_runtime' 4945 Target supports the execution of `sse' instructions. 4946 4947 `sse2' 4948 Target supports compiling `sse2' instructions. 4949 4950 `sse2_runtime' 4951 Target supports the execution of `sse2' instructions. 4952 4953 `sync_char_short' 4954 Target supports atomic operations on `char' and `short'. 4955 4956 `sync_int_long' 4957 Target supports atomic operations on `int' and `long'. 4958 4959 `ultrasparc_hw' 4960 Test environment appears to run executables on a simulator that 4961 accepts only `EM_SPARC' executables and chokes on `EM_SPARC32PLUS' 4962 or `EM_SPARCV9' executables. 4963 4964 `vect_cmdline_needed' 4965 Target requires a command line argument to enable a SIMD 4966 instruction set. 4967 4968 7.2.3.10 Environment attributes 4969 ............................... 4970 4971 `c' 4972 The language for the compiler under test is C. 4973 4974 `c++' 4975 The language for the compiler under test is C++. 4976 4977 `c99_runtime' 4978 Target provides a full C99 runtime. 4979 4980 `correct_iso_cpp_string_wchar_protos' 4981 Target `string.h' and `wchar.h' headers provide C++ required 4982 overloads for `strchr' etc. functions. 4983 4984 `dummy_wcsftime' 4985 Target uses a dummy `wcsftime' function that always returns zero. 4986 4987 `fd_truncate' 4988 Target can truncate a file from a file descriptor, as used by 4989 `libgfortran/io/unix.c:fd_truncate'; i.e. `ftruncate' or `chsize'. 4990 4991 `freestanding' 4992 Target is `freestanding' as defined in section 4 of the C99 4993 standard. Effectively, it is a target which supports no extra 4994 headers or libraries other than what is considered essential. 4995 4996 `init_priority' 4997 Target supports constructors with initialization priority 4998 arguments. 4999 5000 `inttypes_types' 5001 Target has the basic signed and unsigned types in `inttypes.h'. 5002 This is for tests that GCC's notions of these types agree with 5003 those in the header, as some systems have only `inttypes.h'. 5004 5005 `lax_strtofp' 5006 Target might have errors of a few ULP in string to floating-point 5007 conversion functions and overflow is not always detected correctly 5008 by those functions. 5009 5010 `newlib' 5011 Target supports Newlib. 5012 5013 `pow10' 5014 Target provides `pow10' function. 5015 5016 `pthread' 5017 Target can compile using `pthread.h' with no errors or warnings. 5018 5019 `pthread_h' 5020 Target has `pthread.h'. 5021 5022 `run_expensive_tests' 5023 Expensive testcases (usually those that consume excessive amounts 5024 of CPU time) should be run on this target. This can be enabled by 5025 setting the `GCC_TEST_RUN_EXPENSIVE' environment variable to a 5026 non-empty string. 5027 5028 `simulator' 5029 Test system runs executables on a simulator (i.e. slowly) rather 5030 than hardware (i.e. fast). 5031 5032 `stdint_types' 5033 Target has the basic signed and unsigned C types in `stdint.h'. 5034 This will be obsolete when GCC ensures a working `stdint.h' for 5035 all targets. 5036 5037 `trampolines' 5038 Target supports trampolines. 5039 5040 `uclibc' 5041 Target supports uClibc. 5042 5043 `unwrapped' 5044 Target does not use a status wrapper. 5045 5046 `vxworks_kernel' 5047 Target is a VxWorks kernel. 5048 5049 `vxworks_rtp' 5050 Target is a VxWorks RTP. 5051 5052 `wchar' 5053 Target supports wide characters. 5054 5055 7.2.3.11 Other attributes 5056 ......................... 5057 5058 `automatic_stack_alignment' 5059 Target supports automatic stack alignment. 5060 5061 `cxa_atexit' 5062 Target uses `__cxa_atexit'. 5063 5064 `default_packed' 5065 Target has packed layout of structure members by default. 5066 5067 `fgraphite' 5068 Target supports Graphite optimizations. 5069 5070 `fixed_point' 5071 Target supports fixed-point extension to C. 5072 5073 `fopenmp' 5074 Target supports OpenMP via `-fopenmp'. 5075 5076 `fpic' 5077 Target supports `-fpic' and `-fPIC'. 5078 5079 `freorder' 5080 Target supports `-freorder-blocks-and-partition'. 5081 5082 `fstack_protector' 5083 Target supports `-fstack-protector'. 5084 5085 `gas' 5086 Target uses GNU `as'. 5087 5088 `gc_sections' 5089 Target supports `--gc-sections'. 5090 5091 `keeps_null_pointer_checks' 5092 Target keeps null pointer checks, either due to the use of 5093 `-fno-delete-null-pointer-checks' or hardwired into the target. 5094 5095 `lto' 5096 Compiler has been configured to support link-time optimization 5097 (LTO). 5098 5099 `named_sections' 5100 Target supports named sections. 5101 5102 `natural_alignment_32' 5103 Target uses natural alignment (aligned to type size) for types of 5104 32 bits or less. 5105 5106 `target_natural_alignment_64' 5107 Target uses natural alignment (aligned to type size) for types of 5108 64 bits or less. 5109 5110 `nonpic' 5111 Target does not generate PIC by default. 5112 5113 `pcc_bitfield_type_matters' 5114 Target defines `PCC_BITFIELD_TYPE_MATTERS'. 5115 5116 `pe_aligned_commons' 5117 Target supports `-mpe-aligned-commons'. 5118 5119 `section_anchors' 5120 Target supports section anchors. 5121 5122 `short_enums' 5123 Target defaults to short enums. 5124 5125 `static' 5126 Target supports `-static'. 5127 5128 `static_libgfortran' 5129 Target supports statically linking `libgfortran'. 5130 5131 `string_merging' 5132 Target supports merging string constants at link time. 5133 5134 `ucn' 5135 Target supports compiling and assembling UCN. 5136 5137 `ucn_nocache' 5138 Including the options used to compile this particular test, the 5139 target supports compiling and assembling UCN. 5140 5141 `unaligned_stack' 5142 Target does not guarantee that its `STACK_BOUNDARY' is greater than 5143 or equal to the required vector alignment. 5144 5145 `vector_alignment_reachable' 5146 Vector alignment is reachable for types of 32 bits or less. 5147 5148 `vector_alignment_reachable_for_64bit' 5149 Vector alignment is reachable for types of 64 bits or less. 5150 5151 `wchar_t_char16_t_compatible' 5152 Target supports `wchar_t' that is compatible with `char16_t'. 5153 5154 `wchar_t_char32_t_compatible' 5155 Target supports `wchar_t' that is compatible with `char32_t'. 5156 5157 7.2.3.12 Local to tests in `gcc.target/i386' 5158 ............................................ 5159 5160 `3dnow' 5161 Target supports compiling `3dnow' instructions. 5162 5163 `aes' 5164 Target supports compiling `aes' instructions. 5165 5166 `fma4' 5167 Target supports compiling `fma4' instructions. 5168 5169 `ms_hook_prologue' 5170 Target supports attribute `ms_hook_prologue'. 5171 5172 `pclmul' 5173 Target supports compiling `pclmul' instructions. 5174 5175 `sse3' 5176 Target supports compiling `sse3' instructions. 5177 5178 `sse4' 5179 Target supports compiling `sse4' instructions. 5180 5181 `sse4a' 5182 Target supports compiling `sse4a' instructions. 5183 5184 `ssse3' 5185 Target supports compiling `ssse3' instructions. 5186 5187 `vaes' 5188 Target supports compiling `vaes' instructions. 5189 5190 `vpclmul' 5191 Target supports compiling `vpclmul' instructions. 5192 5193 `xop' 5194 Target supports compiling `xop' instructions. 5195 5196 7.2.3.13 Local to tests in `gcc.target/spu/ea' 5197 .............................................. 5198 5199 `ealib' 5200 Target `__ea' library functions are available. 5201 5202 7.2.3.14 Local to tests in `gcc.test-framework' 5203 ............................................... 5204 5205 `no' 5206 Always returns 0. 5207 5208 `yes' 5209 Always returns 1. 5210 5211 5212 File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5213 5214 7.2.4 Features for `dg-add-options' 5215 ----------------------------------- 5216 5217 The supported values of FEATURE for directive `dg-add-options' are: 5218 5219 `arm_neon' 5220 NEON support. Only ARM targets support this feature, and only then 5221 in certain modes; see the *note arm_neon_ok effective target 5222 keyword: arm_neon_ok. 5223 5224 `arm_neon_fp16' 5225 NEON and half-precision floating point support. Only ARM targets 5226 support this feature, and only then in certain modes; see the 5227 *note arm_neon_fp16_ok effective target keyword: arm_neon_ok. 5228 5229 `bind_pic_locally' 5230 Add the target-specific flags needed to enable functions to bind 5231 locally when using pic/PIC passes in the testsuite. 5232 5233 `c99_runtime' 5234 Add the target-specific flags needed to access the C99 runtime. 5235 5236 `ieee' 5237 Add the target-specific flags needed to enable full IEEE 5238 compliance mode. 5239 5240 `mips16_attribute' 5241 `mips16' function attributes. Only MIPS targets support this 5242 feature, and only then in certain modes. 5243 5244 `tls' 5245 Add the target-specific flags needed to use thread-local storage. 5246 5247 5248 File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 5249 5250 7.2.5 Variants of `dg-require-SUPPORT' 5251 -------------------------------------- 5252 5253 A few of the `dg-require' directives take arguments. 5254 5255 `dg-require-iconv CODESET' 5256 Skip the test if the target does not support iconv. CODESET is 5257 the codeset to convert to. 5258 5259 `dg-require-profiling PROFOPT' 5260 Skip the test if the target does not support profiling with option 5261 PROFOPT. 5262 5263 `dg-require-visibility VIS' 5264 Skip the test if the target does not support the `visibility' 5265 attribute. If VIS is `""', support for `visibility("hidden")' is 5266 checked, for `visibility("VIS")' otherwise. 5267 5268 The original `dg-require' directives were defined before there was 5269 support for effective-target keywords. The directives that do not take 5270 arguments could be replaced with effective-target keywords. 5271 5272 `dg-require-alias ""' 5273 Skip the test if the target does not support the `alias' attribute. 5274 5275 `dg-require-ascii-locale ""' 5276 Skip the test if the host does not support an ASCII locale. 5277 5278 `dg-require-compat-dfp ""' 5279 Skip this test unless both compilers in a `compat' testsuite 5280 support decimal floating point. 5281 5282 `dg-require-cxa-atexit ""' 5283 Skip the test if the target does not support `__cxa_atexit'. This 5284 is equivalent to `dg-require-effective-target cxa_atexit'. 5285 5286 `dg-require-dll ""' 5287 Skip the test if the target does not support DLL attributes. 5288 5289 `dg-require-fork ""' 5290 Skip the test if the target does not support `fork'. 5291 5292 `dg-require-gc-sections ""' 5293 Skip the test if the target's linker does not support the 5294 `--gc-sections' flags. This is equivalent to 5295 `dg-require-effective-target gc-sections'. 5296 5297 `dg-require-host-local ""' 5298 Skip the test if the host is remote, rather than the same as the 5299 build system. Some tests are incompatible with DejaGnu's handling 5300 of remote hosts, which involves copying the source file to the 5301 host and compiling it with a relative path and "`-o a.out'". 5302 5303 `dg-require-mkfifo ""' 5304 Skip the test if the target does not support `mkfifo'. 5305 5306 `dg-require-named-sections ""' 5307 Skip the test is the target does not support named sections. This 5308 is equivalent to `dg-require-effective-target named_sections'. 5309 5310 `dg-require-weak ""' 5311 Skip the test if the target does not support weak symbols. 5312 5313 `dg-require-weak-override ""' 5314 Skip the test if the target does not support overriding weak 5315 symbols. 5316 5317 5318 File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 5319 5320 7.2.6 Commands for use in `dg-final' 5321 ------------------------------------ 5322 5323 The GCC testsuite defines the following directives to be used within 5324 `dg-final'. 5325 5326 7.2.6.1 Scan a particular file 5327 .............................. 5328 5329 `scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 5330 Passes if REGEXP matches text in FILENAME. 5331 5332 `scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 5333 Passes if REGEXP does not match text in FILENAME. 5334 5335 `scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 5336 Passes if REGEXP matches in Fortran module MODULE. 5337 5338 7.2.6.2 Scan the assembly output 5339 ................................ 5340 5341 `scan-assembler REGEX [{ target/xfail SELECTOR }]' 5342 Passes if REGEX matches text in the test's assembler output. 5343 5344 `scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 5345 Passes if REGEX does not match text in the test's assembler output. 5346 5347 `scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 5348 Passes if REGEX is matched exactly NUM times in the test's 5349 assembler output. 5350 5351 `scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 5352 Passes if REGEX matches text in the test's demangled assembler 5353 output. 5354 5355 `scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 5356 Passes if REGEX does not match text in the test's demangled 5357 assembler output. 5358 5359 `scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 5360 Passes if SYMBOL is defined as a hidden symbol in the test's 5361 assembly output. 5362 5363 `scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 5364 Passes if SYMBOL is not defined as a hidden symbol in the test's 5365 assembly output. 5366 5367 7.2.6.3 Scan optimization dump files 5368 .................................... 5369 5370 These commands are available for KIND of `tree', `rtl', and `ipa'. 5371 5372 `scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 5373 Passes if REGEX matches text in the dump file with suffix SUFFIX. 5374 5375 `scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5376 Passes if REGEX does not match text in the dump file with suffix 5377 SUFFIX. 5378 5379 `scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 5380 Passes if REGEX is found exactly NUM times in the dump file with 5381 suffix SUFFIX. 5382 5383 `scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 5384 Passes if REGEX matches demangled text in the dump file with 5385 suffix SUFFIX. 5386 5387 `scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5388 Passes if REGEX does not match demangled text in the dump file with 5389 suffix SUFFIX. 5390 5391 7.2.6.4 Verify that an output files exists or not 5392 ................................................. 5393 5394 `output-exists [{ target/xfail SELECTOR }]' 5395 Passes if compiler output file exists. 5396 5397 `output-exists-not [{ target/xfail SELECTOR }]' 5398 Passes if compiler output file does not exist. 5399 5400 7.2.6.5 Check for LTO tests 5401 ........................... 5402 5403 `scan-symbol REGEXP [{ target/xfail SELECTOR }]' 5404 Passes if the pattern is present in the final executable. 5405 5406 7.2.6.6 Checks for `gcov' tests 5407 ............................... 5408 5409 `run-gcov SOURCEFILE' 5410 Check line counts in `gcov' tests. 5411 5412 `run-gcov [branches] [calls] { OPTS SOURCEFILE }' 5413 Check branch and/or call counts, in addition to line counts, in 5414 `gcov' tests. 5415 5416 7.2.6.7 Clean up generated test files 5417 ..................................... 5418 5419 `cleanup-coverage-files' 5420 Removes coverage data files generated for this test. 5421 5422 `cleanup-ipa-dump SUFFIX' 5423 Removes IPA dump files generated for this test. 5424 5425 `cleanup-modules' 5426 Removes Fortran module files generated for this test. 5427 5428 `cleanup-profile-file' 5429 Removes profiling files generated for this test. 5430 5431 `cleanup-repo-files' 5432 Removes files generated for this test for `-frepo'. 5433 5434 `cleanup-rtl-dump SUFFIX' 5435 Removes RTL dump files generated for this test. 5436 5437 `cleanup-saved-temps' 5438 Removes files for the current test which were kept for 5439 `-save-temps'. 5440 5441 `cleanup-tree-dump SUFFIX' 5442 Removes tree dump files matching SUFFIX which were generated for 5443 this test. 5444 5445 5446 File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 5447 5448 7.3 Ada Language Testsuites 5449 =========================== 5450 5451 The Ada testsuite includes executable tests from the ACATS 2.5 5452 testsuite, publicly available at 5453 `http://www.adaic.org/compilers/acats/2.5'. 5454 5455 These tests are integrated in the GCC testsuite in the `ada/acats' 5456 directory, and enabled automatically when running `make check', assuming 5457 the Ada language has been enabled when configuring GCC. 5458 5459 You can also run the Ada testsuite independently, using `make 5460 check-ada', or run a subset of the tests by specifying which chapter to 5461 run, e.g.: 5462 5463 $ make check-ada CHAPTERS="c3 c9" 5464 5465 The tests are organized by directory, each directory corresponding to 5466 a chapter of the Ada Reference Manual. So for example, `c9' corresponds 5467 to chapter 9, which deals with tasking features of the language. 5468 5469 There is also an extra chapter called `gcc' containing a template for 5470 creating new executable tests, although this is deprecated in favor of 5471 the `gnat.dg' testsuite. 5472 5473 The tests are run using two `sh' scripts: `run_acats' and 5474 `run_all.sh'. To run the tests using a simulator or a cross target, 5475 see the small customization section at the top of `run_all.sh'. 5476 5477 These tests are run using the build tree: they can be run without doing 5478 a `make install'. 5479 5480 5481 File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites 5482 5483 7.4 C Language Testsuites 5484 ========================= 5485 5486 GCC contains the following C language testsuites, in the 5487 `gcc/testsuite' directory: 5488 5489 `gcc.dg' 5490 This contains tests of particular features of the C compiler, 5491 using the more modern `dg' harness. Correctness tests for various 5492 compiler features should go here if possible. 5493 5494 Magic comments determine whether the file is preprocessed, 5495 compiled, linked or run. In these tests, error and warning 5496 message texts are compared against expected texts or regular 5497 expressions given in comments. These tests are run with the 5498 options `-ansi -pedantic' unless other options are given in the 5499 test. Except as noted below they are not run with multiple 5500 optimization options. 5501 5502 `gcc.dg/compat' 5503 This subdirectory contains tests for binary compatibility using 5504 `lib/compat.exp', which in turn uses the language-independent 5505 support (*note Support for testing binary compatibility: compat 5506 Testing.). 5507 5508 `gcc.dg/cpp' 5509 This subdirectory contains tests of the preprocessor. 5510 5511 `gcc.dg/debug' 5512 This subdirectory contains tests for debug formats. Tests in this 5513 subdirectory are run for each debug format that the compiler 5514 supports. 5515 5516 `gcc.dg/format' 5517 This subdirectory contains tests of the `-Wformat' format 5518 checking. Tests in this directory are run with and without 5519 `-DWIDE'. 5520 5521 `gcc.dg/noncompile' 5522 This subdirectory contains tests of code that should not compile 5523 and does not need any special compilation options. They are run 5524 with multiple optimization options, since sometimes invalid code 5525 crashes the compiler with optimization. 5526 5527 `gcc.dg/special' 5528 FIXME: describe this. 5529 5530 `gcc.c-torture' 5531 This contains particular code fragments which have historically 5532 broken easily. These tests are run with multiple optimization 5533 options, so tests for features which only break at some 5534 optimization levels belong here. This also contains tests to 5535 check that certain optimizations occur. It might be worthwhile to 5536 separate the correctness tests cleanly from the code quality 5537 tests, but it hasn't been done yet. 5538 5539 `gcc.c-torture/compat' 5540 FIXME: describe this. 5541 5542 This directory should probably not be used for new tests. 5543 5544 `gcc.c-torture/compile' 5545 This testsuite contains test cases that should compile, but do not 5546 need to link or run. These test cases are compiled with several 5547 different combinations of optimization options. All warnings are 5548 disabled for these test cases, so this directory is not suitable if 5549 you wish to test for the presence or absence of compiler warnings. 5550 While special options can be set, and tests disabled on specific 5551 platforms, by the use of `.x' files, mostly these test cases 5552 should not contain platform dependencies. FIXME: discuss how 5553 defines such as `NO_LABEL_VALUES' and `STACK_SIZE' are used. 5554 5555 `gcc.c-torture/execute' 5556 This testsuite contains test cases that should compile, link and 5557 run; otherwise the same comments as for `gcc.c-torture/compile' 5558 apply. 5559 5560 `gcc.c-torture/execute/ieee' 5561 This contains tests which are specific to IEEE floating point. 5562 5563 `gcc.c-torture/unsorted' 5564 FIXME: describe this. 5565 5566 This directory should probably not be used for new tests. 5567 5568 `gcc.misc-tests' 5569 This directory contains C tests that require special handling. 5570 Some of these tests have individual expect files, and others share 5571 special-purpose expect files: 5572 5573 ``bprob*.c'' 5574 Test `-fbranch-probabilities' using 5575 `gcc.misc-tests/bprob.exp', which in turn uses the generic, 5576 language-independent framework (*note Support for testing 5577 profile-directed optimizations: profopt Testing.). 5578 5579 ``gcov*.c'' 5580 Test `gcov' output using `gcov.exp', which in turn uses the 5581 language-independent support (*note Support for testing gcov: 5582 gcov Testing.). 5583 5584 ``i386-pf-*.c'' 5585 Test i386-specific support for data prefetch using 5586 `i386-prefetch.exp'. 5587 5588 `gcc.test-framework' 5589 5590 ``dg-*.c'' 5591 Test the testsuite itself using 5592 `gcc.test-framework/test-framework.exp'. 5593 5594 5595 FIXME: merge in `testsuite/README.gcc' and discuss the format of test 5596 cases and magic comments more. 5597 5598 5599 File: gccint.info, Node: libgcj Tests, Next: LTO Testing, Prev: C Tests, Up: Testsuites 5600 5601 7.5 The Java library testsuites. 5602 ================================ 5603 5604 Runtime tests are executed via `make check' in the 5605 `TARGET/libjava/testsuite' directory in the build tree. Additional 5606 runtime tests can be checked into this testsuite. 5607 5608 Regression testing of the core packages in libgcj is also covered by 5609 the Mauve testsuite. The Mauve Project develops tests for the Java 5610 Class Libraries. These tests are run as part of libgcj testing by 5611 placing the Mauve tree within the libjava testsuite sources at 5612 `libjava/testsuite/libjava.mauve/mauve', or by specifying the location 5613 of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'. 5614 5615 To detect regressions, a mechanism in `mauve.exp' compares the 5616 failures for a test run against the list of expected failures in 5617 `libjava/testsuite/libjava.mauve/xfails' from the source hierarchy. 5618 Update this file when adding new failing tests to Mauve, or when fixing 5619 bugs in libgcj that had caused Mauve test failures. 5620 5621 We encourage developers to contribute test cases to Mauve. 5622 5623 5624 File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: libgcj Tests, Up: Testsuites 5625 5626 7.6 Support for testing link-time optimizations 5627 =============================================== 5628 5629 Tests for link-time optimizations usually require multiple source files 5630 that are compiled separately, perhaps with different sets of options. 5631 There are several special-purpose test directives used for these tests. 5632 5633 `{ dg-lto-do DO-WHAT-KEYWORD }' 5634 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 5635 is executed. It is one of: 5636 5637 `assemble' 5638 Compile with `-c' to produce a relocatable object file. 5639 5640 `link' 5641 Compile, assemble, and link to produce an executable file. 5642 5643 `run' 5644 Produce and run an executable file, which is expected to 5645 return an exit code of 0. 5646 5647 The default is `assemble'. That can be overridden for a set of 5648 tests by redefining `dg-do-what-default' within the `.exp' file 5649 for those tests. 5650 5651 Unlike `dg-do', `dg-lto-do' does not support an optional `target' 5652 or `xfail' list. Use `dg-skip-if', `dg-xfail-if', or 5653 `dg-xfail-run-if'. 5654 5655 `{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 5656 This directive provides a list of one or more sets of compiler 5657 options to override LTO_OPTIONS. Each test will be compiled and 5658 run with each of these sets of options. 5659 5660 `{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}' 5661 This directive adds OPTIONS to the linker options used. 5662 5663 `{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}' 5664 This directive removes OPTIONS from the set of linker options used. 5665 5666 5667 File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 5668 5669 7.7 Support for testing `gcov' 5670 ============================== 5671 5672 Language-independent support for testing `gcov', and for checking that 5673 branch profiling produces expected values, is provided by the expect 5674 file `lib/gcov.exp'. `gcov' tests also rely on procedures in 5675 `lib/gcc-dg.exp' to compile and run the test program. A typical `gcov' 5676 test contains the following DejaGnu commands within comments: 5677 5678 { dg-options "-fprofile-arcs -ftest-coverage" } 5679 { dg-do run { target native } } 5680 { dg-final { run-gcov sourcefile } } 5681 5682 Checks of `gcov' output can include line counts, branch percentages, 5683 and call return percentages. All of these checks are requested via 5684 commands that appear in comments in the test's source file. Commands 5685 to check line counts are processed by default. Commands to check 5686 branch percentages and call return percentages are processed if the 5687 `run-gcov' command has arguments `branches' or `calls', respectively. 5688 For example, the following specifies checking both, as well as passing 5689 `-b' to `gcov': 5690 5691 { dg-final { run-gcov branches calls { -b sourcefile } } } 5692 5693 A line count command appears within a comment on the source line that 5694 is expected to get the specified count and has the form `count(CNT)'. 5695 A test should only check line counts for lines that will get the same 5696 count for any architecture. 5697 5698 Commands to check branch percentages (`branch') and call return 5699 percentages (`returns') are very similar to each other. A beginning 5700 command appears on or before the first of a range of lines that will 5701 report the percentage, and the ending command follows that range of 5702 lines. The beginning command can include a list of percentages, all of 5703 which are expected to be found within the range. A range is terminated 5704 by the next command of the same kind. A command `branch(end)' or 5705 `returns(end)' marks the end of a range without starting a new one. 5706 For example: 5707 5708 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 5709 /* branch(end) */ 5710 foo (i, j); 5711 5712 For a call return percentage, the value specified is the percentage of 5713 calls reported to return. For a branch percentage, the value is either 5714 the expected percentage or 100 minus that value, since the direction of 5715 a branch can differ depending on the target or the optimization level. 5716 5717 Not all branches and calls need to be checked. A test should not 5718 check for branches that might be optimized away or replaced with 5719 predicated instructions. Don't check for calls inserted by the 5720 compiler or ones that might be inlined or optimized away. 5721 5722 A single test can check for combinations of line counts, branch 5723 percentages, and call return percentages. The command to check a line 5724 count must appear on the line that will report that count, but commands 5725 to check branch percentages and call return percentages can bracket the 5726 lines that report them. 5727 5728 5729 File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 5730 5731 7.8 Support for testing profile-directed optimizations 5732 ====================================================== 5733 5734 The file `profopt.exp' provides language-independent support for 5735 checking correct execution of a test built with profile-directed 5736 optimization. This testing requires that a test program be built and 5737 executed twice. The first time it is compiled to generate profile 5738 data, and the second time it is compiled to use the data that was 5739 generated during the first execution. The second execution is to 5740 verify that the test produces the expected results. 5741 5742 To check that the optimization actually generated better code, a test 5743 can be built and run a third time with normal optimizations to verify 5744 that the performance is better with the profile-directed optimizations. 5745 `profopt.exp' has the beginnings of this kind of support. 5746 5747 `profopt.exp' provides generic support for profile-directed 5748 optimizations. Each set of tests that uses it provides information 5749 about a specific optimization: 5750 5751 `tool' 5752 tool being tested, e.g., `gcc' 5753 5754 `profile_option' 5755 options used to generate profile data 5756 5757 `feedback_option' 5758 options used to optimize using that profile data 5759 5760 `prof_ext' 5761 suffix of profile data files 5762 5763 `PROFOPT_OPTIONS' 5764 list of options with which to run each test, similar to the lists 5765 for torture tests 5766 5767 `{ dg-final-generate { LOCAL-DIRECTIVE } }' 5768 This directive is similar to `dg-final', but the LOCAL-DIRECTIVE 5769 is run after the generation of profile data. 5770 5771 `{ dg-final-use { LOCAL-DIRECTIVE } }' 5772 The LOCAL-DIRECTIVE is run after the profile data have been used. 5773 5774 5775 File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 5776 5777 7.9 Support for testing binary compatibility 5778 ============================================ 5779 5780 The file `compat.exp' provides language-independent support for binary 5781 compatibility testing. It supports testing interoperability of two 5782 compilers that follow the same ABI, or of multiple sets of compiler 5783 options that should not affect binary compatibility. It is intended to 5784 be used for testsuites that complement ABI testsuites. 5785 5786 A test supported by this framework has three parts, each in a separate 5787 source file: a main program and two pieces that interact with each 5788 other to split up the functionality being tested. 5789 5790 `TESTNAME_main.SUFFIX' 5791 Contains the main program, which calls a function in file 5792 `TESTNAME_x.SUFFIX'. 5793 5794 `TESTNAME_x.SUFFIX' 5795 Contains at least one call to a function in `TESTNAME_y.SUFFIX'. 5796 5797 `TESTNAME_y.SUFFIX' 5798 Shares data with, or gets arguments from, `TESTNAME_x.SUFFIX'. 5799 5800 Within each test, the main program and one functional piece are 5801 compiled by the GCC under test. The other piece can be compiled by an 5802 alternate compiler. If no alternate compiler is specified, then all 5803 three source files are all compiled by the GCC under test. You can 5804 specify pairs of sets of compiler options. The first element of such a 5805 pair specifies options used with the GCC under test, and the second 5806 element of the pair specifies options used with the alternate compiler. 5807 Each test is compiled with each pair of options. 5808 5809 `compat.exp' defines default pairs of compiler options. These can be 5810 overridden by defining the environment variable `COMPAT_OPTIONS' as: 5811 5812 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 5813 ...[list {TSTN} {ALTN}]]" 5814 5815 where TSTI and ALTI are lists of options, with TSTI used by the 5816 compiler under test and ALTI used by the alternate compiler. For 5817 example, with `[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 5818 the test is first built with `-g -O0' by the compiler under test and 5819 with `-O3' by the alternate compiler. The test is built a second time 5820 using `-fpic' by the compiler under test and `-fPIC -O2' by the 5821 alternate compiler. 5822 5823 An alternate compiler is specified by defining an environment variable 5824 to be the full pathname of an installed compiler; for C define 5825 `ALT_CC_UNDER_TEST', and for C++ define `ALT_CXX_UNDER_TEST'. These 5826 will be written to the `site.exp' file used by DejaGnu. The default is 5827 to build each test with the compiler under test using the first of each 5828 pair of compiler options from `COMPAT_OPTIONS'. When 5829 `ALT_CC_UNDER_TEST' or `ALT_CXX_UNDER_TEST' is `same', each test is 5830 built using the compiler under test but with combinations of the 5831 options from `COMPAT_OPTIONS'. 5832 5833 To run only the C++ compatibility suite using the compiler under test 5834 and another version of GCC using specific compiler options, do the 5835 following from `OBJDIR/gcc': 5836 5837 rm site.exp 5838 make -k \ 5839 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 5840 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 5841 check-c++ \ 5842 RUNTESTFLAGS="compat.exp" 5843 5844 A test that fails when the source files are compiled with different 5845 compilers, but passes when the files are compiled with the same 5846 compiler, demonstrates incompatibility of the generated code or runtime 5847 support. A test that fails for the alternate compiler but passes for 5848 the compiler under test probably tests for a bug that was fixed in the 5849 compiler under test but is present in the alternate compiler. 5850 5851 The binary compatibility tests support a small number of test framework 5852 commands that appear within comments in a test file. 5853 5854 `dg-require-*' 5855 These commands can be used in `TESTNAME_main.SUFFIX' to skip the 5856 test if specific support is not available on the target. 5857 5858 `dg-options' 5859 The specified options are used for compiling this particular source 5860 file, appended to the options from `COMPAT_OPTIONS'. When this 5861 command appears in `TESTNAME_main.SUFFIX' the options are also 5862 used to link the test program. 5863 5864 `dg-xfail-if' 5865 This command can be used in a secondary source file to specify that 5866 compilation is expected to fail for particular options on 5867 particular targets. 5868 5869 5870 File: gccint.info, Node: Torture Tests, Prev: compat Testing, Up: Testsuites 5871 5872 7.10 Support for torture testing using multiple options 5873 ======================================================= 5874 5875 Throughout the compiler testsuite there are several directories whose 5876 tests are run multiple times, each with a different set of options. 5877 These are known as torture tests. `lib/torture-options.exp' defines 5878 procedures to set up these lists: 5879 5880 `torture-init' 5881 Initialize use of torture lists. 5882 5883 `set-torture-options' 5884 Set lists of torture options to use for tests with and without 5885 loops. Optionally combine a set of torture options with a set of 5886 other options, as is done with Objective-C runtime options. 5887 5888 `torture-finish' 5889 Finalize use of torture lists. 5890 5891 The `.exp' file for a set of tests that use torture options must 5892 include calls to these three procedures if: 5893 5894 * It calls `gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 5895 5896 * It calls ${TOOL}`-torture' or ${TOOL}`-torture-execute', where 5897 TOOL is `c', `fortran', or `objc'. 5898 5899 * It calls `dg-pch'. 5900 5901 It is not necessary for a `.exp' file that calls `gcc-dg-runtest' to 5902 call the torture procedures if the tests should use the list in 5903 DG_TORTURE_OPTIONS defined in `gcc-dg.exp'. 5904 5905 Most uses of torture options can override the default lists by defining 5906 TORTURE_OPTIONS or add to the default list by defining 5907 ADDITIONAL_TORTURE_OPTIONS. Define these in a `.dejagnurc' file or add 5908 them to the `site.exp' file; for example 5909 5910 set ADDITIONAL_TORTURE_OPTIONS [list \ 5911 { -O2 -ftree-loop-linear } \ 5912 { -O2 -fpeel-loops } ] 5913 5914 5915 File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 5916 5917 8 Option specification files 5918 **************************** 5919 5920 Most GCC command-line options are described by special option 5921 definition files, the names of which conventionally end in `.opt'. 5922 This chapter describes the format of these files. 5923 5924 * Menu: 5925 5926 * Option file format:: The general layout of the files 5927 * Option properties:: Supported option properties 5928 5929 5930 File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 5931 5932 8.1 Option file format 5933 ====================== 5934 5935 Option files are a simple list of records in which each field occupies 5936 its own line and in which the records themselves are separated by blank 5937 lines. Comments may appear on their own line anywhere within the file 5938 and are preceded by semicolons. Whitespace is allowed before the 5939 semicolon. 5940 5941 The files can contain the following types of record: 5942 5943 * A language definition record. These records have two fields: the 5944 string `Language' and the name of the language. Once a language 5945 has been declared in this way, it can be used as an option 5946 property. *Note Option properties::. 5947 5948 * A target specific save record to save additional information. These 5949 records have two fields: the string `TargetSave', and a 5950 declaration type to go in the `cl_target_option' structure. 5951 5952 * A variable record to define a variable used to store option 5953 information. These records have two fields: the string 5954 `Variable', and a declaration of the type and name of the 5955 variable, optionally with an initializer (but without any trailing 5956 `;'). These records may be used for variables used for many 5957 options where declaring the initializer in a single option 5958 definition record, or duplicating it in many records, would be 5959 inappropriate, or for variables set in option handlers rather than 5960 referenced by `Var' properties. 5961 5962 * A variable record to define a variable used to store option 5963 information. These records have two fields: the string 5964 `TargetVariable', and a declaration of the type and name of the 5965 variable, optionally with an initializer (but without any trailing 5966 `;'). `TargetVariable' is a combination of `Variable' and 5967 `TargetSave' records in that the variable is defined in the 5968 `gcc_options' structure, but these variables are also stored in 5969 the `cl_target_option' structure. The variables are saved in the 5970 target save code and restored in the target restore code. 5971 5972 * A variable record to record any additional files that the 5973 `options.h' file should include. This is useful to provide 5974 enumeration or structure definitions needed for target variables. 5975 These records have two fields: the string `HeaderInclude' and the 5976 name of the include file. 5977 5978 * A variable record to record any additional files that the 5979 `options.c' file should include. This is useful to provide inline 5980 functions needed for target variables and/or `#ifdef' sequences to 5981 properly set up the initialization. These records have two 5982 fields: the string `SourceInclude' and the name of the include 5983 file. 5984 5985 * An enumeration record to define a set of strings that may be used 5986 as arguments to an option or options. These records have three 5987 fields: the string `Enum', a space-separated list of properties 5988 and help text used to describe the set of strings in `--help' 5989 output. Properties use the same format as option properties; the 5990 following are valid: 5991 `Name(NAME)' 5992 This property is required; NAME must be a name (suitable for 5993 use in C identifiers) used to identify the set of strings in 5994 `Enum' option properties. 5995 5996 `Type(TYPE)' 5997 This property is required; TYPE is the C type for variables 5998 set by options using this enumeration together with `Var'. 5999 6000 `UnknownError(MESSAGE)' 6001 The message MESSAGE will be used as an error message if the 6002 argument is invalid; for enumerations without `UnknownError', 6003 a generic error message is used. MESSAGE should contain a 6004 single `%qs' format, which will be used to format the invalid 6005 argument. 6006 6007 * An enumeration value record to define one of the strings in a set 6008 given in an `Enum' record. These records have two fields: the 6009 string `EnumValue' and a space-separated list of properties. 6010 Properties use the same format as option properties; the following 6011 are valid: 6012 `Enum(NAME)' 6013 This property is required; NAME says which `Enum' record this 6014 `EnumValue' record corresponds to. 6015 6016 `String(STRING)' 6017 This property is required; STRING is the string option 6018 argument being described by this record. 6019 6020 `Value(VALUE)' 6021 This property is required; it says what value (representable 6022 as `int') should be used for the given string. 6023 6024 `Canonical' 6025 This property is optional. If present, it says the present 6026 string is the canonical one among all those with the given 6027 value. Other strings yielding that value will be mapped to 6028 this one so specs do not need to handle them. 6029 6030 `DriverOnly' 6031 This property is optional. If present, the present string 6032 will only be accepted by the driver. This is used for cases 6033 such as `-march=native' that are processed by the driver so 6034 that `gcc -v' shows how the options chosen depended on the 6035 system on which the compiler was run. 6036 6037 * An option definition record. These records have the following 6038 fields: 6039 1. the name of the option, with the leading "-" removed 6040 6041 2. a space-separated list of option properties (*note Option 6042 properties::) 6043 6044 3. the help text to use for `--help' (omitted if the second field 6045 contains the `Undocumented' property). 6046 6047 By default, all options beginning with "f", "W" or "m" are 6048 implicitly assumed to take a "no-" form. This form should not be 6049 listed separately. If an option beginning with one of these 6050 letters does not have a "no-" form, you can use the 6051 `RejectNegative' property to reject it. 6052 6053 The help text is automatically line-wrapped before being displayed. 6054 Normally the name of the option is printed on the left-hand side of 6055 the output and the help text is printed on the right. However, if 6056 the help text contains a tab character, the text to the left of 6057 the tab is used instead of the option's name and the text to the 6058 right of the tab forms the help text. This allows you to 6059 elaborate on what type of argument the option takes. 6060 6061 * A target mask record. These records have one field of the form 6062 `Mask(X)'. The options-processing script will automatically 6063 allocate a bit in `target_flags' (*note Run-time Target::) for 6064 each mask name X and set the macro `MASK_X' to the appropriate 6065 bitmask. It will also declare a `TARGET_X' macro that has the 6066 value 1 when bit `MASK_X' is set and 0 otherwise. 6067 6068 They are primarily intended to declare target masks that are not 6069 associated with user options, either because these masks represent 6070 internal switches or because the options are not available on all 6071 configurations and yet the masks always need to be defined. 6072 6073 6074 File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 6075 6076 8.2 Option properties 6077 ===================== 6078 6079 The second field of an option record can specify any of the following 6080 properties. When an option takes an argument, it is enclosed in 6081 parentheses following the option property name. The parser that 6082 handles option files is quite simplistic, and will be tricked by any 6083 nested parentheses within the argument text itself; in this case, the 6084 entire option argument can be wrapped in curly braces within the 6085 parentheses to demarcate it, e.g.: 6086 6087 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 6088 6089 `Common' 6090 The option is available for all languages and targets. 6091 6092 `Target' 6093 The option is available for all languages but is target-specific. 6094 6095 `Driver' 6096 The option is handled by the compiler driver using code not shared 6097 with the compilers proper (`cc1' etc.). 6098 6099 `LANGUAGE' 6100 The option is available when compiling for the given language. 6101 6102 It is possible to specify several different languages for the same 6103 option. Each LANGUAGE must have been declared by an earlier 6104 `Language' record. *Note Option file format::. 6105 6106 `RejectDriver' 6107 The option is only handled by the compilers proper (`cc1' etc.) 6108 and should not be accepted by the driver. 6109 6110 `RejectNegative' 6111 The option does not have a "no-" form. All options beginning with 6112 "f", "W" or "m" are assumed to have a "no-" form unless this 6113 property is used. 6114 6115 `Negative(OTHERNAME)' 6116 The option will turn off another option OTHERNAME, which is the 6117 option name with the leading "-" removed. This chain action will 6118 propagate through the `Negative' property of the option to be 6119 turned off. 6120 6121 `Joined' 6122 `Separate' 6123 The option takes a mandatory argument. `Joined' indicates that 6124 the option and argument can be included in the same `argv' entry 6125 (as with `-mflush-func=NAME', for example). `Separate' indicates 6126 that the option and argument can be separate `argv' entries (as 6127 with `-o'). An option is allowed to have both of these properties. 6128 6129 `JoinedOrMissing' 6130 The option takes an optional argument. If the argument is given, 6131 it will be part of the same `argv' entry as the option itself. 6132 6133 This property cannot be used alongside `Joined' or `Separate'. 6134 6135 `MissingArgError(MESSAGE)' 6136 For an option marked `Joined' or `Separate', the message MESSAGE 6137 will be used as an error message if the mandatory argument is 6138 missing; for options without `MissingArgError', a generic error 6139 message is used. MESSAGE should contain a single `%qs' format, 6140 which will be used to format the name of the option passed. 6141 6142 `Args(N)' 6143 For an option marked `Separate', indicate that it takes N 6144 arguments. The default is 1. 6145 6146 `UInteger' 6147 The option's argument is a non-negative integer. The option parser 6148 will check and convert the argument before passing it to the 6149 relevant option handler. `UInteger' should also be used on 6150 options like `-falign-loops' where both `-falign-loops' and 6151 `-falign-loops'=N are supported to make sure the saved options are 6152 given a full integer. 6153 6154 `NoDriverArg' 6155 For an option marked `Separate', the option only takes an argument 6156 in the compiler proper, not in the driver. This is for 6157 compatibility with existing options that are used both directly and 6158 via `-Wp,'; new options should not have this property. 6159 6160 `Var(VAR)' 6161 The state of this option should be stored in variable VAR 6162 (actually a macro for `global_options.x_VAR'). The way that the 6163 state is stored depends on the type of option: 6164 6165 * If the option uses the `Mask' or `InverseMask' properties, 6166 VAR is the integer variable that contains the mask. 6167 6168 * If the option is a normal on/off switch, VAR is an integer 6169 variable that is nonzero when the option is enabled. The 6170 options parser will set the variable to 1 when the positive 6171 form of the option is used and 0 when the "no-" form is used. 6172 6173 * If the option takes an argument and has the `UInteger' 6174 property, VAR is an integer variable that stores the value of 6175 the argument. 6176 6177 * If the option takes an argument and has the `Enum' property, 6178 VAR is a variable (type given in the `Type' property of the 6179 `Enum' record whose `Name' property has the same argument as 6180 the `Enum' property of this option) that stores the value of 6181 the argument. 6182 6183 * If the option has the `Defer' property, VAR is a pointer to a 6184 `VEC(cl_deferred_option,heap)' that stores the option for 6185 later processing. (VAR is declared with type `void *' and 6186 needs to be cast to `VEC(cl_deferred_option,heap)' before 6187 use.) 6188 6189 * Otherwise, if the option takes an argument, VAR is a pointer 6190 to the argument string. The pointer will be null if the 6191 argument is optional and wasn't given. 6192 6193 The option-processing script will usually zero-initialize VAR. 6194 You can modify this behavior using `Init'. 6195 6196 `Var(VAR, SET)' 6197 The option controls an integer variable VAR and is active when VAR 6198 equals SET. The option parser will set VAR to SET when the 6199 positive form of the option is used and `!SET' when the "no-" form 6200 is used. 6201 6202 VAR is declared in the same way as for the single-argument form 6203 described above. 6204 6205 `Init(VALUE)' 6206 The variable specified by the `Var' property should be statically 6207 initialized to VALUE. If more than one option using the same 6208 variable specifies `Init', all must specify the same initializer. 6209 6210 `Mask(NAME)' 6211 The option is associated with a bit in the `target_flags' variable 6212 (*note Run-time Target::) and is active when that bit is set. You 6213 may also specify `Var' to select a variable other than 6214 `target_flags'. 6215 6216 The options-processing script will automatically allocate a unique 6217 bit for the option. If the option is attached to `target_flags', 6218 the script will set the macro `MASK_NAME' to the appropriate 6219 bitmask. It will also declare a `TARGET_NAME' macro that has the 6220 value 1 when the option is active and 0 otherwise. If you use 6221 `Var' to attach the option to a different variable, the associated 6222 macros are called `OPTION_MASK_NAME' and `OPTION_NAME' 6223 respectively. 6224 6225 You can disable automatic bit allocation using `MaskExists'. 6226 6227 `InverseMask(OTHERNAME)' 6228 `InverseMask(OTHERNAME, THISNAME)' 6229 The option is the inverse of another option that has the 6230 `Mask(OTHERNAME)' property. If THISNAME is given, the 6231 options-processing script will declare a `TARGET_THISNAME' macro 6232 that is 1 when the option is active and 0 otherwise. 6233 6234 `MaskExists' 6235 The mask specified by the `Mask' property already exists. No 6236 `MASK' or `TARGET' definitions should be added to `options.h' in 6237 response to this option record. 6238 6239 The main purpose of this property is to support synonymous options. 6240 The first option should use `Mask(NAME)' and the others should use 6241 `Mask(NAME) MaskExists'. 6242 6243 `Enum(NAME)' 6244 The option's argument is a string from the set of strings 6245 associated with the corresponding `Enum' record. The string is 6246 checked and converted to the integer specified in the corresponding 6247 `EnumValue' record before being passed to option handlers. 6248 6249 `Defer' 6250 The option should be stored in a vector, specified with `Var', for 6251 later processing. 6252 6253 `Alias(OPT)' 6254 `Alias(OPT, ARG)' 6255 `Alias(OPT, POSARG, NEGARG)' 6256 The option is an alias for `-OPT'. In the first form, any 6257 argument passed to the alias is considered to be passed to `-OPT', 6258 and `-OPT' is considered to be negated if the alias is used in 6259 negated form. In the second form, the alias may not be negated or 6260 have an argument, and POSARG is considered to be passed as an 6261 argument to `-OPT'. In the third form, the alias may not have an 6262 argument, if the alias is used in the positive form then POSARG is 6263 considered to be passed to `-OPT', and if the alias is used in the 6264 negative form then NEGARG is considered to be passed to `-OPT'. 6265 6266 Aliases should not specify `Var' or `Mask' or `UInteger'. Aliases 6267 should normally specify the same languages as the target of the 6268 alias; the flags on the target will be used to determine any 6269 diagnostic for use of an option for the wrong language, while 6270 those on the alias will be used to identify what command-line text 6271 is the option and what text is any argument to that option. 6272 6273 When an `Alias' definition is used for an option, driver specs do 6274 not need to handle it and no `OPT_' enumeration value is defined 6275 for it; only the canonical form of the option will be seen in those 6276 places. 6277 6278 `Ignore' 6279 This option is ignored apart from printing any warning specified 6280 using `Warn'. The option will not be seen by specs and no `OPT_' 6281 enumeration value is defined for it. 6282 6283 `SeparateAlias' 6284 For an option marked with `Joined', `Separate' and `Alias', the 6285 option only acts as an alias when passed a separate argument; with 6286 a joined argument it acts as a normal option, with an `OPT_' 6287 enumeration value. This is for compatibility with the Java `-d' 6288 option and should not be used for new options. 6289 6290 `Warn(MESSAGE)' 6291 If this option is used, output the warning MESSAGE. MESSAGE is a 6292 format string, either taking a single operand with a `%qs' format 6293 which is the option name, or not taking any operands, which is 6294 passed to the `warning' function. If an alias is marked `Warn', 6295 the target of the alias must not also be marked `Warn'. 6296 6297 `Report' 6298 The state of the option should be printed by `-fverbose-asm'. 6299 6300 `Warning' 6301 This is a warning option and should be shown as such in `--help' 6302 output. This flag does not currently affect anything other than 6303 `--help'. 6304 6305 `Optimization' 6306 This is an optimization option. It should be shown as such in 6307 `--help' output, and any associated variable named using `Var' 6308 should be saved and restored when the optimization level is 6309 changed with `optimize' attributes. 6310 6311 `Undocumented' 6312 The option is deliberately missing documentation and should not be 6313 included in the `--help' output. 6314 6315 `Condition(COND)' 6316 The option should only be accepted if preprocessor condition COND 6317 is true. Note that any C declarations associated with the option 6318 will be present even if COND is false; COND simply controls 6319 whether the option is accepted and whether it is printed in the 6320 `--help' output. 6321 6322 `Save' 6323 Build the `cl_target_option' structure to hold a copy of the 6324 option, add the functions `cl_target_option_save' and 6325 `cl_target_option_restore' to save and restore the options. 6326 6327 `SetByCombined' 6328 The option may also be set by a combined option such as 6329 `-ffast-math'. This causes the `gcc_options' struct to have a 6330 field `frontend_set_NAME', where `NAME' is the name of the field 6331 holding the value of this option (without the leading `x_'). This 6332 gives the front end a way to indicate that the value has been set 6333 explicitly and should not be changed by the combined option. For 6334 example, some front ends use this to prevent `-ffast-math' and 6335 `-fno-fast-math' from changing the value of `-fmath-errno' for 6336 languages that do not use `errno'. 6337 6338 6339 6340 File: gccint.info, Node: Passes, Next: GENERIC, Prev: Options, Up: Top 6341 6342 9 Passes and Files of the Compiler 6343 ********************************** 6344 6345 This chapter is dedicated to giving an overview of the optimization and 6346 code generation passes of the compiler. In the process, it describes 6347 some of the language front end interface, though this description is no 6348 where near complete. 6349 6350 * Menu: 6351 6352 * Parsing pass:: The language front end turns text into bits. 6353 * Gimplification pass:: The bits are turned into something we can optimize. 6354 * Pass manager:: Sequencing the optimization passes. 6355 * Tree SSA passes:: Optimizations on a high-level representation. 6356 * RTL passes:: Optimizations on a low-level representation. 6357 6358 6359 File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes 6360 6361 9.1 Parsing pass 6362 ================ 6363 6364 The language front end is invoked only once, via 6365 `lang_hooks.parse_file', to parse the entire input. The language front 6366 end may use any intermediate language representation deemed 6367 appropriate. The C front end uses GENERIC trees (*note GENERIC::), plus 6368 a double handful of language specific tree codes defined in 6369 `c-common.def'. The Fortran front end uses a completely different 6370 private representation. 6371 6372 At some point the front end must translate the representation used in 6373 the front end to a representation understood by the language-independent 6374 portions of the compiler. Current practice takes one of two forms. 6375 The C front end manually invokes the gimplifier (*note GIMPLE::) on 6376 each function, and uses the gimplifier callbacks to convert the 6377 language-specific tree nodes directly to GIMPLE before passing the 6378 function off to be compiled. The Fortran front end converts from a 6379 private representation to GENERIC, which is later lowered to GIMPLE 6380 when the function is compiled. Which route to choose probably depends 6381 on how well GENERIC (plus extensions) can be made to match up with the 6382 source language and necessary parsing data structures. 6383 6384 BUG: Gimplification must occur before nested function lowering, and 6385 nested function lowering must be done by the front end before passing 6386 the data off to cgraph. 6387 6388 TODO: Cgraph should control nested function lowering. It would only 6389 be invoked when it is certain that the outer-most function is used. 6390 6391 TODO: Cgraph needs a gimplify_function callback. It should be invoked 6392 when (1) it is certain that the function is used, (2) warning flags 6393 specified by the user require some amount of compilation in order to 6394 honor, (3) the language indicates that semantic analysis is not 6395 complete until gimplification occurs. Hum... this sounds overly 6396 complicated. Perhaps we should just have the front end gimplify 6397 always; in most cases it's only one function call. 6398 6399 The front end needs to pass all function definitions and top level 6400 declarations off to the middle-end so that they can be compiled and 6401 emitted to the object file. For a simple procedural language, it is 6402 usually most convenient to do this as each top level declaration or 6403 definition is seen. There is also a distinction to be made between 6404 generating functional code and generating complete debug information. 6405 The only thing that is absolutely required for functional code is that 6406 function and data _definitions_ be passed to the middle-end. For 6407 complete debug information, function, data and type declarations should 6408 all be passed as well. 6409 6410 In any case, the front end needs each complete top-level function or 6411 data declaration, and each data definition should be passed to 6412 `rest_of_decl_compilation'. Each complete type definition should be 6413 passed to `rest_of_type_compilation'. Each function definition should 6414 be passed to `cgraph_finalize_function'. 6415 6416 TODO: I know rest_of_compilation currently has all sorts of RTL 6417 generation semantics. I plan to move all code generation bits (both 6418 Tree and RTL) to compile_function. Should we hide cgraph from the 6419 front ends and move back to rest_of_compilation as the official 6420 interface? Possibly we should rename all three interfaces such that 6421 the names match in some meaningful way and that is more descriptive 6422 than "rest_of". 6423 6424 The middle-end will, at its option, emit the function and data 6425 definitions immediately or queue them for later processing. 6426 6427 6428 File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes 6429 6430 9.2 Gimplification pass 6431 ======================= 6432 6433 "Gimplification" is a whimsical term for the process of converting the 6434 intermediate representation of a function into the GIMPLE language 6435 (*note GIMPLE::). The term stuck, and so words like "gimplification", 6436 "gimplify", "gimplifier" and the like are sprinkled throughout this 6437 section of code. 6438 6439 While a front end may certainly choose to generate GIMPLE directly if 6440 it chooses, this can be a moderately complex process unless the 6441 intermediate language used by the front end is already fairly simple. 6442 Usually it is easier to generate GENERIC trees plus extensions and let 6443 the language-independent gimplifier do most of the work. 6444 6445 The main entry point to this pass is `gimplify_function_tree' located 6446 in `gimplify.c'. From here we process the entire function gimplifying 6447 each statement in turn. The main workhorse for this pass is 6448 `gimplify_expr'. Approximately everything passes through here at least 6449 once, and it is from here that we invoke the `lang_hooks.gimplify_expr' 6450 callback. 6451 6452 The callback should examine the expression in question and return 6453 `GS_UNHANDLED' if the expression is not a language specific construct 6454 that requires attention. Otherwise it should alter the expression in 6455 some way to such that forward progress is made toward producing valid 6456 GIMPLE. If the callback is certain that the transformation is complete 6457 and the expression is valid GIMPLE, it should return `GS_ALL_DONE'. 6458 Otherwise it should return `GS_OK', which will cause the expression to 6459 be processed again. If the callback encounters an error during the 6460 transformation (because the front end is relying on the gimplification 6461 process to finish semantic checks), it should return `GS_ERROR'. 6462 6463 6464 File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes 6465 6466 9.3 Pass manager 6467 ================ 6468 6469 The pass manager is located in `passes.c', `tree-optimize.c' and 6470 `tree-pass.h'. Its job is to run all of the individual passes in the 6471 correct order, and take care of standard bookkeeping that applies to 6472 every pass. 6473 6474 The theory of operation is that each pass defines a structure that 6475 represents everything we need to know about that pass--when it should 6476 be run, how it should be run, what intermediate language form or 6477 on-the-side data structures it needs. We register the pass to be run 6478 in some particular order, and the pass manager arranges for everything 6479 to happen in the correct order. 6480 6481 The actuality doesn't completely live up to the theory at present. 6482 Command-line switches and `timevar_id_t' enumerations must still be 6483 defined elsewhere. The pass manager validates constraints but does not 6484 attempt to (re-)generate data structures or lower intermediate language 6485 form based on the requirements of the next pass. Nevertheless, what is 6486 present is useful, and a far sight better than nothing at all. 6487 6488 Each pass should have a unique name. Each pass may have its own dump 6489 file (for GCC debugging purposes). Passes with a name starting with a 6490 star do not dump anything. Sometimes passes are supposed to share a 6491 dump file / option name. To still give these unique names, you can use 6492 a prefix that is delimited by a space from the part that is used for 6493 the dump file / option name. E.g. When the pass name is "ud dce", the 6494 name used for dump file/options is "dce". 6495 6496 TODO: describe the global variables set up by the pass manager, and a 6497 brief description of how a new pass should use it. I need to look at 6498 what info RTL passes use first... 6499 6500 6501 File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes 6502 6503 9.4 Tree SSA passes 6504 =================== 6505 6506 The following briefly describes the Tree optimization passes that are 6507 run after gimplification and what source files they are located in. 6508 6509 * Remove useless statements 6510 6511 This pass is an extremely simple sweep across the gimple code in 6512 which we identify obviously dead code and remove it. Here we do 6513 things like simplify `if' statements with constant conditions, 6514 remove exception handling constructs surrounding code that 6515 obviously cannot throw, remove lexical bindings that contain no 6516 variables, and other assorted simplistic cleanups. The idea is to 6517 get rid of the obvious stuff quickly rather than wait until later 6518 when it's more work to get rid of it. This pass is located in 6519 `tree-cfg.c' and described by `pass_remove_useless_stmts'. 6520 6521 * Mudflap declaration registration 6522 6523 If mudflap (*note -fmudflap -fmudflapth -fmudflapir: (gcc)Optimize 6524 Options.) is enabled, we generate code to register some variable 6525 declarations with the mudflap runtime. Specifically, the runtime 6526 tracks the lifetimes of those variable declarations that have 6527 their addresses taken, or whose bounds are unknown at compile time 6528 (`extern'). This pass generates new exception handling constructs 6529 (`try'/`finally'), and so must run before those are lowered. In 6530 addition, the pass enqueues declarations of static variables whose 6531 lifetimes extend to the entire program. The pass is located in 6532 `tree-mudflap.c' and is described by `pass_mudflap_1'. 6533 6534 * OpenMP lowering 6535 6536 If OpenMP generation (`-fopenmp') is enabled, this pass lowers 6537 OpenMP constructs into GIMPLE. 6538 6539 Lowering of OpenMP constructs involves creating replacement 6540 expressions for local variables that have been mapped using data 6541 sharing clauses, exposing the control flow of most synchronization 6542 directives and adding region markers to facilitate the creation of 6543 the control flow graph. The pass is located in `omp-low.c' and is 6544 described by `pass_lower_omp'. 6545 6546 * OpenMP expansion 6547 6548 If OpenMP generation (`-fopenmp') is enabled, this pass expands 6549 parallel regions into their own functions to be invoked by the 6550 thread library. The pass is located in `omp-low.c' and is 6551 described by `pass_expand_omp'. 6552 6553 * Lower control flow 6554 6555 This pass flattens `if' statements (`COND_EXPR') and moves lexical 6556 bindings (`BIND_EXPR') out of line. After this pass, all `if' 6557 statements will have exactly two `goto' statements in its `then' 6558 and `else' arms. Lexical binding information for each statement 6559 will be found in `TREE_BLOCK' rather than being inferred from its 6560 position under a `BIND_EXPR'. This pass is found in 6561 `gimple-low.c' and is described by `pass_lower_cf'. 6562 6563 * Lower exception handling control flow 6564 6565 This pass decomposes high-level exception handling constructs 6566 (`TRY_FINALLY_EXPR' and `TRY_CATCH_EXPR') into a form that 6567 explicitly represents the control flow involved. After this pass, 6568 `lookup_stmt_eh_region' will return a non-negative number for any 6569 statement that may have EH control flow semantics; examine 6570 `tree_can_throw_internal' or `tree_can_throw_external' for exact 6571 semantics. Exact control flow may be extracted from 6572 `foreach_reachable_handler'. The EH region nesting tree is defined 6573 in `except.h' and built in `except.c'. The lowering pass itself 6574 is in `tree-eh.c' and is described by `pass_lower_eh'. 6575 6576 * Build the control flow graph 6577 6578 This pass decomposes a function into basic blocks and creates all 6579 of the edges that connect them. It is located in `tree-cfg.c' and 6580 is described by `pass_build_cfg'. 6581 6582 * Find all referenced variables 6583 6584 This pass walks the entire function and collects an array of all 6585 variables referenced in the function, `referenced_vars'. The 6586 index at which a variable is found in the array is used as a UID 6587 for the variable within this function. This data is needed by the 6588 SSA rewriting routines. The pass is located in `tree-dfa.c' and 6589 is described by `pass_referenced_vars'. 6590 6591 * Enter static single assignment form 6592 6593 This pass rewrites the function such that it is in SSA form. After 6594 this pass, all `is_gimple_reg' variables will be referenced by 6595 `SSA_NAME', and all occurrences of other variables will be 6596 annotated with `VDEFS' and `VUSES'; PHI nodes will have been 6597 inserted as necessary for each basic block. This pass is located 6598 in `tree-ssa.c' and is described by `pass_build_ssa'. 6599 6600 * Warn for uninitialized variables 6601 6602 This pass scans the function for uses of `SSA_NAME's that are fed 6603 by default definition. For non-parameter variables, such uses are 6604 uninitialized. The pass is run twice, before and after 6605 optimization (if turned on). In the first pass we only warn for 6606 uses that are positively uninitialized; in the second pass we warn 6607 for uses that are possibly uninitialized. The pass is located in 6608 `tree-ssa.c' and is defined by `pass_early_warn_uninitialized' and 6609 `pass_late_warn_uninitialized'. 6610 6611 * Dead code elimination 6612 6613 This pass scans the function for statements without side effects 6614 whose result is unused. It does not do memory life analysis, so 6615 any value that is stored in memory is considered used. The pass 6616 is run multiple times throughout the optimization process. It is 6617 located in `tree-ssa-dce.c' and is described by `pass_dce'. 6618 6619 * Dominator optimizations 6620 6621 This pass performs trivial dominator-based copy and constant 6622 propagation, expression simplification, and jump threading. It is 6623 run multiple times throughout the optimization process. It is 6624 located in `tree-ssa-dom.c' and is described by `pass_dominator'. 6625 6626 * Forward propagation of single-use variables 6627 6628 This pass attempts to remove redundant computation by substituting 6629 variables that are used once into the expression that uses them and 6630 seeing if the result can be simplified. It is located in 6631 `tree-ssa-forwprop.c' and is described by `pass_forwprop'. 6632 6633 * Copy Renaming 6634 6635 This pass attempts to change the name of compiler temporaries 6636 involved in copy operations such that SSA->normal can coalesce the 6637 copy away. When compiler temporaries are copies of user 6638 variables, it also renames the compiler temporary to the user 6639 variable resulting in better use of user symbols. It is located 6640 in `tree-ssa-copyrename.c' and is described by `pass_copyrename'. 6641 6642 * PHI node optimizations 6643 6644 This pass recognizes forms of PHI inputs that can be represented as 6645 conditional expressions and rewrites them into straight line code. 6646 It is located in `tree-ssa-phiopt.c' and is described by 6647 `pass_phiopt'. 6648 6649 * May-alias optimization 6650 6651 This pass performs a flow sensitive SSA-based points-to analysis. 6652 The resulting may-alias, must-alias, and escape analysis 6653 information is used to promote variables from in-memory 6654 addressable objects to non-aliased variables that can be renamed 6655 into SSA form. We also update the `VDEF'/`VUSE' memory tags for 6656 non-renameable aggregates so that we get fewer false kills. The 6657 pass is located in `tree-ssa-alias.c' and is described by 6658 `pass_may_alias'. 6659 6660 Interprocedural points-to information is located in 6661 `tree-ssa-structalias.c' and described by `pass_ipa_pta'. 6662 6663 * Profiling 6664 6665 This pass rewrites the function in order to collect runtime block 6666 and value profiling data. Such data may be fed back into the 6667 compiler on a subsequent run so as to allow optimization based on 6668 expected execution frequencies. The pass is located in 6669 `predict.c' and is described by `pass_profile'. 6670 6671 * Lower complex arithmetic 6672 6673 This pass rewrites complex arithmetic operations into their 6674 component scalar arithmetic operations. The pass is located in 6675 `tree-complex.c' and is described by `pass_lower_complex'. 6676 6677 * Scalar replacement of aggregates 6678 6679 This pass rewrites suitable non-aliased local aggregate variables 6680 into a set of scalar variables. The resulting scalar variables are 6681 rewritten into SSA form, which allows subsequent optimization 6682 passes to do a significantly better job with them. The pass is 6683 located in `tree-sra.c' and is described by `pass_sra'. 6684 6685 * Dead store elimination 6686 6687 This pass eliminates stores to memory that are subsequently 6688 overwritten by another store, without any intervening loads. The 6689 pass is located in `tree-ssa-dse.c' and is described by `pass_dse'. 6690 6691 * Tail recursion elimination 6692 6693 This pass transforms tail recursion into a loop. It is located in 6694 `tree-tailcall.c' and is described by `pass_tail_recursion'. 6695 6696 * Forward store motion 6697 6698 This pass sinks stores and assignments down the flowgraph closer 6699 to their use point. The pass is located in `tree-ssa-sink.c' and 6700 is described by `pass_sink_code'. 6701 6702 * Partial redundancy elimination 6703 6704 This pass eliminates partially redundant computations, as well as 6705 performing load motion. The pass is located in `tree-ssa-pre.c' 6706 and is described by `pass_pre'. 6707 6708 Just before partial redundancy elimination, if 6709 `-funsafe-math-optimizations' is on, GCC tries to convert 6710 divisions to multiplications by the reciprocal. The pass is 6711 located in `tree-ssa-math-opts.c' and is described by 6712 `pass_cse_reciprocal'. 6713 6714 * Full redundancy elimination 6715 6716 This is a simpler form of PRE that only eliminates redundancies 6717 that occur an all paths. It is located in `tree-ssa-pre.c' and 6718 described by `pass_fre'. 6719 6720 * Loop optimization 6721 6722 The main driver of the pass is placed in `tree-ssa-loop.c' and 6723 described by `pass_loop'. 6724 6725 The optimizations performed by this pass are: 6726 6727 Loop invariant motion. This pass moves only invariants that would 6728 be hard to handle on RTL level (function calls, operations that 6729 expand to nontrivial sequences of insns). With `-funswitch-loops' 6730 it also moves operands of conditions that are invariant out of the 6731 loop, so that we can use just trivial invariantness analysis in 6732 loop unswitching. The pass also includes store motion. The pass 6733 is implemented in `tree-ssa-loop-im.c'. 6734 6735 Canonical induction variable creation. This pass creates a simple 6736 counter for number of iterations of the loop and replaces the exit 6737 condition of the loop using it, in case when a complicated 6738 analysis is necessary to determine the number of iterations. 6739 Later optimizations then may determine the number easily. The 6740 pass is implemented in `tree-ssa-loop-ivcanon.c'. 6741 6742 Induction variable optimizations. This pass performs standard 6743 induction variable optimizations, including strength reduction, 6744 induction variable merging and induction variable elimination. 6745 The pass is implemented in `tree-ssa-loop-ivopts.c'. 6746 6747 Loop unswitching. This pass moves the conditional jumps that are 6748 invariant out of the loops. To achieve this, a duplicate of the 6749 loop is created for each possible outcome of conditional jump(s). 6750 The pass is implemented in `tree-ssa-loop-unswitch.c'. This pass 6751 should eventually replace the RTL level loop unswitching in 6752 `loop-unswitch.c', but currently the RTL level pass is not 6753 completely redundant yet due to deficiencies in tree level alias 6754 analysis. 6755 6756 The optimizations also use various utility functions contained in 6757 `tree-ssa-loop-manip.c', `cfgloop.c', `cfgloopanal.c' and 6758 `cfgloopmanip.c'. 6759 6760 Vectorization. This pass transforms loops to operate on vector 6761 types instead of scalar types. Data parallelism across loop 6762 iterations is exploited to group data elements from consecutive 6763 iterations into a vector and operate on them in parallel. 6764 Depending on available target support the loop is conceptually 6765 unrolled by a factor `VF' (vectorization factor), which is the 6766 number of elements operated upon in parallel in each iteration, 6767 and the `VF' copies of each scalar operation are fused to form a 6768 vector operation. Additional loop transformations such as peeling 6769 and versioning may take place to align the number of iterations, 6770 and to align the memory accesses in the loop. The pass is 6771 implemented in `tree-vectorizer.c' (the main driver), 6772 `tree-vect-loop.c' and `tree-vect-loop-manip.c' (loop specific 6773 parts and general loop utilities), `tree-vect-slp' (loop-aware SLP 6774 functionality), `tree-vect-stmts.c' and `tree-vect-data-refs.c'. 6775 Analysis of data references is in `tree-data-ref.c'. 6776 6777 SLP Vectorization. This pass performs vectorization of 6778 straight-line code. The pass is implemented in `tree-vectorizer.c' 6779 (the main driver), `tree-vect-slp.c', `tree-vect-stmts.c' and 6780 `tree-vect-data-refs.c'. 6781 6782 Autoparallelization. This pass splits the loop iteration space to 6783 run into several threads. The pass is implemented in 6784 `tree-parloops.c'. 6785 6786 Graphite is a loop transformation framework based on the polyhedral 6787 model. Graphite stands for Gimple Represented as Polyhedra. The 6788 internals of this infrastructure are documented in 6789 `http://gcc.gnu.org/wiki/Graphite'. The passes working on this 6790 representation are implemented in the various `graphite-*' files. 6791 6792 * Tree level if-conversion for vectorizer 6793 6794 This pass applies if-conversion to simple loops to help vectorizer. 6795 We identify if convertible loops, if-convert statements and merge 6796 basic blocks in one big block. The idea is to present loop in such 6797 form so that vectorizer can have one to one mapping between 6798 statements and available vector operations. This pass is located 6799 in `tree-if-conv.c' and is described by `pass_if_conversion'. 6800 6801 * Conditional constant propagation 6802 6803 This pass relaxes a lattice of values in order to identify those 6804 that must be constant even in the presence of conditional branches. 6805 The pass is located in `tree-ssa-ccp.c' and is described by 6806 `pass_ccp'. 6807 6808 A related pass that works on memory loads and stores, and not just 6809 register values, is located in `tree-ssa-ccp.c' and described by 6810 `pass_store_ccp'. 6811 6812 * Conditional copy propagation 6813 6814 This is similar to constant propagation but the lattice of values 6815 is the "copy-of" relation. It eliminates redundant copies from the 6816 code. The pass is located in `tree-ssa-copy.c' and described by 6817 `pass_copy_prop'. 6818 6819 A related pass that works on memory copies, and not just register 6820 copies, is located in `tree-ssa-copy.c' and described by 6821 `pass_store_copy_prop'. 6822 6823 * Value range propagation 6824 6825 This transformation is similar to constant propagation but instead 6826 of propagating single constant values, it propagates known value 6827 ranges. The implementation is based on Patterson's range 6828 propagation algorithm (Accurate Static Branch Prediction by Value 6829 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 6830 Patterson's algorithm, this implementation does not propagate 6831 branch probabilities nor it uses more than a single range per SSA 6832 name. This means that the current implementation cannot be used 6833 for branch prediction (though adapting it would not be difficult). 6834 The pass is located in `tree-vrp.c' and is described by `pass_vrp'. 6835 6836 * Folding built-in functions 6837 6838 This pass simplifies built-in functions, as applicable, with 6839 constant arguments or with inferable string lengths. It is 6840 located in `tree-ssa-ccp.c' and is described by 6841 `pass_fold_builtins'. 6842 6843 * Split critical edges 6844 6845 This pass identifies critical edges and inserts empty basic blocks 6846 such that the edge is no longer critical. The pass is located in 6847 `tree-cfg.c' and is described by `pass_split_crit_edges'. 6848 6849 * Control dependence dead code elimination 6850 6851 This pass is a stronger form of dead code elimination that can 6852 eliminate unnecessary control flow statements. It is located in 6853 `tree-ssa-dce.c' and is described by `pass_cd_dce'. 6854 6855 * Tail call elimination 6856 6857 This pass identifies function calls that may be rewritten into 6858 jumps. No code transformation is actually applied here, but the 6859 data and control flow problem is solved. The code transformation 6860 requires target support, and so is delayed until RTL. In the 6861 meantime `CALL_EXPR_TAILCALL' is set indicating the possibility. 6862 The pass is located in `tree-tailcall.c' and is described by 6863 `pass_tail_calls'. The RTL transformation is handled by 6864 `fixup_tail_calls' in `calls.c'. 6865 6866 * Warn for function return without value 6867 6868 For non-void functions, this pass locates return statements that do 6869 not specify a value and issues a warning. Such a statement may 6870 have been injected by falling off the end of the function. This 6871 pass is run last so that we have as much time as possible to prove 6872 that the statement is not reachable. It is located in 6873 `tree-cfg.c' and is described by `pass_warn_function_return'. 6874 6875 * Mudflap statement annotation 6876 6877 If mudflap is enabled, we rewrite some memory accesses with code to 6878 validate that the memory access is correct. In particular, 6879 expressions involving pointer dereferences (`INDIRECT_REF', 6880 `ARRAY_REF', etc.) are replaced by code that checks the selected 6881 address range against the mudflap runtime's database of valid 6882 regions. This check includes an inline lookup into a 6883 direct-mapped cache, based on shift/mask operations of the pointer 6884 value, with a fallback function call into the runtime. The pass 6885 is located in `tree-mudflap.c' and is described by 6886 `pass_mudflap_2'. 6887 6888 * Leave static single assignment form 6889 6890 This pass rewrites the function such that it is in normal form. At 6891 the same time, we eliminate as many single-use temporaries as 6892 possible, so the intermediate language is no longer GIMPLE, but 6893 GENERIC. The pass is located in `tree-outof-ssa.c' and is 6894 described by `pass_del_ssa'. 6895 6896 * Merge PHI nodes that feed into one another 6897 6898 This is part of the CFG cleanup passes. It attempts to join PHI 6899 nodes from a forwarder CFG block into another block with PHI 6900 nodes. The pass is located in `tree-cfgcleanup.c' and is 6901 described by `pass_merge_phi'. 6902 6903 * Return value optimization 6904 6905 If a function always returns the same local variable, and that 6906 local variable is an aggregate type, then the variable is replaced 6907 with the return value for the function (i.e., the function's 6908 DECL_RESULT). This is equivalent to the C++ named return value 6909 optimization applied to GIMPLE. The pass is located in 6910 `tree-nrv.c' and is described by `pass_nrv'. 6911 6912 * Return slot optimization 6913 6914 If a function returns a memory object and is called as `var = 6915 foo()', this pass tries to change the call so that the address of 6916 `var' is sent to the caller to avoid an extra memory copy. This 6917 pass is located in `tree-nrv.c' and is described by 6918 `pass_return_slot'. 6919 6920 * Optimize calls to `__builtin_object_size' 6921 6922 This is a propagation pass similar to CCP that tries to remove 6923 calls to `__builtin_object_size' when the size of the object can be 6924 computed at compile-time. This pass is located in 6925 `tree-object-size.c' and is described by `pass_object_sizes'. 6926 6927 * Loop invariant motion 6928 6929 This pass removes expensive loop-invariant computations out of 6930 loops. The pass is located in `tree-ssa-loop.c' and described by 6931 `pass_lim'. 6932 6933 * Loop nest optimizations 6934 6935 This is a family of loop transformations that works on loop nests. 6936 It includes loop interchange, scaling, skewing and reversal and 6937 they are all geared to the optimization of data locality in array 6938 traversals and the removal of dependencies that hamper 6939 optimizations such as loop parallelization and vectorization. The 6940 pass is located in `tree-loop-linear.c' and described by 6941 `pass_linear_transform'. 6942 6943 * Removal of empty loops 6944 6945 This pass removes loops with no code in them. The pass is located 6946 in `tree-ssa-loop-ivcanon.c' and described by `pass_empty_loop'. 6947 6948 * Unrolling of small loops 6949 6950 This pass completely unrolls loops with few iterations. The pass 6951 is located in `tree-ssa-loop-ivcanon.c' and described by 6952 `pass_complete_unroll'. 6953 6954 * Predictive commoning 6955 6956 This pass makes the code reuse the computations from the previous 6957 iterations of the loops, especially loads and stores to memory. 6958 It does so by storing the values of these computations to a bank 6959 of temporary variables that are rotated at the end of loop. To 6960 avoid the need for this rotation, the loop is then unrolled and 6961 the copies of the loop body are rewritten to use the appropriate 6962 version of the temporary variable. This pass is located in 6963 `tree-predcom.c' and described by `pass_predcom'. 6964 6965 * Array prefetching 6966 6967 This pass issues prefetch instructions for array references inside 6968 loops. The pass is located in `tree-ssa-loop-prefetch.c' and 6969 described by `pass_loop_prefetch'. 6970 6971 * Reassociation 6972 6973 This pass rewrites arithmetic expressions to enable optimizations 6974 that operate on them, like redundancy elimination and 6975 vectorization. The pass is located in `tree-ssa-reassoc.c' and 6976 described by `pass_reassoc'. 6977 6978 * Optimization of `stdarg' functions 6979 6980 This pass tries to avoid the saving of register arguments into the 6981 stack on entry to `stdarg' functions. If the function doesn't use 6982 any `va_start' macros, no registers need to be saved. If 6983 `va_start' macros are used, the `va_list' variables don't escape 6984 the function, it is only necessary to save registers that will be 6985 used in `va_arg' macros. For instance, if `va_arg' is only used 6986 with integral types in the function, floating point registers 6987 don't need to be saved. This pass is located in `tree-stdarg.c' 6988 and described by `pass_stdarg'. 6989 6990 6991 6992 File: gccint.info, Node: RTL passes, Prev: Tree SSA passes, Up: Passes 6993 6994 9.5 RTL passes 6995 ============== 6996 6997 The following briefly describes the RTL generation and optimization 6998 passes that are run after the Tree optimization passes. 6999 7000 * RTL generation 7001 7002 The source files for RTL generation include `stmt.c', `calls.c', 7003 `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and 7004 `emit-rtl.c'. Also, the file `insn-emit.c', generated from the 7005 machine description by the program `genemit', is used in this 7006 pass. The header file `expr.h' is used for communication within 7007 this pass. 7008 7009 The header files `insn-flags.h' and `insn-codes.h', generated from 7010 the machine description by the programs `genflags' and `gencodes', 7011 tell this pass which standard names are available for use and 7012 which patterns correspond to them. 7013 7014 * Generation of exception landing pads 7015 7016 This pass generates the glue that handles communication between the 7017 exception handling library routines and the exception handlers 7018 within the function. Entry points in the function that are 7019 invoked by the exception handling library are called "landing 7020 pads". The code for this pass is located in `except.c'. 7021 7022 * Control flow graph cleanup 7023 7024 This pass removes unreachable code, simplifies jumps to next, 7025 jumps to jump, jumps across jumps, etc. The pass is run multiple 7026 times. For historical reasons, it is occasionally referred to as 7027 the "jump optimization pass". The bulk of the code for this pass 7028 is in `cfgcleanup.c', and there are support routines in `cfgrtl.c' 7029 and `jump.c'. 7030 7031 * Forward propagation of single-def values 7032 7033 This pass attempts to remove redundant computation by substituting 7034 variables that come from a single definition, and seeing if the 7035 result can be simplified. It performs copy propagation and 7036 addressing mode selection. The pass is run twice, with values 7037 being propagated into loops only on the second run. The code is 7038 located in `fwprop.c'. 7039 7040 * Common subexpression elimination 7041 7042 This pass removes redundant computation within basic blocks, and 7043 optimizes addressing modes based on cost. The pass is run twice. 7044 The code for this pass is located in `cse.c'. 7045 7046 * Global common subexpression elimination 7047 7048 This pass performs two different types of GCSE depending on 7049 whether you are optimizing for size or not (LCM based GCSE tends 7050 to increase code size for a gain in speed, while Morel-Renvoise 7051 based GCSE does not). When optimizing for size, GCSE is done 7052 using Morel-Renvoise Partial Redundancy Elimination, with the 7053 exception that it does not try to move invariants out of 7054 loops--that is left to the loop optimization pass. If MR PRE 7055 GCSE is done, code hoisting (aka unification) is also done, as 7056 well as load motion. If you are optimizing for speed, LCM (lazy 7057 code motion) based GCSE is done. LCM is based on the work of 7058 Knoop, Ruthing, and Steffen. LCM based GCSE also does loop 7059 invariant code motion. We also perform load and store motion when 7060 optimizing for speed. Regardless of which type of GCSE is used, 7061 the GCSE pass also performs global constant and copy propagation. 7062 The source file for this pass is `gcse.c', and the LCM routines 7063 are in `lcm.c'. 7064 7065 * Loop optimization 7066 7067 This pass performs several loop related optimizations. The source 7068 files `cfgloopanal.c' and `cfgloopmanip.c' contain generic loop 7069 analysis and manipulation code. Initialization and finalization 7070 of loop structures is handled by `loop-init.c'. A loop invariant 7071 motion pass is implemented in `loop-invariant.c'. Basic block 7072 level optimizations--unrolling, peeling and unswitching loops-- 7073 are implemented in `loop-unswitch.c' and `loop-unroll.c'. 7074 Replacing of the exit condition of loops by special 7075 machine-dependent instructions is handled by `loop-doloop.c'. 7076 7077 * Jump bypassing 7078 7079 This pass is an aggressive form of GCSE that transforms the control 7080 flow graph of a function by propagating constants into conditional 7081 branch instructions. The source file for this pass is `gcse.c'. 7082 7083 * If conversion 7084 7085 This pass attempts to replace conditional branches and surrounding 7086 assignments with arithmetic, boolean value producing comparison 7087 instructions, and conditional move instructions. In the very last 7088 invocation after reload, it will generate predicated instructions 7089 when supported by the target. The code is located in `ifcvt.c'. 7090 7091 * Web construction 7092 7093 This pass splits independent uses of each pseudo-register. This 7094 can improve effect of the other transformation, such as CSE or 7095 register allocation. The code for this pass is located in `web.c'. 7096 7097 * Instruction combination 7098 7099 This pass attempts to combine groups of two or three instructions 7100 that are related by data flow into single instructions. It 7101 combines the RTL expressions for the instructions by substitution, 7102 simplifies the result using algebra, and then attempts to match 7103 the result against the machine description. The code is located 7104 in `combine.c'. 7105 7106 * Register movement 7107 7108 This pass looks for cases where matching constraints would force an 7109 instruction to need a reload, and this reload would be a 7110 register-to-register move. It then attempts to change the 7111 registers used by the instruction to avoid the move instruction. 7112 The code is located in `regmove.c'. 7113 7114 * Mode switching optimization 7115 7116 This pass looks for instructions that require the processor to be 7117 in a specific "mode" and minimizes the number of mode changes 7118 required to satisfy all users. What these modes are, and what 7119 they apply to are completely target-specific. The code for this 7120 pass is located in `mode-switching.c'. 7121 7122 * Modulo scheduling 7123 7124 This pass looks at innermost loops and reorders their instructions 7125 by overlapping different iterations. Modulo scheduling is 7126 performed immediately before instruction scheduling. The code for 7127 this pass is located in `modulo-sched.c'. 7128 7129 * Instruction scheduling 7130 7131 This pass looks for instructions whose output will not be 7132 available by the time that it is used in subsequent instructions. 7133 Memory loads and floating point instructions often have this 7134 behavior on RISC machines. It re-orders instructions within a 7135 basic block to try to separate the definition and use of items 7136 that otherwise would cause pipeline stalls. This pass is 7137 performed twice, before and after register allocation. The code 7138 for this pass is located in `haifa-sched.c', `sched-deps.c', 7139 `sched-ebb.c', `sched-rgn.c' and `sched-vis.c'. 7140 7141 * Register allocation 7142 7143 These passes make sure that all occurrences of pseudo registers are 7144 eliminated, either by allocating them to a hard register, replacing 7145 them by an equivalent expression (e.g. a constant) or by placing 7146 them on the stack. This is done in several subpasses: 7147 7148 * Register move optimizations. This pass makes some simple RTL 7149 code transformations which improve the subsequent register 7150 allocation. The source file is `regmove.c'. 7151 7152 * The integrated register allocator (IRA). It is called 7153 integrated because coalescing, register live range splitting, 7154 and hard register preferencing are done on-the-fly during 7155 coloring. It also has better integration with the reload 7156 pass. Pseudo-registers spilled by the allocator or the 7157 reload have still a chance to get hard-registers if the 7158 reload evicts some pseudo-registers from hard-registers. The 7159 allocator helps to choose better pseudos for spilling based 7160 on their live ranges and to coalesce stack slots allocated 7161 for the spilled pseudo-registers. IRA is a regional register 7162 allocator which is transformed into Chaitin-Briggs allocator 7163 if there is one region. By default, IRA chooses regions using 7164 register pressure but the user can force it to use one region 7165 or regions corresponding to all loops. 7166 7167 Source files of the allocator are `ira.c', `ira-build.c', 7168 `ira-costs.c', `ira-conflicts.c', `ira-color.c', 7169 `ira-emit.c', `ira-lives', plus header files `ira.h' and 7170 `ira-int.h' used for the communication between the allocator 7171 and the rest of the compiler and between the IRA files. 7172 7173 * Reloading. This pass renumbers pseudo registers with the 7174 hardware registers numbers they were allocated. Pseudo 7175 registers that did not get hard registers are replaced with 7176 stack slots. Then it finds instructions that are invalid 7177 because a value has failed to end up in a register, or has 7178 ended up in a register of the wrong kind. It fixes up these 7179 instructions by reloading the problematical values 7180 temporarily into registers. Additional instructions are 7181 generated to do the copying. 7182 7183 The reload pass also optionally eliminates the frame pointer 7184 and inserts instructions to save and restore call-clobbered 7185 registers around calls. 7186 7187 Source files are `reload.c' and `reload1.c', plus the header 7188 `reload.h' used for communication between them. 7189 7190 * Basic block reordering 7191 7192 This pass implements profile guided code positioning. If profile 7193 information is not available, various types of static analysis are 7194 performed to make the predictions normally coming from the profile 7195 feedback (IE execution frequency, branch probability, etc). It is 7196 implemented in the file `bb-reorder.c', and the various prediction 7197 routines are in `predict.c'. 7198 7199 * Variable tracking 7200 7201 This pass computes where the variables are stored at each position 7202 in code and generates notes describing the variable locations to 7203 RTL code. The location lists are then generated according to these 7204 notes to debug information if the debugging information format 7205 supports location lists. The code is located in `var-tracking.c'. 7206 7207 * Delayed branch scheduling 7208 7209 This optional pass attempts to find instructions that can go into 7210 the delay slots of other instructions, usually jumps and calls. 7211 The code for this pass is located in `reorg.c'. 7212 7213 * Branch shortening 7214 7215 On many RISC machines, branch instructions have a limited range. 7216 Thus, longer sequences of instructions must be used for long 7217 branches. In this pass, the compiler figures out what how far 7218 each instruction will be from each other instruction, and 7219 therefore whether the usual instructions, or the longer sequences, 7220 must be used for each branch. The code for this pass is located 7221 in `final.c'. 7222 7223 * Register-to-stack conversion 7224 7225 Conversion from usage of some hard registers to usage of a register 7226 stack may be done at this point. Currently, this is supported only 7227 for the floating-point registers of the Intel 80387 coprocessor. 7228 The code for this pass is located in `reg-stack.c'. 7229 7230 * Final 7231 7232 This pass outputs the assembler code for the function. The source 7233 files are `final.c' plus `insn-output.c'; the latter is generated 7234 automatically from the machine description by the tool `genoutput'. 7235 The header file `conditions.h' is used for communication between 7236 these files. If mudflap is enabled, the queue of deferred 7237 declarations and any addressed constants (e.g., string literals) 7238 is processed by `mudflap_finish_file' into a synthetic constructor 7239 function containing calls into the mudflap runtime. 7240 7241 * Debugging information output 7242 7243 This is run after final because it must output the stack slot 7244 offsets for pseudo registers that did not get hard registers. 7245 Source files are `dbxout.c' for DBX symbol table format, 7246 `sdbout.c' for SDB symbol table format, `dwarfout.c' for DWARF 7247 symbol table format, files `dwarf2out.c' and `dwarf2asm.c' for 7248 DWARF2 symbol table format, and `vmsdbgout.c' for VMS debug symbol 7249 table format. 7250 7251 7252 7253 File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 7254 7255 10 RTL Representation 7256 ********************* 7257 7258 The last part of the compiler work is done on a low-level intermediate 7259 representation called Register Transfer Language. In this language, the 7260 instructions to be output are described, pretty much one by one, in an 7261 algebraic form that describes what the instruction does. 7262 7263 RTL is inspired by Lisp lists. It has both an internal form, made up 7264 of structures that point at other structures, and a textual form that 7265 is used in the machine description and in printed debugging dumps. The 7266 textual form uses nested parentheses to indicate the pointers in the 7267 internal form. 7268 7269 * Menu: 7270 7271 * RTL Objects:: Expressions vs vectors vs strings vs integers. 7272 * RTL Classes:: Categories of RTL expression objects, and their structure. 7273 * Accessors:: Macros to access expression operands or vector elts. 7274 * Special Accessors:: Macros to access specific annotations on RTL. 7275 * Flags:: Other flags in an RTL expression. 7276 * Machine Modes:: Describing the size and format of a datum. 7277 * Constants:: Expressions with constant values. 7278 * Regs and Memory:: Expressions representing register contents or memory. 7279 * Arithmetic:: Expressions representing arithmetic on other expressions. 7280 * Comparisons:: Expressions representing comparison of expressions. 7281 * Bit-Fields:: Expressions representing bit-fields in memory or reg. 7282 * Vector Operations:: Expressions involving vector datatypes. 7283 * Conversions:: Extending, truncating, floating or fixing. 7284 * RTL Declarations:: Declaring volatility, constancy, etc. 7285 * Side Effects:: Expressions for storing in registers, etc. 7286 * Incdec:: Embedded side-effects for autoincrement addressing. 7287 * Assembler:: Representing `asm' with operands. 7288 * Debug Information:: Expressions representing debugging information. 7289 * Insns:: Expression types for entire insns. 7290 * Calls:: RTL representation of function call insns. 7291 * Sharing:: Some expressions are unique; others *must* be copied. 7292 * Reading RTL:: Reading textual RTL from a file. 7293 7294 7295 File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 7296 7297 10.1 RTL Object Types 7298 ===================== 7299 7300 RTL uses five kinds of objects: expressions, integers, wide integers, 7301 strings and vectors. Expressions are the most important ones. An RTL 7302 expression ("RTX", for short) is a C structure, but it is usually 7303 referred to with a pointer; a type that is given the typedef name `rtx'. 7304 7305 An integer is simply an `int'; their written form uses decimal digits. 7306 A wide integer is an integral object whose type is `HOST_WIDE_INT'; 7307 their written form uses decimal digits. 7308 7309 A string is a sequence of characters. In core it is represented as a 7310 `char *' in usual C fashion, and it is written in C syntax as well. 7311 However, strings in RTL may never be null. If you write an empty 7312 string in a machine description, it is represented in core as a null 7313 pointer rather than as a pointer to a null character. In certain 7314 contexts, these null pointers instead of strings are valid. Within RTL 7315 code, strings are most commonly found inside `symbol_ref' expressions, 7316 but they appear in other contexts in the RTL expressions that make up 7317 machine descriptions. 7318 7319 In a machine description, strings are normally written with double 7320 quotes, as you would in C. However, strings in machine descriptions may 7321 extend over many lines, which is invalid C, and adjacent string 7322 constants are not concatenated as they are in C. Any string constant 7323 may be surrounded with a single set of parentheses. Sometimes this 7324 makes the machine description easier to read. 7325 7326 There is also a special syntax for strings, which can be useful when C 7327 code is embedded in a machine description. Wherever a string can 7328 appear, it is also valid to write a C-style brace block. The entire 7329 brace block, including the outermost pair of braces, is considered to be 7330 the string constant. Double quote characters inside the braces are not 7331 special. Therefore, if you write string constants in the C code, you 7332 need not escape each quote character with a backslash. 7333 7334 A vector contains an arbitrary number of pointers to expressions. The 7335 number of elements in the vector is explicitly present in the vector. 7336 The written form of a vector consists of square brackets (`[...]') 7337 surrounding the elements, in sequence and with whitespace separating 7338 them. Vectors of length zero are not created; null pointers are used 7339 instead. 7340 7341 Expressions are classified by "expression codes" (also called RTX 7342 codes). The expression code is a name defined in `rtl.def', which is 7343 also (in uppercase) a C enumeration constant. The possible expression 7344 codes and their meanings are machine-independent. The code of an RTX 7345 can be extracted with the macro `GET_CODE (X)' and altered with 7346 `PUT_CODE (X, NEWCODE)'. 7347 7348 The expression code determines how many operands the expression 7349 contains, and what kinds of objects they are. In RTL, unlike Lisp, you 7350 cannot tell by looking at an operand what kind of object it is. 7351 Instead, you must know from its context--from the expression code of 7352 the containing expression. For example, in an expression of code 7353 `subreg', the first operand is to be regarded as an expression and the 7354 second operand as an integer. In an expression of code `plus', there 7355 are two operands, both of which are to be regarded as expressions. In 7356 a `symbol_ref' expression, there is one operand, which is to be 7357 regarded as a string. 7358 7359 Expressions are written as parentheses containing the name of the 7360 expression type, its flags and machine mode if any, and then the 7361 operands of the expression (separated by spaces). 7362 7363 Expression code names in the `md' file are written in lowercase, but 7364 when they appear in C code they are written in uppercase. In this 7365 manual, they are shown as follows: `const_int'. 7366 7367 In a few contexts a null pointer is valid where an expression is 7368 normally wanted. The written form of this is `(nil)'. 7369 7370 7371 File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 7372 7373 10.2 RTL Classes and Formats 7374 ============================ 7375 7376 The various expression codes are divided into several "classes", which 7377 are represented by single characters. You can determine the class of 7378 an RTX code with the macro `GET_RTX_CLASS (CODE)'. Currently, 7379 `rtl.def' defines these classes: 7380 7381 `RTX_OBJ' 7382 An RTX code that represents an actual object, such as a register 7383 (`REG') or a memory location (`MEM', `SYMBOL_REF'). `LO_SUM') is 7384 also included; instead, `SUBREG' and `STRICT_LOW_PART' are not in 7385 this class, but in class `x'. 7386 7387 `RTX_CONST_OBJ' 7388 An RTX code that represents a constant object. `HIGH' is also 7389 included in this class. 7390 7391 `RTX_COMPARE' 7392 An RTX code for a non-symmetric comparison, such as `GEU' or `LT'. 7393 7394 `RTX_COMM_COMPARE' 7395 An RTX code for a symmetric (commutative) comparison, such as `EQ' 7396 or `ORDERED'. 7397 7398 `RTX_UNARY' 7399 An RTX code for a unary arithmetic operation, such as `NEG', 7400 `NOT', or `ABS'. This category also includes value extension 7401 (sign or zero) and conversions between integer and floating point. 7402 7403 `RTX_COMM_ARITH' 7404 An RTX code for a commutative binary operation, such as `PLUS' or 7405 `AND'. `NE' and `EQ' are comparisons, so they have class `<'. 7406 7407 `RTX_BIN_ARITH' 7408 An RTX code for a non-commutative binary operation, such as 7409 `MINUS', `DIV', or `ASHIFTRT'. 7410 7411 `RTX_BITFIELD_OPS' 7412 An RTX code for a bit-field operation. Currently only 7413 `ZERO_EXTRACT' and `SIGN_EXTRACT'. These have three inputs and 7414 are lvalues (so they can be used for insertion as well). *Note 7415 Bit-Fields::. 7416 7417 `RTX_TERNARY' 7418 An RTX code for other three input operations. Currently only 7419 `IF_THEN_ELSE', `VEC_MERGE', `SIGN_EXTRACT', `ZERO_EXTRACT', and 7420 `FMA'. 7421 7422 `RTX_INSN' 7423 An RTX code for an entire instruction: `INSN', `JUMP_INSN', and 7424 `CALL_INSN'. *Note Insns::. 7425 7426 `RTX_MATCH' 7427 An RTX code for something that matches in insns, such as 7428 `MATCH_DUP'. These only occur in machine descriptions. 7429 7430 `RTX_AUTOINC' 7431 An RTX code for an auto-increment addressing mode, such as 7432 `POST_INC'. 7433 7434 `RTX_EXTRA' 7435 All other RTX codes. This category includes the remaining codes 7436 used only in machine descriptions (`DEFINE_*', etc.). It also 7437 includes all the codes describing side effects (`SET', `USE', 7438 `CLOBBER', etc.) and the non-insns that may appear on an insn 7439 chain, such as `NOTE', `BARRIER', and `CODE_LABEL'. `SUBREG' is 7440 also part of this class. 7441 7442 For each expression code, `rtl.def' specifies the number of contained 7443 objects and their kinds using a sequence of characters called the 7444 "format" of the expression code. For example, the format of `subreg' 7445 is `ei'. 7446 7447 These are the most commonly used format characters: 7448 7449 `e' 7450 An expression (actually a pointer to an expression). 7451 7452 `i' 7453 An integer. 7454 7455 `w' 7456 A wide integer. 7457 7458 `s' 7459 A string. 7460 7461 `E' 7462 A vector of expressions. 7463 7464 A few other format characters are used occasionally: 7465 7466 `u' 7467 `u' is equivalent to `e' except that it is printed differently in 7468 debugging dumps. It is used for pointers to insns. 7469 7470 `n' 7471 `n' is equivalent to `i' except that it is printed differently in 7472 debugging dumps. It is used for the line number or code number of 7473 a `note' insn. 7474 7475 `S' 7476 `S' indicates a string which is optional. In the RTL objects in 7477 core, `S' is equivalent to `s', but when the object is read, from 7478 an `md' file, the string value of this operand may be omitted. An 7479 omitted string is taken to be the null string. 7480 7481 `V' 7482 `V' indicates a vector which is optional. In the RTL objects in 7483 core, `V' is equivalent to `E', but when the object is read from 7484 an `md' file, the vector value of this operand may be omitted. An 7485 omitted vector is effectively the same as a vector of no elements. 7486 7487 `B' 7488 `B' indicates a pointer to basic block structure. 7489 7490 `0' 7491 `0' means a slot whose contents do not fit any normal category. 7492 `0' slots are not printed at all in dumps, and are often used in 7493 special ways by small parts of the compiler. 7494 7495 There are macros to get the number of operands and the format of an 7496 expression code: 7497 7498 `GET_RTX_LENGTH (CODE)' 7499 Number of operands of an RTX of code CODE. 7500 7501 `GET_RTX_FORMAT (CODE)' 7502 The format of an RTX of code CODE, as a C string. 7503 7504 Some classes of RTX codes always have the same format. For example, it 7505 is safe to assume that all comparison operations have format `ee'. 7506 7507 `1' 7508 All codes of this class have format `e'. 7509 7510 `<' 7511 `c' 7512 `2' 7513 All codes of these classes have format `ee'. 7514 7515 `b' 7516 `3' 7517 All codes of these classes have format `eee'. 7518 7519 `i' 7520 All codes of this class have formats that begin with `iuueiee'. 7521 *Note Insns::. Note that not all RTL objects linked onto an insn 7522 chain are of class `i'. 7523 7524 `o' 7525 `m' 7526 `x' 7527 You can make no assumptions about the format of these codes. 7528 7529 7530 File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 7531 7532 10.3 Access to Operands 7533 ======================= 7534 7535 Operands of expressions are accessed using the macros `XEXP', `XINT', 7536 `XWINT' and `XSTR'. Each of these macros takes two arguments: an 7537 expression-pointer (RTX) and an operand number (counting from zero). 7538 Thus, 7539 7540 XEXP (X, 2) 7541 7542 accesses operand 2 of expression X, as an expression. 7543 7544 XINT (X, 2) 7545 7546 accesses the same operand as an integer. `XSTR', used in the same 7547 fashion, would access it as a string. 7548 7549 Any operand can be accessed as an integer, as an expression or as a 7550 string. You must choose the correct method of access for the kind of 7551 value actually stored in the operand. You would do this based on the 7552 expression code of the containing expression. That is also how you 7553 would know how many operands there are. 7554 7555 For example, if X is a `subreg' expression, you know that it has two 7556 operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, 7557 1)'. If you did `XINT (X, 0)', you would get the address of the 7558 expression operand but cast as an integer; that might occasionally be 7559 useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP 7560 (X, 1)' would also compile without error, and would return the second, 7561 integer operand cast as an expression pointer, which would probably 7562 result in a crash when accessed. Nothing stops you from writing `XEXP 7563 (X, 28)' either, but this will access memory past the end of the 7564 expression with unpredictable results. 7565 7566 Access to operands which are vectors is more complicated. You can use 7567 the macro `XVEC' to get the vector-pointer itself, or the macros 7568 `XVECEXP' and `XVECLEN' to access the elements and length of a vector. 7569 7570 `XVEC (EXP, IDX)' 7571 Access the vector-pointer which is operand number IDX in EXP. 7572 7573 `XVECLEN (EXP, IDX)' 7574 Access the length (number of elements) in the vector which is in 7575 operand number IDX in EXP. This value is an `int'. 7576 7577 `XVECEXP (EXP, IDX, ELTNUM)' 7578 Access element number ELTNUM in the vector which is in operand 7579 number IDX in EXP. This value is an RTX. 7580 7581 It is up to you to make sure that ELTNUM is not negative and is 7582 less than `XVECLEN (EXP, IDX)'. 7583 7584 All the macros defined in this section expand into lvalues and 7585 therefore can be used to assign the operands, lengths and vector 7586 elements as well as to access them. 7587 7588 7589 File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 7590 7591 10.4 Access to Special Operands 7592 =============================== 7593 7594 Some RTL nodes have special annotations associated with them. 7595 7596 `MEM' 7597 7598 `MEM_ALIAS_SET (X)' 7599 If 0, X is not in any alias set, and may alias anything. 7600 Otherwise, X can only alias `MEM's in a conflicting alias 7601 set. This value is set in a language-dependent manner in the 7602 front-end, and should not be altered in the back-end. In 7603 some front-ends, these numbers may correspond in some way to 7604 types, or other language-level entities, but they need not, 7605 and the back-end makes no such assumptions. These set 7606 numbers are tested with `alias_sets_conflict_p'. 7607 7608 `MEM_EXPR (X)' 7609 If this register is known to hold the value of some user-level 7610 declaration, this is that tree node. It may also be a 7611 `COMPONENT_REF', in which case this is some field reference, 7612 and `TREE_OPERAND (X, 0)' contains the declaration, or 7613 another `COMPONENT_REF', or null if there is no compile-time 7614 object associated with the reference. 7615 7616 `MEM_OFFSET (X)' 7617 The offset from the start of `MEM_EXPR' as a `CONST_INT' rtx. 7618 7619 `MEM_SIZE (X)' 7620 The size in bytes of the memory reference as a `CONST_INT' 7621 rtx. This is mostly relevant for `BLKmode' references as 7622 otherwise the size is implied by the mode. 7623 7624 `MEM_ALIGN (X)' 7625 The known alignment in bits of the memory reference. 7626 7627 `MEM_ADDR_SPACE (X)' 7628 The address space of the memory reference. This will 7629 commonly be zero for the generic address space. 7630 7631 `REG' 7632 7633 `ORIGINAL_REGNO (X)' 7634 This field holds the number the register "originally" had; 7635 for a pseudo register turned into a hard reg this will hold 7636 the old pseudo register number. 7637 7638 `REG_EXPR (X)' 7639 If this register is known to hold the value of some user-level 7640 declaration, this is that tree node. 7641 7642 `REG_OFFSET (X)' 7643 If this register is known to hold the value of some user-level 7644 declaration, this is the offset into that logical storage. 7645 7646 `SYMBOL_REF' 7647 7648 `SYMBOL_REF_DECL (X)' 7649 If the `symbol_ref' X was created for a `VAR_DECL' or a 7650 `FUNCTION_DECL', that tree is recorded here. If this value is 7651 null, then X was created by back end code generation routines, 7652 and there is no associated front end symbol table entry. 7653 7654 `SYMBOL_REF_DECL' may also point to a tree of class `'c'', 7655 that is, some sort of constant. In this case, the 7656 `symbol_ref' is an entry in the per-file constant pool; 7657 again, there is no associated front end symbol table entry. 7658 7659 `SYMBOL_REF_CONSTANT (X)' 7660 If `CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 7661 pool entry for X. It is null otherwise. 7662 7663 `SYMBOL_REF_DATA (X)' 7664 A field of opaque type used to store `SYMBOL_REF_DECL' or 7665 `SYMBOL_REF_CONSTANT'. 7666 7667 `SYMBOL_REF_FLAGS (X)' 7668 In a `symbol_ref', this is used to communicate various 7669 predicates about the symbol. Some of these are common enough 7670 to be computed by common code, some are specific to the 7671 target. The common bits are: 7672 7673 `SYMBOL_FLAG_FUNCTION' 7674 Set if the symbol refers to a function. 7675 7676 `SYMBOL_FLAG_LOCAL' 7677 Set if the symbol is local to this "module". See 7678 `TARGET_BINDS_LOCAL_P'. 7679 7680 `SYMBOL_FLAG_EXTERNAL' 7681 Set if this symbol is not defined in this translation 7682 unit. Note that this is not the inverse of 7683 `SYMBOL_FLAG_LOCAL'. 7684 7685 `SYMBOL_FLAG_SMALL' 7686 Set if the symbol is located in the small data section. 7687 See `TARGET_IN_SMALL_DATA_P'. 7688 7689 `SYMBOL_REF_TLS_MODEL (X)' 7690 This is a multi-bit field accessor that returns the 7691 `tls_model' to be used for a thread-local storage 7692 symbol. It returns zero for non-thread-local symbols. 7693 7694 `SYMBOL_FLAG_HAS_BLOCK_INFO' 7695 Set if the symbol has `SYMBOL_REF_BLOCK' and 7696 `SYMBOL_REF_BLOCK_OFFSET' fields. 7697 7698 `SYMBOL_FLAG_ANCHOR' 7699 Set if the symbol is used as a section anchor. "Section 7700 anchors" are symbols that have a known position within 7701 an `object_block' and that can be used to access nearby 7702 members of that block. They are used to implement 7703 `-fsection-anchors'. 7704 7705 If this flag is set, then `SYMBOL_FLAG_HAS_BLOCK_INFO' 7706 will be too. 7707 7708 Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for 7709 the target's use. 7710 7711 `SYMBOL_REF_BLOCK (X)' 7712 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the `object_block' 7713 structure to which the symbol belongs, or `NULL' if it has not 7714 been assigned a block. 7715 7716 `SYMBOL_REF_BLOCK_OFFSET (X)' 7717 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 7718 the first object in `SYMBOL_REF_BLOCK (X)'. The value is negative 7719 if X has not yet been assigned to a block, or it has not been 7720 given an offset within that block. 7721 7722 7723 File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 7724 7725 10.5 Flags in an RTL Expression 7726 =============================== 7727 7728 RTL expressions contain several flags (one-bit bit-fields) that are 7729 used in certain types of expression. Most often they are accessed with 7730 the following macros, which expand into lvalues. 7731 7732 `CONSTANT_POOL_ADDRESS_P (X)' 7733 Nonzero in a `symbol_ref' if it refers to part of the current 7734 function's constant pool. For most targets these addresses are in 7735 a `.rodata' section entirely separate from the function, but for 7736 some targets the addresses are close to the beginning of the 7737 function. In either case GCC assumes these addresses can be 7738 addressed directly, perhaps with the help of base registers. 7739 Stored in the `unchanging' field and printed as `/u'. 7740 7741 `RTL_CONST_CALL_P (X)' 7742 In a `call_insn' indicates that the insn represents a call to a 7743 const function. Stored in the `unchanging' field and printed as 7744 `/u'. 7745 7746 `RTL_PURE_CALL_P (X)' 7747 In a `call_insn' indicates that the insn represents a call to a 7748 pure function. Stored in the `return_val' field and printed as 7749 `/i'. 7750 7751 `RTL_CONST_OR_PURE_CALL_P (X)' 7752 In a `call_insn', true if `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' 7753 is true. 7754 7755 `RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 7756 In a `call_insn' indicates that the insn represents a possibly 7757 infinite looping call to a const or pure function. Stored in the 7758 `call' field and printed as `/c'. Only true if one of 7759 `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' is true. 7760 7761 `INSN_ANNULLED_BRANCH_P (X)' 7762 In a `jump_insn', `call_insn', or `insn' indicates that the branch 7763 is an annulling one. See the discussion under `sequence' below. 7764 Stored in the `unchanging' field and printed as `/u'. 7765 7766 `INSN_DELETED_P (X)' 7767 In an `insn', `call_insn', `jump_insn', `code_label', `barrier', 7768 or `note', nonzero if the insn has been deleted. Stored in the 7769 `volatil' field and printed as `/v'. 7770 7771 `INSN_FROM_TARGET_P (X)' 7772 In an `insn' or `jump_insn' or `call_insn' in a delay slot of a 7773 branch, indicates that the insn is from the target of the branch. 7774 If the branch insn has `INSN_ANNULLED_BRANCH_P' set, this insn 7775 will only be executed if the branch is taken. For annulled 7776 branches with `INSN_FROM_TARGET_P' clear, the insn will be 7777 executed only if the branch is not taken. When 7778 `INSN_ANNULLED_BRANCH_P' is not set, this insn will always be 7779 executed. Stored in the `in_struct' field and printed as `/s'. 7780 7781 `LABEL_PRESERVE_P (X)' 7782 In a `code_label' or `note', indicates that the label is 7783 referenced by code or data not visible to the RTL of a given 7784 function. Labels referenced by a non-local goto will have this 7785 bit set. Stored in the `in_struct' field and printed as `/s'. 7786 7787 `LABEL_REF_NONLOCAL_P (X)' 7788 In `label_ref' and `reg_label' expressions, nonzero if this is a 7789 reference to a non-local label. Stored in the `volatil' field and 7790 printed as `/v'. 7791 7792 `MEM_IN_STRUCT_P (X)' 7793 In `mem' expressions, nonzero for reference to an entire structure, 7794 union or array, or to a component of one. Zero for references to a 7795 scalar variable or through a pointer to a scalar. If both this 7796 flag and `MEM_SCALAR_P' are clear, then we don't know whether this 7797 `mem' is in a structure or not. Both flags should never be 7798 simultaneously set. Stored in the `in_struct' field and printed 7799 as `/s'. 7800 7801 `MEM_KEEP_ALIAS_SET_P (X)' 7802 In `mem' expressions, 1 if we should keep the alias set for this 7803 mem unchanged when we access a component. Set to 1, for example, 7804 when we are already in a non-addressable component of an aggregate. 7805 Stored in the `jump' field and printed as `/j'. 7806 7807 `MEM_SCALAR_P (X)' 7808 In `mem' expressions, nonzero for reference to a scalar known not 7809 to be a member of a structure, union, or array. Zero for such 7810 references and for indirections through pointers, even pointers 7811 pointing to scalar types. If both this flag and `MEM_IN_STRUCT_P' 7812 are clear, then we don't know whether this `mem' is in a structure 7813 or not. Both flags should never be simultaneously set. Stored in 7814 the `return_val' field and printed as `/i'. 7815 7816 `MEM_VOLATILE_P (X)' 7817 In `mem', `asm_operands', and `asm_input' expressions, nonzero for 7818 volatile memory references. Stored in the `volatil' field and 7819 printed as `/v'. 7820 7821 `MEM_NOTRAP_P (X)' 7822 In `mem', nonzero for memory references that will not trap. 7823 Stored in the `call' field and printed as `/c'. 7824 7825 `MEM_POINTER (X)' 7826 Nonzero in a `mem' if the memory reference holds a pointer. 7827 Stored in the `frame_related' field and printed as `/f'. 7828 7829 `REG_FUNCTION_VALUE_P (X)' 7830 Nonzero in a `reg' if it is the place in which this function's 7831 value is going to be returned. (This happens only in a hard 7832 register.) Stored in the `return_val' field and printed as `/i'. 7833 7834 `REG_POINTER (X)' 7835 Nonzero in a `reg' if the register holds a pointer. Stored in the 7836 `frame_related' field and printed as `/f'. 7837 7838 `REG_USERVAR_P (X)' 7839 In a `reg', nonzero if it corresponds to a variable present in the 7840 user's source code. Zero for temporaries generated internally by 7841 the compiler. Stored in the `volatil' field and printed as `/v'. 7842 7843 The same hard register may be used also for collecting the values 7844 of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero 7845 in this kind of use. 7846 7847 `RTX_FRAME_RELATED_P (X)' 7848 Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or 7849 `set' which is part of a function prologue and sets the stack 7850 pointer, sets the frame pointer, or saves a register. This flag 7851 should also be set on an instruction that sets up a temporary 7852 register to use in place of the frame pointer. Stored in the 7853 `frame_related' field and printed as `/f'. 7854 7855 In particular, on RISC targets where there are limits on the sizes 7856 of immediate constants, it is sometimes impossible to reach the 7857 register save area directly from the stack pointer. In that case, 7858 a temporary register is used that is near enough to the register 7859 save area, and the Canonical Frame Address, i.e., DWARF2's logical 7860 frame pointer, register must (temporarily) be changed to be this 7861 temporary register. So, the instruction that sets this temporary 7862 register must be marked as `RTX_FRAME_RELATED_P'. 7863 7864 If the marked instruction is overly complex (defined in terms of 7865 what `dwarf2out_frame_debug_expr' can handle), you will also have 7866 to create a `REG_FRAME_RELATED_EXPR' note and attach it to the 7867 instruction. This note should contain a simple expression of the 7868 computation performed by this instruction, i.e., one that 7869 `dwarf2out_frame_debug_expr' can handle. 7870 7871 This flag is required for exception handling support on targets 7872 with RTL prologues. 7873 7874 `MEM_READONLY_P (X)' 7875 Nonzero in a `mem', if the memory is statically allocated and 7876 read-only. 7877 7878 Read-only in this context means never modified during the lifetime 7879 of the program, not necessarily in ROM or in write-disabled pages. 7880 A common example of the later is a shared library's global offset 7881 table. This table is initialized by the runtime loader, so the 7882 memory is technically writable, but after control is transfered 7883 from the runtime loader to the application, this memory will never 7884 be subsequently modified. 7885 7886 Stored in the `unchanging' field and printed as `/u'. 7887 7888 `SCHED_GROUP_P (X)' 7889 During instruction scheduling, in an `insn', `call_insn' or 7890 `jump_insn', indicates that the previous insn must be scheduled 7891 together with this insn. This is used to ensure that certain 7892 groups of instructions will not be split up by the instruction 7893 scheduling pass, for example, `use' insns before a `call_insn' may 7894 not be separated from the `call_insn'. Stored in the `in_struct' 7895 field and printed as `/s'. 7896 7897 `SET_IS_RETURN_P (X)' 7898 For a `set', nonzero if it is for a return. Stored in the `jump' 7899 field and printed as `/j'. 7900 7901 `SIBLING_CALL_P (X)' 7902 For a `call_insn', nonzero if the insn is a sibling call. Stored 7903 in the `jump' field and printed as `/j'. 7904 7905 `STRING_POOL_ADDRESS_P (X)' 7906 For a `symbol_ref' expression, nonzero if it addresses this 7907 function's string constant pool. Stored in the `frame_related' 7908 field and printed as `/f'. 7909 7910 `SUBREG_PROMOTED_UNSIGNED_P (X)' 7911 Returns a value greater then zero for a `subreg' that has 7912 `SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 7913 kept zero-extended, zero if it is kept sign-extended, and less 7914 then zero if it is extended some other way via the `ptr_extend' 7915 instruction. Stored in the `unchanging' field and `volatil' 7916 field, printed as `/u' and `/v'. This macro may only be used to 7917 get the value it may not be used to change the value. Use 7918 `SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 7919 7920 `SUBREG_PROMOTED_UNSIGNED_SET (X)' 7921 Set the `unchanging' and `volatil' fields in a `subreg' to reflect 7922 zero, sign, or other extension. If `volatil' is zero, then 7923 `unchanging' as nonzero means zero extension and as zero means 7924 sign extension. If `volatil' is nonzero then some other type of 7925 extension was done via the `ptr_extend' instruction. 7926 7927 `SUBREG_PROMOTED_VAR_P (X)' 7928 Nonzero in a `subreg' if it was made when accessing an object that 7929 was promoted to a wider mode in accord with the `PROMOTED_MODE' 7930 machine description macro (*note Storage Layout::). In this case, 7931 the mode of the `subreg' is the declared mode of the object and 7932 the mode of `SUBREG_REG' is the mode of the register that holds 7933 the object. Promoted variables are always either sign- or 7934 zero-extended to the wider mode on every assignment. Stored in 7935 the `in_struct' field and printed as `/s'. 7936 7937 `SYMBOL_REF_USED (X)' 7938 In a `symbol_ref', indicates that X has been used. This is 7939 normally only used to ensure that X is only declared external 7940 once. Stored in the `used' field. 7941 7942 `SYMBOL_REF_WEAK (X)' 7943 In a `symbol_ref', indicates that X has been declared weak. 7944 Stored in the `return_val' field and printed as `/i'. 7945 7946 `SYMBOL_REF_FLAG (X)' 7947 In a `symbol_ref', this is used as a flag for machine-specific 7948 purposes. Stored in the `volatil' field and printed as `/v'. 7949 7950 Most uses of `SYMBOL_REF_FLAG' are historic and may be subsumed by 7951 `SYMBOL_REF_FLAGS'. Certainly use of `SYMBOL_REF_FLAGS' is 7952 mandatory if the target requires more than one bit of storage. 7953 7954 `PREFETCH_SCHEDULE_BARRIER_P (X)' 7955 In a `prefetch', indicates that the prefetch is a scheduling 7956 barrier. No other INSNs will be moved over it. Stored in the 7957 `volatil' field and printed as `/v'. 7958 7959 These are the fields to which the above macros refer: 7960 7961 `call' 7962 In a `mem', 1 means that the memory reference will not trap. 7963 7964 In a `call', 1 means that this pure or const call may possibly 7965 infinite loop. 7966 7967 In an RTL dump, this flag is represented as `/c'. 7968 7969 `frame_related' 7970 In an `insn' or `set' expression, 1 means that it is part of a 7971 function prologue and sets the stack pointer, sets the frame 7972 pointer, saves a register, or sets up a temporary register to use 7973 in place of the frame pointer. 7974 7975 In `reg' expressions, 1 means that the register holds a pointer. 7976 7977 In `mem' expressions, 1 means that the memory reference holds a 7978 pointer. 7979 7980 In `symbol_ref' expressions, 1 means that the reference addresses 7981 this function's string constant pool. 7982 7983 In an RTL dump, this flag is represented as `/f'. 7984 7985 `in_struct' 7986 In `mem' expressions, it is 1 if the memory datum referred to is 7987 all or part of a structure or array; 0 if it is (or might be) a 7988 scalar variable. A reference through a C pointer has 0 because 7989 the pointer might point to a scalar variable. This information 7990 allows the compiler to determine something about possible cases of 7991 aliasing. 7992 7993 In `reg' expressions, it is 1 if the register has its entire life 7994 contained within the test expression of some loop. 7995 7996 In `subreg' expressions, 1 means that the `subreg' is accessing an 7997 object that has had its mode promoted from a wider mode. 7998 7999 In `label_ref' expressions, 1 means that the referenced label is 8000 outside the innermost loop containing the insn in which the 8001 `label_ref' was found. 8002 8003 In `code_label' expressions, it is 1 if the label may never be 8004 deleted. This is used for labels which are the target of 8005 non-local gotos. Such a label that would have been deleted is 8006 replaced with a `note' of type `NOTE_INSN_DELETED_LABEL'. 8007 8008 In an `insn' during dead-code elimination, 1 means that the insn is 8009 dead code. 8010 8011 In an `insn' or `jump_insn' during reorg for an insn in the delay 8012 slot of a branch, 1 means that this insn is from the target of the 8013 branch. 8014 8015 In an `insn' during instruction scheduling, 1 means that this insn 8016 must be scheduled as part of a group together with the previous 8017 insn. 8018 8019 In an RTL dump, this flag is represented as `/s'. 8020 8021 `return_val' 8022 In `reg' expressions, 1 means the register contains the value to 8023 be returned by the current function. On machines that pass 8024 parameters in registers, the same register number may be used for 8025 parameters as well, but this flag is not set on such uses. 8026 8027 In `mem' expressions, 1 means the memory reference is to a scalar 8028 known not to be a member of a structure, union, or array. 8029 8030 In `symbol_ref' expressions, 1 means the referenced symbol is weak. 8031 8032 In `call' expressions, 1 means the call is pure. 8033 8034 In an RTL dump, this flag is represented as `/i'. 8035 8036 `jump' 8037 In a `mem' expression, 1 means we should keep the alias set for 8038 this mem unchanged when we access a component. 8039 8040 In a `set', 1 means it is for a return. 8041 8042 In a `call_insn', 1 means it is a sibling call. 8043 8044 In an RTL dump, this flag is represented as `/j'. 8045 8046 `unchanging' 8047 In `reg' and `mem' expressions, 1 means that the value of the 8048 expression never changes. 8049 8050 In `subreg' expressions, it is 1 if the `subreg' references an 8051 unsigned object whose mode has been promoted to a wider mode. 8052 8053 In an `insn' or `jump_insn' in the delay slot of a branch 8054 instruction, 1 means an annulling branch should be used. 8055 8056 In a `symbol_ref' expression, 1 means that this symbol addresses 8057 something in the per-function constant pool. 8058 8059 In a `call_insn' 1 means that this instruction is a call to a const 8060 function. 8061 8062 In an RTL dump, this flag is represented as `/u'. 8063 8064 `used' 8065 This flag is used directly (without an access macro) at the end of 8066 RTL generation for a function, to count the number of times an 8067 expression appears in insns. Expressions that appear more than 8068 once are copied, according to the rules for shared structure 8069 (*note Sharing::). 8070 8071 For a `reg', it is used directly (without an access macro) by the 8072 leaf register renumbering code to ensure that each register is only 8073 renumbered once. 8074 8075 In a `symbol_ref', it indicates that an external declaration for 8076 the symbol has already been written. 8077 8078 `volatil' 8079 In a `mem', `asm_operands', or `asm_input' expression, it is 1 if 8080 the memory reference is volatile. Volatile memory references may 8081 not be deleted, reordered or combined. 8082 8083 In a `symbol_ref' expression, it is used for machine-specific 8084 purposes. 8085 8086 In a `reg' expression, it is 1 if the value is a user-level 8087 variable. 0 indicates an internal compiler temporary. 8088 8089 In an `insn', 1 means the insn has been deleted. 8090 8091 In `label_ref' and `reg_label' expressions, 1 means a reference to 8092 a non-local label. 8093 8094 In `prefetch' expressions, 1 means that the containing insn is a 8095 scheduling barrier. 8096 8097 In an RTL dump, this flag is represented as `/v'. 8098 8099 8100 File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 8101 8102 10.6 Machine Modes 8103 ================== 8104 8105 A machine mode describes a size of data object and the representation 8106 used for it. In the C code, machine modes are represented by an 8107 enumeration type, `enum machine_mode', defined in `machmode.def'. Each 8108 RTL expression has room for a machine mode and so do certain kinds of 8109 tree expressions (declarations and types, to be precise). 8110 8111 In debugging dumps and machine descriptions, the machine mode of an RTL 8112 expression is written after the expression code with a colon to separate 8113 them. The letters `mode' which appear at the end of each machine mode 8114 name are omitted. For example, `(reg:SI 38)' is a `reg' expression 8115 with machine mode `SImode'. If the mode is `VOIDmode', it is not 8116 written at all. 8117 8118 Here is a table of machine modes. The term "byte" below refers to an 8119 object of `BITS_PER_UNIT' bits (*note Storage Layout::). 8120 8121 `BImode' 8122 "Bit" mode represents a single bit, for predicate registers. 8123 8124 `QImode' 8125 "Quarter-Integer" mode represents a single byte treated as an 8126 integer. 8127 8128 `HImode' 8129 "Half-Integer" mode represents a two-byte integer. 8130 8131 `PSImode' 8132 "Partial Single Integer" mode represents an integer which occupies 8133 four bytes but which doesn't really use all four. On some 8134 machines, this is the right mode to use for pointers. 8135 8136 `SImode' 8137 "Single Integer" mode represents a four-byte integer. 8138 8139 `PDImode' 8140 "Partial Double Integer" mode represents an integer which occupies 8141 eight bytes but which doesn't really use all eight. On some 8142 machines, this is the right mode to use for certain pointers. 8143 8144 `DImode' 8145 "Double Integer" mode represents an eight-byte integer. 8146 8147 `TImode' 8148 "Tetra Integer" (?) mode represents a sixteen-byte integer. 8149 8150 `OImode' 8151 "Octa Integer" (?) mode represents a thirty-two-byte integer. 8152 8153 `QFmode' 8154 "Quarter-Floating" mode represents a quarter-precision (single 8155 byte) floating point number. 8156 8157 `HFmode' 8158 "Half-Floating" mode represents a half-precision (two byte) 8159 floating point number. 8160 8161 `TQFmode' 8162 "Three-Quarter-Floating" (?) mode represents a 8163 three-quarter-precision (three byte) floating point number. 8164 8165 `SFmode' 8166 "Single Floating" mode represents a four byte floating point 8167 number. In the common case, of a processor with IEEE arithmetic 8168 and 8-bit bytes, this is a single-precision IEEE floating point 8169 number; it can also be used for double-precision (on processors 8170 with 16-bit bytes) and single-precision VAX and IBM types. 8171 8172 `DFmode' 8173 "Double Floating" mode represents an eight byte floating point 8174 number. In the common case, of a processor with IEEE arithmetic 8175 and 8-bit bytes, this is a double-precision IEEE floating point 8176 number. 8177 8178 `XFmode' 8179 "Extended Floating" mode represents an IEEE extended floating point 8180 number. This mode only has 80 meaningful bits (ten bytes). Some 8181 processors require such numbers to be padded to twelve bytes, 8182 others to sixteen; this mode is used for either. 8183 8184 `SDmode' 8185 "Single Decimal Floating" mode represents a four byte decimal 8186 floating point number (as distinct from conventional binary 8187 floating point). 8188 8189 `DDmode' 8190 "Double Decimal Floating" mode represents an eight byte decimal 8191 floating point number. 8192 8193 `TDmode' 8194 "Tetra Decimal Floating" mode represents a sixteen byte decimal 8195 floating point number all 128 of whose bits are meaningful. 8196 8197 `TFmode' 8198 "Tetra Floating" mode represents a sixteen byte floating point 8199 number all 128 of whose bits are meaningful. One common use is the 8200 IEEE quad-precision format. 8201 8202 `QQmode' 8203 "Quarter-Fractional" mode represents a single byte treated as a 8204 signed fractional number. The default format is "s.7". 8205 8206 `HQmode' 8207 "Half-Fractional" mode represents a two-byte signed fractional 8208 number. The default format is "s.15". 8209 8210 `SQmode' 8211 "Single Fractional" mode represents a four-byte signed fractional 8212 number. The default format is "s.31". 8213 8214 `DQmode' 8215 "Double Fractional" mode represents an eight-byte signed 8216 fractional number. The default format is "s.63". 8217 8218 `TQmode' 8219 "Tetra Fractional" mode represents a sixteen-byte signed 8220 fractional number. The default format is "s.127". 8221 8222 `UQQmode' 8223 "Unsigned Quarter-Fractional" mode represents a single byte 8224 treated as an unsigned fractional number. The default format is 8225 ".8". 8226 8227 `UHQmode' 8228 "Unsigned Half-Fractional" mode represents a two-byte unsigned 8229 fractional number. The default format is ".16". 8230 8231 `USQmode' 8232 "Unsigned Single Fractional" mode represents a four-byte unsigned 8233 fractional number. The default format is ".32". 8234 8235 `UDQmode' 8236 "Unsigned Double Fractional" mode represents an eight-byte unsigned 8237 fractional number. The default format is ".64". 8238 8239 `UTQmode' 8240 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 8241 fractional number. The default format is ".128". 8242 8243 `HAmode' 8244 "Half-Accumulator" mode represents a two-byte signed accumulator. 8245 The default format is "s8.7". 8246 8247 `SAmode' 8248 "Single Accumulator" mode represents a four-byte signed 8249 accumulator. The default format is "s16.15". 8250 8251 `DAmode' 8252 "Double Accumulator" mode represents an eight-byte signed 8253 accumulator. The default format is "s32.31". 8254 8255 `TAmode' 8256 "Tetra Accumulator" mode represents a sixteen-byte signed 8257 accumulator. The default format is "s64.63". 8258 8259 `UHAmode' 8260 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 8261 accumulator. The default format is "8.8". 8262 8263 `USAmode' 8264 "Unsigned Single Accumulator" mode represents a four-byte unsigned 8265 accumulator. The default format is "16.16". 8266 8267 `UDAmode' 8268 "Unsigned Double Accumulator" mode represents an eight-byte 8269 unsigned accumulator. The default format is "32.32". 8270 8271 `UTAmode' 8272 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 8273 unsigned accumulator. The default format is "64.64". 8274 8275 `CCmode' 8276 "Condition Code" mode represents the value of a condition code, 8277 which is a machine-specific set of bits used to represent the 8278 result of a comparison operation. Other machine-specific modes 8279 may also be used for the condition code. These modes are not used 8280 on machines that use `cc0' (*note Condition Code::). 8281 8282 `BLKmode' 8283 "Block" mode represents values that are aggregates to which none of 8284 the other modes apply. In RTL, only memory references can have 8285 this mode, and only if they appear in string-move or vector 8286 instructions. On machines which have no such instructions, 8287 `BLKmode' will not appear in RTL. 8288 8289 `VOIDmode' 8290 Void mode means the absence of a mode or an unspecified mode. For 8291 example, RTL expressions of code `const_int' have mode `VOIDmode' 8292 because they can be taken to have whatever mode the context 8293 requires. In debugging dumps of RTL, `VOIDmode' is expressed by 8294 the absence of any mode. 8295 8296 `QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 8297 These modes stand for a complex number represented as a pair of 8298 floating point values. The floating point values are in `QFmode', 8299 `HFmode', `SFmode', `DFmode', `XFmode', and `TFmode', respectively. 8300 8301 `CQImode, CHImode, CSImode, CDImode, CTImode, COImode' 8302 These modes stand for a complex number represented as a pair of 8303 integer values. The integer values are in `QImode', `HImode', 8304 `SImode', `DImode', `TImode', and `OImode', respectively. 8305 8306 The machine description defines `Pmode' as a C macro which expands 8307 into the machine mode used for addresses. Normally this is the mode 8308 whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. 8309 8310 The only modes which a machine description must support are `QImode', 8311 and the modes corresponding to `BITS_PER_WORD', `FLOAT_TYPE_SIZE' and 8312 `DOUBLE_TYPE_SIZE'. The compiler will attempt to use `DImode' for 8313 8-byte structures and unions, but this can be prevented by overriding 8314 the definition of `MAX_FIXED_MODE_SIZE'. Alternatively, you can have 8315 the compiler use `TImode' for 16-byte structures and unions. Likewise, 8316 you can arrange for the C type `short int' to avoid using `HImode'. 8317 8318 Very few explicit references to machine modes remain in the compiler 8319 and these few references will soon be removed. Instead, the machine 8320 modes are divided into mode classes. These are represented by the 8321 enumeration type `enum mode_class' defined in `machmode.h'. The 8322 possible mode classes are: 8323 8324 `MODE_INT' 8325 Integer modes. By default these are `BImode', `QImode', `HImode', 8326 `SImode', `DImode', `TImode', and `OImode'. 8327 8328 `MODE_PARTIAL_INT' 8329 The "partial integer" modes, `PQImode', `PHImode', `PSImode' and 8330 `PDImode'. 8331 8332 `MODE_FLOAT' 8333 Floating point modes. By default these are `QFmode', `HFmode', 8334 `TQFmode', `SFmode', `DFmode', `XFmode' and `TFmode'. 8335 8336 `MODE_DECIMAL_FLOAT' 8337 Decimal floating point modes. By default these are `SDmode', 8338 `DDmode' and `TDmode'. 8339 8340 `MODE_FRACT' 8341 Signed fractional modes. By default these are `QQmode', `HQmode', 8342 `SQmode', `DQmode' and `TQmode'. 8343 8344 `MODE_UFRACT' 8345 Unsigned fractional modes. By default these are `UQQmode', 8346 `UHQmode', `USQmode', `UDQmode' and `UTQmode'. 8347 8348 `MODE_ACCUM' 8349 Signed accumulator modes. By default these are `HAmode', 8350 `SAmode', `DAmode' and `TAmode'. 8351 8352 `MODE_UACCUM' 8353 Unsigned accumulator modes. By default these are `UHAmode', 8354 `USAmode', `UDAmode' and `UTAmode'. 8355 8356 `MODE_COMPLEX_INT' 8357 Complex integer modes. (These are not currently implemented). 8358 8359 `MODE_COMPLEX_FLOAT' 8360 Complex floating point modes. By default these are `QCmode', 8361 `HCmode', `SCmode', `DCmode', `XCmode', and `TCmode'. 8362 8363 `MODE_FUNCTION' 8364 Algol or Pascal function variables including a static chain. 8365 (These are not currently implemented). 8366 8367 `MODE_CC' 8368 Modes representing condition code values. These are `CCmode' plus 8369 any `CC_MODE' modes listed in the `MACHINE-modes.def'. *Note Jump 8370 Patterns::, also see *note Condition Code::. 8371 8372 `MODE_RANDOM' 8373 This is a catchall mode class for modes which don't fit into the 8374 above classes. Currently `VOIDmode' and `BLKmode' are in 8375 `MODE_RANDOM'. 8376 8377 Here are some C macros that relate to machine modes: 8378 8379 `GET_MODE (X)' 8380 Returns the machine mode of the RTX X. 8381 8382 `PUT_MODE (X, NEWMODE)' 8383 Alters the machine mode of the RTX X to be NEWMODE. 8384 8385 `NUM_MACHINE_MODES' 8386 Stands for the number of machine modes available on the target 8387 machine. This is one greater than the largest numeric value of any 8388 machine mode. 8389 8390 `GET_MODE_NAME (M)' 8391 Returns the name of mode M as a string. 8392 8393 `GET_MODE_CLASS (M)' 8394 Returns the mode class of mode M. 8395 8396 `GET_MODE_WIDER_MODE (M)' 8397 Returns the next wider natural mode. For example, the expression 8398 `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. 8399 8400 `GET_MODE_SIZE (M)' 8401 Returns the size in bytes of a datum of mode M. 8402 8403 `GET_MODE_BITSIZE (M)' 8404 Returns the size in bits of a datum of mode M. 8405 8406 `GET_MODE_IBIT (M)' 8407 Returns the number of integral bits of a datum of fixed-point mode 8408 M. 8409 8410 `GET_MODE_FBIT (M)' 8411 Returns the number of fractional bits of a datum of fixed-point 8412 mode M. 8413 8414 `GET_MODE_MASK (M)' 8415 Returns a bitmask containing 1 for all bits in a word that fit 8416 within mode M. This macro can only be used for modes whose 8417 bitsize is less than or equal to `HOST_BITS_PER_INT'. 8418 8419 `GET_MODE_ALIGNMENT (M)' 8420 Return the required alignment, in bits, for an object of mode M. 8421 8422 `GET_MODE_UNIT_SIZE (M)' 8423 Returns the size in bytes of the subunits of a datum of mode M. 8424 This is the same as `GET_MODE_SIZE' except in the case of complex 8425 modes. For them, the unit size is the size of the real or 8426 imaginary part. 8427 8428 `GET_MODE_NUNITS (M)' 8429 Returns the number of units contained in a mode, i.e., 8430 `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. 8431 8432 `GET_CLASS_NARROWEST_MODE (C)' 8433 Returns the narrowest mode in mode class C. 8434 8435 The global variables `byte_mode' and `word_mode' contain modes whose 8436 classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or 8437 `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' 8438 and `SImode', respectively. 8439 8440 8441 File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 8442 8443 10.7 Constant Expression Types 8444 ============================== 8445 8446 The simplest RTL expressions are those that represent constant values. 8447 8448 `(const_int I)' 8449 This type of expression represents the integer value I. I is 8450 customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', 8451 which is equivalent to `XWINT (EXP, 0)'. 8452 8453 Constants generated for modes with fewer bits than `HOST_WIDE_INT' 8454 must be sign extended to full width (e.g., with `gen_int_mode'). 8455 8456 There is only one expression object for the integer value zero; it 8457 is the value of the variable `const0_rtx'. Likewise, the only 8458 expression for integer value one is found in `const1_rtx', the only 8459 expression for integer value two is found in `const2_rtx', and the 8460 only expression for integer value negative one is found in 8461 `constm1_rtx'. Any attempt to create an expression of code 8462 `const_int' and value zero, one, two or negative one will return 8463 `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as 8464 appropriate. 8465 8466 Similarly, there is only one object for the integer whose value is 8467 `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If 8468 `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will 8469 point to the same object. If `STORE_FLAG_VALUE' is -1, 8470 `const_true_rtx' and `constm1_rtx' will point to the same object. 8471 8472 `(const_double:M I0 I1 ...)' 8473 Represents either a floating-point constant of mode M or an 8474 integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' 8475 bits but small enough to fit within twice that number of bits (GCC 8476 does not provide a mechanism to represent even larger constants). 8477 In the latter case, M will be `VOIDmode'. 8478 8479 If M is `VOIDmode', the bits of the value are stored in I0 and I1. 8480 I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and 8481 I1 with `CONST_DOUBLE_HIGH'. 8482 8483 If the constant is floating point (regardless of its precision), 8484 then the number of integers used to store the value depends on the 8485 size of `REAL_VALUE_TYPE' (*note Floating Point::). The integers 8486 represent a floating point number, but not precisely in the target 8487 machine's or host machine's floating point format. To convert 8488 them to the precise bit pattern used by the target machine, use 8489 the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 8490 Output::). 8491 8492 `(const_fixed:M ...)' 8493 Represents a fixed-point constant of mode M. The operand is a 8494 data structure of type `struct fixed_value' and is accessed with 8495 the macro `CONST_FIXED_VALUE'. The high part of data is accessed 8496 with `CONST_FIXED_VALUE_HIGH'; the low part is accessed with 8497 `CONST_FIXED_VALUE_LOW'. 8498 8499 `(const_vector:M [X0 X1 ...])' 8500 Represents a vector constant. The square brackets stand for the 8501 vector containing the constant elements. X0, X1 and so on are the 8502 `const_int', `const_double' or `const_fixed' elements. 8503 8504 The number of units in a `const_vector' is obtained with the macro 8505 `CONST_VECTOR_NUNITS' as in `CONST_VECTOR_NUNITS (V)'. 8506 8507 Individual elements in a vector constant are accessed with the 8508 macro `CONST_VECTOR_ELT' as in `CONST_VECTOR_ELT (V, N)' where V 8509 is the vector constant and N is the element desired. 8510 8511 `(const_string STR)' 8512 Represents a constant string with value STR. Currently this is 8513 used only for insn attributes (*note Insn Attributes::) since 8514 constant strings in C are placed in memory. 8515 8516 `(symbol_ref:MODE SYMBOL)' 8517 Represents the value of an assembler label for data. SYMBOL is a 8518 string that describes the name of the assembler label. If it 8519 starts with a `*', the label is the rest of SYMBOL not including 8520 the `*'. Otherwise, the label is SYMBOL, usually prefixed with 8521 `_'. 8522 8523 The `symbol_ref' contains a mode, which is usually `Pmode'. 8524 Usually that is the only mode for which a symbol is directly valid. 8525 8526 `(label_ref:MODE LABEL)' 8527 Represents the value of an assembler label for code. It contains 8528 one operand, an expression, which must be a `code_label' or a 8529 `note' of type `NOTE_INSN_DELETED_LABEL' that appears in the 8530 instruction sequence to identify the place where the label should 8531 go. 8532 8533 The reason for using a distinct expression type for code label 8534 references is so that jump optimization can distinguish them. 8535 8536 The `label_ref' contains a mode, which is usually `Pmode'. 8537 Usually that is the only mode for which a label is directly valid. 8538 8539 `(const:M EXP)' 8540 Represents a constant that is the result of an assembly-time 8541 arithmetic computation. The operand, EXP, is an expression that 8542 contains only constants (`const_int', `symbol_ref' and `label_ref' 8543 expressions) combined with `plus' and `minus'. However, not all 8544 combinations are valid, since the assembler cannot do arbitrary 8545 arithmetic on relocatable symbols. 8546 8547 M should be `Pmode'. 8548 8549 `(high:M EXP)' 8550 Represents the high-order bits of EXP, usually a `symbol_ref'. 8551 The number of bits is machine-dependent and is normally the number 8552 of bits specified in an instruction that initializes the high 8553 order bits of a register. It is used with `lo_sum' to represent 8554 the typical two-instruction sequence used in RISC machines to 8555 reference a global memory location. 8556 8557 M should be `Pmode'. 8558 8559 The macro `CONST0_RTX (MODE)' refers to an expression with value 0 in 8560 mode MODE. If mode MODE is of mode class `MODE_INT', it returns 8561 `const0_rtx'. If mode MODE is of mode class `MODE_FLOAT', it returns a 8562 `CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 8563 `CONST_VECTOR' expression in mode MODE. Similarly, the macro 8564 `CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 8565 and similarly for `CONST2_RTX'. The `CONST1_RTX' and `CONST2_RTX' 8566 macros are undefined for vector modes. 8567 8568 8569 File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 8570 8571 10.8 Registers and Memory 8572 ========================= 8573 8574 Here are the RTL expression types for describing access to machine 8575 registers and to main memory. 8576 8577 `(reg:M N)' 8578 For small values of the integer N (those that are less than 8579 `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 8580 register number N: a "hard register". For larger values of N, it 8581 stands for a temporary value or "pseudo register". The compiler's 8582 strategy is to generate code assuming an unlimited number of such 8583 pseudo registers, and later convert them into hard registers or 8584 into memory references. 8585 8586 M is the machine mode of the reference. It is necessary because 8587 machines can generally refer to each register in more than one 8588 mode. For example, a register may contain a full word but there 8589 may be instructions to refer to it as a half word or as a single 8590 byte, as well as instructions to refer to it as a floating point 8591 number of various precisions. 8592 8593 Even for a register that the machine can access in only one mode, 8594 the mode must always be specified. 8595 8596 The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine 8597 description, since the number of hard registers on the machine is 8598 an invariant characteristic of the machine. Note, however, that 8599 not all of the machine registers must be general registers. All 8600 the machine registers that can be used for storage of data are 8601 given hard register numbers, even those that can be used only in 8602 certain instructions or can hold only certain types of data. 8603 8604 A hard register may be accessed in various modes throughout one 8605 function, but each pseudo register is given a natural mode and is 8606 accessed only in that mode. When it is necessary to describe an 8607 access to a pseudo register using a nonnatural mode, a `subreg' 8608 expression is used. 8609 8610 A `reg' expression with a machine mode that specifies more than 8611 one word of data may actually stand for several consecutive 8612 registers. If in addition the register number specifies a 8613 hardware register, then it actually represents several consecutive 8614 hardware registers starting with the specified one. 8615 8616 Each pseudo register number used in a function's RTL code is 8617 represented by a unique `reg' expression. 8618 8619 Some pseudo register numbers, those within the range of 8620 `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear 8621 during the RTL generation phase and are eliminated before the 8622 optimization phases. These represent locations in the stack frame 8623 that cannot be determined until RTL generation for the function 8624 has been completed. The following virtual register numbers are 8625 defined: 8626 8627 `VIRTUAL_INCOMING_ARGS_REGNUM' 8628 This points to the first word of the incoming arguments 8629 passed on the stack. Normally these arguments are placed 8630 there by the caller, but the callee may have pushed some 8631 arguments that were previously passed in registers. 8632 8633 When RTL generation is complete, this virtual register is 8634 replaced by the sum of the register given by 8635 `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'. 8636 8637 `VIRTUAL_STACK_VARS_REGNUM' 8638 If `FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 8639 points to immediately above the first variable on the stack. 8640 Otherwise, it points to the first variable on the stack. 8641 8642 `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 8643 register given by `FRAME_POINTER_REGNUM' and the value 8644 `STARTING_FRAME_OFFSET'. 8645 8646 `VIRTUAL_STACK_DYNAMIC_REGNUM' 8647 This points to the location of dynamically allocated memory 8648 on the stack immediately after the stack pointer has been 8649 adjusted by the amount of memory desired. 8650 8651 This virtual register is replaced by the sum of the register 8652 given by `STACK_POINTER_REGNUM' and the value 8653 `STACK_DYNAMIC_OFFSET'. 8654 8655 `VIRTUAL_OUTGOING_ARGS_REGNUM' 8656 This points to the location in the stack at which outgoing 8657 arguments should be written when the stack is pre-pushed 8658 (arguments pushed using push insns should always use 8659 `STACK_POINTER_REGNUM'). 8660 8661 This virtual register is replaced by the sum of the register 8662 given by `STACK_POINTER_REGNUM' and the value 8663 `STACK_POINTER_OFFSET'. 8664 8665 `(subreg:M1 REG:M2 BYTENUM)' 8666 `subreg' expressions are used to refer to a register in a machine 8667 mode other than its natural one, or to refer to one register of a 8668 multi-part `reg' that actually refers to several registers. 8669 8670 Each pseudo register has a natural mode. If it is necessary to 8671 operate on it in a different mode, the register must be enclosed 8672 in a `subreg'. 8673 8674 There are currently three supported types for the first operand of 8675 a `subreg': 8676 * pseudo registers This is the most common case. Most 8677 `subreg's have pseudo `reg's as their first operand. 8678 8679 * mem `subreg's of `mem' were common in earlier versions of GCC 8680 and are still supported. During the reload pass these are 8681 replaced by plain `mem's. On machines that do not do 8682 instruction scheduling, use of `subreg's of `mem' are still 8683 used, but this is no longer recommended. Such `subreg's are 8684 considered to be `register_operand's rather than 8685 `memory_operand's before and during reload. Because of this, 8686 the scheduling passes cannot properly schedule instructions 8687 with `subreg's of `mem', so for machines that do scheduling, 8688 `subreg's of `mem' should never be used. To support this, 8689 the combine and recog passes have explicit code to inhibit 8690 the creation of `subreg's of `mem' when `INSN_SCHEDULING' is 8691 defined. 8692 8693 The use of `subreg's of `mem' after the reload pass is an area 8694 that is not well understood and should be avoided. There is 8695 still some code in the compiler to support this, but this 8696 code has possibly rotted. This use of `subreg's is 8697 discouraged and will most likely not be supported in the 8698 future. 8699 8700 * hard registers It is seldom necessary to wrap hard registers 8701 in `subreg's; such registers would normally reduce to a 8702 single `reg' rtx. This use of `subreg's is discouraged and 8703 may not be supported in the future. 8704 8705 8706 `subreg's of `subreg's are not supported. Using 8707 `simplify_gen_subreg' is the recommended way to avoid this problem. 8708 8709 `subreg's come in two distinct flavors, each having its own usage 8710 and rules: 8711 8712 Paradoxical subregs 8713 When M1 is strictly wider than M2, the `subreg' expression is 8714 called "paradoxical". The canonical test for this class of 8715 `subreg' is: 8716 8717 GET_MODE_SIZE (M1) > GET_MODE_SIZE (M2) 8718 8719 Paradoxical `subreg's can be used as both lvalues and rvalues. 8720 When used as an lvalue, the low-order bits of the source value 8721 are stored in REG and the high-order bits are discarded. 8722 When used as an rvalue, the low-order bits of the `subreg' are 8723 taken from REG while the high-order bits may or may not be 8724 defined. 8725 8726 The high-order bits of rvalues are in the following 8727 circumstances: 8728 8729 * `subreg's of `mem' When M2 is smaller than a word, the 8730 macro `LOAD_EXTEND_OP', can control how the high-order 8731 bits are defined. 8732 8733 * `subreg' of `reg's The upper bits are defined when 8734 `SUBREG_PROMOTED_VAR_P' is true. 8735 `SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 8736 bits hold. Such subregs usually represent local 8737 variables, register variables and parameter pseudo 8738 variables that have been promoted to a wider mode. 8739 8740 8741 BYTENUM is always zero for a paradoxical `subreg', even on 8742 big-endian targets. 8743 8744 For example, the paradoxical `subreg': 8745 8746 (set (subreg:SI (reg:HI X) 0) Y) 8747 8748 stores the lower 2 bytes of Y in X and discards the upper 2 8749 bytes. A subsequent: 8750 8751 (set Z (subreg:SI (reg:HI X) 0)) 8752 8753 would set the lower two bytes of Z to Y and set the upper two 8754 bytes to an unknown value assuming `SUBREG_PROMOTED_VAR_P' is 8755 false. 8756 8757 Normal subregs 8758 When M1 is at least as narrow as M2 the `subreg' expression 8759 is called "normal". 8760 8761 Normal `subreg's restrict consideration to certain bits of 8762 REG. There are two cases. If M1 is smaller than a word, the 8763 `subreg' refers to the least-significant part (or "lowpart") 8764 of one word of REG. If M1 is word-sized or greater, the 8765 `subreg' refers to one or more complete words. 8766 8767 When used as an lvalue, `subreg' is a word-based accessor. 8768 Storing to a `subreg' modifies all the words of REG that 8769 overlap the `subreg', but it leaves the other words of REG 8770 alone. 8771 8772 When storing to a normal `subreg' that is smaller than a word, 8773 the other bits of the referenced word are usually left in an 8774 undefined state. This laxity makes it easier to generate 8775 efficient code for such instructions. To represent an 8776 instruction that preserves all the bits outside of those in 8777 the `subreg', use `strict_low_part' or `zero_extract' around 8778 the `subreg'. 8779 8780 BYTENUM must identify the offset of the first byte of the 8781 `subreg' from the start of REG, assuming that REG is laid out 8782 in memory order. The memory order of bytes is defined by two 8783 target macros, `WORDS_BIG_ENDIAN' and `BYTES_BIG_ENDIAN': 8784 8785 * `WORDS_BIG_ENDIAN', if set to 1, says that byte number 8786 zero is part of the most significant word; otherwise, it 8787 is part of the least significant word. 8788 8789 * `BYTES_BIG_ENDIAN', if set to 1, says that byte number 8790 zero is the most significant byte within a word; 8791 otherwise, it is the least significant byte within a 8792 word. 8793 8794 On a few targets, `FLOAT_WORDS_BIG_ENDIAN' disagrees with 8795 `WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 8796 floating point values as if they had the same endianness as 8797 integer values. This works because they handle them solely 8798 as a collection of integer values, with no particular 8799 numerical value. Only real.c and the runtime libraries care 8800 about `FLOAT_WORDS_BIG_ENDIAN'. 8801 8802 Thus, 8803 8804 (subreg:HI (reg:SI X) 2) 8805 8806 on a `BYTES_BIG_ENDIAN', `UNITS_PER_WORD == 4' target is the 8807 same as 8808 8809 (subreg:HI (reg:SI X) 0) 8810 8811 on a little-endian, `UNITS_PER_WORD == 4' target. Both 8812 `subreg's access the lower two bytes of register X. 8813 8814 8815 A `MODE_PARTIAL_INT' mode behaves as if it were as wide as the 8816 corresponding `MODE_INT' mode, except that it has an unknown 8817 number of undefined bits. For example: 8818 8819 (subreg:PSI (reg:SI 0) 0) 8820 8821 accesses the whole of `(reg:SI 0)', but the exact relationship 8822 between the `PSImode' value and the `SImode' value is not defined. 8823 If we assume `UNITS_PER_WORD <= 4', then the following two 8824 `subreg's: 8825 8826 (subreg:PSI (reg:DI 0) 0) 8827 (subreg:PSI (reg:DI 0) 4) 8828 8829 represent independent 4-byte accesses to the two halves of 8830 `(reg:DI 0)'. Both `subreg's have an unknown number of undefined 8831 bits. 8832 8833 If `UNITS_PER_WORD <= 2' then these two `subreg's: 8834 8835 (subreg:HI (reg:PSI 0) 0) 8836 (subreg:HI (reg:PSI 0) 2) 8837 8838 represent independent 2-byte accesses that together span the whole 8839 of `(reg:PSI 0)'. Storing to the first `subreg' does not affect 8840 the value of the second, and vice versa. `(reg:PSI 0)' has an 8841 unknown number of undefined bits, so the assignment: 8842 8843 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 8844 8845 does not guarantee that `(subreg:HI (reg:PSI 0) 0)' has the value 8846 `(reg:HI 4)'. 8847 8848 The rules above apply to both pseudo REGs and hard REGs. If the 8849 semantics are not correct for particular combinations of M1, M2 8850 and hard REG, the target-specific code must ensure that those 8851 combinations are never used. For example: 8852 8853 CANNOT_CHANGE_MODE_CLASS (M2, M1, CLASS) 8854 8855 must be true for every class CLASS that includes REG. 8856 8857 The first operand of a `subreg' expression is customarily accessed 8858 with the `SUBREG_REG' macro and the second operand is customarily 8859 accessed with the `SUBREG_BYTE' macro. 8860 8861 It has been several years since a platform in which 8862 `BYTES_BIG_ENDIAN' not equal to `WORDS_BIG_ENDIAN' has been 8863 tested. Anyone wishing to support such a platform in the future 8864 may be confronted with code rot. 8865 8866 `(scratch:M)' 8867 This represents a scratch register that will be required for the 8868 execution of a single instruction and not used subsequently. It is 8869 converted into a `reg' by either the local register allocator or 8870 the reload pass. 8871 8872 `scratch' is usually present inside a `clobber' operation (*note 8873 Side Effects::). 8874 8875 `(cc0)' 8876 This refers to the machine's condition code register. It has no 8877 operands and may not have a machine mode. There are two ways to 8878 use it: 8879 8880 * To stand for a complete set of condition code flags. This is 8881 best on most machines, where each comparison sets the entire 8882 series of flags. 8883 8884 With this technique, `(cc0)' may be validly used in only two 8885 contexts: as the destination of an assignment (in test and 8886 compare instructions) and in comparison operators comparing 8887 against zero (`const_int' with value zero; that is to say, 8888 `const0_rtx'). 8889 8890 * To stand for a single flag that is the result of a single 8891 condition. This is useful on machines that have only a 8892 single flag bit, and in which comparison instructions must 8893 specify the condition to test. 8894 8895 With this technique, `(cc0)' may be validly used in only two 8896 contexts: as the destination of an assignment (in test and 8897 compare instructions) where the source is a comparison 8898 operator, and as the first operand of `if_then_else' (in a 8899 conditional branch). 8900 8901 There is only one expression object of code `cc0'; it is the value 8902 of the variable `cc0_rtx'. Any attempt to create an expression of 8903 code `cc0' will return `cc0_rtx'. 8904 8905 Instructions can set the condition code implicitly. On many 8906 machines, nearly all instructions set the condition code based on 8907 the value that they compute or store. It is not necessary to 8908 record these actions explicitly in the RTL because the machine 8909 description includes a prescription for recognizing the 8910 instructions that do so (by means of the macro 8911 `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions 8912 whose sole purpose is to set the condition code, and instructions 8913 that use the condition code, need mention `(cc0)'. 8914 8915 On some machines, the condition code register is given a register 8916 number and a `reg' is used instead of `(cc0)'. This is usually the 8917 preferable approach if only a small subset of instructions modify 8918 the condition code. Other machines store condition codes in 8919 general registers; in such cases a pseudo register should be used. 8920 8921 Some machines, such as the SPARC and RS/6000, have two sets of 8922 arithmetic instructions, one that sets and one that does not set 8923 the condition code. This is best handled by normally generating 8924 the instruction that does not set the condition code, and making a 8925 pattern that both performs the arithmetic and sets the condition 8926 code register (which would not be `(cc0)' in this case). For 8927 examples, search for `addcc' and `andcc' in `sparc.md'. 8928 8929 `(pc)' 8930 This represents the machine's program counter. It has no operands 8931 and may not have a machine mode. `(pc)' may be validly used only 8932 in certain specific contexts in jump instructions. 8933 8934 There is only one expression object of code `pc'; it is the value 8935 of the variable `pc_rtx'. Any attempt to create an expression of 8936 code `pc' will return `pc_rtx'. 8937 8938 All instructions that do not jump alter the program counter 8939 implicitly by incrementing it, but there is no need to mention 8940 this in the RTL. 8941 8942 `(mem:M ADDR ALIAS)' 8943 This RTX represents a reference to main memory at an address 8944 represented by the expression ADDR. M specifies how large a unit 8945 of memory is accessed. ALIAS specifies an alias set for the 8946 reference. In general two items are in different alias sets if 8947 they cannot reference the same memory address. 8948 8949 The construct `(mem:BLK (scratch))' is considered to alias all 8950 other memories. Thus it may be used as a memory barrier in 8951 epilogue stack deallocation patterns. 8952 8953 `(concatM RTX RTX)' 8954 This RTX represents the concatenation of two other RTXs. This is 8955 used for complex values. It should only appear in the RTL 8956 attached to declarations and during RTL generation. It should not 8957 appear in the ordinary insn chain. 8958 8959 `(concatnM [RTX ...])' 8960 This RTX represents the concatenation of all the RTX to make a 8961 single value. Like `concat', this should only appear in 8962 declarations, and not in the insn chain. 8963 8964 8965 File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 8966 8967 10.9 RTL Expressions for Arithmetic 8968 =================================== 8969 8970 Unless otherwise specified, all the operands of arithmetic expressions 8971 must be valid for mode M. An operand is valid for mode M if it has 8972 mode M, or if it is a `const_int' or `const_double' and M is a mode of 8973 class `MODE_INT'. 8974 8975 For commutative binary operations, constants should be placed in the 8976 second operand. 8977 8978 `(plus:M X Y)' 8979 `(ss_plus:M X Y)' 8980 `(us_plus:M X Y)' 8981 These three expressions all represent the sum of the values 8982 represented by X and Y carried out in machine mode M. They differ 8983 in their behavior on overflow of integer modes. `plus' wraps 8984 round modulo the width of M; `ss_plus' saturates at the maximum 8985 signed value representable in M; `us_plus' saturates at the 8986 maximum unsigned value. 8987 8988 `(lo_sum:M X Y)' 8989 This expression represents the sum of X and the low-order bits of 8990 Y. It is used with `high' (*note Constants::) to represent the 8991 typical two-instruction sequence used in RISC machines to 8992 reference a global memory location. 8993 8994 The number of low order bits is machine-dependent but is normally 8995 the number of bits in a `Pmode' item minus the number of bits set 8996 by `high'. 8997 8998 M should be `Pmode'. 8999 9000 `(minus:M X Y)' 9001 `(ss_minus:M X Y)' 9002 `(us_minus:M X Y)' 9003 These three expressions represent the result of subtracting Y from 9004 X, carried out in mode M. Behavior on overflow is the same as for 9005 the three variants of `plus' (see above). 9006 9007 `(compare:M X Y)' 9008 Represents the result of subtracting Y from X for purposes of 9009 comparison. The result is computed without overflow, as if with 9010 infinite precision. 9011 9012 Of course, machines can't really subtract with infinite precision. 9013 However, they can pretend to do so when only the sign of the 9014 result will be used, which is the case when the result is stored 9015 in the condition code. And that is the _only_ way this kind of 9016 expression may validly be used: as a value to be stored in the 9017 condition codes, either `(cc0)' or a register. *Note 9018 Comparisons::. 9019 9020 The mode M is not related to the modes of X and Y, but instead is 9021 the mode of the condition code value. If `(cc0)' is used, it is 9022 `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often 9023 `CCmode'. *Note Condition Code::. If M is `VOIDmode' or 9024 `CCmode', the operation returns sufficient information (in an 9025 unspecified format) so that any comparison operator can be applied 9026 to the result of the `COMPARE' operation. For other modes in 9027 class `MODE_CC', the operation only returns a subset of this 9028 information. 9029 9030 Normally, X and Y must have the same mode. Otherwise, `compare' 9031 is valid only if the mode of X is in class `MODE_INT' and Y is a 9032 `const_int' or `const_double' with mode `VOIDmode'. The mode of X 9033 determines what mode the comparison is to be done in; thus it must 9034 not be `VOIDmode'. 9035 9036 If one of the operands is a constant, it should be placed in the 9037 second operand and the comparison code adjusted as appropriate. 9038 9039 A `compare' specifying two `VOIDmode' constants is not valid since 9040 there is no way to know in what mode the comparison is to be 9041 performed; the comparison must either be folded during the 9042 compilation or the first operand must be loaded into a register 9043 while its mode is still known. 9044 9045 `(neg:M X)' 9046 `(ss_neg:M X)' 9047 `(us_neg:M X)' 9048 These two expressions represent the negation (subtraction from 9049 zero) of the value represented by X, carried out in mode M. They 9050 differ in the behavior on overflow of integer modes. In the case 9051 of `neg', the negation of the operand may be a number not 9052 representable in mode M, in which case it is truncated to M. 9053 `ss_neg' and `us_neg' ensure that an out-of-bounds result 9054 saturates to the maximum or minimum signed or unsigned value. 9055 9056 `(mult:M X Y)' 9057 `(ss_mult:M X Y)' 9058 `(us_mult:M X Y)' 9059 Represents the signed product of the values represented by X and Y 9060 carried out in machine mode M. `ss_mult' and `us_mult' ensure 9061 that an out-of-bounds result saturates to the maximum or minimum 9062 signed or unsigned value. 9063 9064 Some machines support a multiplication that generates a product 9065 wider than the operands. Write the pattern for this as 9066 9067 (mult:M (sign_extend:M X) (sign_extend:M Y)) 9068 9069 where M is wider than the modes of X and Y, which need not be the 9070 same. 9071 9072 For unsigned widening multiplication, use the same idiom, but with 9073 `zero_extend' instead of `sign_extend'. 9074 9075 `(fma:M X Y Z)' 9076 Represents the `fma', `fmaf', and `fmal' builtin functions that do 9077 a combined multiply of X and Y and then adding toZ without doing 9078 an intermediate rounding step. 9079 9080 `(div:M X Y)' 9081 `(ss_div:M X Y)' 9082 Represents the quotient in signed division of X by Y, carried out 9083 in machine mode M. If M is a floating point mode, it represents 9084 the exact quotient; otherwise, the integerized quotient. `ss_div' 9085 ensures that an out-of-bounds result saturates to the maximum or 9086 minimum signed value. 9087 9088 Some machines have division instructions in which the operands and 9089 quotient widths are not all the same; you should represent such 9090 instructions using `truncate' and `sign_extend' as in, 9091 9092 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 9093 9094 `(udiv:M X Y)' 9095 `(us_div:M X Y)' 9096 Like `div' but represents unsigned division. `us_div' ensures 9097 that an out-of-bounds result saturates to the maximum or minimum 9098 unsigned value. 9099 9100 `(mod:M X Y)' 9101 `(umod:M X Y)' 9102 Like `div' and `udiv' but represent the remainder instead of the 9103 quotient. 9104 9105 `(smin:M X Y)' 9106 `(smax:M X Y)' 9107 Represents the smaller (for `smin') or larger (for `smax') of X 9108 and Y, interpreted as signed values in mode M. When used with 9109 floating point, if both operands are zeros, or if either operand 9110 is `NaN', then it is unspecified which of the two operands is 9111 returned as the result. 9112 9113 `(umin:M X Y)' 9114 `(umax:M X Y)' 9115 Like `smin' and `smax', but the values are interpreted as unsigned 9116 integers. 9117 9118 `(not:M X)' 9119 Represents the bitwise complement of the value represented by X, 9120 carried out in mode M, which must be a fixed-point machine mode. 9121 9122 `(and:M X Y)' 9123 Represents the bitwise logical-and of the values represented by X 9124 and Y, carried out in machine mode M, which must be a fixed-point 9125 machine mode. 9126 9127 `(ior:M X Y)' 9128 Represents the bitwise inclusive-or of the values represented by X 9129 and Y, carried out in machine mode M, which must be a fixed-point 9130 mode. 9131 9132 `(xor:M X Y)' 9133 Represents the bitwise exclusive-or of the values represented by X 9134 and Y, carried out in machine mode M, which must be a fixed-point 9135 mode. 9136 9137 `(ashift:M X C)' 9138 `(ss_ashift:M X C)' 9139 `(us_ashift:M X C)' 9140 These three expressions represent the result of arithmetically 9141 shifting X left by C places. They differ in their behavior on 9142 overflow of integer modes. An `ashift' operation is a plain shift 9143 with no special behavior in case of a change in the sign bit; 9144 `ss_ashift' and `us_ashift' saturates to the minimum or maximum 9145 representable value if any of the bits shifted out differs from 9146 the final sign bit. 9147 9148 X have mode M, a fixed-point machine mode. C be a fixed-point 9149 mode or be a constant with mode `VOIDmode'; which mode is 9150 determined by the mode called for in the machine description entry 9151 for the left-shift instruction. For example, on the VAX, the mode 9152 of C is `QImode' regardless of M. 9153 9154 `(lshiftrt:M X C)' 9155 `(ashiftrt:M X C)' 9156 Like `ashift' but for right shift. Unlike the case for left shift, 9157 these two operations are distinct. 9158 9159 `(rotate:M X C)' 9160 `(rotatert:M X C)' 9161 Similar but represent left and right rotate. If C is a constant, 9162 use `rotate'. 9163 9164 `(abs:M X)' 9165 9166 `(ss_abs:M X)' 9167 Represents the absolute value of X, computed in mode M. `ss_abs' 9168 ensures that an out-of-bounds result saturates to the maximum 9169 signed value. 9170 9171 `(sqrt:M X)' 9172 Represents the square root of X, computed in mode M. Most often M 9173 will be a floating point mode. 9174 9175 `(ffs:M X)' 9176 Represents one plus the index of the least significant 1-bit in X, 9177 represented as an integer of mode M. (The value is zero if X is 9178 zero.) The mode of X need not be M; depending on the target 9179 machine, various mode combinations may be valid. 9180 9181 `(clz:M X)' 9182 Represents the number of leading 0-bits in X, represented as an 9183 integer of mode M, starting at the most significant bit position. 9184 If X is zero, the value is determined by 9185 `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 9186 of the few expressions that is not invariant under widening. The 9187 mode of X will usually be an integer mode. 9188 9189 `(ctz:M X)' 9190 Represents the number of trailing 0-bits in X, represented as an 9191 integer of mode M, starting at the least significant bit position. 9192 If X is zero, the value is determined by 9193 `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 9194 `ctz(x)' is equivalent to `ffs(X) - 1'. The mode of X will 9195 usually be an integer mode. 9196 9197 `(popcount:M X)' 9198 Represents the number of 1-bits in X, represented as an integer of 9199 mode M. The mode of X will usually be an integer mode. 9200 9201 `(parity:M X)' 9202 Represents the number of 1-bits modulo 2 in X, represented as an 9203 integer of mode M. The mode of X will usually be an integer mode. 9204 9205 `(bswap:M X)' 9206 Represents the value X with the order of bytes reversed, carried 9207 out in mode M, which must be a fixed-point machine mode. 9208 9209 9210 File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 9211 9212 10.10 Comparison Operations 9213 =========================== 9214 9215 Comparison operators test a relation on two operands and are considered 9216 to represent a machine-dependent nonzero value described by, but not 9217 necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::) if the relation 9218 holds, or zero if it does not, for comparison operators whose results 9219 have a `MODE_INT' mode, `FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 9220 relation holds, or zero if it does not, for comparison operators that 9221 return floating-point values, and a vector of either 9222 `VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 9223 zeros if it does not, for comparison operators that return vector 9224 results. The mode of the comparison operation is independent of the 9225 mode of the data being compared. If the comparison operation is being 9226 tested (e.g., the first operand of an `if_then_else'), the mode must be 9227 `VOIDmode'. 9228 9229 There are two ways that comparison operations may be used. The 9230 comparison operators may be used to compare the condition codes `(cc0)' 9231 against zero, as in `(eq (cc0) (const_int 0))'. Such a construct 9232 actually refers to the result of the preceding instruction in which the 9233 condition codes were set. The instruction setting the condition code 9234 must be adjacent to the instruction using the condition code; only 9235 `note' insns may separate them. 9236 9237 Alternatively, a comparison operation may directly compare two data 9238 objects. The mode of the comparison is determined by the operands; they 9239 must both be valid for a common machine mode. A comparison with both 9240 operands constant would be invalid as the machine mode could not be 9241 deduced from it, but such a comparison should never exist in RTL due to 9242 constant folding. 9243 9244 In the example above, if `(cc0)' were last set to `(compare X Y)', the 9245 comparison operation is identical to `(eq X Y)'. Usually only one style 9246 of comparisons is supported on a particular machine, but the combine 9247 pass will try to merge the operations to produce the `eq' shown in case 9248 it exists in the context of the particular insn involved. 9249 9250 Inequality comparisons come in two flavors, signed and unsigned. Thus, 9251 there are distinct expression codes `gt' and `gtu' for signed and 9252 unsigned greater-than. These can produce different results for the same 9253 pair of integer values: for example, 1 is signed greater-than -1 but not 9254 unsigned greater-than, because -1 when regarded as unsigned is actually 9255 `0xffffffff' which is greater than 1. 9256 9257 The signed comparisons are also used for floating point values. 9258 Floating point comparisons are distinguished by the machine modes of 9259 the operands. 9260 9261 `(eq:M X Y)' 9262 `STORE_FLAG_VALUE' if the values represented by X and Y are equal, 9263 otherwise 0. 9264 9265 `(ne:M X Y)' 9266 `STORE_FLAG_VALUE' if the values represented by X and Y are not 9267 equal, otherwise 0. 9268 9269 `(gt:M X Y)' 9270 `STORE_FLAG_VALUE' if the X is greater than Y. If they are 9271 fixed-point, the comparison is done in a signed sense. 9272 9273 `(gtu:M X Y)' 9274 Like `gt' but does unsigned comparison, on fixed-point numbers 9275 only. 9276 9277 `(lt:M X Y)' 9278 `(ltu:M X Y)' 9279 Like `gt' and `gtu' but test for "less than". 9280 9281 `(ge:M X Y)' 9282 `(geu:M X Y)' 9283 Like `gt' and `gtu' but test for "greater than or equal". 9284 9285 `(le:M X Y)' 9286 `(leu:M X Y)' 9287 Like `gt' and `gtu' but test for "less than or equal". 9288 9289 `(if_then_else COND THEN ELSE)' 9290 This is not a comparison operation but is listed here because it is 9291 always used in conjunction with a comparison operation. To be 9292 precise, COND is a comparison expression. This expression 9293 represents a choice, according to COND, between the value 9294 represented by THEN and the one represented by ELSE. 9295 9296 On most machines, `if_then_else' expressions are valid only to 9297 express conditional jumps. 9298 9299 `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 9300 Similar to `if_then_else', but more general. Each of TEST1, 9301 TEST2, ... is performed in turn. The result of this expression is 9302 the VALUE corresponding to the first nonzero test, or DEFAULT if 9303 none of the tests are nonzero expressions. 9304 9305 This is currently not valid for instruction patterns and is 9306 supported only for insn attributes. *Note Insn Attributes::. 9307 9308 9309 File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 9310 9311 10.11 Bit-Fields 9312 ================ 9313 9314 Special expression codes exist to represent bit-field instructions. 9315 9316 `(sign_extract:M LOC SIZE POS)' 9317 This represents a reference to a sign-extended bit-field contained 9318 or starting in LOC (a memory or register reference). The bit-field 9319 is SIZE bits wide and starts at bit POS. The compilation option 9320 `BITS_BIG_ENDIAN' says which end of the memory unit POS counts 9321 from. 9322 9323 If LOC is in memory, its mode must be a single-byte integer mode. 9324 If LOC is in a register, the mode to use is specified by the 9325 operand of the `insv' or `extv' pattern (*note Standard Names::) 9326 and is usually a full-word integer mode, which is the default if 9327 none is specified. 9328 9329 The mode of POS is machine-specific and is also specified in the 9330 `insv' or `extv' pattern. 9331 9332 The mode M is the same as the mode that would be used for LOC if 9333 it were a register. 9334 9335 A `sign_extract' can not appear as an lvalue, or part thereof, in 9336 RTL. 9337 9338 `(zero_extract:M LOC SIZE POS)' 9339 Like `sign_extract' but refers to an unsigned or zero-extended 9340 bit-field. The same sequence of bits are extracted, but they are 9341 filled to an entire word with zeros instead of by sign-extension. 9342 9343 Unlike `sign_extract', this type of expressions can be lvalues in 9344 RTL; they may appear on the left side of an assignment, indicating 9345 insertion of a value into the specified bit-field. 9346 9347 9348 File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 9349 9350 10.12 Vector Operations 9351 ======================= 9352 9353 All normal RTL expressions can be used with vector modes; they are 9354 interpreted as operating on each part of the vector independently. 9355 Additionally, there are a few new expressions to describe specific 9356 vector operations. 9357 9358 `(vec_merge:M VEC1 VEC2 ITEMS)' 9359 This describes a merge operation between two vectors. The result 9360 is a vector of mode M; its elements are selected from either VEC1 9361 or VEC2. Which elements are selected is described by ITEMS, which 9362 is a bit mask represented by a `const_int'; a zero bit indicates 9363 the corresponding element in the result vector is taken from VEC2 9364 while a set bit indicates it is taken from VEC1. 9365 9366 `(vec_select:M VEC1 SELECTION)' 9367 This describes an operation that selects parts of a vector. VEC1 9368 is the source vector, and SELECTION is a `parallel' that contains a 9369 `const_int' for each of the subparts of the result vector, giving 9370 the number of the source subpart that should be stored into it. 9371 The result mode M is either the submode for a single element of 9372 VEC1 (if only one subpart is selected), or another vector mode 9373 with that element submode (if multiple subparts are selected). 9374 9375 `(vec_concat:M VEC1 VEC2)' 9376 Describes a vector concat operation. The result is a 9377 concatenation of the vectors VEC1 and VEC2; its length is the sum 9378 of the lengths of the two inputs. 9379 9380 `(vec_duplicate:M VEC)' 9381 This operation converts a small vector into a larger one by 9382 duplicating the input values. The output vector mode must have 9383 the same submodes as the input vector mode, and the number of 9384 output parts must be an integer multiple of the number of input 9385 parts. 9386 9387 9388 9389 File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 9390 9391 10.13 Conversions 9392 ================= 9393 9394 All conversions between machine modes must be represented by explicit 9395 conversion operations. For example, an expression which is the sum of 9396 a byte and a full word cannot be written as `(plus:SI (reg:QI 34) 9397 (reg:SI 80))' because the `plus' operation requires two operands of the 9398 same machine mode. Therefore, the byte-sized operand is enclosed in a 9399 conversion operation, as in 9400 9401 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 9402 9403 The conversion operation is not a mere placeholder, because there may 9404 be more than one way of converting from a given starting mode to the 9405 desired final mode. The conversion operation code says how to do it. 9406 9407 For all conversion operations, X must not be `VOIDmode' because the 9408 mode in which to do the conversion would not be known. The conversion 9409 must either be done at compile-time or X must be placed into a register. 9410 9411 `(sign_extend:M X)' 9412 Represents the result of sign-extending the value X to machine 9413 mode M. M must be a fixed-point mode and X a fixed-point value of 9414 a mode narrower than M. 9415 9416 `(zero_extend:M X)' 9417 Represents the result of zero-extending the value X to machine 9418 mode M. M must be a fixed-point mode and X a fixed-point value of 9419 a mode narrower than M. 9420 9421 `(float_extend:M X)' 9422 Represents the result of extending the value X to machine mode M. 9423 M must be a floating point mode and X a floating point value of a 9424 mode narrower than M. 9425 9426 `(truncate:M X)' 9427 Represents the result of truncating the value X to machine mode M. 9428 M must be a fixed-point mode and X a fixed-point value of a mode 9429 wider than M. 9430 9431 `(ss_truncate:M X)' 9432 Represents the result of truncating the value X to machine mode M, 9433 using signed saturation in the case of overflow. Both M and the 9434 mode of X must be fixed-point modes. 9435 9436 `(us_truncate:M X)' 9437 Represents the result of truncating the value X to machine mode M, 9438 using unsigned saturation in the case of overflow. Both M and the 9439 mode of X must be fixed-point modes. 9440 9441 `(float_truncate:M X)' 9442 Represents the result of truncating the value X to machine mode M. 9443 M must be a floating point mode and X a floating point value of a 9444 mode wider than M. 9445 9446 `(float:M X)' 9447 Represents the result of converting fixed point value X, regarded 9448 as signed, to floating point mode M. 9449 9450 `(unsigned_float:M X)' 9451 Represents the result of converting fixed point value X, regarded 9452 as unsigned, to floating point mode M. 9453 9454 `(fix:M X)' 9455 When M is a floating-point mode, represents the result of 9456 converting floating point value X (valid for mode M) to an 9457 integer, still represented in floating point mode M, by rounding 9458 towards zero. 9459 9460 When M is a fixed-point mode, represents the result of converting 9461 floating point value X to mode M, regarded as signed. How 9462 rounding is done is not specified, so this operation may be used 9463 validly in compiling C code only for integer-valued operands. 9464 9465 `(unsigned_fix:M X)' 9466 Represents the result of converting floating point value X to 9467 fixed point mode M, regarded as unsigned. How rounding is done is 9468 not specified. 9469 9470 `(fract_convert:M X)' 9471 Represents the result of converting fixed-point value X to 9472 fixed-point mode M, signed integer value X to fixed-point mode M, 9473 floating-point value X to fixed-point mode M, fixed-point value X 9474 to integer mode M regarded as signed, or fixed-point value X to 9475 floating-point mode M. When overflows or underflows happen, the 9476 results are undefined. 9477 9478 `(sat_fract:M X)' 9479 Represents the result of converting fixed-point value X to 9480 fixed-point mode M, signed integer value X to fixed-point mode M, 9481 or floating-point value X to fixed-point mode M. When overflows 9482 or underflows happen, the results are saturated to the maximum or 9483 the minimum. 9484 9485 `(unsigned_fract_convert:M X)' 9486 Represents the result of converting fixed-point value X to integer 9487 mode M regarded as unsigned, or unsigned integer value X to 9488 fixed-point mode M. When overflows or underflows happen, the 9489 results are undefined. 9490 9491 `(unsigned_sat_fract:M X)' 9492 Represents the result of converting unsigned integer value X to 9493 fixed-point mode M. When overflows or underflows happen, the 9494 results are saturated to the maximum or the minimum. 9495 9496 9497 File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 9498 9499 10.14 Declarations 9500 ================== 9501 9502 Declaration expression codes do not represent arithmetic operations but 9503 rather state assertions about their operands. 9504 9505 `(strict_low_part (subreg:M (reg:N R) 0))' 9506 This expression code is used in only one context: as the 9507 destination operand of a `set' expression. In addition, the 9508 operand of this expression must be a non-paradoxical `subreg' 9509 expression. 9510 9511 The presence of `strict_low_part' says that the part of the 9512 register which is meaningful in mode N, but is not part of mode M, 9513 is not to be altered. Normally, an assignment to such a subreg is 9514 allowed to have undefined effects on the rest of the register when 9515 M is less than a word. 9516 9517 9518 File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 9519 9520 10.15 Side Effect Expressions 9521 ============================= 9522 9523 The expression codes described so far represent values, not actions. 9524 But machine instructions never produce values; they are meaningful only 9525 for their side effects on the state of the machine. Special expression 9526 codes are used to represent side effects. 9527 9528 The body of an instruction is always one of these side effect codes; 9529 the codes described above, which represent values, appear only as the 9530 operands of these. 9531 9532 `(set LVAL X)' 9533 Represents the action of storing the value of X into the place 9534 represented by LVAL. LVAL must be an expression representing a 9535 place that can be stored in: `reg' (or `subreg', `strict_low_part' 9536 or `zero_extract'), `mem', `pc', `parallel', or `cc0'. 9537 9538 If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then 9539 X must be valid for that mode. 9540 9541 If LVAL is a `reg' whose machine mode is less than the full width 9542 of the register, then it means that the part of the register 9543 specified by the machine mode is given the specified value and the 9544 rest of the register receives an undefined value. Likewise, if 9545 LVAL is a `subreg' whose machine mode is narrower than the mode of 9546 the register, the rest of the register can be changed in an 9547 undefined way. 9548 9549 If LVAL is a `strict_low_part' of a subreg, then the part of the 9550 register specified by the machine mode of the `subreg' is given 9551 the value X and the rest of the register is not changed. 9552 9553 If LVAL is a `zero_extract', then the referenced part of the 9554 bit-field (a memory or register reference) specified by the 9555 `zero_extract' is given the value X and the rest of the bit-field 9556 is not changed. Note that `sign_extract' can not appear in LVAL. 9557 9558 If LVAL is `(cc0)', it has no machine mode, and X may be either a 9559 `compare' expression or a value that may have any mode. The 9560 latter case represents a "test" instruction. The expression `(set 9561 (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N) 9562 (const_int 0)))'. Use the former expression to save space during 9563 the compilation. 9564 9565 If LVAL is a `parallel', it is used to represent the case of a 9566 function returning a structure in multiple registers. Each element 9567 of the `parallel' is an `expr_list' whose first operand is a `reg' 9568 and whose second operand is a `const_int' representing the offset 9569 (in bytes) into the structure at which the data in that register 9570 corresponds. The first element may be null to indicate that the 9571 structure is also passed partly in memory. 9572 9573 If LVAL is `(pc)', we have a jump instruction, and the 9574 possibilities for X are very limited. It may be a `label_ref' 9575 expression (unconditional jump). It may be an `if_then_else' 9576 (conditional jump), in which case either the second or the third 9577 operand must be `(pc)' (for the case which does not jump) and the 9578 other of the two must be a `label_ref' (for the case which does 9579 jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may 9580 be a `reg' or a `mem'; these unusual patterns are used to 9581 represent jumps through branch tables. 9582 9583 If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not 9584 be `VOIDmode' and the mode of X must be valid for the mode of LVAL. 9585 9586 LVAL is customarily accessed with the `SET_DEST' macro and X with 9587 the `SET_SRC' macro. 9588 9589 `(return)' 9590 As the sole expression in a pattern, represents a return from the 9591 current function, on machines where this can be done with one 9592 instruction, such as VAXen. On machines where a multi-instruction 9593 "epilogue" must be executed in order to return from the function, 9594 returning is done by jumping to a label which precedes the 9595 epilogue, and the `return' expression code is never used. 9596 9597 Inside an `if_then_else' expression, represents the value to be 9598 placed in `pc' to return to the caller. 9599 9600 Note that an insn pattern of `(return)' is logically equivalent to 9601 `(set (pc) (return))', but the latter form is never used. 9602 9603 `(call FUNCTION NARGS)' 9604 Represents a function call. FUNCTION is a `mem' expression whose 9605 address is the address of the function to be called. NARGS is an 9606 expression which can be used for two purposes: on some machines it 9607 represents the number of bytes of stack argument; on others, it 9608 represents the number of argument registers. 9609 9610 Each machine has a standard machine mode which FUNCTION must have. 9611 The machine description defines macro `FUNCTION_MODE' to expand 9612 into the requisite mode name. The purpose of this mode is to 9613 specify what kind of addressing is allowed, on machines where the 9614 allowed kinds of addressing depend on the machine mode being 9615 addressed. 9616 9617 `(clobber X)' 9618 Represents the storing or possible storing of an unpredictable, 9619 undescribed value into X, which must be a `reg', `scratch', 9620 `parallel' or `mem' expression. 9621 9622 One place this is used is in string instructions that store 9623 standard values into particular hard registers. It may not be 9624 worth the trouble to describe the values that are stored, but it 9625 is essential to inform the compiler that the registers will be 9626 altered, lest it attempt to keep data in them across the string 9627 instruction. 9628 9629 If X is `(mem:BLK (const_int 0))' or `(mem:BLK (scratch))', it 9630 means that all memory locations must be presumed clobbered. If X 9631 is a `parallel', it has the same meaning as a `parallel' in a 9632 `set' expression. 9633 9634 Note that the machine description classifies certain hard 9635 registers as "call-clobbered". All function call instructions are 9636 assumed by default to clobber these registers, so there is no need 9637 to use `clobber' expressions to indicate this fact. Also, each 9638 function call is assumed to have the potential to alter any memory 9639 location, unless the function is declared `const'. 9640 9641 If the last group of expressions in a `parallel' are each a 9642 `clobber' expression whose arguments are `reg' or `match_scratch' 9643 (*note RTL Template::) expressions, the combiner phase can add the 9644 appropriate `clobber' expressions to an insn it has constructed 9645 when doing so will cause a pattern to be matched. 9646 9647 This feature can be used, for example, on a machine that whose 9648 multiply and add instructions don't use an MQ register but which 9649 has an add-accumulate instruction that does clobber the MQ 9650 register. Similarly, a combined instruction might require a 9651 temporary register while the constituent instructions might not. 9652 9653 When a `clobber' expression for a register appears inside a 9654 `parallel' with other side effects, the register allocator 9655 guarantees that the register is unoccupied both before and after 9656 that insn if it is a hard register clobber. For pseudo-register 9657 clobber, the register allocator and the reload pass do not assign 9658 the same hard register to the clobber and the input operands if 9659 there is an insn alternative containing the `&' constraint (*note 9660 Modifiers::) for the clobber and the hard register is in register 9661 classes of the clobber in the alternative. You can clobber either 9662 a specific hard register, a pseudo register, or a `scratch' 9663 expression; in the latter two cases, GCC will allocate a hard 9664 register that is available there for use as a temporary. 9665 9666 For instructions that require a temporary register, you should use 9667 `scratch' instead of a pseudo-register because this will allow the 9668 combiner phase to add the `clobber' when required. You do this by 9669 coding (`clobber' (`match_scratch' ...)). If you do clobber a 9670 pseudo register, use one which appears nowhere else--generate a 9671 new one each time. Otherwise, you may confuse CSE. 9672 9673 There is one other known use for clobbering a pseudo register in a 9674 `parallel': when one of the input operands of the insn is also 9675 clobbered by the insn. In this case, using the same pseudo 9676 register in the clobber and elsewhere in the insn produces the 9677 expected results. 9678 9679 `(use X)' 9680 Represents the use of the value of X. It indicates that the value 9681 in X at this point in the program is needed, even though it may 9682 not be apparent why this is so. Therefore, the compiler will not 9683 attempt to delete previous instructions whose only effect is to 9684 store a value in X. X must be a `reg' expression. 9685 9686 In some situations, it may be tempting to add a `use' of a 9687 register in a `parallel' to describe a situation where the value 9688 of a special register will modify the behavior of the instruction. 9689 A hypothetical example might be a pattern for an addition that can 9690 either wrap around or use saturating addition depending on the 9691 value of a special control register: 9692 9693 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 9694 (reg:SI 4)] 0)) 9695 (use (reg:SI 1))]) 9696 9697 This will not work, several of the optimizers only look at 9698 expressions locally; it is very likely that if you have multiple 9699 insns with identical inputs to the `unspec', they will be 9700 optimized away even if register 1 changes in between. 9701 9702 This means that `use' can _only_ be used to describe that the 9703 register is live. You should think twice before adding `use' 9704 statements, more often you will want to use `unspec' instead. The 9705 `use' RTX is most commonly useful to describe that a fixed 9706 register is implicitly used in an insn. It is also safe to use in 9707 patterns where the compiler knows for other reasons that the result 9708 of the whole pattern is variable, such as `movmemM' or `call' 9709 patterns. 9710 9711 During the reload phase, an insn that has a `use' as pattern can 9712 carry a reg_equal note. These `use' insns will be deleted before 9713 the reload phase exits. 9714 9715 During the delayed branch scheduling phase, X may be an insn. 9716 This indicates that X previously was located at this place in the 9717 code and its data dependencies need to be taken into account. 9718 These `use' insns will be deleted before the delayed branch 9719 scheduling phase exits. 9720 9721 `(parallel [X0 X1 ...])' 9722 Represents several side effects performed in parallel. The square 9723 brackets stand for a vector; the operand of `parallel' is a vector 9724 of expressions. X0, X1 and so on are individual side effect 9725 expressions--expressions of code `set', `call', `return', 9726 `clobber' or `use'. 9727 9728 "In parallel" means that first all the values used in the 9729 individual side-effects are computed, and second all the actual 9730 side-effects are performed. For example, 9731 9732 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 9733 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 9734 9735 says unambiguously that the values of hard register 1 and the 9736 memory location addressed by it are interchanged. In both places 9737 where `(reg:SI 1)' appears as a memory address it refers to the 9738 value in register 1 _before_ the execution of the insn. 9739 9740 It follows that it is _incorrect_ to use `parallel' and expect the 9741 result of one `set' to be available for the next one. For 9742 example, people sometimes attempt to represent a jump-if-zero 9743 instruction this way: 9744 9745 (parallel [(set (cc0) (reg:SI 34)) 9746 (set (pc) (if_then_else 9747 (eq (cc0) (const_int 0)) 9748 (label_ref ...) 9749 (pc)))]) 9750 9751 But this is incorrect, because it says that the jump condition 9752 depends on the condition code value _before_ this instruction, not 9753 on the new value that is set by this instruction. 9754 9755 Peephole optimization, which takes place together with final 9756 assembly code output, can produce insns whose patterns consist of 9757 a `parallel' whose elements are the operands needed to output the 9758 resulting assembler code--often `reg', `mem' or constant 9759 expressions. This would not be well-formed RTL at any other stage 9760 in compilation, but it is ok then because no further optimization 9761 remains to be done. However, the definition of the macro 9762 `NOTICE_UPDATE_CC', if any, must deal with such insns if you 9763 define any peephole optimizations. 9764 9765 `(cond_exec [COND EXPR])' 9766 Represents a conditionally executed expression. The EXPR is 9767 executed only if the COND is nonzero. The COND expression must 9768 not have side-effects, but the EXPR may very well have 9769 side-effects. 9770 9771 `(sequence [INSNS ...])' 9772 Represents a sequence of insns. Each of the INSNS that appears in 9773 the vector is suitable for appearing in the chain of insns, so it 9774 must be an `insn', `jump_insn', `call_insn', `code_label', 9775 `barrier' or `note'. 9776 9777 A `sequence' RTX is never placed in an actual insn during RTL 9778 generation. It represents the sequence of insns that result from a 9779 `define_expand' _before_ those insns are passed to `emit_insn' to 9780 insert them in the chain of insns. When actually inserted, the 9781 individual sub-insns are separated out and the `sequence' is 9782 forgotten. 9783 9784 After delay-slot scheduling is completed, an insn and all the 9785 insns that reside in its delay slots are grouped together into a 9786 `sequence'. The insn requiring the delay slot is the first insn 9787 in the vector; subsequent insns are to be placed in the delay slot. 9788 9789 `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 9790 indicate that a branch insn should be used that will conditionally 9791 annul the effect of the insns in the delay slots. In such a case, 9792 `INSN_FROM_TARGET_P' indicates that the insn is from the target of 9793 the branch and should be executed only if the branch is taken; 9794 otherwise the insn should be executed only if the branch is not 9795 taken. *Note Delay Slots::. 9796 9797 These expression codes appear in place of a side effect, as the body of 9798 an insn, though strictly speaking they do not always describe side 9799 effects as such: 9800 9801 `(asm_input S)' 9802 Represents literal assembler code as described by the string S. 9803 9804 `(unspec [OPERANDS ...] INDEX)' 9805 `(unspec_volatile [OPERANDS ...] INDEX)' 9806 Represents a machine-specific operation on OPERANDS. INDEX 9807 selects between multiple machine-specific operations. 9808 `unspec_volatile' is used for volatile operations and operations 9809 that may trap; `unspec' is used for other operations. 9810 9811 These codes may appear inside a `pattern' of an insn, inside a 9812 `parallel', or inside an expression. 9813 9814 `(addr_vec:M [LR0 LR1 ...])' 9815 Represents a table of jump addresses. The vector elements LR0, 9816 etc., are `label_ref' expressions. The mode M specifies how much 9817 space is given to each address; normally M would be `Pmode'. 9818 9819 `(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 9820 Represents a table of jump addresses expressed as offsets from 9821 BASE. The vector elements LR0, etc., are `label_ref' expressions 9822 and so is BASE. The mode M specifies how much space is given to 9823 each address-difference. MIN and MAX are set up by branch 9824 shortening and hold a label with a minimum and a maximum address, 9825 respectively. FLAGS indicates the relative position of BASE, MIN 9826 and MAX to the containing insn and of MIN and MAX to BASE. See 9827 rtl.def for details. 9828 9829 `(prefetch:M ADDR RW LOCALITY)' 9830 Represents prefetch of memory at address ADDR. Operand RW is 1 if 9831 the prefetch is for data to be written, 0 otherwise; targets that 9832 do not support write prefetches should treat this as a normal 9833 prefetch. Operand LOCALITY specifies the amount of temporal 9834 locality; 0 if there is none or 1, 2, or 3 for increasing levels 9835 of temporal locality; targets that do not support locality hints 9836 should ignore this. 9837 9838 This insn is used to minimize cache-miss latency by moving data 9839 into a cache before it is accessed. It should use only 9840 non-faulting data prefetch instructions. 9841 9842 9843 File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 9844 9845 10.16 Embedded Side-Effects on Addresses 9846 ======================================== 9847 9848 Six special side-effect expression codes appear as memory addresses. 9849 9850 `(pre_dec:M X)' 9851 Represents the side effect of decrementing X by a standard amount 9852 and represents also the value that X has after being decremented. 9853 X must be a `reg' or `mem', but most machines allow only a `reg'. 9854 M must be the machine mode for pointers on the machine in use. 9855 The amount X is decremented by is the length in bytes of the 9856 machine mode of the containing memory reference of which this 9857 expression serves as the address. Here is an example of its use: 9858 9859 (mem:DF (pre_dec:SI (reg:SI 39))) 9860 9861 This says to decrement pseudo register 39 by the length of a 9862 `DFmode' value and use the result to address a `DFmode' value. 9863 9864 `(pre_inc:M X)' 9865 Similar, but specifies incrementing X instead of decrementing it. 9866 9867 `(post_dec:M X)' 9868 Represents the same side effect as `pre_dec' but a different 9869 value. The value represented here is the value X has before being 9870 decremented. 9871 9872 `(post_inc:M X)' 9873 Similar, but specifies incrementing X instead of decrementing it. 9874 9875 `(post_modify:M X Y)' 9876 Represents the side effect of setting X to Y and represents X 9877 before X is modified. X must be a `reg' or `mem', but most 9878 machines allow only a `reg'. M must be the machine mode for 9879 pointers on the machine in use. 9880 9881 The expression Y must be one of three forms: `(plus:M X Z)', 9882 `(minus:M X Z)', or `(plus:M X I)', where Z is an index register 9883 and I is a constant. 9884 9885 Here is an example of its use: 9886 9887 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 9888 (reg:SI 48)))) 9889 9890 This says to modify pseudo register 42 by adding the contents of 9891 pseudo register 48 to it, after the use of what ever 42 points to. 9892 9893 `(pre_modify:M X EXPR)' 9894 Similar except side effects happen before the use. 9895 9896 These embedded side effect expressions must be used with care. 9897 Instruction patterns may not use them. Until the `flow' pass of the 9898 compiler, they may occur only to represent pushes onto the stack. The 9899 `flow' pass finds cases where registers are incremented or decremented 9900 in one instruction and used as an address shortly before or after; 9901 these cases are then transformed to use pre- or post-increment or 9902 -decrement. 9903 9904 If a register used as the operand of these expressions is used in 9905 another address in an insn, the original value of the register is used. 9906 Uses of the register outside of an address are not permitted within the 9907 same insn as a use in an embedded side effect expression because such 9908 insns behave differently on different machines and hence must be treated 9909 as ambiguous and disallowed. 9910 9911 An instruction that can be represented with an embedded side effect 9912 could also be represented using `parallel' containing an additional 9913 `set' to describe how the address register is altered. This is not 9914 done because machines that allow these operations at all typically 9915 allow them wherever a memory address is called for. Describing them as 9916 additional parallel stores would require doubling the number of entries 9917 in the machine description. 9918 9919 9920 File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 9921 9922 10.17 Assembler Instructions as Expressions 9923 =========================================== 9924 9925 The RTX code `asm_operands' represents a value produced by a 9926 user-specified assembler instruction. It is used to represent an `asm' 9927 statement with arguments. An `asm' statement with a single output 9928 operand, like this: 9929 9930 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 9931 9932 is represented using a single `asm_operands' RTX which represents the 9933 value that is stored in `outputvar': 9934 9935 (set RTX-FOR-OUTPUTVAR 9936 (asm_operands "foo %1,%2,%0" "a" 0 9937 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 9938 [(asm_input:M1 "g") 9939 (asm_input:M2 "di")])) 9940 9941 Here the operands of the `asm_operands' RTX are the assembler template 9942 string, the output-operand's constraint, the index-number of the output 9943 operand among the output operands specified, a vector of input operand 9944 RTX's, and a vector of input-operand modes and constraints. The mode 9945 M1 is the mode of the sum `x+y'; M2 is that of `*z'. 9946 9947 When an `asm' statement has multiple output values, its insn has 9948 several such `set' RTX's inside of a `parallel'. Each `set' contains 9949 an `asm_operands'; all of these share the same assembler template and 9950 vectors, but each contains the constraint for the respective output 9951 operand. They are also distinguished by the output-operand index 9952 number, which is 0, 1, ... for successive output operands. 9953 9954 9955 File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 9956 9957 10.18 Variable Location Debug Information in RTL 9958 ================================================ 9959 9960 Variable tracking relies on `MEM_EXPR' and `REG_EXPR' annotations to 9961 determine what user variables memory and register references refer to. 9962 9963 Variable tracking at assignments uses these notes only when they refer 9964 to variables that live at fixed locations (e.g., addressable variables, 9965 global non-automatic variables). For variables whose location may 9966 vary, it relies on the following types of notes. 9967 9968 `(var_location:MODE VAR EXP STAT)' 9969 Binds variable `var', a tree, to value EXP, an RTL expression. It 9970 appears only in `NOTE_INSN_VAR_LOCATION' and `DEBUG_INSN's, with 9971 slightly different meanings. MODE, if present, represents the 9972 mode of EXP, which is useful if it is a modeless expression. STAT 9973 is only meaningful in notes, indicating whether the variable is 9974 known to be initialized or uninitialized. 9975 9976 `(debug_expr:MODE DECL)' 9977 Stands for the value bound to the `DEBUG_EXPR_DECL' DECL, that 9978 points back to it, within value expressions in `VAR_LOCATION' 9979 nodes. 9980 9981 9982 9983 File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 9984 9985 10.19 Insns 9986 =========== 9987 9988 The RTL representation of the code for a function is a doubly-linked 9989 chain of objects called "insns". Insns are expressions with special 9990 codes that are used for no other purpose. Some insns are actual 9991 instructions; others represent dispatch tables for `switch' statements; 9992 others represent labels to jump to or various sorts of declarative 9993 information. 9994 9995 In addition to its own specific data, each insn must have a unique 9996 id-number that distinguishes it from all other insns in the current 9997 function (after delayed branch scheduling, copies of an insn with the 9998 same id-number may be present in multiple places in a function, but 9999 these copies will always be identical and will only appear inside a 10000 `sequence'), and chain pointers to the preceding and following insns. 10001 These three fields occupy the same position in every insn, independent 10002 of the expression code of the insn. They could be accessed with `XEXP' 10003 and `XINT', but instead three special macros are always used: 10004 10005 `INSN_UID (I)' 10006 Accesses the unique id of insn I. 10007 10008 `PREV_INSN (I)' 10009 Accesses the chain pointer to the insn preceding I. If I is the 10010 first insn, this is a null pointer. 10011 10012 `NEXT_INSN (I)' 10013 Accesses the chain pointer to the insn following I. If I is the 10014 last insn, this is a null pointer. 10015 10016 The first insn in the chain is obtained by calling `get_insns'; the 10017 last insn is the result of calling `get_last_insn'. Within the chain 10018 delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must 10019 always correspond: if INSN is not the first insn, 10020 10021 NEXT_INSN (PREV_INSN (INSN)) == INSN 10022 10023 is always true and if INSN is not the last insn, 10024 10025 PREV_INSN (NEXT_INSN (INSN)) == INSN 10026 10027 is always true. 10028 10029 After delay slot scheduling, some of the insns in the chain might be 10030 `sequence' expressions, which contain a vector of insns. The value of 10031 `NEXT_INSN' in all but the last of these insns is the next insn in the 10032 vector; the value of `NEXT_INSN' of the last insn in the vector is the 10033 same as the value of `NEXT_INSN' for the `sequence' in which it is 10034 contained. Similar rules apply for `PREV_INSN'. 10035 10036 This means that the above invariants are not necessarily true for insns 10037 inside `sequence' expressions. Specifically, if INSN is the first insn 10038 in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn containing 10039 the `sequence' expression, as is the value of `PREV_INSN (NEXT_INSN 10040 (INSN))' if INSN is the last insn in the `sequence' expression. You 10041 can use these expressions to find the containing `sequence' expression. 10042 10043 Every insn has one of the following expression codes: 10044 10045 `insn' 10046 The expression code `insn' is used for instructions that do not 10047 jump and do not do function calls. `sequence' expressions are 10048 always contained in insns with code `insn' even if one of those 10049 insns should jump or do function calls. 10050 10051 Insns with code `insn' have four additional fields beyond the three 10052 mandatory ones listed above. These four are described in a table 10053 below. 10054 10055 `jump_insn' 10056 The expression code `jump_insn' is used for instructions that may 10057 jump (or, more generally, may contain `label_ref' expressions to 10058 which `pc' can be set in that instruction). If there is an 10059 instruction to return from the current function, it is recorded as 10060 a `jump_insn'. 10061 10062 `jump_insn' insns have the same extra fields as `insn' insns, 10063 accessed in the same way and in addition contain a field 10064 `JUMP_LABEL' which is defined once jump optimization has completed. 10065 10066 For simple conditional and unconditional jumps, this field contains 10067 the `code_label' to which this insn will (possibly conditionally) 10068 branch. In a more complex jump, `JUMP_LABEL' records one of the 10069 labels that the insn refers to; other jump target labels are 10070 recorded as `REG_LABEL_TARGET' notes. The exception is `addr_vec' 10071 and `addr_diff_vec', where `JUMP_LABEL' is `NULL_RTX' and the only 10072 way to find the labels is to scan the entire body of the insn. 10073 10074 Return insns count as jumps, but since they do not refer to any 10075 labels, their `JUMP_LABEL' is `NULL_RTX'. 10076 10077 `call_insn' 10078 The expression code `call_insn' is used for instructions that may 10079 do function calls. It is important to distinguish these 10080 instructions because they imply that certain registers and memory 10081 locations may be altered unpredictably. 10082 10083 `call_insn' insns have the same extra fields as `insn' insns, 10084 accessed in the same way and in addition contain a field 10085 `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 10086 `expr_list' expressions) containing `use' and `clobber' 10087 expressions that denote hard registers and `MEM's used or 10088 clobbered by the called function. 10089 10090 A `MEM' generally points to a stack slots in which arguments passed 10091 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 10092 Register Arguments.) are stored. If the argument is caller-copied 10093 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 10094 will be mentioned in `CLOBBER' and `USE' entries; if it's 10095 callee-copied, only a `USE' will appear, and the `MEM' may point 10096 to addresses that are not stack slots. 10097 10098 `CLOBBER'ed registers in this list augment registers specified in 10099 `CALL_USED_REGISTERS' (*note Register Basics::). 10100 10101 `code_label' 10102 A `code_label' insn represents a label that a jump insn can jump 10103 to. It contains two special fields of data in addition to the 10104 three standard ones. `CODE_LABEL_NUMBER' is used to hold the 10105 "label number", a number that identifies this label uniquely among 10106 all the labels in the compilation (not just in the current 10107 function). Ultimately, the label is represented in the assembler 10108 output as an assembler label, usually of the form `LN' where N is 10109 the label number. 10110 10111 When a `code_label' appears in an RTL expression, it normally 10112 appears within a `label_ref' which represents the address of the 10113 label, as a number. 10114 10115 Besides as a `code_label', a label can also be represented as a 10116 `note' of type `NOTE_INSN_DELETED_LABEL'. 10117 10118 The field `LABEL_NUSES' is only defined once the jump optimization 10119 phase is completed. It contains the number of times this label is 10120 referenced in the current function. 10121 10122 The field `LABEL_KIND' differentiates four different types of 10123 labels: `LABEL_NORMAL', `LABEL_STATIC_ENTRY', 10124 `LABEL_GLOBAL_ENTRY', and `LABEL_WEAK_ENTRY'. The only labels 10125 that do not have type `LABEL_NORMAL' are "alternate entry points" 10126 to the current function. These may be static (visible only in the 10127 containing translation unit), global (exposed to all translation 10128 units), or weak (global, but can be overridden by another symbol 10129 with the same name). 10130 10131 Much of the compiler treats all four kinds of label identically. 10132 Some of it needs to know whether or not a label is an alternate 10133 entry point; for this purpose, the macro `LABEL_ALT_ENTRY_P' is 10134 provided. It is equivalent to testing whether `LABEL_KIND (label) 10135 == LABEL_NORMAL'. The only place that cares about the distinction 10136 between static, global, and weak alternate entry points, besides 10137 the front-end code that creates them, is the function 10138 `output_alternate_entry_point', in `final.c'. 10139 10140 To set the kind of a label, use the `SET_LABEL_KIND' macro. 10141 10142 `barrier' 10143 Barriers are placed in the instruction stream when control cannot 10144 flow past them. They are placed after unconditional jump 10145 instructions to indicate that the jumps are unconditional and 10146 after calls to `volatile' functions, which do not return (e.g., 10147 `exit'). They contain no information beyond the three standard 10148 fields. 10149 10150 `note' 10151 `note' insns are used to represent additional debugging and 10152 declarative information. They contain two nonstandard fields, an 10153 integer which is accessed with the macro `NOTE_LINE_NUMBER' and a 10154 string accessed with `NOTE_SOURCE_FILE'. 10155 10156 If `NOTE_LINE_NUMBER' is positive, the note represents the 10157 position of a source line and `NOTE_SOURCE_FILE' is the source 10158 file name that the line came from. These notes control generation 10159 of line number data in the assembler output. 10160 10161 Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a 10162 code with one of the following values (and `NOTE_SOURCE_FILE' must 10163 contain a null pointer): 10164 10165 `NOTE_INSN_DELETED' 10166 Such a note is completely ignorable. Some passes of the 10167 compiler delete insns by altering them into notes of this 10168 kind. 10169 10170 `NOTE_INSN_DELETED_LABEL' 10171 This marks what used to be a `code_label', but was not used 10172 for other purposes than taking its address and was 10173 transformed to mark that no code jumps to it. 10174 10175 `NOTE_INSN_BLOCK_BEG' 10176 `NOTE_INSN_BLOCK_END' 10177 These types of notes indicate the position of the beginning 10178 and end of a level of scoping of variable names. They 10179 control the output of debugging information. 10180 10181 `NOTE_INSN_EH_REGION_BEG' 10182 `NOTE_INSN_EH_REGION_END' 10183 These types of notes indicate the position of the beginning 10184 and end of a level of scoping for exception handling. 10185 `NOTE_BLOCK_NUMBER' identifies which `CODE_LABEL' or `note' 10186 of type `NOTE_INSN_DELETED_LABEL' is associated with the 10187 given region. 10188 10189 `NOTE_INSN_LOOP_BEG' 10190 `NOTE_INSN_LOOP_END' 10191 These types of notes indicate the position of the beginning 10192 and end of a `while' or `for' loop. They enable the loop 10193 optimizer to find loops quickly. 10194 10195 `NOTE_INSN_LOOP_CONT' 10196 Appears at the place in a loop that `continue' statements 10197 jump to. 10198 10199 `NOTE_INSN_LOOP_VTOP' 10200 This note indicates the place in a loop where the exit test 10201 begins for those loops in which the exit test has been 10202 duplicated. This position becomes another virtual start of 10203 the loop when considering loop invariants. 10204 10205 `NOTE_INSN_FUNCTION_BEG' 10206 Appears at the start of the function body, after the function 10207 prologue. 10208 10209 `NOTE_INSN_VAR_LOCATION' 10210 This note is used to generate variable location debugging 10211 information. It indicates that the user variable in its 10212 `VAR_LOCATION' operand is at the location given in the RTL 10213 expression, or holds a value that can be computed by 10214 evaluating the RTL expression from that static point in the 10215 program up to the next such note for the same user variable. 10216 10217 10218 These codes are printed symbolically when they appear in debugging 10219 dumps. 10220 10221 `debug_insn' 10222 The expression code `debug_insn' is used for pseudo-instructions 10223 that hold debugging information for variable tracking at 10224 assignments (see `-fvar-tracking-assignments' option). They are 10225 the RTL representation of `GIMPLE_DEBUG' statements (*note 10226 `GIMPLE_DEBUG'::), with a `VAR_LOCATION' operand that binds a user 10227 variable tree to an RTL representation of the `value' in the 10228 corresponding statement. A `DEBUG_EXPR' in it stands for the 10229 value bound to the corresponding `DEBUG_EXPR_DECL'. 10230 10231 Throughout optimization passes, binding information is kept in 10232 pseudo-instruction form, so that, unlike notes, it gets the same 10233 treatment and adjustments that regular instructions would. It is 10234 the variable tracking pass that turns these pseudo-instructions 10235 into var location notes, analyzing control flow, value 10236 equivalences and changes to registers and memory referenced in 10237 value expressions, propagating the values of debug temporaries and 10238 determining expressions that can be used to compute the value of 10239 each user variable at as many points (ranges, actually) in the 10240 program as possible. 10241 10242 Unlike `NOTE_INSN_VAR_LOCATION', the value expression in an 10243 `INSN_VAR_LOCATION' denotes a value at that specific point in the 10244 program, rather than an expression that can be evaluated at any 10245 later point before an overriding `VAR_LOCATION' is encountered. 10246 E.g., if a user variable is bound to a `REG' and then a subsequent 10247 insn modifies the `REG', the note location would keep mapping the 10248 user variable to the register across the insn, whereas the insn 10249 location would keep the variable bound to the value, so that the 10250 variable tracking pass would emit another location note for the 10251 variable at the point in which the register is modified. 10252 10253 10254 The machine mode of an insn is normally `VOIDmode', but some phases 10255 use the mode for various purposes. 10256 10257 The common subexpression elimination pass sets the mode of an insn to 10258 `QImode' when it is the first insn in a block that has already been 10259 processed. 10260 10261 The second Haifa scheduling pass, for targets that can multiple issue, 10262 sets the mode of an insn to `TImode' when it is believed that the 10263 instruction begins an issue group. That is, when the instruction 10264 cannot issue simultaneously with the previous. This may be relied on 10265 by later passes, in particular machine-dependent reorg. 10266 10267 Here is a table of the extra fields of `insn', `jump_insn' and 10268 `call_insn' insns: 10269 10270 `PATTERN (I)' 10271 An expression for the side effect performed by this insn. This 10272 must be one of the following codes: `set', `call', `use', 10273 `clobber', `return', `asm_input', `asm_output', `addr_vec', 10274 `addr_diff_vec', `trap_if', `unspec', `unspec_volatile', 10275 `parallel', `cond_exec', or `sequence'. If it is a `parallel', 10276 each element of the `parallel' must be one these codes, except that 10277 `parallel' expressions cannot be nested and `addr_vec' and 10278 `addr_diff_vec' are not permitted inside a `parallel' expression. 10279 10280 `INSN_CODE (I)' 10281 An integer that says which pattern in the machine description 10282 matches this insn, or -1 if the matching has not yet been 10283 attempted. 10284 10285 Such matching is never attempted and this field remains -1 on an 10286 insn whose pattern consists of a single `use', `clobber', 10287 `asm_input', `addr_vec' or `addr_diff_vec' expression. 10288 10289 Matching is also never attempted on insns that result from an `asm' 10290 statement. These contain at least one `asm_operands' expression. 10291 The function `asm_noperands' returns a non-negative value for such 10292 insns. 10293 10294 In the debugging output, this field is printed as a number 10295 followed by a symbolic representation that locates the pattern in 10296 the `md' file as some small positive or negative offset from a 10297 named pattern. 10298 10299 `LOG_LINKS (I)' 10300 A list (chain of `insn_list' expressions) giving information about 10301 dependencies between instructions within a basic block. Neither a 10302 jump nor a label may come between the related insns. These are 10303 only used by the schedulers and by combine. This is a deprecated 10304 data structure. Def-use and use-def chains are now preferred. 10305 10306 `REG_NOTES (I)' 10307 A list (chain of `expr_list' and `insn_list' expressions) giving 10308 miscellaneous information about the insn. It is often information 10309 pertaining to the registers used in this insn. 10310 10311 The `LOG_LINKS' field of an insn is a chain of `insn_list' 10312 expressions. Each of these has two operands: the first is an insn, and 10313 the second is another `insn_list' expression (the next one in the 10314 chain). The last `insn_list' in the chain has a null pointer as second 10315 operand. The significant thing about the chain is which insns appear 10316 in it (as first operands of `insn_list' expressions). Their order is 10317 not significant. 10318 10319 This list is originally set up by the flow analysis pass; it is a null 10320 pointer until then. Flow only adds links for those data dependencies 10321 which can be used for instruction combination. For each insn, the flow 10322 analysis pass adds a link to insns which store into registers values 10323 that are used for the first time in this insn. 10324 10325 The `REG_NOTES' field of an insn is a chain similar to the `LOG_LINKS' 10326 field but it includes `expr_list' expressions in addition to 10327 `insn_list' expressions. There are several kinds of register notes, 10328 which are distinguished by the machine mode, which in a register note 10329 is really understood as being an `enum reg_note'. The first operand OP 10330 of the note is data whose meaning depends on the kind of note. 10331 10332 The macro `REG_NOTE_KIND (X)' returns the kind of register note. Its 10333 counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 10334 register note type of X to be NEWKIND. 10335 10336 Register notes are of three classes: They may say something about an 10337 input to an insn, they may say something about an output of an insn, or 10338 they may create a linkage between two insns. There are also a set of 10339 values that are only used in `LOG_LINKS'. 10340 10341 These register notes annotate inputs to an insn: 10342 10343 `REG_DEAD' 10344 The value in OP dies in this insn; that is to say, altering the 10345 value immediately after this insn would not affect the future 10346 behavior of the program. 10347 10348 It does not follow that the register OP has no useful value after 10349 this insn since OP is not necessarily modified by this insn. 10350 Rather, no subsequent instruction uses the contents of OP. 10351 10352 `REG_UNUSED' 10353 The register OP being set by this insn will not be used in a 10354 subsequent insn. This differs from a `REG_DEAD' note, which 10355 indicates that the value in an input will not be used subsequently. 10356 These two notes are independent; both may be present for the same 10357 register. 10358 10359 `REG_INC' 10360 The register OP is incremented (or decremented; at this level 10361 there is no distinction) by an embedded side effect inside this 10362 insn. This means it appears in a `post_inc', `pre_inc', 10363 `post_dec' or `pre_dec' expression. 10364 10365 `REG_NONNEG' 10366 The register OP is known to have a nonnegative value when this 10367 insn is reached. This is used so that decrement and branch until 10368 zero instructions, such as the m68k dbra, can be matched. 10369 10370 The `REG_NONNEG' note is added to insns only if the machine 10371 description has a `decrement_and_branch_until_zero' pattern. 10372 10373 `REG_LABEL_OPERAND' 10374 This insn uses OP, a `code_label' or a `note' of type 10375 `NOTE_INSN_DELETED_LABEL', but is not a `jump_insn', or it is a 10376 `jump_insn' that refers to the operand as an ordinary operand. 10377 The label may still eventually be a jump target, but if so in an 10378 indirect jump in a subsequent insn. The presence of this note 10379 allows jump optimization to be aware that OP is, in fact, being 10380 used, and flow optimization to build an accurate flow graph. 10381 10382 `REG_LABEL_TARGET' 10383 This insn is a `jump_insn' but not an `addr_vec' or 10384 `addr_diff_vec'. It uses OP, a `code_label' as a direct or 10385 indirect jump target. Its purpose is similar to that of 10386 `REG_LABEL_OPERAND'. This note is only present if the insn has 10387 multiple targets; the last label in the insn (in the highest 10388 numbered insn-field) goes into the `JUMP_LABEL' field and does not 10389 have a `REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 10390 10391 `REG_CROSSING_JUMP' 10392 This insn is a branching instruction (either an unconditional jump 10393 or an indirect jump) which crosses between hot and cold sections, 10394 which could potentially be very far apart in the executable. The 10395 presence of this note indicates to other optimizations that this 10396 branching instruction should not be "collapsed" into a simpler 10397 branching construct. It is used when the optimization to 10398 partition basic blocks into hot and cold sections is turned on. 10399 10400 `REG_SETJMP' 10401 Appears attached to each `CALL_INSN' to `setjmp' or a related 10402 function. 10403 10404 The following notes describe attributes of outputs of an insn: 10405 10406 `REG_EQUIV' 10407 `REG_EQUAL' 10408 This note is only valid on an insn that sets only one register and 10409 indicates that that register will be equal to OP at run time; the 10410 scope of this equivalence differs between the two types of notes. 10411 The value which the insn explicitly copies into the register may 10412 look different from OP, but they will be equal at run time. If the 10413 output of the single `set' is a `strict_low_part' expression, the 10414 note refers to the register that is contained in `SUBREG_REG' of 10415 the `subreg' expression. 10416 10417 For `REG_EQUIV', the register is equivalent to OP throughout the 10418 entire function, and could validly be replaced in all its 10419 occurrences by OP. ("Validly" here refers to the data flow of the 10420 program; simple replacement may make some insns invalid.) For 10421 example, when a constant is loaded into a register that is never 10422 assigned any other value, this kind of note is used. 10423 10424 When a parameter is copied into a pseudo-register at entry to a 10425 function, a note of this kind records that the register is 10426 equivalent to the stack slot where the parameter was passed. 10427 Although in this case the register may be set by other insns, it 10428 is still valid to replace the register by the stack slot 10429 throughout the function. 10430 10431 A `REG_EQUIV' note is also used on an instruction which copies a 10432 register parameter into a pseudo-register at entry to a function, 10433 if there is a stack slot where that parameter could be stored. 10434 Although other insns may set the pseudo-register, it is valid for 10435 the compiler to replace the pseudo-register by stack slot 10436 throughout the function, provided the compiler ensures that the 10437 stack slot is properly initialized by making the replacement in 10438 the initial copy instruction as well. This is used on machines 10439 for which the calling convention allocates stack space for 10440 register parameters. See `REG_PARM_STACK_SPACE' in *note Stack 10441 Arguments::. 10442 10443 In the case of `REG_EQUAL', the register that is set by this insn 10444 will be equal to OP at run time at the end of this insn but not 10445 necessarily elsewhere in the function. In this case, OP is 10446 typically an arithmetic expression. For example, when a sequence 10447 of insns such as a library call is used to perform an arithmetic 10448 operation, this kind of note is attached to the insn that produces 10449 or copies the final value. 10450 10451 These two notes are used in different ways by the compiler passes. 10452 `REG_EQUAL' is used by passes prior to register allocation (such as 10453 common subexpression elimination and loop optimization) to tell 10454 them how to think of that value. `REG_EQUIV' notes are used by 10455 register allocation to indicate that there is an available 10456 substitute expression (either a constant or a `mem' expression for 10457 the location of a parameter on the stack) that may be used in 10458 place of a register if insufficient registers are available. 10459 10460 Except for stack homes for parameters, which are indicated by a 10461 `REG_EQUIV' note and are not useful to the early optimization 10462 passes and pseudo registers that are equivalent to a memory 10463 location throughout their entire life, which is not detected until 10464 later in the compilation, all equivalences are initially indicated 10465 by an attached `REG_EQUAL' note. In the early stages of register 10466 allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note 10467 if OP is a constant and the insn represents the only set of its 10468 destination register. 10469 10470 Thus, compiler passes prior to register allocation need only check 10471 for `REG_EQUAL' notes and passes subsequent to register allocation 10472 need only check for `REG_EQUIV' notes. 10473 10474 These notes describe linkages between insns. They occur in pairs: one 10475 insn has one of a pair of notes that points to a second insn, which has 10476 the inverse note pointing back to the first insn. 10477 10478 `REG_CC_SETTER' 10479 `REG_CC_USER' 10480 On machines that use `cc0', the insns which set and use `cc0' set 10481 and use `cc0' are adjacent. However, when branch delay slot 10482 filling is done, this may no longer be true. In this case a 10483 `REG_CC_USER' note will be placed on the insn setting `cc0' to 10484 point to the insn using `cc0' and a `REG_CC_SETTER' note will be 10485 placed on the insn using `cc0' to point to the insn setting `cc0'. 10486 10487 These values are only used in the `LOG_LINKS' field, and indicate the 10488 type of dependency that each link represents. Links which indicate a 10489 data dependence (a read after write dependence) do not use any code, 10490 they simply have mode `VOIDmode', and are printed without any 10491 descriptive text. 10492 10493 `REG_DEP_TRUE' 10494 This indicates a true dependence (a read after write dependence). 10495 10496 `REG_DEP_OUTPUT' 10497 This indicates an output dependence (a write after write 10498 dependence). 10499 10500 `REG_DEP_ANTI' 10501 This indicates an anti dependence (a write after read dependence). 10502 10503 10504 These notes describe information gathered from gcov profile data. They 10505 are stored in the `REG_NOTES' field of an insn as an `expr_list'. 10506 10507 `REG_BR_PROB' 10508 This is used to specify the ratio of branches to non-branches of a 10509 branch insn according to the profile data. The value is stored as 10510 a value between 0 and REG_BR_PROB_BASE; larger values indicate a 10511 higher probability that the branch will be taken. 10512 10513 `REG_BR_PRED' 10514 These notes are found in JUMP insns after delayed branch scheduling 10515 has taken place. They indicate both the direction and the 10516 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 10517 values. 10518 10519 `REG_FRAME_RELATED_EXPR' 10520 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 10521 expression is used in place of the actual insn pattern. This is 10522 done in cases where the pattern is either complex or misleading. 10523 10524 For convenience, the machine mode in an `insn_list' or `expr_list' is 10525 printed using these symbolic codes in debugging dumps. 10526 10527 The only difference between the expression codes `insn_list' and 10528 `expr_list' is that the first operand of an `insn_list' is assumed to 10529 be an insn and is printed in debugging dumps as the insn's unique id; 10530 the first operand of an `expr_list' is printed in the ordinary way as 10531 an expression. 10532 10533 10534 File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 10535 10536 10.20 RTL Representation of Function-Call Insns 10537 =============================================== 10538 10539 Insns that call subroutines have the RTL expression code `call_insn'. 10540 These insns must satisfy special rules, and their bodies must use a 10541 special RTL expression code, `call'. 10542 10543 A `call' expression has two operands, as follows: 10544 10545 (call (mem:FM ADDR) NBYTES) 10546 10547 Here NBYTES is an operand that represents the number of bytes of 10548 argument data being passed to the subroutine, FM is a machine mode 10549 (which must equal as the definition of the `FUNCTION_MODE' macro in the 10550 machine description) and ADDR represents the address of the subroutine. 10551 10552 For a subroutine that returns no value, the `call' expression as shown 10553 above is the entire body of the insn, except that the insn might also 10554 contain `use' or `clobber' expressions. 10555 10556 For a subroutine that returns a value whose mode is not `BLKmode', the 10557 value is returned in a hard register. If this register's number is R, 10558 then the body of the call insn looks like this: 10559 10560 (set (reg:M R) 10561 (call (mem:FM ADDR) NBYTES)) 10562 10563 This RTL expression makes it clear (to the optimizer passes) that the 10564 appropriate register receives a useful value in this insn. 10565 10566 When a subroutine returns a `BLKmode' value, it is handled by passing 10567 to the subroutine the address of a place to store the value. So the 10568 call insn itself does not "return" any value, and it has the same RTL 10569 form as a call that returns nothing. 10570 10571 On some machines, the call instruction itself clobbers some register, 10572 for example to contain the return address. `call_insn' insns on these 10573 machines should have a body which is a `parallel' that contains both 10574 the `call' expression and `clobber' expressions that indicate which 10575 registers are destroyed. Similarly, if the call instruction requires 10576 some register other than the stack pointer that is not explicitly 10577 mentioned in its RTL, a `use' subexpression should mention that 10578 register. 10579 10580 Functions that are called are assumed to modify all registers listed in 10581 the configuration macro `CALL_USED_REGISTERS' (*note Register Basics::) 10582 and, with the exception of `const' functions and library calls, to 10583 modify all of memory. 10584 10585 Insns containing just `use' expressions directly precede the 10586 `call_insn' insn to indicate which registers contain inputs to the 10587 function. Similarly, if registers other than those in 10588 `CALL_USED_REGISTERS' are clobbered by the called function, insns 10589 containing a single `clobber' follow immediately after the call to 10590 indicate which registers. 10591 10592 10593 File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 10594 10595 10.21 Structure Sharing Assumptions 10596 =================================== 10597 10598 The compiler assumes that certain kinds of RTL expressions are unique; 10599 there do not exist two distinct objects representing the same value. 10600 In other cases, it makes an opposite assumption: that no RTL expression 10601 object of a certain kind appears in more than one place in the 10602 containing structure. 10603 10604 These assumptions refer to a single function; except for the RTL 10605 objects that describe global variables and external functions, and a 10606 few standard objects such as small integer constants, no RTL objects 10607 are common to two functions. 10608 10609 * Each pseudo-register has only a single `reg' object to represent 10610 it, and therefore only a single machine mode. 10611 10612 * For any symbolic label, there is only one `symbol_ref' object 10613 referring to it. 10614 10615 * All `const_int' expressions with equal values are shared. 10616 10617 * There is only one `pc' expression. 10618 10619 * There is only one `cc0' expression. 10620 10621 * There is only one `const_double' expression with value 0 for each 10622 floating point mode. Likewise for values 1 and 2. 10623 10624 * There is only one `const_vector' expression with value 0 for each 10625 vector mode, be it an integer or a double constant vector. 10626 10627 * No `label_ref' or `scratch' appears in more than one place in the 10628 RTL structure; in other words, it is safe to do a tree-walk of all 10629 the insns in the function and assume that each time a `label_ref' 10630 or `scratch' is seen it is distinct from all others that are seen. 10631 10632 * Only one `mem' object is normally created for each static variable 10633 or stack slot, so these objects are frequently shared in all the 10634 places they appear. However, separate but equal objects for these 10635 variables are occasionally made. 10636 10637 * When a single `asm' statement has multiple output operands, a 10638 distinct `asm_operands' expression is made for each output operand. 10639 However, these all share the vector which contains the sequence of 10640 input operands. This sharing is used later on to test whether two 10641 `asm_operands' expressions come from the same statement, so all 10642 optimizations must carefully preserve the sharing if they copy the 10643 vector at all. 10644 10645 * No RTL object appears in more than one place in the RTL structure 10646 except as described above. Many passes of the compiler rely on 10647 this by assuming that they can modify RTL objects in place without 10648 unwanted side-effects on other insns. 10649 10650 * During initial RTL generation, shared structure is freely 10651 introduced. After all the RTL for a function has been generated, 10652 all shared structure is copied by `unshare_all_rtl' in 10653 `emit-rtl.c', after which the above rules are guaranteed to be 10654 followed. 10655 10656 * During the combiner pass, shared structure within an insn can exist 10657 temporarily. However, the shared structure is copied before the 10658 combiner is finished with the insn. This is done by calling 10659 `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'. 10660 10661 10662 File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 10663 10664 10.22 Reading RTL 10665 ================= 10666 10667 To read an RTL object from a file, call `read_rtx'. It takes one 10668 argument, a stdio stream, and returns a single RTL object. This routine 10669 is defined in `read-rtl.c'. It is not available in the compiler 10670 itself, only the various programs that generate the compiler back end 10671 from the machine description. 10672 10673 People frequently have the idea of using RTL stored as text in a file 10674 as an interface between a language front end and the bulk of GCC. This 10675 idea is not feasible. 10676 10677 GCC was designed to use RTL internally only. Correct RTL for a given 10678 program is very dependent on the particular target machine. And the RTL 10679 does not contain all the information about the program. 10680 10681 The proper way to interface GCC to a new language front end is with 10682 the "tree" data structure, described in the files `tree.h' and 10683 `tree.def'. The documentation for this structure (*note GENERIC::) is 10684 incomplete. 10685 10686 10687 File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: Passes, Up: Top 10688 10689 11 GENERIC 10690 ********** 10691 10692 The purpose of GENERIC is simply to provide a language-independent way 10693 of representing an entire function in trees. To this end, it was 10694 necessary to add a few new tree codes to the back end, but most 10695 everything was already there. If you can express it with the codes in 10696 `gcc/tree.def', it's GENERIC. 10697 10698 Early on, there was a great deal of debate about how to think about 10699 statements in a tree IL. In GENERIC, a statement is defined as any 10700 expression whose value, if any, is ignored. A statement will always 10701 have `TREE_SIDE_EFFECTS' set (or it will be discarded), but a 10702 non-statement expression may also have side effects. A `CALL_EXPR', 10703 for instance. 10704 10705 It would be possible for some local optimizations to work on the 10706 GENERIC form of a function; indeed, the adapted tree inliner works fine 10707 on GENERIC, but the current compiler performs inlining after lowering 10708 to GIMPLE (a restricted form described in the next section). Indeed, 10709 currently the frontends perform this lowering before handing off to 10710 `tree_rest_of_compilation', but this seems inelegant. 10711 10712 * Menu: 10713 10714 * Deficiencies:: Topics net yet covered in this document. 10715 * Tree overview:: All about `tree's. 10716 * Types:: Fundamental and aggregate types. 10717 * Declarations:: Type declarations and variables. 10718 * Attributes:: Declaration and type attributes. 10719 * Expressions: Expression trees. Operating on data. 10720 * Statements:: Control flow and related trees. 10721 * Functions:: Function bodies, linkage, and other aspects. 10722 * Language-dependent trees:: Topics and trees specific to language front ends. 10723 * C and C++ Trees:: Trees specific to C and C++. 10724 * Java Trees:: Trees specific to Java. 10725 10726 10727 File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 10728 10729 11.1 Deficiencies 10730 ================= 10731 10732 There are many places in which this document is incomplet and incorrekt. 10733 It is, as of yet, only _preliminary_ documentation. 10734 10735 10736 File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 10737 10738 11.2 Overview 10739 ============= 10740 10741 The central data structure used by the internal representation is the 10742 `tree'. These nodes, while all of the C type `tree', are of many 10743 varieties. A `tree' is a pointer type, but the object to which it 10744 points may be of a variety of types. From this point forward, we will 10745 refer to trees in ordinary type, rather than in `this font', except 10746 when talking about the actual C type `tree'. 10747 10748 You can tell what kind of node a particular tree is by using the 10749 `TREE_CODE' macro. Many, many macros take trees as input and return 10750 trees as output. However, most macros require a certain kind of tree 10751 node as input. In other words, there is a type-system for trees, but 10752 it is not reflected in the C type-system. 10753 10754 For safety, it is useful to configure GCC with `--enable-checking'. 10755 Although this results in a significant performance penalty (since all 10756 tree types are checked at run-time), and is therefore inappropriate in a 10757 release version, it is extremely helpful during the development process. 10758 10759 Many macros behave as predicates. Many, although not all, of these 10760 predicates end in `_P'. Do not rely on the result type of these macros 10761 being of any particular type. You may, however, rely on the fact that 10762 the type can be compared to `0', so that statements like 10763 if (TEST_P (t) && !TEST_P (y)) 10764 x = 1; 10765 and 10766 int i = (TEST_P (t) != 0); 10767 are legal. Macros that return `int' values now may be changed to 10768 return `tree' values, or other pointers in the future. Even those that 10769 continue to return `int' may return multiple nonzero codes where 10770 previously they returned only zero and one. Therefore, you should not 10771 write code like 10772 if (TEST_P (t) == 1) 10773 as this code is not guaranteed to work correctly in the future. 10774 10775 You should not take the address of values returned by the macros or 10776 functions described here. In particular, no guarantee is given that the 10777 values are lvalues. 10778 10779 In general, the names of macros are all in uppercase, while the names 10780 of functions are entirely in lowercase. There are rare exceptions to 10781 this rule. You should assume that any macro or function whose name is 10782 made up entirely of uppercase letters may evaluate its arguments more 10783 than once. You may assume that a macro or function whose name is made 10784 up entirely of lowercase letters will evaluate its arguments only once. 10785 10786 The `error_mark_node' is a special tree. Its tree code is 10787 `ERROR_MARK', but since there is only ever one node with that code, the 10788 usual practice is to compare the tree against `error_mark_node'. (This 10789 test is just a test for pointer equality.) If an error has occurred 10790 during front-end processing the flag `errorcount' will be set. If the 10791 front end has encountered code it cannot handle, it will issue a 10792 message to the user and set `sorrycount'. When these flags are set, 10793 any macro or function which normally returns a tree of a particular 10794 kind may instead return the `error_mark_node'. Thus, if you intend to 10795 do any processing of erroneous code, you must be prepared to deal with 10796 the `error_mark_node'. 10797 10798 Occasionally, a particular tree slot (like an operand to an expression, 10799 or a particular field in a declaration) will be referred to as 10800 "reserved for the back end". These slots are used to store RTL when 10801 the tree is converted to RTL for use by the GCC back end. However, if 10802 that process is not taking place (e.g., if the front end is being hooked 10803 up to an intelligent editor), then those slots may be used by the back 10804 end presently in use. 10805 10806 If you encounter situations that do not match this documentation, such 10807 as tree nodes of types not mentioned here, or macros documented to 10808 return entities of a particular kind that instead return entities of 10809 some different kind, you have found a bug, either in the front end or in 10810 the documentation. Please report these bugs as you would any other bug. 10811 10812 * Menu: 10813 10814 * Macros and Functions::Macros and functions that can be used with all trees. 10815 * Identifiers:: The names of things. 10816 * Containers:: Lists and vectors. 10817 10818 10819 File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 10820 10821 11.2.1 Trees 10822 ------------ 10823 10824 All GENERIC trees have two fields in common. First, `TREE_CHAIN' is a 10825 pointer that can be used as a singly-linked list to other trees. The 10826 other is `TREE_TYPE'. Many trees store the type of an expression or 10827 declaration in this field. 10828 10829 These are some other functions for handling trees: 10830 10831 `tree_size' 10832 Return the number of bytes a tree takes. 10833 10834 `build0' 10835 `build1' 10836 `build2' 10837 `build3' 10838 `build4' 10839 `build5' 10840 `build6' 10841 These functions build a tree and supply values to put in each 10842 parameter. The basic signature is `code, type, [operands]'. 10843 `code' is the `TREE_CODE', and `type' is a tree representing the 10844 `TREE_TYPE'. These are followed by the operands, each of which is 10845 also a tree. 10846 10847 10848 10849 File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 10850 10851 11.2.2 Identifiers 10852 ------------------ 10853 10854 An `IDENTIFIER_NODE' represents a slightly more general concept that 10855 the standard C or C++ concept of identifier. In particular, an 10856 `IDENTIFIER_NODE' may contain a `$', or other extraordinary characters. 10857 10858 There are never two distinct `IDENTIFIER_NODE's representing the same 10859 identifier. Therefore, you may use pointer equality to compare 10860 `IDENTIFIER_NODE's, rather than using a routine like `strcmp'. Use 10861 `get_identifier' to obtain the unique `IDENTIFIER_NODE' for a supplied 10862 string. 10863 10864 You can use the following macros to access identifiers: 10865 `IDENTIFIER_POINTER' 10866 The string represented by the identifier, represented as a 10867 `char*'. This string is always `NUL'-terminated, and contains no 10868 embedded `NUL' characters. 10869 10870 `IDENTIFIER_LENGTH' 10871 The length of the string returned by `IDENTIFIER_POINTER', not 10872 including the trailing `NUL'. This value of `IDENTIFIER_LENGTH 10873 (x)' is always the same as `strlen (IDENTIFIER_POINTER (x))'. 10874 10875 `IDENTIFIER_OPNAME_P' 10876 This predicate holds if the identifier represents the name of an 10877 overloaded operator. In this case, you should not depend on the 10878 contents of either the `IDENTIFIER_POINTER' or the 10879 `IDENTIFIER_LENGTH'. 10880 10881 `IDENTIFIER_TYPENAME_P' 10882 This predicate holds if the identifier represents the name of a 10883 user-defined conversion operator. In this case, the `TREE_TYPE' of 10884 the `IDENTIFIER_NODE' holds the type to which the conversion 10885 operator converts. 10886 10887 10888 10889 File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 10890 10891 11.2.3 Containers 10892 ----------------- 10893 10894 Two common container data structures can be represented directly with 10895 tree nodes. A `TREE_LIST' is a singly linked list containing two trees 10896 per node. These are the `TREE_PURPOSE' and `TREE_VALUE' of each node. 10897 (Often, the `TREE_PURPOSE' contains some kind of tag, or additional 10898 information, while the `TREE_VALUE' contains the majority of the 10899 payload. In other cases, the `TREE_PURPOSE' is simply `NULL_TREE', 10900 while in still others both the `TREE_PURPOSE' and `TREE_VALUE' are of 10901 equal stature.) Given one `TREE_LIST' node, the next node is found by 10902 following the `TREE_CHAIN'. If the `TREE_CHAIN' is `NULL_TREE', then 10903 you have reached the end of the list. 10904 10905 A `TREE_VEC' is a simple vector. The `TREE_VEC_LENGTH' is an integer 10906 (not a tree) giving the number of nodes in the vector. The nodes 10907 themselves are accessed using the `TREE_VEC_ELT' macro, which takes two 10908 arguments. The first is the `TREE_VEC' in question; the second is an 10909 integer indicating which element in the vector is desired. The 10910 elements are indexed from zero. 10911 10912 10913 File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 10914 10915 11.3 Types 10916 ========== 10917 10918 All types have corresponding tree nodes. However, you should not assume 10919 that there is exactly one tree node corresponding to each type. There 10920 are often multiple nodes corresponding to the same type. 10921 10922 For the most part, different kinds of types have different tree codes. 10923 (For example, pointer types use a `POINTER_TYPE' code while arrays use 10924 an `ARRAY_TYPE' code.) However, pointers to member functions use the 10925 `RECORD_TYPE' code. Therefore, when writing a `switch' statement that 10926 depends on the code associated with a particular type, you should take 10927 care to handle pointers to member functions under the `RECORD_TYPE' 10928 case label. 10929 10930 The following functions and macros deal with cv-qualification of types: 10931 `TYPE_MAIN_VARIANT' 10932 This macro returns the unqualified version of a type. It may be 10933 applied to an unqualified type, but it is not always the identity 10934 function in that case. 10935 10936 A few other macros and functions are usable with all types: 10937 `TYPE_SIZE' 10938 The number of bits required to represent the type, represented as 10939 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 10940 `NULL_TREE'. 10941 10942 `TYPE_ALIGN' 10943 The alignment of the type, in bits, represented as an `int'. 10944 10945 `TYPE_NAME' 10946 This macro returns a declaration (in the form of a `TYPE_DECL') for 10947 the type. (Note this macro does _not_ return an 10948 `IDENTIFIER_NODE', as you might expect, given its name!) You can 10949 look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual 10950 name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type 10951 that is not a built-in type, the result of a typedef, or a named 10952 class type. 10953 10954 `TYPE_CANONICAL' 10955 This macro returns the "canonical" type for the given type node. 10956 Canonical types are used to improve performance in the C++ and 10957 Objective-C++ front ends by allowing efficient comparison between 10958 two type nodes in `same_type_p': if the `TYPE_CANONICAL' values of 10959 the types are equal, the types are equivalent; otherwise, the types 10960 are not equivalent. The notion of equivalence for canonical types 10961 is the same as the notion of type equivalence in the language 10962 itself. For instance, 10963 10964 When `TYPE_CANONICAL' is `NULL_TREE', there is no canonical type 10965 for the given type node. In this case, comparison between this 10966 type and any other type requires the compiler to perform a deep, 10967 "structural" comparison to see if the two type nodes have the same 10968 form and properties. 10969 10970 The canonical type for a node is always the most fundamental type 10971 in the equivalence class of types. For instance, `int' is its own 10972 canonical type. A typedef `I' of `int' will have `int' as its 10973 canonical type. Similarly, `I*' and a typedef `IP' (defined to 10974 `I*') will has `int*' as their canonical type. When building a new 10975 type node, be sure to set `TYPE_CANONICAL' to the appropriate 10976 canonical type. If the new type is a compound type (built from 10977 other types), and any of those other types require structural 10978 equality, use `SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the 10979 new type also requires structural equality. Finally, if for some 10980 reason you cannot guarantee that `TYPE_CANONICAL' will point to 10981 the canonical type, use `SET_TYPE_STRUCTURAL_EQUALITY' to make 10982 sure that the new type-and any type constructed based on 10983 it-requires structural equality. If you suspect that the canonical 10984 type system is miscomparing types, pass `--param 10985 verify-canonical-types=1' to the compiler or configure with 10986 `--enable-checking' to force the compiler to verify its 10987 canonical-type comparisons against the structural comparisons; the 10988 compiler will then print any warnings if the canonical types 10989 miscompare. 10990 10991 `TYPE_STRUCTURAL_EQUALITY_P' 10992 This predicate holds when the node requires structural equality 10993 checks, e.g., when `TYPE_CANONICAL' is `NULL_TREE'. 10994 10995 `SET_TYPE_STRUCTURAL_EQUALITY' 10996 This macro states that the type node it is given requires 10997 structural equality checks, e.g., it sets `TYPE_CANONICAL' to 10998 `NULL_TREE'. 10999 11000 `same_type_p' 11001 This predicate takes two types as input, and holds if they are the 11002 same type. For example, if one type is a `typedef' for the other, 11003 or both are `typedef's for the same type. This predicate also 11004 holds if the two trees given as input are simply copies of one 11005 another; i.e., there is no difference between them at the source 11006 level, but, for whatever reason, a duplicate has been made in the 11007 representation. You should never use `==' (pointer equality) to 11008 compare types; always use `same_type_p' instead. 11009 11010 Detailed below are the various kinds of types, and the macros that can 11011 be used to access them. Although other kinds of types are used 11012 elsewhere in G++, the types described here are the only ones that you 11013 will encounter while examining the intermediate representation. 11014 11015 `VOID_TYPE' 11016 Used to represent the `void' type. 11017 11018 `INTEGER_TYPE' 11019 Used to represent the various integral types, including `char', 11020 `short', `int', `long', and `long long'. This code is not used 11021 for enumeration types, nor for the `bool' type. The 11022 `TYPE_PRECISION' is the number of bits used in the representation, 11023 represented as an `unsigned int'. (Note that in the general case 11024 this is not the same value as `TYPE_SIZE'; suppose that there were 11025 a 24-bit integer type, but that alignment requirements for the ABI 11026 required 32-bit alignment. Then, `TYPE_SIZE' would be an 11027 `INTEGER_CST' for 32, while `TYPE_PRECISION' would be 24.) The 11028 integer type is unsigned if `TYPE_UNSIGNED' holds; otherwise, it 11029 is signed. 11030 11031 The `TYPE_MIN_VALUE' is an `INTEGER_CST' for the smallest integer 11032 that may be represented by this type. Similarly, the 11033 `TYPE_MAX_VALUE' is an `INTEGER_CST' for the largest integer that 11034 may be represented by this type. 11035 11036 `REAL_TYPE' 11037 Used to represent the `float', `double', and `long double' types. 11038 The number of bits in the floating-point representation is given 11039 by `TYPE_PRECISION', as in the `INTEGER_TYPE' case. 11040 11041 `FIXED_POINT_TYPE' 11042 Used to represent the `short _Fract', `_Fract', `long _Fract', 11043 `long long _Fract', `short _Accum', `_Accum', `long _Accum', and 11044 `long long _Accum' types. The number of bits in the fixed-point 11045 representation is given by `TYPE_PRECISION', as in the 11046 `INTEGER_TYPE' case. There may be padding bits, fractional bits 11047 and integral bits. The number of fractional bits is given by 11048 `TYPE_FBIT', and the number of integral bits is given by 11049 `TYPE_IBIT'. The fixed-point type is unsigned if `TYPE_UNSIGNED' 11050 holds; otherwise, it is signed. The fixed-point type is 11051 saturating if `TYPE_SATURATING' holds; otherwise, it is not 11052 saturating. 11053 11054 `COMPLEX_TYPE' 11055 Used to represent GCC built-in `__complex__' data types. The 11056 `TREE_TYPE' is the type of the real and imaginary parts. 11057 11058 `ENUMERAL_TYPE' 11059 Used to represent an enumeration type. The `TYPE_PRECISION' gives 11060 (as an `int'), the number of bits used to represent the type. If 11061 there are no negative enumeration constants, `TYPE_UNSIGNED' will 11062 hold. The minimum and maximum enumeration constants may be 11063 obtained with `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE', respectively; 11064 each of these macros returns an `INTEGER_CST'. 11065 11066 The actual enumeration constants themselves may be obtained by 11067 looking at the `TYPE_VALUES'. This macro will return a 11068 `TREE_LIST', containing the constants. The `TREE_PURPOSE' of each 11069 node will be an `IDENTIFIER_NODE' giving the name of the constant; 11070 the `TREE_VALUE' will be an `INTEGER_CST' giving the value 11071 assigned to that constant. These constants will appear in the 11072 order in which they were declared. The `TREE_TYPE' of each of 11073 these constants will be the type of enumeration type itself. 11074 11075 `BOOLEAN_TYPE' 11076 Used to represent the `bool' type. 11077 11078 `POINTER_TYPE' 11079 Used to represent pointer types, and pointer to data member types. 11080 The `TREE_TYPE' gives the type to which this type points. 11081 11082 `REFERENCE_TYPE' 11083 Used to represent reference types. The `TREE_TYPE' gives the type 11084 to which this type refers. 11085 11086 `FUNCTION_TYPE' 11087 Used to represent the type of non-member functions and of static 11088 member functions. The `TREE_TYPE' gives the return type of the 11089 function. The `TYPE_ARG_TYPES' are a `TREE_LIST' of the argument 11090 types. The `TREE_VALUE' of each node in this list is the type of 11091 the corresponding argument; the `TREE_PURPOSE' is an expression 11092 for the default argument value, if any. If the last node in the 11093 list is `void_list_node' (a `TREE_LIST' node whose `TREE_VALUE' is 11094 the `void_type_node'), then functions of this type do not take 11095 variable arguments. Otherwise, they do take a variable number of 11096 arguments. 11097 11098 Note that in C (but not in C++) a function declared like `void f()' 11099 is an unprototyped function taking a variable number of arguments; 11100 the `TYPE_ARG_TYPES' of such a function will be `NULL'. 11101 11102 `METHOD_TYPE' 11103 Used to represent the type of a non-static member function. Like a 11104 `FUNCTION_TYPE', the return type is given by the `TREE_TYPE'. The 11105 type of `*this', i.e., the class of which functions of this type 11106 are a member, is given by the `TYPE_METHOD_BASETYPE'. The 11107 `TYPE_ARG_TYPES' is the parameter list, as for a `FUNCTION_TYPE', 11108 and includes the `this' argument. 11109 11110 `ARRAY_TYPE' 11111 Used to represent array types. The `TREE_TYPE' gives the type of 11112 the elements in the array. If the array-bound is present in the 11113 type, the `TYPE_DOMAIN' is an `INTEGER_TYPE' whose 11114 `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE' will be the lower and upper 11115 bounds of the array, respectively. The `TYPE_MIN_VALUE' will 11116 always be an `INTEGER_CST' for zero, while the `TYPE_MAX_VALUE' 11117 will be one less than the number of elements in the array, i.e., 11118 the highest value which may be used to index an element in the 11119 array. 11120 11121 `RECORD_TYPE' 11122 Used to represent `struct' and `class' types, as well as pointers 11123 to member functions and similar constructs in other languages. 11124 `TYPE_FIELDS' contains the items contained in this type, each of 11125 which can be a `FIELD_DECL', `VAR_DECL', `CONST_DECL', or 11126 `TYPE_DECL'. You may not make any assumptions about the ordering 11127 of the fields in the type or whether one or more of them overlap. 11128 11129 `UNION_TYPE' 11130 Used to represent `union' types. Similar to `RECORD_TYPE' except 11131 that all `FIELD_DECL' nodes in `TYPE_FIELD' start at bit position 11132 zero. 11133 11134 `QUAL_UNION_TYPE' 11135 Used to represent part of a variant record in Ada. Similar to 11136 `UNION_TYPE' except that each `FIELD_DECL' has a `DECL_QUALIFIER' 11137 field, which contains a boolean expression that indicates whether 11138 the field is present in the object. The type will only have one 11139 field, so each field's `DECL_QUALIFIER' is only evaluated if none 11140 of the expressions in the previous fields in `TYPE_FIELDS' are 11141 nonzero. Normally these expressions will reference a field in the 11142 outer object using a `PLACEHOLDER_EXPR'. 11143 11144 `LANG_TYPE' 11145 This node is used to represent a language-specific type. The front 11146 end must handle it. 11147 11148 `OFFSET_TYPE' 11149 This node is used to represent a pointer-to-data member. For a 11150 data member `X::m' the `TYPE_OFFSET_BASETYPE' is `X' and the 11151 `TREE_TYPE' is the type of `m'. 11152 11153 11154 There are variables whose values represent some of the basic types. 11155 These include: 11156 `void_type_node' 11157 A node for `void'. 11158 11159 `integer_type_node' 11160 A node for `int'. 11161 11162 `unsigned_type_node.' 11163 A node for `unsigned int'. 11164 11165 `char_type_node.' 11166 A node for `char'. 11167 It may sometimes be useful to compare one of these variables with a 11168 type in hand, using `same_type_p'. 11169 11170 11171 File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 11172 11173 11.4 Declarations 11174 ================= 11175 11176 This section covers the various kinds of declarations that appear in the 11177 internal representation, except for declarations of functions 11178 (represented by `FUNCTION_DECL' nodes), which are described in *note 11179 Functions::. 11180 11181 * Menu: 11182 11183 * Working with declarations:: Macros and functions that work on 11184 declarations. 11185 * Internal structure:: How declaration nodes are represented. 11186 11187 11188 File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 11189 11190 11.4.1 Working with declarations 11191 -------------------------------- 11192 11193 Some macros can be used with any kind of declaration. These include: 11194 `DECL_NAME' 11195 This macro returns an `IDENTIFIER_NODE' giving the name of the 11196 entity. 11197 11198 `TREE_TYPE' 11199 This macro returns the type of the entity declared. 11200 11201 `EXPR_FILENAME' 11202 This macro returns the name of the file in which the entity was 11203 declared, as a `char*'. For an entity declared implicitly by the 11204 compiler (like `__builtin_memcpy'), this will be the string 11205 `"<internal>"'. 11206 11207 `EXPR_LINENO' 11208 This macro returns the line number at which the entity was 11209 declared, as an `int'. 11210 11211 `DECL_ARTIFICIAL' 11212 This predicate holds if the declaration was implicitly generated 11213 by the compiler. For example, this predicate will hold of an 11214 implicitly declared member function, or of the `TYPE_DECL' 11215 implicitly generated for a class type. Recall that in C++ code 11216 like: 11217 struct S {}; 11218 is roughly equivalent to C code like: 11219 struct S {}; 11220 typedef struct S S; 11221 The implicitly generated `typedef' declaration is represented by a 11222 `TYPE_DECL' for which `DECL_ARTIFICIAL' holds. 11223 11224 11225 The various kinds of declarations include: 11226 `LABEL_DECL' 11227 These nodes are used to represent labels in function bodies. For 11228 more information, see *note Functions::. These nodes only appear 11229 in block scopes. 11230 11231 `CONST_DECL' 11232 These nodes are used to represent enumeration constants. The 11233 value of the constant is given by `DECL_INITIAL' which will be an 11234 `INTEGER_CST' with the same type as the `TREE_TYPE' of the 11235 `CONST_DECL', i.e., an `ENUMERAL_TYPE'. 11236 11237 `RESULT_DECL' 11238 These nodes represent the value returned by a function. When a 11239 value is assigned to a `RESULT_DECL', that indicates that the 11240 value should be returned, via bitwise copy, by the function. You 11241 can use `DECL_SIZE' and `DECL_ALIGN' on a `RESULT_DECL', just as 11242 with a `VAR_DECL'. 11243 11244 `TYPE_DECL' 11245 These nodes represent `typedef' declarations. The `TREE_TYPE' is 11246 the type declared to have the name given by `DECL_NAME'. In some 11247 cases, there is no associated name. 11248 11249 `VAR_DECL' 11250 These nodes represent variables with namespace or block scope, as 11251 well as static data members. The `DECL_SIZE' and `DECL_ALIGN' are 11252 analogous to `TYPE_SIZE' and `TYPE_ALIGN'. For a declaration, you 11253 should always use the `DECL_SIZE' and `DECL_ALIGN' rather than the 11254 `TYPE_SIZE' and `TYPE_ALIGN' given by the `TREE_TYPE', since 11255 special attributes may have been applied to the variable to give 11256 it a particular size and alignment. You may use the predicates 11257 `DECL_THIS_STATIC' or `DECL_THIS_EXTERN' to test whether the 11258 storage class specifiers `static' or `extern' were used to declare 11259 a variable. 11260 11261 If this variable is initialized (but does not require a 11262 constructor), the `DECL_INITIAL' will be an expression for the 11263 initializer. The initializer should be evaluated, and a bitwise 11264 copy into the variable performed. If the `DECL_INITIAL' is the 11265 `error_mark_node', there is an initializer, but it is given by an 11266 explicit statement later in the code; no bitwise copy is required. 11267 11268 GCC provides an extension that allows either automatic variables, 11269 or global variables, to be placed in particular registers. This 11270 extension is being used for a particular `VAR_DECL' if 11271 `DECL_REGISTER' holds for the `VAR_DECL', and if 11272 `DECL_ASSEMBLER_NAME' is not equal to `DECL_NAME'. In that case, 11273 `DECL_ASSEMBLER_NAME' is the name of the register into which the 11274 variable will be placed. 11275 11276 `PARM_DECL' 11277 Used to represent a parameter to a function. Treat these nodes 11278 similarly to `VAR_DECL' nodes. These nodes only appear in the 11279 `DECL_ARGUMENTS' for a `FUNCTION_DECL'. 11280 11281 The `DECL_ARG_TYPE' for a `PARM_DECL' is the type that will 11282 actually be used when a value is passed to this function. It may 11283 be a wider type than the `TREE_TYPE' of the parameter; for 11284 example, the ordinary type might be `short' while the 11285 `DECL_ARG_TYPE' is `int'. 11286 11287 `DEBUG_EXPR_DECL' 11288 Used to represent an anonymous debug-information temporary created 11289 to hold an expression as it is optimized away, so that its value 11290 can be referenced in debug bind statements. 11291 11292 `FIELD_DECL' 11293 These nodes represent non-static data members. The `DECL_SIZE' and 11294 `DECL_ALIGN' behave as for `VAR_DECL' nodes. The position of the 11295 field within the parent record is specified by a combination of 11296 three attributes. `DECL_FIELD_OFFSET' is the position, counting 11297 in bytes, of the `DECL_OFFSET_ALIGN'-bit sized word containing the 11298 bit of the field closest to the beginning of the structure. 11299 `DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 11300 field within this word; this may be nonzero even for fields that 11301 are not bit-fields, since `DECL_OFFSET_ALIGN' may be greater than 11302 the natural alignment of the field's type. 11303 11304 If `DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 11305 bit-field, `DECL_BIT_FIELD_TYPE' also contains the type that was 11306 originally specified for it, while DECL_TYPE may be a modified 11307 type with lesser precision, according to the size of the bit field. 11308 11309 `NAMESPACE_DECL' 11310 Namespaces provide a name hierarchy for other declarations. They 11311 appear in the `DECL_CONTEXT' of other `_DECL' nodes. 11312 11313 11314 11315 File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 11316 11317 11.4.2 Internal structure 11318 ------------------------- 11319 11320 `DECL' nodes are represented internally as a hierarchy of structures. 11321 11322 * Menu: 11323 11324 * Current structure hierarchy:: The current DECL node structure 11325 hierarchy. 11326 * Adding new DECL node types:: How to add a new DECL node to a 11327 frontend. 11328 11329 11330 File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 11331 11332 11.4.2.1 Current structure hierarchy 11333 .................................... 11334 11335 `struct tree_decl_minimal' 11336 This is the minimal structure to inherit from in order for common 11337 `DECL' macros to work. The fields it contains are a unique ID, 11338 source location, context, and name. 11339 11340 `struct tree_decl_common' 11341 This structure inherits from `struct tree_decl_minimal'. It 11342 contains fields that most `DECL' nodes need, such as a field to 11343 store alignment, machine mode, size, and attributes. 11344 11345 `struct tree_field_decl' 11346 This structure inherits from `struct tree_decl_common'. It is 11347 used to represent `FIELD_DECL'. 11348 11349 `struct tree_label_decl' 11350 This structure inherits from `struct tree_decl_common'. It is 11351 used to represent `LABEL_DECL'. 11352 11353 `struct tree_translation_unit_decl' 11354 This structure inherits from `struct tree_decl_common'. It is 11355 used to represent `TRANSLATION_UNIT_DECL'. 11356 11357 `struct tree_decl_with_rtl' 11358 This structure inherits from `struct tree_decl_common'. It 11359 contains a field to store the low-level RTL associated with a 11360 `DECL' node. 11361 11362 `struct tree_result_decl' 11363 This structure inherits from `struct tree_decl_with_rtl'. It is 11364 used to represent `RESULT_DECL'. 11365 11366 `struct tree_const_decl' 11367 This structure inherits from `struct tree_decl_with_rtl'. It is 11368 used to represent `CONST_DECL'. 11369 11370 `struct tree_parm_decl' 11371 This structure inherits from `struct tree_decl_with_rtl'. It is 11372 used to represent `PARM_DECL'. 11373 11374 `struct tree_decl_with_vis' 11375 This structure inherits from `struct tree_decl_with_rtl'. It 11376 contains fields necessary to store visibility information, as well 11377 as a section name and assembler name. 11378 11379 `struct tree_var_decl' 11380 This structure inherits from `struct tree_decl_with_vis'. It is 11381 used to represent `VAR_DECL'. 11382 11383 `struct tree_function_decl' 11384 This structure inherits from `struct tree_decl_with_vis'. It is 11385 used to represent `FUNCTION_DECL'. 11386 11387 11388 11389 File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 11390 11391 11.4.2.2 Adding new DECL node types 11392 ................................... 11393 11394 Adding a new `DECL' tree consists of the following steps 11395 11396 Add a new tree code for the `DECL' node 11397 For language specific `DECL' nodes, there is a `.def' file in each 11398 frontend directory where the tree code should be added. For 11399 `DECL' nodes that are part of the middle-end, the code should be 11400 added to `tree.def'. 11401 11402 Create a new structure type for the `DECL' node 11403 These structures should inherit from one of the existing 11404 structures in the language hierarchy by using that structure as 11405 the first member. 11406 11407 struct tree_foo_decl 11408 { 11409 struct tree_decl_with_vis common; 11410 } 11411 11412 Would create a structure name `tree_foo_decl' that inherits from 11413 `struct tree_decl_with_vis'. 11414 11415 For language specific `DECL' nodes, this new structure type should 11416 go in the appropriate `.h' file. For `DECL' nodes that are part 11417 of the middle-end, the structure type should go in `tree.h'. 11418 11419 Add a member to the tree structure enumerator for the node 11420 For garbage collection and dynamic checking purposes, each `DECL' 11421 node structure type is required to have a unique enumerator value 11422 specified with it. For language specific `DECL' nodes, this new 11423 enumerator value should go in the appropriate `.def' file. For 11424 `DECL' nodes that are part of the middle-end, the enumerator 11425 values are specified in `treestruct.def'. 11426 11427 Update `union tree_node' 11428 In order to make your new structure type usable, it must be added 11429 to `union tree_node'. For language specific `DECL' nodes, a new 11430 entry should be added to the appropriate `.h' file of the form 11431 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 11432 For `DECL' nodes that are part of the middle-end, the additional 11433 member goes directly into `union tree_node' in `tree.h'. 11434 11435 Update dynamic checking info 11436 In order to be able to check whether accessing a named portion of 11437 `union tree_node' is legal, and whether a certain `DECL' node 11438 contains one of the enumerated `DECL' node structures in the 11439 hierarchy, a simple lookup table is used. This lookup table needs 11440 to be kept up to date with the tree structure hierarchy, or else 11441 checking and containment macros will fail inappropriately. 11442 11443 For language specific `DECL' nodes, their is an `init_ts' function 11444 in an appropriate `.c' file, which initializes the lookup table. 11445 Code setting up the table for new `DECL' nodes should be added 11446 there. For each `DECL' tree code and enumerator value 11447 representing a member of the inheritance hierarchy, the table 11448 should contain 1 if that tree code inherits (directly or 11449 indirectly) from that member. Thus, a `FOO_DECL' node derived 11450 from `struct decl_with_rtl', and enumerator value `TS_FOO_DECL', 11451 would be set up as follows 11452 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 11453 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 11454 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 11455 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 11456 11457 For `DECL' nodes that are part of the middle-end, the setup code 11458 goes into `tree.c'. 11459 11460 Add macros to access any new fields and flags 11461 Each added field or flag should have a macro that is used to access 11462 it, that performs appropriate checking to ensure only the right 11463 type of `DECL' nodes access the field. 11464 11465 These macros generally take the following form 11466 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 11467 However, if the structure is simply a base class for further 11468 structures, something like the following should be used 11469 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 11470 #define BASE_STRUCT_FIELDNAME(NODE) \ 11471 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 11472 11473 11474 11475 File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 11476 11477 11.5 Attributes in trees 11478 ======================== 11479 11480 Attributes, as specified using the `__attribute__' keyword, are 11481 represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the 11482 name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a 11483 `TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE' 11484 if there are no arguments; the arguments are stored as the `TREE_VALUE' 11485 of successive entries in the list, and may be identifiers or 11486 expressions. The `TREE_CHAIN' of the attribute is the next attribute 11487 in a list of attributes applying to the same declaration or type, or 11488 `NULL_TREE' if there are no further attributes in the list. 11489 11490 Attributes may be attached to declarations and to types; these 11491 attributes may be accessed with the following macros. All attributes 11492 are stored in this way, and many also cause other changes to the 11493 declaration or type or to other internal compiler data structures. 11494 11495 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 11496 This macro returns the attributes on the declaration DECL. 11497 11498 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 11499 This macro returns the attributes on the type TYPE. 11500 11501 11502 File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 11503 11504 11.6 Expressions 11505 ================ 11506 11507 The internal representation for expressions is for the most part quite 11508 straightforward. However, there are a few facts that one must bear in 11509 mind. In particular, the expression "tree" is actually a directed 11510 acyclic graph. (For example there may be many references to the integer 11511 constant zero throughout the source program; many of these will be 11512 represented by the same expression node.) You should not rely on 11513 certain kinds of node being shared, nor should you rely on certain 11514 kinds of nodes being unshared. 11515 11516 The following macros can be used with all expression nodes: 11517 11518 `TREE_TYPE' 11519 Returns the type of the expression. This value may not be 11520 precisely the same type that would be given the expression in the 11521 original program. 11522 11523 In what follows, some nodes that one might expect to always have type 11524 `bool' are documented to have either integral or boolean type. At some 11525 point in the future, the C front end may also make use of this same 11526 intermediate representation, and at this point these nodes will 11527 certainly have integral type. The previous sentence is not meant to 11528 imply that the C++ front end does not or will not give these nodes 11529 integral type. 11530 11531 Below, we list the various kinds of expression nodes. Except where 11532 noted otherwise, the operands to an expression are accessed using the 11533 `TREE_OPERAND' macro. For example, to access the first operand to a 11534 binary plus expression `expr', use: 11535 11536 TREE_OPERAND (expr, 0) 11537 As this example indicates, the operands are zero-indexed. 11538 11539 * Menu: 11540 11541 * Constants: Constant expressions. 11542 * Storage References:: 11543 * Unary and Binary Expressions:: 11544 * Vectors:: 11545 11546 11547 File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 11548 11549 11.6.1 Constant expressions 11550 --------------------------- 11551 11552 The table below begins with constants, moves on to unary expressions, 11553 then proceeds to binary expressions, and concludes with various other 11554 kinds of expressions: 11555 11556 `INTEGER_CST' 11557 These nodes represent integer constants. Note that the type of 11558 these constants is obtained with `TREE_TYPE'; they are not always 11559 of type `int'. In particular, `char' constants are represented 11560 with `INTEGER_CST' nodes. The value of the integer constant `e' is 11561 given by 11562 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT) 11563 + TREE_INST_CST_LOW (e)) 11564 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms. 11565 Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a 11566 `HOST_WIDE_INT'. The value of an `INTEGER_CST' is interpreted as 11567 a signed or unsigned quantity depending on the type of the 11568 constant. In general, the expression given above will overflow, 11569 so it should not be used to calculate the value of the constant. 11570 11571 The variable `integer_zero_node' is an integer constant with value 11572 zero. Similarly, `integer_one_node' is an integer constant with 11573 value one. The `size_zero_node' and `size_one_node' variables are 11574 analogous, but have type `size_t' rather than `int'. 11575 11576 The function `tree_int_cst_lt' is a predicate which holds if its 11577 first argument is less than its second. Both constants are 11578 assumed to have the same signedness (i.e., either both should be 11579 signed or both should be unsigned.) The full width of the 11580 constant is used when doing the comparison; the usual rules about 11581 promotions and conversions are ignored. Similarly, 11582 `tree_int_cst_equal' holds if the two constants are equal. The 11583 `tree_int_cst_sgn' function returns the sign of a constant. The 11584 value is `1', `0', or `-1' according on whether the constant is 11585 greater than, equal to, or less than zero. Again, the signedness 11586 of the constant's type is taken into account; an unsigned constant 11587 is never less than zero, no matter what its bit-pattern. 11588 11589 `REAL_CST' 11590 FIXME: Talk about how to obtain representations of this constant, 11591 do comparisons, and so forth. 11592 11593 `FIXED_CST' 11594 These nodes represent fixed-point constants. The type of these 11595 constants is obtained with `TREE_TYPE'. `TREE_FIXED_CST_PTR' 11596 points to a `struct fixed_value'; `TREE_FIXED_CST' returns the 11597 structure itself. `struct fixed_value' contains `data' with the 11598 size of two `HOST_BITS_PER_WIDE_INT' and `mode' as the associated 11599 fixed-point machine mode for `data'. 11600 11601 `COMPLEX_CST' 11602 These nodes are used to represent complex number constants, that 11603 is a `__complex__' whose parts are constant nodes. The 11604 `TREE_REALPART' and `TREE_IMAGPART' return the real and the 11605 imaginary parts respectively. 11606 11607 `VECTOR_CST' 11608 These nodes are used to represent vector constants, whose parts are 11609 constant nodes. Each individual constant node is either an 11610 integer or a double constant node. The first operand is a 11611 `TREE_LIST' of the constant nodes and is accessed through 11612 `TREE_VECTOR_CST_ELTS'. 11613 11614 `STRING_CST' 11615 These nodes represent string-constants. The `TREE_STRING_LENGTH' 11616 returns the length of the string, as an `int'. The 11617 `TREE_STRING_POINTER' is a `char*' containing the string itself. 11618 The string may not be `NUL'-terminated, and it may contain 11619 embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH' 11620 includes the trailing `NUL' if it is present. 11621 11622 For wide string constants, the `TREE_STRING_LENGTH' is the number 11623 of bytes in the string, and the `TREE_STRING_POINTER' points to an 11624 array of the bytes of the string, as represented on the target 11625 system (that is, as integers in the target endianness). Wide and 11626 non-wide string constants are distinguished only by the `TREE_TYPE' 11627 of the `STRING_CST'. 11628 11629 FIXME: The formats of string constants are not well-defined when 11630 the target system bytes are not the same width as host system 11631 bytes. 11632 11633 11634 11635 File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 11636 11637 11.6.2 References to storage 11638 ---------------------------- 11639 11640 `ARRAY_REF' 11641 These nodes represent array accesses. The first operand is the 11642 array; the second is the index. To calculate the address of the 11643 memory accessed, you must scale the index by the size of the type 11644 of the array elements. The type of these expressions must be the 11645 type of a component of the array. The third and fourth operands 11646 are used after gimplification to represent the lower bound and 11647 component size but should not be used directly; call 11648 `array_ref_low_bound' and `array_ref_element_size' instead. 11649 11650 `ARRAY_RANGE_REF' 11651 These nodes represent access to a range (or "slice") of an array. 11652 The operands are the same as that for `ARRAY_REF' and have the same 11653 meanings. The type of these expressions must be an array whose 11654 component type is the same as that of the first operand. The 11655 range of that array type determines the amount of data these 11656 expressions access. 11657 11658 `TARGET_MEM_REF' 11659 These nodes represent memory accesses whose address directly map to 11660 an addressing mode of the target architecture. The first argument 11661 is `TMR_SYMBOL' and must be a `VAR_DECL' of an object with a fixed 11662 address. The second argument is `TMR_BASE' and the third one is 11663 `TMR_INDEX'. The fourth argument is `TMR_STEP' and must be an 11664 `INTEGER_CST'. The fifth argument is `TMR_OFFSET' and must be an 11665 `INTEGER_CST'. Any of the arguments may be NULL if the 11666 appropriate component does not appear in the address. Address of 11667 the `TARGET_MEM_REF' is determined in the following way. 11668 11669 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 11670 11671 The sixth argument is the reference to the original memory access, 11672 which is preserved for the purposes of the RTL alias analysis. 11673 The seventh argument is a tag representing the results of tree 11674 level alias analysis. 11675 11676 `ADDR_EXPR' 11677 These nodes are used to represent the address of an object. (These 11678 expressions will always have pointer or reference type.) The 11679 operand may be another expression, or it may be a declaration. 11680 11681 As an extension, GCC allows users to take the address of a label. 11682 In this case, the operand of the `ADDR_EXPR' will be a 11683 `LABEL_DECL'. The type of such an expression is `void*'. 11684 11685 If the object addressed is not an lvalue, a temporary is created, 11686 and the address of the temporary is used. 11687 11688 `INDIRECT_REF' 11689 These nodes are used to represent the object pointed to by a 11690 pointer. The operand is the pointer being dereferenced; it will 11691 always have pointer or reference type. 11692 11693 `MEM_REF' 11694 These nodes are used to represent the object pointed to by a 11695 pointer offset by a constant. The first operand is the pointer 11696 being dereferenced; it will always have pointer or reference type. 11697 The second operand is a pointer constant. Its type is specifying 11698 the type to be used for type-based alias analysis. 11699 11700 `COMPONENT_REF' 11701 These nodes represent non-static data member accesses. The first 11702 operand is the object (rather than a pointer to it); the second 11703 operand is the `FIELD_DECL' for the data member. The third 11704 operand represents the byte offset of the field, but should not be 11705 used directly; call `component_ref_field_offset' instead. 11706 11707 11708 11709 File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 11710 11711 11.6.3 Unary and Binary Expressions 11712 ----------------------------------- 11713 11714 `NEGATE_EXPR' 11715 These nodes represent unary negation of the single operand, for 11716 both integer and floating-point types. The type of negation can be 11717 determined by looking at the type of the expression. 11718 11719 The behavior of this operation on signed arithmetic overflow is 11720 controlled by the `flag_wrapv' and `flag_trapv' variables. 11721 11722 `ABS_EXPR' 11723 These nodes represent the absolute value of the single operand, for 11724 both integer and floating-point types. This is typically used to 11725 implement the `abs', `labs' and `llabs' builtins for integer 11726 types, and the `fabs', `fabsf' and `fabsl' builtins for floating 11727 point types. The type of abs operation can be determined by 11728 looking at the type of the expression. 11729 11730 This node is not used for complex types. To represent the modulus 11731 or complex abs of a complex value, use the `BUILT_IN_CABS', 11732 `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to 11733 implement the C99 `cabs', `cabsf' and `cabsl' built-in functions. 11734 11735 `BIT_NOT_EXPR' 11736 These nodes represent bitwise complement, and will always have 11737 integral type. The only operand is the value to be complemented. 11738 11739 `TRUTH_NOT_EXPR' 11740 These nodes represent logical negation, and will always have 11741 integral (or boolean) type. The operand is the value being 11742 negated. The type of the operand and that of the result are 11743 always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 11744 11745 `PREDECREMENT_EXPR' 11746 `PREINCREMENT_EXPR' 11747 `POSTDECREMENT_EXPR' 11748 `POSTINCREMENT_EXPR' 11749 These nodes represent increment and decrement expressions. The 11750 value of the single operand is computed, and the operand 11751 incremented or decremented. In the case of `PREDECREMENT_EXPR' and 11752 `PREINCREMENT_EXPR', the value of the expression is the value 11753 resulting after the increment or decrement; in the case of 11754 `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before 11755 the increment or decrement occurs. The type of the operand, like 11756 that of the result, will be either integral, boolean, or 11757 floating-point. 11758 11759 `FIX_TRUNC_EXPR' 11760 These nodes represent conversion of a floating-point value to an 11761 integer. The single operand will have a floating-point type, while 11762 the complete expression will have an integral (or boolean) type. 11763 The operand is rounded towards zero. 11764 11765 `FLOAT_EXPR' 11766 These nodes represent conversion of an integral (or boolean) value 11767 to a floating-point value. The single operand will have integral 11768 type, while the complete expression will have a floating-point 11769 type. 11770 11771 FIXME: How is the operand supposed to be rounded? Is this 11772 dependent on `-mieee'? 11773 11774 `COMPLEX_EXPR' 11775 These nodes are used to represent complex numbers constructed from 11776 two expressions of the same (integer or real) type. The first 11777 operand is the real part and the second operand is the imaginary 11778 part. 11779 11780 `CONJ_EXPR' 11781 These nodes represent the conjugate of their operand. 11782 11783 `REALPART_EXPR' 11784 `IMAGPART_EXPR' 11785 These nodes represent respectively the real and the imaginary parts 11786 of complex numbers (their sole argument). 11787 11788 `NON_LVALUE_EXPR' 11789 These nodes indicate that their one and only operand is not an 11790 lvalue. A back end can treat these identically to the single 11791 operand. 11792 11793 `NOP_EXPR' 11794 These nodes are used to represent conversions that do not require 11795 any code-generation. For example, conversion of a `char*' to an 11796 `int*' does not require any code be generated; such a conversion is 11797 represented by a `NOP_EXPR'. The single operand is the expression 11798 to be converted. The conversion from a pointer to a reference is 11799 also represented with a `NOP_EXPR'. 11800 11801 `CONVERT_EXPR' 11802 These nodes are similar to `NOP_EXPR's, but are used in those 11803 situations where code may need to be generated. For example, if an 11804 `int*' is converted to an `int' code may need to be generated on 11805 some platforms. These nodes are never used for C++-specific 11806 conversions, like conversions between pointers to different 11807 classes in an inheritance hierarchy. Any adjustments that need to 11808 be made in such cases are always indicated explicitly. Similarly, 11809 a user-defined conversion is never represented by a 11810 `CONVERT_EXPR'; instead, the function calls are made explicit. 11811 11812 `FIXED_CONVERT_EXPR' 11813 These nodes are used to represent conversions that involve 11814 fixed-point values. For example, from a fixed-point value to 11815 another fixed-point value, from an integer to a fixed-point value, 11816 from a fixed-point value to an integer, from a floating-point 11817 value to a fixed-point value, or from a fixed-point value to a 11818 floating-point value. 11819 11820 `LSHIFT_EXPR' 11821 `RSHIFT_EXPR' 11822 These nodes represent left and right shifts, respectively. The 11823 first operand is the value to shift; it will always be of integral 11824 type. The second operand is an expression for the number of bits 11825 by which to shift. Right shift should be treated as arithmetic, 11826 i.e., the high-order bits should be zero-filled when the 11827 expression has unsigned type and filled with the sign bit when the 11828 expression has signed type. Note that the result is undefined if 11829 the second operand is larger than or equal to the first operand's 11830 type size. 11831 11832 `BIT_IOR_EXPR' 11833 `BIT_XOR_EXPR' 11834 `BIT_AND_EXPR' 11835 These nodes represent bitwise inclusive or, bitwise exclusive or, 11836 and bitwise and, respectively. Both operands will always have 11837 integral type. 11838 11839 `TRUTH_ANDIF_EXPR' 11840 `TRUTH_ORIF_EXPR' 11841 These nodes represent logical "and" and logical "or", respectively. 11842 These operators are not strict; i.e., the second operand is 11843 evaluated only if the value of the expression is not determined by 11844 evaluation of the first operand. The type of the operands and 11845 that of the result are always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 11846 11847 `TRUTH_AND_EXPR' 11848 `TRUTH_OR_EXPR' 11849 `TRUTH_XOR_EXPR' 11850 These nodes represent logical and, logical or, and logical 11851 exclusive or. They are strict; both arguments are always 11852 evaluated. There are no corresponding operators in C or C++, but 11853 the front end will sometimes generate these expressions anyhow, if 11854 it can tell that strictness does not matter. The type of the 11855 operands and that of the result are always of `BOOLEAN_TYPE' or 11856 `INTEGER_TYPE'. 11857 11858 `POINTER_PLUS_EXPR' 11859 This node represents pointer arithmetic. The first operand is 11860 always a pointer/reference type. The second operand is always an 11861 unsigned integer type compatible with sizetype. This is the only 11862 binary arithmetic operand that can operate on pointer types. 11863 11864 `PLUS_EXPR' 11865 `MINUS_EXPR' 11866 `MULT_EXPR' 11867 These nodes represent various binary arithmetic operations. 11868 Respectively, these operations are addition, subtraction (of the 11869 second operand from the first) and multiplication. Their operands 11870 may have either integral or floating type, but there will never be 11871 case in which one operand is of floating type and the other is of 11872 integral type. 11873 11874 The behavior of these operations on signed arithmetic overflow is 11875 controlled by the `flag_wrapv' and `flag_trapv' variables. 11876 11877 `RDIV_EXPR' 11878 This node represents a floating point division operation. 11879 11880 `TRUNC_DIV_EXPR' 11881 `FLOOR_DIV_EXPR' 11882 `CEIL_DIV_EXPR' 11883 `ROUND_DIV_EXPR' 11884 These nodes represent integer division operations that return an 11885 integer result. `TRUNC_DIV_EXPR' rounds towards zero, 11886 `FLOOR_DIV_EXPR' rounds towards negative infinity, `CEIL_DIV_EXPR' 11887 rounds towards positive infinity and `ROUND_DIV_EXPR' rounds to 11888 the closest integer. Integer division in C and C++ is truncating, 11889 i.e. `TRUNC_DIV_EXPR'. 11890 11891 The behavior of these operations on signed arithmetic overflow, 11892 when dividing the minimum signed integer by minus one, is 11893 controlled by the `flag_wrapv' and `flag_trapv' variables. 11894 11895 `TRUNC_MOD_EXPR' 11896 `FLOOR_MOD_EXPR' 11897 `CEIL_MOD_EXPR' 11898 `ROUND_MOD_EXPR' 11899 These nodes represent the integer remainder or modulus operation. 11900 The integer modulus of two operands `a' and `b' is defined as `a - 11901 (a/b)*b' where the division calculated using the corresponding 11902 division operator. Hence for `TRUNC_MOD_EXPR' this definition 11903 assumes division using truncation towards zero, i.e. 11904 `TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 11905 division, i.e. `TRUNC_MOD_EXPR'. 11906 11907 `EXACT_DIV_EXPR' 11908 The `EXACT_DIV_EXPR' code is used to represent integer divisions 11909 where the numerator is known to be an exact multiple of the 11910 denominator. This allows the backend to choose between the faster 11911 of `TRUNC_DIV_EXPR', `CEIL_DIV_EXPR' and `FLOOR_DIV_EXPR' for the 11912 current target. 11913 11914 `LT_EXPR' 11915 `LE_EXPR' 11916 `GT_EXPR' 11917 `GE_EXPR' 11918 `EQ_EXPR' 11919 `NE_EXPR' 11920 These nodes represent the less than, less than or equal to, greater 11921 than, greater than or equal to, equal, and not equal comparison 11922 operators. The first and second operand with either be both of 11923 integral type or both of floating type. The result type of these 11924 expressions will always be of integral or boolean type. These 11925 operations return the result type's zero value for false, and the 11926 result type's one value for true. 11927 11928 For floating point comparisons, if we honor IEEE NaNs and either 11929 operand is NaN, then `NE_EXPR' always returns true and the 11930 remaining operators always return false. On some targets, 11931 comparisons against an IEEE NaN, other than equality and 11932 inequality, may generate a floating point exception. 11933 11934 `ORDERED_EXPR' 11935 `UNORDERED_EXPR' 11936 These nodes represent non-trapping ordered and unordered comparison 11937 operators. These operations take two floating point operands and 11938 determine whether they are ordered or unordered relative to each 11939 other. If either operand is an IEEE NaN, their comparison is 11940 defined to be unordered, otherwise the comparison is defined to be 11941 ordered. The result type of these expressions will always be of 11942 integral or boolean type. These operations return the result 11943 type's zero value for false, and the result type's one value for 11944 true. 11945 11946 `UNLT_EXPR' 11947 `UNLE_EXPR' 11948 `UNGT_EXPR' 11949 `UNGE_EXPR' 11950 `UNEQ_EXPR' 11951 `LTGT_EXPR' 11952 These nodes represent the unordered comparison operators. These 11953 operations take two floating point operands and determine whether 11954 the operands are unordered or are less than, less than or equal to, 11955 greater than, greater than or equal to, or equal respectively. For 11956 example, `UNLT_EXPR' returns true if either operand is an IEEE NaN 11957 or the first operand is less than the second. With the possible 11958 exception of `LTGT_EXPR', all of these operations are guaranteed 11959 not to generate a floating point exception. The result type of 11960 these expressions will always be of integral or boolean type. 11961 These operations return the result type's zero value for false, 11962 and the result type's one value for true. 11963 11964 `MODIFY_EXPR' 11965 These nodes represent assignment. The left-hand side is the first 11966 operand; the right-hand side is the second operand. The left-hand 11967 side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or 11968 other lvalue. 11969 11970 These nodes are used to represent not only assignment with `=' but 11971 also compound assignments (like `+='), by reduction to `=' 11972 assignment. In other words, the representation for `i += 3' looks 11973 just like that for `i = i + 3'. 11974 11975 `INIT_EXPR' 11976 These nodes are just like `MODIFY_EXPR', but are used only when a 11977 variable is initialized, rather than assigned to subsequently. 11978 This means that we can assume that the target of the 11979 initialization is not used in computing its own value; any 11980 reference to the lhs in computing the rhs is undefined. 11981 11982 `COMPOUND_EXPR' 11983 These nodes represent comma-expressions. The first operand is an 11984 expression whose value is computed and thrown away prior to the 11985 evaluation of the second operand. The value of the entire 11986 expression is the value of the second operand. 11987 11988 `COND_EXPR' 11989 These nodes represent `?:' expressions. The first operand is of 11990 boolean or integral type. If it evaluates to a nonzero value, the 11991 second operand should be evaluated, and returned as the value of 11992 the expression. Otherwise, the third operand is evaluated, and 11993 returned as the value of the expression. 11994 11995 The second operand must have the same type as the entire 11996 expression, unless it unconditionally throws an exception or calls 11997 a noreturn function, in which case it should have void type. The 11998 same constraints apply to the third operand. This allows array 11999 bounds checks to be represented conveniently as `(i >= 0 && i < 12000 10) ? i : abort()'. 12001 12002 As a GNU extension, the C language front-ends allow the second 12003 operand of the `?:' operator may be omitted in the source. For 12004 example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x' 12005 is an expression without side-effects. In the tree 12006 representation, however, the second operand is always present, 12007 possibly protected by `SAVE_EXPR' if the first argument does cause 12008 side-effects. 12009 12010 `CALL_EXPR' 12011 These nodes are used to represent calls to functions, including 12012 non-static member functions. `CALL_EXPR's are implemented as 12013 expression nodes with a variable number of operands. Rather than 12014 using `TREE_OPERAND' to extract them, it is preferable to use the 12015 specialized accessor macros and functions that operate 12016 specifically on `CALL_EXPR' nodes. 12017 12018 `CALL_EXPR_FN' returns a pointer to the function to call; it is 12019 always an expression whose type is a `POINTER_TYPE'. 12020 12021 The number of arguments to the call is returned by 12022 `call_expr_nargs', while the arguments themselves can be accessed 12023 with the `CALL_EXPR_ARG' macro. The arguments are zero-indexed 12024 and numbered left-to-right. You can iterate over the arguments 12025 using `FOR_EACH_CALL_EXPR_ARG', as in: 12026 12027 tree call, arg; 12028 call_expr_arg_iterator iter; 12029 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 12030 /* arg is bound to successive arguments of call. */ 12031 ...; 12032 12033 For non-static member functions, there will be an operand 12034 corresponding to the `this' pointer. There will always be 12035 expressions corresponding to all of the arguments, even if the 12036 function is declared with default arguments and some arguments are 12037 not explicitly provided at the call sites. 12038 12039 `CALL_EXPR's also have a `CALL_EXPR_STATIC_CHAIN' operand that is 12040 used to implement nested functions. This operand is otherwise 12041 null. 12042 12043 `CLEANUP_POINT_EXPR' 12044 These nodes represent full-expressions. The single operand is an 12045 expression to evaluate. Any destructor calls engendered by the 12046 creation of temporaries during the evaluation of that expression 12047 should be performed immediately after the expression is evaluated. 12048 12049 `CONSTRUCTOR' 12050 These nodes represent the brace-enclosed initializers for a 12051 structure or array. The first operand is reserved for use by the 12052 back end. The second operand is a `TREE_LIST'. If the 12053 `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or 12054 `UNION_TYPE', then the `TREE_PURPOSE' of each node in the 12055 `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each 12056 node will be the expression used to initialize that field. 12057 12058 If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then 12059 the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an 12060 `INTEGER_CST' or a `RANGE_EXPR' of two `INTEGER_CST's. A single 12061 `INTEGER_CST' indicates which element of the array (indexed from 12062 zero) is being assigned to. A `RANGE_EXPR' indicates an inclusive 12063 range of elements to initialize. In both cases the `TREE_VALUE' 12064 is the corresponding initializer. It is re-evaluated for each 12065 element of a `RANGE_EXPR'. If the `TREE_PURPOSE' is `NULL_TREE', 12066 then the initializer is for the next available array element. 12067 12068 In the front end, you should not depend on the fields appearing in 12069 any particular order. However, in the middle end, fields must 12070 appear in declaration order. You should not assume that all 12071 fields will be represented. Unrepresented fields will be set to 12072 zero. 12073 12074 `COMPOUND_LITERAL_EXPR' 12075 These nodes represent ISO C99 compound literals. The 12076 `COMPOUND_LITERAL_EXPR_DECL_EXPR' is a `DECL_EXPR' containing an 12077 anonymous `VAR_DECL' for the unnamed object represented by the 12078 compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a 12079 `CONSTRUCTOR' representing the brace-enclosed list of initializers 12080 in the compound literal. That anonymous `VAR_DECL' can also be 12081 accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro. 12082 12083 `SAVE_EXPR' 12084 A `SAVE_EXPR' represents an expression (possibly involving 12085 side-effects) that is used more than once. The side-effects should 12086 occur only the first time the expression is evaluated. Subsequent 12087 uses should just reuse the computed value. The first operand to 12088 the `SAVE_EXPR' is the expression to evaluate. The side-effects 12089 should be executed where the `SAVE_EXPR' is first encountered in a 12090 depth-first preorder traversal of the expression tree. 12091 12092 `TARGET_EXPR' 12093 A `TARGET_EXPR' represents a temporary object. The first operand 12094 is a `VAR_DECL' for the temporary variable. The second operand is 12095 the initializer for the temporary. The initializer is evaluated 12096 and, if non-void, copied (bitwise) into the temporary. If the 12097 initializer is void, that means that it will perform the 12098 initialization itself. 12099 12100 Often, a `TARGET_EXPR' occurs on the right-hand side of an 12101 assignment, or as the second operand to a comma-expression which is 12102 itself the right-hand side of an assignment, etc. In this case, 12103 we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is 12104 "orphaned". For a normal `TARGET_EXPR' the temporary variable 12105 should be treated as an alias for the left-hand side of the 12106 assignment, rather than as a new temporary variable. 12107 12108 The third operand to the `TARGET_EXPR', if present, is a 12109 cleanup-expression (i.e., destructor call) for the temporary. If 12110 this expression is orphaned, then this expression must be executed 12111 when the statement containing this expression is complete. These 12112 cleanups must always be executed in the order opposite to that in 12113 which they were encountered. Note that if a temporary is created 12114 on one branch of a conditional operator (i.e., in the second or 12115 third operand to a `COND_EXPR'), the cleanup must be run only if 12116 that branch is actually executed. 12117 12118 `VA_ARG_EXPR' 12119 This node is used to implement support for the C/C++ variable 12120 argument-list mechanism. It represents expressions like `va_arg 12121 (ap, type)'. Its `TREE_TYPE' yields the tree representation for 12122 `type' and its sole argument yields the representation for `ap'. 12123 12124 12125 12126 File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 12127 12128 11.6.4 Vectors 12129 -------------- 12130 12131 `VEC_LSHIFT_EXPR' 12132 `VEC_RSHIFT_EXPR' 12133 These nodes represent whole vector left and right shifts, 12134 respectively. The first operand is the vector to shift; it will 12135 always be of vector type. The second operand is an expression for 12136 the number of bits by which to shift. Note that the result is 12137 undefined if the second operand is larger than or equal to the 12138 first operand's type size. 12139 12140 `VEC_WIDEN_MULT_HI_EXPR' 12141 `VEC_WIDEN_MULT_LO_EXPR' 12142 These nodes represent widening vector multiplication of the high 12143 and low parts of the two input vectors, respectively. Their 12144 operands are vectors that contain the same number of elements 12145 (`N') of the same integral type. The result is a vector that 12146 contains half as many elements, of an integral type whose size is 12147 twice as wide. In the case of `VEC_WIDEN_MULT_HI_EXPR' the high 12148 `N/2' elements of the two vector are multiplied to produce the 12149 vector of `N/2' products. In the case of `VEC_WIDEN_MULT_LO_EXPR' 12150 the low `N/2' elements of the two vector are multiplied to produce 12151 the vector of `N/2' products. 12152 12153 `VEC_UNPACK_HI_EXPR' 12154 `VEC_UNPACK_LO_EXPR' 12155 These nodes represent unpacking of the high and low parts of the 12156 input vector, respectively. The single operand is a vector that 12157 contains `N' elements of the same integral or floating point type. 12158 The result is a vector that contains half as many elements, of an 12159 integral or floating point type whose size is twice as wide. In 12160 the case of `VEC_UNPACK_HI_EXPR' the high `N/2' elements of the 12161 vector are extracted and widened (promoted). In the case of 12162 `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the vector are 12163 extracted and widened (promoted). 12164 12165 `VEC_UNPACK_FLOAT_HI_EXPR' 12166 `VEC_UNPACK_FLOAT_LO_EXPR' 12167 These nodes represent unpacking of the high and low parts of the 12168 input vector, where the values are converted from fixed point to 12169 floating point. The single operand is a vector that contains `N' 12170 elements of the same integral type. The result is a vector that 12171 contains half as many elements of a floating point type whose size 12172 is twice as wide. In the case of `VEC_UNPACK_HI_EXPR' the high 12173 `N/2' elements of the vector are extracted, converted and widened. 12174 In the case of `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the 12175 vector are extracted, converted and widened. 12176 12177 `VEC_PACK_TRUNC_EXPR' 12178 This node represents packing of truncated elements of the two 12179 input vectors into the output vector. Input operands are vectors 12180 that contain the same number of elements of the same integral or 12181 floating point type. The result is a vector that contains twice 12182 as many elements of an integral or floating point type whose size 12183 is half as wide. The elements of the two vectors are demoted and 12184 merged (concatenated) to form the output vector. 12185 12186 `VEC_PACK_SAT_EXPR' 12187 This node represents packing of elements of the two input vectors 12188 into the output vector using saturation. Input operands are 12189 vectors that contain the same number of elements of the same 12190 integral type. The result is a vector that contains twice as many 12191 elements of an integral type whose size is half as wide. The 12192 elements of the two vectors are demoted and merged (concatenated) 12193 to form the output vector. 12194 12195 `VEC_PACK_FIX_TRUNC_EXPR' 12196 This node represents packing of elements of the two input vectors 12197 into the output vector, where the values are converted from 12198 floating point to fixed point. Input operands are vectors that 12199 contain the same number of elements of a floating point type. The 12200 result is a vector that contains twice as many elements of an 12201 integral type whose size is half as wide. The elements of the two 12202 vectors are merged (concatenated) to form the output vector. 12203 12204 `VEC_EXTRACT_EVEN_EXPR' 12205 `VEC_EXTRACT_ODD_EXPR' 12206 These nodes represent extracting of the even/odd elements of the 12207 two input vectors, respectively. Their operands and result are 12208 vectors that contain the same number of elements of the same type. 12209 12210 `VEC_INTERLEAVE_HIGH_EXPR' 12211 `VEC_INTERLEAVE_LOW_EXPR' 12212 These nodes represent merging and interleaving of the high/low 12213 elements of the two input vectors, respectively. The operands and 12214 the result are vectors that contain the same number of elements 12215 (`N') of the same type. In the case of 12216 `VEC_INTERLEAVE_HIGH_EXPR', the high `N/2' elements of the first 12217 input vector are interleaved with the high `N/2' elements of the 12218 second input vector. In the case of `VEC_INTERLEAVE_LOW_EXPR', the 12219 low `N/2' elements of the first input vector are interleaved with 12220 the low `N/2' elements of the second input vector. 12221 12222 12223 12224 File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 12225 12226 11.7 Statements 12227 =============== 12228 12229 Most statements in GIMPLE are assignment statements, represented by 12230 `GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 12231 a reference to a volatile object is converted into a `GIMPLE_ASSIGN'. 12232 12233 There are also several varieties of complex statements. 12234 12235 * Menu: 12236 12237 * Basic Statements:: 12238 * Blocks:: 12239 * Statement Sequences:: 12240 * Empty Statements:: 12241 * Jumps:: 12242 * Cleanups:: 12243 * OpenMP:: 12244 12245 12246 File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 12247 12248 11.7.1 Basic Statements 12249 ----------------------- 12250 12251 `ASM_EXPR' 12252 Used to represent an inline assembly statement. For an inline 12253 assembly statement like: 12254 asm ("mov x, y"); 12255 The `ASM_STRING' macro will return a `STRING_CST' node for `"mov 12256 x, y"'. If the original statement made use of the 12257 extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and 12258 `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the 12259 statement, represented as `STRING_CST' nodes. The 12260 extended-assembly syntax looks like: 12261 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 12262 The first string is the `ASM_STRING', containing the instruction 12263 template. The next two strings are the output and inputs, 12264 respectively; this statement has no clobbers. As this example 12265 indicates, "plain" assembly statements are merely a special case 12266 of extended assembly statements; they have no cv-qualifiers, 12267 outputs, inputs, or clobbers. All of the strings will be 12268 `NUL'-terminated, and will contain no embedded `NUL'-characters. 12269 12270 If the assembly statement is declared `volatile', or if the 12271 statement was not an extended assembly statement, and is therefore 12272 implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold 12273 of the `ASM_EXPR'. 12274 12275 `DECL_EXPR' 12276 Used to represent a local declaration. The `DECL_EXPR_DECL' macro 12277 can be used to obtain the entity declared. This declaration may 12278 be a `LABEL_DECL', indicating that the label declared is a local 12279 label. (As an extension, GCC allows the declaration of labels 12280 with scope.) In C, this declaration may be a `FUNCTION_DECL', 12281 indicating the use of the GCC nested function extension. For more 12282 information, *note Functions::. 12283 12284 `LABEL_EXPR' 12285 Used to represent a label. The `LABEL_DECL' declared by this 12286 statement can be obtained with the `LABEL_EXPR_LABEL' macro. The 12287 `IDENTIFIER_NODE' giving the name of the label can be obtained from 12288 the `LABEL_DECL' with `DECL_NAME'. 12289 12290 `GOTO_EXPR' 12291 Used to represent a `goto' statement. The `GOTO_DESTINATION' will 12292 usually be a `LABEL_DECL'. However, if the "computed goto" 12293 extension has been used, the `GOTO_DESTINATION' will be an 12294 arbitrary expression indicating the destination. This expression 12295 will always have pointer type. 12296 12297 `RETURN_EXPR' 12298 Used to represent a `return' statement. Operand 0 represents the 12299 value to return. It should either be the `RESULT_DECL' for the 12300 containing function, or a `MODIFY_EXPR' or `INIT_EXPR' setting the 12301 function's `RESULT_DECL'. It will be `NULL_TREE' if the statement 12302 was just 12303 return; 12304 12305 `LOOP_EXPR' 12306 These nodes represent "infinite" loops. The `LOOP_EXPR_BODY' 12307 represents the body of the loop. It should be executed forever, 12308 unless an `EXIT_EXPR' is encountered. 12309 12310 `EXIT_EXPR' 12311 These nodes represent conditional exits from the nearest enclosing 12312 `LOOP_EXPR'. The single operand is the condition; if it is 12313 nonzero, then the loop should be exited. An `EXIT_EXPR' will only 12314 appear within a `LOOP_EXPR'. 12315 12316 `SWITCH_STMT' 12317 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is 12318 the expression on which the switch is occurring. See the 12319 documentation for an `IF_STMT' for more information on the 12320 representation used for the condition. The `SWITCH_STMT_BODY' is 12321 the body of the switch statement. The `SWITCH_STMT_TYPE' is the 12322 original type of switch expression as given in the source, before 12323 any compiler conversions. 12324 12325 `CASE_LABEL_EXPR' 12326 Use to represent a `case' label, range of `case' labels, or a 12327 `default' label. If `CASE_LOW' is `NULL_TREE', then this is a 12328 `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then 12329 this is an ordinary `case' label. In this case, `CASE_LOW' is an 12330 expression giving the value of the label. Both `CASE_LOW' and 12331 `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the 12332 same type as the condition expression in the switch statement. 12333 12334 Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the 12335 statement is a range of case labels. Such statements originate 12336 with the extension that allows users to write things of the form: 12337 case 2 ... 5: 12338 The first value will be `CASE_LOW', while the second will be 12339 `CASE_HIGH'. 12340 12341 12342 12343 File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 12344 12345 11.7.2 Blocks 12346 ------------- 12347 12348 Block scopes and the variables they declare in GENERIC are expressed 12349 using the `BIND_EXPR' code, which in previous versions of GCC was 12350 primarily used for the C statement-expression extension. 12351 12352 Variables in a block are collected into `BIND_EXPR_VARS' in 12353 declaration order through their `TREE_CHAIN' field. Any runtime 12354 initialization is moved out of `DECL_INITIAL' and into a statement in 12355 the controlled block. When gimplifying from C or C++, this 12356 initialization replaces the `DECL_STMT'. These variables will never 12357 require cleanups. The scope of these variables is just the body 12358 12359 Variable-length arrays (VLAs) complicate this process, as their size 12360 often refers to variables initialized earlier in the block. To handle 12361 this, we currently split the block at that point, and move the VLA into 12362 a new, inner `BIND_EXPR'. This strategy may change in the future. 12363 12364 A C++ program will usually contain more `BIND_EXPR's than there are 12365 syntactic blocks in the source code, since several C++ constructs have 12366 implicit scopes associated with them. On the other hand, although the 12367 C++ front end uses pseudo-scopes to handle cleanups for objects with 12368 destructors, these don't translate into the GIMPLE form; multiple 12369 declarations at the same level use the same `BIND_EXPR'. 12370 12371 12372 File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 12373 12374 11.7.3 Statement Sequences 12375 -------------------------- 12376 12377 Multiple statements at the same nesting level are collected into a 12378 `STATEMENT_LIST'. Statement lists are modified and traversed using the 12379 interface in `tree-iterator.h'. 12380 12381 12382 File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 12383 12384 11.7.4 Empty Statements 12385 ----------------------- 12386 12387 Whenever possible, statements with no effect are discarded. But if 12388 they are nested within another construct which cannot be discarded for 12389 some reason, they are instead replaced with an empty statement, 12390 generated by `build_empty_stmt'. Initially, all empty statements were 12391 shared, after the pattern of the Java front end, but this caused a lot 12392 of trouble in practice. 12393 12394 An empty statement is represented as `(void)0'. 12395 12396 12397 File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 12398 12399 11.7.5 Jumps 12400 ------------ 12401 12402 Other jumps are expressed by either `GOTO_EXPR' or `RETURN_EXPR'. 12403 12404 The operand of a `GOTO_EXPR' must be either a label or a variable 12405 containing the address to jump to. 12406 12407 The operand of a `RETURN_EXPR' is either `NULL_TREE', `RESULT_DECL', 12408 or a `MODIFY_EXPR' which sets the return value. It would be nice to 12409 move the `MODIFY_EXPR' into a separate statement, but the special 12410 return semantics in `expand_return' make that difficult. It may still 12411 happen in the future, perhaps by moving most of that logic into 12412 `expand_assignment'. 12413 12414 12415 File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 12416 12417 11.7.6 Cleanups 12418 --------------- 12419 12420 Destructors for local C++ objects and similar dynamic cleanups are 12421 represented in GIMPLE by a `TRY_FINALLY_EXPR'. `TRY_FINALLY_EXPR' has 12422 two operands, both of which are a sequence of statements to execute. 12423 The first sequence is executed. When it completes the second sequence 12424 is executed. 12425 12426 The first sequence may complete in the following ways: 12427 12428 1. Execute the last statement in the sequence and fall off the end. 12429 12430 2. Execute a goto statement (`GOTO_EXPR') to an ordinary label 12431 outside the sequence. 12432 12433 3. Execute a return statement (`RETURN_EXPR'). 12434 12435 4. Throw an exception. This is currently not explicitly represented 12436 in GIMPLE. 12437 12438 12439 The second sequence is not executed if the first sequence completes by 12440 calling `setjmp' or `exit' or any other function that does not return. 12441 The second sequence is also not executed if the first sequence 12442 completes via a non-local goto or a computed goto (in general the 12443 compiler does not know whether such a goto statement exits the first 12444 sequence or not, so we assume that it doesn't). 12445 12446 After the second sequence is executed, if it completes normally by 12447 falling off the end, execution continues wherever the first sequence 12448 would have continued, by falling off the end, or doing a goto, etc. 12449 12450 `TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 12451 to appear on every edge out of the controlled block; this reduces the 12452 freedom to move code across these edges. Therefore, the EH lowering 12453 pass which runs before most of the optimization passes eliminates these 12454 expressions by explicitly adding the cleanup to each edge. Rethrowing 12455 the exception is represented using `RESX_EXPR'. 12456 12457 12458 File: gccint.info, Node: OpenMP, Prev: Cleanups, Up: Statements 12459 12460 11.7.7 OpenMP 12461 ------------- 12462 12463 All the statements starting with `OMP_' represent directives and 12464 clauses used by the OpenMP API `http://www.openmp.org/'. 12465 12466 `OMP_PARALLEL' 12467 Represents `#pragma omp parallel [clause1 ... clauseN]'. It has 12468 four operands: 12469 12470 Operand `OMP_PARALLEL_BODY' is valid while in GENERIC and High 12471 GIMPLE forms. It contains the body of code to be executed by all 12472 the threads. During GIMPLE lowering, this operand becomes `NULL' 12473 and the body is emitted linearly after `OMP_PARALLEL'. 12474 12475 Operand `OMP_PARALLEL_CLAUSES' is the list of clauses associated 12476 with the directive. 12477 12478 Operand `OMP_PARALLEL_FN' is created by `pass_lower_omp', it 12479 contains the `FUNCTION_DECL' for the function that will contain 12480 the body of the parallel region. 12481 12482 Operand `OMP_PARALLEL_DATA_ARG' is also created by 12483 `pass_lower_omp'. If there are shared variables to be communicated 12484 to the children threads, this operand will contain the `VAR_DECL' 12485 that contains all the shared values and variables. 12486 12487 `OMP_FOR' 12488 Represents `#pragma omp for [clause1 ... clauseN]'. It has 5 12489 operands: 12490 12491 Operand `OMP_FOR_BODY' contains the loop body. 12492 12493 Operand `OMP_FOR_CLAUSES' is the list of clauses associated with 12494 the directive. 12495 12496 Operand `OMP_FOR_INIT' is the loop initialization code of the form 12497 `VAR = N1'. 12498 12499 Operand `OMP_FOR_COND' is the loop conditional expression of the 12500 form `VAR {<,>,<=,>=} N2'. 12501 12502 Operand `OMP_FOR_INCR' is the loop index increment of the form 12503 `VAR {+=,-=} INCR'. 12504 12505 Operand `OMP_FOR_PRE_BODY' contains side-effect code from operands 12506 `OMP_FOR_INIT', `OMP_FOR_COND' and `OMP_FOR_INC'. These 12507 side-effects are part of the `OMP_FOR' block but must be evaluated 12508 before the start of loop body. 12509 12510 The loop index variable `VAR' must be a signed integer variable, 12511 which is implicitly private to each thread. Bounds `N1' and `N2' 12512 and the increment expression `INCR' are required to be loop 12513 invariant integer expressions that are evaluated without any 12514 synchronization. The evaluation order, frequency of evaluation and 12515 side-effects are unspecified by the standard. 12516 12517 `OMP_SECTIONS' 12518 Represents `#pragma omp sections [clause1 ... clauseN]'. 12519 12520 Operand `OMP_SECTIONS_BODY' contains the sections body, which in 12521 turn contains a set of `OMP_SECTION' nodes for each of the 12522 concurrent sections delimited by `#pragma omp section'. 12523 12524 Operand `OMP_SECTIONS_CLAUSES' is the list of clauses associated 12525 with the directive. 12526 12527 `OMP_SECTION' 12528 Section delimiter for `OMP_SECTIONS'. 12529 12530 `OMP_SINGLE' 12531 Represents `#pragma omp single'. 12532 12533 Operand `OMP_SINGLE_BODY' contains the body of code to be executed 12534 by a single thread. 12535 12536 Operand `OMP_SINGLE_CLAUSES' is the list of clauses associated 12537 with the directive. 12538 12539 `OMP_MASTER' 12540 Represents `#pragma omp master'. 12541 12542 Operand `OMP_MASTER_BODY' contains the body of code to be executed 12543 by the master thread. 12544 12545 `OMP_ORDERED' 12546 Represents `#pragma omp ordered'. 12547 12548 Operand `OMP_ORDERED_BODY' contains the body of code to be 12549 executed in the sequential order dictated by the loop index 12550 variable. 12551 12552 `OMP_CRITICAL' 12553 Represents `#pragma omp critical [name]'. 12554 12555 Operand `OMP_CRITICAL_BODY' is the critical section. 12556 12557 Operand `OMP_CRITICAL_NAME' is an optional identifier to label the 12558 critical section. 12559 12560 `OMP_RETURN' 12561 This does not represent any OpenMP directive, it is an artificial 12562 marker to indicate the end of the body of an OpenMP. It is used by 12563 the flow graph (`tree-cfg.c') and OpenMP region building code 12564 (`omp-low.c'). 12565 12566 `OMP_CONTINUE' 12567 Similarly, this instruction does not represent an OpenMP 12568 directive, it is used by `OMP_FOR' and `OMP_SECTIONS' to mark the 12569 place where the code needs to loop to the next iteration (in the 12570 case of `OMP_FOR') or the next section (in the case of 12571 `OMP_SECTIONS'). 12572 12573 In some cases, `OMP_CONTINUE' is placed right before `OMP_RETURN'. 12574 But if there are cleanups that need to occur right after the 12575 looping body, it will be emitted between `OMP_CONTINUE' and 12576 `OMP_RETURN'. 12577 12578 `OMP_ATOMIC' 12579 Represents `#pragma omp atomic'. 12580 12581 Operand 0 is the address at which the atomic operation is to be 12582 performed. 12583 12584 Operand 1 is the expression to evaluate. The gimplifier tries 12585 three alternative code generation strategies. Whenever possible, 12586 an atomic update built-in is used. If that fails, a 12587 compare-and-swap loop is attempted. If that also fails, a regular 12588 critical section around the expression is used. 12589 12590 `OMP_CLAUSE' 12591 Represents clauses associated with one of the `OMP_' directives. 12592 Clauses are represented by separate sub-codes defined in `tree.h'. 12593 Clauses codes can be one of: `OMP_CLAUSE_PRIVATE', 12594 `OMP_CLAUSE_SHARED', `OMP_CLAUSE_FIRSTPRIVATE', 12595 `OMP_CLAUSE_LASTPRIVATE', `OMP_CLAUSE_COPYIN', 12596 `OMP_CLAUSE_COPYPRIVATE', `OMP_CLAUSE_IF', 12597 `OMP_CLAUSE_NUM_THREADS', `OMP_CLAUSE_SCHEDULE', 12598 `OMP_CLAUSE_NOWAIT', `OMP_CLAUSE_ORDERED', `OMP_CLAUSE_DEFAULT', 12599 and `OMP_CLAUSE_REDUCTION'. Each code represents the 12600 corresponding OpenMP clause. 12601 12602 Clauses associated with the same directive are chained together 12603 via `OMP_CLAUSE_CHAIN'. Those clauses that accept a list of 12604 variables are restricted to exactly one, accessed with 12605 `OMP_CLAUSE_VAR'. Therefore, multiple variables under the same 12606 clause `C' need to be represented as multiple `C' clauses chained 12607 together. This facilitates adding new clauses during compilation. 12608 12609 12610 12611 File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 12612 12613 11.8 Functions 12614 ============== 12615 12616 A function is represented by a `FUNCTION_DECL' node. It stores the 12617 basic pieces of the function such as body, parameters, and return type 12618 as well as information on the surrounding context, visibility, and 12619 linkage. 12620 12621 * Menu: 12622 12623 * Function Basics:: Function names, body, and parameters. 12624 * Function Properties:: Context, linkage, etc. 12625 12626 12627 File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 12628 12629 11.8.1 Function Basics 12630 ---------------------- 12631 12632 A function has four core parts: the name, the parameters, the result, 12633 and the body. The following macros and functions access these parts of 12634 a `FUNCTION_DECL' as well as other basic features: 12635 `DECL_NAME' 12636 This macro returns the unqualified name of the function, as an 12637 `IDENTIFIER_NODE'. For an instantiation of a function template, 12638 the `DECL_NAME' is the unqualified name of the template, not 12639 something like `f<int>'. The value of `DECL_NAME' is undefined 12640 when used on a constructor, destructor, overloaded operator, or 12641 type-conversion operator, or any function that is implicitly 12642 generated by the compiler. See below for macros that can be used 12643 to distinguish these cases. 12644 12645 `DECL_ASSEMBLER_NAME' 12646 This macro returns the mangled name of the function, also an 12647 `IDENTIFIER_NODE'. This name does not contain leading underscores 12648 on systems that prefix all identifiers with underscores. The 12649 mangled name is computed in the same way on all platforms; if 12650 special processing is required to deal with the object file format 12651 used on a particular platform, it is the responsibility of the 12652 back end to perform those modifications. (Of course, the back end 12653 should not modify `DECL_ASSEMBLER_NAME' itself.) 12654 12655 Using `DECL_ASSEMBLER_NAME' will cause additional memory to be 12656 allocated (for the mangled name of the entity) so it should be used 12657 only when emitting assembly code. It should not be used within the 12658 optimizers to determine whether or not two declarations are the 12659 same, even though some of the existing optimizers do use it in 12660 that way. These uses will be removed over time. 12661 12662 `DECL_ARGUMENTS' 12663 This macro returns the `PARM_DECL' for the first argument to the 12664 function. Subsequent `PARM_DECL' nodes can be obtained by 12665 following the `TREE_CHAIN' links. 12666 12667 `DECL_RESULT' 12668 This macro returns the `RESULT_DECL' for the function. 12669 12670 `DECL_SAVED_TREE' 12671 This macro returns the complete body of the function. 12672 12673 `TREE_TYPE' 12674 This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the 12675 function. 12676 12677 `DECL_INITIAL' 12678 A function that has a definition in the current translation unit 12679 will have a non-`NULL' `DECL_INITIAL'. However, back ends should 12680 not make use of the particular value given by `DECL_INITIAL'. 12681 12682 It should contain a tree of `BLOCK' nodes that mirrors the scopes 12683 that variables are bound in the function. Each block contains a 12684 list of decls declared in a basic block, a pointer to a chain of 12685 blocks at the next lower scope level, then a pointer to the next 12686 block at the same level and a backpointer to the parent `BLOCK' or 12687 `FUNCTION_DECL'. So given a function as follows: 12688 12689 void foo() 12690 { 12691 int a; 12692 { 12693 int b; 12694 } 12695 int c; 12696 } 12697 12698 you would get the following: 12699 12700 tree foo = FUNCTION_DECL; 12701 tree decl_a = VAR_DECL; 12702 tree decl_b = VAR_DECL; 12703 tree decl_c = VAR_DECL; 12704 tree block_a = BLOCK; 12705 tree block_b = BLOCK; 12706 tree block_c = BLOCK; 12707 BLOCK_VARS(block_a) = decl_a; 12708 BLOCK_SUBBLOCKS(block_a) = block_b; 12709 BLOCK_CHAIN(block_a) = block_c; 12710 BLOCK_SUPERCONTEXT(block_a) = foo; 12711 BLOCK_VARS(block_b) = decl_b; 12712 BLOCK_SUPERCONTEXT(block_b) = block_a; 12713 BLOCK_VARS(block_c) = decl_c; 12714 BLOCK_SUPERCONTEXT(block_c) = foo; 12715 DECL_INITIAL(foo) = block_a; 12716 12717 12718 12719 File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 12720 12721 11.8.2 Function Properties 12722 -------------------------- 12723 12724 To determine the scope of a function, you can use the `DECL_CONTEXT' 12725 macro. This macro will return the class (either a `RECORD_TYPE' or a 12726 `UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 12727 is a member. For a virtual function, this macro returns the class in 12728 which the function was actually defined, not the base class in which 12729 the virtual declaration occurred. 12730 12731 In C, the `DECL_CONTEXT' for a function maybe another function. This 12732 representation indicates that the GNU nested function extension is in 12733 use. For details on the semantics of nested functions, see the GCC 12734 Manual. The nested function can refer to local variables in its 12735 containing function. Such references are not explicitly marked in the 12736 tree structure; back ends must look at the `DECL_CONTEXT' for the 12737 referenced `VAR_DECL'. If the `DECL_CONTEXT' for the referenced 12738 `VAR_DECL' is not the same as the function currently being processed, 12739 and neither `DECL_EXTERNAL' nor `TREE_STATIC' hold, then the reference 12740 is to a local variable in a containing function, and the back end must 12741 take appropriate action. 12742 12743 `DECL_EXTERNAL' 12744 This predicate holds if the function is undefined. 12745 12746 `TREE_PUBLIC' 12747 This predicate holds if the function has external linkage. 12748 12749 `TREE_STATIC' 12750 This predicate holds if the function has been defined. 12751 12752 `TREE_THIS_VOLATILE' 12753 This predicate holds if the function does not return normally. 12754 12755 `TREE_READONLY' 12756 This predicate holds if the function can only read its arguments. 12757 12758 `DECL_PURE_P' 12759 This predicate holds if the function can only read its arguments, 12760 but may also read global memory. 12761 12762 `DECL_VIRTUAL_P' 12763 This predicate holds if the function is virtual. 12764 12765 `DECL_ARTIFICIAL' 12766 This macro holds if the function was implicitly generated by the 12767 compiler, rather than explicitly declared. In addition to 12768 implicitly generated class member functions, this macro holds for 12769 the special functions created to implement static initialization 12770 and destruction, to compute run-time type information, and so 12771 forth. 12772 12773 `DECL_FUNCTION_SPECIFIC_TARGET' 12774 This macro returns a tree node that holds the target options that 12775 are to be used to compile this particular function or `NULL_TREE' 12776 if the function is to be compiled with the target options 12777 specified on the command line. 12778 12779 `DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 12780 This macro returns a tree node that holds the optimization options 12781 that are to be used to compile this particular function or 12782 `NULL_TREE' if the function is to be compiled with the 12783 optimization options specified on the command line. 12784 12785 12786 12787 File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 12788 12789 11.9 Language-dependent trees 12790 ============================= 12791 12792 Front ends may wish to keep some state associated with various GENERIC 12793 trees while parsing. To support this, trees provide a set of flags 12794 that may be used by the front end. They are accessed using 12795 `TREE_LANG_FLAG_n' where `n' is currently 0 through 6. 12796 12797 If necessary, a front end can use some language-dependent tree codes 12798 in its GENERIC representation, so long as it provides a hook for 12799 converting them to GIMPLE and doesn't expect them to work with any 12800 (hypothetical) optimizers that run before the conversion to GIMPLE. The 12801 intermediate representation used while parsing C and C++ looks very 12802 little like GENERIC, but the C and C++ gimplifier hooks are perfectly 12803 happy to take it as input and spit out GIMPLE. 12804 12805 12806 File: gccint.info, Node: C and C++ Trees, Next: Java Trees, Prev: Language-dependent trees, Up: GENERIC 12807 12808 11.10 C and C++ Trees 12809 ===================== 12810 12811 This section documents the internal representation used by GCC to 12812 represent C and C++ source programs. When presented with a C or C++ 12813 source program, GCC parses the program, performs semantic analysis 12814 (including the generation of error messages), and then produces the 12815 internal representation described here. This representation contains a 12816 complete representation for the entire translation unit provided as 12817 input to the front end. This representation is then typically processed 12818 by a code-generator in order to produce machine code, but could also be 12819 used in the creation of source browsers, intelligent editors, automatic 12820 documentation generators, interpreters, and any other programs needing 12821 the ability to process C or C++ code. 12822 12823 This section explains the internal representation. In particular, it 12824 documents the internal representation for C and C++ source constructs, 12825 and the macros, functions, and variables that can be used to access 12826 these constructs. The C++ representation is largely a superset of the 12827 representation used in the C front end. There is only one construct 12828 used in C that does not appear in the C++ front end and that is the GNU 12829 "nested function" extension. Many of the macros documented here do not 12830 apply in C because the corresponding language constructs do not appear 12831 in C. 12832 12833 The C and C++ front ends generate a mix of GENERIC trees and ones 12834 specific to C and C++. These language-specific trees are higher-level 12835 constructs than the ones in GENERIC to make the parser's job easier. 12836 This section describes those trees that aren't part of GENERIC as well 12837 as aspects of GENERIC trees that are treated in a language-specific 12838 manner. 12839 12840 If you are developing a "back end", be it is a code-generator or some 12841 other tool, that uses this representation, you may occasionally find 12842 that you need to ask questions not easily answered by the functions and 12843 macros available here. If that situation occurs, it is quite likely 12844 that GCC already supports the functionality you desire, but that the 12845 interface is simply not documented here. In that case, you should ask 12846 the GCC maintainers (via mail to <gcc (a] gcc.gnu.org>) about documenting 12847 the functionality you require. Similarly, if you find yourself writing 12848 functions that do not deal directly with your back end, but instead 12849 might be useful to other people using the GCC front end, you should 12850 submit your patches for inclusion in GCC. 12851 12852 * Menu: 12853 12854 * Types for C++:: Fundamental and aggregate types. 12855 * Namespaces:: Namespaces. 12856 * Classes:: Classes. 12857 * Functions for C++:: Overloading and accessors for C++. 12858 * Statements for C++:: Statements specific to C and C++. 12859 * C++ Expressions:: From `typeid' to `throw'. 12860 12861 12862 File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 12863 12864 11.10.1 Types for C++ 12865 --------------------- 12866 12867 In C++, an array type is not qualified; rather the type of the array 12868 elements is qualified. This situation is reflected in the intermediate 12869 representation. The macros described here will always examine the 12870 qualification of the underlying element type when applied to an array 12871 type. (If the element type is itself an array, then the recursion 12872 continues until a non-array type is found, and the qualification of this 12873 type is examined.) So, for example, `CP_TYPE_CONST_P' will hold of the 12874 type `const int ()[7]', denoting an array of seven `int's. 12875 12876 The following functions and macros deal with cv-qualification of types: 12877 `CP_TYPE_QUALS' 12878 This macro returns the set of type qualifiers applied to this type. 12879 This value is `TYPE_UNQUALIFIED' if no qualifiers have been 12880 applied. The `TYPE_QUAL_CONST' bit is set if the type is 12881 `const'-qualified. The `TYPE_QUAL_VOLATILE' bit is set if the 12882 type is `volatile'-qualified. The `TYPE_QUAL_RESTRICT' bit is set 12883 if the type is `restrict'-qualified. 12884 12885 `CP_TYPE_CONST_P' 12886 This macro holds if the type is `const'-qualified. 12887 12888 `CP_TYPE_VOLATILE_P' 12889 This macro holds if the type is `volatile'-qualified. 12890 12891 `CP_TYPE_RESTRICT_P' 12892 This macro holds if the type is `restrict'-qualified. 12893 12894 `CP_TYPE_CONST_NON_VOLATILE_P' 12895 This predicate holds for a type that is `const'-qualified, but 12896 _not_ `volatile'-qualified; other cv-qualifiers are ignored as 12897 well: only the `const'-ness is tested. 12898 12899 12900 A few other macros and functions are usable with all types: 12901 `TYPE_SIZE' 12902 The number of bits required to represent the type, represented as 12903 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 12904 `NULL_TREE'. 12905 12906 `TYPE_ALIGN' 12907 The alignment of the type, in bits, represented as an `int'. 12908 12909 `TYPE_NAME' 12910 This macro returns a declaration (in the form of a `TYPE_DECL') for 12911 the type. (Note this macro does _not_ return an 12912 `IDENTIFIER_NODE', as you might expect, given its name!) You can 12913 look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual 12914 name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type 12915 that is not a built-in type, the result of a typedef, or a named 12916 class type. 12917 12918 `CP_INTEGRAL_TYPE' 12919 This predicate holds if the type is an integral type. Notice that 12920 in C++, enumerations are _not_ integral types. 12921 12922 `ARITHMETIC_TYPE_P' 12923 This predicate holds if the type is an integral type (in the C++ 12924 sense) or a floating point type. 12925 12926 `CLASS_TYPE_P' 12927 This predicate holds for a class-type. 12928 12929 `TYPE_BUILT_IN' 12930 This predicate holds for a built-in type. 12931 12932 `TYPE_PTRMEM_P' 12933 This predicate holds if the type is a pointer to data member. 12934 12935 `TYPE_PTR_P' 12936 This predicate holds if the type is a pointer type, and the 12937 pointee is not a data member. 12938 12939 `TYPE_PTRFN_P' 12940 This predicate holds for a pointer to function type. 12941 12942 `TYPE_PTROB_P' 12943 This predicate holds for a pointer to object type. Note however 12944 that it does not hold for the generic pointer to object type `void 12945 *'. You may use `TYPE_PTROBV_P' to test for a pointer to object 12946 type as well as `void *'. 12947 12948 12949 The table below describes types specific to C and C++ as well as 12950 language-dependent info about GENERIC types. 12951 12952 `POINTER_TYPE' 12953 Used to represent pointer types, and pointer to data member types. 12954 If `TREE_TYPE' is a pointer to data member type, then 12955 `TYPE_PTRMEM_P' will hold. For a pointer to data member type of 12956 the form `T X::*', `TYPE_PTRMEM_CLASS_TYPE' will be the type `X', 12957 while `TYPE_PTRMEM_POINTED_TO_TYPE' will be the type `T'. 12958 12959 `RECORD_TYPE' 12960 Used to represent `struct' and `class' types in C and C++. If 12961 `TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 12962 type. In that case, the `TYPE_PTRMEMFUNC_FN_TYPE' is a 12963 `POINTER_TYPE' pointing to a `METHOD_TYPE'. The `METHOD_TYPE' is 12964 the type of a function pointed to by the pointer-to-member 12965 function. If `TYPE_PTRMEMFUNC_P' does not hold, this type is a 12966 class type. For more information, *note Classes::. 12967 12968 `UNKNOWN_TYPE' 12969 This node is used to represent a type the knowledge of which is 12970 insufficient for a sound processing. 12971 12972 `TYPENAME_TYPE' 12973 Used to represent a construct of the form `typename T::A'. The 12974 `TYPE_CONTEXT' is `T'; the `TYPE_NAME' is an `IDENTIFIER_NODE' for 12975 `A'. If the type is specified via a template-id, then 12976 `TYPENAME_TYPE_FULLNAME' yields a `TEMPLATE_ID_EXPR'. The 12977 `TREE_TYPE' is non-`NULL' if the node is implicitly generated in 12978 support for the implicit typename extension; in which case the 12979 `TREE_TYPE' is a type node for the base-class. 12980 12981 `TYPEOF_TYPE' 12982 Used to represent the `__typeof__' extension. The `TYPE_FIELDS' 12983 is the expression the type of which is being represented. 12984 12985 12986 12987 File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 12988 12989 11.10.2 Namespaces 12990 ------------------ 12991 12992 The root of the entire intermediate representation is the variable 12993 `global_namespace'. This is the namespace specified with `::' in C++ 12994 source code. All other namespaces, types, variables, functions, and so 12995 forth can be found starting with this namespace. 12996 12997 However, except for the fact that it is distinguished as the root of 12998 the representation, the global namespace is no different from any other 12999 namespace. Thus, in what follows, we describe namespaces generally, 13000 rather than the global namespace in particular. 13001 13002 A namespace is represented by a `NAMESPACE_DECL' node. 13003 13004 The following macros and functions can be used on a `NAMESPACE_DECL': 13005 13006 `DECL_NAME' 13007 This macro is used to obtain the `IDENTIFIER_NODE' corresponding to 13008 the unqualified name of the name of the namespace (*note 13009 Identifiers::). The name of the global namespace is `::', even 13010 though in C++ the global namespace is unnamed. However, you 13011 should use comparison with `global_namespace', rather than 13012 `DECL_NAME' to determine whether or not a namespace is the global 13013 one. An unnamed namespace will have a `DECL_NAME' equal to 13014 `anonymous_namespace_name'. Within a single translation unit, all 13015 unnamed namespaces will have the same name. 13016 13017 `DECL_CONTEXT' 13018 This macro returns the enclosing namespace. The `DECL_CONTEXT' for 13019 the `global_namespace' is `NULL_TREE'. 13020 13021 `DECL_NAMESPACE_ALIAS' 13022 If this declaration is for a namespace alias, then 13023 `DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 13024 alias. 13025 13026 Do not attempt to use `cp_namespace_decls' for a namespace which is 13027 an alias. Instead, follow `DECL_NAMESPACE_ALIAS' links until you 13028 reach an ordinary, non-alias, namespace, and call 13029 `cp_namespace_decls' there. 13030 13031 `DECL_NAMESPACE_STD_P' 13032 This predicate holds if the namespace is the special `::std' 13033 namespace. 13034 13035 `cp_namespace_decls' 13036 This function will return the declarations contained in the 13037 namespace, including types, overloaded functions, other 13038 namespaces, and so forth. If there are no declarations, this 13039 function will return `NULL_TREE'. The declarations are connected 13040 through their `TREE_CHAIN' fields. 13041 13042 Although most entries on this list will be declarations, 13043 `TREE_LIST' nodes may also appear. In this case, the `TREE_VALUE' 13044 will be an `OVERLOAD'. The value of the `TREE_PURPOSE' is 13045 unspecified; back ends should ignore this value. As with the 13046 other kinds of declarations returned by `cp_namespace_decls', the 13047 `TREE_CHAIN' will point to the next declaration in this list. 13048 13049 For more information on the kinds of declarations that can occur 13050 on this list, *Note Declarations::. Some declarations will not 13051 appear on this list. In particular, no `FIELD_DECL', 13052 `LABEL_DECL', or `PARM_DECL' nodes will appear here. 13053 13054 This function cannot be used with namespaces that have 13055 `DECL_NAMESPACE_ALIAS' set. 13056 13057 13058 13059 File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 13060 13061 11.10.3 Classes 13062 --------------- 13063 13064 Besides namespaces, the other high-level scoping construct in C++ is the 13065 class. (Throughout this manual the term "class" is used to mean the 13066 types referred to in the ANSI/ISO C++ Standard as classes; these include 13067 types defined with the `class', `struct', and `union' keywords.) 13068 13069 A class type is represented by either a `RECORD_TYPE' or a 13070 `UNION_TYPE'. A class declared with the `union' tag is represented by 13071 a `UNION_TYPE', while classes declared with either the `struct' or the 13072 `class' tag are represented by `RECORD_TYPE's. You can use the 13073 `CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 13074 type is a `class' as opposed to a `struct'. This macro will be true 13075 only for classes declared with the `class' tag. 13076 13077 Almost all non-function members are available on the `TYPE_FIELDS' 13078 list. Given one member, the next can be found by following the 13079 `TREE_CHAIN'. You should not depend in any way on the order in which 13080 fields appear on this list. All nodes on this list will be `DECL' 13081 nodes. A `FIELD_DECL' is used to represent a non-static data member, a 13082 `VAR_DECL' is used to represent a static data member, and a `TYPE_DECL' 13083 is used to represent a type. Note that the `CONST_DECL' for an 13084 enumeration constant will appear on this list, if the enumeration type 13085 was declared in the class. (Of course, the `TYPE_DECL' for the 13086 enumeration type will appear here as well.) There are no entries for 13087 base classes on this list. In particular, there is no `FIELD_DECL' for 13088 the "base-class portion" of an object. 13089 13090 The `TYPE_VFIELD' is a compiler-generated field used to point to 13091 virtual function tables. It may or may not appear on the `TYPE_FIELDS' 13092 list. However, back ends should handle the `TYPE_VFIELD' just like all 13093 the entries on the `TYPE_FIELDS' list. 13094 13095 The function members are available on the `TYPE_METHODS' list. Again, 13096 subsequent members are found by following the `TREE_CHAIN' field. If a 13097 function is overloaded, each of the overloaded functions appears; no 13098 `OVERLOAD' nodes appear on the `TYPE_METHODS' list. Implicitly 13099 declared functions (including default constructors, copy constructors, 13100 assignment operators, and destructors) will appear on this list as well. 13101 13102 Every class has an associated "binfo", which can be obtained with 13103 `TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 13104 given by `TYPE_BINFO' is the degenerate case, whereby every class is 13105 considered to be its own base-class. The base binfos for a particular 13106 binfo are held in a vector, whose length is obtained with 13107 `BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 13108 `BINFO_BASE_BINFO' and `BINFO_BASE_ITERATE'. To add a new binfo, use 13109 `BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 13110 `BINFO_BASE_BINFOS', but normally you do not need to use that. The 13111 class type associated with a binfo is given by `BINFO_TYPE'. It is not 13112 always the case that `BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 13113 and qualified types. Neither is it the case that `TYPE_BINFO 13114 (BINFO_TYPE (y))' is the same binfo as `y'. The reason is that if `y' 13115 is a binfo representing a base-class `B' of a derived class `D', then 13116 `BINFO_TYPE (y)' will be `B', and `TYPE_BINFO (BINFO_TYPE (y))' will be 13117 `B' as its own base-class, rather than as a base-class of `D'. 13118 13119 The access to a base type can be found with `BINFO_BASE_ACCESS'. This 13120 will produce `access_public_node', `access_private_node' or 13121 `access_protected_node'. If bases are always public, 13122 `BINFO_BASE_ACCESSES' may be `NULL'. 13123 13124 `BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 13125 virtually or not. The other flags, `BINFO_MARKED_P' and `BINFO_FLAG_1' 13126 to `BINFO_FLAG_6' can be used for language specific use. 13127 13128 The following macros can be used on a tree node representing a 13129 class-type. 13130 13131 `LOCAL_CLASS_P' 13132 This predicate holds if the class is local class _i.e._ declared 13133 inside a function body. 13134 13135 `TYPE_POLYMORPHIC_P' 13136 This predicate holds if the class has at least one virtual function 13137 (declared or inherited). 13138 13139 `TYPE_HAS_DEFAULT_CONSTRUCTOR' 13140 This predicate holds whenever its argument represents a class-type 13141 with default constructor. 13142 13143 `CLASSTYPE_HAS_MUTABLE' 13144 `TYPE_HAS_MUTABLE_P' 13145 These predicates hold for a class-type having a mutable data 13146 member. 13147 13148 `CLASSTYPE_NON_POD_P' 13149 This predicate holds only for class-types that are not PODs. 13150 13151 `TYPE_HAS_NEW_OPERATOR' 13152 This predicate holds for a class-type that defines `operator new'. 13153 13154 `TYPE_HAS_ARRAY_NEW_OPERATOR' 13155 This predicate holds for a class-type for which `operator new[]' 13156 is defined. 13157 13158 `TYPE_OVERLOADS_CALL_EXPR' 13159 This predicate holds for class-type for which the function call 13160 `operator()' is overloaded. 13161 13162 `TYPE_OVERLOADS_ARRAY_REF' 13163 This predicate holds for a class-type that overloads `operator[]' 13164 13165 `TYPE_OVERLOADS_ARROW' 13166 This predicate holds for a class-type for which `operator->' is 13167 overloaded. 13168 13169 13170 13171 File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees 13172 13173 11.10.4 Functions for C++ 13174 ------------------------- 13175 13176 A function is represented by a `FUNCTION_DECL' node. A set of 13177 overloaded functions is sometimes represented by an `OVERLOAD' node. 13178 13179 An `OVERLOAD' node is not a declaration, so none of the `DECL_' macros 13180 should be used on an `OVERLOAD'. An `OVERLOAD' node is similar to a 13181 `TREE_LIST'. Use `OVL_CURRENT' to get the function associated with an 13182 `OVERLOAD' node; use `OVL_NEXT' to get the next `OVERLOAD' node in the 13183 list of overloaded functions. The macros `OVL_CURRENT' and `OVL_NEXT' 13184 are actually polymorphic; you can use them to work with `FUNCTION_DECL' 13185 nodes as well as with overloads. In the case of a `FUNCTION_DECL', 13186 `OVL_CURRENT' will always return the function itself, and `OVL_NEXT' 13187 will always be `NULL_TREE'. 13188 13189 To determine the scope of a function, you can use the `DECL_CONTEXT' 13190 macro. This macro will return the class (either a `RECORD_TYPE' or a 13191 `UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 13192 is a member. For a virtual function, this macro returns the class in 13193 which the function was actually defined, not the base class in which 13194 the virtual declaration occurred. 13195 13196 If a friend function is defined in a class scope, the 13197 `DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 13198 it was defined. For example, in 13199 class C { friend void f() {} }; 13200 the `DECL_CONTEXT' for `f' will be the `global_namespace', but the 13201 `DECL_FRIEND_CONTEXT' will be the `RECORD_TYPE' for `C'. 13202 13203 The following macros and functions can be used on a `FUNCTION_DECL': 13204 `DECL_MAIN_P' 13205 This predicate holds for a function that is the program entry point 13206 `::code'. 13207 13208 `DECL_LOCAL_FUNCTION_P' 13209 This predicate holds if the function was declared at block scope, 13210 even though it has a global scope. 13211 13212 `DECL_ANTICIPATED' 13213 This predicate holds if the function is a built-in function but its 13214 prototype is not yet explicitly declared. 13215 13216 `DECL_EXTERN_C_FUNCTION_P' 13217 This predicate holds if the function is declared as an ``extern 13218 "C"'' function. 13219 13220 `DECL_LINKONCE_P' 13221 This macro holds if multiple copies of this function may be 13222 emitted in various translation units. It is the responsibility of 13223 the linker to merge the various copies. Template instantiations 13224 are the most common example of functions for which 13225 `DECL_LINKONCE_P' holds; G++ instantiates needed templates in all 13226 translation units which require them, and then relies on the 13227 linker to remove duplicate instantiations. 13228 13229 FIXME: This macro is not yet implemented. 13230 13231 `DECL_FUNCTION_MEMBER_P' 13232 This macro holds if the function is a member of a class, rather 13233 than a member of a namespace. 13234 13235 `DECL_STATIC_FUNCTION_P' 13236 This predicate holds if the function a static member function. 13237 13238 `DECL_NONSTATIC_MEMBER_FUNCTION_P' 13239 This macro holds for a non-static member function. 13240 13241 `DECL_CONST_MEMFUNC_P' 13242 This predicate holds for a `const'-member function. 13243 13244 `DECL_VOLATILE_MEMFUNC_P' 13245 This predicate holds for a `volatile'-member function. 13246 13247 `DECL_CONSTRUCTOR_P' 13248 This macro holds if the function is a constructor. 13249 13250 `DECL_NONCONVERTING_P' 13251 This predicate holds if the constructor is a non-converting 13252 constructor. 13253 13254 `DECL_COMPLETE_CONSTRUCTOR_P' 13255 This predicate holds for a function which is a constructor for an 13256 object of a complete type. 13257 13258 `DECL_BASE_CONSTRUCTOR_P' 13259 This predicate holds for a function which is a constructor for a 13260 base class sub-object. 13261 13262 `DECL_COPY_CONSTRUCTOR_P' 13263 This predicate holds for a function which is a copy-constructor. 13264 13265 `DECL_DESTRUCTOR_P' 13266 This macro holds if the function is a destructor. 13267 13268 `DECL_COMPLETE_DESTRUCTOR_P' 13269 This predicate holds if the function is the destructor for an 13270 object a complete type. 13271 13272 `DECL_OVERLOADED_OPERATOR_P' 13273 This macro holds if the function is an overloaded operator. 13274 13275 `DECL_CONV_FN_P' 13276 This macro holds if the function is a type-conversion operator. 13277 13278 `DECL_GLOBAL_CTOR_P' 13279 This predicate holds if the function is a file-scope initialization 13280 function. 13281 13282 `DECL_GLOBAL_DTOR_P' 13283 This predicate holds if the function is a file-scope finalization 13284 function. 13285 13286 `DECL_THUNK_P' 13287 This predicate holds if the function is a thunk. 13288 13289 These functions represent stub code that adjusts the `this' pointer 13290 and then jumps to another function. When the jumped-to function 13291 returns, control is transferred directly to the caller, without 13292 returning to the thunk. The first parameter to the thunk is 13293 always the `this' pointer; the thunk should add `THUNK_DELTA' to 13294 this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.) 13295 13296 Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the 13297 adjusted `this' pointer must be adjusted again. The complete 13298 calculation is given by the following pseudo-code: 13299 13300 this += THUNK_DELTA 13301 if (THUNK_VCALL_OFFSET) 13302 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 13303 13304 Finally, the thunk should jump to the location given by 13305 `DECL_INITIAL'; this will always be an expression for the address 13306 of a function. 13307 13308 `DECL_NON_THUNK_FUNCTION_P' 13309 This predicate holds if the function is _not_ a thunk function. 13310 13311 `GLOBAL_INIT_PRIORITY' 13312 If either `DECL_GLOBAL_CTOR_P' or `DECL_GLOBAL_DTOR_P' holds, then 13313 this gives the initialization priority for the function. The 13314 linker will arrange that all functions for which 13315 `DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 13316 before `main' is called. When the program exits, all functions for 13317 which `DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 13318 13319 `TYPE_RAISES_EXCEPTIONS' 13320 This macro returns the list of exceptions that a (member-)function 13321 can raise. The returned list, if non `NULL', is comprised of nodes 13322 whose `TREE_VALUE' represents a type. 13323 13324 `TYPE_NOTHROW_P' 13325 This predicate holds when the exception-specification of its 13326 arguments is of the form ``()''. 13327 13328 `DECL_ARRAY_DELETE_OPERATOR_P' 13329 This predicate holds if the function an overloaded `operator 13330 delete[]'. 13331 13332 13333 13334 File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 13335 13336 11.10.5 Statements for C++ 13337 -------------------------- 13338 13339 A function that has a definition in the current translation unit will 13340 have a non-`NULL' `DECL_INITIAL'. However, back ends should not make 13341 use of the particular value given by `DECL_INITIAL'. 13342 13343 The `DECL_SAVED_TREE' macro will give the complete body of the 13344 function. 13345 13346 11.10.5.1 Statements 13347 .................... 13348 13349 There are tree nodes corresponding to all of the source-level statement 13350 constructs, used within the C and C++ frontends. These are enumerated 13351 here, together with a list of the various macros that can be used to 13352 obtain information about them. There are a few macros that can be used 13353 with all statements: 13354 13355 `STMT_IS_FULL_EXPR_P' 13356 In C++, statements normally constitute "full expressions"; 13357 temporaries created during a statement are destroyed when the 13358 statement is complete. However, G++ sometimes represents 13359 expressions by statements; these statements will not have 13360 `STMT_IS_FULL_EXPR_P' set. Temporaries created during such 13361 statements should be destroyed when the innermost enclosing 13362 statement with `STMT_IS_FULL_EXPR_P' set is exited. 13363 13364 13365 Here is the list of the various statement nodes, and the macros used to 13366 access them. This documentation describes the use of these nodes in 13367 non-template functions (including instantiations of template functions). 13368 In template functions, the same nodes are used, but sometimes in 13369 slightly different ways. 13370 13371 Many of the statements have substatements. For example, a `while' 13372 loop will have a body, which is itself a statement. If the substatement 13373 is `NULL_TREE', it is considered equivalent to a statement consisting 13374 of a single `;', i.e., an expression statement in which the expression 13375 has been omitted. A substatement may in fact be a list of statements, 13376 connected via their `TREE_CHAIN's. So, you should always process the 13377 statement tree by looping over substatements, like this: 13378 void process_stmt (stmt) 13379 tree stmt; 13380 { 13381 while (stmt) 13382 { 13383 switch (TREE_CODE (stmt)) 13384 { 13385 case IF_STMT: 13386 process_stmt (THEN_CLAUSE (stmt)); 13387 /* More processing here. */ 13388 break; 13389 13390 ... 13391 } 13392 13393 stmt = TREE_CHAIN (stmt); 13394 } 13395 } 13396 In other words, while the `then' clause of an `if' statement in C++ 13397 can be only one statement (although that one statement may be a 13398 compound statement), the intermediate representation will sometimes use 13399 several statements chained together. 13400 13401 `BREAK_STMT' 13402 Used to represent a `break' statement. There are no additional 13403 fields. 13404 13405 `CLEANUP_STMT' 13406 Used to represent an action that should take place upon exit from 13407 the enclosing scope. Typically, these actions are calls to 13408 destructors for local objects, but back ends cannot rely on this 13409 fact. If these nodes are in fact representing such destructors, 13410 `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise, 13411 `CLEANUP_DECL' will be `NULL_TREE'. In any case, the 13412 `CLEANUP_EXPR' is the expression to execute. The cleanups 13413 executed on exit from a scope should be run in the reverse order 13414 of the order in which the associated `CLEANUP_STMT's were 13415 encountered. 13416 13417 `CONTINUE_STMT' 13418 Used to represent a `continue' statement. There are no additional 13419 fields. 13420 13421 `CTOR_STMT' 13422 Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if 13423 `CTOR_END_P' holds of the main body of a constructor. See also 13424 `SUBOBJECT' for more information on how to use these nodes. 13425 13426 `DO_STMT' 13427 Used to represent a `do' loop. The body of the loop is given by 13428 `DO_BODY' while the termination condition for the loop is given by 13429 `DO_COND'. The condition for a `do'-statement is always an 13430 expression. 13431 13432 `EMPTY_CLASS_EXPR' 13433 Used to represent a temporary object of a class with no data whose 13434 address is never taken. (All such objects are interchangeable.) 13435 The `TREE_TYPE' represents the type of the object. 13436 13437 `EXPR_STMT' 13438 Used to represent an expression statement. Use `EXPR_STMT_EXPR' to 13439 obtain the expression. 13440 13441 `FOR_STMT' 13442 Used to represent a `for' statement. The `FOR_INIT_STMT' is the 13443 initialization statement for the loop. The `FOR_COND' is the 13444 termination condition. The `FOR_EXPR' is the expression executed 13445 right before the `FOR_COND' on each loop iteration; often, this 13446 expression increments a counter. The body of the loop is given by 13447 `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return 13448 statements, while `FOR_COND' and `FOR_EXPR' return expressions. 13449 13450 `HANDLER' 13451 Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the 13452 type of exception that will be caught by this handler; it is equal 13453 (by pointer equality) to `NULL' if this handler is for all types. 13454 `HANDLER_PARMS' is the `DECL_STMT' for the catch parameter, and 13455 `HANDLER_BODY' is the code for the block itself. 13456 13457 `IF_STMT' 13458 Used to represent an `if' statement. The `IF_COND' is the 13459 expression. 13460 13461 If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a 13462 statement (usually a `DECL_STMT'). Each time the condition is 13463 evaluated, the statement should be executed. Then, the 13464 `TREE_VALUE' should be used as the conditional expression itself. 13465 This representation is used to handle C++ code like this: 13466 13467 C++ distinguishes between this and `COND_EXPR' for handling 13468 templates. 13469 13470 if (int i = 7) ... 13471 13472 where there is a new local variable (or variables) declared within 13473 the condition. 13474 13475 The `THEN_CLAUSE' represents the statement given by the `then' 13476 condition, while the `ELSE_CLAUSE' represents the statement given 13477 by the `else' condition. 13478 13479 `SUBOBJECT' 13480 In a constructor, these nodes are used to mark the point at which a 13481 subobject of `this' is fully constructed. If, after this point, an 13482 exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is 13483 encountered, the `SUBOBJECT_CLEANUP' must be executed. The 13484 cleanups must be executed in the reverse order in which they 13485 appear. 13486 13487 `SWITCH_STMT' 13488 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is 13489 the expression on which the switch is occurring. See the 13490 documentation for an `IF_STMT' for more information on the 13491 representation used for the condition. The `SWITCH_STMT_BODY' is 13492 the body of the switch statement. The `SWITCH_STMT_TYPE' is the 13493 original type of switch expression as given in the source, before 13494 any compiler conversions. 13495 13496 `TRY_BLOCK' 13497 Used to represent a `try' block. The body of the try block is 13498 given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER' 13499 node. The first handler is given by `TRY_HANDLERS'. Subsequent 13500 handlers are obtained by following the `TREE_CHAIN' link from one 13501 handler to the next. The body of the handler is given by 13502 `HANDLER_BODY'. 13503 13504 If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS' 13505 will not be a `HANDLER' node. Instead, it will be an expression 13506 that should be executed if an exception is thrown in the try 13507 block. It must rethrow the exception after executing that code. 13508 And, if an exception is thrown while the expression is executing, 13509 `terminate' must be called. 13510 13511 `USING_STMT' 13512 Used to represent a `using' directive. The namespace is given by 13513 `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 13514 is needed inside template functions, to implement using directives 13515 during instantiation. 13516 13517 `WHILE_STMT' 13518 Used to represent a `while' loop. The `WHILE_COND' is the 13519 termination condition for the loop. See the documentation for an 13520 `IF_STMT' for more information on the representation used for the 13521 condition. 13522 13523 The `WHILE_BODY' is the body of the loop. 13524 13525 13526 13527 File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees 13528 13529 11.10.6 C++ Expressions 13530 ----------------------- 13531 13532 This section describes expressions specific to the C and C++ front ends. 13533 13534 `TYPEID_EXPR' 13535 Used to represent a `typeid' expression. 13536 13537 `NEW_EXPR' 13538 `VEC_NEW_EXPR' 13539 Used to represent a call to `new' and `new[]' respectively. 13540 13541 `DELETE_EXPR' 13542 `VEC_DELETE_EXPR' 13543 Used to represent a call to `delete' and `delete[]' respectively. 13544 13545 `MEMBER_REF' 13546 Represents a reference to a member of a class. 13547 13548 `THROW_EXPR' 13549 Represents an instance of `throw' in the program. Operand 0, 13550 which is the expression to throw, may be `NULL_TREE'. 13551 13552 `AGGR_INIT_EXPR' 13553 An `AGGR_INIT_EXPR' represents the initialization as the return 13554 value of a function call, or as the result of a constructor. An 13555 `AGGR_INIT_EXPR' will only appear as a full-expression, or as the 13556 second operand of a `TARGET_EXPR'. `AGGR_INIT_EXPR's have a 13557 representation similar to that of `CALL_EXPR's. You can use the 13558 `AGGR_INIT_EXPR_FN' and `AGGR_INIT_EXPR_ARG' macros to access the 13559 function to call and the arguments to pass. 13560 13561 If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the 13562 initialization is via a constructor call. The address of the 13563 `AGGR_INIT_EXPR_SLOT' operand, which is always a `VAR_DECL', is 13564 taken, and this value replaces the first argument in the argument 13565 list. 13566 13567 In either case, the expression is void. 13568 13569 13570 13571 File: gccint.info, Node: Java Trees, Prev: C and C++ Trees, Up: GENERIC 13572 13573 11.11 Java Trees 13574 ================ 13575 13576 13577 File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 13578 13579 12 GIMPLE 13580 ********* 13581 13582 GIMPLE is a three-address representation derived from GENERIC by 13583 breaking down GENERIC expressions into tuples of no more than 3 13584 operands (with some exceptions like function calls). GIMPLE was 13585 heavily influenced by the SIMPLE IL used by the McCAT compiler project 13586 at McGill University, though we have made some different choices. For 13587 one thing, SIMPLE doesn't support `goto'. 13588 13589 Temporaries are introduced to hold intermediate values needed to 13590 compute complex expressions. Additionally, all the control structures 13591 used in GENERIC are lowered into conditional jumps, lexical scopes are 13592 removed and exception regions are converted into an on the side 13593 exception region tree. 13594 13595 The compiler pass which converts GENERIC into GIMPLE is referred to as 13596 the `gimplifier'. The gimplifier works recursively, generating GIMPLE 13597 tuples out of the original GENERIC expressions. 13598 13599 One of the early implementation strategies used for the GIMPLE 13600 representation was to use the same internal data structures used by 13601 front ends to represent parse trees. This simplified implementation 13602 because we could leverage existing functionality and interfaces. 13603 However, GIMPLE is a much more restrictive representation than abstract 13604 syntax trees (AST), therefore it does not require the full structural 13605 complexity provided by the main tree data structure. 13606 13607 The GENERIC representation of a function is stored in the 13608 `DECL_SAVED_TREE' field of the associated `FUNCTION_DECL' tree node. 13609 It is converted to GIMPLE by a call to `gimplify_function_tree'. 13610 13611 If a front end wants to include language-specific tree codes in the 13612 tree representation which it provides to the back end, it must provide a 13613 definition of `LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 13614 front end trees to GIMPLE. Usually such a hook will involve much of 13615 the same code for expanding front end trees to RTL. This function can 13616 return fully lowered GIMPLE, or it can return GENERIC trees and let the 13617 main gimplifier lower them the rest of the way; this is often simpler. 13618 GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 13619 of the IL before the pass `pass_lower_cf'. High GIMPLE contains some 13620 container statements like lexical scopes (represented by `GIMPLE_BIND') 13621 and nested expressions (e.g., `GIMPLE_TRY'), while "Low GIMPLE" exposes 13622 all of the implicit jumps for control and exception expressions 13623 directly in the IL and EH region trees. 13624 13625 The C and C++ front ends currently convert directly from front end 13626 trees to GIMPLE, and hand that off to the back end rather than first 13627 converting to GENERIC. Their gimplifier hooks know about all the 13628 `_STMT' nodes and how to convert them to GENERIC forms. There was some 13629 work done on a genericization pass which would run first, but the 13630 existence of `STMT_EXPR' meant that in order to convert all of the C 13631 statements into GENERIC equivalents would involve walking the entire 13632 tree anyway, so it was simpler to lower all the way. This might change 13633 in the future if someone writes an optimization pass which would work 13634 better with higher-level trees, but currently the optimizers all expect 13635 GIMPLE. 13636 13637 You can request to dump a C-like representation of the GIMPLE form 13638 with the flag `-fdump-tree-gimple'. 13639 13640 * Menu: 13641 13642 * Tuple representation:: 13643 * GIMPLE instruction set:: 13644 * GIMPLE Exception Handling:: 13645 * Temporaries:: 13646 * Operands:: 13647 * Manipulating GIMPLE statements:: 13648 * Tuple specific accessors:: 13649 * GIMPLE sequences:: 13650 * Sequence iterators:: 13651 * Adding a new GIMPLE statement code:: 13652 * Statement and operand traversals:: 13653 13654 13655 File: gccint.info, Node: Tuple representation, Next: GIMPLE instruction set, Up: GIMPLE 13656 13657 12.1 Tuple representation 13658 ========================= 13659 13660 GIMPLE instructions are tuples of variable size divided in two groups: 13661 a header describing the instruction and its locations, and a variable 13662 length body with all the operands. Tuples are organized into a 13663 hierarchy with 3 main classes of tuples. 13664 13665 12.1.1 `gimple_statement_base' (gsbase) 13666 --------------------------------------- 13667 13668 This is the root of the hierarchy, it holds basic information needed by 13669 most GIMPLE statements. There are some fields that may not be relevant 13670 to every GIMPLE statement, but those were moved into the base structure 13671 to take advantage of holes left by other fields (thus making the 13672 structure more compact). The structure takes 4 words (32 bytes) on 64 13673 bit hosts: 13674 13675 Field Size (bits) 13676 `code' 8 13677 `subcode' 16 13678 `no_warning' 1 13679 `visited' 1 13680 `nontemporal_move' 1 13681 `plf' 2 13682 `modified' 1 13683 `has_volatile_ops' 1 13684 `references_memory_p' 1 13685 `uid' 32 13686 `location' 32 13687 `num_ops' 32 13688 `bb' 64 13689 `block' 63 13690 Total size 32 bytes 13691 13692 * `code' Main identifier for a GIMPLE instruction. 13693 13694 * `subcode' Used to distinguish different variants of the same basic 13695 instruction or provide flags applicable to a given code. The 13696 `subcode' flags field has different uses depending on the code of 13697 the instruction, but mostly it distinguishes instructions of the 13698 same family. The most prominent use of this field is in 13699 assignments, where subcode indicates the operation done on the RHS 13700 of the assignment. For example, a = b + c is encoded as 13701 `GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 13702 13703 * `no_warning' Bitflag to indicate whether a warning has already 13704 been issued on this statement. 13705 13706 * `visited' General purpose "visited" marker. Set and cleared by 13707 each pass when needed. 13708 13709 * `nontemporal_move' Bitflag used in assignments that represent 13710 non-temporal moves. Although this bitflag is only used in 13711 assignments, it was moved into the base to take advantage of the 13712 bit holes left by the previous fields. 13713 13714 * `plf' Pass Local Flags. This 2-bit mask can be used as general 13715 purpose markers by any pass. Passes are responsible for clearing 13716 and setting these two flags accordingly. 13717 13718 * `modified' Bitflag to indicate whether the statement has been 13719 modified. Used mainly by the operand scanner to determine when to 13720 re-scan a statement for operands. 13721 13722 * `has_volatile_ops' Bitflag to indicate whether this statement 13723 contains operands that have been marked volatile. 13724 13725 * `references_memory_p' Bitflag to indicate whether this statement 13726 contains memory references (i.e., its operands are either global 13727 variables, or pointer dereferences or anything that must reside in 13728 memory). 13729 13730 * `uid' This is an unsigned integer used by passes that want to 13731 assign IDs to every statement. These IDs must be assigned and used 13732 by each pass. 13733 13734 * `location' This is a `location_t' identifier to specify source code 13735 location for this statement. It is inherited from the front end. 13736 13737 * `num_ops' Number of operands that this statement has. This 13738 specifies the size of the operand vector embedded in the tuple. 13739 Only used in some tuples, but it is declared in the base tuple to 13740 take advantage of the 32-bit hole left by the previous fields. 13741 13742 * `bb' Basic block holding the instruction. 13743 13744 * `block' Lexical block holding this statement. Also used for debug 13745 information generation. 13746 13747 12.1.2 `gimple_statement_with_ops' 13748 ---------------------------------- 13749 13750 This tuple is actually split in two: `gimple_statement_with_ops_base' 13751 and `gimple_statement_with_ops'. This is needed to accommodate the way 13752 the operand vector is allocated. The operand vector is defined to be an 13753 array of 1 element. So, to allocate a dynamic number of operands, the 13754 memory allocator (`gimple_alloc') simply allocates enough memory to 13755 hold the structure itself plus `N - 1' operands which run "off the end" 13756 of the structure. For example, to allocate space for a tuple with 3 13757 operands, `gimple_alloc' reserves `sizeof (struct 13758 gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 13759 13760 On the other hand, several fields in this tuple need to be shared with 13761 the `gimple_statement_with_memory_ops' tuple. So, these common fields 13762 are placed in `gimple_statement_with_ops_base' which is then inherited 13763 from the other two tuples. 13764 13765 `gsbase' 256 13766 `def_ops' 64 13767 `use_ops' 64 13768 `op' `num_ops' * 64 13769 Total size 48 + 8 * `num_ops' bytes 13770 13771 * `gsbase' Inherited from `struct gimple_statement_base'. 13772 13773 * `def_ops' Array of pointers into the operand array indicating all 13774 the slots that contain a variable written-to by the statement. 13775 This array is also used for immediate use chaining. Note that it 13776 would be possible to not rely on this array, but the changes 13777 required to implement this are pretty invasive. 13778 13779 * `use_ops' Similar to `def_ops' but for variables read by the 13780 statement. 13781 13782 * `op' Array of trees with `num_ops' slots. 13783 13784 12.1.3 `gimple_statement_with_memory_ops' 13785 ----------------------------------------- 13786 13787 This tuple is essentially identical to `gimple_statement_with_ops', 13788 except that it contains 4 additional fields to hold vectors related 13789 memory stores and loads. Similar to the previous case, the structure 13790 is split in two to accommodate for the operand vector 13791 (`gimple_statement_with_memory_ops_base' and 13792 `gimple_statement_with_memory_ops'). 13793 13794 Field Size (bits) 13795 `gsbase' 256 13796 `def_ops' 64 13797 `use_ops' 64 13798 `vdef_ops' 64 13799 `vuse_ops' 64 13800 `stores' 64 13801 `loads' 64 13802 `op' `num_ops' * 64 13803 Total size 80 + 8 * `num_ops' bytes 13804 13805 * `vdef_ops' Similar to `def_ops' but for `VDEF' operators. There is 13806 one entry per memory symbol written by this statement. This is 13807 used to maintain the memory SSA use-def and def-def chains. 13808 13809 * `vuse_ops' Similar to `use_ops' but for `VUSE' operators. There is 13810 one entry per memory symbol loaded by this statement. This is used 13811 to maintain the memory SSA use-def chains. 13812 13813 * `stores' Bitset with all the UIDs for the symbols written-to by the 13814 statement. This is different than `vdef_ops' in that all the 13815 affected symbols are mentioned in this set. If memory 13816 partitioning is enabled, the `vdef_ops' vector will refer to memory 13817 partitions. Furthermore, no SSA information is stored in this set. 13818 13819 * `loads' Similar to `stores', but for memory loads. (Note that there 13820 is some amount of redundancy here, it should be possible to reduce 13821 memory utilization further by removing these sets). 13822 13823 All the other tuples are defined in terms of these three basic ones. 13824 Each tuple will add some fields. The main gimple type is defined to be 13825 the union of all these structures (`GTY' markers elided for clarity): 13826 13827 union gimple_statement_d 13828 { 13829 struct gimple_statement_base gsbase; 13830 struct gimple_statement_with_ops gsops; 13831 struct gimple_statement_with_memory_ops gsmem; 13832 struct gimple_statement_omp omp; 13833 struct gimple_statement_bind gimple_bind; 13834 struct gimple_statement_catch gimple_catch; 13835 struct gimple_statement_eh_filter gimple_eh_filter; 13836 struct gimple_statement_phi gimple_phi; 13837 struct gimple_statement_resx gimple_resx; 13838 struct gimple_statement_try gimple_try; 13839 struct gimple_statement_wce gimple_wce; 13840 struct gimple_statement_asm gimple_asm; 13841 struct gimple_statement_omp_critical gimple_omp_critical; 13842 struct gimple_statement_omp_for gimple_omp_for; 13843 struct gimple_statement_omp_parallel gimple_omp_parallel; 13844 struct gimple_statement_omp_task gimple_omp_task; 13845 struct gimple_statement_omp_sections gimple_omp_sections; 13846 struct gimple_statement_omp_single gimple_omp_single; 13847 struct gimple_statement_omp_continue gimple_omp_continue; 13848 struct gimple_statement_omp_atomic_load gimple_omp_atomic_load; 13849 struct gimple_statement_omp_atomic_store gimple_omp_atomic_store; 13850 }; 13851 13852 13853 File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Tuple representation, Up: GIMPLE 13854 13855 12.2 GIMPLE instruction set 13856 =========================== 13857 13858 The following table briefly describes the GIMPLE instruction set. 13859 13860 Instruction High GIMPLE Low GIMPLE 13861 `GIMPLE_ASM' x x 13862 `GIMPLE_ASSIGN' x x 13863 `GIMPLE_BIND' x 13864 `GIMPLE_CALL' x x 13865 `GIMPLE_CATCH' x 13866 `GIMPLE_COND' x x 13867 `GIMPLE_DEBUG' x x 13868 `GIMPLE_EH_FILTER' x 13869 `GIMPLE_GOTO' x x 13870 `GIMPLE_LABEL' x x 13871 `GIMPLE_NOP' x x 13872 `GIMPLE_OMP_ATOMIC_LOAD' x x 13873 `GIMPLE_OMP_ATOMIC_STORE' x x 13874 `GIMPLE_OMP_CONTINUE' x x 13875 `GIMPLE_OMP_CRITICAL' x x 13876 `GIMPLE_OMP_FOR' x x 13877 `GIMPLE_OMP_MASTER' x x 13878 `GIMPLE_OMP_ORDERED' x x 13879 `GIMPLE_OMP_PARALLEL' x x 13880 `GIMPLE_OMP_RETURN' x x 13881 `GIMPLE_OMP_SECTION' x x 13882 `GIMPLE_OMP_SECTIONS' x x 13883 `GIMPLE_OMP_SECTIONS_SWITCH' x x 13884 `GIMPLE_OMP_SINGLE' x x 13885 `GIMPLE_PHI' x 13886 `GIMPLE_RESX' x 13887 `GIMPLE_RETURN' x x 13888 `GIMPLE_SWITCH' x x 13889 `GIMPLE_TRY' x 13890 13891 13892 File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 13893 13894 12.3 Exception Handling 13895 ======================= 13896 13897 Other exception handling constructs are represented using 13898 `GIMPLE_TRY_CATCH'. `GIMPLE_TRY_CATCH' has two operands. The first 13899 operand is a sequence of statements to execute. If executing these 13900 statements does not throw an exception, then the second operand is 13901 ignored. Otherwise, if an exception is thrown, then the second operand 13902 of the `GIMPLE_TRY_CATCH' is checked. The second operand may have the 13903 following forms: 13904 13905 1. A sequence of statements to execute. When an exception occurs, 13906 these statements are executed, and then the exception is rethrown. 13907 13908 2. A sequence of `GIMPLE_CATCH' statements. Each `GIMPLE_CATCH' has 13909 a list of applicable exception types and handler code. If the 13910 thrown exception matches one of the caught types, the associated 13911 handler code is executed. If the handler code falls off the 13912 bottom, execution continues after the original `GIMPLE_TRY_CATCH'. 13913 13914 3. A `GIMPLE_EH_FILTER' statement. This has a list of permitted 13915 exception types, and code to handle a match failure. If the 13916 thrown exception does not match one of the allowed types, the 13917 associated match failure code is executed. If the thrown exception 13918 does match, it continues unwinding the stack looking for the next 13919 handler. 13920 13921 13922 Currently throwing an exception is not directly represented in GIMPLE, 13923 since it is implemented by calling a function. At some point in the 13924 future we will want to add some way to express that the call will throw 13925 an exception of a known type. 13926 13927 Just before running the optimizers, the compiler lowers the high-level 13928 EH constructs above into a set of `goto's, magic labels, and EH 13929 regions. Continuing to unwind at the end of a cleanup is represented 13930 with a `GIMPLE_RESX'. 13931 13932 13933 File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 13934 13935 12.4 Temporaries 13936 ================ 13937 13938 When gimplification encounters a subexpression that is too complex, it 13939 creates a new temporary variable to hold the value of the 13940 subexpression, and adds a new statement to initialize it before the 13941 current statement. These special temporaries are known as `expression 13942 temporaries', and are allocated using `get_formal_tmp_var'. The 13943 compiler tries to always evaluate identical expressions into the same 13944 temporary, to simplify elimination of redundant calculations. 13945 13946 We can only use expression temporaries when we know that it will not 13947 be reevaluated before its value is used, and that it will not be 13948 otherwise modified(1). Other temporaries can be allocated using 13949 `get_initialized_tmp_var' or `create_tmp_var'. 13950 13951 Currently, an expression like `a = b + 5' is not reduced any further. 13952 We tried converting it to something like 13953 T1 = b + 5; 13954 a = T1; 13955 but this bloated the representation for minimal benefit. However, a 13956 variable which must live in memory cannot appear in an expression; its 13957 value is explicitly loaded into a temporary first. Similarly, storing 13958 the value of an expression to a memory variable goes through a 13959 temporary. 13960 13961 ---------- Footnotes ---------- 13962 13963 (1) These restrictions are derived from those in Morgan 4.8. 13964 13965 13966 File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 13967 13968 12.5 Operands 13969 ============= 13970 13971 In general, expressions in GIMPLE consist of an operation and the 13972 appropriate number of simple operands; these operands must either be a 13973 GIMPLE rvalue (`is_gimple_val'), i.e. a constant or a register 13974 variable. More complex operands are factored out into temporaries, so 13975 that 13976 a = b + c + d 13977 becomes 13978 T1 = b + c; 13979 a = T1 + d; 13980 13981 The same rule holds for arguments to a `GIMPLE_CALL'. 13982 13983 The target of an assignment is usually a variable, but can also be a 13984 `MEM_REF' or a compound lvalue as described below. 13985 13986 * Menu: 13987 13988 * Compound Expressions:: 13989 * Compound Lvalues:: 13990 * Conditional Expressions:: 13991 * Logical Operators:: 13992 13993 13994 File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 13995 13996 12.5.1 Compound Expressions 13997 --------------------------- 13998 13999 The left-hand side of a C comma expression is simply moved into a 14000 separate statement. 14001 14002 14003 File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 14004 14005 12.5.2 Compound Lvalues 14006 ----------------------- 14007 14008 Currently compound lvalues involving array and structure field 14009 references are not broken down; an expression like `a.b[2] = 42' is not 14010 reduced any further (though complex array subscripts are). This 14011 restriction is a workaround for limitations in later optimizers; if we 14012 were to convert this to 14013 14014 T1 = &a.b; 14015 T1[2] = 42; 14016 14017 alias analysis would not remember that the reference to `T1[2]' came 14018 by way of `a.b', so it would think that the assignment could alias 14019 another member of `a'; this broke `struct-alias-1.c'. Future optimizer 14020 improvements may make this limitation unnecessary. 14021 14022 14023 File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 14024 14025 12.5.3 Conditional Expressions 14026 ------------------------------ 14027 14028 A C `?:' expression is converted into an `if' statement with each 14029 branch assigning to the same temporary. So, 14030 14031 a = b ? c : d; 14032 becomes 14033 if (b == 1) 14034 T1 = c; 14035 else 14036 T1 = d; 14037 a = T1; 14038 14039 The GIMPLE level if-conversion pass re-introduces `?:' expression, if 14040 appropriate. It is used to vectorize loops with conditions using vector 14041 conditional operations. 14042 14043 Note that in GIMPLE, `if' statements are represented using 14044 `GIMPLE_COND', as described below. 14045 14046 14047 File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 14048 14049 12.5.4 Logical Operators 14050 ------------------------ 14051 14052 Except when they appear in the condition operand of a `GIMPLE_COND', 14053 logical `and' and `or' operators are simplified as follows: `a = b && 14054 c' becomes 14055 14056 T1 = (bool)b; 14057 if (T1 == true) 14058 T1 = (bool)c; 14059 a = T1; 14060 14061 Note that `T1' in this example cannot be an expression temporary, 14062 because it has two different assignments. 14063 14064 12.5.5 Manipulating operands 14065 ---------------------------- 14066 14067 All gimple operands are of type `tree'. But only certain types of 14068 trees are allowed to be used as operand tuples. Basic validation is 14069 controlled by the function `get_gimple_rhs_class', which given a tree 14070 code, returns an `enum' with the following values of type `enum 14071 gimple_rhs_class' 14072 14073 * `GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 14074 14075 * `GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation. 14076 14077 * `GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 14078 14079 * `GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 14080 14081 * `GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 14082 split into simpler operands (for instance, `SSA_NAME', `VAR_DECL', 14083 `COMPONENT_REF', etc). 14084 14085 This operand class also acts as an escape hatch for tree nodes 14086 that may be flattened out into the operand vector, but would need 14087 more than two slots on the RHS. For instance, a `COND_EXPR' 14088 expression of the form `(a op b) ? x : y' could be flattened out 14089 on the operand vector using 4 slots, but it would also require 14090 additional processing to distinguish `c = a op b' from `c = a op b 14091 ? x : y'. Something similar occurs with `ASSERT_EXPR'. In time, 14092 these special case tree expressions should be flattened into the 14093 operand vector. 14094 14095 For tree nodes in the categories `GIMPLE_TERNARY_RHS', 14096 `GIMPLE_BINARY_RHS' and `GIMPLE_UNARY_RHS', they cannot be stored 14097 inside tuples directly. They first need to be flattened and separated 14098 into individual components. For instance, given the GENERIC expression 14099 14100 a = b + c 14101 14102 its tree representation is: 14103 14104 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 14105 14106 In this case, the GIMPLE form for this statement is logically 14107 identical to its GENERIC form but in GIMPLE, the `PLUS_EXPR' on the RHS 14108 of the assignment is not represented as a tree, instead the two 14109 operands are taken out of the `PLUS_EXPR' sub-tree and flattened into 14110 the GIMPLE tuple as follows: 14111 14112 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 14113 14114 12.5.6 Operand vector allocation 14115 -------------------------------- 14116 14117 The operand vector is stored at the bottom of the three tuple 14118 structures that accept operands. This means, that depending on the code 14119 of a given statement, its operand vector will be at different offsets 14120 from the base of the structure. To access tuple operands use the 14121 following accessors 14122 14123 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 14124 Returns the number of operands in statement G. 14125 14126 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 14127 Returns operand `I' from statement `G'. 14128 14129 -- GIMPLE function: tree * gimple_ops (gimple g) 14130 Returns a pointer into the operand vector for statement `G'. This 14131 is computed using an internal table called `gimple_ops_offset_'[]. 14132 This table is indexed by the gimple code of `G'. 14133 14134 When the compiler is built, this table is filled-in using the 14135 sizes of the structures used by each statement code defined in 14136 gimple.def. Since the operand vector is at the bottom of the 14137 structure, for a gimple code `C' the offset is computed as sizeof 14138 (struct-of `C') - sizeof (tree). 14139 14140 This mechanism adds one memory indirection to every access when 14141 using `gimple_op'(), if this becomes a bottleneck, a pass can 14142 choose to memoize the result from `gimple_ops'() and use that to 14143 access the operands. 14144 14145 12.5.7 Operand validation 14146 ------------------------- 14147 14148 When adding a new operand to a gimple statement, the operand will be 14149 validated according to what each tuple accepts in its operand vector. 14150 These predicates are called by the `gimple_NAME_set_...()'. Each tuple 14151 will use one of the following predicates (Note, this list is not 14152 exhaustive): 14153 14154 -- GIMPLE function: bool is_gimple_val (tree t) 14155 Returns true if t is a "GIMPLE value", which are all the 14156 non-addressable stack variables (variables for which 14157 `is_gimple_reg' returns true) and constants (expressions for which 14158 `is_gimple_min_invariant' returns true). 14159 14160 -- GIMPLE function: bool is_gimple_addressable (tree t) 14161 Returns true if t is a symbol or memory reference whose address 14162 can be taken. 14163 14164 -- GIMPLE function: bool is_gimple_asm_val (tree t) 14165 Similar to `is_gimple_val' but it also accepts hard registers. 14166 14167 -- GIMPLE function: bool is_gimple_call_addr (tree t) 14168 Return true if t is a valid expression to use as the function 14169 called by a `GIMPLE_CALL'. 14170 14171 -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t) 14172 Return true if t is a valid expression to use as first operand of 14173 a `MEM_REF' expression. 14174 14175 -- GIMPLE function: bool is_gimple_constant (tree t) 14176 Return true if t is a valid gimple constant. 14177 14178 -- GIMPLE function: bool is_gimple_min_invariant (tree t) 14179 Return true if t is a valid minimal invariant. This is different 14180 from constants, in that the specific value of t may not be known 14181 at compile time, but it is known that it doesn't change (e.g., the 14182 address of a function local variable). 14183 14184 -- GIMPLE function: bool is_gimple_ip_invariant (tree t) 14185 Return true if t is an interprocedural invariant. This means that 14186 t is a valid invariant in all functions (e.g. it can be an address 14187 of a global variable but not of a local one). 14188 14189 -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t) 14190 Return true if t is an `ADDR_EXPR' that does not change once the 14191 program is running (and which is valid in all functions). 14192 14193 12.5.8 Statement validation 14194 --------------------------- 14195 14196 -- GIMPLE function: bool is_gimple_assign (gimple g) 14197 Return true if the code of g is `GIMPLE_ASSIGN'. 14198 14199 -- GIMPLE function: bool is_gimple_call (gimple g) 14200 Return true if the code of g is `GIMPLE_CALL'. 14201 14202 -- GIMPLE function: bool is_gimple_debug (gimple g) 14203 Return true if the code of g is `GIMPLE_DEBUG'. 14204 14205 -- GIMPLE function: bool gimple_assign_cast_p (gimple g) 14206 Return true if g is a `GIMPLE_ASSIGN' that performs a type cast 14207 operation. 14208 14209 -- GIMPLE function: bool gimple_debug_bind_p (gimple g) 14210 Return true if g is a `GIMPLE_DEBUG' that binds the value of an 14211 expression to a variable. 14212 14213 14214 File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 14215 14216 12.6 Manipulating GIMPLE statements 14217 =================================== 14218 14219 This section documents all the functions available to handle each of 14220 the GIMPLE instructions. 14221 14222 12.6.1 Common accessors 14223 ----------------------- 14224 14225 The following are common accessors for gimple statements. 14226 14227 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 14228 Return the code for statement `G'. 14229 14230 -- GIMPLE function: basic_block gimple_bb (gimple g) 14231 Return the basic block to which statement `G' belongs to. 14232 14233 -- GIMPLE function: tree gimple_block (gimple g) 14234 Return the lexical scope block holding statement `G'. 14235 14236 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 14237 Return the type of the main expression computed by `STMT'. Return 14238 `void_type_node' if `STMT' computes nothing. This will only return 14239 something meaningful for `GIMPLE_ASSIGN', `GIMPLE_COND' and 14240 `GIMPLE_CALL'. For all other tuple codes, it will return 14241 `void_type_node'. 14242 14243 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 14244 Return the tree code for the expression computed by `STMT'. This 14245 is only meaningful for `GIMPLE_CALL', `GIMPLE_ASSIGN' and 14246 `GIMPLE_COND'. If `STMT' is `GIMPLE_CALL', it will return 14247 `CALL_EXPR'. For `GIMPLE_COND', it returns the code of the 14248 comparison predicate. For `GIMPLE_ASSIGN' it returns the code of 14249 the operation performed by the `RHS' of the assignment. 14250 14251 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 14252 Set the lexical scope block of `G' to `BLOCK'. 14253 14254 -- GIMPLE function: location_t gimple_locus (gimple g) 14255 Return locus information for statement `G'. 14256 14257 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 14258 Set locus information for statement `G'. 14259 14260 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 14261 Return true if `G' does not have locus information. 14262 14263 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 14264 Return true if no warnings should be emitted for statement `STMT'. 14265 14266 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 14267 visited_p) 14268 Set the visited status on statement `STMT' to `VISITED_P'. 14269 14270 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 14271 Return the visited status on statement `STMT'. 14272 14273 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 14274 plf, bool val_p) 14275 Set pass local flag `PLF' on statement `STMT' to `VAL_P'. 14276 14277 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum 14278 plf_mask plf) 14279 Return the value of pass local flag `PLF' on statement `STMT'. 14280 14281 -- GIMPLE function: bool gimple_has_ops (gimple g) 14282 Return true if statement `G' has register or memory operands. 14283 14284 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 14285 Return true if statement `G' has memory operands. 14286 14287 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 14288 Return the number of operands for statement `G'. 14289 14290 -- GIMPLE function: tree * gimple_ops (gimple g) 14291 Return the array of operands for statement `G'. 14292 14293 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 14294 Return operand `I' for statement `G'. 14295 14296 -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i) 14297 Return a pointer to operand `I' for statement `G'. 14298 14299 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 14300 Set operand `I' of statement `G' to `OP'. 14301 14302 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 14303 Return the set of symbols that have had their address taken by 14304 `STMT'. 14305 14306 -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g) 14307 Return the set of `DEF' operands for statement `G'. 14308 14309 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 14310 def_optype_d *def) 14311 Set `DEF' to be the set of `DEF' operands for statement `G'. 14312 14313 -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g) 14314 Return the set of `USE' operands for statement `G'. 14315 14316 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 14317 use_optype_d *use) 14318 Set `USE' to be the set of `USE' operands for statement `G'. 14319 14320 -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g) 14321 Return the set of `VUSE' operands for statement `G'. 14322 14323 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 14324 voptype_d *ops) 14325 Set `OPS' to be the set of `VUSE' operands for statement `G'. 14326 14327 -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g) 14328 Return the set of `VDEF' operands for statement `G'. 14329 14330 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 14331 voptype_d *ops) 14332 Set `OPS' to be the set of `VDEF' operands for statement `G'. 14333 14334 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 14335 Return the set of symbols loaded by statement `G'. Each element of 14336 the set is the `DECL_UID' of the corresponding symbol. 14337 14338 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 14339 Return the set of symbols stored by statement `G'. Each element of 14340 the set is the `DECL_UID' of the corresponding symbol. 14341 14342 -- GIMPLE function: bool gimple_modified_p (gimple g) 14343 Return true if statement `G' has operands and the modified field 14344 has been set. 14345 14346 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 14347 Return true if statement `STMT' contains volatile operands. 14348 14349 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, 14350 bool volatilep) 14351 Return true if statement `STMT' contains volatile operands. 14352 14353 -- GIMPLE function: void update_stmt (gimple s) 14354 Mark statement `S' as modified, and update it. 14355 14356 -- GIMPLE function: void update_stmt_if_modified (gimple s) 14357 Update statement `S' if it has been marked modified. 14358 14359 -- GIMPLE function: gimple gimple_copy (gimple stmt) 14360 Return a deep copy of statement `STMT'. 14361 14362 14363 File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 14364 14365 12.7 Tuple specific accessors 14366 ============================= 14367 14368 * Menu: 14369 14370 * `GIMPLE_ASM':: 14371 * `GIMPLE_ASSIGN':: 14372 * `GIMPLE_BIND':: 14373 * `GIMPLE_CALL':: 14374 * `GIMPLE_CATCH':: 14375 * `GIMPLE_COND':: 14376 * `GIMPLE_DEBUG':: 14377 * `GIMPLE_EH_FILTER':: 14378 * `GIMPLE_LABEL':: 14379 * `GIMPLE_NOP':: 14380 * `GIMPLE_OMP_ATOMIC_LOAD':: 14381 * `GIMPLE_OMP_ATOMIC_STORE':: 14382 * `GIMPLE_OMP_CONTINUE':: 14383 * `GIMPLE_OMP_CRITICAL':: 14384 * `GIMPLE_OMP_FOR':: 14385 * `GIMPLE_OMP_MASTER':: 14386 * `GIMPLE_OMP_ORDERED':: 14387 * `GIMPLE_OMP_PARALLEL':: 14388 * `GIMPLE_OMP_RETURN':: 14389 * `GIMPLE_OMP_SECTION':: 14390 * `GIMPLE_OMP_SECTIONS':: 14391 * `GIMPLE_OMP_SINGLE':: 14392 * `GIMPLE_PHI':: 14393 * `GIMPLE_RESX':: 14394 * `GIMPLE_RETURN':: 14395 * `GIMPLE_SWITCH':: 14396 * `GIMPLE_TRY':: 14397 * `GIMPLE_WITH_CLEANUP_EXPR':: 14398 14399 14400 File: gccint.info, Node: `GIMPLE_ASM', Next: `GIMPLE_ASSIGN', Up: Tuple specific accessors 14401 14402 12.7.1 `GIMPLE_ASM' 14403 ------------------- 14404 14405 -- GIMPLE function: gimple gimple_build_asm (const char *string, 14406 ninputs, noutputs, nclobbers, ...) 14407 Build a `GIMPLE_ASM' statement. This statement is used for 14408 building in-line assembly constructs. `STRING' is the assembly 14409 code. `NINPUT' is the number of register inputs. `NOUTPUT' is the 14410 number of register outputs. `NCLOBBERS' is the number of clobbered 14411 registers. The rest of the arguments trees for each input, 14412 output, and clobbered registers. 14413 14414 -- GIMPLE function: gimple gimple_build_asm_vec (const char *, 14415 VEC(tree,gc) *, VEC(tree,gc) *, VEC(tree,gc) *) 14416 Identical to gimple_build_asm, but the arguments are passed in 14417 VECs. 14418 14419 -- GIMPLE function: unsigned gimple_asm_ninputs (gimple g) 14420 Return the number of input operands for `GIMPLE_ASM' `G'. 14421 14422 -- GIMPLE function: unsigned gimple_asm_noutputs (gimple g) 14423 Return the number of output operands for `GIMPLE_ASM' `G'. 14424 14425 -- GIMPLE function: unsigned gimple_asm_nclobbers (gimple g) 14426 Return the number of clobber operands for `GIMPLE_ASM' `G'. 14427 14428 -- GIMPLE function: tree gimple_asm_input_op (gimple g, unsigned index) 14429 Return input operand `INDEX' of `GIMPLE_ASM' `G'. 14430 14431 -- GIMPLE function: void gimple_asm_set_input_op (gimple g, unsigned 14432 index, tree in_op) 14433 Set `IN_OP' to be input operand `INDEX' in `GIMPLE_ASM' `G'. 14434 14435 -- GIMPLE function: tree gimple_asm_output_op (gimple g, unsigned 14436 index) 14437 Return output operand `INDEX' of `GIMPLE_ASM' `G'. 14438 14439 -- GIMPLE function: void gimple_asm_set_output_op (gimple g, unsigned 14440 index, tree out_op) 14441 Set `OUT_OP' to be output operand `INDEX' in `GIMPLE_ASM' `G'. 14442 14443 -- GIMPLE function: tree gimple_asm_clobber_op (gimple g, unsigned 14444 index) 14445 Return clobber operand `INDEX' of `GIMPLE_ASM' `G'. 14446 14447 -- GIMPLE function: void gimple_asm_set_clobber_op (gimple g, unsigned 14448 index, tree clobber_op) 14449 Set `CLOBBER_OP' to be clobber operand `INDEX' in `GIMPLE_ASM' `G'. 14450 14451 -- GIMPLE function: const char * gimple_asm_string (gimple g) 14452 Return the string representing the assembly instruction in 14453 `GIMPLE_ASM' `G'. 14454 14455 -- GIMPLE function: bool gimple_asm_volatile_p (gimple g) 14456 Return true if `G' is an asm statement marked volatile. 14457 14458 -- GIMPLE function: void gimple_asm_set_volatile (gimple g) 14459 Mark asm statement `G' as volatile. 14460 14461 -- GIMPLE function: void gimple_asm_clear_volatile (gimple g) 14462 Remove volatile marker from asm statement `G'. 14463 14464 14465 File: gccint.info, Node: `GIMPLE_ASSIGN', Next: `GIMPLE_BIND', Prev: `GIMPLE_ASM', Up: Tuple specific accessors 14466 14467 12.7.2 `GIMPLE_ASSIGN' 14468 ---------------------- 14469 14470 -- GIMPLE function: gimple gimple_build_assign (tree lhs, tree rhs) 14471 Build a `GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 14472 passed in lhs. The right-hand side can be either a unary or 14473 binary tree expression. The expression tree rhs will be flattened 14474 and its operands assigned to the corresponding operand slots in 14475 the new statement. This function is useful when you already have 14476 a tree expression that you want to convert into a tuple. However, 14477 try to avoid building expression trees for the sole purpose of 14478 calling this function. If you already have the operands in 14479 separate trees, it is better to use `gimple_build_assign_with_ops'. 14480 14481 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 14482 gimple_seq *seq_p) 14483 Build a new `GIMPLE_ASSIGN' tuple and append it to the end of 14484 `*SEQ_P'. 14485 14486 `DST'/`SRC' are the destination and source respectively. You can pass 14487 ungimplified trees in `DST' or `SRC', in which case they will be 14488 converted to a gimple operand if necessary. 14489 14490 This function returns the newly created `GIMPLE_ASSIGN' tuple. 14491 14492 -- GIMPLE function: gimple gimple_build_assign_with_ops (enum 14493 tree_code subcode, tree lhs, tree op1, tree op2) 14494 This function is similar to `gimple_build_assign', but is used to 14495 build a `GIMPLE_ASSIGN' statement when the operands of the 14496 right-hand side of the assignment are already split into different 14497 operands. 14498 14499 The left-hand side is an lvalue passed in lhs. Subcode is the 14500 `tree_code' for the right-hand side of the assignment. Op1 and op2 14501 are the operands. If op2 is null, subcode must be a `tree_code' 14502 for a unary expression. 14503 14504 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 14505 Return the code of the expression computed on the `RHS' of 14506 assignment statement `G'. 14507 14508 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 14509 (gimple g) 14510 Return the gimple rhs class of the code for the expression 14511 computed on the rhs of assignment statement `G'. This will never 14512 return `GIMPLE_INVALID_RHS'. 14513 14514 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 14515 Return the `LHS' of assignment statement `G'. 14516 14517 -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g) 14518 Return a pointer to the `LHS' of assignment statement `G'. 14519 14520 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 14521 Return the first operand on the `RHS' of assignment statement `G'. 14522 14523 -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g) 14524 Return the address of the first operand on the `RHS' of assignment 14525 statement `G'. 14526 14527 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 14528 Return the second operand on the `RHS' of assignment statement `G'. 14529 14530 -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g) 14531 Return the address of the second operand on the `RHS' of assignment 14532 statement `G'. 14533 14534 -- GIMPLE function: tree gimple_assign_rhs3 (gimple g) 14535 Return the third operand on the `RHS' of assignment statement `G'. 14536 14537 -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g) 14538 Return the address of the third operand on the `RHS' of assignment 14539 statement `G'. 14540 14541 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 14542 Set `LHS' to be the `LHS' operand of assignment statement `G'. 14543 14544 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 14545 Set `RHS' to be the first operand on the `RHS' of assignment 14546 statement `G'. 14547 14548 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 14549 Set `RHS' to be the second operand on the `RHS' of assignment 14550 statement `G'. 14551 14552 -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs) 14553 Set `RHS' to be the third operand on the `RHS' of assignment 14554 statement `G'. 14555 14556 -- GIMPLE function: bool gimple_assign_cast_p (gimple s) 14557 Return true if `S' is a type-cast assignment. 14558 14559 14560 File: gccint.info, Node: `GIMPLE_BIND', Next: `GIMPLE_CALL', Prev: `GIMPLE_ASSIGN', Up: Tuple specific accessors 14561 14562 12.7.3 `GIMPLE_BIND' 14563 -------------------- 14564 14565 -- GIMPLE function: gimple gimple_build_bind (tree vars, gimple_seq 14566 body) 14567 Build a `GIMPLE_BIND' statement with a list of variables in `VARS' 14568 and a body of statements in sequence `BODY'. 14569 14570 -- GIMPLE function: tree gimple_bind_vars (gimple g) 14571 Return the variables declared in the `GIMPLE_BIND' statement `G'. 14572 14573 -- GIMPLE function: void gimple_bind_set_vars (gimple g, tree vars) 14574 Set `VARS' to be the set of variables declared in the `GIMPLE_BIND' 14575 statement `G'. 14576 14577 -- GIMPLE function: void gimple_bind_append_vars (gimple g, tree vars) 14578 Append `VARS' to the set of variables declared in the `GIMPLE_BIND' 14579 statement `G'. 14580 14581 -- GIMPLE function: gimple_seq gimple_bind_body (gimple g) 14582 Return the GIMPLE sequence contained in the `GIMPLE_BIND' statement 14583 `G'. 14584 14585 -- GIMPLE function: void gimple_bind_set_body (gimple g, gimple_seq 14586 seq) 14587 Set `SEQ' to be sequence contained in the `GIMPLE_BIND' statement 14588 `G'. 14589 14590 -- GIMPLE function: void gimple_bind_add_stmt (gimple gs, gimple stmt) 14591 Append a statement to the end of a `GIMPLE_BIND''s body. 14592 14593 -- GIMPLE function: void gimple_bind_add_seq (gimple gs, gimple_seq 14594 seq) 14595 Append a sequence of statements to the end of a `GIMPLE_BIND''s 14596 body. 14597 14598 -- GIMPLE function: tree gimple_bind_block (gimple g) 14599 Return the `TREE_BLOCK' node associated with `GIMPLE_BIND' 14600 statement `G'. This is analogous to the `BIND_EXPR_BLOCK' field in 14601 trees. 14602 14603 -- GIMPLE function: void gimple_bind_set_block (gimple g, tree block) 14604 Set `BLOCK' to be the `TREE_BLOCK' node associated with 14605 `GIMPLE_BIND' statement `G'. 14606 14607 14608 File: gccint.info, Node: `GIMPLE_CALL', Next: `GIMPLE_CATCH', Prev: `GIMPLE_BIND', Up: Tuple specific accessors 14609 14610 12.7.4 `GIMPLE_CALL' 14611 -------------------- 14612 14613 -- GIMPLE function: gimple gimple_build_call (tree fn, unsigned nargs, 14614 ...) 14615 Build a `GIMPLE_CALL' statement to function `FN'. The argument 14616 `FN' must be either a `FUNCTION_DECL' or a gimple call address as 14617 determined by `is_gimple_call_addr'. `NARGS' are the number of 14618 arguments. The rest of the arguments follow the argument `NARGS', 14619 and must be trees that are valid as rvalues in gimple (i.e., each 14620 operand is validated with `is_gimple_operand'). 14621 14622 -- GIMPLE function: gimple gimple_build_call_from_tree (tree call_expr) 14623 Build a `GIMPLE_CALL' from a `CALL_EXPR' node. The arguments and 14624 the function are taken from the expression directly. This routine 14625 assumes that `call_expr' is already in GIMPLE form. That is, its 14626 operands are GIMPLE values and the function call needs no further 14627 simplification. All the call flags in `call_expr' are copied over 14628 to the new `GIMPLE_CALL'. 14629 14630 -- GIMPLE function: gimple gimple_build_call_vec (tree fn, `VEC'(tree, 14631 heap) *args) 14632 Identical to `gimple_build_call' but the arguments are stored in a 14633 `VEC'(). 14634 14635 -- GIMPLE function: tree gimple_call_lhs (gimple g) 14636 Return the `LHS' of call statement `G'. 14637 14638 -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g) 14639 Return a pointer to the `LHS' of call statement `G'. 14640 14641 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 14642 Set `LHS' to be the `LHS' operand of call statement `G'. 14643 14644 -- GIMPLE function: tree gimple_call_fn (gimple g) 14645 Return the tree node representing the function called by call 14646 statement `G'. 14647 14648 -- GIMPLE function: void gimple_call_set_fn (gimple g, tree fn) 14649 Set `FN' to be the function called by call statement `G'. This has 14650 to be a gimple value specifying the address of the called function. 14651 14652 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 14653 If a given `GIMPLE_CALL''s callee is a `FUNCTION_DECL', return it. 14654 Otherwise return `NULL'. This function is analogous to 14655 `get_callee_fndecl' in `GENERIC'. 14656 14657 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 14658 Set the called function to `FNDECL'. 14659 14660 -- GIMPLE function: tree gimple_call_return_type (gimple g) 14661 Return the type returned by call statement `G'. 14662 14663 -- GIMPLE function: tree gimple_call_chain (gimple g) 14664 Return the static chain for call statement `G'. 14665 14666 -- GIMPLE function: void gimple_call_set_chain (gimple g, tree chain) 14667 Set `CHAIN' to be the static chain for call statement `G'. 14668 14669 -- GIMPLE function: unsigned gimple_call_num_args (gimple g) 14670 Return the number of arguments used by call statement `G'. 14671 14672 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 14673 Return the argument at position `INDEX' for call statement `G'. 14674 The first argument is 0. 14675 14676 -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned 14677 index) 14678 Return a pointer to the argument at position `INDEX' for call 14679 statement `G'. 14680 14681 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned 14682 index, tree arg) 14683 Set `ARG' to be the argument at position `INDEX' for call statement 14684 `G'. 14685 14686 -- GIMPLE function: void gimple_call_set_tail (gimple s) 14687 Mark call statement `S' as being a tail call (i.e., a call just 14688 before the exit of a function). These calls are candidate for tail 14689 call optimization. 14690 14691 -- GIMPLE function: bool gimple_call_tail_p (gimple s) 14692 Return true if `GIMPLE_CALL' `S' is marked as a tail call. 14693 14694 -- GIMPLE function: void gimple_call_mark_uninlinable (gimple s) 14695 Mark `GIMPLE_CALL' `S' as being uninlinable. 14696 14697 -- GIMPLE function: bool gimple_call_cannot_inline_p (gimple s) 14698 Return true if `GIMPLE_CALL' `S' cannot be inlined. 14699 14700 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 14701 Return true if `S' is a noreturn call. 14702 14703 -- GIMPLE function: gimple gimple_call_copy_skip_args (gimple stmt, 14704 bitmap args_to_skip) 14705 Build a `GIMPLE_CALL' identical to `STMT' but skipping the 14706 arguments in the positions marked by the set `ARGS_TO_SKIP'. 14707 14708 14709 File: gccint.info, Node: `GIMPLE_CATCH', Next: `GIMPLE_COND', Prev: `GIMPLE_CALL', Up: Tuple specific accessors 14710 14711 12.7.5 `GIMPLE_CATCH' 14712 --------------------- 14713 14714 -- GIMPLE function: gimple gimple_build_catch (tree types, gimple_seq 14715 handler) 14716 Build a `GIMPLE_CATCH' statement. `TYPES' are the tree types this 14717 catch handles. `HANDLER' is a sequence of statements with the code 14718 for the handler. 14719 14720 -- GIMPLE function: tree gimple_catch_types (gimple g) 14721 Return the types handled by `GIMPLE_CATCH' statement `G'. 14722 14723 -- GIMPLE function: tree * gimple_catch_types_ptr (gimple g) 14724 Return a pointer to the types handled by `GIMPLE_CATCH' statement 14725 `G'. 14726 14727 -- GIMPLE function: gimple_seq gimple_catch_handler (gimple g) 14728 Return the GIMPLE sequence representing the body of the handler of 14729 `GIMPLE_CATCH' statement `G'. 14730 14731 -- GIMPLE function: void gimple_catch_set_types (gimple g, tree t) 14732 Set `T' to be the set of types handled by `GIMPLE_CATCH' `G'. 14733 14734 -- GIMPLE function: void gimple_catch_set_handler (gimple g, 14735 gimple_seq handler) 14736 Set `HANDLER' to be the body of `GIMPLE_CATCH' `G'. 14737 14738 14739 File: gccint.info, Node: `GIMPLE_COND', Next: `GIMPLE_DEBUG', Prev: `GIMPLE_CATCH', Up: Tuple specific accessors 14740 14741 12.7.6 `GIMPLE_COND' 14742 -------------------- 14743 14744 -- GIMPLE function: gimple gimple_build_cond (enum tree_code 14745 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 14746 Build a `GIMPLE_COND' statement. `A' `GIMPLE_COND' statement 14747 compares `LHS' and `RHS' and if the condition in `PRED_CODE' is 14748 true, jump to the label in `t_label', otherwise jump to the label 14749 in `f_label'. `PRED_CODE' are relational operator tree codes like 14750 `EQ_EXPR', `LT_EXPR', `LE_EXPR', `NE_EXPR', etc. 14751 14752 -- GIMPLE function: gimple gimple_build_cond_from_tree (tree cond, 14753 tree t_label, tree f_label) 14754 Build a `GIMPLE_COND' statement from the conditional expression 14755 tree `COND'. `T_LABEL' and `F_LABEL' are as in 14756 `gimple_build_cond'. 14757 14758 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 14759 Return the code of the predicate computed by conditional statement 14760 `G'. 14761 14762 -- GIMPLE function: void gimple_cond_set_code (gimple g, enum 14763 tree_code code) 14764 Set `CODE' to be the predicate code for the conditional statement 14765 `G'. 14766 14767 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 14768 Return the `LHS' of the predicate computed by conditional statement 14769 `G'. 14770 14771 -- GIMPLE function: void gimple_cond_set_lhs (gimple g, tree lhs) 14772 Set `LHS' to be the `LHS' operand of the predicate computed by 14773 conditional statement `G'. 14774 14775 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 14776 Return the `RHS' operand of the predicate computed by conditional 14777 `G'. 14778 14779 -- GIMPLE function: void gimple_cond_set_rhs (gimple g, tree rhs) 14780 Set `RHS' to be the `RHS' operand of the predicate computed by 14781 conditional statement `G'. 14782 14783 -- GIMPLE function: tree gimple_cond_true_label (gimple g) 14784 Return the label used by conditional statement `G' when its 14785 predicate evaluates to true. 14786 14787 -- GIMPLE function: void gimple_cond_set_true_label (gimple g, tree 14788 label) 14789 Set `LABEL' to be the label used by conditional statement `G' when 14790 its predicate evaluates to true. 14791 14792 -- GIMPLE function: void gimple_cond_set_false_label (gimple g, tree 14793 label) 14794 Set `LABEL' to be the label used by conditional statement `G' when 14795 its predicate evaluates to false. 14796 14797 -- GIMPLE function: tree gimple_cond_false_label (gimple g) 14798 Return the label used by conditional statement `G' when its 14799 predicate evaluates to false. 14800 14801 -- GIMPLE function: void gimple_cond_make_false (gimple g) 14802 Set the conditional `COND_STMT' to be of the form 'if (1 == 0)'. 14803 14804 -- GIMPLE function: void gimple_cond_make_true (gimple g) 14805 Set the conditional `COND_STMT' to be of the form 'if (1 == 1)'. 14806 14807 14808 File: gccint.info, Node: `GIMPLE_DEBUG', Next: `GIMPLE_EH_FILTER', Prev: `GIMPLE_COND', Up: Tuple specific accessors 14809 14810 12.7.7 `GIMPLE_DEBUG' 14811 --------------------- 14812 14813 -- GIMPLE function: gimple gimple_build_debug_bind (tree var, tree 14814 value, gimple stmt) 14815 Build a `GIMPLE_DEBUG' statement with `GIMPLE_DEBUG_BIND' of 14816 `subcode'. The effect of this statement is to tell debug 14817 information generation machinery that the value of user variable 14818 `var' is given by `value' at that point, and to remain with that 14819 value until `var' runs out of scope, a dynamically-subsequent 14820 debug bind statement overrides the binding, or conflicting values 14821 reach a control flow merge point. Even if components of the 14822 `value' expression change afterwards, the variable is supposed to 14823 retain the same value, though not necessarily the same location. 14824 14825 It is expected that `var' be most often a tree for automatic user 14826 variables (`VAR_DECL' or `PARM_DECL') that satisfy the 14827 requirements for gimple registers, but it may also be a tree for a 14828 scalarized component of a user variable (`ARRAY_REF', 14829 `COMPONENT_REF'), or a debug temporary (`DEBUG_EXPR_DECL'). 14830 14831 As for `value', it can be an arbitrary tree expression, but it is 14832 recommended that it be in a suitable form for a gimple assignment 14833 `RHS'. It is not expected that user variables that could appear 14834 as `var' ever appear in `value', because in the latter we'd have 14835 their `SSA_NAME's instead, but even if they were not in SSA form, 14836 user variables appearing in `value' are to be regarded as part of 14837 the executable code space, whereas those in `var' are to be 14838 regarded as part of the source code space. There is no way to 14839 refer to the value bound to a user variable within a `value' 14840 expression. 14841 14842 If `value' is `GIMPLE_DEBUG_BIND_NOVALUE', debug information 14843 generation machinery is informed that the variable `var' is 14844 unbound, i.e., that its value is indeterminate, which sometimes 14845 means it is really unavailable, and other times that the compiler 14846 could not keep track of it. 14847 14848 Block and location information for the newly-created stmt are 14849 taken from `stmt', if given. 14850 14851 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 14852 Return the user variable VAR that is bound at `stmt'. 14853 14854 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 14855 Return the value expression that is bound to a user variable at 14856 `stmt'. 14857 14858 -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple 14859 stmt) 14860 Return a pointer to the value expression that is bound to a user 14861 variable at `stmt'. 14862 14863 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 14864 var) 14865 Modify the user variable bound at `stmt' to VAR. 14866 14867 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, 14868 tree var) 14869 Modify the value bound to the user variable bound at `stmt' to 14870 VALUE. 14871 14872 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 14873 Modify the value bound to the user variable bound at `stmt' so 14874 that the variable becomes unbound. 14875 14876 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 14877 Return `TRUE' if `stmt' binds a user variable to a value, and 14878 `FALSE' if it unbinds the variable. 14879 14880 14881 File: gccint.info, Node: `GIMPLE_EH_FILTER', Next: `GIMPLE_LABEL', Prev: `GIMPLE_DEBUG', Up: Tuple specific accessors 14882 14883 12.7.8 `GIMPLE_EH_FILTER' 14884 ------------------------- 14885 14886 -- GIMPLE function: gimple gimple_build_eh_filter (tree types, 14887 gimple_seq failure) 14888 Build a `GIMPLE_EH_FILTER' statement. `TYPES' are the filter's 14889 types. `FAILURE' is a sequence with the filter's failure action. 14890 14891 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 14892 Return the types handled by `GIMPLE_EH_FILTER' statement `G'. 14893 14894 -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g) 14895 Return a pointer to the types handled by `GIMPLE_EH_FILTER' 14896 statement `G'. 14897 14898 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 14899 Return the sequence of statement to execute when `GIMPLE_EH_FILTER' 14900 statement fails. 14901 14902 -- GIMPLE function: void gimple_eh_filter_set_types (gimple g, tree 14903 types) 14904 Set `TYPES' to be the set of types handled by `GIMPLE_EH_FILTER' 14905 `G'. 14906 14907 -- GIMPLE function: void gimple_eh_filter_set_failure (gimple g, 14908 gimple_seq failure) 14909 Set `FAILURE' to be the sequence of statements to execute on 14910 failure for `GIMPLE_EH_FILTER' `G'. 14911 14912 -- GIMPLE function: bool gimple_eh_filter_must_not_throw (gimple g) 14913 Return the `EH_FILTER_MUST_NOT_THROW' flag. 14914 14915 -- GIMPLE function: void gimple_eh_filter_set_must_not_throw (gimple 14916 g, bool mntp) 14917 Set the `EH_FILTER_MUST_NOT_THROW' flag. 14918 14919 14920 File: gccint.info, Node: `GIMPLE_LABEL', Next: `GIMPLE_NOP', Prev: `GIMPLE_EH_FILTER', Up: Tuple specific accessors 14921 14922 12.7.9 `GIMPLE_LABEL' 14923 --------------------- 14924 14925 -- GIMPLE function: gimple gimple_build_label (tree label) 14926 Build a `GIMPLE_LABEL' statement with corresponding to the tree 14927 label, `LABEL'. 14928 14929 -- GIMPLE function: tree gimple_label_label (gimple g) 14930 Return the `LABEL_DECL' node used by `GIMPLE_LABEL' statement `G'. 14931 14932 -- GIMPLE function: void gimple_label_set_label (gimple g, tree label) 14933 Set `LABEL' to be the `LABEL_DECL' node used by `GIMPLE_LABEL' 14934 statement `G'. 14935 14936 -- GIMPLE function: gimple gimple_build_goto (tree dest) 14937 Build a `GIMPLE_GOTO' statement to label `DEST'. 14938 14939 -- GIMPLE function: tree gimple_goto_dest (gimple g) 14940 Return the destination of the unconditional jump `G'. 14941 14942 -- GIMPLE function: void gimple_goto_set_dest (gimple g, tree dest) 14943 Set `DEST' to be the destination of the unconditional jump `G'. 14944 14945 14946 File: gccint.info, Node: `GIMPLE_NOP', Next: `GIMPLE_OMP_ATOMIC_LOAD', Prev: `GIMPLE_LABEL', Up: Tuple specific accessors 14947 14948 12.7.10 `GIMPLE_NOP' 14949 -------------------- 14950 14951 -- GIMPLE function: gimple gimple_build_nop (void) 14952 Build a `GIMPLE_NOP' statement. 14953 14954 -- GIMPLE function: bool gimple_nop_p (gimple g) 14955 Returns `TRUE' if statement `G' is a `GIMPLE_NOP'. 14956 14957 14958 File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_LOAD', Next: `GIMPLE_OMP_ATOMIC_STORE', Prev: `GIMPLE_NOP', Up: Tuple specific accessors 14959 14960 12.7.11 `GIMPLE_OMP_ATOMIC_LOAD' 14961 -------------------------------- 14962 14963 -- GIMPLE function: gimple gimple_build_omp_atomic_load (tree lhs, 14964 tree rhs) 14965 Build a `GIMPLE_OMP_ATOMIC_LOAD' statement. `LHS' is the left-hand 14966 side of the assignment. `RHS' is the right-hand side of the 14967 assignment. 14968 14969 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs (gimple g, 14970 tree lhs) 14971 Set the `LHS' of an atomic load. 14972 14973 -- GIMPLE function: tree gimple_omp_atomic_load_lhs (gimple g) 14974 Get the `LHS' of an atomic load. 14975 14976 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs (gimple g, 14977 tree rhs) 14978 Set the `RHS' of an atomic set. 14979 14980 -- GIMPLE function: tree gimple_omp_atomic_load_rhs (gimple g) 14981 Get the `RHS' of an atomic set. 14982 14983 14984 File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_STORE', Next: `GIMPLE_OMP_CONTINUE', Prev: `GIMPLE_OMP_ATOMIC_LOAD', Up: Tuple specific accessors 14985 14986 12.7.12 `GIMPLE_OMP_ATOMIC_STORE' 14987 --------------------------------- 14988 14989 -- GIMPLE function: gimple gimple_build_omp_atomic_store (tree val) 14990 Build a `GIMPLE_OMP_ATOMIC_STORE' statement. `VAL' is the value to 14991 be stored. 14992 14993 -- GIMPLE function: void gimple_omp_atomic_store_set_val (gimple g, 14994 tree val) 14995 Set the value being stored in an atomic store. 14996 14997 -- GIMPLE function: tree gimple_omp_atomic_store_val (gimple g) 14998 Return the value being stored in an atomic store. 14999 15000 15001 File: gccint.info, Node: `GIMPLE_OMP_CONTINUE', Next: `GIMPLE_OMP_CRITICAL', Prev: `GIMPLE_OMP_ATOMIC_STORE', Up: Tuple specific accessors 15002 15003 12.7.13 `GIMPLE_OMP_CONTINUE' 15004 ----------------------------- 15005 15006 -- GIMPLE function: gimple gimple_build_omp_continue (tree 15007 control_def, tree control_use) 15008 Build a `GIMPLE_OMP_CONTINUE' statement. `CONTROL_DEF' is the 15009 definition of the control variable. `CONTROL_USE' is the use of 15010 the control variable. 15011 15012 -- GIMPLE function: tree gimple_omp_continue_control_def (gimple s) 15013 Return the definition of the control variable on a 15014 `GIMPLE_OMP_CONTINUE' in `S'. 15015 15016 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr (gimple s) 15017 Same as above, but return the pointer. 15018 15019 -- GIMPLE function: tree gimple_omp_continue_set_control_def (gimple s) 15020 Set the control variable definition for a `GIMPLE_OMP_CONTINUE' 15021 statement in `S'. 15022 15023 -- GIMPLE function: tree gimple_omp_continue_control_use (gimple s) 15024 Return the use of the control variable on a `GIMPLE_OMP_CONTINUE' 15025 in `S'. 15026 15027 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr (gimple s) 15028 Same as above, but return the pointer. 15029 15030 -- GIMPLE function: tree gimple_omp_continue_set_control_use (gimple s) 15031 Set the control variable use for a `GIMPLE_OMP_CONTINUE' statement 15032 in `S'. 15033 15034 15035 File: gccint.info, Node: `GIMPLE_OMP_CRITICAL', Next: `GIMPLE_OMP_FOR', Prev: `GIMPLE_OMP_CONTINUE', Up: Tuple specific accessors 15036 15037 12.7.14 `GIMPLE_OMP_CRITICAL' 15038 ----------------------------- 15039 15040 -- GIMPLE function: gimple gimple_build_omp_critical (gimple_seq body, 15041 tree name) 15042 Build a `GIMPLE_OMP_CRITICAL' statement. `BODY' is the sequence of 15043 statements for which only one thread can execute. `NAME' is an 15044 optional identifier for this critical block. 15045 15046 -- GIMPLE function: tree gimple_omp_critical_name (gimple g) 15047 Return the name associated with `OMP_CRITICAL' statement `G'. 15048 15049 -- GIMPLE function: tree * gimple_omp_critical_name_ptr (gimple g) 15050 Return a pointer to the name associated with `OMP' critical 15051 statement `G'. 15052 15053 -- GIMPLE function: void gimple_omp_critical_set_name (gimple g, tree 15054 name) 15055 Set `NAME' to be the name associated with `OMP' critical statement 15056 `G'. 15057 15058 15059 File: gccint.info, Node: `GIMPLE_OMP_FOR', Next: `GIMPLE_OMP_MASTER', Prev: `GIMPLE_OMP_CRITICAL', Up: Tuple specific accessors 15060 15061 12.7.15 `GIMPLE_OMP_FOR' 15062 ------------------------ 15063 15064 -- GIMPLE function: gimple gimple_build_omp_for (gimple_seq body, tree 15065 clauses, tree index, tree initial, tree final, tree incr, 15066 gimple_seq pre_body, enum tree_code omp_for_cond) 15067 Build a `GIMPLE_OMP_FOR' statement. `BODY' is sequence of 15068 statements inside the for loop. `CLAUSES', are any of the `OMP' 15069 loop construct's clauses: private, firstprivate, lastprivate, 15070 reductions, ordered, schedule, and nowait. `PRE_BODY' is the 15071 sequence of statements that are loop invariant. `INDEX' is the 15072 index variable. `INITIAL' is the initial value of `INDEX'. 15073 `FINAL' is final value of `INDEX'. OMP_FOR_COND is the predicate 15074 used to compare `INDEX' and `FINAL'. `INCR' is the increment 15075 expression. 15076 15077 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 15078 Return the clauses associated with `OMP_FOR' `G'. 15079 15080 -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g) 15081 Return a pointer to the `OMP_FOR' `G'. 15082 15083 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 15084 clauses) 15085 Set `CLAUSES' to be the list of clauses associated with `OMP_FOR' 15086 `G'. 15087 15088 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 15089 Return the index variable for `OMP_FOR' `G'. 15090 15091 -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g) 15092 Return a pointer to the index variable for `OMP_FOR' `G'. 15093 15094 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 15095 index) 15096 Set `INDEX' to be the index variable for `OMP_FOR' `G'. 15097 15098 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 15099 Return the initial value for `OMP_FOR' `G'. 15100 15101 -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g) 15102 Return a pointer to the initial value for `OMP_FOR' `G'. 15103 15104 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 15105 initial) 15106 Set `INITIAL' to be the initial value for `OMP_FOR' `G'. 15107 15108 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 15109 Return the final value for `OMP_FOR' `G'. 15110 15111 -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g) 15112 turn a pointer to the final value for `OMP_FOR' `G'. 15113 15114 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 15115 final) 15116 Set `FINAL' to be the final value for `OMP_FOR' `G'. 15117 15118 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 15119 Return the increment value for `OMP_FOR' `G'. 15120 15121 -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g) 15122 Return a pointer to the increment value for `OMP_FOR' `G'. 15123 15124 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 15125 Set `INCR' to be the increment value for `OMP_FOR' `G'. 15126 15127 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 15128 Return the sequence of statements to execute before the `OMP_FOR' 15129 statement `G' starts. 15130 15131 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 15132 gimple_seq pre_body) 15133 Set `PRE_BODY' to be the sequence of statements to execute before 15134 the `OMP_FOR' statement `G' starts. 15135 15136 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 15137 tree_code cond) 15138 Set `COND' to be the condition code for `OMP_FOR' `G'. 15139 15140 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 15141 Return the condition code associated with `OMP_FOR' `G'. 15142 15143 15144 File: gccint.info, Node: `GIMPLE_OMP_MASTER', Next: `GIMPLE_OMP_ORDERED', Prev: `GIMPLE_OMP_FOR', Up: Tuple specific accessors 15145 15146 12.7.16 `GIMPLE_OMP_MASTER' 15147 --------------------------- 15148 15149 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 15150 Build a `GIMPLE_OMP_MASTER' statement. `BODY' is the sequence of 15151 statements to be executed by just the master. 15152 15153 15154 File: gccint.info, Node: `GIMPLE_OMP_ORDERED', Next: `GIMPLE_OMP_PARALLEL', Prev: `GIMPLE_OMP_MASTER', Up: Tuple specific accessors 15155 15156 12.7.17 `GIMPLE_OMP_ORDERED' 15157 ---------------------------- 15158 15159 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 15160 Build a `GIMPLE_OMP_ORDERED' statement. 15161 15162 `BODY' is the sequence of statements inside a loop that will executed 15163 in sequence. 15164 15165 15166 File: gccint.info, Node: `GIMPLE_OMP_PARALLEL', Next: `GIMPLE_OMP_RETURN', Prev: `GIMPLE_OMP_ORDERED', Up: Tuple specific accessors 15167 15168 12.7.18 `GIMPLE_OMP_PARALLEL' 15169 ----------------------------- 15170 15171 -- GIMPLE function: gimple gimple_build_omp_parallel (gimple_seq body, 15172 tree clauses, tree child_fn, tree data_arg) 15173 Build a `GIMPLE_OMP_PARALLEL' statement. 15174 15175 `BODY' is sequence of statements which are executed in parallel. 15176 `CLAUSES', are the `OMP' parallel construct's clauses. `CHILD_FN' is 15177 the function created for the parallel threads to execute. `DATA_ARG' 15178 are the shared data argument(s). 15179 15180 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 15181 Return true if `OMP' parallel statement `G' has the 15182 `GF_OMP_PARALLEL_COMBINED' flag set. 15183 15184 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 15185 Set the `GF_OMP_PARALLEL_COMBINED' field in `OMP' parallel 15186 statement `G'. 15187 15188 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 15189 Return the body for the `OMP' statement `G'. 15190 15191 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 15192 body) 15193 Set `BODY' to be the body for the `OMP' statement `G'. 15194 15195 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 15196 Return the clauses associated with `OMP_PARALLEL' `G'. 15197 15198 -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr (gimple g) 15199 Return a pointer to the clauses associated with `OMP_PARALLEL' `G'. 15200 15201 -- GIMPLE function: void gimple_omp_parallel_set_clauses (gimple g, 15202 tree clauses) 15203 Set `CLAUSES' to be the list of clauses associated with 15204 `OMP_PARALLEL' `G'. 15205 15206 -- GIMPLE function: tree gimple_omp_parallel_child_fn (gimple g) 15207 Return the child function used to hold the body of `OMP_PARALLEL' 15208 `G'. 15209 15210 -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr (gimple g) 15211 Return a pointer to the child function used to hold the body of 15212 `OMP_PARALLEL' `G'. 15213 15214 -- GIMPLE function: void gimple_omp_parallel_set_child_fn (gimple g, 15215 tree child_fn) 15216 Set `CHILD_FN' to be the child function for `OMP_PARALLEL' `G'. 15217 15218 -- GIMPLE function: tree gimple_omp_parallel_data_arg (gimple g) 15219 Return the artificial argument used to send variables and values 15220 from the parent to the children threads in `OMP_PARALLEL' `G'. 15221 15222 -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr (gimple g) 15223 Return a pointer to the data argument for `OMP_PARALLEL' `G'. 15224 15225 -- GIMPLE function: void gimple_omp_parallel_set_data_arg (gimple g, 15226 tree data_arg) 15227 Set `DATA_ARG' to be the data argument for `OMP_PARALLEL' `G'. 15228 15229 -- GIMPLE function: bool is_gimple_omp (gimple stmt) 15230 Returns true when the gimple statement `STMT' is any of the OpenMP 15231 types. 15232 15233 15234 File: gccint.info, Node: `GIMPLE_OMP_RETURN', Next: `GIMPLE_OMP_SECTION', Prev: `GIMPLE_OMP_PARALLEL', Up: Tuple specific accessors 15235 15236 12.7.19 `GIMPLE_OMP_RETURN' 15237 --------------------------- 15238 15239 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 15240 Build a `GIMPLE_OMP_RETURN' statement. `WAIT_P' is true if this is 15241 a non-waiting return. 15242 15243 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 15244 Set the nowait flag on `GIMPLE_OMP_RETURN' statement `S'. 15245 15246 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 15247 Return true if `OMP' return statement `G' has the 15248 `GF_OMP_RETURN_NOWAIT' flag set. 15249 15250 15251 File: gccint.info, Node: `GIMPLE_OMP_SECTION', Next: `GIMPLE_OMP_SECTIONS', Prev: `GIMPLE_OMP_RETURN', Up: Tuple specific accessors 15252 15253 12.7.20 `GIMPLE_OMP_SECTION' 15254 ---------------------------- 15255 15256 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 15257 Build a `GIMPLE_OMP_SECTION' statement for a sections statement. 15258 15259 `BODY' is the sequence of statements in the section. 15260 15261 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 15262 Return true if `OMP' section statement `G' has the 15263 `GF_OMP_SECTION_LAST' flag set. 15264 15265 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 15266 Set the `GF_OMP_SECTION_LAST' flag on `G'. 15267 15268 15269 File: gccint.info, Node: `GIMPLE_OMP_SECTIONS', Next: `GIMPLE_OMP_SINGLE', Prev: `GIMPLE_OMP_SECTION', Up: Tuple specific accessors 15270 15271 12.7.21 `GIMPLE_OMP_SECTIONS' 15272 ----------------------------- 15273 15274 -- GIMPLE function: gimple gimple_build_omp_sections (gimple_seq body, 15275 tree clauses) 15276 Build a `GIMPLE_OMP_SECTIONS' statement. `BODY' is a sequence of 15277 section statements. `CLAUSES' are any of the `OMP' sections 15278 construct's clauses: private, firstprivate, lastprivate, 15279 reduction, and nowait. 15280 15281 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 15282 Build a `GIMPLE_OMP_SECTIONS_SWITCH' statement. 15283 15284 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 15285 Return the control variable associated with the 15286 `GIMPLE_OMP_SECTIONS' in `G'. 15287 15288 -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g) 15289 Return a pointer to the clauses associated with the 15290 `GIMPLE_OMP_SECTIONS' in `G'. 15291 15292 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 15293 tree control) 15294 Set `CONTROL' to be the set of clauses associated with the 15295 `GIMPLE_OMP_SECTIONS' in `G'. 15296 15297 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 15298 Return the clauses associated with `OMP_SECTIONS' `G'. 15299 15300 -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g) 15301 Return a pointer to the clauses associated with `OMP_SECTIONS' `G'. 15302 15303 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 15304 tree clauses) 15305 Set `CLAUSES' to be the set of clauses associated with 15306 `OMP_SECTIONS' `G'. 15307 15308 15309 File: gccint.info, Node: `GIMPLE_OMP_SINGLE', Next: `GIMPLE_PHI', Prev: `GIMPLE_OMP_SECTIONS', Up: Tuple specific accessors 15310 15311 12.7.22 `GIMPLE_OMP_SINGLE' 15312 --------------------------- 15313 15314 -- GIMPLE function: gimple gimple_build_omp_single (gimple_seq body, 15315 tree clauses) 15316 Build a `GIMPLE_OMP_SINGLE' statement. `BODY' is the sequence of 15317 statements that will be executed once. `CLAUSES' are any of the 15318 `OMP' single construct's clauses: private, firstprivate, 15319 copyprivate, nowait. 15320 15321 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 15322 Return the clauses associated with `OMP_SINGLE' `G'. 15323 15324 -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g) 15325 Return a pointer to the clauses associated with `OMP_SINGLE' `G'. 15326 15327 -- GIMPLE function: void gimple_omp_single_set_clauses (gimple g, tree 15328 clauses) 15329 Set `CLAUSES' to be the clauses associated with `OMP_SINGLE' `G'. 15330 15331 15332 File: gccint.info, Node: `GIMPLE_PHI', Next: `GIMPLE_RESX', Prev: `GIMPLE_OMP_SINGLE', Up: Tuple specific accessors 15333 15334 12.7.23 `GIMPLE_PHI' 15335 -------------------- 15336 15337 -- GIMPLE function: gimple make_phi_node (tree var, int len) 15338 Build a `PHI' node with len argument slots for variable var. 15339 15340 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 15341 Return the maximum number of arguments supported by `GIMPLE_PHI' 15342 `G'. 15343 15344 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 15345 Return the number of arguments in `GIMPLE_PHI' `G'. This must 15346 always be exactly the number of incoming edges for the basic block 15347 holding `G'. 15348 15349 -- GIMPLE function: tree gimple_phi_result (gimple g) 15350 Return the `SSA' name created by `GIMPLE_PHI' `G'. 15351 15352 -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g) 15353 Return a pointer to the `SSA' name created by `GIMPLE_PHI' `G'. 15354 15355 -- GIMPLE function: void gimple_phi_set_result (gimple g, tree result) 15356 Set `RESULT' to be the `SSA' name created by `GIMPLE_PHI' `G'. 15357 15358 -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index) 15359 Return the `PHI' argument corresponding to incoming edge `INDEX' 15360 for `GIMPLE_PHI' `G'. 15361 15362 -- GIMPLE function: void gimple_phi_set_arg (gimple g, index, struct 15363 phi_arg_d * phiarg) 15364 Set `PHIARG' to be the argument corresponding to incoming edge 15365 `INDEX' for `GIMPLE_PHI' `G'. 15366 15367 15368 File: gccint.info, Node: `GIMPLE_RESX', Next: `GIMPLE_RETURN', Prev: `GIMPLE_PHI', Up: Tuple specific accessors 15369 15370 12.7.24 `GIMPLE_RESX' 15371 --------------------- 15372 15373 -- GIMPLE function: gimple gimple_build_resx (int region) 15374 Build a `GIMPLE_RESX' statement which is a statement. This 15375 statement is a placeholder for _Unwind_Resume before we know if a 15376 function call or a branch is needed. `REGION' is the exception 15377 region from which control is flowing. 15378 15379 -- GIMPLE function: int gimple_resx_region (gimple g) 15380 Return the region number for `GIMPLE_RESX' `G'. 15381 15382 -- GIMPLE function: void gimple_resx_set_region (gimple g, int region) 15383 Set `REGION' to be the region number for `GIMPLE_RESX' `G'. 15384 15385 15386 File: gccint.info, Node: `GIMPLE_RETURN', Next: `GIMPLE_SWITCH', Prev: `GIMPLE_RESX', Up: Tuple specific accessors 15387 15388 12.7.25 `GIMPLE_RETURN' 15389 ----------------------- 15390 15391 -- GIMPLE function: gimple gimple_build_return (tree retval) 15392 Build a `GIMPLE_RETURN' statement whose return value is retval. 15393 15394 -- GIMPLE function: tree gimple_return_retval (gimple g) 15395 Return the return value for `GIMPLE_RETURN' `G'. 15396 15397 -- GIMPLE function: void gimple_return_set_retval (gimple g, tree 15398 retval) 15399 Set `RETVAL' to be the return value for `GIMPLE_RETURN' `G'. 15400 15401 15402 File: gccint.info, Node: `GIMPLE_SWITCH', Next: `GIMPLE_TRY', Prev: `GIMPLE_RETURN', Up: Tuple specific accessors 15403 15404 12.7.26 `GIMPLE_SWITCH' 15405 ----------------------- 15406 15407 -- GIMPLE function: gimple gimple_build_switch (unsigned nlabels, tree 15408 index, tree default_label, ...) 15409 Build a `GIMPLE_SWITCH' statement. `NLABELS' are the number of 15410 labels excluding the default label. The default label is passed 15411 in `DEFAULT_LABEL'. The rest of the arguments are trees 15412 representing the labels. Each label is a tree of code 15413 `CASE_LABEL_EXPR'. 15414 15415 -- GIMPLE function: gimple gimple_build_switch_vec (tree index, tree 15416 default_label, `VEC'(tree,heap) *args) 15417 This function is an alternate way of building `GIMPLE_SWITCH' 15418 statements. `INDEX' and `DEFAULT_LABEL' are as in 15419 gimple_build_switch. `ARGS' is a vector of `CASE_LABEL_EXPR' trees 15420 that contain the labels. 15421 15422 -- GIMPLE function: unsigned gimple_switch_num_labels (gimple g) 15423 Return the number of labels associated with the switch statement 15424 `G'. 15425 15426 -- GIMPLE function: void gimple_switch_set_num_labels (gimple g, 15427 unsigned nlabels) 15428 Set `NLABELS' to be the number of labels for the switch statement 15429 `G'. 15430 15431 -- GIMPLE function: tree gimple_switch_index (gimple g) 15432 Return the index variable used by the switch statement `G'. 15433 15434 -- GIMPLE function: void gimple_switch_set_index (gimple g, tree index) 15435 Set `INDEX' to be the index variable for switch statement `G'. 15436 15437 -- GIMPLE function: tree gimple_switch_label (gimple g, unsigned index) 15438 Return the label numbered `INDEX'. The default label is 0, followed 15439 by any labels in a switch statement. 15440 15441 -- GIMPLE function: void gimple_switch_set_label (gimple g, unsigned 15442 index, tree label) 15443 Set the label number `INDEX' to `LABEL'. 0 is always the default 15444 label. 15445 15446 -- GIMPLE function: tree gimple_switch_default_label (gimple g) 15447 Return the default label for a switch statement. 15448 15449 -- GIMPLE function: void gimple_switch_set_default_label (gimple g, 15450 tree label) 15451 Set the default label for a switch statement. 15452 15453 15454 File: gccint.info, Node: `GIMPLE_TRY', Next: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_SWITCH', Up: Tuple specific accessors 15455 15456 12.7.27 `GIMPLE_TRY' 15457 -------------------- 15458 15459 -- GIMPLE function: gimple gimple_build_try (gimple_seq eval, 15460 gimple_seq cleanup, unsigned int kind) 15461 Build a `GIMPLE_TRY' statement. `EVAL' is a sequence with the 15462 expression to evaluate. `CLEANUP' is a sequence of statements to 15463 run at clean-up time. `KIND' is the enumeration value 15464 `GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 15465 or `GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 15466 construct. 15467 15468 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 15469 Return the kind of try block represented by `GIMPLE_TRY' `G'. This 15470 is either `GIMPLE_TRY_CATCH' or `GIMPLE_TRY_FINALLY'. 15471 15472 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 15473 Return the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 15474 15475 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 15476 Return the sequence of statements used as the body for `GIMPLE_TRY' 15477 `G'. 15478 15479 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 15480 Return the sequence of statements used as the cleanup body for 15481 `GIMPLE_TRY' `G'. 15482 15483 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 15484 bool catch_is_cleanup) 15485 Set the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 15486 15487 -- GIMPLE function: void gimple_try_set_eval (gimple g, gimple_seq 15488 eval) 15489 Set `EVAL' to be the sequence of statements to use as the body for 15490 `GIMPLE_TRY' `G'. 15491 15492 -- GIMPLE function: void gimple_try_set_cleanup (gimple g, gimple_seq 15493 cleanup) 15494 Set `CLEANUP' to be the sequence of statements to use as the 15495 cleanup body for `GIMPLE_TRY' `G'. 15496 15497 15498 File: gccint.info, Node: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_TRY', Up: Tuple specific accessors 15499 15500 12.7.28 `GIMPLE_WITH_CLEANUP_EXPR' 15501 ---------------------------------- 15502 15503 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 15504 Build a `GIMPLE_WITH_CLEANUP_EXPR' statement. `CLEANUP' is the 15505 clean-up expression. 15506 15507 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 15508 Return the cleanup sequence for cleanup statement `G'. 15509 15510 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 15511 cleanup) 15512 Set `CLEANUP' to be the cleanup sequence for `G'. 15513 15514 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 15515 Return the `CLEANUP_EH_ONLY' flag for a `WCE' tuple. 15516 15517 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, 15518 bool eh_only_p) 15519 Set the `CLEANUP_EH_ONLY' flag for a `WCE' tuple. 15520 15521 15522 File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 15523 15524 12.8 GIMPLE sequences 15525 ===================== 15526 15527 GIMPLE sequences are the tuple equivalent of `STATEMENT_LIST''s used in 15528 `GENERIC'. They are used to chain statements together, and when used 15529 in conjunction with sequence iterators, provide a framework for 15530 iterating through statements. 15531 15532 GIMPLE sequences are of type struct `gimple_sequence', but are more 15533 commonly passed by reference to functions dealing with sequences. The 15534 type for a sequence pointer is `gimple_seq' which is the same as struct 15535 `gimple_sequence' *. When declaring a local sequence, you can define a 15536 local variable of type struct `gimple_sequence'. When declaring a 15537 sequence allocated on the garbage collected heap, use the function 15538 `gimple_seq_alloc' documented below. 15539 15540 There are convenience functions for iterating through sequences in the 15541 section entitled Sequence Iterators. 15542 15543 Below is a list of functions to manipulate and query sequences. 15544 15545 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 15546 g) 15547 Link a gimple statement to the end of the sequence *`SEQ' if `G' is 15548 not `NULL'. If *`SEQ' is `NULL', allocate a sequence before 15549 linking. 15550 15551 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 15552 gimple_seq src) 15553 Append sequence `SRC' to the end of sequence *`DEST' if `SRC' is 15554 not `NULL'. If *`DEST' is `NULL', allocate a new sequence before 15555 appending. 15556 15557 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 15558 Perform a deep copy of sequence `SRC' and return the result. 15559 15560 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 15561 Reverse the order of the statements in the sequence `SEQ'. Return 15562 `SEQ'. 15563 15564 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 15565 Return the first statement in sequence `S'. 15566 15567 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 15568 Return the last statement in sequence `S'. 15569 15570 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 15571 last) 15572 Set the last statement in sequence `S' to the statement in `LAST'. 15573 15574 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 15575 first) 15576 Set the first statement in sequence `S' to the statement in 15577 `FIRST'. 15578 15579 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 15580 Initialize sequence `S' to an empty sequence. 15581 15582 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 15583 Allocate a new sequence in the garbage collected store and return 15584 it. 15585 15586 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 15587 src) 15588 Copy the sequence `SRC' into the sequence `DEST'. 15589 15590 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 15591 Return true if the sequence `S' is empty. 15592 15593 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 15594 Returns the sequence of statements in `BB'. 15595 15596 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 15597 Sets the sequence of statements in `BB' to `SEQ'. 15598 15599 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 15600 Determine whether `SEQ' contains exactly one statement. 15601 15602 15603 File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 15604 15605 12.9 Sequence iterators 15606 ======================= 15607 15608 Sequence iterators are convenience constructs for iterating through 15609 statements in a sequence. Given a sequence `SEQ', here is a typical 15610 use of gimple sequence iterators: 15611 15612 gimple_stmt_iterator gsi; 15613 15614 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 15615 { 15616 gimple g = gsi_stmt (gsi); 15617 /* Do something with gimple statement `G'. */ 15618 } 15619 15620 Backward iterations are possible: 15621 15622 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 15623 15624 Forward and backward iterations on basic blocks are possible with 15625 `gsi_start_bb' and `gsi_last_bb'. 15626 15627 In the documentation below we sometimes refer to enum 15628 `gsi_iterator_update'. The valid options for this enumeration are: 15629 15630 * `GSI_NEW_STMT' Only valid when a single statement is added. Move 15631 the iterator to it. 15632 15633 * `GSI_SAME_STMT' Leave the iterator at the same statement. 15634 15635 * `GSI_CONTINUE_LINKING' Move iterator to whatever position is 15636 suitable for linking other statements in the same direction. 15637 15638 Below is a list of the functions used to manipulate and use statement 15639 iterators. 15640 15641 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 15642 Return a new iterator pointing to the sequence `SEQ''s first 15643 statement. If `SEQ' is empty, the iterator's basic block is 15644 `NULL'. Use `gsi_start_bb' instead when the iterator needs to 15645 always have the correct basic block set. 15646 15647 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 15648 Return a new iterator pointing to the first statement in basic 15649 block `BB'. 15650 15651 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 15652 Return a new iterator initially pointing to the last statement of 15653 sequence `SEQ'. If `SEQ' is empty, the iterator's basic block is 15654 `NULL'. Use `gsi_last_bb' instead when the iterator needs to 15655 always have the correct basic block set. 15656 15657 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 15658 Return a new iterator pointing to the last statement in basic 15659 block `BB'. 15660 15661 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 15662 Return `TRUE' if at the end of `I'. 15663 15664 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 15665 Return `TRUE' if we're one statement before the end of `I'. 15666 15667 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 15668 Advance the iterator to the next gimple statement. 15669 15670 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 15671 Advance the iterator to the previous gimple statement. 15672 15673 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 15674 Return the current stmt. 15675 15676 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 15677 bb) 15678 Return a block statement iterator that points to the first 15679 non-label statement in block `BB'. 15680 15681 -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i) 15682 Return a pointer to the current stmt. 15683 15684 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 15685 Return the basic block associated with this iterator. 15686 15687 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 15688 Return the sequence associated with this iterator. 15689 15690 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 15691 remove_eh_info) 15692 Remove the current stmt from the sequence. The iterator is 15693 updated to point to the next statement. When `REMOVE_EH_INFO' is 15694 true we remove the statement pointed to by iterator `I' from the 15695 `EH' tables. Otherwise we do not modify the `EH' tables. 15696 Generally, `REMOVE_EH_INFO' should be true when the statement is 15697 going to be removed from the `IL' and not reinserted elsewhere. 15698 15699 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 15700 gimple_seq seq, enum gsi_iterator_update mode) 15701 Links the sequence of statements `SEQ' before the statement pointed 15702 by iterator `I'. `MODE' indicates what to do with the iterator 15703 after insertion (see `enum gsi_iterator_update' above). 15704 15705 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 15706 gimple g, enum gsi_iterator_update mode) 15707 Links statement `G' before the statement pointed-to by iterator 15708 `I'. Updates iterator `I' according to `MODE'. 15709 15710 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 15711 gimple_seq seq, enum gsi_iterator_update mode) 15712 Links sequence `SEQ' after the statement pointed-to by iterator 15713 `I'. `MODE' is as in `gsi_insert_after'. 15714 15715 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 15716 gimple g, enum gsi_iterator_update mode) 15717 Links statement `G' after the statement pointed-to by iterator `I'. 15718 `MODE' is as in `gsi_insert_after'. 15719 15720 -- GIMPLE function: gimple_seq gsi_split_seq_after 15721 (gimple_stmt_iterator i) 15722 Move all statements in the sequence after `I' to a new sequence. 15723 Return this new sequence. 15724 15725 -- GIMPLE function: gimple_seq gsi_split_seq_before 15726 (gimple_stmt_iterator *i) 15727 Move all statements in the sequence before `I' to a new sequence. 15728 Return this new sequence. 15729 15730 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 15731 stmt, bool update_eh_info) 15732 Replace the statement pointed-to by `I' to `STMT'. If 15733 `UPDATE_EH_INFO' is true, the exception handling information of 15734 the original statement is moved to the new statement. 15735 15736 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 15737 gimple stmt, enum gsi_iterator_update mode) 15738 Insert statement `STMT' before the statement pointed-to by iterator 15739 `I', update `STMT''s basic block and scan it for new operands. 15740 `MODE' specifies how to update iterator `I' after insertion (see 15741 enum `gsi_iterator_update'). 15742 15743 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 15744 *i, gimple_seq seq, enum gsi_iterator_update mode) 15745 Like `gsi_insert_before', but for all the statements in `SEQ'. 15746 15747 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 15748 gimple stmt, enum gsi_iterator_update mode) 15749 Insert statement `STMT' after the statement pointed-to by iterator 15750 `I', update `STMT''s basic block and scan it for new operands. 15751 `MODE' specifies how to update iterator `I' after insertion (see 15752 enum `gsi_iterator_update'). 15753 15754 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator 15755 *i, gimple_seq seq, enum gsi_iterator_update mode) 15756 Like `gsi_insert_after', but for all the statements in `SEQ'. 15757 15758 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 15759 Finds iterator for `STMT'. 15760 15761 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 15762 gimple_stmt_iterator *to) 15763 Move the statement at `FROM' so it comes right after the statement 15764 at `TO'. 15765 15766 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 15767 gimple_stmt_iterator *to) 15768 Move the statement at `FROM' so it comes right before the statement 15769 at `TO'. 15770 15771 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 15772 *from, basic_block bb) 15773 Move the statement at `FROM' to the end of basic block `BB'. 15774 15775 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 15776 Add `STMT' to the pending list of edge `E'. No actual insertion is 15777 made until a call to `gsi_commit_edge_inserts'() is made. 15778 15779 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 15780 seq) 15781 Add the sequence of statements in `SEQ' to the pending list of edge 15782 `E'. No actual insertion is made until a call to 15783 `gsi_commit_edge_inserts'() is made. 15784 15785 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 15786 gimple stmt) 15787 Similar to `gsi_insert_on_edge'+`gsi_commit_edge_inserts'. If a 15788 new block has to be created, it is returned. 15789 15790 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 15791 basic_block *new_bb) 15792 Commit insertions pending at edge `E'. If a new block is created, 15793 set `NEW_BB' to this block, otherwise set it to `NULL'. 15794 15795 -- GIMPLE function: void gsi_commit_edge_inserts (void) 15796 This routine will commit all pending edge insertions, creating any 15797 new basic blocks which are necessary. 15798 15799 15800 File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 15801 15802 12.10 Adding a new GIMPLE statement code 15803 ======================================== 15804 15805 The first step in adding a new GIMPLE statement code, is modifying the 15806 file `gimple.def', which contains all the GIMPLE codes. Then you must 15807 add a corresponding structure, and an entry in `union 15808 gimple_statement_d', both of which are located in `gimple.h'. This in 15809 turn, will require you to add a corresponding `GTY' tag in 15810 `gsstruct.def', and code to handle this tag in `gss_for_code' which is 15811 located in `gimple.c'. 15812 15813 In order for the garbage collector to know the size of the structure 15814 you created in `gimple.h', you need to add a case to handle your new 15815 GIMPLE statement in `gimple_size' which is located in `gimple.c'. 15816 15817 You will probably want to create a function to build the new gimple 15818 statement in `gimple.c'. The function should be called 15819 `gimple_build_NEW-TUPLE-NAME', and should return the new tuple of type 15820 gimple. 15821 15822 If your new statement requires accessors for any members or operands 15823 it may have, put simple inline accessors in `gimple.h' and any 15824 non-trivial accessors in `gimple.c' with a corresponding prototype in 15825 `gimple.h'. 15826 15827 15828 File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 15829 15830 12.11 Statement and operand traversals 15831 ====================================== 15832 15833 There are two functions available for walking statements and sequences: 15834 `walk_gimple_stmt' and `walk_gimple_seq', accordingly, and a third 15835 function for walking the operands in a statement: `walk_gimple_op'. 15836 15837 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 15838 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 15839 walk_stmt_info *wi) 15840 This function is used to walk the current statement in `GSI', 15841 optionally using traversal state stored in `WI'. If `WI' is 15842 `NULL', no state is kept during the traversal. 15843 15844 The callback `CALLBACK_STMT' is called. If `CALLBACK_STMT' returns 15845 true, it means that the callback function has handled all the 15846 operands of the statement and it is not necessary to walk its 15847 operands. 15848 15849 If `CALLBACK_STMT' is `NULL' or it returns false, `CALLBACK_OP' is 15850 called on each operand of the statement via `walk_gimple_op'. If 15851 `walk_gimple_op' returns non-`NULL' for any operand, the remaining 15852 operands are not scanned. 15853 15854 The return value is that returned by the last call to 15855 `walk_gimple_op', or `NULL_TREE' if no `CALLBACK_OP' is specified. 15856 15857 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 15858 callback_op, struct walk_stmt_info *wi) 15859 Use this function to walk the operands of statement `STMT'. Every 15860 operand is walked via `walk_tree' with optional state information 15861 in `WI'. 15862 15863 `CALLBACK_OP' is called on each operand of `STMT' via `walk_tree'. 15864 Additional parameters to `walk_tree' must be stored in `WI'. For 15865 each operand `OP', `walk_tree' is called as: 15866 15867 walk_tree (&`OP', `CALLBACK_OP', `WI', `PSET') 15868 15869 If `CALLBACK_OP' returns non-`NULL' for an operand, the remaining 15870 operands are not scanned. The return value is that returned by 15871 the last call to `walk_tree', or `NULL_TREE' if no `CALLBACK_OP' is 15872 specified. 15873 15874 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 15875 callback_stmt, walk_tree_fn callback_op, struct 15876 walk_stmt_info *wi) 15877 This function walks all the statements in the sequence `SEQ' 15878 calling `walk_gimple_stmt' on each one. `WI' is as in 15879 `walk_gimple_stmt'. If `walk_gimple_stmt' returns non-`NULL', the 15880 walk is stopped and the value returned. Otherwise, all the 15881 statements are walked and `NULL_TREE' returned. 15882 15883 15884 File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 15885 15886 13 Analysis and Optimization of GIMPLE tuples 15887 ********************************************* 15888 15889 GCC uses three main intermediate languages to represent the program 15890 during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 15891 language-independent representation generated by each front end. It is 15892 used to serve as an interface between the parser and optimizer. 15893 GENERIC is a common representation that is able to represent programs 15894 written in all the languages supported by GCC. 15895 15896 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 15897 target and language independent optimizations (e.g., inlining, constant 15898 propagation, tail call elimination, redundancy elimination, etc). Much 15899 like GENERIC, GIMPLE is a language independent, tree based 15900 representation. However, it differs from GENERIC in that the GIMPLE 15901 grammar is more restrictive: expressions contain no more than 3 15902 operands (except function calls), it has no control flow structures and 15903 expressions with side-effects are only allowed on the right hand side 15904 of assignments. See the chapter describing GENERIC and GIMPLE for more 15905 details. 15906 15907 This chapter describes the data structures and functions used in the 15908 GIMPLE optimizers (also known as "tree optimizers" or "middle end"). 15909 In particular, it focuses on all the macros, data structures, functions 15910 and programming constructs needed to implement optimization passes for 15911 GIMPLE. 15912 15913 * Menu: 15914 15915 * Annotations:: Attributes for variables. 15916 * SSA Operands:: SSA names referenced by GIMPLE statements. 15917 * SSA:: Static Single Assignment representation. 15918 * Alias analysis:: Representing aliased loads and stores. 15919 * Memory model:: Memory model used by the middle-end. 15920 15921 15922 File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 15923 15924 13.1 Annotations 15925 ================ 15926 15927 The optimizers need to associate attributes with variables during the 15928 optimization process. For instance, we need to know whether a variable 15929 has aliases. All these attributes are stored in data structures called 15930 annotations which are then linked to the field `ann' in `struct 15931 tree_common'. 15932 15933 Presently, we define annotations for variables (`var_ann_t'). 15934 Annotations are defined and documented in `tree-flow.h'. 15935 15936 15937 File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 15938 15939 13.2 SSA Operands 15940 ================= 15941 15942 Almost every GIMPLE statement will contain a reference to a variable or 15943 memory location. Since statements come in different shapes and sizes, 15944 their operands are going to be located at various spots inside the 15945 statement's tree. To facilitate access to the statement's operands, 15946 they are organized into lists associated inside each statement's 15947 annotation. Each element in an operand list is a pointer to a 15948 `VAR_DECL', `PARM_DECL' or `SSA_NAME' tree node. This provides a very 15949 convenient way of examining and replacing operands. 15950 15951 Data flow analysis and optimization is done on all tree nodes 15952 representing variables. Any node for which `SSA_VAR_P' returns nonzero 15953 is considered when scanning statement operands. However, not all 15954 `SSA_VAR_P' variables are processed in the same way. For the purposes 15955 of optimization, we need to distinguish between references to local 15956 scalar variables and references to globals, statics, structures, 15957 arrays, aliased variables, etc. The reason is simple, the compiler can 15958 gather complete data flow information for a local scalar. On the other 15959 hand, a global variable may be modified by a function call, it may not 15960 be possible to keep track of all the elements of an array or the fields 15961 of a structure, etc. 15962 15963 The operand scanner gathers two kinds of operands: "real" and 15964 "virtual". An operand for which `is_gimple_reg' returns true is 15965 considered real, otherwise it is a virtual operand. We also 15966 distinguish between uses and definitions. An operand is used if its 15967 value is loaded by the statement (e.g., the operand at the RHS of an 15968 assignment). If the statement assigns a new value to the operand, the 15969 operand is considered a definition (e.g., the operand at the LHS of an 15970 assignment). 15971 15972 Virtual and real operands also have very different data flow 15973 properties. Real operands are unambiguous references to the full 15974 object that they represent. For instance, given 15975 15976 { 15977 int a, b; 15978 a = b 15979 } 15980 15981 Since `a' and `b' are non-aliased locals, the statement `a = b' will 15982 have one real definition and one real use because variable `a' is 15983 completely modified with the contents of variable `b'. Real definition 15984 are also known as "killing definitions". Similarly, the use of `b' 15985 reads all its bits. 15986 15987 In contrast, virtual operands are used with variables that can have a 15988 partial or ambiguous reference. This includes structures, arrays, 15989 globals, and aliased variables. In these cases, we have two types of 15990 definitions. For globals, structures, and arrays, we can determine from 15991 a statement whether a variable of these types has a killing definition. 15992 If the variable does, then the statement is marked as having a "must 15993 definition" of that variable. However, if a statement is only defining 15994 a part of the variable (i.e. a field in a structure), or if we know 15995 that a statement might define the variable but we cannot say for sure, 15996 then we mark that statement as having a "may definition". For 15997 instance, given 15998 15999 { 16000 int a, b, *p; 16001 16002 if (...) 16003 p = &a; 16004 else 16005 p = &b; 16006 *p = 5; 16007 return *p; 16008 } 16009 16010 The assignment `*p = 5' may be a definition of `a' or `b'. If we 16011 cannot determine statically where `p' is pointing to at the time of the 16012 store operation, we create virtual definitions to mark that statement 16013 as a potential definition site for `a' and `b'. Memory loads are 16014 similarly marked with virtual use operands. Virtual operands are shown 16015 in tree dumps right before the statement that contains them. To 16016 request a tree dump with virtual operands, use the `-vops' option to 16017 `-fdump-tree': 16018 16019 { 16020 int a, b, *p; 16021 16022 if (...) 16023 p = &a; 16024 else 16025 p = &b; 16026 # a = VDEF <a> 16027 # b = VDEF <b> 16028 *p = 5; 16029 16030 # VUSE <a> 16031 # VUSE <b> 16032 return *p; 16033 } 16034 16035 Notice that `VDEF' operands have two copies of the referenced 16036 variable. This indicates that this is not a killing definition of that 16037 variable. In this case we refer to it as a "may definition" or 16038 "aliased store". The presence of the second copy of the variable in 16039 the `VDEF' operand will become important when the function is converted 16040 into SSA form. This will be used to link all the non-killing 16041 definitions to prevent optimizations from making incorrect assumptions 16042 about them. 16043 16044 Operands are updated as soon as the statement is finished via a call 16045 to `update_stmt'. If statement elements are changed via `SET_USE' or 16046 `SET_DEF', then no further action is required (i.e., those macros take 16047 care of updating the statement). If changes are made by manipulating 16048 the statement's tree directly, then a call must be made to 16049 `update_stmt' when complete. Calling one of the `bsi_insert' routines 16050 or `bsi_replace' performs an implicit call to `update_stmt'. 16051 16052 13.2.1 Operand Iterators And Access Routines 16053 -------------------------------------------- 16054 16055 Operands are collected by `tree-ssa-operands.c'. They are stored 16056 inside each statement's annotation and can be accessed through either 16057 the operand iterators or an access routine. 16058 16059 The following access routines are available for examining operands: 16060 16061 1. `SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 16062 NULL unless there is exactly one operand matching the specified 16063 flags. If there is exactly one operand, the operand is returned 16064 as either a `tree', `def_operand_p', or `use_operand_p'. 16065 16066 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 16067 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 16068 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 16069 16070 2. `ZERO_SSA_OPERANDS': This macro returns true if there are no 16071 operands matching the specified flags. 16072 16073 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 16074 return; 16075 16076 3. `NUM_SSA_OPERANDS': This macro Returns the number of operands 16077 matching 'flags'. This actually executes a loop to perform the 16078 count, so only use this if it is really needed. 16079 16080 int count = NUM_SSA_OPERANDS (stmt, flags) 16081 16082 If you wish to iterate over some or all operands, use the 16083 `FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 16084 all the operands for a statement: 16085 16086 void 16087 print_ops (tree stmt) 16088 { 16089 ssa_op_iter; 16090 tree var; 16091 16092 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 16093 print_generic_expr (stderr, var, TDF_SLIM); 16094 } 16095 16096 How to choose the appropriate iterator: 16097 16098 1. Determine whether you are need to see the operand pointers, or 16099 just the trees, and choose the appropriate macro: 16100 16101 Need Macro: 16102 ---- ------- 16103 use_operand_p FOR_EACH_SSA_USE_OPERAND 16104 def_operand_p FOR_EACH_SSA_DEF_OPERAND 16105 tree FOR_EACH_SSA_TREE_OPERAND 16106 16107 2. You need to declare a variable of the type you are interested in, 16108 and an ssa_op_iter structure which serves as the loop controlling 16109 variable. 16110 16111 3. Determine which operands you wish to use, and specify the flags of 16112 those you are interested in. They are documented in 16113 `tree-ssa-operands.h': 16114 16115 #define SSA_OP_USE 0x01 /* Real USE operands. */ 16116 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 16117 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 16118 #define SSA_OP_VMAYUSE 0x08 /* USE portion of VDEFS. */ 16119 #define SSA_OP_VDEF 0x10 /* DEF portion of VDEFS. */ 16120 16121 /* These are commonly grouped operand flags. */ 16122 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE | SSA_OP_VMAYUSE) 16123 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 16124 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 16125 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 16126 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 16127 16128 So if you want to look at the use pointers for all the `USE' and 16129 `VUSE' operands, you would do something like: 16130 16131 use_operand_p use_p; 16132 ssa_op_iter iter; 16133 16134 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 16135 { 16136 process_use_ptr (use_p); 16137 } 16138 16139 The `TREE' macro is basically the same as the `USE' and `DEF' macros, 16140 only with the use or def dereferenced via `USE_FROM_PTR (use_p)' and 16141 `DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use 16142 and defs flags can be mixed. 16143 16144 tree var; 16145 ssa_op_iter iter; 16146 16147 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 16148 { 16149 print_generic_expr (stderr, var, TDF_SLIM); 16150 } 16151 16152 `VDEF's are broken into two flags, one for the `DEF' portion 16153 (`SSA_OP_VDEF') and one for the USE portion (`SSA_OP_VMAYUSE'). If all 16154 you want to look at are the `VDEF's together, there is a fourth 16155 iterator macro for this, which returns both a def_operand_p and a 16156 use_operand_p for each `VDEF' in the statement. Note that you don't 16157 need any flags for this one. 16158 16159 use_operand_p use_p; 16160 def_operand_p def_p; 16161 ssa_op_iter iter; 16162 16163 FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter) 16164 { 16165 my_code; 16166 } 16167 16168 There are many examples in the code as well, as well as the 16169 documentation in `tree-ssa-operands.h'. 16170 16171 There are also a couple of variants on the stmt iterators regarding PHI 16172 nodes. 16173 16174 `FOR_EACH_PHI_ARG' Works exactly like `FOR_EACH_SSA_USE_OPERAND', 16175 except it works over `PHI' arguments instead of statement operands. 16176 16177 /* Look at every virtual PHI use. */ 16178 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 16179 { 16180 my_code; 16181 } 16182 16183 /* Look at every real PHI use. */ 16184 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 16185 my_code; 16186 16187 /* Look at every PHI use. */ 16188 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 16189 my_code; 16190 16191 `FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 16192 `FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 16193 statement or a `PHI' node. These should be used when it is appropriate 16194 but they are not quite as efficient as the individual `FOR_EACH_PHI' 16195 and `FOR_EACH_SSA' routines. 16196 16197 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 16198 { 16199 my_code; 16200 } 16201 16202 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 16203 { 16204 my_code; 16205 } 16206 16207 13.2.2 Immediate Uses 16208 --------------------- 16209 16210 Immediate use information is now always available. Using the immediate 16211 use iterators, you may examine every use of any `SSA_NAME'. For 16212 instance, to change each use of `ssa_var' to `ssa_var2' and call 16213 fold_stmt on each stmt after that is done: 16214 16215 use_operand_p imm_use_p; 16216 imm_use_iterator iterator; 16217 tree ssa_var, stmt; 16218 16219 16220 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 16221 { 16222 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 16223 SET_USE (imm_use_p, ssa_var_2); 16224 fold_stmt (stmt); 16225 } 16226 16227 There are 2 iterators which can be used. `FOR_EACH_IMM_USE_FAST' is 16228 used when the immediate uses are not changed, i.e., you are looking at 16229 the uses, but not setting them. 16230 16231 If they do get changed, then care must be taken that things are not 16232 changed under the iterators, so use the `FOR_EACH_IMM_USE_STMT' and 16233 `FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 16234 sanity of the use list by moving all the uses for a statement into a 16235 controlled position, and then iterating over those uses. Then the 16236 optimization can manipulate the stmt when all the uses have been 16237 processed. This is a little slower than the FAST version since it adds 16238 a placeholder element and must sort through the list a bit for each 16239 statement. This placeholder element must be also be removed if the 16240 loop is terminated early. The macro `BREAK_FROM_IMM_USE_SAFE' is 16241 provided to do this : 16242 16243 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 16244 { 16245 if (stmt == last_stmt) 16246 BREAK_FROM_SAFE_IMM_USE (iter); 16247 16248 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 16249 SET_USE (imm_use_p, ssa_var_2); 16250 fold_stmt (stmt); 16251 } 16252 16253 There are checks in `verify_ssa' which verify that the immediate use 16254 list is up to date, as well as checking that an optimization didn't 16255 break from the loop without using this macro. It is safe to simply 16256 'break'; from a `FOR_EACH_IMM_USE_FAST' traverse. 16257 16258 Some useful functions and macros: 16259 1. `has_zero_uses (ssa_var)' : Returns true if there are no uses of 16260 `ssa_var'. 16261 16262 2. `has_single_use (ssa_var)' : Returns true if there is only a 16263 single use of `ssa_var'. 16264 16265 3. `single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 16266 Returns true if there is only a single use of `ssa_var', and also 16267 returns the use pointer and statement it occurs in, in the second 16268 and third parameters. 16269 16270 4. `num_imm_uses (ssa_var)' : Returns the number of immediate uses of 16271 `ssa_var'. It is better not to use this if possible since it simply 16272 utilizes a loop to count the uses. 16273 16274 5. `PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a `PHI' 16275 node, return the index number for the use. An assert is triggered 16276 if the use isn't located in a `PHI' node. 16277 16278 6. `USE_STMT (use_p)' : Return the statement a use occurs in. 16279 16280 Note that uses are not put into an immediate use list until their 16281 statement is actually inserted into the instruction stream via a 16282 `bsi_*' routine. 16283 16284 It is also still possible to utilize lazy updating of statements, but 16285 this should be used only when absolutely required. Both alias analysis 16286 and the dominator optimizations currently do this. 16287 16288 When lazy updating is being used, the immediate use information is out 16289 of date and cannot be used reliably. Lazy updating is achieved by 16290 simply marking statements modified via calls to `mark_stmt_modified' 16291 instead of `update_stmt'. When lazy updating is no longer required, 16292 all the modified statements must have `update_stmt' called in order to 16293 bring them up to date. This must be done before the optimization is 16294 finished, or `verify_ssa' will trigger an abort. 16295 16296 This is done with a simple loop over the instruction stream: 16297 block_stmt_iterator bsi; 16298 basic_block bb; 16299 FOR_EACH_BB (bb) 16300 { 16301 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 16302 update_stmt_if_modified (bsi_stmt (bsi)); 16303 } 16304 16305 16306 File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 16307 16308 13.3 Static Single Assignment 16309 ============================= 16310 16311 Most of the tree optimizers rely on the data flow information provided 16312 by the Static Single Assignment (SSA) form. We implement the SSA form 16313 as described in `R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 16314 Zadeck. Efficiently Computing Static Single Assignment Form and the 16315 Control Dependence Graph. ACM Transactions on Programming Languages 16316 and Systems, 13(4):451-490, October 1991'. 16317 16318 The SSA form is based on the premise that program variables are 16319 assigned in exactly one location in the program. Multiple assignments 16320 to the same variable create new versions of that variable. Naturally, 16321 actual programs are seldom in SSA form initially because variables tend 16322 to be assigned multiple times. The compiler modifies the program 16323 representation so that every time a variable is assigned in the code, a 16324 new version of the variable is created. Different versions of the same 16325 variable are distinguished by subscripting the variable name with its 16326 version number. Variables used in the right-hand side of expressions 16327 are renamed so that their version number matches that of the most 16328 recent assignment. 16329 16330 We represent variable versions using `SSA_NAME' nodes. The renaming 16331 process in `tree-ssa.c' wraps every real and virtual operand with an 16332 `SSA_NAME' node which contains the version number and the statement 16333 that created the `SSA_NAME'. Only definitions and virtual definitions 16334 may create new `SSA_NAME' nodes. 16335 16336 Sometimes, flow of control makes it impossible to determine the most 16337 recent version of a variable. In these cases, the compiler inserts an 16338 artificial definition for that variable called "PHI function" or "PHI 16339 node". This new definition merges all the incoming versions of the 16340 variable to create a new name for it. For instance, 16341 16342 if (...) 16343 a_1 = 5; 16344 else if (...) 16345 a_2 = 2; 16346 else 16347 a_3 = 13; 16348 16349 # a_4 = PHI <a_1, a_2, a_3> 16350 return a_4; 16351 16352 Since it is not possible to determine which of the three branches will 16353 be taken at runtime, we don't know which of `a_1', `a_2' or `a_3' to 16354 use at the return statement. So, the SSA renamer creates a new version 16355 `a_4' which is assigned the result of "merging" `a_1', `a_2' and `a_3'. 16356 Hence, PHI nodes mean "one of these operands. I don't know which". 16357 16358 The following macros can be used to examine PHI nodes 16359 16360 -- Macro: PHI_RESULT (PHI) 16361 Returns the `SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 16362 16363 -- Macro: PHI_NUM_ARGS (PHI) 16364 Returns the number of arguments in PHI. This number is exactly 16365 the number of incoming edges to the basic block holding PHI. 16366 16367 -- Macro: PHI_ARG_ELT (PHI, I) 16368 Returns a tuple representing the Ith argument of PHI. Each 16369 element of this tuple contains an `SSA_NAME' VAR and the incoming 16370 edge through which VAR flows. 16371 16372 -- Macro: PHI_ARG_EDGE (PHI, I) 16373 Returns the incoming edge for the Ith argument of PHI. 16374 16375 -- Macro: PHI_ARG_DEF (PHI, I) 16376 Returns the `SSA_NAME' for the Ith argument of PHI. 16377 16378 13.3.1 Preserving the SSA form 16379 ------------------------------ 16380 16381 Some optimization passes make changes to the function that invalidate 16382 the SSA property. This can happen when a pass has added new symbols or 16383 changed the program so that variables that were previously aliased 16384 aren't anymore. Whenever something like this happens, the affected 16385 symbols must be renamed into SSA form again. Transformations that emit 16386 new code or replicate existing statements will also need to update the 16387 SSA form. 16388 16389 Since GCC implements two different SSA forms for register and virtual 16390 variables, keeping the SSA form up to date depends on whether you are 16391 updating register or virtual names. In both cases, the general idea 16392 behind incremental SSA updates is similar: when new SSA names are 16393 created, they typically are meant to replace other existing names in 16394 the program. 16395 16396 For instance, given the following code: 16397 16398 1 L0: 16399 2 x_1 = PHI (0, x_5) 16400 3 if (x_1 < 10) 16401 4 if (x_1 > 7) 16402 5 y_2 = 0 16403 6 else 16404 7 y_3 = x_1 + x_7 16405 8 endif 16406 9 x_5 = x_1 + 1 16407 10 goto L0; 16408 11 endif 16409 16410 Suppose that we insert new names `x_10' and `x_11' (lines `4' and `8'). 16411 16412 1 L0: 16413 2 x_1 = PHI (0, x_5) 16414 3 if (x_1 < 10) 16415 4 x_10 = ... 16416 5 if (x_1 > 7) 16417 6 y_2 = 0 16418 7 else 16419 8 x_11 = ... 16420 9 y_3 = x_1 + x_7 16421 10 endif 16422 11 x_5 = x_1 + 1 16423 12 goto L0; 16424 13 endif 16425 16426 We want to replace all the uses of `x_1' with the new definitions of 16427 `x_10' and `x_11'. Note that the only uses that should be replaced are 16428 those at lines `5', `9' and `11'. Also, the use of `x_7' at line `9' 16429 should _not_ be replaced (this is why we cannot just mark symbol `x' for 16430 renaming). 16431 16432 Additionally, we may need to insert a PHI node at line `11' because 16433 that is a merge point for `x_10' and `x_11'. So the use of `x_1' at 16434 line `11' will be replaced with the new PHI node. The insertion of PHI 16435 nodes is optional. They are not strictly necessary to preserve the SSA 16436 form, and depending on what the caller inserted, they may not even be 16437 useful for the optimizers. 16438 16439 Updating the SSA form is a two step process. First, the pass has to 16440 identify which names need to be updated and/or which symbols need to be 16441 renamed into SSA form for the first time. When new names are 16442 introduced to replace existing names in the program, the mapping 16443 between the old and the new names are registered by calling 16444 `register_new_name_mapping' (note that if your pass creates new code by 16445 duplicating basic blocks, the call to `tree_duplicate_bb' will set up 16446 the necessary mappings automatically). On the other hand, if your pass 16447 exposes a new symbol that should be put in SSA form for the first time, 16448 the new symbol should be registered with `mark_sym_for_renaming'. 16449 16450 After the replacement mappings have been registered and new symbols 16451 marked for renaming, a call to `update_ssa' makes the registered 16452 changes. This can be done with an explicit call or by creating `TODO' 16453 flags in the `tree_opt_pass' structure for your pass. There are 16454 several `TODO' flags that control the behavior of `update_ssa': 16455 16456 * `TODO_update_ssa'. Update the SSA form inserting PHI nodes for 16457 newly exposed symbols and virtual names marked for updating. When 16458 updating real names, only insert PHI nodes for a real name `O_j' 16459 in blocks reached by all the new and old definitions for `O_j'. 16460 If the iterated dominance frontier for `O_j' is not pruned, we may 16461 end up inserting PHI nodes in blocks that have one or more edges 16462 with no incoming definition for `O_j'. This would lead to 16463 uninitialized warnings for `O_j''s symbol. 16464 16465 * `TODO_update_ssa_no_phi'. Update the SSA form without inserting 16466 any new PHI nodes at all. This is used by passes that have either 16467 inserted all the PHI nodes themselves or passes that need only to 16468 patch use-def and def-def chains for virtuals (e.g., DCE). 16469 16470 * `TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 16471 needed. No pruning of the IDF is done. This is used by passes 16472 that need the PHI nodes for `O_j' even if it means that some 16473 arguments will come from the default definition of `O_j''s symbol 16474 (e.g., `pass_linear_transform'). 16475 16476 WARNING: If you need to use this flag, chances are that your pass 16477 may be doing something wrong. Inserting PHI nodes for an old name 16478 where not all edges carry a new replacement may lead to silent 16479 codegen errors or spurious uninitialized warnings. 16480 16481 * `TODO_update_ssa_only_virtuals'. Passes that update the SSA form 16482 on their own may want to delegate the updating of virtual names to 16483 the generic updater. Since FUD chains are easier to maintain, 16484 this simplifies the work they need to do. NOTE: If this flag is 16485 used, any OLD->NEW mappings for real names are explicitly 16486 destroyed and only the symbols marked for renaming are processed. 16487 16488 13.3.2 Preserving the virtual SSA form 16489 -------------------------------------- 16490 16491 The virtual SSA form is harder to preserve than the non-virtual SSA form 16492 mainly because the set of virtual operands for a statement may change at 16493 what some would consider unexpected times. In general, statement 16494 modifications should be bracketed between calls to `push_stmt_changes' 16495 and `pop_stmt_changes'. For example, 16496 16497 munge_stmt (tree stmt) 16498 { 16499 push_stmt_changes (&stmt); 16500 ... rewrite STMT ... 16501 pop_stmt_changes (&stmt); 16502 } 16503 16504 The call to `push_stmt_changes' saves the current state of the 16505 statement operands and the call to `pop_stmt_changes' compares the 16506 saved state with the current one and does the appropriate symbol 16507 marking for the SSA renamer. 16508 16509 It is possible to modify several statements at a time, provided that 16510 `push_stmt_changes' and `pop_stmt_changes' are called in LIFO order, as 16511 when processing a stack of statements. 16512 16513 Additionally, if the pass discovers that it did not need to make 16514 changes to the statement after calling `push_stmt_changes', it can 16515 simply discard the topmost change buffer by calling 16516 `discard_stmt_changes'. This will avoid the expensive operand re-scan 16517 operation and the buffer comparison that determines if symbols need to 16518 be marked for renaming. 16519 16520 13.3.3 Examining `SSA_NAME' nodes 16521 --------------------------------- 16522 16523 The following macros can be used to examine `SSA_NAME' nodes 16524 16525 -- Macro: SSA_NAME_DEF_STMT (VAR) 16526 Returns the statement S that creates the `SSA_NAME' VAR. If S is 16527 an empty statement (i.e., `IS_EMPTY_STMT (S)' returns `true'), it 16528 means that the first reference to this variable is a USE or a VUSE. 16529 16530 -- Macro: SSA_NAME_VERSION (VAR) 16531 Returns the version number of the `SSA_NAME' object VAR. 16532 16533 13.3.4 Walking use-def chains 16534 ----------------------------- 16535 16536 -- Tree SSA function: void walk_use_def_chains (VAR, FN, DATA) 16537 Walks use-def chains starting at the `SSA_NAME' node VAR. Calls 16538 function FN at each reaching definition found. Function FN takes 16539 three arguments: VAR, its defining statement (DEF_STMT) and a 16540 generic pointer to whatever state information that FN may want to 16541 maintain (DATA). Function FN is able to stop the walk by 16542 returning `true', otherwise in order to continue the walk, FN 16543 should return `false'. 16544 16545 Note, that if DEF_STMT is a `PHI' node, the semantics are slightly 16546 different. For each argument ARG of the PHI node, this function 16547 will: 16548 16549 1. Walk the use-def chains for ARG. 16550 16551 2. Call `FN (ARG, PHI, DATA)'. 16552 16553 Note how the first argument to FN is no longer the original 16554 variable VAR, but the PHI argument currently being examined. If 16555 FN wants to get at VAR, it should call `PHI_RESULT' (PHI). 16556 16557 13.3.5 Walking the dominator tree 16558 --------------------------------- 16559 16560 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 16561 This function walks the dominator tree for the current CFG calling 16562 a set of callback functions defined in STRUCT DOM_WALK_DATA in 16563 `domwalk.h'. The call back functions you need to define give you 16564 hooks to execute custom code at various points during traversal: 16565 16566 1. Once to initialize any local data needed while processing BB 16567 and its children. This local data is pushed into an internal 16568 stack which is automatically pushed and popped as the walker 16569 traverses the dominator tree. 16570 16571 2. Once before traversing all the statements in the BB. 16572 16573 3. Once for every statement inside BB. 16574 16575 4. Once after traversing all the statements and before recursing 16576 into BB's dominator children. 16577 16578 5. It then recurses into all the dominator children of BB. 16579 16580 6. After recursing into all the dominator children of BB it can, 16581 optionally, traverse every statement in BB again (i.e., 16582 repeating steps 2 and 3). 16583 16584 7. Once after walking the statements in BB and BB's dominator 16585 children. At this stage, the block local data stack is 16586 popped. 16587 16588 16589 File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 16590 16591 13.4 Alias analysis 16592 =================== 16593 16594 Alias analysis in GIMPLE SSA form consists of two pieces. First the 16595 virtual SSA web ties conflicting memory accesses and provides a SSA 16596 use-def chain and SSA immediate-use chains for walking possibly 16597 dependent memory accesses. Second an alias-oracle can be queried to 16598 disambiguate explicit and implicit memory references. 16599 16600 1. Memory SSA form. 16601 16602 All statements that may use memory have exactly one accompanied 16603 use of a virtual SSA name that represents the state of memory at 16604 the given point in the IL. 16605 16606 All statements that may define memory have exactly one accompanied 16607 definition of a virtual SSA name using the previous state of memory 16608 and defining the new state of memory after the given point in the 16609 IL. 16610 16611 int i; 16612 int foo (void) 16613 { 16614 # .MEM_3 = VDEF <.MEM_2(D)> 16615 i = 1; 16616 # VUSE <.MEM_3> 16617 return i; 16618 } 16619 16620 The virtual SSA names in this case are `.MEM_2(D)' and `.MEM_3'. 16621 The store to the global variable `i' defines `.MEM_3' invalidating 16622 `.MEM_2(D)'. The load from `i' uses that new state `.MEM_3'. 16623 16624 The virtual SSA web serves as constraints to SSA optimizers 16625 preventing illegitimate code-motion and optimization. It also 16626 provides a way to walk related memory statements. 16627 16628 2. Points-to and escape analysis. 16629 16630 Points-to analysis builds a set of constraints from the GIMPLE SSA 16631 IL representing all pointer operations and facts we do or do not 16632 know about pointers. Solving this set of constraints yields a 16633 conservatively correct solution for each pointer variable in the 16634 program (though we are only interested in SSA name pointers) as to 16635 what it may possibly point to. 16636 16637 This points-to solution for a given SSA name pointer is stored in 16638 the `pt_solution' sub-structure of the `SSA_NAME_PTR_INFO' record. 16639 The following accessor functions are available: 16640 16641 * `pt_solution_includes' 16642 16643 * `pt_solutions_intersect' 16644 16645 Points-to analysis also computes the solution for two special set 16646 of pointers, `ESCAPED' and `CALLUSED'. Those represent all memory 16647 that has escaped the scope of analysis or that is used by pure or 16648 nested const calls. 16649 16650 3. Type-based alias analysis 16651 16652 Type-based alias analysis is frontend dependent though generic 16653 support is provided by the middle-end in `alias.c'. TBAA code is 16654 used by both tree optimizers and RTL optimizers. 16655 16656 Every language that wishes to perform language-specific alias 16657 analysis should define a function that computes, given a `tree' 16658 node, an alias set for the node. Nodes in different alias sets 16659 are not allowed to alias. For an example, see the C front-end 16660 function `c_get_alias_set'. 16661 16662 4. Tree alias-oracle 16663 16664 The tree alias-oracle provides means to disambiguate two memory 16665 references and memory references against statements. The following 16666 queries are available: 16667 16668 * `refs_may_alias_p' 16669 16670 * `ref_maybe_used_by_stmt_p' 16671 16672 * `stmt_may_clobber_ref_p' 16673 16674 In addition to those two kind of statement walkers are available 16675 walking statements related to a reference ref. 16676 `walk_non_aliased_vuses' walks over dominating memory defining 16677 statements and calls back if the statement does not clobber ref 16678 providing the non-aliased VUSE. The walk stops at the first 16679 clobbering statement or if asked to. `walk_aliased_vdefs' walks 16680 over dominating memory defining statements and calls back on each 16681 statement clobbering ref providing its aliasing VDEF. The walk 16682 stops if asked to. 16683 16684 16685 16686 File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 16687 16688 13.5 Memory model 16689 ================= 16690 16691 The memory model used by the middle-end models that of the C/C++ 16692 languages. The middle-end has the notion of an effective type of a 16693 memory region which is used for type-based alias analysis. 16694 16695 The following is a refinement of ISO C99 6.5/6, clarifying the block 16696 copy case to follow common sense and extending the concept of a dynamic 16697 effective type to objects with a declared type as required for C++. 16698 16699 The effective type of an object for an access to its stored value is 16700 the declared type of the object or the effective type determined by 16701 a previous store to it. If a value is stored into an object through 16702 an lvalue having a type that is not a character type, then the 16703 type of the lvalue becomes the effective type of the object for that 16704 access and for subsequent accesses that do not modify the stored value. 16705 If a value is copied into an object using `memcpy' or `memmove', 16706 or is copied as an array of character type, then the effective type 16707 of the modified object for that access and for subsequent accesses that 16708 do not modify the value is undetermined. For all other accesses to an 16709 object, the effective type of the object is simply the type of the 16710 lvalue used for the access. 16711 16712 16713 File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 16714 16715 14 Analysis and Representation of Loops 16716 *************************************** 16717 16718 GCC provides extensive infrastructure for work with natural loops, i.e., 16719 strongly connected components of CFG with only one entry block. This 16720 chapter describes representation of loops in GCC, both on GIMPLE and in 16721 RTL, as well as the interfaces to loop-related analyses (induction 16722 variable analysis and number of iterations analysis). 16723 16724 * Menu: 16725 16726 * Loop representation:: Representation and analysis of loops. 16727 * Loop querying:: Getting information about loops. 16728 * Loop manipulation:: Loop manipulation functions. 16729 * LCSSA:: Loop-closed SSA form. 16730 * Scalar evolutions:: Induction variables on GIMPLE. 16731 * loop-iv:: Induction variables on RTL. 16732 * Number of iterations:: Number of iterations analysis. 16733 * Dependency analysis:: Data dependency analysis. 16734 * Lambda:: Linear loop transformations framework. 16735 * Omega:: A solver for linear programming problems. 16736 16737 16738 File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 16739 16740 14.1 Loop representation 16741 ======================== 16742 16743 This chapter describes the representation of loops in GCC, and functions 16744 that can be used to build, modify and analyze this representation. Most 16745 of the interfaces and data structures are declared in `cfgloop.h'. At 16746 the moment, loop structures are analyzed and this information is 16747 updated only by the optimization passes that deal with loops, but some 16748 efforts are being made to make it available throughout most of the 16749 optimization passes. 16750 16751 In general, a natural loop has one entry block (header) and possibly 16752 several back edges (latches) leading to the header from the inside of 16753 the loop. Loops with several latches may appear if several loops share 16754 a single header, or if there is a branching in the middle of the loop. 16755 The representation of loops in GCC however allows only loops with a 16756 single latch. During loop analysis, headers of such loops are split and 16757 forwarder blocks are created in order to disambiguate their structures. 16758 Heuristic based on profile information and structure of the induction 16759 variables in the loops is used to determine whether the latches 16760 correspond to sub-loops or to control flow in a single loop. This means 16761 that the analysis sometimes changes the CFG, and if you run it in the 16762 middle of an optimization pass, you must be able to deal with the new 16763 blocks. You may avoid CFG changes by passing 16764 `LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 16765 however that most other loop manipulation functions will not work 16766 correctly for loops with multiple latch edges (the functions that only 16767 query membership of blocks to loops and subloop relationships, or 16768 enumerate and test loop exits, can be expected to work). 16769 16770 Body of the loop is the set of blocks that are dominated by its header, 16771 and reachable from its latch against the direction of edges in CFG. The 16772 loops are organized in a containment hierarchy (tree) such that all the 16773 loops immediately contained inside loop L are the children of L in the 16774 tree. This tree is represented by the `struct loops' structure. The 16775 root of this tree is a fake loop that contains all blocks in the 16776 function. Each of the loops is represented in a `struct loop' 16777 structure. Each loop is assigned an index (`num' field of the `struct 16778 loop' structure), and the pointer to the loop is stored in the 16779 corresponding field of the `larray' vector in the loops structure. The 16780 indices do not have to be continuous, there may be empty (`NULL') 16781 entries in the `larray' created by deleting loops. Also, there is no 16782 guarantee on the relative order of a loop and its subloops in the 16783 numbering. The index of a loop never changes. 16784 16785 The entries of the `larray' field should not be accessed directly. 16786 The function `get_loop' returns the loop description for a loop with 16787 the given index. `number_of_loops' function returns number of loops in 16788 the function. To traverse all loops, use `FOR_EACH_LOOP' macro. The 16789 `flags' argument of the macro is used to determine the direction of 16790 traversal and the set of loops visited. Each loop is guaranteed to be 16791 visited exactly once, regardless of the changes to the loop tree, and 16792 the loops may be removed during the traversal. The newly created loops 16793 are never traversed, if they need to be visited, this must be done 16794 separately after their creation. The `FOR_EACH_LOOP' macro allocates 16795 temporary variables. If the `FOR_EACH_LOOP' loop were ended using 16796 break or goto, they would not be released; `FOR_EACH_LOOP_BREAK' macro 16797 must be used instead. 16798 16799 Each basic block contains the reference to the innermost loop it 16800 belongs to (`loop_father'). For this reason, it is only possible to 16801 have one `struct loops' structure initialized at the same time for each 16802 CFG. The global variable `current_loops' contains the `struct loops' 16803 structure. Many of the loop manipulation functions assume that 16804 dominance information is up-to-date. 16805 16806 The loops are analyzed through `loop_optimizer_init' function. The 16807 argument of this function is a set of flags represented in an integer 16808 bitmask. These flags specify what other properties of the loop 16809 structures should be calculated/enforced and preserved later: 16810 16811 * `LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 16812 to CFG will be performed in the loop analysis, in particular, 16813 loops with multiple latch edges will not be disambiguated. If a 16814 loop has multiple latches, its latch block is set to NULL. Most of 16815 the loop manipulation functions will not work for loops in this 16816 shape. No other flags that require CFG changes can be passed to 16817 loop_optimizer_init. 16818 16819 * `LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a 16820 way that each loop has only one entry edge, and additionally, the 16821 source block of this entry edge has only one successor. This 16822 creates a natural place where the code can be moved out of the 16823 loop, and ensures that the entry edge of the loop leads from its 16824 immediate super-loop. 16825 16826 * `LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 16827 the latch block of each loop to have only one successor. This 16828 ensures that the latch of the loop does not belong to any of its 16829 sub-loops, and makes manipulation with the loops significantly 16830 easier. Most of the loop manipulation functions assume that the 16831 loops are in this shape. Note that with this flag, the "normal" 16832 loop without any control flow inside and with one exit consists of 16833 two basic blocks. 16834 16835 * `LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 16836 the strongly connected components that are not natural loops (have 16837 more than one entry block) are marked with `BB_IRREDUCIBLE_LOOP' 16838 and `EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 16839 and edges that belong to natural loops that are in such an 16840 irreducible region (but it is set for the entry and exit edges of 16841 such a loop, if they lead to/from this region). 16842 16843 * `LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 16844 updated for each loop. This makes some functions (e.g., 16845 `get_loop_exit_edges') more efficient. Some functions (e.g., 16846 `single_exit') can be used only if the lists of exits are recorded. 16847 16848 These properties may also be computed/enforced later, using functions 16849 `create_preheaders', `force_single_succ_latches', 16850 `mark_irreducible_loops' and `record_loop_exits'. 16851 16852 The memory occupied by the loops structures should be freed with 16853 `loop_optimizer_finalize' function. 16854 16855 The CFG manipulation functions in general do not update loop 16856 structures. Specialized versions that additionally do so are provided 16857 for the most common tasks. On GIMPLE, `cleanup_tree_cfg_loop' function 16858 can be used to cleanup CFG while updating the loops structures if 16859 `current_loops' is set. 16860 16861 16862 File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 16863 16864 14.2 Loop querying 16865 ================== 16866 16867 The functions to query the information about loops are declared in 16868 `cfgloop.h'. Some of the information can be taken directly from the 16869 structures. `loop_father' field of each basic block contains the 16870 innermost loop to that the block belongs. The most useful fields of 16871 loop structure (that are kept up-to-date at all times) are: 16872 16873 * `header', `latch': Header and latch basic blocks of the loop. 16874 16875 * `num_nodes': Number of basic blocks in the loop (including the 16876 basic blocks of the sub-loops). 16877 16878 * `depth': The depth of the loop in the loops tree, i.e., the number 16879 of super-loops of the loop. 16880 16881 * `outer', `inner', `next': The super-loop, the first sub-loop, and 16882 the sibling of the loop in the loops tree. 16883 16884 There are other fields in the loop structures, many of them used only 16885 by some of the passes, or not updated during CFG changes; in general, 16886 they should not be accessed directly. 16887 16888 The most important functions to query loop structures are: 16889 16890 * `flow_loops_dump': Dumps the information about loops to a file. 16891 16892 * `verify_loop_structure': Checks consistency of the loop structures. 16893 16894 * `loop_latch_edge': Returns the latch edge of a loop. 16895 16896 * `loop_preheader_edge': If loops have preheaders, returns the 16897 preheader edge of a loop. 16898 16899 * `flow_loop_nested_p': Tests whether loop is a sub-loop of another 16900 loop. 16901 16902 * `flow_bb_inside_loop_p': Tests whether a basic block belongs to a 16903 loop (including its sub-loops). 16904 16905 * `find_common_loop': Finds the common super-loop of two loops. 16906 16907 * `superloop_at_depth': Returns the super-loop of a loop with the 16908 given depth. 16909 16910 * `tree_num_loop_insns', `num_loop_insns': Estimates the number of 16911 insns in the loop, on GIMPLE and on RTL. 16912 16913 * `loop_exit_edge_p': Tests whether edge is an exit from a loop. 16914 16915 * `mark_loop_exit_edges': Marks all exit edges of all loops with 16916 `EDGE_LOOP_EXIT' flag. 16917 16918 * `get_loop_body', `get_loop_body_in_dom_order', 16919 `get_loop_body_in_bfs_order': Enumerates the basic blocks in the 16920 loop in depth-first search order in reversed CFG, ordered by 16921 dominance relation, and breath-first search order, respectively. 16922 16923 * `single_exit': Returns the single exit edge of the loop, or `NULL' 16924 if the loop has more than one exit. You can only use this 16925 function if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 16926 16927 * `get_loop_exit_edges': Enumerates the exit edges of a loop. 16928 16929 * `just_once_each_iteration_p': Returns true if the basic block is 16930 executed exactly once during each iteration of a loop (that is, it 16931 does not belong to a sub-loop, and it dominates the latch of the 16932 loop). 16933 16934 16935 File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 16936 16937 14.3 Loop manipulation 16938 ====================== 16939 16940 The loops tree can be manipulated using the following functions: 16941 16942 * `flow_loop_tree_node_add': Adds a node to the tree. 16943 16944 * `flow_loop_tree_node_remove': Removes a node from the tree. 16945 16946 * `add_bb_to_loop': Adds a basic block to a loop. 16947 16948 * `remove_bb_from_loops': Removes a basic block from loops. 16949 16950 Most low-level CFG functions update loops automatically. The following 16951 functions handle some more complicated cases of CFG manipulations: 16952 16953 * `remove_path': Removes an edge and all blocks it dominates. 16954 16955 * `split_loop_exit_edge': Splits exit edge of the loop, ensuring 16956 that PHI node arguments remain in the loop (this ensures that 16957 loop-closed SSA form is preserved). Only useful on GIMPLE. 16958 16959 Finally, there are some higher-level loop transformations implemented. 16960 While some of them are written so that they should work on non-innermost 16961 loops, they are mostly untested in that case, and at the moment, they 16962 are only reliable for the innermost loops: 16963 16964 * `create_iv': Creates a new induction variable. Only works on 16965 GIMPLE. `standard_iv_increment_position' can be used to find a 16966 suitable place for the iv increment. 16967 16968 * `duplicate_loop_to_header_edge', 16969 `tree_duplicate_loop_to_header_edge': These functions (on RTL and 16970 on GIMPLE) duplicate the body of the loop prescribed number of 16971 times on one of the edges entering loop header, thus performing 16972 either loop unrolling or loop peeling. `can_duplicate_loop_p' 16973 (`can_unroll_loop_p' on GIMPLE) must be true for the duplicated 16974 loop. 16975 16976 * `loop_version', `tree_ssa_loop_version': These function create a 16977 copy of a loop, and a branch before them that selects one of them 16978 depending on the prescribed condition. This is useful for 16979 optimizations that need to verify some assumptions in runtime (one 16980 of the copies of the loop is usually left unchanged, while the 16981 other one is transformed in some way). 16982 16983 * `tree_unroll_loop': Unrolls the loop, including peeling the extra 16984 iterations to make the number of iterations divisible by unroll 16985 factor, updating the exit condition, and removing the exits that 16986 now cannot be taken. Works only on GIMPLE. 16987 16988 16989 File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 16990 16991 14.4 Loop-closed SSA form 16992 ========================= 16993 16994 Throughout the loop optimizations on tree level, one extra condition is 16995 enforced on the SSA form: No SSA name is used outside of the loop in 16996 that it is defined. The SSA form satisfying this condition is called 16997 "loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 16998 created at the exits of the loops for the SSA names that are used 16999 outside of them. Only the real operands (not virtual SSA names) are 17000 held in LCSSA, in order to save memory. 17001 17002 There are various benefits of LCSSA: 17003 17004 * Many optimizations (value range analysis, final value replacement) 17005 are interested in the values that are defined in the loop and used 17006 outside of it, i.e., exactly those for that we create new PHI 17007 nodes. 17008 17009 * In induction variable analysis, it is not necessary to specify the 17010 loop in that the analysis should be performed - the scalar 17011 evolution analysis always returns the results with respect to the 17012 loop in that the SSA name is defined. 17013 17014 * It makes updating of SSA form during loop transformations simpler. 17015 Without LCSSA, operations like loop unrolling may force creation 17016 of PHI nodes arbitrarily far from the loop, while in LCSSA, the 17017 SSA form can be updated locally. However, since we only keep real 17018 operands in LCSSA, we cannot use this advantage (we could have 17019 local updating of real operands, but it is not much more efficient 17020 than to use generic SSA form updating for it as well; the amount 17021 of changes to SSA is the same). 17022 17023 However, it also means LCSSA must be updated. This is usually 17024 straightforward, unless you create a new value in loop and use it 17025 outside, or unless you manipulate loop exit edges (functions are 17026 provided to make these manipulations simple). 17027 `rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, 17028 and `verify_loop_closed_ssa' to check that the invariant of LCSSA is 17029 preserved. 17030 17031 17032 File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 17033 17034 14.5 Scalar evolutions 17035 ====================== 17036 17037 Scalar evolutions (SCEV) are used to represent results of induction 17038 variable analysis on GIMPLE. They enable us to represent variables with 17039 complicated behavior in a simple and consistent way (we only use it to 17040 express values of polynomial induction variables, but it is possible to 17041 extend it). The interfaces to SCEV analysis are declared in 17042 `tree-scalar-evolution.h'. To use scalar evolutions analysis, 17043 `scev_initialize' must be used. To stop using SCEV, `scev_finalize' 17044 should be used. SCEV analysis caches results in order to save time and 17045 memory. This cache however is made invalid by most of the loop 17046 transformations, including removal of code. If such a transformation 17047 is performed, `scev_reset' must be called to clean the caches. 17048 17049 Given an SSA name, its behavior in loops can be analyzed using the 17050 `analyze_scalar_evolution' function. The returned SCEV however does 17051 not have to be fully analyzed and it may contain references to other 17052 SSA names defined in the loop. To resolve these (potentially 17053 recursive) references, `instantiate_parameters' or `resolve_mixers' 17054 functions must be used. `instantiate_parameters' is useful when you 17055 use the results of SCEV only for some analysis, and when you work with 17056 whole nest of loops at once. It will try replacing all SSA names by 17057 their SCEV in all loops, including the super-loops of the current loop, 17058 thus providing a complete information about the behavior of the 17059 variable in the loop nest. `resolve_mixers' is useful if you work with 17060 only one loop at a time, and if you possibly need to create code based 17061 on the value of the induction variable. It will only resolve the SSA 17062 names defined in the current loop, leaving the SSA names defined 17063 outside unchanged, even if their evolution in the outer loops is known. 17064 17065 The SCEV is a normal tree expression, except for the fact that it may 17066 contain several special tree nodes. One of them is `SCEV_NOT_KNOWN', 17067 used for SSA names whose value cannot be expressed. The other one is 17068 `POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 17069 and loop (both base and step may contain further polynomial chrecs). 17070 Type of the expression and of base and step must be the same. A 17071 variable has evolution `POLYNOMIAL_CHREC(base, step, loop)' if it is 17072 (in the specified loop) equivalent to `x_1' in the following example 17073 17074 while (...) 17075 { 17076 x_1 = phi (base, x_2); 17077 x_2 = x_1 + step; 17078 } 17079 17080 Note that this includes the language restrictions on the operations. 17081 For example, if we compile C code and `x' has signed type, then the 17082 overflow in addition would cause undefined behavior, and we may assume 17083 that this does not happen. Hence, the value with this SCEV cannot 17084 overflow (which restricts the number of iterations of such a loop). 17085 17086 In many cases, one wants to restrict the attention just to affine 17087 induction variables. In this case, the extra expressive power of SCEV 17088 is not useful, and may complicate the optimizations. In this case, 17089 `simple_iv' function may be used to analyze a value - the result is a 17090 loop-invariant base and step. 17091 17092 17093 File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 17094 17095 14.6 IV analysis on RTL 17096 ======================= 17097 17098 The induction variable on RTL is simple and only allows analysis of 17099 affine induction variables, and only in one loop at once. The interface 17100 is declared in `cfgloop.h'. Before analyzing induction variables in a 17101 loop L, `iv_analysis_loop_init' function must be called on L. After 17102 the analysis (possibly calling `iv_analysis_loop_init' for several 17103 loops) is finished, `iv_analysis_done' should be called. The following 17104 functions can be used to access the results of the analysis: 17105 17106 * `iv_analyze': Analyzes a single register used in the given insn. 17107 If no use of the register in this insn is found, the following 17108 insns are scanned, so that this function can be called on the insn 17109 returned by get_condition. 17110 17111 * `iv_analyze_result': Analyzes result of the assignment in the 17112 given insn. 17113 17114 * `iv_analyze_expr': Analyzes a more complicated expression. All 17115 its operands are analyzed by `iv_analyze', and hence they must be 17116 used in the specified insn or one of the following insns. 17117 17118 The description of the induction variable is provided in `struct 17119 rtx_iv'. In order to handle subregs, the representation is a bit 17120 complicated; if the value of the `extend' field is not `UNKNOWN', the 17121 value of the induction variable in the i-th iteration is 17122 17123 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 17124 17125 with the following exception: if `first_special' is true, then the 17126 value in the first iteration (when `i' is zero) is `delta + mult * 17127 base'. However, if `extend' is equal to `UNKNOWN', then 17128 `first_special' must be false, `delta' 0, `mult' 1 and the value in the 17129 i-th iteration is 17130 17131 subreg_{mode} (base + i * step) 17132 17133 The function `get_iv_value' can be used to perform these calculations. 17134 17135 17136 File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 17137 17138 14.7 Number of iterations analysis 17139 ================================== 17140 17141 Both on GIMPLE and on RTL, there are functions available to determine 17142 the number of iterations of a loop, with a similar interface. The 17143 number of iterations of a loop in GCC is defined as the number of 17144 executions of the loop latch. In many cases, it is not possible to 17145 determine the number of iterations unconditionally - the determined 17146 number is correct only if some assumptions are satisfied. The analysis 17147 tries to verify these conditions using the information contained in the 17148 program; if it fails, the conditions are returned together with the 17149 result. The following information and conditions are provided by the 17150 analysis: 17151 17152 * `assumptions': If this condition is false, the rest of the 17153 information is invalid. 17154 17155 * `noloop_assumptions' on RTL, `may_be_zero' on GIMPLE: If this 17156 condition is true, the loop exits in the first iteration. 17157 17158 * `infinite': If this condition is true, the loop is infinite. This 17159 condition is only available on RTL. On GIMPLE, conditions for 17160 finiteness of the loop are included in `assumptions'. 17161 17162 * `niter_expr' on RTL, `niter' on GIMPLE: The expression that gives 17163 number of iterations. The number of iterations is defined as the 17164 number of executions of the loop latch. 17165 17166 Both on GIMPLE and on RTL, it necessary for the induction variable 17167 analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 17168 On GIMPLE, the results are stored to `struct tree_niter_desc' 17169 structure. Number of iterations before the loop is exited through a 17170 given exit can be determined using `number_of_iterations_exit' 17171 function. On RTL, the results are returned in `struct niter_desc' 17172 structure. The corresponding function is named `check_simple_exit'. 17173 There are also functions that pass through all the exits of a loop and 17174 try to find one with easy to determine number of iterations - 17175 `find_loop_niter' on GIMPLE and `find_simple_exit' on RTL. Finally, 17176 there are functions that provide the same information, but additionally 17177 cache it, so that repeated calls to number of iterations are not so 17178 costly - `number_of_latch_executions' on GIMPLE and 17179 `get_simple_loop_desc' on RTL. 17180 17181 Note that some of these functions may behave slightly differently than 17182 others - some of them return only the expression for the number of 17183 iterations, and fail if there are some assumptions. The function 17184 `number_of_latch_executions' works only for single-exit loops. The 17185 function `number_of_cond_exit_executions' can be used to determine 17186 number of executions of the exit condition of a single-exit loop (i.e., 17187 the `number_of_latch_executions' increased by one). 17188 17189 17190 File: gccint.info, Node: Dependency analysis, Next: Lambda, Prev: Number of iterations, Up: Loop Analysis and Representation 17191 17192 14.8 Data Dependency Analysis 17193 ============================= 17194 17195 The code for the data dependence analysis can be found in 17196 `tree-data-ref.c' and its interface and data structures are described 17197 in `tree-data-ref.h'. The function that computes the data dependences 17198 for all the array and pointer references for a given loop is 17199 `compute_data_dependences_for_loop'. This function is currently used 17200 by the linear loop transform and the vectorization passes. Before 17201 calling this function, one has to allocate two vectors: a first vector 17202 will contain the set of data references that are contained in the 17203 analyzed loop body, and the second vector will contain the dependence 17204 relations between the data references. Thus if the vector of data 17205 references is of size `n', the vector containing the dependence 17206 relations will contain `n*n' elements. However if the analyzed loop 17207 contains side effects, such as calls that potentially can interfere 17208 with the data references in the current analyzed loop, the analysis 17209 stops while scanning the loop body for data references, and inserts a 17210 single `chrec_dont_know' in the dependence relation array. 17211 17212 The data references are discovered in a particular order during the 17213 scanning of the loop body: the loop body is analyzed in execution order, 17214 and the data references of each statement are pushed at the end of the 17215 data reference array. Two data references syntactically occur in the 17216 program in the same order as in the array of data references. This 17217 syntactic order is important in some classical data dependence tests, 17218 and mapping this order to the elements of this array avoids costly 17219 queries to the loop body representation. 17220 17221 Three types of data references are currently handled: ARRAY_REF, 17222 INDIRECT_REF and COMPONENT_REF. The data structure for the data 17223 reference is `data_reference', where `data_reference_p' is a name of a 17224 pointer to the data reference structure. The structure contains the 17225 following elements: 17226 17227 * `base_object_info': Provides information about the base object of 17228 the data reference and its access functions. These access functions 17229 represent the evolution of the data reference in the loop relative 17230 to its base, in keeping with the classical meaning of the data 17231 reference access function for the support of arrays. For example, 17232 for a reference `a.b[i][j]', the base object is `a.b' and the 17233 access functions, one for each array subscript, are: `{i_init, + 17234 i_step}_1, {j_init, +, j_step}_2'. 17235 17236 * `first_location_in_loop': Provides information about the first 17237 location accessed by the data reference in the loop and about the 17238 access function used to represent evolution relative to this 17239 location. This data is used to support pointers, and is not used 17240 for arrays (for which we have base objects). Pointer accesses are 17241 represented as a one-dimensional access that starts from the first 17242 location accessed in the loop. For example: 17243 17244 for1 i 17245 for2 j 17246 *((int *)p + i + j) = a[i][j]; 17247 17248 The access function of the pointer access is `{0, + 4B}_for2' 17249 relative to `p + i'. The access functions of the array are 17250 `{i_init, + i_step}_for1' and `{j_init, +, j_step}_for2' relative 17251 to `a'. 17252 17253 Usually, the object the pointer refers to is either unknown, or we 17254 can't prove that the access is confined to the boundaries of a 17255 certain object. 17256 17257 Two data references can be compared only if at least one of these 17258 two representations has all its fields filled for both data 17259 references. 17260 17261 The current strategy for data dependence tests is as follows: If 17262 both `a' and `b' are represented as arrays, compare 17263 `a.base_object' and `b.base_object'; if they are equal, apply 17264 dependence tests (use access functions based on base_objects). 17265 Else if both `a' and `b' are represented as pointers, compare 17266 `a.first_location' and `b.first_location'; if they are equal, 17267 apply dependence tests (use access functions based on first 17268 location). However, if `a' and `b' are represented differently, 17269 only try to prove that the bases are definitely different. 17270 17271 * Aliasing information. 17272 17273 * Alignment information. 17274 17275 The structure describing the relation between two data references is 17276 `data_dependence_relation' and the shorter name for a pointer to such a 17277 structure is `ddr_p'. This structure contains: 17278 17279 * a pointer to each data reference, 17280 17281 * a tree node `are_dependent' that is set to `chrec_known' if the 17282 analysis has proved that there is no dependence between these two 17283 data references, `chrec_dont_know' if the analysis was not able to 17284 determine any useful result and potentially there could exist a 17285 dependence between these data references, and `are_dependent' is 17286 set to `NULL_TREE' if there exist a dependence relation between the 17287 data references, and the description of this dependence relation is 17288 given in the `subscripts', `dir_vects', and `dist_vects' arrays, 17289 17290 * a boolean that determines whether the dependence relation can be 17291 represented by a classical distance vector, 17292 17293 * an array `subscripts' that contains a description of each 17294 subscript of the data references. Given two array accesses a 17295 subscript is the tuple composed of the access functions for a given 17296 dimension. For example, given `A[f1][f2][f3]' and 17297 `B[g1][g2][g3]', there are three subscripts: `(f1, g1), (f2, g2), 17298 (f3, g3)'. 17299 17300 * two arrays `dir_vects' and `dist_vects' that contain classical 17301 representations of the data dependences under the form of 17302 direction and distance dependence vectors, 17303 17304 * an array of loops `loop_nest' that contains the loops to which the 17305 distance and direction vectors refer to. 17306 17307 Several functions for pretty printing the information extracted by the 17308 data dependence analysis are available: `dump_ddrs' prints with a 17309 maximum verbosity the details of a data dependence relations array, 17310 `dump_dist_dir_vectors' prints only the classical distance and 17311 direction vectors for a data dependence relations array, and 17312 `dump_data_references' prints the details of the data references 17313 contained in a data reference array. 17314 17315 17316 File: gccint.info, Node: Lambda, Next: Omega, Prev: Dependency analysis, Up: Loop Analysis and Representation 17317 17318 14.9 Linear loop transformations framework 17319 ========================================== 17320 17321 Lambda is a framework that allows transformations of loops using 17322 non-singular matrix based transformations of the iteration space and 17323 loop bounds. This allows compositions of skewing, scaling, interchange, 17324 and reversal transformations. These transformations are often used to 17325 improve cache behavior or remove inner loop dependencies to allow 17326 parallelization and vectorization to take place. 17327 17328 To perform these transformations, Lambda requires that the loopnest be 17329 converted into an internal form that can be matrix transformed easily. 17330 To do this conversion, the function `gcc_loopnest_to_lambda_loopnest' 17331 is provided. If the loop cannot be transformed using lambda, this 17332 function will return NULL. 17333 17334 Once a `lambda_loopnest' is obtained from the conversion function, it 17335 can be transformed by using `lambda_loopnest_transform', which takes a 17336 transformation matrix to apply. Note that it is up to the caller to 17337 verify that the transformation matrix is legal to apply to the loop 17338 (dependence respecting, etc). Lambda simply applies whatever matrix it 17339 is told to provide. It can be extended to make legal matrices out of 17340 any non-singular matrix, but this is not currently implemented. 17341 Legality of a matrix for a given loopnest can be verified using 17342 `lambda_transform_legal_p'. 17343 17344 Given a transformed loopnest, conversion back into gcc IR is done by 17345 `lambda_loopnest_to_gcc_loopnest'. This function will modify the loops 17346 so that they match the transformed loopnest. 17347 17348 17349 File: gccint.info, Node: Omega, Prev: Lambda, Up: Loop Analysis and Representation 17350 17351 14.10 Omega a solver for linear programming problems 17352 ==================================================== 17353 17354 The data dependence analysis contains several solvers triggered 17355 sequentially from the less complex ones to the more sophisticated. For 17356 ensuring the consistency of the results of these solvers, a data 17357 dependence check pass has been implemented based on two different 17358 solvers. The second method that has been integrated to GCC is based on 17359 the Omega dependence solver, written in the 1990's by William Pugh and 17360 David Wonnacott. Data dependence tests can be formulated using a 17361 subset of the Presburger arithmetics that can be translated to linear 17362 constraint systems. These linear constraint systems can then be solved 17363 using the Omega solver. 17364 17365 The Omega solver is using Fourier-Motzkin's algorithm for variable 17366 elimination: a linear constraint system containing `n' variables is 17367 reduced to a linear constraint system with `n-1' variables. The Omega 17368 solver can also be used for solving other problems that can be 17369 expressed under the form of a system of linear equalities and 17370 inequalities. The Omega solver is known to have an exponential worst 17371 case, also known under the name of "omega nightmare" in the literature, 17372 but in practice, the omega test is known to be efficient for the common 17373 data dependence tests. 17374 17375 The interface used by the Omega solver for describing the linear 17376 programming problems is described in `omega.h', and the solver is 17377 `omega_solve_problem'. 17378 17379 17380 File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 17381 17382 15 Control Flow Graph 17383 ********************* 17384 17385 A control flow graph (CFG) is a data structure built on top of the 17386 intermediate code representation (the RTL or `tree' instruction stream) 17387 abstracting the control flow behavior of a function that is being 17388 compiled. The CFG is a directed graph where the vertices represent 17389 basic blocks and edges represent possible transfer of control flow from 17390 one basic block to another. The data structures used to represent the 17391 control flow graph are defined in `basic-block.h'. 17392 17393 * Menu: 17394 17395 * Basic Blocks:: The definition and representation of basic blocks. 17396 * Edges:: Types of edges and their representation. 17397 * Profile information:: Representation of frequencies and probabilities. 17398 * Maintaining the CFG:: Keeping the control flow graph and up to date. 17399 * Liveness information:: Using and maintaining liveness information. 17400 17401 17402 File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 17403 17404 15.1 Basic Blocks 17405 ================= 17406 17407 A basic block is a straight-line sequence of code with only one entry 17408 point and only one exit. In GCC, basic blocks are represented using 17409 the `basic_block' data type. 17410 17411 Two pointer members of the `basic_block' structure are the pointers 17412 `next_bb' and `prev_bb'. These are used to keep doubly linked chain of 17413 basic blocks in the same order as the underlying instruction stream. 17414 The chain of basic blocks is updated transparently by the provided API 17415 for manipulating the CFG. The macro `FOR_EACH_BB' can be used to visit 17416 all the basic blocks in lexicographical order. Dominator traversals 17417 are also possible using `walk_dominator_tree'. Given two basic blocks 17418 A and B, block A dominates block B if A is _always_ executed before B. 17419 17420 The `BASIC_BLOCK' array contains all basic blocks in an unspecified 17421 order. Each `basic_block' structure has a field that holds a unique 17422 integer identifier `index' that is the index of the block in the 17423 `BASIC_BLOCK' array. The total number of basic blocks in the function 17424 is `n_basic_blocks'. Both the basic block indices and the total number 17425 of basic blocks may vary during the compilation process, as passes 17426 reorder, create, duplicate, and destroy basic blocks. The index for 17427 any block should never be greater than `last_basic_block'. 17428 17429 Special basic blocks represent possible entry and exit points of a 17430 function. These blocks are called `ENTRY_BLOCK_PTR' and 17431 `EXIT_BLOCK_PTR'. These blocks do not contain any code, and are not 17432 elements of the `BASIC_BLOCK' array. Therefore they have been assigned 17433 unique, negative index numbers. 17434 17435 Each `basic_block' also contains pointers to the first instruction 17436 (the "head") and the last instruction (the "tail") or "end" of the 17437 instruction stream contained in a basic block. In fact, since the 17438 `basic_block' data type is used to represent blocks in both major 17439 intermediate representations of GCC (`tree' and RTL), there are 17440 pointers to the head and end of a basic block for both representations. 17441 17442 For RTL, these pointers are `rtx head, end'. In the RTL function 17443 representation, the head pointer always points either to a 17444 `NOTE_INSN_BASIC_BLOCK' or to a `CODE_LABEL', if present. In the RTL 17445 representation of a function, the instruction stream contains not only 17446 the "real" instructions, but also "notes". Any function that moves or 17447 duplicates the basic blocks needs to take care of updating of these 17448 notes. Many of these notes expect that the instruction stream consists 17449 of linear regions, making such updates difficult. The 17450 `NOTE_INSN_BASIC_BLOCK' note is the only kind of note that may appear 17451 in the instruction stream contained in a basic block. The instruction 17452 stream of a basic block always follows a `NOTE_INSN_BASIC_BLOCK', but 17453 zero or more `CODE_LABEL' nodes can precede the block note. A basic 17454 block ends by control flow instruction or last instruction before 17455 following `CODE_LABEL' or `NOTE_INSN_BASIC_BLOCK'. A `CODE_LABEL' 17456 cannot appear in the instruction stream of a basic block. 17457 17458 In addition to notes, the jump table vectors are also represented as 17459 "pseudo-instructions" inside the insn stream. These vectors never 17460 appear in the basic block and should always be placed just after the 17461 table jump instructions referencing them. After removing the 17462 table-jump it is often difficult to eliminate the code computing the 17463 address and referencing the vector, so cleaning up these vectors is 17464 postponed until after liveness analysis. Thus the jump table vectors 17465 may appear in the insn stream unreferenced and without any purpose. 17466 Before any edge is made "fall-thru", the existence of such construct in 17467 the way needs to be checked by calling `can_fallthru' function. 17468 17469 For the `tree' representation, the head and end of the basic block are 17470 being pointed to by the `stmt_list' field, but this special `tree' 17471 should never be referenced directly. Instead, at the tree level 17472 abstract containers and iterators are used to access statements and 17473 expressions in basic blocks. These iterators are called "block 17474 statement iterators" (BSIs). Grep for `^bsi' in the various `tree-*' 17475 files. The following snippet will pretty-print all the statements of 17476 the program in the GIMPLE representation. 17477 17478 FOR_EACH_BB (bb) 17479 { 17480 block_stmt_iterator si; 17481 17482 for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si)) 17483 { 17484 tree stmt = bsi_stmt (si); 17485 print_generic_stmt (stderr, stmt, 0); 17486 } 17487 } 17488 17489 17490 File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 17491 17492 15.2 Edges 17493 ========== 17494 17495 Edges represent possible control flow transfers from the end of some 17496 basic block A to the head of another basic block B. We say that A is a 17497 predecessor of B, and B is a successor of A. Edges are represented in 17498 GCC with the `edge' data type. Each `edge' acts as a link between two 17499 basic blocks: the `src' member of an edge points to the predecessor 17500 basic block of the `dest' basic block. The members `preds' and `succs' 17501 of the `basic_block' data type point to type-safe vectors of edges to 17502 the predecessors and successors of the block. 17503 17504 When walking the edges in an edge vector, "edge iterators" should be 17505 used. Edge iterators are constructed using the `edge_iterator' data 17506 structure and several methods are available to operate on them: 17507 17508 `ei_start' 17509 This function initializes an `edge_iterator' that points to the 17510 first edge in a vector of edges. 17511 17512 `ei_last' 17513 This function initializes an `edge_iterator' that points to the 17514 last edge in a vector of edges. 17515 17516 `ei_end_p' 17517 This predicate is `true' if an `edge_iterator' represents the last 17518 edge in an edge vector. 17519 17520 `ei_one_before_end_p' 17521 This predicate is `true' if an `edge_iterator' represents the 17522 second last edge in an edge vector. 17523 17524 `ei_next' 17525 This function takes a pointer to an `edge_iterator' and makes it 17526 point to the next edge in the sequence. 17527 17528 `ei_prev' 17529 This function takes a pointer to an `edge_iterator' and makes it 17530 point to the previous edge in the sequence. 17531 17532 `ei_edge' 17533 This function returns the `edge' currently pointed to by an 17534 `edge_iterator'. 17535 17536 `ei_safe_safe' 17537 This function returns the `edge' currently pointed to by an 17538 `edge_iterator', but returns `NULL' if the iterator is pointing at 17539 the end of the sequence. This function has been provided for 17540 existing code makes the assumption that a `NULL' edge indicates 17541 the end of the sequence. 17542 17543 17544 The convenience macro `FOR_EACH_EDGE' can be used to visit all of the 17545 edges in a sequence of predecessor or successor edges. It must not be 17546 used when an element might be removed during the traversal, otherwise 17547 elements will be missed. Here is an example of how to use the macro: 17548 17549 edge e; 17550 edge_iterator ei; 17551 17552 FOR_EACH_EDGE (e, ei, bb->succs) 17553 { 17554 if (e->flags & EDGE_FALLTHRU) 17555 break; 17556 } 17557 17558 There are various reasons why control flow may transfer from one block 17559 to another. One possibility is that some instruction, for example a 17560 `CODE_LABEL', in a linearized instruction stream just always starts a 17561 new basic block. In this case a "fall-thru" edge links the basic block 17562 to the first following basic block. But there are several other 17563 reasons why edges may be created. The `flags' field of the `edge' data 17564 type is used to store information about the type of edge we are dealing 17565 with. Each edge is of one of the following types: 17566 17567 _jump_ 17568 No type flags are set for edges corresponding to jump instructions. 17569 These edges are used for unconditional or conditional jumps and in 17570 RTL also for table jumps. They are the easiest to manipulate as 17571 they may be freely redirected when the flow graph is not in SSA 17572 form. 17573 17574 _fall-thru_ 17575 Fall-thru edges are present in case where the basic block may 17576 continue execution to the following one without branching. These 17577 edges have the `EDGE_FALLTHRU' flag set. Unlike other types of 17578 edges, these edges must come into the basic block immediately 17579 following in the instruction stream. The function 17580 `force_nonfallthru' is available to insert an unconditional jump 17581 in the case that redirection is needed. Note that this may 17582 require creation of a new basic block. 17583 17584 _exception handling_ 17585 Exception handling edges represent possible control transfers from 17586 a trapping instruction to an exception handler. The definition of 17587 "trapping" varies. In C++, only function calls can throw, but for 17588 Java, exceptions like division by zero or segmentation fault are 17589 defined and thus each instruction possibly throwing this kind of 17590 exception needs to be handled as control flow instruction. 17591 Exception edges have the `EDGE_ABNORMAL' and `EDGE_EH' flags set. 17592 17593 When updating the instruction stream it is easy to change possibly 17594 trapping instruction to non-trapping, by simply removing the 17595 exception edge. The opposite conversion is difficult, but should 17596 not happen anyway. The edges can be eliminated via 17597 `purge_dead_edges' call. 17598 17599 In the RTL representation, the destination of an exception edge is 17600 specified by `REG_EH_REGION' note attached to the insn. In case 17601 of a trapping call the `EDGE_ABNORMAL_CALL' flag is set too. In 17602 the `tree' representation, this extra flag is not set. 17603 17604 In the RTL representation, the predicate `may_trap_p' may be used 17605 to check whether instruction still may trap or not. For the tree 17606 representation, the `tree_could_trap_p' predicate is available, 17607 but this predicate only checks for possible memory traps, as in 17608 dereferencing an invalid pointer location. 17609 17610 _sibling calls_ 17611 Sibling calls or tail calls terminate the function in a 17612 non-standard way and thus an edge to the exit must be present. 17613 `EDGE_SIBCALL' and `EDGE_ABNORMAL' are set in such case. These 17614 edges only exist in the RTL representation. 17615 17616 _computed jumps_ 17617 Computed jumps contain edges to all labels in the function 17618 referenced from the code. All those edges have `EDGE_ABNORMAL' 17619 flag set. The edges used to represent computed jumps often cause 17620 compile time performance problems, since functions consisting of 17621 many taken labels and many computed jumps may have _very_ dense 17622 flow graphs, so these edges need to be handled with special care. 17623 During the earlier stages of the compilation process, GCC tries to 17624 avoid such dense flow graphs by factoring computed jumps. For 17625 example, given the following series of jumps, 17626 17627 goto *x; 17628 [ ... ] 17629 17630 goto *x; 17631 [ ... ] 17632 17633 goto *x; 17634 [ ... ] 17635 17636 factoring the computed jumps results in the following code sequence 17637 which has a much simpler flow graph: 17638 17639 goto y; 17640 [ ... ] 17641 17642 goto y; 17643 [ ... ] 17644 17645 goto y; 17646 [ ... ] 17647 17648 y: 17649 goto *x; 17650 17651 However, the classic problem with this transformation is that it 17652 has a runtime cost in there resulting code: An extra jump. 17653 Therefore, the computed jumps are un-factored in the later passes 17654 of the compiler. Be aware of that when you work on passes in that 17655 area. There have been numerous examples already where the compile 17656 time for code with unfactored computed jumps caused some serious 17657 headaches. 17658 17659 _nonlocal goto handlers_ 17660 GCC allows nested functions to return into caller using a `goto' 17661 to a label passed to as an argument to the callee. The labels 17662 passed to nested functions contain special code to cleanup after 17663 function call. Such sections of code are referred to as "nonlocal 17664 goto receivers". If a function contains such nonlocal goto 17665 receivers, an edge from the call to the label is created with the 17666 `EDGE_ABNORMAL' and `EDGE_ABNORMAL_CALL' flags set. 17667 17668 _function entry points_ 17669 By definition, execution of function starts at basic block 0, so 17670 there is always an edge from the `ENTRY_BLOCK_PTR' to basic block 17671 0. There is no `tree' representation for alternate entry points at 17672 this moment. In RTL, alternate entry points are specified by 17673 `CODE_LABEL' with `LABEL_ALTERNATE_NAME' defined. This feature is 17674 currently used for multiple entry point prologues and is limited 17675 to post-reload passes only. This can be used by back-ends to emit 17676 alternate prologues for functions called from different contexts. 17677 In future full support for multiple entry functions defined by 17678 Fortran 90 needs to be implemented. 17679 17680 _function exits_ 17681 In the pre-reload representation a function terminates after the 17682 last instruction in the insn chain and no explicit return 17683 instructions are used. This corresponds to the fall-thru edge 17684 into exit block. After reload, optimal RTL epilogues are used 17685 that use explicit (conditional) return instructions that are 17686 represented by edges with no flags set. 17687 17688 17689 17690 File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 17691 17692 15.3 Profile information 17693 ======================== 17694 17695 In many cases a compiler must make a choice whether to trade speed in 17696 one part of code for speed in another, or to trade code size for code 17697 speed. In such cases it is useful to know information about how often 17698 some given block will be executed. That is the purpose for maintaining 17699 profile within the flow graph. GCC can handle profile information 17700 obtained through "profile feedback", but it can also estimate branch 17701 probabilities based on statics and heuristics. 17702 17703 The feedback based profile is produced by compiling the program with 17704 instrumentation, executing it on a train run and reading the numbers of 17705 executions of basic blocks and edges back to the compiler while 17706 re-compiling the program to produce the final executable. This method 17707 provides very accurate information about where a program spends most of 17708 its time on the train run. Whether it matches the average run of 17709 course depends on the choice of train data set, but several studies 17710 have shown that the behavior of a program usually changes just 17711 marginally over different data sets. 17712 17713 When profile feedback is not available, the compiler may be asked to 17714 attempt to predict the behavior of each branch in the program using a 17715 set of heuristics (see `predict.def' for details) and compute estimated 17716 frequencies of each basic block by propagating the probabilities over 17717 the graph. 17718 17719 Each `basic_block' contains two integer fields to represent profile 17720 information: `frequency' and `count'. The `frequency' is an estimation 17721 how often is basic block executed within a function. It is represented 17722 as an integer scaled in the range from 0 to `BB_FREQ_BASE'. The most 17723 frequently executed basic block in function is initially set to 17724 `BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 17725 During optimization, the frequency of the most frequent basic block can 17726 both decrease (for instance by loop unrolling) or grow (for instance by 17727 cross-jumping optimization), so scaling sometimes has to be performed 17728 multiple times. 17729 17730 The `count' contains hard-counted numbers of execution measured during 17731 training runs and is nonzero only when profile feedback is available. 17732 This value is represented as the host's widest integer (typically a 64 17733 bit integer) of the special type `gcov_type'. 17734 17735 Most optimization passes can use only the frequency information of a 17736 basic block, but a few passes may want to know hard execution counts. 17737 The frequencies should always match the counts after scaling, however 17738 during updating of the profile information numerical error may 17739 accumulate into quite large errors. 17740 17741 Each edge also contains a branch probability field: an integer in the 17742 range from 0 to `REG_BR_PROB_BASE'. It represents probability of 17743 passing control from the end of the `src' basic block to the `dest' 17744 basic block, i.e. the probability that control will flow along this 17745 edge. The `EDGE_FREQUENCY' macro is available to compute how 17746 frequently a given edge is taken. There is a `count' field for each 17747 edge as well, representing same information as for a basic block. 17748 17749 The basic block frequencies are not represented in the instruction 17750 stream, but in the RTL representation the edge frequencies are 17751 represented for conditional jumps (via the `REG_BR_PROB' macro) since 17752 they are used when instructions are output to the assembly file and the 17753 flow graph is no longer maintained. 17754 17755 The probability that control flow arrives via a given edge to its 17756 destination basic block is called "reverse probability" and is not 17757 directly represented, but it may be easily computed from frequencies of 17758 basic blocks. 17759 17760 Updating profile information is a delicate task that can unfortunately 17761 not be easily integrated with the CFG manipulation API. Many of the 17762 functions and hooks to modify the CFG, such as 17763 `redirect_edge_and_branch', do not have enough information to easily 17764 update the profile, so updating it is in the majority of cases left up 17765 to the caller. It is difficult to uncover bugs in the profile updating 17766 code, because they manifest themselves only by producing worse code, 17767 and checking profile consistency is not possible because of numeric 17768 error accumulation. Hence special attention needs to be given to this 17769 issue in each pass that modifies the CFG. 17770 17771 It is important to point out that `REG_BR_PROB_BASE' and 17772 `BB_FREQ_BASE' are both set low enough to be possible to compute second 17773 power of any frequency or probability in the flow graph, it is not 17774 possible to even square the `count' field, as modern CPUs are fast 17775 enough to execute $2^32$ operations quickly. 17776 17777 17778 File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 17779 17780 15.4 Maintaining the CFG 17781 ======================== 17782 17783 An important task of each compiler pass is to keep both the control 17784 flow graph and all profile information up-to-date. Reconstruction of 17785 the control flow graph after each pass is not an option, since it may be 17786 very expensive and lost profile information cannot be reconstructed at 17787 all. 17788 17789 GCC has two major intermediate representations, and both use the 17790 `basic_block' and `edge' data types to represent control flow. Both 17791 representations share as much of the CFG maintenance code as possible. 17792 For each representation, a set of "hooks" is defined so that each 17793 representation can provide its own implementation of CFG manipulation 17794 routines when necessary. These hooks are defined in `cfghooks.h'. 17795 There are hooks for almost all common CFG manipulations, including 17796 block splitting and merging, edge redirection and creating and deleting 17797 basic blocks. These hooks should provide everything you need to 17798 maintain and manipulate the CFG in both the RTL and `tree' 17799 representation. 17800 17801 At the moment, the basic block boundaries are maintained transparently 17802 when modifying instructions, so there rarely is a need to move them 17803 manually (such as in case someone wants to output instruction outside 17804 basic block explicitly). Often the CFG may be better viewed as 17805 integral part of instruction chain, than structure built on the top of 17806 it. However, in principle the control flow graph for the `tree' 17807 representation is _not_ an integral part of the representation, in that 17808 a function tree may be expanded without first building a flow graph 17809 for the `tree' representation at all. This happens when compiling 17810 without any `tree' optimization enabled. When the `tree' optimizations 17811 are enabled and the instruction stream is rewritten in SSA form, the 17812 CFG is very tightly coupled with the instruction stream. In 17813 particular, statement insertion and removal has to be done with care. 17814 In fact, the whole `tree' representation can not be easily used or 17815 maintained without proper maintenance of the CFG simultaneously. 17816 17817 In the RTL representation, each instruction has a `BLOCK_FOR_INSN' 17818 value that represents pointer to the basic block that contains the 17819 instruction. In the `tree' representation, the function `bb_for_stmt' 17820 returns a pointer to the basic block containing the queried statement. 17821 17822 When changes need to be applied to a function in its `tree' 17823 representation, "block statement iterators" should be used. These 17824 iterators provide an integrated abstraction of the flow graph and the 17825 instruction stream. Block statement iterators are constructed using 17826 the `block_stmt_iterator' data structure and several modifier are 17827 available, including the following: 17828 17829 `bsi_start' 17830 This function initializes a `block_stmt_iterator' that points to 17831 the first non-empty statement in a basic block. 17832 17833 `bsi_last' 17834 This function initializes a `block_stmt_iterator' that points to 17835 the last statement in a basic block. 17836 17837 `bsi_end_p' 17838 This predicate is `true' if a `block_stmt_iterator' represents the 17839 end of a basic block. 17840 17841 `bsi_next' 17842 This function takes a `block_stmt_iterator' and makes it point to 17843 its successor. 17844 17845 `bsi_prev' 17846 This function takes a `block_stmt_iterator' and makes it point to 17847 its predecessor. 17848 17849 `bsi_insert_after' 17850 This function inserts a statement after the `block_stmt_iterator' 17851 passed in. The final parameter determines whether the statement 17852 iterator is updated to point to the newly inserted statement, or 17853 left pointing to the original statement. 17854 17855 `bsi_insert_before' 17856 This function inserts a statement before the `block_stmt_iterator' 17857 passed in. The final parameter determines whether the statement 17858 iterator is updated to point to the newly inserted statement, or 17859 left pointing to the original statement. 17860 17861 `bsi_remove' 17862 This function removes the `block_stmt_iterator' passed in and 17863 rechains the remaining statements in a basic block, if any. 17864 17865 In the RTL representation, the macros `BB_HEAD' and `BB_END' may be 17866 used to get the head and end `rtx' of a basic block. No abstract 17867 iterators are defined for traversing the insn chain, but you can just 17868 use `NEXT_INSN' and `PREV_INSN' instead. *Note Insns::. 17869 17870 Usually a code manipulating pass simplifies the instruction stream and 17871 the flow of control, possibly eliminating some edges. This may for 17872 example happen when a conditional jump is replaced with an 17873 unconditional jump, but also when simplifying possibly trapping 17874 instruction to non-trapping while compiling Java. Updating of edges is 17875 not transparent and each optimization pass is required to do so 17876 manually. However only few cases occur in practice. The pass may call 17877 `purge_dead_edges' on a given basic block to remove superfluous edges, 17878 if any. 17879 17880 Another common scenario is redirection of branch instructions, but 17881 this is best modeled as redirection of edges in the control flow graph 17882 and thus use of `redirect_edge_and_branch' is preferred over more low 17883 level functions, such as `redirect_jump' that operate on RTL chain 17884 only. The CFG hooks defined in `cfghooks.h' should provide the 17885 complete API required for manipulating and maintaining the CFG. 17886 17887 It is also possible that a pass has to insert control flow instruction 17888 into the middle of a basic block, thus creating an entry point in the 17889 middle of the basic block, which is impossible by definition: The block 17890 must be split to make sure it only has one entry point, i.e. the head 17891 of the basic block. The CFG hook `split_block' may be used when an 17892 instruction in the middle of a basic block has to become the target of 17893 a jump or branch instruction. 17894 17895 For a global optimizer, a common operation is to split edges in the 17896 flow graph and insert instructions on them. In the RTL representation, 17897 this can be easily done using the `insert_insn_on_edge' function that 17898 emits an instruction "on the edge", caching it for a later 17899 `commit_edge_insertions' call that will take care of moving the 17900 inserted instructions off the edge into the instruction stream 17901 contained in a basic block. This includes the creation of new basic 17902 blocks where needed. In the `tree' representation, the equivalent 17903 functions are `bsi_insert_on_edge' which inserts a block statement 17904 iterator on an edge, and `bsi_commit_edge_inserts' which flushes the 17905 instruction to actual instruction stream. 17906 17907 While debugging the optimization pass, a `verify_flow_info' function 17908 may be useful to find bugs in the control flow graph updating code. 17909 17910 Note that at present, the representation of control flow in the `tree' 17911 representation is discarded before expanding to RTL. Long term the CFG 17912 should be maintained and "expanded" to the RTL representation along 17913 with the function `tree' itself. 17914 17915 17916 File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 17917 17918 15.5 Liveness information 17919 ========================= 17920 17921 Liveness information is useful to determine whether some register is 17922 "live" at given point of program, i.e. that it contains a value that 17923 may be used at a later point in the program. This information is used, 17924 for instance, during register allocation, as the pseudo registers only 17925 need to be assigned to a unique hard register or to a stack slot if 17926 they are live. The hard registers and stack slots may be freely reused 17927 for other values when a register is dead. 17928 17929 Liveness information is available in the back end starting with 17930 `pass_df_initialize' and ending with `pass_df_finish'. Three flavors 17931 of live analysis are available: With `LR', it is possible to determine 17932 at any point `P' in the function if the register may be used on some 17933 path from `P' to the end of the function. With `UR', it is possible to 17934 determine if there is a path from the beginning of the function to `P' 17935 that defines the variable. `LIVE' is the intersection of the `LR' and 17936 `UR' and a variable is live at `P' if there is both an assignment that 17937 reaches it from the beginning of the function and a use that can be 17938 reached on some path from `P' to the end of the function. 17939 17940 In general `LIVE' is the most useful of the three. The macros 17941 `DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 17942 macros take a basic block number and return a bitmap that is indexed by 17943 the register number. This information is only guaranteed to be up to 17944 date after calls are made to `df_analyze'. See the file `df-core.c' 17945 for details on using the dataflow. 17946 17947 The liveness information is stored partly in the RTL instruction stream 17948 and partly in the flow graph. Local information is stored in the 17949 instruction stream: Each instruction may contain `REG_DEAD' notes 17950 representing that the value of a given register is no longer needed, or 17951 `REG_UNUSED' notes representing that the value computed by the 17952 instruction is never used. The second is useful for instructions 17953 computing multiple values at once. 17954 17955 17956 File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 17957 17958 16 Machine Descriptions 17959 *********************** 17960 17961 A machine description has two parts: a file of instruction patterns 17962 (`.md' file) and a C header file of macro definitions. 17963 17964 The `.md' file for a target machine contains a pattern for each 17965 instruction that the target machine supports (or at least each 17966 instruction that is worth telling the compiler about). It may also 17967 contain comments. A semicolon causes the rest of the line to be a 17968 comment, unless the semicolon is inside a quoted string. 17969 17970 See the next chapter for information on the C header file. 17971 17972 * Menu: 17973 17974 * Overview:: How the machine description is used. 17975 * Patterns:: How to write instruction patterns. 17976 * Example:: An explained example of a `define_insn' pattern. 17977 * RTL Template:: The RTL template defines what insns match a pattern. 17978 * Output Template:: The output template says how to make assembler code 17979 from such an insn. 17980 * Output Statement:: For more generality, write C code to output 17981 the assembler code. 17982 * Predicates:: Controlling what kinds of operands can be used 17983 for an insn. 17984 * Constraints:: Fine-tuning operand selection. 17985 * Standard Names:: Names mark patterns to use for code generation. 17986 * Pattern Ordering:: When the order of patterns makes a difference. 17987 * Dependent Patterns:: Having one pattern may make you need another. 17988 * Jump Patterns:: Special considerations for patterns for jump insns. 17989 * Looping Patterns:: How to define patterns for special looping insns. 17990 * Insn Canonicalizations::Canonicalization of Instructions 17991 * Expander Definitions::Generating a sequence of several RTL insns 17992 for a standard operation. 17993 * Insn Splitting:: Splitting Instructions into Multiple Instructions. 17994 * Including Patterns:: Including Patterns in Machine Descriptions. 17995 * Peephole Definitions::Defining machine-specific peephole optimizations. 17996 * Insn Attributes:: Specifying the value of attributes for generated insns. 17997 * Conditional Execution::Generating `define_insn' patterns for 17998 predication. 17999 * Constant Definitions::Defining symbolic constants that can be used in the 18000 md file. 18001 * Iterators:: Using iterators to generate patterns from a template. 18002 18003 18004 File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 18005 18006 16.1 Overview of How the Machine Description is Used 18007 ==================================================== 18008 18009 There are three main conversions that happen in the compiler: 18010 18011 1. The front end reads the source code and builds a parse tree. 18012 18013 2. The parse tree is used to generate an RTL insn list based on named 18014 instruction patterns. 18015 18016 3. The insn list is matched against the RTL templates to produce 18017 assembler code. 18018 18019 18020 For the generate pass, only the names of the insns matter, from either 18021 a named `define_insn' or a `define_expand'. The compiler will choose 18022 the pattern with the right name and apply the operands according to the 18023 documentation later in this chapter, without regard for the RTL 18024 template or operand constraints. Note that the names the compiler looks 18025 for are hard-coded in the compiler--it will ignore unnamed patterns and 18026 patterns with names it doesn't know about, but if you don't provide a 18027 named pattern it needs, it will abort. 18028 18029 If a `define_insn' is used, the template given is inserted into the 18030 insn list. If a `define_expand' is used, one of three things happens, 18031 based on the condition logic. The condition logic may manually create 18032 new insns for the insn list, say via `emit_insn()', and invoke `DONE'. 18033 For certain named patterns, it may invoke `FAIL' to tell the compiler 18034 to use an alternate way of performing that task. If it invokes neither 18035 `DONE' nor `FAIL', the template given in the pattern is inserted, as if 18036 the `define_expand' were a `define_insn'. 18037 18038 Once the insn list is generated, various optimization passes convert, 18039 replace, and rearrange the insns in the insn list. This is where the 18040 `define_split' and `define_peephole' patterns get used, for example. 18041 18042 Finally, the insn list's RTL is matched up with the RTL templates in 18043 the `define_insn' patterns, and those patterns are used to emit the 18044 final assembly code. For this purpose, each named `define_insn' acts 18045 like it's unnamed, since the names are ignored. 18046 18047 18048 File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 18049 18050 16.2 Everything about Instruction Patterns 18051 ========================================== 18052 18053 Each instruction pattern contains an incomplete RTL expression, with 18054 pieces to be filled in later, operand constraints that restrict how the 18055 pieces can be filled in, and an output pattern or C code to generate 18056 the assembler output, all wrapped up in a `define_insn' expression. 18057 18058 A `define_insn' is an RTL expression containing four or five operands: 18059 18060 1. An optional name. The presence of a name indicate that this 18061 instruction pattern can perform a certain standard job for the 18062 RTL-generation pass of the compiler. This pass knows certain 18063 names and will use the instruction patterns with those names, if 18064 the names are defined in the machine description. 18065 18066 The absence of a name is indicated by writing an empty string 18067 where the name should go. Nameless instruction patterns are never 18068 used for generating RTL code, but they may permit several simpler 18069 insns to be combined later on. 18070 18071 Names that are not thus known and used in RTL-generation have no 18072 effect; they are equivalent to no name at all. 18073 18074 For the purpose of debugging the compiler, you may also specify a 18075 name beginning with the `*' character. Such a name is used only 18076 for identifying the instruction in RTL dumps; it is entirely 18077 equivalent to having a nameless pattern for all other purposes. 18078 18079 2. The "RTL template" (*note RTL Template::) is a vector of incomplete 18080 RTL expressions which show what the instruction should look like. 18081 It is incomplete because it may contain `match_operand', 18082 `match_operator', and `match_dup' expressions that stand for 18083 operands of the instruction. 18084 18085 If the vector has only one element, that element is the template 18086 for the instruction pattern. If the vector has multiple elements, 18087 then the instruction pattern is a `parallel' expression containing 18088 the elements described. 18089 18090 3. A condition. This is a string which contains a C expression that 18091 is the final test to decide whether an insn body matches this 18092 pattern. 18093 18094 For a named pattern, the condition (if present) may not depend on 18095 the data in the insn being matched, but only the 18096 target-machine-type flags. The compiler needs to test these 18097 conditions during initialization in order to learn exactly which 18098 named instructions are available in a particular run. 18099 18100 For nameless patterns, the condition is applied only when matching 18101 an individual insn, and only after the insn has matched the 18102 pattern's recognition template. The insn's operands may be found 18103 in the vector `operands'. For an insn where the condition has 18104 once matched, it can't be used to control register allocation, for 18105 example by excluding certain hard registers or hard register 18106 combinations. 18107 18108 4. The "output template": a string that says how to output matching 18109 insns as assembler code. `%' in this string specifies where to 18110 substitute the value of an operand. *Note Output Template::. 18111 18112 When simple substitution isn't general enough, you can specify a 18113 piece of C code to compute the output. *Note Output Statement::. 18114 18115 5. Optionally, a vector containing the values of attributes for insns 18116 matching this pattern. *Note Insn Attributes::. 18117 18118 18119 File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 18120 18121 16.3 Example of `define_insn' 18122 ============================= 18123 18124 Here is an actual example of an instruction pattern, for the 18125 68000/68020. 18126 18127 (define_insn "tstsi" 18128 [(set (cc0) 18129 (match_operand:SI 0 "general_operand" "rm"))] 18130 "" 18131 "* 18132 { 18133 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18134 return \"tstl %0\"; 18135 return \"cmpl #0,%0\"; 18136 }") 18137 18138 This can also be written using braced strings: 18139 18140 (define_insn "tstsi" 18141 [(set (cc0) 18142 (match_operand:SI 0 "general_operand" "rm"))] 18143 "" 18144 { 18145 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18146 return "tstl %0"; 18147 return "cmpl #0,%0"; 18148 }) 18149 18150 This is an instruction that sets the condition codes based on the 18151 value of a general operand. It has no condition, so any insn whose RTL 18152 description has the form shown may be handled according to this 18153 pattern. The name `tstsi' means "test a `SImode' value" and tells the 18154 RTL generation pass that, when it is necessary to test such a value, an 18155 insn to do so can be constructed using this pattern. 18156 18157 The output control string is a piece of C code which chooses which 18158 output template to return based on the kind of operand and the specific 18159 type of CPU for which code is being generated. 18160 18161 `"rm"' is an operand constraint. Its meaning is explained below. 18162 18163 18164 File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 18165 18166 16.4 RTL Template 18167 ================= 18168 18169 The RTL template is used to define which insns match the particular 18170 pattern and how to find their operands. For named patterns, the RTL 18171 template also says how to construct an insn from specified operands. 18172 18173 Construction involves substituting specified operands into a copy of 18174 the template. Matching involves determining the values that serve as 18175 the operands in the insn being matched. Both of these activities are 18176 controlled by special expression types that direct matching and 18177 substitution of the operands. 18178 18179 `(match_operand:M N PREDICATE CONSTRAINT)' 18180 This expression is a placeholder for operand number N of the insn. 18181 When constructing an insn, operand number N will be substituted at 18182 this point. When matching an insn, whatever appears at this 18183 position in the insn will be taken as operand number N; but it 18184 must satisfy PREDICATE or this instruction pattern will not match 18185 at all. 18186 18187 Operand numbers must be chosen consecutively counting from zero in 18188 each instruction pattern. There may be only one `match_operand' 18189 expression in the pattern for each operand number. Usually 18190 operands are numbered in the order of appearance in `match_operand' 18191 expressions. In the case of a `define_expand', any operand numbers 18192 used only in `match_dup' expressions have higher values than all 18193 other operand numbers. 18194 18195 PREDICATE is a string that is the name of a function that accepts 18196 two arguments, an expression and a machine mode. *Note 18197 Predicates::. During matching, the function will be called with 18198 the putative operand as the expression and M as the mode argument 18199 (if M is not specified, `VOIDmode' will be used, which normally 18200 causes PREDICATE to accept any mode). If it returns zero, this 18201 instruction pattern fails to match. PREDICATE may be an empty 18202 string; then it means no test is to be done on the operand, so 18203 anything which occurs in this position is valid. 18204 18205 Most of the time, PREDICATE will reject modes other than M--but 18206 not always. For example, the predicate `address_operand' uses M 18207 as the mode of memory ref that the address should be valid for. 18208 Many predicates accept `const_int' nodes even though their mode is 18209 `VOIDmode'. 18210 18211 CONSTRAINT controls reloading and the choice of the best register 18212 class to use for a value, as explained later (*note Constraints::). 18213 If the constraint would be an empty string, it can be omitted. 18214 18215 People are often unclear on the difference between the constraint 18216 and the predicate. The predicate helps decide whether a given 18217 insn matches the pattern. The constraint plays no role in this 18218 decision; instead, it controls various decisions in the case of an 18219 insn which does match. 18220 18221 `(match_scratch:M N CONSTRAINT)' 18222 This expression is also a placeholder for operand number N and 18223 indicates that operand must be a `scratch' or `reg' expression. 18224 18225 When matching patterns, this is equivalent to 18226 18227 (match_operand:M N "scratch_operand" PRED) 18228 18229 but, when generating RTL, it produces a (`scratch':M) expression. 18230 18231 If the last few expressions in a `parallel' are `clobber' 18232 expressions whose operands are either a hard register or 18233 `match_scratch', the combiner can add or delete them when 18234 necessary. *Note Side Effects::. 18235 18236 `(match_dup N)' 18237 This expression is also a placeholder for operand number N. It is 18238 used when the operand needs to appear more than once in the insn. 18239 18240 In construction, `match_dup' acts just like `match_operand': the 18241 operand is substituted into the insn being constructed. But in 18242 matching, `match_dup' behaves differently. It assumes that operand 18243 number N has already been determined by a `match_operand' 18244 appearing earlier in the recognition template, and it matches only 18245 an identical-looking expression. 18246 18247 Note that `match_dup' should not be used to tell the compiler that 18248 a particular register is being used for two operands (example: 18249 `add' that adds one register to another; the second register is 18250 both an input operand and the output operand). Use a matching 18251 constraint (*note Simple Constraints::) for those. `match_dup' is 18252 for the cases where one operand is used in two places in the 18253 template, such as an instruction that computes both a quotient and 18254 a remainder, where the opcode takes two input operands but the RTL 18255 template has to refer to each of those twice; once for the 18256 quotient pattern and once for the remainder pattern. 18257 18258 `(match_operator:M N PREDICATE [OPERANDS...])' 18259 This pattern is a kind of placeholder for a variable RTL expression 18260 code. 18261 18262 When constructing an insn, it stands for an RTL expression whose 18263 expression code is taken from that of operand N, and whose 18264 operands are constructed from the patterns OPERANDS. 18265 18266 When matching an expression, it matches an expression if the 18267 function PREDICATE returns nonzero on that expression _and_ the 18268 patterns OPERANDS match the operands of the expression. 18269 18270 Suppose that the function `commutative_operator' is defined as 18271 follows, to match any expression whose operator is one of the 18272 commutative arithmetic operators of RTL and whose mode is MODE: 18273 18274 int 18275 commutative_integer_operator (x, mode) 18276 rtx x; 18277 enum machine_mode mode; 18278 { 18279 enum rtx_code code = GET_CODE (x); 18280 if (GET_MODE (x) != mode) 18281 return 0; 18282 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 18283 || code == EQ || code == NE); 18284 } 18285 18286 Then the following pattern will match any RTL expression consisting 18287 of a commutative operator applied to two general operands: 18288 18289 (match_operator:SI 3 "commutative_operator" 18290 [(match_operand:SI 1 "general_operand" "g") 18291 (match_operand:SI 2 "general_operand" "g")]) 18292 18293 Here the vector `[OPERANDS...]' contains two patterns because the 18294 expressions to be matched all contain two operands. 18295 18296 When this pattern does match, the two operands of the commutative 18297 operator are recorded as operands 1 and 2 of the insn. (This is 18298 done by the two instances of `match_operand'.) Operand 3 of the 18299 insn will be the entire commutative expression: use `GET_CODE 18300 (operands[3])' to see which commutative operator was used. 18301 18302 The machine mode M of `match_operator' works like that of 18303 `match_operand': it is passed as the second argument to the 18304 predicate function, and that function is solely responsible for 18305 deciding whether the expression to be matched "has" that mode. 18306 18307 When constructing an insn, argument 3 of the gen-function will 18308 specify the operation (i.e. the expression code) for the 18309 expression to be made. It should be an RTL expression, whose 18310 expression code is copied into a new expression whose operands are 18311 arguments 1 and 2 of the gen-function. The subexpressions of 18312 argument 3 are not used; only its expression code matters. 18313 18314 When `match_operator' is used in a pattern for matching an insn, 18315 it usually best if the operand number of the `match_operator' is 18316 higher than that of the actual operands of the insn. This improves 18317 register allocation because the register allocator often looks at 18318 operands 1 and 2 of insns to see if it can do register tying. 18319 18320 There is no way to specify constraints in `match_operator'. The 18321 operand of the insn which corresponds to the `match_operator' 18322 never has any constraints because it is never reloaded as a whole. 18323 However, if parts of its OPERANDS are matched by `match_operand' 18324 patterns, those parts may have constraints of their own. 18325 18326 `(match_op_dup:M N[OPERANDS...])' 18327 Like `match_dup', except that it applies to operators instead of 18328 operands. When constructing an insn, operand number N will be 18329 substituted at this point. But in matching, `match_op_dup' behaves 18330 differently. It assumes that operand number N has already been 18331 determined by a `match_operator' appearing earlier in the 18332 recognition template, and it matches only an identical-looking 18333 expression. 18334 18335 `(match_parallel N PREDICATE [SUBPAT...])' 18336 This pattern is a placeholder for an insn that consists of a 18337 `parallel' expression with a variable number of elements. This 18338 expression should only appear at the top level of an insn pattern. 18339 18340 When constructing an insn, operand number N will be substituted at 18341 this point. When matching an insn, it matches if the body of the 18342 insn is a `parallel' expression with at least as many elements as 18343 the vector of SUBPAT expressions in the `match_parallel', if each 18344 SUBPAT matches the corresponding element of the `parallel', _and_ 18345 the function PREDICATE returns nonzero on the `parallel' that is 18346 the body of the insn. It is the responsibility of the predicate 18347 to validate elements of the `parallel' beyond those listed in the 18348 `match_parallel'. 18349 18350 A typical use of `match_parallel' is to match load and store 18351 multiple expressions, which can contain a variable number of 18352 elements in a `parallel'. For example, 18353 18354 (define_insn "" 18355 [(match_parallel 0 "load_multiple_operation" 18356 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 18357 (match_operand:SI 2 "memory_operand" "m")) 18358 (use (reg:SI 179)) 18359 (clobber (reg:SI 179))])] 18360 "" 18361 "loadm 0,0,%1,%2") 18362 18363 This example comes from `a29k.md'. The function 18364 `load_multiple_operation' is defined in `a29k.c' and checks that 18365 subsequent elements in the `parallel' are the same as the `set' in 18366 the pattern, except that they are referencing subsequent registers 18367 and memory locations. 18368 18369 An insn that matches this pattern might look like: 18370 18371 (parallel 18372 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 18373 (use (reg:SI 179)) 18374 (clobber (reg:SI 179)) 18375 (set (reg:SI 21) 18376 (mem:SI (plus:SI (reg:SI 100) 18377 (const_int 4)))) 18378 (set (reg:SI 22) 18379 (mem:SI (plus:SI (reg:SI 100) 18380 (const_int 8))))]) 18381 18382 `(match_par_dup N [SUBPAT...])' 18383 Like `match_op_dup', but for `match_parallel' instead of 18384 `match_operator'. 18385 18386 18387 18388 File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 18389 18390 16.5 Output Templates and Operand Substitution 18391 ============================================== 18392 18393 The "output template" is a string which specifies how to output the 18394 assembler code for an instruction pattern. Most of the template is a 18395 fixed string which is output literally. The character `%' is used to 18396 specify where to substitute an operand; it can also be used to identify 18397 places where different variants of the assembler require different 18398 syntax. 18399 18400 In the simplest case, a `%' followed by a digit N says to output 18401 operand N at that point in the string. 18402 18403 `%' followed by a letter and a digit says to output an operand in an 18404 alternate fashion. Four letters have standard, built-in meanings 18405 described below. The machine description macro `PRINT_OPERAND' can 18406 define additional letters with nonstandard meanings. 18407 18408 `%cDIGIT' can be used to substitute an operand that is a constant 18409 value without the syntax that normally indicates an immediate operand. 18410 18411 `%nDIGIT' is like `%cDIGIT' except that the value of the constant is 18412 negated before printing. 18413 18414 `%aDIGIT' can be used to substitute an operand as if it were a memory 18415 reference, with the actual operand treated as the address. This may be 18416 useful when outputting a "load address" instruction, because often the 18417 assembler syntax for such an instruction requires you to write the 18418 operand as if it were a memory reference. 18419 18420 `%lDIGIT' is used to substitute a `label_ref' into a jump instruction. 18421 18422 `%=' outputs a number which is unique to each instruction in the 18423 entire compilation. This is useful for making local labels to be 18424 referred to more than once in a single template that generates multiple 18425 assembler instructions. 18426 18427 `%' followed by a punctuation character specifies a substitution that 18428 does not use an operand. Only one case is standard: `%%' outputs a `%' 18429 into the assembler code. Other nonstandard cases can be defined in the 18430 `PRINT_OPERAND' macro. You must also define which punctuation 18431 characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. 18432 18433 The template may generate multiple assembler instructions. Write the 18434 text for the instructions, with `\;' between them. 18435 18436 When the RTL contains two operands which are required by constraint to 18437 match each other, the output template must refer only to the 18438 lower-numbered operand. Matching operands are not always identical, 18439 and the rest of the compiler arranges to put the proper RTL expression 18440 for printing into the lower-numbered operand. 18441 18442 One use of nonstandard letters or punctuation following `%' is to 18443 distinguish between different assembler languages for the same machine; 18444 for example, Motorola syntax versus MIT syntax for the 68000. Motorola 18445 syntax requires periods in most opcode names, while MIT syntax does 18446 not. For example, the opcode `movel' in MIT syntax is `move.l' in 18447 Motorola syntax. The same file of patterns is used for both kinds of 18448 output syntax, but the character sequence `%.' is used in each place 18449 where Motorola syntax wants a period. The `PRINT_OPERAND' macro for 18450 Motorola syntax defines the sequence to output a period; the macro for 18451 MIT syntax defines it to do nothing. 18452 18453 As a special case, a template consisting of the single character `#' 18454 instructs the compiler to first split the insn, and then output the 18455 resulting instructions separately. This helps eliminate redundancy in 18456 the output templates. If you have a `define_insn' that needs to emit 18457 multiple assembler instructions, and there is a matching `define_split' 18458 already defined, then you can simply use `#' as the output template 18459 instead of writing an output template that emits the multiple assembler 18460 instructions. 18461 18462 If the macro `ASSEMBLER_DIALECT' is defined, you can use construct of 18463 the form `{option0|option1|option2}' in the templates. These describe 18464 multiple variants of assembler language syntax. *Note Instruction 18465 Output::. 18466 18467 18468 File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 18469 18470 16.6 C Statements for Assembler Output 18471 ====================================== 18472 18473 Often a single fixed template string cannot produce correct and 18474 efficient assembler code for all the cases that are recognized by a 18475 single instruction pattern. For example, the opcodes may depend on the 18476 kinds of operands; or some unfortunate combinations of operands may 18477 require extra machine instructions. 18478 18479 If the output control string starts with a `@', then it is actually a 18480 series of templates, each on a separate line. (Blank lines and leading 18481 spaces and tabs are ignored.) The templates correspond to the 18482 pattern's constraint alternatives (*note Multi-Alternative::). For 18483 example, if a target machine has a two-address add instruction `addr' 18484 to add into a register and another `addm' to add a register to memory, 18485 you might write this pattern: 18486 18487 (define_insn "addsi3" 18488 [(set (match_operand:SI 0 "general_operand" "=r,m") 18489 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 18490 (match_operand:SI 2 "general_operand" "g,r")))] 18491 "" 18492 "@ 18493 addr %2,%0 18494 addm %2,%0") 18495 18496 If the output control string starts with a `*', then it is not an 18497 output template but rather a piece of C program that should compute a 18498 template. It should execute a `return' statement to return the 18499 template-string you want. Most such templates use C string literals, 18500 which require doublequote characters to delimit them. To include these 18501 doublequote characters in the string, prefix each one with `\'. 18502 18503 If the output control string is written as a brace block instead of a 18504 double-quoted string, it is automatically assumed to be C code. In that 18505 case, it is not necessary to put in a leading asterisk, or to escape the 18506 doublequotes surrounding C string literals. 18507 18508 The operands may be found in the array `operands', whose C data type 18509 is `rtx []'. 18510 18511 It is very common to select different ways of generating assembler code 18512 based on whether an immediate operand is within a certain range. Be 18513 careful when doing this, because the result of `INTVAL' is an integer 18514 on the host machine. If the host machine has more bits in an `int' 18515 than the target machine has in the mode in which the constant will be 18516 used, then some of the bits you get from `INTVAL' will be superfluous. 18517 For proper results, you must carefully disregard the values of those 18518 bits. 18519 18520 It is possible to output an assembler instruction and then go on to 18521 output or compute more of them, using the subroutine `output_asm_insn'. 18522 This receives two arguments: a template-string and a vector of 18523 operands. The vector may be `operands', or it may be another array of 18524 `rtx' that you declare locally and initialize yourself. 18525 18526 When an insn pattern has multiple alternatives in its constraints, 18527 often the appearance of the assembler code is determined mostly by 18528 which alternative was matched. When this is so, the C code can test 18529 the variable `which_alternative', which is the ordinal number of the 18530 alternative that was actually satisfied (0 for the first, 1 for the 18531 second alternative, etc.). 18532 18533 For example, suppose there are two opcodes for storing zero, `clrreg' 18534 for registers and `clrmem' for memory locations. Here is how a pattern 18535 could use `which_alternative' to choose between them: 18536 18537 (define_insn "" 18538 [(set (match_operand:SI 0 "general_operand" "=r,m") 18539 (const_int 0))] 18540 "" 18541 { 18542 return (which_alternative == 0 18543 ? "clrreg %0" : "clrmem %0"); 18544 }) 18545 18546 The example above, where the assembler code to generate was _solely_ 18547 determined by the alternative, could also have been specified as 18548 follows, having the output control string start with a `@': 18549 18550 (define_insn "" 18551 [(set (match_operand:SI 0 "general_operand" "=r,m") 18552 (const_int 0))] 18553 "" 18554 "@ 18555 clrreg %0 18556 clrmem %0") 18557 18558 18559 File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 18560 18561 16.7 Predicates 18562 =============== 18563 18564 A predicate determines whether a `match_operand' or `match_operator' 18565 expression matches, and therefore whether the surrounding instruction 18566 pattern will be used for that combination of operands. GCC has a 18567 number of machine-independent predicates, and you can define 18568 machine-specific predicates as needed. By convention, predicates used 18569 with `match_operand' have names that end in `_operand', and those used 18570 with `match_operator' have names that end in `_operator'. 18571 18572 All predicates are Boolean functions (in the mathematical sense) of 18573 two arguments: the RTL expression that is being considered at that 18574 position in the instruction pattern, and the machine mode that the 18575 `match_operand' or `match_operator' specifies. In this section, the 18576 first argument is called OP and the second argument MODE. Predicates 18577 can be called from C as ordinary two-argument functions; this can be 18578 useful in output templates or other machine-specific code. 18579 18580 Operand predicates can allow operands that are not actually acceptable 18581 to the hardware, as long as the constraints give reload the ability to 18582 fix them up (*note Constraints::). However, GCC will usually generate 18583 better code if the predicates specify the requirements of the machine 18584 instructions as closely as possible. Reload cannot fix up operands 18585 that must be constants ("immediate operands"); you must use a predicate 18586 that allows only constants, or else enforce the requirement in the 18587 extra condition. 18588 18589 Most predicates handle their MODE argument in a uniform manner. If 18590 MODE is `VOIDmode' (unspecified), then OP can have any mode. If MODE 18591 is anything else, then OP must have the same mode, unless OP is a 18592 `CONST_INT' or integer `CONST_DOUBLE'. These RTL expressions always 18593 have `VOIDmode', so it would be counterproductive to check that their 18594 mode matches. Instead, predicates that accept `CONST_INT' and/or 18595 integer `CONST_DOUBLE' check that the value stored in the constant will 18596 fit in the requested mode. 18597 18598 Predicates with this behavior are called "normal". `genrecog' can 18599 optimize the instruction recognizer based on knowledge of how normal 18600 predicates treat modes. It can also diagnose certain kinds of common 18601 errors in the use of normal predicates; for instance, it is almost 18602 always an error to use a normal predicate without specifying a mode. 18603 18604 Predicates that do something different with their MODE argument are 18605 called "special". The generic predicates `address_operand' and 18606 `pmode_register_operand' are special predicates. `genrecog' does not 18607 do any optimizations or diagnosis when special predicates are used. 18608 18609 * Menu: 18610 18611 * Machine-Independent Predicates:: Predicates available to all back ends. 18612 * Defining Predicates:: How to write machine-specific predicate 18613 functions. 18614 18615 18616 File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 18617 18618 16.7.1 Machine-Independent Predicates 18619 ------------------------------------- 18620 18621 These are the generic predicates available to all back ends. They are 18622 defined in `recog.c'. The first category of predicates allow only 18623 constant, or "immediate", operands. 18624 18625 -- Function: immediate_operand 18626 This predicate allows any sort of constant that fits in MODE. It 18627 is an appropriate choice for instructions that take operands that 18628 must be constant. 18629 18630 -- Function: const_int_operand 18631 This predicate allows any `CONST_INT' expression that fits in 18632 MODE. It is an appropriate choice for an immediate operand that 18633 does not allow a symbol or label. 18634 18635 -- Function: const_double_operand 18636 This predicate accepts any `CONST_DOUBLE' expression that has 18637 exactly MODE. If MODE is `VOIDmode', it will also accept 18638 `CONST_INT'. It is intended for immediate floating point 18639 constants. 18640 18641 The second category of predicates allow only some kind of machine 18642 register. 18643 18644 -- Function: register_operand 18645 This predicate allows any `REG' or `SUBREG' expression that is 18646 valid for MODE. It is often suitable for arithmetic instruction 18647 operands on a RISC machine. 18648 18649 -- Function: pmode_register_operand 18650 This is a slight variant on `register_operand' which works around 18651 a limitation in the machine-description reader. 18652 18653 (match_operand N "pmode_register_operand" CONSTRAINT) 18654 18655 means exactly what 18656 18657 (match_operand:P N "register_operand" CONSTRAINT) 18658 18659 would mean, if the machine-description reader accepted `:P' mode 18660 suffixes. Unfortunately, it cannot, because `Pmode' is an alias 18661 for some other mode, and might vary with machine-specific options. 18662 *Note Misc::. 18663 18664 -- Function: scratch_operand 18665 This predicate allows hard registers and `SCRATCH' expressions, 18666 but not pseudo-registers. It is used internally by 18667 `match_scratch'; it should not be used directly. 18668 18669 The third category of predicates allow only some kind of memory 18670 reference. 18671 18672 -- Function: memory_operand 18673 This predicate allows any valid reference to a quantity of mode 18674 MODE in memory, as determined by the weak form of 18675 `GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 18676 18677 -- Function: address_operand 18678 This predicate is a little unusual; it allows any operand that is a 18679 valid expression for the _address_ of a quantity of mode MODE, 18680 again determined by the weak form of `GO_IF_LEGITIMATE_ADDRESS'. 18681 To first order, if `(mem:MODE (EXP))' is acceptable to 18682 `memory_operand', then EXP is acceptable to `address_operand'. 18683 Note that EXP does not necessarily have the mode MODE. 18684 18685 -- Function: indirect_operand 18686 This is a stricter form of `memory_operand' which allows only 18687 memory references with a `general_operand' as the address 18688 expression. New uses of this predicate are discouraged, because 18689 `general_operand' is very permissive, so it's hard to tell what an 18690 `indirect_operand' does or does not allow. If a target has 18691 different requirements for memory operands for different 18692 instructions, it is better to define target-specific predicates 18693 which enforce the hardware's requirements explicitly. 18694 18695 -- Function: push_operand 18696 This predicate allows a memory reference suitable for pushing a 18697 value onto the stack. This will be a `MEM' which refers to 18698 `stack_pointer_rtx', with a side-effect in its address expression 18699 (*note Incdec::); which one is determined by the `STACK_PUSH_CODE' 18700 macro (*note Frame Layout::). 18701 18702 -- Function: pop_operand 18703 This predicate allows a memory reference suitable for popping a 18704 value off the stack. Again, this will be a `MEM' referring to 18705 `stack_pointer_rtx', with a side-effect in its address expression. 18706 However, this time `STACK_POP_CODE' is expected. 18707 18708 The fourth category of predicates allow some combination of the above 18709 operands. 18710 18711 -- Function: nonmemory_operand 18712 This predicate allows any immediate or register operand valid for 18713 MODE. 18714 18715 -- Function: nonimmediate_operand 18716 This predicate allows any register or memory operand valid for 18717 MODE. 18718 18719 -- Function: general_operand 18720 This predicate allows any immediate, register, or memory operand 18721 valid for MODE. 18722 18723 Finally, there are two generic operator predicates. 18724 18725 -- Function: comparison_operator 18726 This predicate matches any expression which performs an arithmetic 18727 comparison in MODE; that is, `COMPARISON_P' is true for the 18728 expression code. 18729 18730 -- Function: ordered_comparison_operator 18731 This predicate matches any expression which performs an arithmetic 18732 comparison in MODE and whose expression code is valid for integer 18733 modes; that is, the expression code will be one of `eq', `ne', 18734 `lt', `ltu', `le', `leu', `gt', `gtu', `ge', `geu'. 18735 18736 18737 File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 18738 18739 16.7.2 Defining Machine-Specific Predicates 18740 ------------------------------------------- 18741 18742 Many machines have requirements for their operands that cannot be 18743 expressed precisely using the generic predicates. You can define 18744 additional predicates using `define_predicate' and 18745 `define_special_predicate' expressions. These expressions have three 18746 operands: 18747 18748 * The name of the predicate, as it will be referred to in 18749 `match_operand' or `match_operator' expressions. 18750 18751 * An RTL expression which evaluates to true if the predicate allows 18752 the operand OP, false if it does not. This expression can only use 18753 the following RTL codes: 18754 18755 `MATCH_OPERAND' 18756 When written inside a predicate expression, a `MATCH_OPERAND' 18757 expression evaluates to true if the predicate it names would 18758 allow OP. The operand number and constraint are ignored. 18759 Due to limitations in `genrecog', you can only refer to 18760 generic predicates and predicates that have already been 18761 defined. 18762 18763 `MATCH_CODE' 18764 This expression evaluates to true if OP or a specified 18765 subexpression of OP has one of a given list of RTX codes. 18766 18767 The first operand of this expression is a string constant 18768 containing a comma-separated list of RTX code names (in lower 18769 case). These are the codes for which the `MATCH_CODE' will 18770 be true. 18771 18772 The second operand is a string constant which indicates what 18773 subexpression of OP to examine. If it is absent or the empty 18774 string, OP itself is examined. Otherwise, the string constant 18775 must be a sequence of digits and/or lowercase letters. Each 18776 character indicates a subexpression to extract from the 18777 current expression; for the first character this is OP, for 18778 the second and subsequent characters it is the result of the 18779 previous character. A digit N extracts `XEXP (E, N)'; a 18780 letter L extracts `XVECEXP (E, 0, N)' where N is the 18781 alphabetic ordinal of L (0 for `a', 1 for 'b', and so on). 18782 The `MATCH_CODE' then examines the RTX code of the 18783 subexpression extracted by the complete string. It is not 18784 possible to extract components of an `rtvec' that is not at 18785 position 0 within its RTX object. 18786 18787 `MATCH_TEST' 18788 This expression has one operand, a string constant containing 18789 a C expression. The predicate's arguments, OP and MODE, are 18790 available with those names in the C expression. The 18791 `MATCH_TEST' evaluates to true if the C expression evaluates 18792 to a nonzero value. `MATCH_TEST' expressions must not have 18793 side effects. 18794 18795 `AND' 18796 `IOR' 18797 `NOT' 18798 `IF_THEN_ELSE' 18799 The basic `MATCH_' expressions can be combined using these 18800 logical operators, which have the semantics of the C operators 18801 `&&', `||', `!', and `? :' respectively. As in Common Lisp, 18802 you may give an `AND' or `IOR' expression an arbitrary number 18803 of arguments; this has exactly the same effect as writing a 18804 chain of two-argument `AND' or `IOR' expressions. 18805 18806 * An optional block of C code, which should execute `return true' if 18807 the predicate is found to match and `return false' if it does not. 18808 It must not have any side effects. The predicate arguments, OP 18809 and MODE, are available with those names. 18810 18811 If a code block is present in a predicate definition, then the RTL 18812 expression must evaluate to true _and_ the code block must execute 18813 `return true' for the predicate to allow the operand. The RTL 18814 expression is evaluated first; do not re-check anything in the 18815 code block that was checked in the RTL expression. 18816 18817 The program `genrecog' scans `define_predicate' and 18818 `define_special_predicate' expressions to determine which RTX codes are 18819 possibly allowed. You should always make this explicit in the RTL 18820 predicate expression, using `MATCH_OPERAND' and `MATCH_CODE'. 18821 18822 Here is an example of a simple predicate definition, from the IA64 18823 machine description: 18824 18825 ;; True if OP is a `SYMBOL_REF' which refers to the sdata section. 18826 (define_predicate "small_addr_symbolic_operand" 18827 (and (match_code "symbol_ref") 18828 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 18829 18830 And here is another, showing the use of the C block. 18831 18832 ;; True if OP is a register operand that is (or could be) a GR reg. 18833 (define_predicate "gr_register_operand" 18834 (match_operand 0 "register_operand") 18835 { 18836 unsigned int regno; 18837 if (GET_CODE (op) == SUBREG) 18838 op = SUBREG_REG (op); 18839 18840 regno = REGNO (op); 18841 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 18842 }) 18843 18844 Predicates written with `define_predicate' automatically include a 18845 test that MODE is `VOIDmode', or OP has the same mode as MODE, or OP is 18846 a `CONST_INT' or `CONST_DOUBLE'. They do _not_ check specifically for 18847 integer `CONST_DOUBLE', nor do they test that the value of either kind 18848 of constant fits in the requested mode. This is because 18849 target-specific predicates that take constants usually have to do more 18850 stringent value checks anyway. If you need the exact same treatment of 18851 `CONST_INT' or `CONST_DOUBLE' that the generic predicates provide, use 18852 a `MATCH_OPERAND' subexpression to call `const_int_operand', 18853 `const_double_operand', or `immediate_operand'. 18854 18855 Predicates written with `define_special_predicate' do not get any 18856 automatic mode checks, and are treated as having special mode handling 18857 by `genrecog'. 18858 18859 The program `genpreds' is responsible for generating code to test 18860 predicates. It also writes a header file containing function 18861 declarations for all machine-specific predicates. It is not necessary 18862 to declare these predicates in `CPU-protos.h'. 18863 18864 18865 File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 18866 18867 16.8 Operand Constraints 18868 ======================== 18869 18870 Each `match_operand' in an instruction pattern can specify constraints 18871 for the operands allowed. The constraints allow you to fine-tune 18872 matching within the set of operands allowed by the predicate. 18873 18874 Constraints can say whether an operand may be in a register, and which 18875 kinds of register; whether the operand can be a memory reference, and 18876 which kinds of address; whether the operand may be an immediate 18877 constant, and which possible values it may have. Constraints can also 18878 require two operands to match. Side-effects aren't allowed in operands 18879 of inline `asm', unless `<' or `>' constraints are used, because there 18880 is no guarantee that the side-effects will happen exactly once in an 18881 instruction that can update the addressing register. 18882 18883 * Menu: 18884 18885 * Simple Constraints:: Basic use of constraints. 18886 * Multi-Alternative:: When an insn has two alternative constraint-patterns. 18887 * Class Preferences:: Constraints guide which hard register to put things in. 18888 * Modifiers:: More precise control over effects of constraints. 18889 * Disable Insn Alternatives:: Disable insn alternatives using the `enabled' attribute. 18890 * Machine Constraints:: Existing constraints for some particular machines. 18891 * Define Constraints:: How to define machine-specific constraints. 18892 * C Constraint Interface:: How to test constraints from C code. 18893 18894 18895 File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 18896 18897 16.8.1 Simple Constraints 18898 ------------------------- 18899 18900 The simplest kind of constraint is a string full of letters, each of 18901 which describes one kind of operand that is permitted. Here are the 18902 letters that are allowed: 18903 18904 whitespace 18905 Whitespace characters are ignored and can be inserted at any 18906 position except the first. This enables each alternative for 18907 different operands to be visually aligned in the machine 18908 description even if they have different number of constraints and 18909 modifiers. 18910 18911 `m' 18912 A memory operand is allowed, with any kind of address that the 18913 machine supports in general. Note that the letter used for the 18914 general memory constraint can be re-defined by a back end using 18915 the `TARGET_MEM_CONSTRAINT' macro. 18916 18917 `o' 18918 A memory operand is allowed, but only if the address is 18919 "offsettable". This means that adding a small integer (actually, 18920 the width in bytes of the operand, as determined by its machine 18921 mode) may be added to the address and the result is also a valid 18922 memory address. 18923 18924 For example, an address which is constant is offsettable; so is an 18925 address that is the sum of a register and a constant (as long as a 18926 slightly larger constant is also within the range of 18927 address-offsets supported by the machine); but an autoincrement or 18928 autodecrement address is not offsettable. More complicated 18929 indirect/indexed addresses may or may not be offsettable depending 18930 on the other addressing modes that the machine supports. 18931 18932 Note that in an output operand which can be matched by another 18933 operand, the constraint letter `o' is valid only when accompanied 18934 by both `<' (if the target machine has predecrement addressing) 18935 and `>' (if the target machine has preincrement addressing). 18936 18937 `V' 18938 A memory operand that is not offsettable. In other words, 18939 anything that would fit the `m' constraint but not the `o' 18940 constraint. 18941 18942 `<' 18943 A memory operand with autodecrement addressing (either 18944 predecrement or postdecrement) is allowed. In inline `asm' this 18945 constraint is only allowed if the operand is used exactly once in 18946 an instruction that can handle the side-effects. Not using an 18947 operand with `<' in constraint string in the inline `asm' pattern 18948 at all or using it in multiple instructions isn't valid, because 18949 the side-effects wouldn't be performed or would be performed more 18950 than once. Furthermore, on some targets the operand with `<' in 18951 constraint string must be accompanied by special instruction 18952 suffixes like `%U0' instruction suffix on PowerPC or `%P0' on 18953 IA-64. 18954 18955 `>' 18956 A memory operand with autoincrement addressing (either 18957 preincrement or postincrement) is allowed. In inline `asm' the 18958 same restrictions as for `<' apply. 18959 18960 `r' 18961 A register operand is allowed provided that it is in a general 18962 register. 18963 18964 `i' 18965 An immediate integer operand (one with constant value) is allowed. 18966 This includes symbolic constants whose values will be known only at 18967 assembly time or later. 18968 18969 `n' 18970 An immediate integer operand with a known numeric value is allowed. 18971 Many systems cannot support assembly-time constants for operands 18972 less than a word wide. Constraints for these operands should use 18973 `n' rather than `i'. 18974 18975 `I', `J', `K', ... `P' 18976 Other letters in the range `I' through `P' may be defined in a 18977 machine-dependent fashion to permit immediate integer operands with 18978 explicit integer values in specified ranges. For example, on the 18979 68000, `I' is defined to stand for the range of values 1 to 8. 18980 This is the range permitted as a shift count in the shift 18981 instructions. 18982 18983 `E' 18984 An immediate floating operand (expression code `const_double') is 18985 allowed, but only if the target floating point format is the same 18986 as that of the host machine (on which the compiler is running). 18987 18988 `F' 18989 An immediate floating operand (expression code `const_double' or 18990 `const_vector') is allowed. 18991 18992 `G', `H' 18993 `G' and `H' may be defined in a machine-dependent fashion to 18994 permit immediate floating operands in particular ranges of values. 18995 18996 `s' 18997 An immediate integer operand whose value is not an explicit 18998 integer is allowed. 18999 19000 This might appear strange; if an insn allows a constant operand 19001 with a value not known at compile time, it certainly must allow 19002 any known value. So why use `s' instead of `i'? Sometimes it 19003 allows better code to be generated. 19004 19005 For example, on the 68000 in a fullword instruction it is possible 19006 to use an immediate operand; but if the immediate value is between 19007 -128 and 127, better code results from loading the value into a 19008 register and using the register. This is because the load into 19009 the register can be done with a `moveq' instruction. We arrange 19010 for this to happen by defining the letter `K' to mean "any integer 19011 outside the range -128 to 127", and then specifying `Ks' in the 19012 operand constraints. 19013 19014 `g' 19015 Any register, memory or immediate integer operand is allowed, 19016 except for registers that are not general registers. 19017 19018 `X' 19019 Any operand whatsoever is allowed, even if it does not satisfy 19020 `general_operand'. This is normally used in the constraint of a 19021 `match_scratch' when certain alternatives will not actually 19022 require a scratch register. 19023 19024 `0', `1', `2', ... `9' 19025 An operand that matches the specified operand number is allowed. 19026 If a digit is used together with letters within the same 19027 alternative, the digit should come last. 19028 19029 This number is allowed to be more than a single digit. If multiple 19030 digits are encountered consecutively, they are interpreted as a 19031 single decimal integer. There is scant chance for ambiguity, 19032 since to-date it has never been desirable that `10' be interpreted 19033 as matching either operand 1 _or_ operand 0. Should this be 19034 desired, one can use multiple alternatives instead. 19035 19036 This is called a "matching constraint" and what it really means is 19037 that the assembler has only a single operand that fills two roles 19038 considered separate in the RTL insn. For example, an add insn has 19039 two input operands and one output operand in the RTL, but on most 19040 CISC machines an add instruction really has only two operands, one 19041 of them an input-output operand: 19042 19043 addl #35,r12 19044 19045 Matching constraints are used in these circumstances. More 19046 precisely, the two operands that match must include one input-only 19047 operand and one output-only operand. Moreover, the digit must be a 19048 smaller number than the number of the operand that uses it in the 19049 constraint. 19050 19051 For operands to match in a particular case usually means that they 19052 are identical-looking RTL expressions. But in a few special cases 19053 specific kinds of dissimilarity are allowed. For example, `*x' as 19054 an input operand will match `*x++' as an output operand. For 19055 proper results in such cases, the output template should always 19056 use the output-operand's number when printing the operand. 19057 19058 `p' 19059 An operand that is a valid memory address is allowed. This is for 19060 "load address" and "push address" instructions. 19061 19062 `p' in the constraint must be accompanied by `address_operand' as 19063 the predicate in the `match_operand'. This predicate interprets 19064 the mode specified in the `match_operand' as the mode of the memory 19065 reference for which the address would be valid. 19066 19067 OTHER-LETTERS 19068 Other letters can be defined in machine-dependent fashion to stand 19069 for particular classes of registers or other arbitrary operand 19070 types. `d', `a' and `f' are defined on the 68000/68020 to stand 19071 for data, address and floating point registers. 19072 19073 In order to have valid assembler code, each operand must satisfy its 19074 constraint. But a failure to do so does not prevent the pattern from 19075 applying to an insn. Instead, it directs the compiler to modify the 19076 code so that the constraint will be satisfied. Usually this is done by 19077 copying an operand into a register. 19078 19079 Contrast, therefore, the two instruction patterns that follow: 19080 19081 (define_insn "" 19082 [(set (match_operand:SI 0 "general_operand" "=r") 19083 (plus:SI (match_dup 0) 19084 (match_operand:SI 1 "general_operand" "r")))] 19085 "" 19086 "...") 19087 19088 which has two operands, one of which must appear in two places, and 19089 19090 (define_insn "" 19091 [(set (match_operand:SI 0 "general_operand" "=r") 19092 (plus:SI (match_operand:SI 1 "general_operand" "0") 19093 (match_operand:SI 2 "general_operand" "r")))] 19094 "" 19095 "...") 19096 19097 which has three operands, two of which are required by a constraint to 19098 be identical. If we are considering an insn of the form 19099 19100 (insn N PREV NEXT 19101 (set (reg:SI 3) 19102 (plus:SI (reg:SI 6) (reg:SI 109))) 19103 ...) 19104 19105 the first pattern would not apply at all, because this insn does not 19106 contain two identical subexpressions in the right place. The pattern 19107 would say, "That does not look like an add instruction; try other 19108 patterns". The second pattern would say, "Yes, that's an add 19109 instruction, but there is something wrong with it". It would direct 19110 the reload pass of the compiler to generate additional insns to make 19111 the constraint true. The results might look like this: 19112 19113 (insn N2 PREV N 19114 (set (reg:SI 3) (reg:SI 6)) 19115 ...) 19116 19117 (insn N N2 NEXT 19118 (set (reg:SI 3) 19119 (plus:SI (reg:SI 3) (reg:SI 109))) 19120 ...) 19121 19122 It is up to you to make sure that each operand, in each pattern, has 19123 constraints that can handle any RTL expression that could be present for 19124 that operand. (When multiple alternatives are in use, each pattern 19125 must, for each possible combination of operand expressions, have at 19126 least one alternative which can handle that combination of operands.) 19127 The constraints don't need to _allow_ any possible operand--when this is 19128 the case, they do not constrain--but they must at least point the way to 19129 reloading any possible operand so that it will fit. 19130 19131 * If the constraint accepts whatever operands the predicate permits, 19132 there is no problem: reloading is never necessary for this operand. 19133 19134 For example, an operand whose constraints permit everything except 19135 registers is safe provided its predicate rejects registers. 19136 19137 An operand whose predicate accepts only constant values is safe 19138 provided its constraints include the letter `i'. If any possible 19139 constant value is accepted, then nothing less than `i' will do; if 19140 the predicate is more selective, then the constraints may also be 19141 more selective. 19142 19143 * Any operand expression can be reloaded by copying it into a 19144 register. So if an operand's constraints allow some kind of 19145 register, it is certain to be safe. It need not permit all 19146 classes of registers; the compiler knows how to copy a register 19147 into another register of the proper class in order to make an 19148 instruction valid. 19149 19150 * A nonoffsettable memory reference can be reloaded by copying the 19151 address into a register. So if the constraint uses the letter 19152 `o', all memory references are taken care of. 19153 19154 * A constant operand can be reloaded by allocating space in memory to 19155 hold it as preinitialized data. Then the memory reference can be 19156 used in place of the constant. So if the constraint uses the 19157 letters `o' or `m', constant operands are not a problem. 19158 19159 * If the constraint permits a constant and a pseudo register used in 19160 an insn was not allocated to a hard register and is equivalent to 19161 a constant, the register will be replaced with the constant. If 19162 the predicate does not permit a constant and the insn is 19163 re-recognized for some reason, the compiler will crash. Thus the 19164 predicate must always recognize any objects allowed by the 19165 constraint. 19166 19167 If the operand's predicate can recognize registers, but the constraint 19168 does not permit them, it can make the compiler crash. When this 19169 operand happens to be a register, the reload pass will be stymied, 19170 because it does not know how to copy a register temporarily into memory. 19171 19172 If the predicate accepts a unary operator, the constraint applies to 19173 the operand. For example, the MIPS processor at ISA level 3 supports an 19174 instruction which adds two registers in `SImode' to produce a `DImode' 19175 result, but only if the registers are correctly sign extended. This 19176 predicate for the input operands accepts a `sign_extend' of an `SImode' 19177 register. Write the constraint to indicate the type of register that 19178 is required for the operand of the `sign_extend'. 19179 19180 19181 File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 19182 19183 16.8.2 Multiple Alternative Constraints 19184 --------------------------------------- 19185 19186 Sometimes a single instruction has multiple alternative sets of possible 19187 operands. For example, on the 68000, a logical-or instruction can 19188 combine register or an immediate value into memory, or it can combine 19189 any kind of operand into a register; but it cannot combine one memory 19190 location into another. 19191 19192 These constraints are represented as multiple alternatives. An 19193 alternative can be described by a series of letters for each operand. 19194 The overall constraint for an operand is made from the letters for this 19195 operand from the first alternative, a comma, the letters for this 19196 operand from the second alternative, a comma, and so on until the last 19197 alternative. Here is how it is done for fullword logical-or on the 19198 68000: 19199 19200 (define_insn "iorsi3" 19201 [(set (match_operand:SI 0 "general_operand" "=m,d") 19202 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 19203 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 19204 ...) 19205 19206 The first alternative has `m' (memory) for operand 0, `0' for operand 19207 1 (meaning it must match operand 0), and `dKs' for operand 2. The 19208 second alternative has `d' (data register) for operand 0, `0' for 19209 operand 1, and `dmKs' for operand 2. The `=' and `%' in the 19210 constraints apply to all the alternatives; their meaning is explained 19211 in the next section (*note Class Preferences::). 19212 19213 If all the operands fit any one alternative, the instruction is valid. 19214 Otherwise, for each alternative, the compiler counts how many 19215 instructions must be added to copy the operands so that that 19216 alternative applies. The alternative requiring the least copying is 19217 chosen. If two alternatives need the same amount of copying, the one 19218 that comes first is chosen. These choices can be altered with the `?' 19219 and `!' characters: 19220 19221 `?' 19222 Disparage slightly the alternative that the `?' appears in, as a 19223 choice when no alternative applies exactly. The compiler regards 19224 this alternative as one unit more costly for each `?' that appears 19225 in it. 19226 19227 `!' 19228 Disparage severely the alternative that the `!' appears in. This 19229 alternative can still be used if it fits without reloading, but if 19230 reloading is needed, some other alternative will be used. 19231 19232 When an insn pattern has multiple alternatives in its constraints, 19233 often the appearance of the assembler code is determined mostly by which 19234 alternative was matched. When this is so, the C code for writing the 19235 assembler code can use the variable `which_alternative', which is the 19236 ordinal number of the alternative that was actually satisfied (0 for 19237 the first, 1 for the second alternative, etc.). *Note Output 19238 Statement::. 19239 19240 19241 File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 19242 19243 16.8.3 Register Class Preferences 19244 --------------------------------- 19245 19246 The operand constraints have another function: they enable the compiler 19247 to decide which kind of hardware register a pseudo register is best 19248 allocated to. The compiler examines the constraints that apply to the 19249 insns that use the pseudo register, looking for the machine-dependent 19250 letters such as `d' and `a' that specify classes of registers. The 19251 pseudo register is put in whichever class gets the most "votes". The 19252 constraint letters `g' and `r' also vote: they vote in favor of a 19253 general register. The machine description says which registers are 19254 considered general. 19255 19256 Of course, on some machines all registers are equivalent, and no 19257 register classes are defined. Then none of this complexity is relevant. 19258 19259 19260 File: gccint.info, Node: Modifiers, Next: Disable Insn Alternatives, Prev: Class Preferences, Up: Constraints 19261 19262 16.8.4 Constraint Modifier Characters 19263 ------------------------------------- 19264 19265 Here are constraint modifier characters. 19266 19267 `=' 19268 Means that this operand is write-only for this instruction: the 19269 previous value is discarded and replaced by output data. 19270 19271 `+' 19272 Means that this operand is both read and written by the 19273 instruction. 19274 19275 When the compiler fixes up the operands to satisfy the constraints, 19276 it needs to know which operands are inputs to the instruction and 19277 which are outputs from it. `=' identifies an output; `+' 19278 identifies an operand that is both input and output; all other 19279 operands are assumed to be input only. 19280 19281 If you specify `=' or `+' in a constraint, you put it in the first 19282 character of the constraint string. 19283 19284 `&' 19285 Means (in a particular alternative) that this operand is an 19286 "earlyclobber" operand, which is modified before the instruction is 19287 finished using the input operands. Therefore, this operand may 19288 not lie in a register that is used as an input operand or as part 19289 of any memory address. 19290 19291 `&' applies only to the alternative in which it is written. In 19292 constraints with multiple alternatives, sometimes one alternative 19293 requires `&' while others do not. See, for example, the `movdf' 19294 insn of the 68000. 19295 19296 An input operand can be tied to an earlyclobber operand if its only 19297 use as an input occurs before the early result is written. Adding 19298 alternatives of this form often allows GCC to produce better code 19299 when only some of the inputs can be affected by the earlyclobber. 19300 See, for example, the `mulsi3' insn of the ARM. 19301 19302 `&' does not obviate the need to write `='. 19303 19304 `%' 19305 Declares the instruction to be commutative for this operand and the 19306 following operand. This means that the compiler may interchange 19307 the two operands if that is the cheapest way to make all operands 19308 fit the constraints. This is often used in patterns for addition 19309 instructions that really have only two operands: the result must 19310 go in one of the arguments. Here for example, is how the 68000 19311 halfword-add instruction is defined: 19312 19313 (define_insn "addhi3" 19314 [(set (match_operand:HI 0 "general_operand" "=m,r") 19315 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 19316 (match_operand:HI 2 "general_operand" "di,g")))] 19317 ...) 19318 GCC can only handle one commutative pair in an asm; if you use 19319 more, the compiler may fail. Note that you need not use the 19320 modifier if the two alternatives are strictly identical; this 19321 would only waste time in the reload pass. The modifier is not 19322 operational after register allocation, so the result of 19323 `define_peephole2' and `define_split's performed after reload 19324 cannot rely on `%' to make the intended insn match. 19325 19326 `#' 19327 Says that all following characters, up to the next comma, are to be 19328 ignored as a constraint. They are significant only for choosing 19329 register preferences. 19330 19331 `*' 19332 Says that the following character should be ignored when choosing 19333 register preferences. `*' has no effect on the meaning of the 19334 constraint as a constraint, and no effect on reloading. 19335 19336 Here is an example: the 68000 has an instruction to sign-extend a 19337 halfword in a data register, and can also sign-extend a value by 19338 copying it into an address register. While either kind of 19339 register is acceptable, the constraints on an address-register 19340 destination are less strict, so it is best if register allocation 19341 makes an address register its goal. Therefore, `*' is used so 19342 that the `d' constraint letter (for data register) is ignored when 19343 computing register preferences. 19344 19345 (define_insn "extendhisi2" 19346 [(set (match_operand:SI 0 "general_operand" "=*d,a") 19347 (sign_extend:SI 19348 (match_operand:HI 1 "general_operand" "0,g")))] 19349 ...) 19350 19351 19352 File: gccint.info, Node: Machine Constraints, Next: Define Constraints, Prev: Disable Insn Alternatives, Up: Constraints 19353 19354 16.8.5 Constraints for Particular Machines 19355 ------------------------------------------ 19356 19357 Whenever possible, you should use the general-purpose constraint letters 19358 in `asm' arguments, since they will convey meaning more readily to 19359 people reading your code. Failing that, use the constraint letters 19360 that usually have very similar meanings across architectures. The most 19361 commonly used constraints are `m' and `r' (for memory and 19362 general-purpose registers respectively; *note Simple Constraints::), and 19363 `I', usually the letter indicating the most common immediate-constant 19364 format. 19365 19366 Each architecture defines additional constraints. These constraints 19367 are used by the compiler itself for instruction generation, as well as 19368 for `asm' statements; therefore, some of the constraints are not 19369 particularly useful for `asm'. Here is a summary of some of the 19370 machine-dependent constraints available on some particular machines; it 19371 includes both constraints that are useful for `asm' and constraints 19372 that aren't. The compiler source file mentioned in the table heading 19373 for each architecture is the definitive reference for the meanings of 19374 that architecture's constraints. 19375 19376 _ARM family--`config/arm/arm.h'_ 19377 19378 `f' 19379 Floating-point register 19380 19381 `w' 19382 VFP floating-point register 19383 19384 `F' 19385 One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0, 19386 4.0, 5.0 or 10.0 19387 19388 `G' 19389 Floating-point constant that would satisfy the constraint `F' 19390 if it were negated 19391 19392 `I' 19393 Integer that is valid as an immediate operand in a data 19394 processing instruction. That is, an integer in the range 0 19395 to 255 rotated by a multiple of 2 19396 19397 `J' 19398 Integer in the range -4095 to 4095 19399 19400 `K' 19401 Integer that satisfies constraint `I' when inverted (ones 19402 complement) 19403 19404 `L' 19405 Integer that satisfies constraint `I' when negated (twos 19406 complement) 19407 19408 `M' 19409 Integer in the range 0 to 32 19410 19411 `Q' 19412 A memory reference where the exact address is in a single 19413 register (``m'' is preferable for `asm' statements) 19414 19415 `R' 19416 An item in the constant pool 19417 19418 `S' 19419 A symbol in the text segment of the current file 19420 19421 `Uv' 19422 A memory reference suitable for VFP load/store insns 19423 (reg+constant offset) 19424 19425 `Uy' 19426 A memory reference suitable for iWMMXt load/store 19427 instructions. 19428 19429 `Uq' 19430 A memory reference suitable for the ARMv4 ldrsb instruction. 19431 19432 _AVR family--`config/avr/constraints.md'_ 19433 19434 `l' 19435 Registers from r0 to r15 19436 19437 `a' 19438 Registers from r16 to r23 19439 19440 `d' 19441 Registers from r16 to r31 19442 19443 `w' 19444 Registers from r24 to r31. These registers can be used in 19445 `adiw' command 19446 19447 `e' 19448 Pointer register (r26-r31) 19449 19450 `b' 19451 Base pointer register (r28-r31) 19452 19453 `q' 19454 Stack pointer register (SPH:SPL) 19455 19456 `t' 19457 Temporary register r0 19458 19459 `x' 19460 Register pair X (r27:r26) 19461 19462 `y' 19463 Register pair Y (r29:r28) 19464 19465 `z' 19466 Register pair Z (r31:r30) 19467 19468 `I' 19469 Constant greater than -1, less than 64 19470 19471 `J' 19472 Constant greater than -64, less than 1 19473 19474 `K' 19475 Constant integer 2 19476 19477 `L' 19478 Constant integer 0 19479 19480 `M' 19481 Constant that fits in 8 bits 19482 19483 `N' 19484 Constant integer -1 19485 19486 `O' 19487 Constant integer 8, 16, or 24 19488 19489 `P' 19490 Constant integer 1 19491 19492 `G' 19493 A floating point constant 0.0 19494 19495 `R' 19496 Integer constant in the range -6 ... 5. 19497 19498 `Q' 19499 A memory address based on Y or Z pointer with displacement. 19500 19501 _CRX Architecture--`config/crx/crx.h'_ 19502 19503 `b' 19504 Registers from r0 to r14 (registers without stack pointer) 19505 19506 `l' 19507 Register r16 (64-bit accumulator lo register) 19508 19509 `h' 19510 Register r17 (64-bit accumulator hi register) 19511 19512 `k' 19513 Register pair r16-r17. (64-bit accumulator lo-hi pair) 19514 19515 `I' 19516 Constant that fits in 3 bits 19517 19518 `J' 19519 Constant that fits in 4 bits 19520 19521 `K' 19522 Constant that fits in 5 bits 19523 19524 `L' 19525 Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48 19526 19527 `G' 19528 Floating point constant that is legal for store immediate 19529 19530 _Hewlett-Packard PA-RISC--`config/pa/pa.h'_ 19531 19532 `a' 19533 General register 1 19534 19535 `f' 19536 Floating point register 19537 19538 `q' 19539 Shift amount register 19540 19541 `x' 19542 Floating point register (deprecated) 19543 19544 `y' 19545 Upper floating point register (32-bit), floating point 19546 register (64-bit) 19547 19548 `Z' 19549 Any register 19550 19551 `I' 19552 Signed 11-bit integer constant 19553 19554 `J' 19555 Signed 14-bit integer constant 19556 19557 `K' 19558 Integer constant that can be deposited with a `zdepi' 19559 instruction 19560 19561 `L' 19562 Signed 5-bit integer constant 19563 19564 `M' 19565 Integer constant 0 19566 19567 `N' 19568 Integer constant that can be loaded with a `ldil' instruction 19569 19570 `O' 19571 Integer constant whose value plus one is a power of 2 19572 19573 `P' 19574 Integer constant that can be used for `and' operations in 19575 `depi' and `extru' instructions 19576 19577 `S' 19578 Integer constant 31 19579 19580 `U' 19581 Integer constant 63 19582 19583 `G' 19584 Floating-point constant 0.0 19585 19586 `A' 19587 A `lo_sum' data-linkage-table memory operand 19588 19589 `Q' 19590 A memory operand that can be used as the destination operand 19591 of an integer store instruction 19592 19593 `R' 19594 A scaled or unscaled indexed memory operand 19595 19596 `T' 19597 A memory operand for floating-point loads and stores 19598 19599 `W' 19600 A register indirect memory operand 19601 19602 _picoChip family--`picochip.h'_ 19603 19604 `k' 19605 Stack register. 19606 19607 `f' 19608 Pointer register. A register which can be used to access 19609 memory without supplying an offset. Any other register can 19610 be used to access memory, but will need a constant offset. 19611 In the case of the offset being zero, it is more efficient to 19612 use a pointer register, since this reduces code size. 19613 19614 `t' 19615 A twin register. A register which may be paired with an 19616 adjacent register to create a 32-bit register. 19617 19618 `a' 19619 Any absolute memory address (e.g., symbolic constant, symbolic 19620 constant + offset). 19621 19622 `I' 19623 4-bit signed integer. 19624 19625 `J' 19626 4-bit unsigned integer. 19627 19628 `K' 19629 8-bit signed integer. 19630 19631 `M' 19632 Any constant whose absolute value is no greater than 4-bits. 19633 19634 `N' 19635 10-bit signed integer 19636 19637 `O' 19638 16-bit signed integer. 19639 19640 19641 _PowerPC and IBM RS6000--`config/rs6000/rs6000.h'_ 19642 19643 `b' 19644 Address base register 19645 19646 `d' 19647 Floating point register (containing 64-bit value) 19648 19649 `f' 19650 Floating point register (containing 32-bit value) 19651 19652 `v' 19653 Altivec vector register 19654 19655 `wd' 19656 VSX vector register to hold vector double data 19657 19658 `wf' 19659 VSX vector register to hold vector float data 19660 19661 `ws' 19662 VSX vector register to hold scalar float data 19663 19664 `wa' 19665 Any VSX register 19666 19667 `h' 19668 `MQ', `CTR', or `LINK' register 19669 19670 `q' 19671 `MQ' register 19672 19673 `c' 19674 `CTR' register 19675 19676 `l' 19677 `LINK' register 19678 19679 `x' 19680 `CR' register (condition register) number 0 19681 19682 `y' 19683 `CR' register (condition register) 19684 19685 `z' 19686 `XER[CA]' carry bit (part of the XER register) 19687 19688 `I' 19689 Signed 16-bit constant 19690 19691 `J' 19692 Unsigned 16-bit constant shifted left 16 bits (use `L' 19693 instead for `SImode' constants) 19694 19695 `K' 19696 Unsigned 16-bit constant 19697 19698 `L' 19699 Signed 16-bit constant shifted left 16 bits 19700 19701 `M' 19702 Constant larger than 31 19703 19704 `N' 19705 Exact power of 2 19706 19707 `O' 19708 Zero 19709 19710 `P' 19711 Constant whose negation is a signed 16-bit constant 19712 19713 `G' 19714 Floating point constant that can be loaded into a register 19715 with one instruction per word 19716 19717 `H' 19718 Integer/Floating point constant that can be loaded into a 19719 register using three instructions 19720 19721 `m' 19722 Memory operand. Normally, `m' does not allow addresses that 19723 update the base register. If `<' or `>' constraint is also 19724 used, they are allowed and therefore on PowerPC targets in 19725 that case it is only safe to use `m<>' in an `asm' statement 19726 if that `asm' statement accesses the operand exactly once. 19727 The `asm' statement must also use `%U<OPNO>' as a placeholder 19728 for the "update" flag in the corresponding load or store 19729 instruction. For example: 19730 19731 asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); 19732 19733 is correct but: 19734 19735 asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); 19736 19737 is not. 19738 19739 `es' 19740 A "stable" memory operand; that is, one which does not 19741 include any automodification of the base register. This used 19742 to be useful when `m' allowed automodification of the base 19743 register, but as those are now only allowed when `<' or `>' 19744 is used, `es' is basically the same as `m' without `<' and 19745 `>'. 19746 19747 `Q' 19748 Memory operand that is an offset from a register (it is 19749 usually better to use `m' or `es' in `asm' statements) 19750 19751 `Z' 19752 Memory operand that is an indexed or indirect from a register 19753 (it is usually better to use `m' or `es' in `asm' statements) 19754 19755 `R' 19756 AIX TOC entry 19757 19758 `a' 19759 Address operand that is an indexed or indirect from a 19760 register (`p' is preferable for `asm' statements) 19761 19762 `S' 19763 Constant suitable as a 64-bit mask operand 19764 19765 `T' 19766 Constant suitable as a 32-bit mask operand 19767 19768 `U' 19769 System V Release 4 small data area reference 19770 19771 `t' 19772 AND masks that can be performed by two rldic{l, r} 19773 instructions 19774 19775 `W' 19776 Vector constant that does not require memory 19777 19778 `j' 19779 Vector constant that is all zeros. 19780 19781 19782 _Intel 386--`config/i386/constraints.md'_ 19783 19784 `R' 19785 Legacy register--the eight integer registers available on all 19786 i386 processors (`a', `b', `c', `d', `si', `di', `bp', `sp'). 19787 19788 `q' 19789 Any register accessible as `Rl'. In 32-bit mode, `a', `b', 19790 `c', and `d'; in 64-bit mode, any integer register. 19791 19792 `Q' 19793 Any register accessible as `Rh': `a', `b', `c', and `d'. 19794 19795 `l' 19796 Any register that can be used as the index in a base+index 19797 memory access: that is, any general register except the stack 19798 pointer. 19799 19800 `a' 19801 The `a' register. 19802 19803 `b' 19804 The `b' register. 19805 19806 `c' 19807 The `c' register. 19808 19809 `d' 19810 The `d' register. 19811 19812 `S' 19813 The `si' register. 19814 19815 `D' 19816 The `di' register. 19817 19818 `A' 19819 The `a' and `d' registers. This class is used for 19820 instructions that return double word results in the `ax:dx' 19821 register pair. Single word values will be allocated either 19822 in `ax' or `dx'. For example on i386 the following 19823 implements `rdtsc': 19824 19825 unsigned long long rdtsc (void) 19826 { 19827 unsigned long long tick; 19828 __asm__ __volatile__("rdtsc":"=A"(tick)); 19829 return tick; 19830 } 19831 19832 This is not correct on x86_64 as it would allocate tick in 19833 either `ax' or `dx'. You have to use the following variant 19834 instead: 19835 19836 unsigned long long rdtsc (void) 19837 { 19838 unsigned int tickl, tickh; 19839 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); 19840 return ((unsigned long long)tickh << 32)|tickl; 19841 } 19842 19843 `f' 19844 Any 80387 floating-point (stack) register. 19845 19846 `t' 19847 Top of 80387 floating-point stack (`%st(0)'). 19848 19849 `u' 19850 Second from top of 80387 floating-point stack (`%st(1)'). 19851 19852 `y' 19853 Any MMX register. 19854 19855 `x' 19856 Any SSE register. 19857 19858 `Yz' 19859 First SSE register (`%xmm0'). 19860 19861 `Y2' 19862 Any SSE register, when SSE2 is enabled. 19863 19864 `Yi' 19865 Any SSE register, when SSE2 and inter-unit moves are enabled. 19866 19867 `Ym' 19868 Any MMX register, when inter-unit moves are enabled. 19869 19870 `I' 19871 Integer constant in the range 0 ... 31, for 32-bit shifts. 19872 19873 `J' 19874 Integer constant in the range 0 ... 63, for 64-bit shifts. 19875 19876 `K' 19877 Signed 8-bit integer constant. 19878 19879 `L' 19880 `0xFF' or `0xFFFF', for andsi as a zero-extending move. 19881 19882 `M' 19883 0, 1, 2, or 3 (shifts for the `lea' instruction). 19884 19885 `N' 19886 Unsigned 8-bit integer constant (for `in' and `out' 19887 instructions). 19888 19889 `O' 19890 Integer constant in the range 0 ... 127, for 128-bit shifts. 19891 19892 `G' 19893 Standard 80387 floating point constant. 19894 19895 `C' 19896 Standard SSE floating point constant. 19897 19898 `e' 19899 32-bit signed integer constant, or a symbolic reference known 19900 to fit that range (for immediate operands in sign-extending 19901 x86-64 instructions). 19902 19903 `Z' 19904 32-bit unsigned integer constant, or a symbolic reference 19905 known to fit that range (for immediate operands in 19906 zero-extending x86-64 instructions). 19907 19908 19909 _Intel IA-64--`config/ia64/ia64.h'_ 19910 19911 `a' 19912 General register `r0' to `r3' for `addl' instruction 19913 19914 `b' 19915 Branch register 19916 19917 `c' 19918 Predicate register (`c' as in "conditional") 19919 19920 `d' 19921 Application register residing in M-unit 19922 19923 `e' 19924 Application register residing in I-unit 19925 19926 `f' 19927 Floating-point register 19928 19929 `m' 19930 Memory operand. If used together with `<' or `>', the 19931 operand can have postincrement and postdecrement which 19932 require printing with `%Pn' on IA-64. 19933 19934 `G' 19935 Floating-point constant 0.0 or 1.0 19936 19937 `I' 19938 14-bit signed integer constant 19939 19940 `J' 19941 22-bit signed integer constant 19942 19943 `K' 19944 8-bit signed integer constant for logical instructions 19945 19946 `L' 19947 8-bit adjusted signed integer constant for compare pseudo-ops 19948 19949 `M' 19950 6-bit unsigned integer constant for shift counts 19951 19952 `N' 19953 9-bit signed integer constant for load and store 19954 postincrements 19955 19956 `O' 19957 The constant zero 19958 19959 `P' 19960 0 or -1 for `dep' instruction 19961 19962 `Q' 19963 Non-volatile memory for floating-point loads and stores 19964 19965 `R' 19966 Integer constant in the range 1 to 4 for `shladd' instruction 19967 19968 `S' 19969 Memory operand except postincrement and postdecrement. This 19970 is now roughly the same as `m' when not used together with `<' 19971 or `>'. 19972 19973 _FRV--`config/frv/frv.h'_ 19974 19975 `a' 19976 Register in the class `ACC_REGS' (`acc0' to `acc7'). 19977 19978 `b' 19979 Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7'). 19980 19981 `c' 19982 Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0' 19983 to `icc3'). 19984 19985 `d' 19986 Register in the class `GPR_REGS' (`gr0' to `gr63'). 19987 19988 `e' 19989 Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd 19990 registers are excluded not in the class but through the use 19991 of a machine mode larger than 4 bytes. 19992 19993 `f' 19994 Register in the class `FPR_REGS' (`fr0' to `fr63'). 19995 19996 `h' 19997 Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd 19998 registers are excluded not in the class but through the use 19999 of a machine mode larger than 4 bytes. 20000 20001 `l' 20002 Register in the class `LR_REG' (the `lr' register). 20003 20004 `q' 20005 Register in the class `QUAD_REGS' (`gr2' to `gr63'). 20006 Register numbers not divisible by 4 are excluded not in the 20007 class but through the use of a machine mode larger than 8 20008 bytes. 20009 20010 `t' 20011 Register in the class `ICC_REGS' (`icc0' to `icc3'). 20012 20013 `u' 20014 Register in the class `FCC_REGS' (`fcc0' to `fcc3'). 20015 20016 `v' 20017 Register in the class `ICR_REGS' (`cc4' to `cc7'). 20018 20019 `w' 20020 Register in the class `FCR_REGS' (`cc0' to `cc3'). 20021 20022 `x' 20023 Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63'). 20024 Register numbers not divisible by 4 are excluded not in the 20025 class but through the use of a machine mode larger than 8 20026 bytes. 20027 20028 `z' 20029 Register in the class `SPR_REGS' (`lcr' and `lr'). 20030 20031 `A' 20032 Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7'). 20033 20034 `B' 20035 Register in the class `ACCG_REGS' (`accg0' to `accg7'). 20036 20037 `C' 20038 Register in the class `CR_REGS' (`cc0' to `cc7'). 20039 20040 `G' 20041 Floating point constant zero 20042 20043 `I' 20044 6-bit signed integer constant 20045 20046 `J' 20047 10-bit signed integer constant 20048 20049 `L' 20050 16-bit signed integer constant 20051 20052 `M' 20053 16-bit unsigned integer constant 20054 20055 `N' 20056 12-bit signed integer constant that is negative--i.e. in the 20057 range of -2048 to -1 20058 20059 `O' 20060 Constant zero 20061 20062 `P' 20063 12-bit signed integer constant that is greater than 20064 zero--i.e. in the range of 1 to 2047. 20065 20066 20067 _Blackfin family--`config/bfin/constraints.md'_ 20068 20069 `a' 20070 P register 20071 20072 `d' 20073 D register 20074 20075 `z' 20076 A call clobbered P register. 20077 20078 `qN' 20079 A single register. If N is in the range 0 to 7, the 20080 corresponding D register. If it is `A', then the register P0. 20081 20082 `D' 20083 Even-numbered D register 20084 20085 `W' 20086 Odd-numbered D register 20087 20088 `e' 20089 Accumulator register. 20090 20091 `A' 20092 Even-numbered accumulator register. 20093 20094 `B' 20095 Odd-numbered accumulator register. 20096 20097 `b' 20098 I register 20099 20100 `v' 20101 B register 20102 20103 `f' 20104 M register 20105 20106 `c' 20107 Registers used for circular buffering, i.e. I, B, or L 20108 registers. 20109 20110 `C' 20111 The CC register. 20112 20113 `t' 20114 LT0 or LT1. 20115 20116 `k' 20117 LC0 or LC1. 20118 20119 `u' 20120 LB0 or LB1. 20121 20122 `x' 20123 Any D, P, B, M, I or L register. 20124 20125 `y' 20126 Additional registers typically used only in prologues and 20127 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 20128 USP. 20129 20130 `w' 20131 Any register except accumulators or CC. 20132 20133 `Ksh' 20134 Signed 16 bit integer (in the range -32768 to 32767) 20135 20136 `Kuh' 20137 Unsigned 16 bit integer (in the range 0 to 65535) 20138 20139 `Ks7' 20140 Signed 7 bit integer (in the range -64 to 63) 20141 20142 `Ku7' 20143 Unsigned 7 bit integer (in the range 0 to 127) 20144 20145 `Ku5' 20146 Unsigned 5 bit integer (in the range 0 to 31) 20147 20148 `Ks4' 20149 Signed 4 bit integer (in the range -8 to 7) 20150 20151 `Ks3' 20152 Signed 3 bit integer (in the range -3 to 4) 20153 20154 `Ku3' 20155 Unsigned 3 bit integer (in the range 0 to 7) 20156 20157 `PN' 20158 Constant N, where N is a single-digit constant in the range 0 20159 to 4. 20160 20161 `PA' 20162 An integer equal to one of the MACFLAG_XXX constants that is 20163 suitable for use with either accumulator. 20164 20165 `PB' 20166 An integer equal to one of the MACFLAG_XXX constants that is 20167 suitable for use only with accumulator A1. 20168 20169 `M1' 20170 Constant 255. 20171 20172 `M2' 20173 Constant 65535. 20174 20175 `J' 20176 An integer constant with exactly a single bit set. 20177 20178 `L' 20179 An integer constant with all bits set except exactly one. 20180 20181 `H' 20182 20183 `Q' 20184 Any SYMBOL_REF. 20185 20186 _M32C--`config/m32c/m32c.c'_ 20187 20188 `Rsp' 20189 `Rfb' 20190 `Rsb' 20191 `$sp', `$fb', `$sb'. 20192 20193 `Rcr' 20194 Any control register, when they're 16 bits wide (nothing if 20195 control registers are 24 bits wide) 20196 20197 `Rcl' 20198 Any control register, when they're 24 bits wide. 20199 20200 `R0w' 20201 `R1w' 20202 `R2w' 20203 `R3w' 20204 $r0, $r1, $r2, $r3. 20205 20206 `R02' 20207 $r0 or $r2, or $r2r0 for 32 bit values. 20208 20209 `R13' 20210 $r1 or $r3, or $r3r1 for 32 bit values. 20211 20212 `Rdi' 20213 A register that can hold a 64 bit value. 20214 20215 `Rhl' 20216 $r0 or $r1 (registers with addressable high/low bytes) 20217 20218 `R23' 20219 $r2 or $r3 20220 20221 `Raa' 20222 Address registers 20223 20224 `Raw' 20225 Address registers when they're 16 bits wide. 20226 20227 `Ral' 20228 Address registers when they're 24 bits wide. 20229 20230 `Rqi' 20231 Registers that can hold QI values. 20232 20233 `Rad' 20234 Registers that can be used with displacements ($a0, $a1, $sb). 20235 20236 `Rsi' 20237 Registers that can hold 32 bit values. 20238 20239 `Rhi' 20240 Registers that can hold 16 bit values. 20241 20242 `Rhc' 20243 Registers chat can hold 16 bit values, including all control 20244 registers. 20245 20246 `Rra' 20247 $r0 through R1, plus $a0 and $a1. 20248 20249 `Rfl' 20250 The flags register. 20251 20252 `Rmm' 20253 The memory-based pseudo-registers $mem0 through $mem15. 20254 20255 `Rpi' 20256 Registers that can hold pointers (16 bit registers for r8c, 20257 m16c; 24 bit registers for m32cm, m32c). 20258 20259 `Rpa' 20260 Matches multiple registers in a PARALLEL to form a larger 20261 register. Used to match function return values. 20262 20263 `Is3' 20264 -8 ... 7 20265 20266 `IS1' 20267 -128 ... 127 20268 20269 `IS2' 20270 -32768 ... 32767 20271 20272 `IU2' 20273 0 ... 65535 20274 20275 `In4' 20276 -8 ... -1 or 1 ... 8 20277 20278 `In5' 20279 -16 ... -1 or 1 ... 16 20280 20281 `In6' 20282 -32 ... -1 or 1 ... 32 20283 20284 `IM2' 20285 -65536 ... -1 20286 20287 `Ilb' 20288 An 8 bit value with exactly one bit set. 20289 20290 `Ilw' 20291 A 16 bit value with exactly one bit set. 20292 20293 `Sd' 20294 The common src/dest memory addressing modes. 20295 20296 `Sa' 20297 Memory addressed using $a0 or $a1. 20298 20299 `Si' 20300 Memory addressed with immediate addresses. 20301 20302 `Ss' 20303 Memory addressed using the stack pointer ($sp). 20304 20305 `Sf' 20306 Memory addressed using the frame base register ($fb). 20307 20308 `Ss' 20309 Memory addressed using the small base register ($sb). 20310 20311 `S1' 20312 $r1h 20313 20314 _MeP--`config/mep/constraints.md'_ 20315 20316 `a' 20317 The $sp register. 20318 20319 `b' 20320 The $tp register. 20321 20322 `c' 20323 Any control register. 20324 20325 `d' 20326 Either the $hi or the $lo register. 20327 20328 `em' 20329 Coprocessor registers that can be directly loaded ($c0-$c15). 20330 20331 `ex' 20332 Coprocessor registers that can be moved to each other. 20333 20334 `er' 20335 Coprocessor registers that can be moved to core registers. 20336 20337 `h' 20338 The $hi register. 20339 20340 `j' 20341 The $rpc register. 20342 20343 `l' 20344 The $lo register. 20345 20346 `t' 20347 Registers which can be used in $tp-relative addressing. 20348 20349 `v' 20350 The $gp register. 20351 20352 `x' 20353 The coprocessor registers. 20354 20355 `y' 20356 The coprocessor control registers. 20357 20358 `z' 20359 The $0 register. 20360 20361 `A' 20362 User-defined register set A. 20363 20364 `B' 20365 User-defined register set B. 20366 20367 `C' 20368 User-defined register set C. 20369 20370 `D' 20371 User-defined register set D. 20372 20373 `I' 20374 Offsets for $gp-rel addressing. 20375 20376 `J' 20377 Constants that can be used directly with boolean insns. 20378 20379 `K' 20380 Constants that can be moved directly to registers. 20381 20382 `L' 20383 Small constants that can be added to registers. 20384 20385 `M' 20386 Long shift counts. 20387 20388 `N' 20389 Small constants that can be compared to registers. 20390 20391 `O' 20392 Constants that can be loaded into the top half of registers. 20393 20394 `S' 20395 Signed 8-bit immediates. 20396 20397 `T' 20398 Symbols encoded for $tp-rel or $gp-rel addressing. 20399 20400 `U' 20401 Non-constant addresses for loading/saving coprocessor 20402 registers. 20403 20404 `W' 20405 The top half of a symbol's value. 20406 20407 `Y' 20408 A register indirect address without offset. 20409 20410 `Z' 20411 Symbolic references to the control bus. 20412 20413 20414 _MicroBlaze--`config/microblaze/constraints.md'_ 20415 20416 `d' 20417 A general register (`r0' to `r31'). 20418 20419 `z' 20420 A status register (`rmsr', `$fcc1' to `$fcc7'). 20421 20422 20423 _MIPS--`config/mips/constraints.md'_ 20424 20425 `d' 20426 An address register. This is equivalent to `r' unless 20427 generating MIPS16 code. 20428 20429 `f' 20430 A floating-point register (if available). 20431 20432 `h' 20433 Formerly the `hi' register. This constraint is no longer 20434 supported. 20435 20436 `l' 20437 The `lo' register. Use this register to store values that are 20438 no bigger than a word. 20439 20440 `x' 20441 The concatenated `hi' and `lo' registers. Use this register 20442 to store doubleword values. 20443 20444 `c' 20445 A register suitable for use in an indirect jump. This will 20446 always be `$25' for `-mabicalls'. 20447 20448 `v' 20449 Register `$3'. Do not use this constraint in new code; it is 20450 retained only for compatibility with glibc. 20451 20452 `y' 20453 Equivalent to `r'; retained for backwards compatibility. 20454 20455 `z' 20456 A floating-point condition code register. 20457 20458 `I' 20459 A signed 16-bit constant (for arithmetic instructions). 20460 20461 `J' 20462 Integer zero. 20463 20464 `K' 20465 An unsigned 16-bit constant (for logic instructions). 20466 20467 `L' 20468 A signed 32-bit constant in which the lower 16 bits are zero. 20469 Such constants can be loaded using `lui'. 20470 20471 `M' 20472 A constant that cannot be loaded using `lui', `addiu' or 20473 `ori'. 20474 20475 `N' 20476 A constant in the range -65535 to -1 (inclusive). 20477 20478 `O' 20479 A signed 15-bit constant. 20480 20481 `P' 20482 A constant in the range 1 to 65535 (inclusive). 20483 20484 `G' 20485 Floating-point zero. 20486 20487 `R' 20488 An address that can be used in a non-macro load or store. 20489 20490 _Motorola 680x0--`config/m68k/constraints.md'_ 20491 20492 `a' 20493 Address register 20494 20495 `d' 20496 Data register 20497 20498 `f' 20499 68881 floating-point register, if available 20500 20501 `I' 20502 Integer in the range 1 to 8 20503 20504 `J' 20505 16-bit signed number 20506 20507 `K' 20508 Signed number whose magnitude is greater than 0x80 20509 20510 `L' 20511 Integer in the range -8 to -1 20512 20513 `M' 20514 Signed number whose magnitude is greater than 0x100 20515 20516 `N' 20517 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 20518 20519 `O' 20520 16 (for rotate using swap) 20521 20522 `P' 20523 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 20524 20525 `R' 20526 Numbers that mov3q can handle 20527 20528 `G' 20529 Floating point constant that is not a 68881 constant 20530 20531 `S' 20532 Operands that satisfy 'm' when -mpcrel is in effect 20533 20534 `T' 20535 Operands that satisfy 's' when -mpcrel is not in effect 20536 20537 `Q' 20538 Address register indirect addressing mode 20539 20540 `U' 20541 Register offset addressing 20542 20543 `W' 20544 const_call_operand 20545 20546 `Cs' 20547 symbol_ref or const 20548 20549 `Ci' 20550 const_int 20551 20552 `C0' 20553 const_int 0 20554 20555 `Cj' 20556 Range of signed numbers that don't fit in 16 bits 20557 20558 `Cmvq' 20559 Integers valid for mvq 20560 20561 `Capsw' 20562 Integers valid for a moveq followed by a swap 20563 20564 `Cmvz' 20565 Integers valid for mvz 20566 20567 `Cmvs' 20568 Integers valid for mvs 20569 20570 `Ap' 20571 push_operand 20572 20573 `Ac' 20574 Non-register operands allowed in clr 20575 20576 20577 _Motorola 68HC11 & 68HC12 families--`config/m68hc11/m68hc11.h'_ 20578 20579 `a' 20580 Register `a' 20581 20582 `b' 20583 Register `b' 20584 20585 `d' 20586 Register `d' 20587 20588 `q' 20589 An 8-bit register 20590 20591 `t' 20592 Temporary soft register _.tmp 20593 20594 `u' 20595 A soft register _.d1 to _.d31 20596 20597 `w' 20598 Stack pointer register 20599 20600 `x' 20601 Register `x' 20602 20603 `y' 20604 Register `y' 20605 20606 `z' 20607 Pseudo register `z' (replaced by `x' or `y' at the end) 20608 20609 `A' 20610 An address register: x, y or z 20611 20612 `B' 20613 An address register: x or y 20614 20615 `D' 20616 Register pair (x:d) to form a 32-bit value 20617 20618 `L' 20619 Constants in the range -65536 to 65535 20620 20621 `M' 20622 Constants whose 16-bit low part is zero 20623 20624 `N' 20625 Constant integer 1 or -1 20626 20627 `O' 20628 Constant integer 16 20629 20630 `P' 20631 Constants in the range -8 to 2 20632 20633 20634 _Moxie--`config/moxie/constraints.md'_ 20635 20636 `A' 20637 An absolute address 20638 20639 `B' 20640 An offset address 20641 20642 `W' 20643 A register indirect memory operand 20644 20645 `I' 20646 A constant in the range of 0 to 255. 20647 20648 `N' 20649 A constant in the range of 0 to -255. 20650 20651 20652 _PDP-11--`config/pdp11/constraints.md'_ 20653 20654 `a' 20655 Floating point registers AC0 through AC3. These can be 20656 loaded from/to memory with a single instruction. 20657 20658 `d' 20659 Odd numbered general registers (R1, R3, R5). These are used 20660 for 16-bit multiply operations. 20661 20662 `f' 20663 Any of the floating point registers (AC0 through AC5). 20664 20665 `G' 20666 Floating point constant 0. 20667 20668 `I' 20669 An integer constant that fits in 16 bits. 20670 20671 `J' 20672 An integer constant whose low order 16 bits are zero. 20673 20674 `K' 20675 An integer constant that does not meet the constraints for 20676 codes `I' or `J'. 20677 20678 `L' 20679 The integer constant 1. 20680 20681 `M' 20682 The integer constant -1. 20683 20684 `N' 20685 The integer constant 0. 20686 20687 `O' 20688 Integer constants -4 through -1 and 1 through 4; shifts by 20689 these amounts are handled as multiple single-bit shifts 20690 rather than a single variable-length shift. 20691 20692 `Q' 20693 A memory reference which requires an additional word (address 20694 or offset) after the opcode. 20695 20696 `R' 20697 A memory reference that is encoded within the opcode. 20698 20699 20700 _RX--`config/rx/constraints.md'_ 20701 20702 `Q' 20703 An address which does not involve register indirect 20704 addressing or pre/post increment/decrement addressing. 20705 20706 `Symbol' 20707 A symbol reference. 20708 20709 `Int08' 20710 A constant in the range -256 to 255, inclusive. 20711 20712 `Sint08' 20713 A constant in the range -128 to 127, inclusive. 20714 20715 `Sint16' 20716 A constant in the range -32768 to 32767, inclusive. 20717 20718 `Sint24' 20719 A constant in the range -8388608 to 8388607, inclusive. 20720 20721 `Uint04' 20722 A constant in the range 0 to 15, inclusive. 20723 20724 20725 _SPARC--`config/sparc/sparc.h'_ 20726 20727 `f' 20728 Floating-point register on the SPARC-V8 architecture and 20729 lower floating-point register on the SPARC-V9 architecture. 20730 20731 `e' 20732 Floating-point register. It is equivalent to `f' on the 20733 SPARC-V8 architecture and contains both lower and upper 20734 floating-point registers on the SPARC-V9 architecture. 20735 20736 `c' 20737 Floating-point condition code register. 20738 20739 `d' 20740 Lower floating-point register. It is only valid on the 20741 SPARC-V9 architecture when the Visual Instruction Set is 20742 available. 20743 20744 `b' 20745 Floating-point register. It is only valid on the SPARC-V9 20746 architecture when the Visual Instruction Set is available. 20747 20748 `h' 20749 64-bit global or out register for the SPARC-V8+ architecture. 20750 20751 `D' 20752 A vector constant 20753 20754 `I' 20755 Signed 13-bit constant 20756 20757 `J' 20758 Zero 20759 20760 `K' 20761 32-bit constant with the low 12 bits clear (a constant that 20762 can be loaded with the `sethi' instruction) 20763 20764 `L' 20765 A constant in the range supported by `movcc' instructions 20766 20767 `M' 20768 A constant in the range supported by `movrcc' instructions 20769 20770 `N' 20771 Same as `K', except that it verifies that bits that are not 20772 in the lower 32-bit range are all zero. Must be used instead 20773 of `K' for modes wider than `SImode' 20774 20775 `O' 20776 The constant 4096 20777 20778 `G' 20779 Floating-point zero 20780 20781 `H' 20782 Signed 13-bit constant, sign-extended to 32 or 64 bits 20783 20784 `Q' 20785 Floating-point constant whose integral representation can be 20786 moved into an integer register using a single sethi 20787 instruction 20788 20789 `R' 20790 Floating-point constant whose integral representation can be 20791 moved into an integer register using a single mov instruction 20792 20793 `S' 20794 Floating-point constant whose integral representation can be 20795 moved into an integer register using a high/lo_sum 20796 instruction sequence 20797 20798 `T' 20799 Memory address aligned to an 8-byte boundary 20800 20801 `U' 20802 Even register 20803 20804 `W' 20805 Memory address for `e' constraint registers 20806 20807 `Y' 20808 Vector zero 20809 20810 20811 _SPU--`config/spu/spu.h'_ 20812 20813 `a' 20814 An immediate which can be loaded with the il/ila/ilh/ilhu 20815 instructions. const_int is treated as a 64 bit value. 20816 20817 `c' 20818 An immediate for and/xor/or instructions. const_int is 20819 treated as a 64 bit value. 20820 20821 `d' 20822 An immediate for the `iohl' instruction. const_int is 20823 treated as a 64 bit value. 20824 20825 `f' 20826 An immediate which can be loaded with `fsmbi'. 20827 20828 `A' 20829 An immediate which can be loaded with the il/ila/ilh/ilhu 20830 instructions. const_int is treated as a 32 bit value. 20831 20832 `B' 20833 An immediate for most arithmetic instructions. const_int is 20834 treated as a 32 bit value. 20835 20836 `C' 20837 An immediate for and/xor/or instructions. const_int is 20838 treated as a 32 bit value. 20839 20840 `D' 20841 An immediate for the `iohl' instruction. const_int is 20842 treated as a 32 bit value. 20843 20844 `I' 20845 A constant in the range [-64, 63] for shift/rotate 20846 instructions. 20847 20848 `J' 20849 An unsigned 7-bit constant for conversion/nop/channel 20850 instructions. 20851 20852 `K' 20853 A signed 10-bit constant for most arithmetic instructions. 20854 20855 `M' 20856 A signed 16 bit immediate for `stop'. 20857 20858 `N' 20859 An unsigned 16-bit constant for `iohl' and `fsmbi'. 20860 20861 `O' 20862 An unsigned 7-bit constant whose 3 least significant bits are 20863 0. 20864 20865 `P' 20866 An unsigned 3-bit constant for 16-byte rotates and shifts 20867 20868 `R' 20869 Call operand, reg, for indirect calls 20870 20871 `S' 20872 Call operand, symbol, for relative calls. 20873 20874 `T' 20875 Call operand, const_int, for absolute calls. 20876 20877 `U' 20878 An immediate which can be loaded with the il/ila/ilh/ilhu 20879 instructions. const_int is sign extended to 128 bit. 20880 20881 `W' 20882 An immediate for shift and rotate instructions. const_int is 20883 treated as a 32 bit value. 20884 20885 `Y' 20886 An immediate for and/xor/or instructions. const_int is sign 20887 extended as a 128 bit. 20888 20889 `Z' 20890 An immediate for the `iohl' instruction. const_int is sign 20891 extended to 128 bit. 20892 20893 20894 _S/390 and zSeries--`config/s390/s390.h'_ 20895 20896 `a' 20897 Address register (general purpose register except r0) 20898 20899 `c' 20900 Condition code register 20901 20902 `d' 20903 Data register (arbitrary general purpose register) 20904 20905 `f' 20906 Floating-point register 20907 20908 `I' 20909 Unsigned 8-bit constant (0-255) 20910 20911 `J' 20912 Unsigned 12-bit constant (0-4095) 20913 20914 `K' 20915 Signed 16-bit constant (-32768-32767) 20916 20917 `L' 20918 Value appropriate as displacement. 20919 `(0..4095)' 20920 for short displacement 20921 20922 `(-524288..524287)' 20923 for long displacement 20924 20925 `M' 20926 Constant integer with a value of 0x7fffffff. 20927 20928 `N' 20929 Multiple letter constraint followed by 4 parameter letters. 20930 `0..9:' 20931 number of the part counting from most to least 20932 significant 20933 20934 `H,Q:' 20935 mode of the part 20936 20937 `D,S,H:' 20938 mode of the containing operand 20939 20940 `0,F:' 20941 value of the other parts (F--all bits set) 20942 The constraint matches if the specified part of a constant 20943 has a value different from its other parts. 20944 20945 `Q' 20946 Memory reference without index register and with short 20947 displacement. 20948 20949 `R' 20950 Memory reference with index register and short displacement. 20951 20952 `S' 20953 Memory reference without index register but with long 20954 displacement. 20955 20956 `T' 20957 Memory reference with index register and long displacement. 20958 20959 `U' 20960 Pointer with short displacement. 20961 20962 `W' 20963 Pointer with long displacement. 20964 20965 `Y' 20966 Shift count operand. 20967 20968 20969 _Score family--`config/score/score.h'_ 20970 20971 `d' 20972 Registers from r0 to r32. 20973 20974 `e' 20975 Registers from r0 to r16. 20976 20977 `t' 20978 r8--r11 or r22--r27 registers. 20979 20980 `h' 20981 hi register. 20982 20983 `l' 20984 lo register. 20985 20986 `x' 20987 hi + lo register. 20988 20989 `q' 20990 cnt register. 20991 20992 `y' 20993 lcb register. 20994 20995 `z' 20996 scb register. 20997 20998 `a' 20999 cnt + lcb + scb register. 21000 21001 `c' 21002 cr0--cr15 register. 21003 21004 `b' 21005 cp1 registers. 21006 21007 `f' 21008 cp2 registers. 21009 21010 `i' 21011 cp3 registers. 21012 21013 `j' 21014 cp1 + cp2 + cp3 registers. 21015 21016 `I' 21017 High 16-bit constant (32-bit constant with 16 LSBs zero). 21018 21019 `J' 21020 Unsigned 5 bit integer (in the range 0 to 31). 21021 21022 `K' 21023 Unsigned 16 bit integer (in the range 0 to 65535). 21024 21025 `L' 21026 Signed 16 bit integer (in the range -32768 to 32767). 21027 21028 `M' 21029 Unsigned 14 bit integer (in the range 0 to 16383). 21030 21031 `N' 21032 Signed 14 bit integer (in the range -8192 to 8191). 21033 21034 `Z' 21035 Any SYMBOL_REF. 21036 21037 _Xstormy16--`config/stormy16/stormy16.h'_ 21038 21039 `a' 21040 Register r0. 21041 21042 `b' 21043 Register r1. 21044 21045 `c' 21046 Register r2. 21047 21048 `d' 21049 Register r8. 21050 21051 `e' 21052 Registers r0 through r7. 21053 21054 `t' 21055 Registers r0 and r1. 21056 21057 `y' 21058 The carry register. 21059 21060 `z' 21061 Registers r8 and r9. 21062 21063 `I' 21064 A constant between 0 and 3 inclusive. 21065 21066 `J' 21067 A constant that has exactly one bit set. 21068 21069 `K' 21070 A constant that has exactly one bit clear. 21071 21072 `L' 21073 A constant between 0 and 255 inclusive. 21074 21075 `M' 21076 A constant between -255 and 0 inclusive. 21077 21078 `N' 21079 A constant between -3 and 0 inclusive. 21080 21081 `O' 21082 A constant between 1 and 4 inclusive. 21083 21084 `P' 21085 A constant between -4 and -1 inclusive. 21086 21087 `Q' 21088 A memory reference that is a stack push. 21089 21090 `R' 21091 A memory reference that is a stack pop. 21092 21093 `S' 21094 A memory reference that refers to a constant address of known 21095 value. 21096 21097 `T' 21098 The register indicated by Rx (not implemented yet). 21099 21100 `U' 21101 A constant that is not between 2 and 15 inclusive. 21102 21103 `Z' 21104 The constant 0. 21105 21106 21107 _Xtensa--`config/xtensa/constraints.md'_ 21108 21109 `a' 21110 General-purpose 32-bit register 21111 21112 `b' 21113 One-bit boolean register 21114 21115 `A' 21116 MAC16 40-bit accumulator register 21117 21118 `I' 21119 Signed 12-bit integer constant, for use in MOVI instructions 21120 21121 `J' 21122 Signed 8-bit integer constant, for use in ADDI instructions 21123 21124 `K' 21125 Integer constant valid for BccI instructions 21126 21127 `L' 21128 Unsigned constant valid for BccUI instructions 21129 21130 21131 21132 21133 File: gccint.info, Node: Disable Insn Alternatives, Next: Machine Constraints, Prev: Modifiers, Up: Constraints 21134 21135 16.8.6 Disable insn alternatives using the `enabled' attribute 21136 -------------------------------------------------------------- 21137 21138 The `enabled' insn attribute may be used to disable certain insn 21139 alternatives for machine-specific reasons. This is useful when adding 21140 new instructions to an existing pattern which are only available for 21141 certain cpu architecture levels as specified with the `-march=' option. 21142 21143 If an insn alternative is disabled, then it will never be used. The 21144 compiler treats the constraints for the disabled alternative as 21145 unsatisfiable. 21146 21147 In order to make use of the `enabled' attribute a back end has to add 21148 in the machine description files: 21149 21150 1. A definition of the `enabled' insn attribute. The attribute is 21151 defined as usual using the `define_attr' command. This definition 21152 should be based on other insn attributes and/or target flags. The 21153 `enabled' attribute is a numeric attribute and should evaluate to 21154 `(const_int 1)' for an enabled alternative and to `(const_int 0)' 21155 otherwise. 21156 21157 2. A definition of another insn attribute used to describe for what 21158 reason an insn alternative might be available or not. E.g. 21159 `cpu_facility' as in the example below. 21160 21161 3. An assignment for the second attribute to each insn definition 21162 combining instructions which are not all available under the same 21163 circumstances. (Note: It obviously only makes sense for 21164 definitions with more than one alternative. Otherwise the insn 21165 pattern should be disabled or enabled using the insn condition.) 21166 21167 E.g. the following two patterns could easily be merged using the 21168 `enabled' attribute: 21169 21170 21171 (define_insn "*movdi_old" 21172 [(set (match_operand:DI 0 "register_operand" "=d") 21173 (match_operand:DI 1 "register_operand" " d"))] 21174 "!TARGET_NEW" 21175 "lgr %0,%1") 21176 21177 (define_insn "*movdi_new" 21178 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 21179 (match_operand:DI 1 "register_operand" " d,d,f"))] 21180 "TARGET_NEW" 21181 "@ 21182 lgr %0,%1 21183 ldgr %0,%1 21184 lgdr %0,%1") 21185 21186 to: 21187 21188 21189 (define_insn "*movdi_combined" 21190 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 21191 (match_operand:DI 1 "register_operand" " d,d,f"))] 21192 "" 21193 "@ 21194 lgr %0,%1 21195 ldgr %0,%1 21196 lgdr %0,%1" 21197 [(set_attr "cpu_facility" "*,new,new")]) 21198 21199 with the `enabled' attribute defined like this: 21200 21201 21202 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 21203 21204 (define_attr "enabled" "" 21205 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 21206 (and (eq_attr "cpu_facility" "new") 21207 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 21208 (const_int 1)] 21209 (const_int 0))) 21210 21211 21212 File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Machine Constraints, Up: Constraints 21213 21214 16.8.7 Defining Machine-Specific Constraints 21215 -------------------------------------------- 21216 21217 Machine-specific constraints fall into two categories: register and 21218 non-register constraints. Within the latter category, constraints 21219 which allow subsets of all possible memory or address operands should 21220 be specially marked, to give `reload' more information. 21221 21222 Machine-specific constraints can be given names of arbitrary length, 21223 but they must be entirely composed of letters, digits, underscores 21224 (`_'), and angle brackets (`< >'). Like C identifiers, they must begin 21225 with a letter or underscore. 21226 21227 In order to avoid ambiguity in operand constraint strings, no 21228 constraint can have a name that begins with any other constraint's 21229 name. For example, if `x' is defined as a constraint name, `xy' may 21230 not be, and vice versa. As a consequence of this rule, no constraint 21231 may begin with one of the generic constraint letters: `E F V X g i m n 21232 o p r s'. 21233 21234 Register constraints correspond directly to register classes. *Note 21235 Register Classes::. There is thus not much flexibility in their 21236 definitions. 21237 21238 -- MD Expression: define_register_constraint name regclass docstring 21239 All three arguments are string constants. NAME is the name of the 21240 constraint, as it will appear in `match_operand' expressions. If 21241 NAME is a multi-letter constraint its length shall be the same for 21242 all constraints starting with the same letter. REGCLASS can be 21243 either the name of the corresponding register class (*note 21244 Register Classes::), or a C expression which evaluates to the 21245 appropriate register class. If it is an expression, it must have 21246 no side effects, and it cannot look at the operand. The usual use 21247 of expressions is to map some register constraints to `NO_REGS' 21248 when the register class is not available on a given 21249 subarchitecture. 21250 21251 DOCSTRING is a sentence documenting the meaning of the constraint. 21252 Docstrings are explained further below. 21253 21254 Non-register constraints are more like predicates: the constraint 21255 definition gives a Boolean expression which indicates whether the 21256 constraint matches. 21257 21258 -- MD Expression: define_constraint name docstring exp 21259 The NAME and DOCSTRING arguments are the same as for 21260 `define_register_constraint', but note that the docstring comes 21261 immediately after the name for these expressions. EXP is an RTL 21262 expression, obeying the same rules as the RTL expressions in 21263 predicate definitions. *Note Defining Predicates::, for details. 21264 If it evaluates true, the constraint matches; if it evaluates 21265 false, it doesn't. Constraint expressions should indicate which 21266 RTL codes they might match, just like predicate expressions. 21267 21268 `match_test' C expressions have access to the following variables: 21269 21270 OP 21271 The RTL object defining the operand. 21272 21273 MODE 21274 The machine mode of OP. 21275 21276 IVAL 21277 `INTVAL (OP)', if OP is a `const_int'. 21278 21279 HVAL 21280 `CONST_DOUBLE_HIGH (OP)', if OP is an integer `const_double'. 21281 21282 LVAL 21283 `CONST_DOUBLE_LOW (OP)', if OP is an integer `const_double'. 21284 21285 RVAL 21286 `CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 21287 `const_double'. 21288 21289 The *VAL variables should only be used once another piece of the 21290 expression has verified that OP is the appropriate kind of RTL 21291 object. 21292 21293 Most non-register constraints should be defined with 21294 `define_constraint'. The remaining two definition expressions are only 21295 appropriate for constraints that should be handled specially by 21296 `reload' if they fail to match. 21297 21298 -- MD Expression: define_memory_constraint name docstring exp 21299 Use this expression for constraints that match a subset of all 21300 memory operands: that is, `reload' can make them match by 21301 converting the operand to the form `(mem (reg X))', where X is a 21302 base register (from the register class specified by 21303 `BASE_REG_CLASS', *note Register Classes::). 21304 21305 For example, on the S/390, some instructions do not accept 21306 arbitrary memory references, but only those that do not make use 21307 of an index register. The constraint letter `Q' is defined to 21308 represent a memory address of this type. If `Q' is defined with 21309 `define_memory_constraint', a `Q' constraint can handle any memory 21310 operand, because `reload' knows it can simply copy the memory 21311 address into a base register if required. This is analogous to 21312 the way an `o' constraint can handle any memory operand. 21313 21314 The syntax and semantics are otherwise identical to 21315 `define_constraint'. 21316 21317 -- MD Expression: define_address_constraint name docstring exp 21318 Use this expression for constraints that match a subset of all 21319 address operands: that is, `reload' can make the constraint match 21320 by converting the operand to the form `(reg X)', again with X a 21321 base register. 21322 21323 Constraints defined with `define_address_constraint' can only be 21324 used with the `address_operand' predicate, or machine-specific 21325 predicates that work the same way. They are treated analogously to 21326 the generic `p' constraint. 21327 21328 The syntax and semantics are otherwise identical to 21329 `define_constraint'. 21330 21331 For historical reasons, names beginning with the letters `G H' are 21332 reserved for constraints that match only `const_double's, and names 21333 beginning with the letters `I J K L M N O P' are reserved for 21334 constraints that match only `const_int's. This may change in the 21335 future. For the time being, constraints with these names must be 21336 written in a stylized form, so that `genpreds' can tell you did it 21337 correctly: 21338 21339 (define_constraint "[GHIJKLMNOP]..." 21340 "DOC..." 21341 (and (match_code "const_int") ; `const_double' for G/H 21342 CONDITION...)) ; usually a `match_test' 21343 21344 It is fine to use names beginning with other letters for constraints 21345 that match `const_double's or `const_int's. 21346 21347 Each docstring in a constraint definition should be one or more 21348 complete sentences, marked up in Texinfo format. _They are currently 21349 unused._ In the future they will be copied into the GCC manual, in 21350 *note Machine Constraints::, replacing the hand-maintained tables 21351 currently found in that section. Also, in the future the compiler may 21352 use this to give more helpful diagnostics when poor choice of `asm' 21353 constraints causes a reload failure. 21354 21355 If you put the pseudo-Texinfo directive `@internal' at the beginning 21356 of a docstring, then (in the future) it will appear only in the 21357 internals manual's version of the machine-specific constraint tables. 21358 Use this for constraints that should not appear in `asm' statements. 21359 21360 21361 File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 21362 21363 16.8.8 Testing constraints from C 21364 --------------------------------- 21365 21366 It is occasionally useful to test a constraint from C code rather than 21367 implicitly via the constraint string in a `match_operand'. The 21368 generated file `tm_p.h' declares a few interfaces for working with 21369 machine-specific constraints. None of these interfaces work with the 21370 generic constraints described in *note Simple Constraints::. This may 21371 change in the future. 21372 21373 *Warning:* `tm_p.h' may declare other functions that operate on 21374 constraints, besides the ones documented here. Do not use those 21375 functions from machine-dependent code. They exist to implement the old 21376 constraint interface that machine-independent components of the 21377 compiler still expect. They will change or disappear in the future. 21378 21379 Some valid constraint names are not valid C identifiers, so there is a 21380 mangling scheme for referring to them from C. Constraint names that do 21381 not contain angle brackets or underscores are left unchanged. 21382 Underscores are doubled, each `<' is replaced with `_l', and each `>' 21383 with `_g'. Here are some examples: 21384 21385 *Original* *Mangled* 21386 `x' `x' 21387 `P42x' `P42x' 21388 `P4_x' `P4__x' 21389 `P4>x' `P4_gx' 21390 `P4>>' `P4_g_g' 21391 `P4_g>' `P4__g_g' 21392 21393 Throughout this section, the variable C is either a constraint in the 21394 abstract sense, or a constant from `enum constraint_num'; the variable 21395 M is a mangled constraint name (usually as part of a larger identifier). 21396 21397 -- Enum: constraint_num 21398 For each machine-specific constraint, there is a corresponding 21399 enumeration constant: `CONSTRAINT_' plus the mangled name of the 21400 constraint. Functions that take an `enum constraint_num' as an 21401 argument expect one of these constants. 21402 21403 Machine-independent constraints do not have associated constants. 21404 This may change in the future. 21405 21406 -- Function: inline bool satisfies_constraint_M (rtx EXP) 21407 For each machine-specific, non-register constraint M, there is one 21408 of these functions; it returns `true' if EXP satisfies the 21409 constraint. These functions are only visible if `rtl.h' was 21410 included before `tm_p.h'. 21411 21412 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 21413 C) 21414 Like the `satisfies_constraint_M' functions, but the constraint to 21415 test is given as an argument, C. If C specifies a register 21416 constraint, this function will always return `false'. 21417 21418 -- Function: enum reg_class regclass_for_constraint (enum 21419 constraint_num C) 21420 Returns the register class associated with C. If C is not a 21421 register constraint, or those registers are not available for the 21422 currently selected subtarget, returns `NO_REGS'. 21423 21424 Here is an example use of `satisfies_constraint_M'. In peephole 21425 optimizations (*note Peephole Definitions::), operand constraint 21426 strings are ignored, so if there are relevant constraints, they must be 21427 tested in the C condition. In the example, the optimization is applied 21428 if operand 2 does _not_ satisfy the `K' constraint. (This is a 21429 simplified version of a peephole definition from the i386 machine 21430 description.) 21431 21432 (define_peephole2 21433 [(match_scratch:SI 3 "r") 21434 (set (match_operand:SI 0 "register_operand" "") 21435 (mult:SI (match_operand:SI 1 "memory_operand" "") 21436 (match_operand:SI 2 "immediate_operand" "")))] 21437 21438 "!satisfies_constraint_K (operands[2])" 21439 21440 [(set (match_dup 3) (match_dup 1)) 21441 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 21442 21443 "") 21444 21445 21446 File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 21447 21448 16.9 Standard Pattern Names For Generation 21449 ========================================== 21450 21451 Here is a table of the instruction names that are meaningful in the RTL 21452 generation pass of the compiler. Giving one of these names to an 21453 instruction pattern tells the RTL generation pass that it can use the 21454 pattern to accomplish a certain task. 21455 21456 `movM' 21457 Here M stands for a two-letter machine mode name, in lowercase. 21458 This instruction pattern moves data with that machine mode from 21459 operand 1 to operand 0. For example, `movsi' moves full-word data. 21460 21461 If operand 0 is a `subreg' with mode M of a register whose own 21462 mode is wider than M, the effect of this instruction is to store 21463 the specified value in the part of the register that corresponds 21464 to mode M. Bits outside of M, but which are within the same 21465 target word as the `subreg' are undefined. Bits which are outside 21466 the target word are left unchanged. 21467 21468 This class of patterns is special in several ways. First of all, 21469 each of these names up to and including full word size _must_ be 21470 defined, because there is no other way to copy a datum from one 21471 place to another. If there are patterns accepting operands in 21472 larger modes, `movM' must be defined for integer modes of those 21473 sizes. 21474 21475 Second, these patterns are not used solely in the RTL generation 21476 pass. Even the reload pass can generate move insns to copy values 21477 from stack slots into temporary registers. When it does so, one 21478 of the operands is a hard register and the other is an operand 21479 that can need to be reloaded into a register. 21480 21481 Therefore, when given such a pair of operands, the pattern must 21482 generate RTL which needs no reloading and needs no temporary 21483 registers--no registers other than the operands. For example, if 21484 you support the pattern with a `define_expand', then in such a 21485 case the `define_expand' mustn't call `force_reg' or any other such 21486 function which might generate new pseudo registers. 21487 21488 This requirement exists even for subword modes on a RISC machine 21489 where fetching those modes from memory normally requires several 21490 insns and some temporary registers. 21491 21492 During reload a memory reference with an invalid address may be 21493 passed as an operand. Such an address will be replaced with a 21494 valid address later in the reload pass. In this case, nothing may 21495 be done with the address except to use it as it stands. If it is 21496 copied, it will not be replaced with a valid address. No attempt 21497 should be made to make such an address into a valid address and no 21498 routine (such as `change_address') that will do so may be called. 21499 Note that `general_operand' will fail when applied to such an 21500 address. 21501 21502 The global variable `reload_in_progress' (which must be explicitly 21503 declared if required) can be used to determine whether such special 21504 handling is required. 21505 21506 The variety of operands that have reloads depends on the rest of 21507 the machine description, but typically on a RISC machine these can 21508 only be pseudo registers that did not get hard registers, while on 21509 other machines explicit memory references will get optional 21510 reloads. 21511 21512 If a scratch register is required to move an object to or from 21513 memory, it can be allocated using `gen_reg_rtx' prior to life 21514 analysis. 21515 21516 If there are cases which need scratch registers during or after 21517 reload, you must provide an appropriate secondary_reload target 21518 hook. 21519 21520 The macro `can_create_pseudo_p' can be used to determine if it is 21521 unsafe to create new pseudo registers. If this variable is 21522 nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new 21523 pseudo. 21524 21525 The constraints on a `movM' must permit moving any hard register 21526 to any other hard register provided that `HARD_REGNO_MODE_OK' 21527 permits mode M in both registers and `TARGET_REGISTER_MOVE_COST' 21528 applied to their classes returns a value of 2. 21529 21530 It is obligatory to support floating point `movM' instructions 21531 into and out of any registers that can hold fixed point values, 21532 because unions and structures (which have modes `SImode' or 21533 `DImode') can be in those registers and they may have floating 21534 point members. 21535 21536 There may also be a need to support fixed point `movM' 21537 instructions in and out of floating point registers. 21538 Unfortunately, I have forgotten why this was so, and I don't know 21539 whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed 21540 point values in floating point registers, then the constraints of 21541 the fixed point `movM' instructions must be designed to avoid ever 21542 trying to reload into a floating point register. 21543 21544 `reload_inM' 21545 `reload_outM' 21546 These named patterns have been obsoleted by the target hook 21547 `secondary_reload'. 21548 21549 Like `movM', but used when a scratch register is required to move 21550 between operand 0 and operand 1. Operand 2 describes the scratch 21551 register. See the discussion of the `SECONDARY_RELOAD_CLASS' 21552 macro in *note Register Classes::. 21553 21554 There are special restrictions on the form of the `match_operand's 21555 used in these patterns. First, only the predicate for the reload 21556 operand is examined, i.e., `reload_in' examines operand 1, but not 21557 the predicates for operand 0 or 2. Second, there may be only one 21558 alternative in the constraints. Third, only a single register 21559 class letter may be used for the constraint; subsequent constraint 21560 letters are ignored. As a special exception, an empty constraint 21561 string matches the `ALL_REGS' register class. This may relieve 21562 ports of the burden of defining an `ALL_REGS' constraint letter 21563 just for these patterns. 21564 21565 `movstrictM' 21566 Like `movM' except that if operand 0 is a `subreg' with mode M of 21567 a register whose natural mode is wider, the `movstrictM' 21568 instruction is guaranteed not to alter any of the register except 21569 the part which belongs to mode M. 21570 21571 `movmisalignM' 21572 This variant of a move pattern is designed to load or store a value 21573 from a memory address that is not naturally aligned for its mode. 21574 For a store, the memory will be in operand 0; for a load, the 21575 memory will be in operand 1. The other operand is guaranteed not 21576 to be a memory, so that it's easy to tell whether this is a load 21577 or store. 21578 21579 This pattern is used by the autovectorizer, and when expanding a 21580 `MISALIGNED_INDIRECT_REF' expression. 21581 21582 `load_multiple' 21583 Load several consecutive memory locations into consecutive 21584 registers. Operand 0 is the first of the consecutive registers, 21585 operand 1 is the first memory location, and operand 2 is a 21586 constant: the number of consecutive registers. 21587 21588 Define this only if the target machine really has such an 21589 instruction; do not define this if the most efficient way of 21590 loading consecutive registers from memory is to do them one at a 21591 time. 21592 21593 On some machines, there are restrictions as to which consecutive 21594 registers can be stored into memory, such as particular starting or 21595 ending register numbers or only a range of valid counts. For those 21596 machines, use a `define_expand' (*note Expander Definitions::) and 21597 make the pattern fail if the restrictions are not met. 21598 21599 Write the generated insn as a `parallel' with elements being a 21600 `set' of one register from the appropriate memory location (you may 21601 also need `use' or `clobber' elements). Use a `match_parallel' 21602 (*note RTL Template::) to recognize the insn. See `rs6000.md' for 21603 examples of the use of this insn pattern. 21604 21605 `store_multiple' 21606 Similar to `load_multiple', but store several consecutive registers 21607 into consecutive memory locations. Operand 0 is the first of the 21608 consecutive memory locations, operand 1 is the first register, and 21609 operand 2 is a constant: the number of consecutive registers. 21610 21611 `vec_setM' 21612 Set given field in the vector value. Operand 0 is the vector to 21613 modify, operand 1 is new value of field and operand 2 specify the 21614 field index. 21615 21616 `vec_extractM' 21617 Extract given field from the vector value. Operand 1 is the 21618 vector, operand 2 specify field index and operand 0 place to store 21619 value into. 21620 21621 `vec_extract_evenM' 21622 Extract even elements from the input vectors (operand 1 and 21623 operand 2). The even elements of operand 2 are concatenated to 21624 the even elements of operand 1 in their original order. The result 21625 is stored in operand 0. The output and input vectors should have 21626 the same modes. 21627 21628 `vec_extract_oddM' 21629 Extract odd elements from the input vectors (operand 1 and operand 21630 2). The odd elements of operand 2 are concatenated to the odd 21631 elements of operand 1 in their original order. The result is 21632 stored in operand 0. The output and input vectors should have the 21633 same modes. 21634 21635 `vec_interleave_highM' 21636 Merge high elements of the two input vectors into the output 21637 vector. The output and input vectors should have the same modes 21638 (`N' elements). The high `N/2' elements of the first input vector 21639 are interleaved with the high `N/2' elements of the second input 21640 vector. 21641 21642 `vec_interleave_lowM' 21643 Merge low elements of the two input vectors into the output 21644 vector. The output and input vectors should have the same modes 21645 (`N' elements). The low `N/2' elements of the first input vector 21646 are interleaved with the low `N/2' elements of the second input 21647 vector. 21648 21649 `vec_initM' 21650 Initialize the vector to given values. Operand 0 is the vector to 21651 initialize and operand 1 is parallel containing values for 21652 individual fields. 21653 21654 `pushM1' 21655 Output a push instruction. Operand 0 is value to push. Used only 21656 when `PUSH_ROUNDING' is defined. For historical reason, this 21657 pattern may be missing and in such case an `mov' expander is used 21658 instead, with a `MEM' expression forming the push operation. The 21659 `mov' expander method is deprecated. 21660 21661 `addM3' 21662 Add operand 2 and operand 1, storing the result in operand 0. All 21663 operands must have mode M. This can be used even on two-address 21664 machines, by means of constraints requiring operands 1 and 0 to be 21665 the same location. 21666 21667 `ssaddM3', `usaddM3' 21668 21669 `subM3', `sssubM3', `ussubM3' 21670 21671 `mulM3', `ssmulM3', `usmulM3' 21672 `divM3', `ssdivM3' 21673 `udivM3', `usdivM3' 21674 `modM3', `umodM3' 21675 `uminM3', `umaxM3' 21676 `andM3', `iorM3', `xorM3' 21677 Similar, for other arithmetic operations. 21678 21679 `fmaM4' 21680 Multiply operand 2 and operand 1, then add operand 3, storing the 21681 result in operand 0. All operands must have mode M. This pattern 21682 is used to implement the `fma', `fmaf', and `fmal' builtin 21683 functions from the ISO C99 standard. The `fma' operation may 21684 produce different results than doing the multiply followed by the 21685 add if the machine does not perform a rounding step between the 21686 operations. 21687 21688 `fmsM4' 21689 Like `fmaM4', except operand 3 subtracted from the product instead 21690 of added to the product. This is represented in the rtl as 21691 21692 (fma:M OP1 OP2 (neg:M OP3)) 21693 21694 `fnmaM4' 21695 Like `fmaM4' except that the intermediate product is negated 21696 before being added to operand 3. This is represented in the rtl as 21697 21698 (fma:M (neg:M OP1) OP2 OP3) 21699 21700 `fnmsM4' 21701 Like `fmsM4' except that the intermediate product is negated 21702 before subtracting operand 3. This is represented in the rtl as 21703 21704 (fma:M (neg:M OP1) OP2 (neg:M OP3)) 21705 21706 `sminM3', `smaxM3' 21707 Signed minimum and maximum operations. When used with floating 21708 point, if both operands are zeros, or if either operand is `NaN', 21709 then it is unspecified which of the two operands is returned as 21710 the result. 21711 21712 `reduc_smin_M', `reduc_smax_M' 21713 Find the signed minimum/maximum of the elements of a vector. The 21714 vector is operand 1, and the scalar result is stored in the least 21715 significant bits of operand 0 (also a vector). The output and 21716 input vector should have the same modes. 21717 21718 `reduc_umin_M', `reduc_umax_M' 21719 Find the unsigned minimum/maximum of the elements of a vector. The 21720 vector is operand 1, and the scalar result is stored in the least 21721 significant bits of operand 0 (also a vector). The output and 21722 input vector should have the same modes. 21723 21724 `reduc_splus_M' 21725 Compute the sum of the signed elements of a vector. The vector is 21726 operand 1, and the scalar result is stored in the least 21727 significant bits of operand 0 (also a vector). The output and 21728 input vector should have the same modes. 21729 21730 `reduc_uplus_M' 21731 Compute the sum of the unsigned elements of a vector. The vector 21732 is operand 1, and the scalar result is stored in the least 21733 significant bits of operand 0 (also a vector). The output and 21734 input vector should have the same modes. 21735 21736 `sdot_prodM' 21737 21738 `udot_prodM' 21739 Compute the sum of the products of two signed/unsigned elements. 21740 Operand 1 and operand 2 are of the same mode. Their product, which 21741 is of a wider mode, is computed and added to operand 3. Operand 3 21742 is of a mode equal or wider than the mode of the product. The 21743 result is placed in operand 0, which is of the same mode as 21744 operand 3. 21745 21746 `ssum_widenM3' 21747 21748 `usum_widenM3' 21749 Operands 0 and 2 are of the same mode, which is wider than the 21750 mode of operand 1. Add operand 1 to operand 2 and place the 21751 widened result in operand 0. (This is used express accumulation of 21752 elements into an accumulator of a wider mode.) 21753 21754 `vec_shl_M', `vec_shr_M' 21755 Whole vector left/right shift in bits. Operand 1 is a vector to 21756 be shifted. Operand 2 is an integer shift amount in bits. 21757 Operand 0 is where the resulting shifted vector is stored. The 21758 output and input vectors should have the same modes. 21759 21760 `vec_pack_trunc_M' 21761 Narrow (demote) and merge the elements of two vectors. Operands 1 21762 and 2 are vectors of the same mode having N integral or floating 21763 point elements of size S. Operand 0 is the resulting vector in 21764 which 2*N elements of size N/2 are concatenated after narrowing 21765 them down using truncation. 21766 21767 `vec_pack_ssat_M', `vec_pack_usat_M' 21768 Narrow (demote) and merge the elements of two vectors. Operands 1 21769 and 2 are vectors of the same mode having N integral elements of 21770 size S. Operand 0 is the resulting vector in which the elements 21771 of the two input vectors are concatenated after narrowing them 21772 down using signed/unsigned saturating arithmetic. 21773 21774 `vec_pack_sfix_trunc_M', `vec_pack_ufix_trunc_M' 21775 Narrow, convert to signed/unsigned integral type and merge the 21776 elements of two vectors. Operands 1 and 2 are vectors of the same 21777 mode having N floating point elements of size S. Operand 0 is the 21778 resulting vector in which 2*N elements of size N/2 are 21779 concatenated. 21780 21781 `vec_unpacks_hi_M', `vec_unpacks_lo_M' 21782 Extract and widen (promote) the high/low part of a vector of signed 21783 integral or floating point elements. The input vector (operand 1) 21784 has N elements of size S. Widen (promote) the high/low elements 21785 of the vector using signed or floating point extension and place 21786 the resulting N/2 values of size 2*S in the output vector (operand 21787 0). 21788 21789 `vec_unpacku_hi_M', `vec_unpacku_lo_M' 21790 Extract and widen (promote) the high/low part of a vector of 21791 unsigned integral elements. The input vector (operand 1) has N 21792 elements of size S. Widen (promote) the high/low elements of the 21793 vector using zero extension and place the resulting N/2 values of 21794 size 2*S in the output vector (operand 0). 21795 21796 `vec_unpacks_float_hi_M', `vec_unpacks_float_lo_M' 21797 `vec_unpacku_float_hi_M', `vec_unpacku_float_lo_M' 21798 Extract, convert to floating point type and widen the high/low 21799 part of a vector of signed/unsigned integral elements. The input 21800 vector (operand 1) has N elements of size S. Convert the high/low 21801 elements of the vector using floating point conversion and place 21802 the resulting N/2 values of size 2*S in the output vector (operand 21803 0). 21804 21805 `vec_widen_umult_hi_M', `vec_widen_umult_lo_M' 21806 `vec_widen_smult_hi_M', `vec_widen_smult_lo_M' 21807 Signed/Unsigned widening multiplication. The two inputs (operands 21808 1 and 2) are vectors with N signed/unsigned elements of size S. 21809 Multiply the high/low elements of the two vectors, and put the N/2 21810 products of size 2*S in the output vector (operand 0). 21811 21812 `mulhisi3' 21813 Multiply operands 1 and 2, which have mode `HImode', and store a 21814 `SImode' product in operand 0. 21815 21816 `mulqihi3', `mulsidi3' 21817 Similar widening-multiplication instructions of other widths. 21818 21819 `umulqihi3', `umulhisi3', `umulsidi3' 21820 Similar widening-multiplication instructions that do unsigned 21821 multiplication. 21822 21823 `usmulqihi3', `usmulhisi3', `usmulsidi3' 21824 Similar widening-multiplication instructions that interpret the 21825 first operand as unsigned and the second operand as signed, then 21826 do a signed multiplication. 21827 21828 `smulM3_highpart' 21829 Perform a signed multiplication of operands 1 and 2, which have 21830 mode M, and store the most significant half of the product in 21831 operand 0. The least significant half of the product is discarded. 21832 21833 `umulM3_highpart' 21834 Similar, but the multiplication is unsigned. 21835 21836 `maddMN4' 21837 Multiply operands 1 and 2, sign-extend them to mode N, add operand 21838 3, and store the result in operand 0. Operands 1 and 2 have mode 21839 M and operands 0 and 3 have mode N. Both modes must be integer or 21840 fixed-point modes and N must be twice the size of M. 21841 21842 In other words, `maddMN4' is like `mulMN3' except that it also 21843 adds operand 3. 21844 21845 These instructions are not allowed to `FAIL'. 21846 21847 `umaddMN4' 21848 Like `maddMN4', but zero-extend the multiplication operands 21849 instead of sign-extending them. 21850 21851 `ssmaddMN4' 21852 Like `maddMN4', but all involved operations must be 21853 signed-saturating. 21854 21855 `usmaddMN4' 21856 Like `umaddMN4', but all involved operations must be 21857 unsigned-saturating. 21858 21859 `msubMN4' 21860 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 21861 result from operand 3, and store the result in operand 0. 21862 Operands 1 and 2 have mode M and operands 0 and 3 have mode N. 21863 Both modes must be integer or fixed-point modes and N must be twice 21864 the size of M. 21865 21866 In other words, `msubMN4' is like `mulMN3' except that it also 21867 subtracts the result from operand 3. 21868 21869 These instructions are not allowed to `FAIL'. 21870 21871 `umsubMN4' 21872 Like `msubMN4', but zero-extend the multiplication operands 21873 instead of sign-extending them. 21874 21875 `ssmsubMN4' 21876 Like `msubMN4', but all involved operations must be 21877 signed-saturating. 21878 21879 `usmsubMN4' 21880 Like `umsubMN4', but all involved operations must be 21881 unsigned-saturating. 21882 21883 `divmodM4' 21884 Signed division that produces both a quotient and a remainder. 21885 Operand 1 is divided by operand 2 to produce a quotient stored in 21886 operand 0 and a remainder stored in operand 3. 21887 21888 For machines with an instruction that produces both a quotient and 21889 a remainder, provide a pattern for `divmodM4' but do not provide 21890 patterns for `divM3' and `modM3'. This allows optimization in the 21891 relatively common case when both the quotient and remainder are 21892 computed. 21893 21894 If an instruction that just produces a quotient or just a remainder 21895 exists and is more efficient than the instruction that produces 21896 both, write the output routine of `divmodM4' to call 21897 `find_reg_note' and look for a `REG_UNUSED' note on the quotient 21898 or remainder and generate the appropriate instruction. 21899 21900 `udivmodM4' 21901 Similar, but does unsigned division. 21902 21903 `ashlM3', `ssashlM3', `usashlM3' 21904 Arithmetic-shift operand 1 left by a number of bits specified by 21905 operand 2, and store the result in operand 0. Here M is the mode 21906 of operand 0 and operand 1; operand 2's mode is specified by the 21907 instruction pattern, and the compiler will convert the operand to 21908 that mode before generating the instruction. The meaning of 21909 out-of-range shift counts can optionally be specified by 21910 `TARGET_SHIFT_TRUNCATION_MASK'. *Note 21911 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 21912 21913 `ashrM3', `lshrM3', `rotlM3', `rotrM3' 21914 Other shift and rotate instructions, analogous to the `ashlM3' 21915 instructions. Operand 2 is always a scalar type. 21916 21917 `vashlM3', `vashrM3', `vlshrM3', `vrotlM3', `vrotrM3' 21918 Vector shift and rotate instructions that take vectors as operand 2 21919 instead of a scalar type. 21920 21921 `negM2', `ssnegM2', `usnegM2' 21922 Negate operand 1 and store the result in operand 0. 21923 21924 `absM2' 21925 Store the absolute value of operand 1 into operand 0. 21926 21927 `sqrtM2' 21928 Store the square root of operand 1 into operand 0. 21929 21930 The `sqrt' built-in function of C always uses the mode which 21931 corresponds to the C data type `double' and the `sqrtf' built-in 21932 function uses the mode which corresponds to the C data type 21933 `float'. 21934 21935 `fmodM3' 21936 Store the remainder of dividing operand 1 by operand 2 into 21937 operand 0, rounded towards zero to an integer. 21938 21939 The `fmod' built-in function of C always uses the mode which 21940 corresponds to the C data type `double' and the `fmodf' built-in 21941 function uses the mode which corresponds to the C data type 21942 `float'. 21943 21944 `remainderM3' 21945 Store the remainder of dividing operand 1 by operand 2 into 21946 operand 0, rounded to the nearest integer. 21947 21948 The `remainder' built-in function of C always uses the mode which 21949 corresponds to the C data type `double' and the `remainderf' 21950 built-in function uses the mode which corresponds to the C data 21951 type `float'. 21952 21953 `cosM2' 21954 Store the cosine of operand 1 into operand 0. 21955 21956 The `cos' built-in function of C always uses the mode which 21957 corresponds to the C data type `double' and the `cosf' built-in 21958 function uses the mode which corresponds to the C data type 21959 `float'. 21960 21961 `sinM2' 21962 Store the sine of operand 1 into operand 0. 21963 21964 The `sin' built-in function of C always uses the mode which 21965 corresponds to the C data type `double' and the `sinf' built-in 21966 function uses the mode which corresponds to the C data type 21967 `float'. 21968 21969 `expM2' 21970 Store the exponential of operand 1 into operand 0. 21971 21972 The `exp' built-in function of C always uses the mode which 21973 corresponds to the C data type `double' and the `expf' built-in 21974 function uses the mode which corresponds to the C data type 21975 `float'. 21976 21977 `logM2' 21978 Store the natural logarithm of operand 1 into operand 0. 21979 21980 The `log' built-in function of C always uses the mode which 21981 corresponds to the C data type `double' and the `logf' built-in 21982 function uses the mode which corresponds to the C data type 21983 `float'. 21984 21985 `powM3' 21986 Store the value of operand 1 raised to the exponent operand 2 into 21987 operand 0. 21988 21989 The `pow' built-in function of C always uses the mode which 21990 corresponds to the C data type `double' and the `powf' built-in 21991 function uses the mode which corresponds to the C data type 21992 `float'. 21993 21994 `atan2M3' 21995 Store the arc tangent (inverse tangent) of operand 1 divided by 21996 operand 2 into operand 0, using the signs of both arguments to 21997 determine the quadrant of the result. 21998 21999 The `atan2' built-in function of C always uses the mode which 22000 corresponds to the C data type `double' and the `atan2f' built-in 22001 function uses the mode which corresponds to the C data type 22002 `float'. 22003 22004 `floorM2' 22005 Store the largest integral value not greater than argument. 22006 22007 The `floor' built-in function of C always uses the mode which 22008 corresponds to the C data type `double' and the `floorf' built-in 22009 function uses the mode which corresponds to the C data type 22010 `float'. 22011 22012 `btruncM2' 22013 Store the argument rounded to integer towards zero. 22014 22015 The `trunc' built-in function of C always uses the mode which 22016 corresponds to the C data type `double' and the `truncf' built-in 22017 function uses the mode which corresponds to the C data type 22018 `float'. 22019 22020 `roundM2' 22021 Store the argument rounded to integer away from zero. 22022 22023 The `round' built-in function of C always uses the mode which 22024 corresponds to the C data type `double' and the `roundf' built-in 22025 function uses the mode which corresponds to the C data type 22026 `float'. 22027 22028 `ceilM2' 22029 Store the argument rounded to integer away from zero. 22030 22031 The `ceil' built-in function of C always uses the mode which 22032 corresponds to the C data type `double' and the `ceilf' built-in 22033 function uses the mode which corresponds to the C data type 22034 `float'. 22035 22036 `nearbyintM2' 22037 Store the argument rounded according to the default rounding mode 22038 22039 The `nearbyint' built-in function of C always uses the mode which 22040 corresponds to the C data type `double' and the `nearbyintf' 22041 built-in function uses the mode which corresponds to the C data 22042 type `float'. 22043 22044 `rintM2' 22045 Store the argument rounded according to the default rounding mode 22046 and raise the inexact exception when the result differs in value 22047 from the argument 22048 22049 The `rint' built-in function of C always uses the mode which 22050 corresponds to the C data type `double' and the `rintf' built-in 22051 function uses the mode which corresponds to the C data type 22052 `float'. 22053 22054 `lrintMN2' 22055 Convert operand 1 (valid for floating point mode M) to fixed point 22056 mode N as a signed number according to the current rounding mode 22057 and store in operand 0 (which has mode N). 22058 22059 `lroundMN2' 22060 Convert operand 1 (valid for floating point mode M) to fixed point 22061 mode N as a signed number rounding to nearest and away from zero 22062 and store in operand 0 (which has mode N). 22063 22064 `lfloorMN2' 22065 Convert operand 1 (valid for floating point mode M) to fixed point 22066 mode N as a signed number rounding down and store in operand 0 22067 (which has mode N). 22068 22069 `lceilMN2' 22070 Convert operand 1 (valid for floating point mode M) to fixed point 22071 mode N as a signed number rounding up and store in operand 0 22072 (which has mode N). 22073 22074 `copysignM3' 22075 Store a value with the magnitude of operand 1 and the sign of 22076 operand 2 into operand 0. 22077 22078 The `copysign' built-in function of C always uses the mode which 22079 corresponds to the C data type `double' and the `copysignf' 22080 built-in function uses the mode which corresponds to the C data 22081 type `float'. 22082 22083 `ffsM2' 22084 Store into operand 0 one plus the index of the least significant 22085 1-bit of operand 1. If operand 1 is zero, store zero. M is the 22086 mode of operand 0; operand 1's mode is specified by the instruction 22087 pattern, and the compiler will convert the operand to that mode 22088 before generating the instruction. 22089 22090 The `ffs' built-in function of C always uses the mode which 22091 corresponds to the C data type `int'. 22092 22093 `clzM2' 22094 Store into operand 0 the number of leading 0-bits in X, starting 22095 at the most significant bit position. If X is 0, the 22096 `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 22097 result is undefined or has a useful value. M is the mode of 22098 operand 0; operand 1's mode is specified by the instruction 22099 pattern, and the compiler will convert the operand to that mode 22100 before generating the instruction. 22101 22102 `ctzM2' 22103 Store into operand 0 the number of trailing 0-bits in X, starting 22104 at the least significant bit position. If X is 0, the 22105 `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 22106 result is undefined or has a useful value. M is the mode of 22107 operand 0; operand 1's mode is specified by the instruction 22108 pattern, and the compiler will convert the operand to that mode 22109 before generating the instruction. 22110 22111 `popcountM2' 22112 Store into operand 0 the number of 1-bits in X. M is the mode of 22113 operand 0; operand 1's mode is specified by the instruction 22114 pattern, and the compiler will convert the operand to that mode 22115 before generating the instruction. 22116 22117 `parityM2' 22118 Store into operand 0 the parity of X, i.e. the number of 1-bits in 22119 X modulo 2. M is the mode of operand 0; operand 1's mode is 22120 specified by the instruction pattern, and the compiler will convert 22121 the operand to that mode before generating the instruction. 22122 22123 `one_cmplM2' 22124 Store the bitwise-complement of operand 1 into operand 0. 22125 22126 `movmemM' 22127 Block move instruction. The destination and source blocks of 22128 memory are the first two operands, and both are `mem:BLK's with an 22129 address in mode `Pmode'. 22130 22131 The number of bytes to move is the third operand, in mode M. 22132 Usually, you specify `word_mode' for M. However, if you can 22133 generate better code knowing the range of valid lengths is smaller 22134 than those representable in a full word, you should provide a 22135 pattern with a mode corresponding to the range of values you can 22136 handle efficiently (e.g., `QImode' for values in the range 0-127; 22137 note we avoid numbers that appear negative) and also a pattern 22138 with `word_mode'. 22139 22140 The fourth operand is the known shared alignment of the source and 22141 destination, in the form of a `const_int' rtx. Thus, if the 22142 compiler knows that both source and destination are word-aligned, 22143 it may provide the value 4 for this operand. 22144 22145 Optional operands 5 and 6 specify expected alignment and size of 22146 block respectively. The expected alignment differs from alignment 22147 in operand 4 in a way that the blocks are not required to be 22148 aligned according to it in all cases. This expected alignment is 22149 also in bytes, just like operand 4. Expected size, when unknown, 22150 is set to `(const_int -1)'. 22151 22152 Descriptions of multiple `movmemM' patterns can only be beneficial 22153 if the patterns for smaller modes have fewer restrictions on their 22154 first, second and fourth operands. Note that the mode M in 22155 `movmemM' does not impose any restriction on the mode of 22156 individually moved data units in the block. 22157 22158 These patterns need not give special consideration to the 22159 possibility that the source and destination strings might overlap. 22160 22161 `movstr' 22162 String copy instruction, with `stpcpy' semantics. Operand 0 is an 22163 output operand in mode `Pmode'. The addresses of the destination 22164 and source strings are operands 1 and 2, and both are `mem:BLK's 22165 with addresses in mode `Pmode'. The execution of the expansion of 22166 this pattern should store in operand 0 the address in which the 22167 `NUL' terminator was stored in the destination string. 22168 22169 `setmemM' 22170 Block set instruction. The destination string is the first 22171 operand, given as a `mem:BLK' whose address is in mode `Pmode'. 22172 The number of bytes to set is the second operand, in mode M. The 22173 value to initialize the memory with is the third operand. Targets 22174 that only support the clearing of memory should reject any value 22175 that is not the constant 0. See `movmemM' for a discussion of the 22176 choice of mode. 22177 22178 The fourth operand is the known alignment of the destination, in 22179 the form of a `const_int' rtx. Thus, if the compiler knows that 22180 the destination is word-aligned, it may provide the value 4 for 22181 this operand. 22182 22183 Optional operands 5 and 6 specify expected alignment and size of 22184 block respectively. The expected alignment differs from alignment 22185 in operand 4 in a way that the blocks are not required to be 22186 aligned according to it in all cases. This expected alignment is 22187 also in bytes, just like operand 4. Expected size, when unknown, 22188 is set to `(const_int -1)'. 22189 22190 The use for multiple `setmemM' is as for `movmemM'. 22191 22192 `cmpstrnM' 22193 String compare instruction, with five operands. Operand 0 is the 22194 output; it has mode M. The remaining four operands are like the 22195 operands of `movmemM'. The two memory blocks specified are 22196 compared byte by byte in lexicographic order starting at the 22197 beginning of each string. The instruction is not allowed to 22198 prefetch more than one byte at a time since either string may end 22199 in the first byte and reading past that may access an invalid page 22200 or segment and cause a fault. The comparison terminates early if 22201 the fetched bytes are different or if they are equal to zero. The 22202 effect of the instruction is to store a value in operand 0 whose 22203 sign indicates the result of the comparison. 22204 22205 `cmpstrM' 22206 String compare instruction, without known maximum length. Operand 22207 0 is the output; it has mode M. The second and third operand are 22208 the blocks of memory to be compared; both are `mem:BLK' with an 22209 address in mode `Pmode'. 22210 22211 The fourth operand is the known shared alignment of the source and 22212 destination, in the form of a `const_int' rtx. Thus, if the 22213 compiler knows that both source and destination are word-aligned, 22214 it may provide the value 4 for this operand. 22215 22216 The two memory blocks specified are compared byte by byte in 22217 lexicographic order starting at the beginning of each string. The 22218 instruction is not allowed to prefetch more than one byte at a 22219 time since either string may end in the first byte and reading 22220 past that may access an invalid page or segment and cause a fault. 22221 The comparison will terminate when the fetched bytes are different 22222 or if they are equal to zero. The effect of the instruction is to 22223 store a value in operand 0 whose sign indicates the result of the 22224 comparison. 22225 22226 `cmpmemM' 22227 Block compare instruction, with five operands like the operands of 22228 `cmpstrM'. The two memory blocks specified are compared byte by 22229 byte in lexicographic order starting at the beginning of each 22230 block. Unlike `cmpstrM' the instruction can prefetch any bytes in 22231 the two memory blocks. Also unlike `cmpstrM' the comparison will 22232 not stop if both bytes are zero. The effect of the instruction is 22233 to store a value in operand 0 whose sign indicates the result of 22234 the comparison. 22235 22236 `strlenM' 22237 Compute the length of a string, with three operands. Operand 0 is 22238 the result (of mode M), operand 1 is a `mem' referring to the 22239 first character of the string, operand 2 is the character to 22240 search for (normally zero), and operand 3 is a constant describing 22241 the known alignment of the beginning of the string. 22242 22243 `floatMN2' 22244 Convert signed integer operand 1 (valid for fixed point mode M) to 22245 floating point mode N and store in operand 0 (which has mode N). 22246 22247 `floatunsMN2' 22248 Convert unsigned integer operand 1 (valid for fixed point mode M) 22249 to floating point mode N and store in operand 0 (which has mode N). 22250 22251 `fixMN2' 22252 Convert operand 1 (valid for floating point mode M) to fixed point 22253 mode N as a signed number and store in operand 0 (which has mode 22254 N). This instruction's result is defined only when the value of 22255 operand 1 is an integer. 22256 22257 If the machine description defines this pattern, it also needs to 22258 define the `ftrunc' pattern. 22259 22260 `fixunsMN2' 22261 Convert operand 1 (valid for floating point mode M) to fixed point 22262 mode N as an unsigned number and store in operand 0 (which has 22263 mode N). This instruction's result is defined only when the value 22264 of operand 1 is an integer. 22265 22266 `ftruncM2' 22267 Convert operand 1 (valid for floating point mode M) to an integer 22268 value, still represented in floating point mode M, and store it in 22269 operand 0 (valid for floating point mode M). 22270 22271 `fix_truncMN2' 22272 Like `fixMN2' but works for any floating point value of mode M by 22273 converting the value to an integer. 22274 22275 `fixuns_truncMN2' 22276 Like `fixunsMN2' but works for any floating point value of mode M 22277 by converting the value to an integer. 22278 22279 `truncMN2' 22280 Truncate operand 1 (valid for mode M) to mode N and store in 22281 operand 0 (which has mode N). Both modes must be fixed point or 22282 both floating point. 22283 22284 `extendMN2' 22285 Sign-extend operand 1 (valid for mode M) to mode N and store in 22286 operand 0 (which has mode N). Both modes must be fixed point or 22287 both floating point. 22288 22289 `zero_extendMN2' 22290 Zero-extend operand 1 (valid for mode M) to mode N and store in 22291 operand 0 (which has mode N). Both modes must be fixed point. 22292 22293 `fractMN2' 22294 Convert operand 1 of mode M to mode N and store in operand 0 22295 (which has mode N). Mode M and mode N could be fixed-point to 22296 fixed-point, signed integer to fixed-point, fixed-point to signed 22297 integer, floating-point to fixed-point, or fixed-point to 22298 floating-point. When overflows or underflows happen, the results 22299 are undefined. 22300 22301 `satfractMN2' 22302 Convert operand 1 of mode M to mode N and store in operand 0 22303 (which has mode N). Mode M and mode N could be fixed-point to 22304 fixed-point, signed integer to fixed-point, or floating-point to 22305 fixed-point. When overflows or underflows happen, the instruction 22306 saturates the results to the maximum or the minimum. 22307 22308 `fractunsMN2' 22309 Convert operand 1 of mode M to mode N and store in operand 0 22310 (which has mode N). Mode M and mode N could be unsigned integer 22311 to fixed-point, or fixed-point to unsigned integer. When 22312 overflows or underflows happen, the results are undefined. 22313 22314 `satfractunsMN2' 22315 Convert unsigned integer operand 1 of mode M to fixed-point mode N 22316 and store in operand 0 (which has mode N). When overflows or 22317 underflows happen, the instruction saturates the results to the 22318 maximum or the minimum. 22319 22320 `extv' 22321 Extract a bit-field from operand 1 (a register or memory operand), 22322 where operand 2 specifies the width in bits and operand 3 the 22323 starting bit, and store it in operand 0. Operand 0 must have mode 22324 `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode'; 22325 often `word_mode' is allowed only for registers. Operands 2 and 3 22326 must be valid for `word_mode'. 22327 22328 The RTL generation pass generates this instruction only with 22329 constants for operands 2 and 3 and the constant is never zero for 22330 operand 2. 22331 22332 The bit-field value is sign-extended to a full word integer before 22333 it is stored in operand 0. 22334 22335 `extzv' 22336 Like `extv' except that the bit-field value is zero-extended. 22337 22338 `insv' 22339 Store operand 3 (which must be valid for `word_mode') into a 22340 bit-field in operand 0, where operand 1 specifies the width in 22341 bits and operand 2 the starting bit. Operand 0 may have mode 22342 `byte_mode' or `word_mode'; often `word_mode' is allowed only for 22343 registers. Operands 1 and 2 must be valid for `word_mode'. 22344 22345 The RTL generation pass generates this instruction only with 22346 constants for operands 1 and 2 and the constant is never zero for 22347 operand 1. 22348 22349 `movMODEcc' 22350 Conditionally move operand 2 or operand 3 into operand 0 according 22351 to the comparison in operand 1. If the comparison is true, 22352 operand 2 is moved into operand 0, otherwise operand 3 is moved. 22353 22354 The mode of the operands being compared need not be the same as 22355 the operands being moved. Some machines, sparc64 for example, 22356 have instructions that conditionally move an integer value based 22357 on the floating point condition codes and vice versa. 22358 22359 If the machine does not have conditional move instructions, do not 22360 define these patterns. 22361 22362 `addMODEcc' 22363 Similar to `movMODEcc' but for conditional addition. Conditionally 22364 move operand 2 or (operands 2 + operand 3) into operand 0 22365 according to the comparison in operand 1. If the comparison is 22366 true, operand 2 is moved into operand 0, otherwise (operand 2 + 22367 operand 3) is moved. 22368 22369 `cstoreMODE4' 22370 Store zero or nonzero in operand 0 according to whether a 22371 comparison is true. Operand 1 is a comparison operator. Operand 22372 2 and operand 3 are the first and second operand of the 22373 comparison, respectively. You specify the mode that operand 0 22374 must have when you write the `match_operand' expression. The 22375 compiler automatically sees which mode you have used and supplies 22376 an operand of that mode. 22377 22378 The value stored for a true condition must have 1 as its low bit, 22379 or else must be negative. Otherwise the instruction is not 22380 suitable and you should omit it from the machine description. You 22381 describe to the compiler exactly which value is stored by defining 22382 the macro `STORE_FLAG_VALUE' (*note Misc::). If a description 22383 cannot be found that can be used for all the possible comparison 22384 operators, you should pick one and use a `define_expand' to map 22385 all results onto the one you chose. 22386 22387 These operations may `FAIL', but should do so only in relatively 22388 uncommon cases; if they would `FAIL' for common cases involving 22389 integer comparisons, it is best to restrict the predicates to not 22390 allow these operands. Likewise if a given comparison operator will 22391 always fail, independent of the operands (for floating-point 22392 modes, the `ordered_comparison_operator' predicate is often useful 22393 in this case). 22394 22395 If this pattern is omitted, the compiler will generate a 22396 conditional branch--for example, it may copy a constant one to the 22397 target and branching around an assignment of zero to the 22398 target--or a libcall. If the predicate for operand 1 only rejects 22399 some operators, it will also try reordering the operands and/or 22400 inverting the result value (e.g. by an exclusive OR). These 22401 possibilities could be cheaper or equivalent to the instructions 22402 used for the `cstoreMODE4' pattern followed by those required to 22403 convert a positive result from `STORE_FLAG_VALUE' to 1; in this 22404 case, you can and should make operand 1's predicate reject some 22405 operators in the `cstoreMODE4' pattern, or remove the pattern 22406 altogether from the machine description. 22407 22408 `cbranchMODE4' 22409 Conditional branch instruction combined with a compare instruction. 22410 Operand 0 is a comparison operator. Operand 1 and operand 2 are 22411 the first and second operands of the comparison, respectively. 22412 Operand 3 is a `label_ref' that refers to the label to jump to. 22413 22414 `jump' 22415 A jump inside a function; an unconditional branch. Operand 0 is 22416 the `label_ref' of the label to jump to. This pattern name is 22417 mandatory on all machines. 22418 22419 `call' 22420 Subroutine call instruction returning no value. Operand 0 is the 22421 function to call; operand 1 is the number of bytes of arguments 22422 pushed as a `const_int'; operand 2 is the number of registers used 22423 as operands. 22424 22425 On most machines, operand 2 is not actually stored into the RTL 22426 pattern. It is supplied for the sake of some RISC machines which 22427 need to put this information into the assembler code; they can put 22428 it in the RTL instead of operand 1. 22429 22430 Operand 0 should be a `mem' RTX whose address is the address of the 22431 function. Note, however, that this address can be a `symbol_ref' 22432 expression even if it would not be a legitimate memory address on 22433 the target machine. If it is also not a valid argument for a call 22434 instruction, the pattern for this operation should be a 22435 `define_expand' (*note Expander Definitions::) that places the 22436 address into a register and uses that register in the call 22437 instruction. 22438 22439 `call_value' 22440 Subroutine call instruction returning a value. Operand 0 is the 22441 hard register in which the value is returned. There are three more 22442 operands, the same as the three operands of the `call' instruction 22443 (but with numbers increased by one). 22444 22445 Subroutines that return `BLKmode' objects use the `call' insn. 22446 22447 `call_pop', `call_value_pop' 22448 Similar to `call' and `call_value', except used if defined and if 22449 `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that 22450 contains both the function call and a `set' to indicate the 22451 adjustment made to the frame pointer. 22452 22453 For machines where `RETURN_POPS_ARGS' can be nonzero, the use of 22454 these patterns increases the number of functions for which the 22455 frame pointer can be eliminated, if desired. 22456 22457 `untyped_call' 22458 Subroutine call instruction returning a value of any type. 22459 Operand 0 is the function to call; operand 1 is a memory location 22460 where the result of calling the function is to be stored; operand 22461 2 is a `parallel' expression where each element is a `set' 22462 expression that indicates the saving of a function return value 22463 into the result block. 22464 22465 This instruction pattern should be defined to support 22466 `__builtin_apply' on machines where special instructions are needed 22467 to call a subroutine with arbitrary arguments or to save the value 22468 returned. This instruction pattern is required on machines that 22469 have multiple registers that can hold a return value (i.e. 22470 `FUNCTION_VALUE_REGNO_P' is true for more than one register). 22471 22472 `return' 22473 Subroutine return instruction. This instruction pattern name 22474 should be defined only if a single instruction can do all the work 22475 of returning from a function. 22476 22477 Like the `movM' patterns, this pattern is also used after the RTL 22478 generation phase. In this case it is to support machines where 22479 multiple instructions are usually needed to return from a 22480 function, but some class of functions only requires one 22481 instruction to implement a return. Normally, the applicable 22482 functions are those which do not need to save any registers or 22483 allocate stack space. 22484 22485 For such machines, the condition specified in this pattern should 22486 only be true when `reload_completed' is nonzero and the function's 22487 epilogue would only be a single instruction. For machines with 22488 register windows, the routine `leaf_function_p' may be used to 22489 determine if a register window push is required. 22490 22491 Machines that have conditional return instructions should define 22492 patterns such as 22493 22494 (define_insn "" 22495 [(set (pc) 22496 (if_then_else (match_operator 22497 0 "comparison_operator" 22498 [(cc0) (const_int 0)]) 22499 (return) 22500 (pc)))] 22501 "CONDITION" 22502 "...") 22503 22504 where CONDITION would normally be the same condition specified on 22505 the named `return' pattern. 22506 22507 `untyped_return' 22508 Untyped subroutine return instruction. This instruction pattern 22509 should be defined to support `__builtin_return' on machines where 22510 special instructions are needed to return a value of any type. 22511 22512 Operand 0 is a memory location where the result of calling a 22513 function with `__builtin_apply' is stored; operand 1 is a 22514 `parallel' expression where each element is a `set' expression 22515 that indicates the restoring of a function return value from the 22516 result block. 22517 22518 `nop' 22519 No-op instruction. This instruction pattern name should always be 22520 defined to output a no-op in assembler code. `(const_int 0)' will 22521 do as an RTL pattern. 22522 22523 `indirect_jump' 22524 An instruction to jump to an address which is operand zero. This 22525 pattern name is mandatory on all machines. 22526 22527 `casesi' 22528 Instruction to jump through a dispatch table, including bounds 22529 checking. This instruction takes five operands: 22530 22531 1. The index to dispatch on, which has mode `SImode'. 22532 22533 2. The lower bound for indices in the table, an integer constant. 22534 22535 3. The total range of indices in the table--the largest index 22536 minus the smallest one (both inclusive). 22537 22538 4. A label that precedes the table itself. 22539 22540 5. A label to jump to if the index has a value outside the 22541 bounds. 22542 22543 The table is an `addr_vec' or `addr_diff_vec' inside of a 22544 `jump_insn'. The number of elements in the table is one plus the 22545 difference between the upper bound and the lower bound. 22546 22547 `tablejump' 22548 Instruction to jump to a variable address. This is a low-level 22549 capability which can be used to implement a dispatch table when 22550 there is no `casesi' pattern. 22551 22552 This pattern requires two operands: the address or offset, and a 22553 label which should immediately precede the jump table. If the 22554 macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 22555 the first operand is an offset which counts from the address of 22556 the table; otherwise, it is an absolute address to jump to. In 22557 either case, the first operand has mode `Pmode'. 22558 22559 The `tablejump' insn is always the last insn before the jump table 22560 it uses. Its assembler code normally has no need to use the 22561 second operand, but you should incorporate it in the RTL pattern so 22562 that the jump optimizer will not delete the table as unreachable 22563 code. 22564 22565 `decrement_and_branch_until_zero' 22566 Conditional branch instruction that decrements a register and 22567 jumps if the register is nonzero. Operand 0 is the register to 22568 decrement and test; operand 1 is the label to jump to if the 22569 register is nonzero. *Note Looping Patterns::. 22570 22571 This optional instruction pattern is only used by the combiner, 22572 typically for loops reversed by the loop optimizer when strength 22573 reduction is enabled. 22574 22575 `doloop_end' 22576 Conditional branch instruction that decrements a register and 22577 jumps if the register is nonzero. This instruction takes five 22578 operands: Operand 0 is the register to decrement and test; operand 22579 1 is the number of loop iterations as a `const_int' or 22580 `const0_rtx' if this cannot be determined until run-time; operand 22581 2 is the actual or estimated maximum number of iterations as a 22582 `const_int'; operand 3 is the number of enclosed loops as a 22583 `const_int' (an innermost loop has a value of 1); operand 4 is the 22584 label to jump to if the register is nonzero. *Note Looping 22585 Patterns::. 22586 22587 This optional instruction pattern should be defined for machines 22588 with low-overhead looping instructions as the loop optimizer will 22589 try to modify suitable loops to utilize it. If nested 22590 low-overhead looping is not supported, use a `define_expand' 22591 (*note Expander Definitions::) and make the pattern fail if 22592 operand 3 is not `const1_rtx'. Similarly, if the actual or 22593 estimated maximum number of iterations is too large for this 22594 instruction, make it fail. 22595 22596 `doloop_begin' 22597 Companion instruction to `doloop_end' required for machines that 22598 need to perform some initialization, such as loading special 22599 registers used by a low-overhead looping instruction. If 22600 initialization insns do not always need to be emitted, use a 22601 `define_expand' (*note Expander Definitions::) and make it fail. 22602 22603 `canonicalize_funcptr_for_compare' 22604 Canonicalize the function pointer in operand 1 and store the result 22605 into operand 0. 22606 22607 Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be 22608 a `reg', `mem', `symbol_ref', `const_int', etc and also has mode 22609 `Pmode'. 22610 22611 Canonicalization of a function pointer usually involves computing 22612 the address of the function which would be called if the function 22613 pointer were used in an indirect call. 22614 22615 Only define this pattern if function pointers on the target machine 22616 can have different values but still call the same function when 22617 used in an indirect call. 22618 22619 `save_stack_block' 22620 `save_stack_function' 22621 `save_stack_nonlocal' 22622 `restore_stack_block' 22623 `restore_stack_function' 22624 `restore_stack_nonlocal' 22625 Most machines save and restore the stack pointer by copying it to 22626 or from an object of mode `Pmode'. Do not define these patterns on 22627 such machines. 22628 22629 Some machines require special handling for stack pointer saves and 22630 restores. On those machines, define the patterns corresponding to 22631 the non-standard cases by using a `define_expand' (*note Expander 22632 Definitions::) that produces the required insns. The three types 22633 of saves and restores are: 22634 22635 1. `save_stack_block' saves the stack pointer at the start of a 22636 block that allocates a variable-sized object, and 22637 `restore_stack_block' restores the stack pointer when the 22638 block is exited. 22639 22640 2. `save_stack_function' and `restore_stack_function' do a 22641 similar job for the outermost block of a function and are 22642 used when the function allocates variable-sized objects or 22643 calls `alloca'. Only the epilogue uses the restored stack 22644 pointer, allowing a simpler save or restore sequence on some 22645 machines. 22646 22647 3. `save_stack_nonlocal' is used in functions that contain labels 22648 branched to by nested functions. It saves the stack pointer 22649 in such a way that the inner function can use 22650 `restore_stack_nonlocal' to restore the stack pointer. The 22651 compiler generates code to restore the frame and argument 22652 pointer registers, but some machines require saving and 22653 restoring additional data such as register window information 22654 or stack backchains. Place insns in these patterns to save 22655 and restore any such required data. 22656 22657 When saving the stack pointer, operand 0 is the save area and 22658 operand 1 is the stack pointer. The mode used to allocate the 22659 save area defaults to `Pmode' but you can override that choice by 22660 defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 22661 You must specify an integral mode, or `VOIDmode' if no save area 22662 is needed for a particular type of save (either because no save is 22663 needed or because a machine-specific save area can be used). 22664 Operand 0 is the stack pointer and operand 1 is the save area for 22665 restore operations. If `save_stack_block' is defined, operand 0 22666 must not be `VOIDmode' since these saves can be arbitrarily nested. 22667 22668 A save area is a `mem' that is at a constant offset from 22669 `virtual_stack_vars_rtx' when the stack pointer is saved for use by 22670 nonlocal gotos and a `reg' in the other two cases. 22671 22672 `allocate_stack' 22673 Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1 22674 from the stack pointer to create space for dynamically allocated 22675 data. 22676 22677 Store the resultant pointer to this space into operand 0. If you 22678 are allocating space from the main stack, do this by emitting a 22679 move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If 22680 you are allocating the space elsewhere, generate code to copy the 22681 location of the space to operand 0. In the latter case, you must 22682 ensure this space gets freed when the corresponding space on the 22683 main stack is free. 22684 22685 Do not define this pattern if all that must be done is the 22686 subtraction. Some machines require other operations such as stack 22687 probes or maintaining the back chain. Define this pattern to emit 22688 those operations in addition to updating the stack pointer. 22689 22690 `check_stack' 22691 If stack checking (*note Stack Checking::) cannot be done on your 22692 system by probing the stack, define this pattern to perform the 22693 needed check and signal an error if the stack has overflowed. The 22694 single operand is the address in the stack farthest from the 22695 current stack pointer that you need to validate. Normally, on 22696 platforms where this pattern is needed, you would obtain the stack 22697 limit from a global or thread-specific variable or register. 22698 22699 `probe_stack' 22700 If stack checking (*note Stack Checking::) can be done on your 22701 system by probing the stack but doing it with a "store zero" 22702 instruction is not valid or optimal, define this pattern to do the 22703 probing differently and signal an error if the stack has 22704 overflowed. The single operand is the memory reference in the 22705 stack that needs to be probed. 22706 22707 `nonlocal_goto' 22708 Emit code to generate a non-local goto, e.g., a jump from one 22709 function to a label in an outer function. This pattern has four 22710 arguments, each representing a value to be used in the jump. The 22711 first argument is to be loaded into the frame pointer, the second 22712 is the address to branch to (code to dispatch to the actual label), 22713 the third is the address of a location where the stack is saved, 22714 and the last is the address of the label, to be placed in the 22715 location for the incoming static chain. 22716 22717 On most machines you need not define this pattern, since GCC will 22718 already generate the correct code, which is to load the frame 22719 pointer and static chain, restore the stack (using the 22720 `restore_stack_nonlocal' pattern, if defined), and jump indirectly 22721 to the dispatcher. You need only define this pattern if this code 22722 will not work on your machine. 22723 22724 `nonlocal_goto_receiver' 22725 This pattern, if defined, contains code needed at the target of a 22726 nonlocal goto after the code already generated by GCC. You will 22727 not normally need to define this pattern. A typical reason why 22728 you might need this pattern is if some value, such as a pointer to 22729 a global table, must be restored when the frame pointer is 22730 restored. Note that a nonlocal goto only occurs within a 22731 unit-of-translation, so a global table pointer that is shared by 22732 all functions of a given module need not be restored. There are 22733 no arguments. 22734 22735 `exception_receiver' 22736 This pattern, if defined, contains code needed at the site of an 22737 exception handler that isn't needed at the site of a nonlocal 22738 goto. You will not normally need to define this pattern. A 22739 typical reason why you might need this pattern is if some value, 22740 such as a pointer to a global table, must be restored after 22741 control flow is branched to the handler of an exception. There 22742 are no arguments. 22743 22744 `builtin_setjmp_setup' 22745 This pattern, if defined, contains additional code needed to 22746 initialize the `jmp_buf'. You will not normally need to define 22747 this pattern. A typical reason why you might need this pattern is 22748 if some value, such as a pointer to a global table, must be 22749 restored. Though it is preferred that the pointer value be 22750 recalculated if possible (given the address of a label for 22751 instance). The single argument is a pointer to the `jmp_buf'. 22752 Note that the buffer is five words long and that the first three 22753 are normally used by the generic mechanism. 22754 22755 `builtin_setjmp_receiver' 22756 This pattern, if defined, contains code needed at the site of a 22757 built-in setjmp that isn't needed at the site of a nonlocal goto. 22758 You will not normally need to define this pattern. A typical 22759 reason why you might need this pattern is if some value, such as a 22760 pointer to a global table, must be restored. It takes one 22761 argument, which is the label to which builtin_longjmp transfered 22762 control; this pattern may be emitted at a small offset from that 22763 label. 22764 22765 `builtin_longjmp' 22766 This pattern, if defined, performs the entire action of the 22767 longjmp. You will not normally need to define this pattern unless 22768 you also define `builtin_setjmp_setup'. The single argument is a 22769 pointer to the `jmp_buf'. 22770 22771 `eh_return' 22772 This pattern, if defined, affects the way `__builtin_eh_return', 22773 and thence the call frame exception handling library routines, are 22774 built. It is intended to handle non-trivial actions needed along 22775 the abnormal return path. 22776 22777 The address of the exception handler to which the function should 22778 return is passed as operand to this pattern. It will normally 22779 need to copied by the pattern to some special register or memory 22780 location. If the pattern needs to determine the location of the 22781 target call frame in order to do so, it may use 22782 `EH_RETURN_STACKADJ_RTX', if defined; it will have already been 22783 assigned. 22784 22785 If this pattern is not defined, the default action will be to 22786 simply copy the return address to `EH_RETURN_HANDLER_RTX'. Either 22787 that macro or this pattern needs to be defined if call frame 22788 exception handling is to be used. 22789 22790 `prologue' 22791 This pattern, if defined, emits RTL for entry to a function. The 22792 function entry is responsible for setting up the stack frame, 22793 initializing the frame pointer register, saving callee saved 22794 registers, etc. 22795 22796 Using a prologue pattern is generally preferred over defining 22797 `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 22798 prologue. 22799 22800 The `prologue' pattern is particularly useful for targets which 22801 perform instruction scheduling. 22802 22803 `epilogue' 22804 This pattern emits RTL for exit from a function. The function 22805 exit is responsible for deallocating the stack frame, restoring 22806 callee saved registers and emitting the return instruction. 22807 22808 Using an epilogue pattern is generally preferred over defining 22809 `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 22810 epilogue. 22811 22812 The `epilogue' pattern is particularly useful for targets which 22813 perform instruction scheduling or which have delay slots for their 22814 return instruction. 22815 22816 `sibcall_epilogue' 22817 This pattern, if defined, emits RTL for exit from a function 22818 without the final branch back to the calling function. This 22819 pattern will be emitted before any sibling call (aka tail call) 22820 sites. 22821 22822 The `sibcall_epilogue' pattern must not clobber any arguments used 22823 for parameter passing or any stack slots for arguments passed to 22824 the current function. 22825 22826 `trap' 22827 This pattern, if defined, signals an error, typically by causing 22828 some kind of signal to be raised. Among other places, it is used 22829 by the Java front end to signal `invalid array index' exceptions. 22830 22831 `ctrapMM4' 22832 Conditional trap instruction. Operand 0 is a piece of RTL which 22833 performs a comparison, and operands 1 and 2 are the arms of the 22834 comparison. Operand 3 is the trap code, an integer. 22835 22836 A typical `ctrap' pattern looks like 22837 22838 (define_insn "ctrapsi4" 22839 [(trap_if (match_operator 0 "trap_operator" 22840 [(match_operand 1 "register_operand") 22841 (match_operand 2 "immediate_operand")]) 22842 (match_operand 3 "const_int_operand" "i"))] 22843 "" 22844 "...") 22845 22846 `prefetch' 22847 This pattern, if defined, emits code for a non-faulting data 22848 prefetch instruction. Operand 0 is the address of the memory to 22849 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 22850 for a write to the memory address, or a constant 0 otherwise. 22851 Operand 2 is the expected degree of temporal locality of the data 22852 and is a value between 0 and 3, inclusive; 0 means that the data 22853 has no temporal locality, so it need not be left in the cache 22854 after the access; 3 means that the data has a high degree of 22855 temporal locality and should be left in all levels of cache 22856 possible; 1 and 2 mean, respectively, a low or moderate degree of 22857 temporal locality. 22858 22859 Targets that do not support write prefetches or locality hints can 22860 ignore the values of operands 1 and 2. 22861 22862 `blockage' 22863 This pattern defines a pseudo insn that prevents the instruction 22864 scheduler from moving instructions across the boundary defined by 22865 the blockage insn. Normally an UNSPEC_VOLATILE pattern. 22866 22867 `memory_barrier' 22868 If the target memory model is not fully synchronous, then this 22869 pattern should be defined to an instruction that orders both loads 22870 and stores before the instruction with respect to loads and stores 22871 after the instruction. This pattern has no operands. 22872 22873 `sync_compare_and_swapMODE' 22874 This pattern, if defined, emits code for an atomic compare-and-swap 22875 operation. Operand 1 is the memory on which the atomic operation 22876 is performed. Operand 2 is the "old" value to be compared against 22877 the current contents of the memory location. Operand 3 is the 22878 "new" value to store in the memory if the compare succeeds. 22879 Operand 0 is the result of the operation; it should contain the 22880 contents of the memory before the operation. If the compare 22881 succeeds, this should obviously be a copy of operand 2. 22882 22883 This pattern must show that both operand 0 and operand 1 are 22884 modified. 22885 22886 This pattern must issue any memory barrier instructions such that 22887 all memory operations before the atomic operation occur before the 22888 atomic operation and all memory operations after the atomic 22889 operation occur after the atomic operation. 22890 22891 For targets where the success or failure of the compare-and-swap 22892 operation is available via the status flags, it is possible to 22893 avoid a separate compare operation and issue the subsequent branch 22894 or store-flag operation immediately after the compare-and-swap. 22895 To this end, GCC will look for a `MODE_CC' set in the output of 22896 `sync_compare_and_swapMODE'; if the machine description includes 22897 such a set, the target should also define special `cbranchcc4' 22898 and/or `cstorecc4' instructions. GCC will then be able to take 22899 the destination of the `MODE_CC' set and pass it to the 22900 `cbranchcc4' or `cstorecc4' pattern as the first operand of the 22901 comparison (the second will be `(const_int 0)'). 22902 22903 `sync_addMODE', `sync_subMODE' 22904 `sync_iorMODE', `sync_andMODE' 22905 `sync_xorMODE', `sync_nandMODE' 22906 These patterns emit code for an atomic operation on memory. 22907 Operand 0 is the memory on which the atomic operation is performed. 22908 Operand 1 is the second operand to the binary operator. 22909 22910 This pattern must issue any memory barrier instructions such that 22911 all memory operations before the atomic operation occur before the 22912 atomic operation and all memory operations after the atomic 22913 operation occur after the atomic operation. 22914 22915 If these patterns are not defined, the operation will be 22916 constructed from a compare-and-swap operation, if defined. 22917 22918 `sync_old_addMODE', `sync_old_subMODE' 22919 `sync_old_iorMODE', `sync_old_andMODE' 22920 `sync_old_xorMODE', `sync_old_nandMODE' 22921 These patterns are emit code for an atomic operation on memory, 22922 and return the value that the memory contained before the 22923 operation. Operand 0 is the result value, operand 1 is the memory 22924 on which the atomic operation is performed, and operand 2 is the 22925 second operand to the binary operator. 22926 22927 This pattern must issue any memory barrier instructions such that 22928 all memory operations before the atomic operation occur before the 22929 atomic operation and all memory operations after the atomic 22930 operation occur after the atomic operation. 22931 22932 If these patterns are not defined, the operation will be 22933 constructed from a compare-and-swap operation, if defined. 22934 22935 `sync_new_addMODE', `sync_new_subMODE' 22936 `sync_new_iorMODE', `sync_new_andMODE' 22937 `sync_new_xorMODE', `sync_new_nandMODE' 22938 These patterns are like their `sync_old_OP' counterparts, except 22939 that they return the value that exists in the memory location 22940 after the operation, rather than before the operation. 22941 22942 `sync_lock_test_and_setMODE' 22943 This pattern takes two forms, based on the capabilities of the 22944 target. In either case, operand 0 is the result of the operand, 22945 operand 1 is the memory on which the atomic operation is 22946 performed, and operand 2 is the value to set in the lock. 22947 22948 In the ideal case, this operation is an atomic exchange operation, 22949 in which the previous value in memory operand is copied into the 22950 result operand, and the value operand is stored in the memory 22951 operand. 22952 22953 For less capable targets, any value operand that is not the 22954 constant 1 should be rejected with `FAIL'. In this case the 22955 target may use an atomic test-and-set bit operation. The result 22956 operand should contain 1 if the bit was previously set and 0 if 22957 the bit was previously clear. The true contents of the memory 22958 operand are implementation defined. 22959 22960 This pattern must issue any memory barrier instructions such that 22961 the pattern as a whole acts as an acquire barrier, that is all 22962 memory operations after the pattern do not occur until the lock is 22963 acquired. 22964 22965 If this pattern is not defined, the operation will be constructed 22966 from a compare-and-swap operation, if defined. 22967 22968 `sync_lock_releaseMODE' 22969 This pattern, if defined, releases a lock set by 22970 `sync_lock_test_and_setMODE'. Operand 0 is the memory that 22971 contains the lock; operand 1 is the value to store in the lock. 22972 22973 If the target doesn't implement full semantics for 22974 `sync_lock_test_and_setMODE', any value operand which is not the 22975 constant 0 should be rejected with `FAIL', and the true contents 22976 of the memory operand are implementation defined. 22977 22978 This pattern must issue any memory barrier instructions such that 22979 the pattern as a whole acts as a release barrier, that is the lock 22980 is released only after all previous memory operations have 22981 completed. 22982 22983 If this pattern is not defined, then a `memory_barrier' pattern 22984 will be emitted, followed by a store of the value to the memory 22985 operand. 22986 22987 `stack_protect_set' 22988 This pattern, if defined, moves a `ptr_mode' value from the memory 22989 in operand 1 to the memory in operand 0 without leaving the value 22990 in a register afterward. This is to avoid leaking the value some 22991 place that an attacker might use to rewrite the stack guard slot 22992 after having clobbered it. 22993 22994 If this pattern is not defined, then a plain move pattern is 22995 generated. 22996 22997 `stack_protect_test' 22998 This pattern, if defined, compares a `ptr_mode' value from the 22999 memory in operand 1 with the memory in operand 0 without leaving 23000 the value in a register afterward and branches to operand 2 if the 23001 values weren't equal. 23002 23003 If this pattern is not defined, then a plain compare pattern and 23004 conditional branch pattern is used. 23005 23006 `clear_cache' 23007 This pattern, if defined, flushes the instruction cache for a 23008 region of memory. The region is bounded to by the Pmode pointers 23009 in operand 0 inclusive and operand 1 exclusive. 23010 23011 If this pattern is not defined, a call to the library function 23012 `__clear_cache' is used. 23013 23014 23015 23016 File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 23017 23018 16.10 When the Order of Patterns Matters 23019 ======================================== 23020 23021 Sometimes an insn can match more than one instruction pattern. Then the 23022 pattern that appears first in the machine description is the one used. 23023 Therefore, more specific patterns (patterns that will match fewer 23024 things) and faster instructions (those that will produce better code 23025 when they do match) should usually go first in the description. 23026 23027 In some cases the effect of ordering the patterns can be used to hide 23028 a pattern when it is not valid. For example, the 68000 has an 23029 instruction for converting a fullword to floating point and another for 23030 converting a byte to floating point. An instruction converting an 23031 integer to floating point could match either one. We put the pattern 23032 to convert the fullword first to make sure that one will be used rather 23033 than the other. (Otherwise a large integer might be generated as a 23034 single-byte immediate quantity, which would not work.) Instead of 23035 using this pattern ordering it would be possible to make the pattern 23036 for convert-a-byte smart enough to deal properly with any constant 23037 value. 23038 23039 23040 File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 23041 23042 16.11 Interdependence of Patterns 23043 ================================= 23044 23045 In some cases machines support instructions identical except for the 23046 machine mode of one or more operands. For example, there may be 23047 "sign-extend halfword" and "sign-extend byte" instructions whose 23048 patterns are 23049 23050 (set (match_operand:SI 0 ...) 23051 (extend:SI (match_operand:HI 1 ...))) 23052 23053 (set (match_operand:SI 0 ...) 23054 (extend:SI (match_operand:QI 1 ...))) 23055 23056 Constant integers do not specify a machine mode, so an instruction to 23057 extend a constant value could match either pattern. The pattern it 23058 actually will match is the one that appears first in the file. For 23059 correct results, this must be the one for the widest possible mode 23060 (`HImode', here). If the pattern matches the `QImode' instruction, the 23061 results will be incorrect if the constant value does not actually fit 23062 that mode. 23063 23064 Such instructions to extend constants are rarely generated because 23065 they are optimized away, but they do occasionally happen in nonoptimized 23066 compilations. 23067 23068 If a constraint in a pattern allows a constant, the reload pass may 23069 replace a register with a constant permitted by the constraint in some 23070 cases. Similarly for memory references. Because of this substitution, 23071 you should not provide separate patterns for increment and decrement 23072 instructions. Instead, they should be generated from the same pattern 23073 that supports register-register add insns by examining the operands and 23074 generating the appropriate machine instruction. 23075 23076 23077 File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 23078 23079 16.12 Defining Jump Instruction Patterns 23080 ======================================== 23081 23082 GCC does not assume anything about how the machine realizes jumps. The 23083 machine description should define a single pattern, usually a 23084 `define_expand', which expands to all the required insns. 23085 23086 Usually, this would be a comparison insn to set the condition code and 23087 a separate branch insn testing the condition code and branching or not 23088 according to its value. For many machines, however, separating 23089 compares and branches is limiting, which is why the more flexible 23090 approach with one `define_expand' is used in GCC. The machine 23091 description becomes clearer for architectures that have 23092 compare-and-branch instructions but no condition code. It also works 23093 better when different sets of comparison operators are supported by 23094 different kinds of conditional branches (e.g. integer vs. 23095 floating-point), or by conditional branches with respect to conditional 23096 stores. 23097 23098 Two separate insns are always used if the machine description 23099 represents a condition code register using the legacy RTL expression 23100 `(cc0)', and on most machines that use a separate condition code 23101 register (*note Condition Code::). For machines that use `(cc0)', in 23102 fact, the set and use of the condition code must be separate and 23103 adjacent(1), thus allowing flags in `cc_status' to be used (*note 23104 Condition Code::) and so that the comparison and branch insns could be 23105 located from each other by using the functions `prev_cc0_setter' and 23106 `next_cc0_user'. 23107 23108 Even in this case having a single entry point for conditional branches 23109 is advantageous, because it handles equally well the case where a single 23110 comparison instruction records the results of both signed and unsigned 23111 comparison of the given operands (with the branch insns coming in 23112 distinct signed and unsigned flavors) as in the x86 or SPARC, and the 23113 case where there are distinct signed and unsigned compare instructions 23114 and only one set of conditional branch instructions as in the PowerPC. 23115 23116 ---------- Footnotes ---------- 23117 23118 (1) `note' insns can separate them, though. 23119 23120 23121 File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 23122 23123 16.13 Defining Looping Instruction Patterns 23124 =========================================== 23125 23126 Some machines have special jump instructions that can be utilized to 23127 make loops more efficient. A common example is the 68000 `dbra' 23128 instruction which performs a decrement of a register and a branch if the 23129 result was greater than zero. Other machines, in particular digital 23130 signal processors (DSPs), have special block repeat instructions to 23131 provide low-overhead loop support. For example, the TI TMS320C3x/C4x 23132 DSPs have a block repeat instruction that loads special registers to 23133 mark the top and end of a loop and to count the number of loop 23134 iterations. This avoids the need for fetching and executing a 23135 `dbra'-like instruction and avoids pipeline stalls associated with the 23136 jump. 23137 23138 GCC has three special named patterns to support low overhead looping. 23139 They are `decrement_and_branch_until_zero', `doloop_begin', and 23140 `doloop_end'. The first pattern, `decrement_and_branch_until_zero', is 23141 not emitted during RTL generation but may be emitted during the 23142 instruction combination phase. This requires the assistance of the 23143 loop optimizer, using information collected during strength reduction, 23144 to reverse a loop to count down to zero. Some targets also require the 23145 loop optimizer to add a `REG_NONNEG' note to indicate that the 23146 iteration count is always positive. This is needed if the target 23147 performs a signed loop termination test. For example, the 68000 uses a 23148 pattern similar to the following for its `dbra' instruction: 23149 23150 (define_insn "decrement_and_branch_until_zero" 23151 [(set (pc) 23152 (if_then_else 23153 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") 23154 (const_int -1)) 23155 (const_int 0)) 23156 (label_ref (match_operand 1 "" "")) 23157 (pc))) 23158 (set (match_dup 0) 23159 (plus:SI (match_dup 0) 23160 (const_int -1)))] 23161 "find_reg_note (insn, REG_NONNEG, 0)" 23162 "...") 23163 23164 Note that since the insn is both a jump insn and has an output, it must 23165 deal with its own reloads, hence the `m' constraints. Also note that 23166 since this insn is generated by the instruction combination phase 23167 combining two sequential insns together into an implicit parallel insn, 23168 the iteration counter needs to be biased by the same amount as the 23169 decrement operation, in this case -1. Note that the following similar 23170 pattern will not be matched by the combiner. 23171 23172 (define_insn "decrement_and_branch_until_zero" 23173 [(set (pc) 23174 (if_then_else 23175 (ge (match_operand:SI 0 "general_operand" "+d*am") 23176 (const_int 1)) 23177 (label_ref (match_operand 1 "" "")) 23178 (pc))) 23179 (set (match_dup 0) 23180 (plus:SI (match_dup 0) 23181 (const_int -1)))] 23182 "find_reg_note (insn, REG_NONNEG, 0)" 23183 "...") 23184 23185 The other two special looping patterns, `doloop_begin' and 23186 `doloop_end', are emitted by the loop optimizer for certain 23187 well-behaved loops with a finite number of loop iterations using 23188 information collected during strength reduction. 23189 23190 The `doloop_end' pattern describes the actual looping instruction (or 23191 the implicit looping operation) and the `doloop_begin' pattern is an 23192 optional companion pattern that can be used for initialization needed 23193 for some low-overhead looping instructions. 23194 23195 Note that some machines require the actual looping instruction to be 23196 emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 23197 the true RTL for a looping instruction at the top of the loop can cause 23198 problems with flow analysis. So instead, a dummy `doloop' insn is 23199 emitted at the end of the loop. The machine dependent reorg pass checks 23200 for the presence of this `doloop' insn and then searches back to the 23201 top of the loop, where it inserts the true looping insn (provided there 23202 are no instructions in the loop which would cause problems). Any 23203 additional labels can be emitted at this point. In addition, if the 23204 desired special iteration counter register was not allocated, this 23205 machine dependent reorg pass could emit a traditional compare and jump 23206 instruction pair. 23207 23208 The essential difference between the `decrement_and_branch_until_zero' 23209 and the `doloop_end' patterns is that the loop optimizer allocates an 23210 additional pseudo register for the latter as an iteration counter. 23211 This pseudo register cannot be used within the loop (i.e., general 23212 induction variables cannot be derived from it), however, in many cases 23213 the loop induction variable may become redundant and removed by the 23214 flow pass. 23215 23216 23217 File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 23218 23219 16.14 Canonicalization of Instructions 23220 ====================================== 23221 23222 There are often cases where multiple RTL expressions could represent an 23223 operation performed by a single machine instruction. This situation is 23224 most commonly encountered with logical, branch, and multiply-accumulate 23225 instructions. In such cases, the compiler attempts to convert these 23226 multiple RTL expressions into a single canonical form to reduce the 23227 number of insn patterns required. 23228 23229 In addition to algebraic simplifications, following canonicalizations 23230 are performed: 23231 23232 * For commutative and comparison operators, a constant is always 23233 made the second operand. If a machine only supports a constant as 23234 the second operand, only patterns that match a constant in the 23235 second operand need be supplied. 23236 23237 * For associative operators, a sequence of operators will always 23238 chain to the left; for instance, only the left operand of an 23239 integer `plus' can itself be a `plus'. `and', `ior', `xor', 23240 `plus', `mult', `smin', `smax', `umin', and `umax' are associative 23241 when applied to integers, and sometimes to floating-point. 23242 23243 * For these operators, if only one operand is a `neg', `not', 23244 `mult', `plus', or `minus' expression, it will be the first 23245 operand. 23246 23247 * In combinations of `neg', `mult', `plus', and `minus', the `neg' 23248 operations (if any) will be moved inside the operations as far as 23249 possible. For instance, `(neg (mult A B))' is canonicalized as 23250 `(mult (neg A) B)', but `(plus (mult (neg B) C) A)' is 23251 canonicalized as `(minus A (mult B C))'. 23252 23253 * For the `compare' operator, a constant is always the second operand 23254 if the first argument is a condition code register or `(cc0)'. 23255 23256 * An operand of `neg', `not', `mult', `plus', or `minus' is made the 23257 first operand under the same conditions as above. 23258 23259 * `(ltu (plus A B) B)' is converted to `(ltu (plus A B) A)'. 23260 Likewise with `geu' instead of `ltu'. 23261 23262 * `(minus X (const_int N))' is converted to `(plus X (const_int 23263 -N))'. 23264 23265 * Within address computations (i.e., inside `mem'), a left shift is 23266 converted into the appropriate multiplication by a power of two. 23267 23268 * De Morgan's Law is used to move bitwise negation inside a bitwise 23269 logical-and or logical-or operation. If this results in only one 23270 operand being a `not' expression, it will be the first one. 23271 23272 A machine that has an instruction that performs a bitwise 23273 logical-and of one operand with the bitwise negation of the other 23274 should specify the pattern for that instruction as 23275 23276 (define_insn "" 23277 [(set (match_operand:M 0 ...) 23278 (and:M (not:M (match_operand:M 1 ...)) 23279 (match_operand:M 2 ...)))] 23280 "..." 23281 "...") 23282 23283 Similarly, a pattern for a "NAND" instruction should be written 23284 23285 (define_insn "" 23286 [(set (match_operand:M 0 ...) 23287 (ior:M (not:M (match_operand:M 1 ...)) 23288 (not:M (match_operand:M 2 ...))))] 23289 "..." 23290 "...") 23291 23292 In both cases, it is not necessary to include patterns for the many 23293 logically equivalent RTL expressions. 23294 23295 * The only possible RTL expressions involving both bitwise 23296 exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M 23297 (xor:M X Y))'. 23298 23299 * The sum of three items, one of which is a constant, will only 23300 appear in the form 23301 23302 (plus:M (plus:M X Y) CONSTANT) 23303 23304 * Equality comparisons of a group of bits (usually a single bit) 23305 with zero will be written using `zero_extract' rather than the 23306 equivalent `and' or `sign_extract' operations. 23307 23308 23309 Further canonicalization rules are defined in the function 23310 `commutative_operand_precedence' in `gcc/rtlanal.c'. 23311 23312 23313 File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 23314 23315 16.15 Defining RTL Sequences for Code Generation 23316 ================================================ 23317 23318 On some target machines, some standard pattern names for RTL generation 23319 cannot be handled with single insn, but a sequence of RTL insns can 23320 represent them. For these target machines, you can write a 23321 `define_expand' to specify how to generate the sequence of RTL. 23322 23323 A `define_expand' is an RTL expression that looks almost like a 23324 `define_insn'; but, unlike the latter, a `define_expand' is used only 23325 for RTL generation and it can produce more than one RTL insn. 23326 23327 A `define_expand' RTX has four operands: 23328 23329 * The name. Each `define_expand' must have a name, since the only 23330 use for it is to refer to it by name. 23331 23332 * The RTL template. This is a vector of RTL expressions representing 23333 a sequence of separate instructions. Unlike `define_insn', there 23334 is no implicit surrounding `PARALLEL'. 23335 23336 * The condition, a string containing a C expression. This 23337 expression is used to express how the availability of this pattern 23338 depends on subclasses of target machine, selected by command-line 23339 options when GCC is run. This is just like the condition of a 23340 `define_insn' that has a standard name. Therefore, the condition 23341 (if present) may not depend on the data in the insn being matched, 23342 but only the target-machine-type flags. The compiler needs to 23343 test these conditions during initialization in order to learn 23344 exactly which named instructions are available in a particular run. 23345 23346 * The preparation statements, a string containing zero or more C 23347 statements which are to be executed before RTL code is generated 23348 from the RTL template. 23349 23350 Usually these statements prepare temporary registers for use as 23351 internal operands in the RTL template, but they can also generate 23352 RTL insns directly by calling routines such as `emit_insn', etc. 23353 Any such insns precede the ones that come from the RTL template. 23354 23355 Every RTL insn emitted by a `define_expand' must match some 23356 `define_insn' in the machine description. Otherwise, the compiler will 23357 crash when trying to generate code for the insn or trying to optimize 23358 it. 23359 23360 The RTL template, in addition to controlling generation of RTL insns, 23361 also describes the operands that need to be specified when this pattern 23362 is used. In particular, it gives a predicate for each operand. 23363 23364 A true operand, which needs to be specified in order to generate RTL 23365 from the pattern, should be described with a `match_operand' in its 23366 first occurrence in the RTL template. This enters information on the 23367 operand's predicate into the tables that record such things. GCC uses 23368 the information to preload the operand into a register if that is 23369 required for valid RTL code. If the operand is referred to more than 23370 once, subsequent references should use `match_dup'. 23371 23372 The RTL template may also refer to internal "operands" which are 23373 temporary registers or labels used only within the sequence made by the 23374 `define_expand'. Internal operands are substituted into the RTL 23375 template with `match_dup', never with `match_operand'. The values of 23376 the internal operands are not passed in as arguments by the compiler 23377 when it requests use of this pattern. Instead, they are computed 23378 within the pattern, in the preparation statements. These statements 23379 compute the values and store them into the appropriate elements of 23380 `operands' so that `match_dup' can find them. 23381 23382 There are two special macros defined for use in the preparation 23383 statements: `DONE' and `FAIL'. Use them with a following semicolon, as 23384 a statement. 23385 23386 `DONE' 23387 Use the `DONE' macro to end RTL generation for the pattern. The 23388 only RTL insns resulting from the pattern on this occasion will be 23389 those already emitted by explicit calls to `emit_insn' within the 23390 preparation statements; the RTL template will not be generated. 23391 23392 `FAIL' 23393 Make the pattern fail on this occasion. When a pattern fails, it 23394 means that the pattern was not truly available. The calling 23395 routines in the compiler will try other strategies for code 23396 generation using other patterns. 23397 23398 Failure is currently supported only for binary (addition, 23399 multiplication, shifting, etc.) and bit-field (`extv', `extzv', 23400 and `insv') operations. 23401 23402 If the preparation falls through (invokes neither `DONE' nor `FAIL'), 23403 then the `define_expand' acts like a `define_insn' in that the RTL 23404 template is used to generate the insn. 23405 23406 The RTL template is not used for matching, only for generating the 23407 initial insn list. If the preparation statement always invokes `DONE' 23408 or `FAIL', the RTL template may be reduced to a simple list of 23409 operands, such as this example: 23410 23411 (define_expand "addsi3" 23412 [(match_operand:SI 0 "register_operand" "") 23413 (match_operand:SI 1 "register_operand" "") 23414 (match_operand:SI 2 "register_operand" "")] 23415 "" 23416 " 23417 { 23418 handle_add (operands[0], operands[1], operands[2]); 23419 DONE; 23420 }") 23421 23422 Here is an example, the definition of left-shift for the SPUR chip: 23423 23424 (define_expand "ashlsi3" 23425 [(set (match_operand:SI 0 "register_operand" "") 23426 (ashift:SI 23427 (match_operand:SI 1 "register_operand" "") 23428 (match_operand:SI 2 "nonmemory_operand" "")))] 23429 "" 23430 " 23431 23432 { 23433 if (GET_CODE (operands[2]) != CONST_INT 23434 || (unsigned) INTVAL (operands[2]) > 3) 23435 FAIL; 23436 }") 23437 23438 This example uses `define_expand' so that it can generate an RTL insn 23439 for shifting when the shift-count is in the supported range of 0 to 3 23440 but fail in other cases where machine insns aren't available. When it 23441 fails, the compiler tries another strategy using different patterns 23442 (such as, a library call). 23443 23444 If the compiler were able to handle nontrivial condition-strings in 23445 patterns with names, then it would be possible to use a `define_insn' 23446 in that case. Here is another case (zero-extension on the 68000) which 23447 makes more use of the power of `define_expand': 23448 23449 (define_expand "zero_extendhisi2" 23450 [(set (match_operand:SI 0 "general_operand" "") 23451 (const_int 0)) 23452 (set (strict_low_part 23453 (subreg:HI 23454 (match_dup 0) 23455 0)) 23456 (match_operand:HI 1 "general_operand" ""))] 23457 "" 23458 "operands[1] = make_safe_from (operands[1], operands[0]);") 23459 23460 Here two RTL insns are generated, one to clear the entire output operand 23461 and the other to copy the input operand into its low half. This 23462 sequence is incorrect if the input operand refers to [the old value of] 23463 the output operand, so the preparation statement makes sure this isn't 23464 so. The function `make_safe_from' copies the `operands[1]' into a 23465 temporary register if it refers to `operands[0]'. It does this by 23466 emitting another RTL insn. 23467 23468 Finally, a third example shows the use of an internal operand. 23469 Zero-extension on the SPUR chip is done by `and'-ing the result against 23470 a halfword mask. But this mask cannot be represented by a `const_int' 23471 because the constant value is too large to be legitimate on this 23472 machine. So it must be copied into a register with `force_reg' and 23473 then the register used in the `and'. 23474 23475 (define_expand "zero_extendhisi2" 23476 [(set (match_operand:SI 0 "register_operand" "") 23477 (and:SI (subreg:SI 23478 (match_operand:HI 1 "register_operand" "") 23479 0) 23480 (match_dup 2)))] 23481 "" 23482 "operands[2] 23483 = force_reg (SImode, GEN_INT (65535)); ") 23484 23485 _Note:_ If the `define_expand' is used to serve a standard binary or 23486 unary arithmetic operation or a bit-field operation, then the last insn 23487 it generates must not be a `code_label', `barrier' or `note'. It must 23488 be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn 23489 at the end, emit an insn to copy the result of the operation into 23490 itself. Such an insn will generate no code, but it can avoid problems 23491 in the compiler. 23492 23493 23494 File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 23495 23496 16.16 Defining How to Split Instructions 23497 ======================================== 23498 23499 There are two cases where you should specify how to split a pattern 23500 into multiple insns. On machines that have instructions requiring 23501 delay slots (*note Delay Slots::) or that have instructions whose 23502 output is not available for multiple cycles (*note Processor pipeline 23503 description::), the compiler phases that optimize these cases need to 23504 be able to move insns into one-instruction delay slots. However, some 23505 insns may generate more than one machine instruction. These insns 23506 cannot be placed into a delay slot. 23507 23508 Often you can rewrite the single insn as a list of individual insns, 23509 each corresponding to one machine instruction. The disadvantage of 23510 doing so is that it will cause the compilation to be slower and require 23511 more space. If the resulting insns are too complex, it may also 23512 suppress some optimizations. The compiler splits the insn if there is a 23513 reason to believe that it might improve instruction or delay slot 23514 scheduling. 23515 23516 The insn combiner phase also splits putative insns. If three insns are 23517 merged into one insn with a complex expression that cannot be matched by 23518 some `define_insn' pattern, the combiner phase attempts to split the 23519 complex pattern into two insns that are recognized. Usually it can 23520 break the complex pattern into two patterns by splitting out some 23521 subexpression. However, in some other cases, such as performing an 23522 addition of a large constant in two insns on a RISC machine, the way to 23523 split the addition into two insns is machine-dependent. 23524 23525 The `define_split' definition tells the compiler how to split a 23526 complex insn into several simpler insns. It looks like this: 23527 23528 (define_split 23529 [INSN-PATTERN] 23530 "CONDITION" 23531 [NEW-INSN-PATTERN-1 23532 NEW-INSN-PATTERN-2 23533 ...] 23534 "PREPARATION-STATEMENTS") 23535 23536 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 23537 final condition to be tested, as in a `define_insn'. When an insn 23538 matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 23539 in the insn list with the insns given by NEW-INSN-PATTERN-1, 23540 NEW-INSN-PATTERN-2, etc. 23541 23542 The PREPARATION-STATEMENTS are similar to those statements that are 23543 specified for `define_expand' (*note Expander Definitions::) and are 23544 executed before the new RTL is generated to prepare for the generated 23545 code or emit some insns whose pattern is not fixed. Unlike those in 23546 `define_expand', however, these statements must not generate any new 23547 pseudo-registers. Once reload has completed, they also must not 23548 allocate any space in the stack frame. 23549 23550 Patterns are matched against INSN-PATTERN in two different 23551 circumstances. If an insn needs to be split for delay slot scheduling 23552 or insn scheduling, the insn is already known to be valid, which means 23553 that it must have been matched by some `define_insn' and, if 23554 `reload_completed' is nonzero, is known to satisfy the constraints of 23555 that `define_insn'. In that case, the new insn patterns must also be 23556 insns that are matched by some `define_insn' and, if `reload_completed' 23557 is nonzero, must also satisfy the constraints of those definitions. 23558 23559 As an example of this usage of `define_split', consider the following 23560 example from `a29k.md', which splits a `sign_extend' from `HImode' to 23561 `SImode' into a pair of shift insns: 23562 23563 (define_split 23564 [(set (match_operand:SI 0 "gen_reg_operand" "") 23565 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 23566 "" 23567 [(set (match_dup 0) 23568 (ashift:SI (match_dup 1) 23569 (const_int 16))) 23570 (set (match_dup 0) 23571 (ashiftrt:SI (match_dup 0) 23572 (const_int 16)))] 23573 " 23574 { operands[1] = gen_lowpart (SImode, operands[1]); }") 23575 23576 When the combiner phase tries to split an insn pattern, it is always 23577 the case that the pattern is _not_ matched by any `define_insn'. The 23578 combiner pass first tries to split a single `set' expression and then 23579 the same `set' expression inside a `parallel', but followed by a 23580 `clobber' of a pseudo-reg to use as a scratch register. In these 23581 cases, the combiner expects exactly two new insn patterns to be 23582 generated. It will verify that these patterns match some `define_insn' 23583 definitions, so you need not do this test in the `define_split' (of 23584 course, there is no point in writing a `define_split' that will never 23585 produce insns that match). 23586 23587 Here is an example of this use of `define_split', taken from 23588 `rs6000.md': 23589 23590 (define_split 23591 [(set (match_operand:SI 0 "gen_reg_operand" "") 23592 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 23593 (match_operand:SI 2 "non_add_cint_operand" "")))] 23594 "" 23595 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 23596 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 23597 " 23598 { 23599 int low = INTVAL (operands[2]) & 0xffff; 23600 int high = (unsigned) INTVAL (operands[2]) >> 16; 23601 23602 if (low & 0x8000) 23603 high++, low |= 0xffff0000; 23604 23605 operands[3] = GEN_INT (high << 16); 23606 operands[4] = GEN_INT (low); 23607 }") 23608 23609 Here the predicate `non_add_cint_operand' matches any `const_int' that 23610 is _not_ a valid operand of a single add insn. The add with the 23611 smaller displacement is written so that it can be substituted into the 23612 address of a subsequent operation. 23613 23614 An example that uses a scratch register, from the same file, generates 23615 an equality comparison of a register and a large constant: 23616 23617 (define_split 23618 [(set (match_operand:CC 0 "cc_reg_operand" "") 23619 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 23620 (match_operand:SI 2 "non_short_cint_operand" ""))) 23621 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 23622 "find_single_use (operands[0], insn, 0) 23623 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 23624 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 23625 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 23626 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 23627 " 23628 { 23629 /* Get the constant we are comparing against, C, and see what it 23630 looks like sign-extended to 16 bits. Then see what constant 23631 could be XOR'ed with C to get the sign-extended value. */ 23632 23633 int c = INTVAL (operands[2]); 23634 int sextc = (c << 16) >> 16; 23635 int xorv = c ^ sextc; 23636 23637 operands[4] = GEN_INT (xorv); 23638 operands[5] = GEN_INT (sextc); 23639 }") 23640 23641 To avoid confusion, don't write a single `define_split' that accepts 23642 some insns that match some `define_insn' as well as some insns that 23643 don't. Instead, write two separate `define_split' definitions, one for 23644 the insns that are valid and one for the insns that are not valid. 23645 23646 The splitter is allowed to split jump instructions into sequence of 23647 jumps or create new jumps in while splitting non-jump instructions. As 23648 the central flowgraph and branch prediction information needs to be 23649 updated, several restriction apply. 23650 23651 Splitting of jump instruction into sequence that over by another jump 23652 instruction is always valid, as compiler expect identical behavior of 23653 new jump. When new sequence contains multiple jump instructions or new 23654 labels, more assistance is needed. Splitter is required to create only 23655 unconditional jumps, or simple conditional jump instructions. 23656 Additionally it must attach a `REG_BR_PROB' note to each conditional 23657 jump. A global variable `split_branch_probability' holds the 23658 probability of the original branch in case it was a simple conditional 23659 jump, -1 otherwise. To simplify recomputing of edge frequencies, the 23660 new sequence is required to have only forward jumps to the newly 23661 created labels. 23662 23663 For the common case where the pattern of a define_split exactly 23664 matches the pattern of a define_insn, use `define_insn_and_split'. It 23665 looks like this: 23666 23667 (define_insn_and_split 23668 [INSN-PATTERN] 23669 "CONDITION" 23670 "OUTPUT-TEMPLATE" 23671 "SPLIT-CONDITION" 23672 [NEW-INSN-PATTERN-1 23673 NEW-INSN-PATTERN-2 23674 ...] 23675 "PREPARATION-STATEMENTS" 23676 [INSN-ATTRIBUTES]) 23677 23678 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 23679 as in `define_insn'. The NEW-INSN-PATTERN vector and the 23680 PREPARATION-STATEMENTS are used as in a `define_split'. The 23681 SPLIT-CONDITION is also used as in `define_split', with the additional 23682 behavior that if the condition starts with `&&', the condition used for 23683 the split will be the constructed as a logical "and" of the split 23684 condition with the insn condition. For example, from i386.md: 23685 23686 (define_insn_and_split "zero_extendhisi2_and" 23687 [(set (match_operand:SI 0 "register_operand" "=r") 23688 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 23689 (clobber (reg:CC 17))] 23690 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 23691 "#" 23692 "&& reload_completed" 23693 [(parallel [(set (match_dup 0) 23694 (and:SI (match_dup 0) (const_int 65535))) 23695 (clobber (reg:CC 17))])] 23696 "" 23697 [(set_attr "type" "alu1")]) 23698 23699 In this case, the actual split condition will be 23700 `TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 23701 23702 The `define_insn_and_split' construction provides exactly the same 23703 functionality as two separate `define_insn' and `define_split' 23704 patterns. It exists for compactness, and as a maintenance tool to 23705 prevent having to ensure the two patterns' templates match. 23706 23707 23708 File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 23709 23710 16.17 Including Patterns in Machine Descriptions. 23711 ================================================= 23712 23713 The `include' pattern tells the compiler tools where to look for 23714 patterns that are in files other than in the file `.md'. This is used 23715 only at build time and there is no preprocessing allowed. 23716 23717 It looks like: 23718 23719 23720 (include 23721 PATHNAME) 23722 23723 For example: 23724 23725 23726 (include "filestuff") 23727 23728 Where PATHNAME is a string that specifies the location of the file, 23729 specifies the include file to be in `gcc/config/target/filestuff'. The 23730 directory `gcc/config/target' is regarded as the default directory. 23731 23732 Machine descriptions may be split up into smaller more manageable 23733 subsections and placed into subdirectories. 23734 23735 By specifying: 23736 23737 23738 (include "BOGUS/filestuff") 23739 23740 the include file is specified to be in 23741 `gcc/config/TARGET/BOGUS/filestuff'. 23742 23743 Specifying an absolute path for the include file such as; 23744 23745 (include "/u2/BOGUS/filestuff") 23746 is permitted but is not encouraged. 23747 23748 16.17.1 RTL Generation Tool Options for Directory Search 23749 -------------------------------------------------------- 23750 23751 The `-IDIR' option specifies directories to search for machine 23752 descriptions. For example: 23753 23754 23755 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 23756 23757 Add the directory DIR to the head of the list of directories to be 23758 searched for header files. This can be used to override a system 23759 machine definition file, substituting your own version, since these 23760 directories are searched before the default machine description file 23761 directories. If you use more than one `-I' option, the directories are 23762 scanned in left-to-right order; the standard default directory come 23763 after. 23764 23765 23766 File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 23767 23768 16.18 Machine-Specific Peephole Optimizers 23769 ========================================== 23770 23771 In addition to instruction patterns the `md' file may contain 23772 definitions of machine-specific peephole optimizations. 23773 23774 The combiner does not notice certain peephole optimizations when the 23775 data flow in the program does not suggest that it should try them. For 23776 example, sometimes two consecutive insns related in purpose can be 23777 combined even though the second one does not appear to use a register 23778 computed in the first one. A machine-specific peephole optimizer can 23779 detect such opportunities. 23780 23781 There are two forms of peephole definitions that may be used. The 23782 original `define_peephole' is run at assembly output time to match 23783 insns and substitute assembly text. Use of `define_peephole' is 23784 deprecated. 23785 23786 A newer `define_peephole2' matches insns and substitutes new insns. 23787 The `peephole2' pass is run after register allocation but before 23788 scheduling, which may result in much better code for targets that do 23789 scheduling. 23790 23791 * Menu: 23792 23793 * define_peephole:: RTL to Text Peephole Optimizers 23794 * define_peephole2:: RTL to RTL Peephole Optimizers 23795 23796 23797 File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 23798 23799 16.18.1 RTL to Text Peephole Optimizers 23800 --------------------------------------- 23801 23802 A definition looks like this: 23803 23804 (define_peephole 23805 [INSN-PATTERN-1 23806 INSN-PATTERN-2 23807 ...] 23808 "CONDITION" 23809 "TEMPLATE" 23810 "OPTIONAL-INSN-ATTRIBUTES") 23811 23812 The last string operand may be omitted if you are not using any 23813 machine-specific information in this machine description. If present, 23814 it must obey the same rules as in a `define_insn'. 23815 23816 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 23817 consecutive insns. The optimization applies to a sequence of insns when 23818 INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 23819 and so on. 23820 23821 Each of the insns matched by a peephole must also match a 23822 `define_insn'. Peepholes are checked only at the last stage just 23823 before code generation, and only optionally. Therefore, any insn which 23824 would match a peephole but no `define_insn' will cause a crash in code 23825 generation in an unoptimized compilation, or at various optimization 23826 stages. 23827 23828 The operands of the insns are matched with `match_operands', 23829 `match_operator', and `match_dup', as usual. What is not usual is that 23830 the operand numbers apply to all the insn patterns in the definition. 23831 So, you can check for identical operands in two insns by using 23832 `match_operand' in one insn and `match_dup' in the other. 23833 23834 The operand constraints used in `match_operand' patterns do not have 23835 any direct effect on the applicability of the peephole, but they will 23836 be validated afterward, so make sure your constraints are general enough 23837 to apply whenever the peephole matches. If the peephole matches but 23838 the constraints are not satisfied, the compiler will crash. 23839 23840 It is safe to omit constraints in all the operands of the peephole; or 23841 you can write constraints which serve as a double-check on the criteria 23842 previously tested. 23843 23844 Once a sequence of insns matches the patterns, the CONDITION is 23845 checked. This is a C expression which makes the final decision whether 23846 to perform the optimization (we do so if the expression is nonzero). If 23847 CONDITION is omitted (in other words, the string is empty) then the 23848 optimization is applied to every sequence of insns that matches the 23849 patterns. 23850 23851 The defined peephole optimizations are applied after register 23852 allocation is complete. Therefore, the peephole definition can check 23853 which operands have ended up in which kinds of registers, just by 23854 looking at the operands. 23855 23856 The way to refer to the operands in CONDITION is to write 23857 `operands[I]' for operand number I (as matched by `(match_operand I 23858 ...)'). Use the variable `insn' to refer to the last of the insns 23859 being matched; use `prev_active_insn' to find the preceding insns. 23860 23861 When optimizing computations with intermediate results, you can use 23862 CONDITION to match only when the intermediate results are not used 23863 elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN 23864 is the insn in which you expect the value to be used for the last time 23865 (from the value of `insn', together with use of `prev_nonnote_insn'), 23866 and OP is the intermediate value (from `operands[I]'). 23867 23868 Applying the optimization means replacing the sequence of insns with 23869 one new insn. The TEMPLATE controls ultimate output of assembler code 23870 for this combined insn. It works exactly like the template of a 23871 `define_insn'. Operand numbers in this template are the same ones used 23872 in matching the original sequence of insns. 23873 23874 The result of a defined peephole optimizer does not need to match any 23875 of the insn patterns in the machine description; it does not even have 23876 an opportunity to match them. The peephole optimizer definition itself 23877 serves as the insn pattern to control how the insn is output. 23878 23879 Defined peephole optimizers are run as assembler code is being output, 23880 so the insns they produce are never combined or rearranged in any way. 23881 23882 Here is an example, taken from the 68000 machine description: 23883 23884 (define_peephole 23885 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 23886 (set (match_operand:DF 0 "register_operand" "=f") 23887 (match_operand:DF 1 "register_operand" "ad"))] 23888 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 23889 { 23890 rtx xoperands[2]; 23891 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 23892 #ifdef MOTOROLA 23893 output_asm_insn ("move.l %1,(sp)", xoperands); 23894 output_asm_insn ("move.l %1,-(sp)", operands); 23895 return "fmove.d (sp)+,%0"; 23896 #else 23897 output_asm_insn ("movel %1,sp@", xoperands); 23898 output_asm_insn ("movel %1,sp@-", operands); 23899 return "fmoved sp@+,%0"; 23900 #endif 23901 }) 23902 23903 The effect of this optimization is to change 23904 23905 jbsr _foobar 23906 addql #4,sp 23907 movel d1,sp@- 23908 movel d0,sp@- 23909 fmoved sp@+,fp0 23910 23911 into 23912 23913 jbsr _foobar 23914 movel d1,sp@ 23915 movel d0,sp@- 23916 fmoved sp@+,fp0 23917 23918 INSN-PATTERN-1 and so on look _almost_ like the second operand of 23919 `define_insn'. There is one important difference: the second operand 23920 of `define_insn' consists of one or more RTX's enclosed in square 23921 brackets. Usually, there is only one: then the same action can be 23922 written as an element of a `define_peephole'. But when there are 23923 multiple actions in a `define_insn', they are implicitly enclosed in a 23924 `parallel'. Then you must explicitly write the `parallel', and the 23925 square brackets within it, in the `define_peephole'. Thus, if an insn 23926 pattern looks like this, 23927 23928 (define_insn "divmodsi4" 23929 [(set (match_operand:SI 0 "general_operand" "=d") 23930 (div:SI (match_operand:SI 1 "general_operand" "0") 23931 (match_operand:SI 2 "general_operand" "dmsK"))) 23932 (set (match_operand:SI 3 "general_operand" "=d") 23933 (mod:SI (match_dup 1) (match_dup 2)))] 23934 "TARGET_68020" 23935 "divsl%.l %2,%3:%0") 23936 23937 then the way to mention this insn in a peephole is as follows: 23938 23939 (define_peephole 23940 [... 23941 (parallel 23942 [(set (match_operand:SI 0 "general_operand" "=d") 23943 (div:SI (match_operand:SI 1 "general_operand" "0") 23944 (match_operand:SI 2 "general_operand" "dmsK"))) 23945 (set (match_operand:SI 3 "general_operand" "=d") 23946 (mod:SI (match_dup 1) (match_dup 2)))]) 23947 ...] 23948 ...) 23949 23950 23951 File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 23952 23953 16.18.2 RTL to RTL Peephole Optimizers 23954 -------------------------------------- 23955 23956 The `define_peephole2' definition tells the compiler how to substitute 23957 one sequence of instructions for another sequence, what additional 23958 scratch registers may be needed and what their lifetimes must be. 23959 23960 (define_peephole2 23961 [INSN-PATTERN-1 23962 INSN-PATTERN-2 23963 ...] 23964 "CONDITION" 23965 [NEW-INSN-PATTERN-1 23966 NEW-INSN-PATTERN-2 23967 ...] 23968 "PREPARATION-STATEMENTS") 23969 23970 The definition is almost identical to `define_split' (*note Insn 23971 Splitting::) except that the pattern to match is not a single 23972 instruction, but a sequence of instructions. 23973 23974 It is possible to request additional scratch registers for use in the 23975 output template. If appropriate registers are not free, the pattern 23976 will simply not match. 23977 23978 Scratch registers are requested with a `match_scratch' pattern at the 23979 top level of the input pattern. The allocated register (initially) will 23980 be dead at the point requested within the original sequence. If the 23981 scratch is used at more than a single point, a `match_dup' pattern at 23982 the top level of the input pattern marks the last position in the input 23983 sequence at which the register must be available. 23984 23985 Here is an example from the IA-32 machine description: 23986 23987 (define_peephole2 23988 [(match_scratch:SI 2 "r") 23989 (parallel [(set (match_operand:SI 0 "register_operand" "") 23990 (match_operator:SI 3 "arith_or_logical_operator" 23991 [(match_dup 0) 23992 (match_operand:SI 1 "memory_operand" "")])) 23993 (clobber (reg:CC 17))])] 23994 "! optimize_size && ! TARGET_READ_MODIFY" 23995 [(set (match_dup 2) (match_dup 1)) 23996 (parallel [(set (match_dup 0) 23997 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 23998 (clobber (reg:CC 17))])] 23999 "") 24000 24001 This pattern tries to split a load from its use in the hopes that we'll 24002 be able to schedule around the memory load latency. It allocates a 24003 single `SImode' register of class `GENERAL_REGS' (`"r"') that needs to 24004 be live only at the point just before the arithmetic. 24005 24006 A real example requiring extended scratch lifetimes is harder to come 24007 by, so here's a silly made-up example: 24008 24009 (define_peephole2 24010 [(match_scratch:SI 4 "r") 24011 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 24012 (set (match_operand:SI 2 "" "") (match_dup 1)) 24013 (match_dup 4) 24014 (set (match_operand:SI 3 "" "") (match_dup 1))] 24015 "/* determine 1 does not overlap 0 and 2 */" 24016 [(set (match_dup 4) (match_dup 1)) 24017 (set (match_dup 0) (match_dup 4)) 24018 (set (match_dup 2) (match_dup 4))] 24019 (set (match_dup 3) (match_dup 4))] 24020 "") 24021 24022 If we had not added the `(match_dup 4)' in the middle of the input 24023 sequence, it might have been the case that the register we chose at the 24024 beginning of the sequence is killed by the first or second `set'. 24025 24026 24027 File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 24028 24029 16.19 Instruction Attributes 24030 ============================ 24031 24032 In addition to describing the instruction supported by the target 24033 machine, the `md' file also defines a group of "attributes" and a set of 24034 values for each. Every generated insn is assigned a value for each 24035 attribute. One possible attribute would be the effect that the insn 24036 has on the machine's condition code. This attribute can then be used 24037 by `NOTICE_UPDATE_CC' to track the condition codes. 24038 24039 * Menu: 24040 24041 * Defining Attributes:: Specifying attributes and their values. 24042 * Expressions:: Valid expressions for attribute values. 24043 * Tagging Insns:: Assigning attribute values to insns. 24044 * Attr Example:: An example of assigning attributes. 24045 * Insn Lengths:: Computing the length of insns. 24046 * Constant Attributes:: Defining attributes that are constant. 24047 * Delay Slots:: Defining delay slots required for a machine. 24048 * Processor pipeline description:: Specifying information for insn scheduling. 24049 24050 24051 File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 24052 24053 16.19.1 Defining Attributes and their Values 24054 -------------------------------------------- 24055 24056 The `define_attr' expression is used to define each attribute required 24057 by the target machine. It looks like: 24058 24059 (define_attr NAME LIST-OF-VALUES DEFAULT) 24060 24061 NAME is a string specifying the name of the attribute being defined. 24062 24063 LIST-OF-VALUES is either a string that specifies a comma-separated 24064 list of values that can be assigned to the attribute, or a null string 24065 to indicate that the attribute takes numeric values. 24066 24067 DEFAULT is an attribute expression that gives the value of this 24068 attribute for insns that match patterns whose definition does not 24069 include an explicit value for this attribute. *Note Attr Example::, 24070 for more information on the handling of defaults. *Note Constant 24071 Attributes::, for information on attributes that do not depend on any 24072 particular insn. 24073 24074 For each defined attribute, a number of definitions are written to the 24075 `insn-attr.h' file. For cases where an explicit set of values is 24076 specified for an attribute, the following are defined: 24077 24078 * A `#define' is written for the symbol `HAVE_ATTR_NAME'. 24079 24080 * An enumerated class is defined for `attr_NAME' with elements of 24081 the form `UPPER-NAME_UPPER-VALUE' where the attribute name and 24082 value are first converted to uppercase. 24083 24084 * A function `get_attr_NAME' is defined that is passed an insn and 24085 returns the attribute value for that insn. 24086 24087 For example, if the following is present in the `md' file: 24088 24089 (define_attr "type" "branch,fp,load,store,arith" ...) 24090 24091 the following lines will be written to the file `insn-attr.h'. 24092 24093 #define HAVE_ATTR_type 24094 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 24095 TYPE_STORE, TYPE_ARITH}; 24096 extern enum attr_type get_attr_type (); 24097 24098 If the attribute takes numeric values, no `enum' type will be defined 24099 and the function to obtain the attribute's value will return `int'. 24100 24101 There are attributes which are tied to a specific meaning. These 24102 attributes are not free to use for other purposes: 24103 24104 `length' 24105 The `length' attribute is used to calculate the length of emitted 24106 code chunks. This is especially important when verifying branch 24107 distances. *Note Insn Lengths::. 24108 24109 `enabled' 24110 The `enabled' attribute can be defined to prevent certain 24111 alternatives of an insn definition from being used during code 24112 generation. *Note Disable Insn Alternatives::. 24113 24114 Another way of defining an attribute is to use: 24115 24116 (define_enum_attr "ATTR" "ENUM" DEFAULT) 24117 24118 This works in just the same way as `define_attr', except that the list 24119 of values is taken from a separate enumeration called ENUM (*note 24120 define_enum::). This form allows you to use the same list of values 24121 for several attributes without having to repeat the list each time. 24122 For example: 24123 24124 (define_enum "processor" [ 24125 model_a 24126 model_b 24127 ... 24128 ]) 24129 (define_enum_attr "arch" "processor" 24130 (const (symbol_ref "target_arch"))) 24131 (define_enum_attr "tune" "processor" 24132 (const (symbol_ref "target_tune"))) 24133 24134 defines the same attributes as: 24135 24136 (define_attr "arch" "model_a,model_b,..." 24137 (const (symbol_ref "target_arch"))) 24138 (define_attr "tune" "model_a,model_b,..." 24139 (const (symbol_ref "target_tune"))) 24140 24141 but without duplicating the processor list. The second example 24142 defines two separate C enums (`attr_arch' and `attr_tune') whereas the 24143 first defines a single C enum (`processor'). 24144 24145 24146 File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 24147 24148 16.19.2 Attribute Expressions 24149 ----------------------------- 24150 24151 RTL expressions used to define attributes use the codes described above 24152 plus a few specific to attribute definitions, to be discussed below. 24153 Attribute value expressions must have one of the following forms: 24154 24155 `(const_int I)' 24156 The integer I specifies the value of a numeric attribute. I must 24157 be non-negative. 24158 24159 The value of a numeric attribute can be specified either with a 24160 `const_int', or as an integer represented as a string in 24161 `const_string', `eq_attr' (see below), `attr', `symbol_ref', 24162 simple arithmetic expressions, and `set_attr' overrides on 24163 specific instructions (*note Tagging Insns::). 24164 24165 `(const_string VALUE)' 24166 The string VALUE specifies a constant attribute value. If VALUE 24167 is specified as `"*"', it means that the default value of the 24168 attribute is to be used for the insn containing this expression. 24169 `"*"' obviously cannot be used in the DEFAULT expression of a 24170 `define_attr'. 24171 24172 If the attribute whose value is being specified is numeric, VALUE 24173 must be a string containing a non-negative integer (normally 24174 `const_int' would be used in this case). Otherwise, it must 24175 contain one of the valid values for the attribute. 24176 24177 `(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 24178 TEST specifies an attribute test, whose format is defined below. 24179 The value of this expression is TRUE-VALUE if TEST is true, 24180 otherwise it is FALSE-VALUE. 24181 24182 `(cond [TEST1 VALUE1 ...] DEFAULT)' 24183 The first operand of this expression is a vector containing an even 24184 number of expressions and consisting of pairs of TEST and VALUE 24185 expressions. The value of the `cond' expression is that of the 24186 VALUE corresponding to the first true TEST expression. If none of 24187 the TEST expressions are true, the value of the `cond' expression 24188 is that of the DEFAULT expression. 24189 24190 TEST expressions can have one of the following forms: 24191 24192 `(const_int I)' 24193 This test is true if I is nonzero and false otherwise. 24194 24195 `(not TEST)' 24196 `(ior TEST1 TEST2)' 24197 `(and TEST1 TEST2)' 24198 These tests are true if the indicated logical function is true. 24199 24200 `(match_operand:M N PRED CONSTRAINTS)' 24201 This test is true if operand N of the insn whose attribute value 24202 is being determined has mode M (this part of the test is ignored 24203 if M is `VOIDmode') and the function specified by the string PRED 24204 returns a nonzero value when passed operand N and mode M (this 24205 part of the test is ignored if PRED is the null string). 24206 24207 The CONSTRAINTS operand is ignored and should be the null string. 24208 24209 `(le ARITH1 ARITH2)' 24210 `(leu ARITH1 ARITH2)' 24211 `(lt ARITH1 ARITH2)' 24212 `(ltu ARITH1 ARITH2)' 24213 `(gt ARITH1 ARITH2)' 24214 `(gtu ARITH1 ARITH2)' 24215 `(ge ARITH1 ARITH2)' 24216 `(geu ARITH1 ARITH2)' 24217 `(ne ARITH1 ARITH2)' 24218 `(eq ARITH1 ARITH2)' 24219 These tests are true if the indicated comparison of the two 24220 arithmetic expressions is true. Arithmetic expressions are formed 24221 with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and', 24222 `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt' 24223 expressions. 24224 24225 `const_int' and `symbol_ref' are always valid terms (*note Insn 24226 Lengths::,for additional forms). `symbol_ref' is a string 24227 denoting a C expression that yields an `int' when evaluated by the 24228 `get_attr_...' routine. It should normally be a global variable. 24229 24230 `(eq_attr NAME VALUE)' 24231 NAME is a string specifying the name of an attribute. 24232 24233 VALUE is a string that is either a valid value for attribute NAME, 24234 a comma-separated list of values, or `!' followed by a value or 24235 list. If VALUE does not begin with a `!', this test is true if 24236 the value of the NAME attribute of the current insn is in the list 24237 specified by VALUE. If VALUE begins with a `!', this test is true 24238 if the attribute's value is _not_ in the specified list. 24239 24240 For example, 24241 24242 (eq_attr "type" "load,store") 24243 24244 is equivalent to 24245 24246 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 24247 24248 If NAME specifies an attribute of `alternative', it refers to the 24249 value of the compiler variable `which_alternative' (*note Output 24250 Statement::) and the values must be small integers. For example, 24251 24252 (eq_attr "alternative" "2,3") 24253 24254 is equivalent to 24255 24256 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 24257 (eq (symbol_ref "which_alternative") (const_int 3))) 24258 24259 Note that, for most attributes, an `eq_attr' test is simplified in 24260 cases where the value of the attribute being tested is known for 24261 all insns matching a particular pattern. This is by far the most 24262 common case. 24263 24264 `(attr_flag NAME)' 24265 The value of an `attr_flag' expression is true if the flag 24266 specified by NAME is true for the `insn' currently being scheduled. 24267 24268 NAME is a string specifying one of a fixed set of flags to test. 24269 Test the flags `forward' and `backward' to determine the direction 24270 of a conditional branch. Test the flags `very_likely', `likely', 24271 `very_unlikely', and `unlikely' to determine if a conditional 24272 branch is expected to be taken. 24273 24274 If the `very_likely' flag is true, then the `likely' flag is also 24275 true. Likewise for the `very_unlikely' and `unlikely' flags. 24276 24277 This example describes a conditional branch delay slot which can 24278 be nullified for forward branches that are taken (annul-true) or 24279 for backward branches which are not taken (annul-false). 24280 24281 (define_delay (eq_attr "type" "cbranch") 24282 [(eq_attr "in_branch_delay" "true") 24283 (and (eq_attr "in_branch_delay" "true") 24284 (attr_flag "forward")) 24285 (and (eq_attr "in_branch_delay" "true") 24286 (attr_flag "backward"))]) 24287 24288 The `forward' and `backward' flags are false if the current `insn' 24289 being scheduled is not a conditional branch. 24290 24291 The `very_likely' and `likely' flags are true if the `insn' being 24292 scheduled is not a conditional branch. The `very_unlikely' and 24293 `unlikely' flags are false if the `insn' being scheduled is not a 24294 conditional branch. 24295 24296 `attr_flag' is only used during delay slot scheduling and has no 24297 meaning to other passes of the compiler. 24298 24299 `(attr NAME)' 24300 The value of another attribute is returned. This is most useful 24301 for numeric attributes, as `eq_attr' and `attr_flag' produce more 24302 efficient code for non-numeric attributes. 24303 24304 24305 File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 24306 24307 16.19.3 Assigning Attribute Values to Insns 24308 ------------------------------------------- 24309 24310 The value assigned to an attribute of an insn is primarily determined by 24311 which pattern is matched by that insn (or which `define_peephole' 24312 generated it). Every `define_insn' and `define_peephole' can have an 24313 optional last argument to specify the values of attributes for matching 24314 insns. The value of any attribute not specified in a particular insn 24315 is set to the default value for that attribute, as specified in its 24316 `define_attr'. Extensive use of default values for attributes permits 24317 the specification of the values for only one or two attributes in the 24318 definition of most insn patterns, as seen in the example in the next 24319 section. 24320 24321 The optional last argument of `define_insn' and `define_peephole' is a 24322 vector of expressions, each of which defines the value for a single 24323 attribute. The most general way of assigning an attribute's value is 24324 to use a `set' expression whose first operand is an `attr' expression 24325 giving the name of the attribute being set. The second operand of the 24326 `set' is an attribute expression (*note Expressions::) giving the value 24327 of the attribute. 24328 24329 When the attribute value depends on the `alternative' attribute (i.e., 24330 which is the applicable alternative in the constraint of the insn), the 24331 `set_attr_alternative' expression can be used. It allows the 24332 specification of a vector of attribute expressions, one for each 24333 alternative. 24334 24335 When the generality of arbitrary attribute expressions is not required, 24336 the simpler `set_attr' expression can be used, which allows specifying 24337 a string giving either a single attribute value or a list of attribute 24338 values, one for each alternative. 24339 24340 The form of each of the above specifications is shown below. In each 24341 case, NAME is a string specifying the attribute to be set. 24342 24343 `(set_attr NAME VALUE-STRING)' 24344 VALUE-STRING is either a string giving the desired attribute value, 24345 or a string containing a comma-separated list giving the values for 24346 succeeding alternatives. The number of elements must match the 24347 number of alternatives in the constraint of the insn pattern. 24348 24349 Note that it may be useful to specify `*' for some alternative, in 24350 which case the attribute will assume its default value for insns 24351 matching that alternative. 24352 24353 `(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 24354 Depending on the alternative of the insn, the value will be one of 24355 the specified values. This is a shorthand for using a `cond' with 24356 tests on the `alternative' attribute. 24357 24358 `(set (attr NAME) VALUE)' 24359 The first operand of this `set' must be the special RTL expression 24360 `attr', whose sole operand is a string giving the name of the 24361 attribute being set. VALUE is the value of the attribute. 24362 24363 The following shows three different ways of representing the same 24364 attribute value specification: 24365 24366 (set_attr "type" "load,store,arith") 24367 24368 (set_attr_alternative "type" 24369 [(const_string "load") (const_string "store") 24370 (const_string "arith")]) 24371 24372 (set (attr "type") 24373 (cond [(eq_attr "alternative" "1") (const_string "load") 24374 (eq_attr "alternative" "2") (const_string "store")] 24375 (const_string "arith"))) 24376 24377 The `define_asm_attributes' expression provides a mechanism to specify 24378 the attributes assigned to insns produced from an `asm' statement. It 24379 has the form: 24380 24381 (define_asm_attributes [ATTR-SETS]) 24382 24383 where ATTR-SETS is specified the same as for both the `define_insn' and 24384 the `define_peephole' expressions. 24385 24386 These values will typically be the "worst case" attribute values. For 24387 example, they might indicate that the condition code will be clobbered. 24388 24389 A specification for a `length' attribute is handled specially. The 24390 way to compute the length of an `asm' insn is to multiply the length 24391 specified in the expression `define_asm_attributes' by the number of 24392 machine instructions specified in the `asm' statement, determined by 24393 counting the number of semicolons and newlines in the string. 24394 Therefore, the value of the `length' attribute specified in a 24395 `define_asm_attributes' should be the maximum possible length of a 24396 single machine instruction. 24397 24398 24399 File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 24400 24401 16.19.4 Example of Attribute Specifications 24402 ------------------------------------------- 24403 24404 The judicious use of defaulting is important in the efficient use of 24405 insn attributes. Typically, insns are divided into "types" and an 24406 attribute, customarily called `type', is used to represent this value. 24407 This attribute is normally used only to define the default value for 24408 other attributes. An example will clarify this usage. 24409 24410 Assume we have a RISC machine with a condition code and in which only 24411 full-word operations are performed in registers. Let us assume that we 24412 can divide all insns into loads, stores, (integer) arithmetic 24413 operations, floating point operations, and branches. 24414 24415 Here we will concern ourselves with determining the effect of an insn 24416 on the condition code and will limit ourselves to the following possible 24417 effects: The condition code can be set unpredictably (clobbered), not 24418 be changed, be set to agree with the results of the operation, or only 24419 changed if the item previously set into the condition code has been 24420 modified. 24421 24422 Here is part of a sample `md' file for such a machine: 24423 24424 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 24425 24426 (define_attr "cc" "clobber,unchanged,set,change0" 24427 (cond [(eq_attr "type" "load") 24428 (const_string "change0") 24429 (eq_attr "type" "store,branch") 24430 (const_string "unchanged") 24431 (eq_attr "type" "arith") 24432 (if_then_else (match_operand:SI 0 "" "") 24433 (const_string "set") 24434 (const_string "clobber"))] 24435 (const_string "clobber"))) 24436 24437 (define_insn "" 24438 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 24439 (match_operand:SI 1 "general_operand" "r,m,r"))] 24440 "" 24441 "@ 24442 move %0,%1 24443 load %0,%1 24444 store %0,%1" 24445 [(set_attr "type" "arith,load,store")]) 24446 24447 Note that we assume in the above example that arithmetic operations 24448 performed on quantities smaller than a machine word clobber the 24449 condition code since they will set the condition code to a value 24450 corresponding to the full-word result. 24451 24452 24453 File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 24454 24455 16.19.5 Computing the Length of an Insn 24456 --------------------------------------- 24457 24458 For many machines, multiple types of branch instructions are provided, 24459 each for different length branch displacements. In most cases, the 24460 assembler will choose the correct instruction to use. However, when 24461 the assembler cannot do so, GCC can when a special attribute, the 24462 `length' attribute, is defined. This attribute must be defined to have 24463 numeric values by specifying a null string in its `define_attr'. 24464 24465 In the case of the `length' attribute, two additional forms of 24466 arithmetic terms are allowed in test expressions: 24467 24468 `(match_dup N)' 24469 This refers to the address of operand N of the current insn, which 24470 must be a `label_ref'. 24471 24472 `(pc)' 24473 This refers to the address of the _current_ insn. It might have 24474 been more consistent with other usage to make this the address of 24475 the _next_ insn but this would be confusing because the length of 24476 the current insn is to be computed. 24477 24478 For normal insns, the length will be determined by value of the 24479 `length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn 24480 patterns, the length is computed as the number of vectors multiplied by 24481 the size of each vector. 24482 24483 Lengths are measured in addressable storage units (bytes). 24484 24485 The following macros can be used to refine the length computation: 24486 24487 `ADJUST_INSN_LENGTH (INSN, LENGTH)' 24488 If defined, modifies the length assigned to instruction INSN as a 24489 function of the context in which it is used. LENGTH is an lvalue 24490 that contains the initially computed length of the insn and should 24491 be updated with the correct length of the insn. 24492 24493 This macro will normally not be required. A case in which it is 24494 required is the ROMP. On this machine, the size of an `addr_vec' 24495 insn must be increased by two to compensate for the fact that 24496 alignment may be required. 24497 24498 The routine that returns `get_attr_length' (the value of the `length' 24499 attribute) can be used by the output routine to determine the form of 24500 the branch instruction to be written, as the example below illustrates. 24501 24502 As an example of the specification of variable-length branches, 24503 consider the IBM 360. If we adopt the convention that a register will 24504 be set to the starting address of a function, we can jump to labels 24505 within 4k of the start using a four-byte instruction. Otherwise, we 24506 need a six-byte sequence to load the address from memory and then 24507 branch to it. 24508 24509 On such a machine, a pattern for a branch instruction might be 24510 specified as follows: 24511 24512 (define_insn "jump" 24513 [(set (pc) 24514 (label_ref (match_operand 0 "" "")))] 24515 "" 24516 { 24517 return (get_attr_length (insn) == 4 24518 ? "b %l0" : "l r15,=a(%l0); br r15"); 24519 } 24520 [(set (attr "length") 24521 (if_then_else (lt (match_dup 0) (const_int 4096)) 24522 (const_int 4) 24523 (const_int 6)))]) 24524 24525 24526 File: gccint.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes 24527 24528 16.19.6 Constant Attributes 24529 --------------------------- 24530 24531 A special form of `define_attr', where the expression for the default 24532 value is a `const' expression, indicates an attribute that is constant 24533 for a given run of the compiler. Constant attributes may be used to 24534 specify which variety of processor is used. For example, 24535 24536 (define_attr "cpu" "m88100,m88110,m88000" 24537 (const 24538 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 24539 (symbol_ref "TARGET_88110") (const_string "m88110")] 24540 (const_string "m88000")))) 24541 24542 (define_attr "memory" "fast,slow" 24543 (const 24544 (if_then_else (symbol_ref "TARGET_FAST_MEM") 24545 (const_string "fast") 24546 (const_string "slow")))) 24547 24548 The routine generated for constant attributes has no parameters as it 24549 does not depend on any particular insn. RTL expressions used to define 24550 the value of a constant attribute may use the `symbol_ref' form, but 24551 may not use either the `match_operand' form or `eq_attr' forms 24552 involving insn attributes. 24553 24554 24555 File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Constant Attributes, Up: Insn Attributes 24556 24557 16.19.7 Delay Slot Scheduling 24558 ----------------------------- 24559 24560 The insn attribute mechanism can be used to specify the requirements for 24561 delay slots, if any, on a target machine. An instruction is said to 24562 require a "delay slot" if some instructions that are physically after 24563 the instruction are executed as if they were located before it. 24564 Classic examples are branch and call instructions, which often execute 24565 the following instruction before the branch or call is performed. 24566 24567 On some machines, conditional branch instructions can optionally 24568 "annul" instructions in the delay slot. This means that the 24569 instruction will not be executed for certain branch outcomes. Both 24570 instructions that annul if the branch is true and instructions that 24571 annul if the branch is false are supported. 24572 24573 Delay slot scheduling differs from instruction scheduling in that 24574 determining whether an instruction needs a delay slot is dependent only 24575 on the type of instruction being generated, not on data flow between the 24576 instructions. See the next section for a discussion of data-dependent 24577 instruction scheduling. 24578 24579 The requirement of an insn needing one or more delay slots is indicated 24580 via the `define_delay' expression. It has the following form: 24581 24582 (define_delay TEST 24583 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 24584 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 24585 ...]) 24586 24587 TEST is an attribute test that indicates whether this `define_delay' 24588 applies to a particular insn. If so, the number of required delay 24589 slots is determined by the length of the vector specified as the second 24590 argument. An insn placed in delay slot N must satisfy attribute test 24591 DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 24592 may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 24593 specifies which insns in the delay slot may be annulled if the branch 24594 is false. If annulling is not supported for that delay slot, `(nil)' 24595 should be coded. 24596 24597 For example, in the common case where branch and call insns require a 24598 single delay slot, which may contain any insn other than a branch or 24599 call, the following would be placed in the `md' file: 24600 24601 (define_delay (eq_attr "type" "branch,call") 24602 [(eq_attr "type" "!branch,call") (nil) (nil)]) 24603 24604 Multiple `define_delay' expressions may be specified. In this case, 24605 each such expression specifies different delay slot requirements and 24606 there must be no insn for which tests in two `define_delay' expressions 24607 are both true. 24608 24609 For example, if we have a machine that requires one delay slot for 24610 branches but two for calls, no delay slot can contain a branch or call 24611 insn, and any valid insn in the delay slot for the branch can be 24612 annulled if the branch is true, we might represent this as follows: 24613 24614 (define_delay (eq_attr "type" "branch") 24615 [(eq_attr "type" "!branch,call") 24616 (eq_attr "type" "!branch,call") 24617 (nil)]) 24618 24619 (define_delay (eq_attr "type" "call") 24620 [(eq_attr "type" "!branch,call") (nil) (nil) 24621 (eq_attr "type" "!branch,call") (nil) (nil)]) 24622 24623 24624 File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 24625 24626 16.19.8 Specifying processor pipeline description 24627 ------------------------------------------------- 24628 24629 To achieve better performance, most modern processors (super-pipelined, 24630 superscalar RISC, and VLIW processors) have many "functional units" on 24631 which several instructions can be executed simultaneously. An 24632 instruction starts execution if its issue conditions are satisfied. If 24633 not, the instruction is stalled until its conditions are satisfied. 24634 Such "interlock (pipeline) delay" causes interruption of the fetching 24635 of successor instructions (or demands nop instructions, e.g. for some 24636 MIPS processors). 24637 24638 There are two major kinds of interlock delays in modern processors. 24639 The first one is a data dependence delay determining "instruction 24640 latency time". The instruction execution is not started until all 24641 source data have been evaluated by prior instructions (there are more 24642 complex cases when the instruction execution starts even when the data 24643 are not available but will be ready in given time after the instruction 24644 execution start). Taking the data dependence delays into account is 24645 simple. The data dependence (true, output, and anti-dependence) delay 24646 between two instructions is given by a constant. In most cases this 24647 approach is adequate. The second kind of interlock delays is a 24648 reservation delay. The reservation delay means that two instructions 24649 under execution will be in need of shared processors resources, i.e. 24650 buses, internal registers, and/or functional units, which are reserved 24651 for some time. Taking this kind of delay into account is complex 24652 especially for modern RISC processors. 24653 24654 The task of exploiting more processor parallelism is solved by an 24655 instruction scheduler. For a better solution to this problem, the 24656 instruction scheduler has to have an adequate description of the 24657 processor parallelism (or "pipeline description"). GCC machine 24658 descriptions describe processor parallelism and functional unit 24659 reservations for groups of instructions with the aid of "regular 24660 expressions". 24661 24662 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 24663 figure out the possibility of the instruction issue by the processor on 24664 a given simulated processor cycle. The pipeline hazard recognizer is 24665 automatically generated from the processor pipeline description. The 24666 pipeline hazard recognizer generated from the machine description is 24667 based on a deterministic finite state automaton (DFA): the instruction 24668 issue is possible if there is a transition from one automaton state to 24669 another one. This algorithm is very fast, and furthermore, its speed 24670 is not dependent on processor complexity(1). 24671 24672 The rest of this section describes the directives that constitute an 24673 automaton-based processor pipeline description. The order of these 24674 constructions within the machine description file is not important. 24675 24676 The following optional construction describes names of automata 24677 generated and used for the pipeline hazards recognition. Sometimes the 24678 generated finite state automaton used by the pipeline hazard recognizer 24679 is large. If we use more than one automaton and bind functional units 24680 to the automata, the total size of the automata is usually less than 24681 the size of the single automaton. If there is no one such 24682 construction, only one finite state automaton is generated. 24683 24684 (define_automaton AUTOMATA-NAMES) 24685 24686 AUTOMATA-NAMES is a string giving names of the automata. The names 24687 are separated by commas. All the automata should have unique names. 24688 The automaton name is used in the constructions `define_cpu_unit' and 24689 `define_query_cpu_unit'. 24690 24691 Each processor functional unit used in the description of instruction 24692 reservations should be described by the following construction. 24693 24694 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 24695 24696 UNIT-NAMES is a string giving the names of the functional units 24697 separated by commas. Don't use name `nothing', it is reserved for 24698 other goals. 24699 24700 AUTOMATON-NAME is a string giving the name of the automaton with which 24701 the unit is bound. The automaton should be described in construction 24702 `define_automaton'. You should give "automaton-name", if there is a 24703 defined automaton. 24704 24705 The assignment of units to automata are constrained by the uses of the 24706 units in insn reservations. The most important constraint is: if a 24707 unit reservation is present on a particular cycle of an alternative for 24708 an insn reservation, then some unit from the same automaton must be 24709 present on the same cycle for the other alternatives of the insn 24710 reservation. The rest of the constraints are mentioned in the 24711 description of the subsequent constructions. 24712 24713 The following construction describes CPU functional units analogously 24714 to `define_cpu_unit'. The reservation of such units can be queried for 24715 an automaton state. The instruction scheduler never queries 24716 reservation of functional units for given automaton state. So as a 24717 rule, you don't need this construction. This construction could be 24718 used for future code generation goals (e.g. to generate VLIW insn 24719 templates). 24720 24721 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 24722 24723 UNIT-NAMES is a string giving names of the functional units separated 24724 by commas. 24725 24726 AUTOMATON-NAME is a string giving the name of the automaton with which 24727 the unit is bound. 24728 24729 The following construction is the major one to describe pipeline 24730 characteristics of an instruction. 24731 24732 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 24733 CONDITION REGEXP) 24734 24735 DEFAULT_LATENCY is a number giving latency time of the instruction. 24736 There is an important difference between the old description and the 24737 automaton based pipeline description. The latency time is used for all 24738 dependencies when we use the old description. In the automaton based 24739 pipeline description, the given latency time is only used for true 24740 dependencies. The cost of anti-dependencies is always zero and the 24741 cost of output dependencies is the difference between latency times of 24742 the producing and consuming insns (if the difference is negative, the 24743 cost is considered to be zero). You can always change the default 24744 costs for any description by using the target hook 24745 `TARGET_SCHED_ADJUST_COST' (*note Scheduling::). 24746 24747 INSN-NAME is a string giving the internal name of the insn. The 24748 internal names are used in constructions `define_bypass' and in the 24749 automaton description file generated for debugging. The internal name 24750 has nothing in common with the names in `define_insn'. It is a good 24751 practice to use insn classes described in the processor manual. 24752 24753 CONDITION defines what RTL insns are described by this construction. 24754 You should remember that you will be in trouble if CONDITION for two or 24755 more different `define_insn_reservation' constructions is TRUE for an 24756 insn. In this case what reservation will be used for the insn is not 24757 defined. Such cases are not checked during generation of the pipeline 24758 hazards recognizer because in general recognizing that two conditions 24759 may have the same value is quite difficult (especially if the conditions 24760 contain `symbol_ref'). It is also not checked during the pipeline 24761 hazard recognizer work because it would slow down the recognizer 24762 considerably. 24763 24764 REGEXP is a string describing the reservation of the cpu's functional 24765 units by the instruction. The reservations are described by a regular 24766 expression according to the following syntax: 24767 24768 regexp = regexp "," oneof 24769 | oneof 24770 24771 oneof = oneof "|" allof 24772 | allof 24773 24774 allof = allof "+" repeat 24775 | repeat 24776 24777 repeat = element "*" number 24778 | element 24779 24780 element = cpu_function_unit_name 24781 | reservation_name 24782 | result_name 24783 | "nothing" 24784 | "(" regexp ")" 24785 24786 * `,' is used for describing the start of the next cycle in the 24787 reservation. 24788 24789 * `|' is used for describing a reservation described by the first 24790 regular expression *or* a reservation described by the second 24791 regular expression *or* etc. 24792 24793 * `+' is used for describing a reservation described by the first 24794 regular expression *and* a reservation described by the second 24795 regular expression *and* etc. 24796 24797 * `*' is used for convenience and simply means a sequence in which 24798 the regular expression are repeated NUMBER times with cycle 24799 advancing (see `,'). 24800 24801 * `cpu_function_unit_name' denotes reservation of the named 24802 functional unit. 24803 24804 * `reservation_name' -- see description of construction 24805 `define_reservation'. 24806 24807 * `nothing' denotes no unit reservations. 24808 24809 Sometimes unit reservations for different insns contain common parts. 24810 In such case, you can simplify the pipeline description by describing 24811 the common part by the following construction 24812 24813 (define_reservation RESERVATION-NAME REGEXP) 24814 24815 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 24816 names and reservation names are in the same name space. So the 24817 reservation names should be different from the functional unit names 24818 and can not be the reserved name `nothing'. 24819 24820 The following construction is used to describe exceptions in the 24821 latency time for given instruction pair. This is so called bypasses. 24822 24823 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 24824 [GUARD]) 24825 24826 NUMBER defines when the result generated by the instructions given in 24827 string OUT_INSN_NAMES will be ready for the instructions given in 24828 string IN_INSN_NAMES. The instructions in the string are separated by 24829 commas. 24830 24831 GUARD is an optional string giving the name of a C function which 24832 defines an additional guard for the bypass. The function will get the 24833 two insns as parameters. If the function returns zero the bypass will 24834 be ignored for this case. The additional guard is necessary to 24835 recognize complicated bypasses, e.g. when the consumer is only an 24836 address of insn `store' (not a stored value). 24837 24838 If there are more one bypass with the same output and input insns, the 24839 chosen bypass is the first bypass with a guard in description whose 24840 guard function returns nonzero. If there is no such bypass, then 24841 bypass without the guard function is chosen. 24842 24843 The following five constructions are usually used to describe VLIW 24844 processors, or more precisely, to describe a placement of small 24845 instructions into VLIW instruction slots. They can be used for RISC 24846 processors, too. 24847 24848 (exclusion_set UNIT-NAMES UNIT-NAMES) 24849 (presence_set UNIT-NAMES PATTERNS) 24850 (final_presence_set UNIT-NAMES PATTERNS) 24851 (absence_set UNIT-NAMES PATTERNS) 24852 (final_absence_set UNIT-NAMES PATTERNS) 24853 24854 UNIT-NAMES is a string giving names of functional units separated by 24855 commas. 24856 24857 PATTERNS is a string giving patterns of functional units separated by 24858 comma. Currently pattern is one unit or units separated by 24859 white-spaces. 24860 24861 The first construction (`exclusion_set') means that each functional 24862 unit in the first string can not be reserved simultaneously with a unit 24863 whose name is in the second string and vice versa. For example, the 24864 construction is useful for describing processors (e.g. some SPARC 24865 processors) with a fully pipelined floating point functional unit which 24866 can execute simultaneously only single floating point insns or only 24867 double floating point insns. 24868 24869 The second construction (`presence_set') means that each functional 24870 unit in the first string can not be reserved unless at least one of 24871 pattern of units whose names are in the second string is reserved. 24872 This is an asymmetric relation. For example, it is useful for 24873 description that VLIW `slot1' is reserved after `slot0' reservation. 24874 We could describe it by the following construction 24875 24876 (presence_set "slot1" "slot0") 24877 24878 Or `slot1' is reserved only after `slot0' and unit `b0' reservation. 24879 In this case we could write 24880 24881 (presence_set "slot1" "slot0 b0") 24882 24883 The third construction (`final_presence_set') is analogous to 24884 `presence_set'. The difference between them is when checking is done. 24885 When an instruction is issued in given automaton state reflecting all 24886 current and planned unit reservations, the automaton state is changed. 24887 The first state is a source state, the second one is a result state. 24888 Checking for `presence_set' is done on the source state reservation, 24889 checking for `final_presence_set' is done on the result reservation. 24890 This construction is useful to describe a reservation which is actually 24891 two subsequent reservations. For example, if we use 24892 24893 (presence_set "slot1" "slot0") 24894 24895 the following insn will be never issued (because `slot1' requires 24896 `slot0' which is absent in the source state). 24897 24898 (define_reservation "insn_and_nop" "slot0 + slot1") 24899 24900 but it can be issued if we use analogous `final_presence_set'. 24901 24902 The forth construction (`absence_set') means that each functional unit 24903 in the first string can be reserved only if each pattern of units whose 24904 names are in the second string is not reserved. This is an asymmetric 24905 relation (actually `exclusion_set' is analogous to this one but it is 24906 symmetric). For example it might be useful in a VLIW description to 24907 say that `slot0' cannot be reserved after either `slot1' or `slot2' 24908 have been reserved. This can be described as: 24909 24910 (absence_set "slot0" "slot1, slot2") 24911 24912 Or `slot2' can not be reserved if `slot0' and unit `b0' are reserved 24913 or `slot1' and unit `b1' are reserved. In this case we could write 24914 24915 (absence_set "slot2" "slot0 b0, slot1 b1") 24916 24917 All functional units mentioned in a set should belong to the same 24918 automaton. 24919 24920 The last construction (`final_absence_set') is analogous to 24921 `absence_set' but checking is done on the result (state) reservation. 24922 See comments for `final_presence_set'. 24923 24924 You can control the generator of the pipeline hazard recognizer with 24925 the following construction. 24926 24927 (automata_option OPTIONS) 24928 24929 OPTIONS is a string giving options which affect the generated code. 24930 Currently there are the following options: 24931 24932 * "no-minimization" makes no minimization of the automaton. This is 24933 only worth to do when we are debugging the description and need to 24934 look more accurately at reservations of states. 24935 24936 * "time" means printing time statistics about the generation of 24937 automata. 24938 24939 * "stats" means printing statistics about the generated automata 24940 such as the number of DFA states, NDFA states and arcs. 24941 24942 * "v" means a generation of the file describing the result automata. 24943 The file has suffix `.dfa' and can be used for the description 24944 verification and debugging. 24945 24946 * "w" means a generation of warning instead of error for 24947 non-critical errors. 24948 24949 * "ndfa" makes nondeterministic finite state automata. This affects 24950 the treatment of operator `|' in the regular expressions. The 24951 usual treatment of the operator is to try the first alternative 24952 and, if the reservation is not possible, the second alternative. 24953 The nondeterministic treatment means trying all alternatives, some 24954 of them may be rejected by reservations in the subsequent insns. 24955 24956 * "progress" means output of a progress bar showing how many states 24957 were generated so far for automaton being processed. This is 24958 useful during debugging a DFA description. If you see too many 24959 generated states, you could interrupt the generator of the pipeline 24960 hazard recognizer and try to figure out a reason for generation of 24961 the huge automaton. 24962 24963 As an example, consider a superscalar RISC machine which can issue 24964 three insns (two integer insns and one floating point insn) on the 24965 cycle but can finish only two insns. To describe this, we define the 24966 following functional units. 24967 24968 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 24969 (define_cpu_unit "port0, port1") 24970 24971 All simple integer insns can be executed in any integer pipeline and 24972 their result is ready in two cycles. The simple integer insns are 24973 issued into the first pipeline unless it is reserved, otherwise they 24974 are issued into the second pipeline. Integer division and 24975 multiplication insns can be executed only in the second integer 24976 pipeline and their results are ready correspondingly in 8 and 4 cycles. 24977 The integer division is not pipelined, i.e. the subsequent integer 24978 division insn can not be issued until the current division insn 24979 finished. Floating point insns are fully pipelined and their results 24980 are ready in 3 cycles. Where the result of a floating point insn is 24981 used by an integer insn, an additional delay of one cycle is incurred. 24982 To describe all of this we could specify 24983 24984 (define_cpu_unit "div") 24985 24986 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 24987 "(i0_pipeline | i1_pipeline), (port0 | port1)") 24988 24989 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 24990 "i1_pipeline, nothing*2, (port0 | port1)") 24991 24992 (define_insn_reservation "div" 8 (eq_attr "type" "div") 24993 "i1_pipeline, div*7, div + (port0 | port1)") 24994 24995 (define_insn_reservation "float" 3 (eq_attr "type" "float") 24996 "f_pipeline, nothing, (port0 | port1)) 24997 24998 (define_bypass 4 "float" "simple,mult,div") 24999 25000 To simplify the description we could describe the following reservation 25001 25002 (define_reservation "finish" "port0|port1") 25003 25004 and use it in all `define_insn_reservation' as in the following 25005 construction 25006 25007 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 25008 "(i0_pipeline | i1_pipeline), finish") 25009 25010 ---------- Footnotes ---------- 25011 25012 (1) However, the size of the automaton depends on processor 25013 complexity. To limit this effect, machine descriptions can split 25014 orthogonal parts of the machine description among several automata: but 25015 then, since each of these must be stepped independently, this does 25016 cause a small decrease in the algorithm's performance. 25017 25018 25019 File: gccint.info, Node: Conditional Execution, Next: Constant Definitions, Prev: Insn Attributes, Up: Machine Desc 25020 25021 16.20 Conditional Execution 25022 =========================== 25023 25024 A number of architectures provide for some form of conditional 25025 execution, or predication. The hallmark of this feature is the ability 25026 to nullify most of the instructions in the instruction set. When the 25027 instruction set is large and not entirely symmetric, it can be quite 25028 tedious to describe these forms directly in the `.md' file. An 25029 alternative is the `define_cond_exec' template. 25030 25031 (define_cond_exec 25032 [PREDICATE-PATTERN] 25033 "CONDITION" 25034 "OUTPUT-TEMPLATE") 25035 25036 PREDICATE-PATTERN is the condition that must be true for the insn to 25037 be executed at runtime and should match a relational operator. One can 25038 use `match_operator' to match several relational operators at once. 25039 Any `match_operand' operands must have no more than one alternative. 25040 25041 CONDITION is a C expression that must be true for the generated 25042 pattern to match. 25043 25044 OUTPUT-TEMPLATE is a string similar to the `define_insn' output 25045 template (*note Output Template::), except that the `*' and `@' special 25046 cases do not apply. This is only useful if the assembly text for the 25047 predicate is a simple prefix to the main insn. In order to handle the 25048 general case, there is a global variable `current_insn_predicate' that 25049 will contain the entire predicate if the current insn is predicated, 25050 and will otherwise be `NULL'. 25051 25052 When `define_cond_exec' is used, an implicit reference to the 25053 `predicable' instruction attribute is made. *Note Insn Attributes::. 25054 This attribute must be boolean (i.e. have exactly two elements in its 25055 LIST-OF-VALUES). Further, it must not be used with complex 25056 expressions. That is, the default and all uses in the insns must be a 25057 simple constant, not dependent on the alternative or anything else. 25058 25059 For each `define_insn' for which the `predicable' attribute is true, a 25060 new `define_insn' pattern will be generated that matches a predicated 25061 version of the instruction. For example, 25062 25063 (define_insn "addsi" 25064 [(set (match_operand:SI 0 "register_operand" "r") 25065 (plus:SI (match_operand:SI 1 "register_operand" "r") 25066 (match_operand:SI 2 "register_operand" "r")))] 25067 "TEST1" 25068 "add %2,%1,%0") 25069 25070 (define_cond_exec 25071 [(ne (match_operand:CC 0 "register_operand" "c") 25072 (const_int 0))] 25073 "TEST2" 25074 "(%0)") 25075 25076 generates a new pattern 25077 25078 (define_insn "" 25079 [(cond_exec 25080 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 25081 (set (match_operand:SI 0 "register_operand" "r") 25082 (plus:SI (match_operand:SI 1 "register_operand" "r") 25083 (match_operand:SI 2 "register_operand" "r"))))] 25084 "(TEST2) && (TEST1)" 25085 "(%3) add %2,%1,%0") 25086 25087 25088 File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Conditional Execution, Up: Machine Desc 25089 25090 16.21 Constant Definitions 25091 ========================== 25092 25093 Using literal constants inside instruction patterns reduces legibility 25094 and can be a maintenance problem. 25095 25096 To overcome this problem, you may use the `define_constants' 25097 expression. It contains a vector of name-value pairs. From that point 25098 on, wherever any of the names appears in the MD file, it is as if the 25099 corresponding value had been written instead. You may use 25100 `define_constants' multiple times; each appearance adds more constants 25101 to the table. It is an error to redefine a constant with a different 25102 value. 25103 25104 To come back to the a29k load multiple example, instead of 25105 25106 (define_insn "" 25107 [(match_parallel 0 "load_multiple_operation" 25108 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 25109 (match_operand:SI 2 "memory_operand" "m")) 25110 (use (reg:SI 179)) 25111 (clobber (reg:SI 179))])] 25112 "" 25113 "loadm 0,0,%1,%2") 25114 25115 You could write: 25116 25117 (define_constants [ 25118 (R_BP 177) 25119 (R_FC 178) 25120 (R_CR 179) 25121 (R_Q 180) 25122 ]) 25123 25124 (define_insn "" 25125 [(match_parallel 0 "load_multiple_operation" 25126 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 25127 (match_operand:SI 2 "memory_operand" "m")) 25128 (use (reg:SI R_CR)) 25129 (clobber (reg:SI R_CR))])] 25130 "" 25131 "loadm 0,0,%1,%2") 25132 25133 The constants that are defined with a define_constant are also output 25134 in the insn-codes.h header file as #defines. 25135 25136 You can also use the machine description file to define enumerations. 25137 Like the constants defined by `define_constant', these enumerations are 25138 visible to both the machine description file and the main C code. 25139 25140 The syntax is as follows: 25141 25142 (define_c_enum "NAME" [ 25143 VALUE0 25144 VALUE1 25145 ... 25146 VALUEN 25147 ]) 25148 25149 This definition causes the equivalent of the following C code to appear 25150 in `insn-constants.h': 25151 25152 enum NAME { 25153 VALUE0 = 0, 25154 VALUE1 = 1, 25155 ... 25156 VALUEN = N 25157 }; 25158 #define NUM_CNAME_VALUES (N + 1) 25159 25160 where CNAME is the capitalized form of NAME. It also makes each 25161 VALUEI available in the machine description file, just as if it had 25162 been declared with: 25163 25164 (define_constants [(VALUEI I)]) 25165 25166 Each VALUEI is usually an upper-case identifier and usually begins 25167 with CNAME. 25168 25169 You can split the enumeration definition into as many statements as 25170 you like. The above example is directly equivalent to: 25171 25172 (define_c_enum "NAME" [VALUE0]) 25173 (define_c_enum "NAME" [VALUE1]) 25174 ... 25175 (define_c_enum "NAME" [VALUEN]) 25176 25177 Splitting the enumeration helps to improve the modularity of each 25178 individual `.md' file. For example, if a port defines its 25179 synchronization instructions in a separate `sync.md' file, it is 25180 convenient to define all synchronization-specific enumeration values in 25181 `sync.md' rather than in the main `.md' file. 25182 25183 Some enumeration names have special significance to GCC: 25184 25185 `unspecv' 25186 If an enumeration called `unspecv' is defined, GCC will use it 25187 when printing out `unspec_volatile' expressions. For example: 25188 25189 (define_c_enum "unspecv" [ 25190 UNSPECV_BLOCKAGE 25191 ]) 25192 25193 causes GCC to print `(unspec_volatile ... 0)' as: 25194 25195 (unspec_volatile ... UNSPECV_BLOCKAGE) 25196 25197 `unspec' 25198 If an enumeration called `unspec' is defined, GCC will use it when 25199 printing out `unspec' expressions. GCC will also use it when 25200 printing out `unspec_volatile' expressions unless an `unspecv' 25201 enumeration is also defined. You can therefore decide whether to 25202 keep separate enumerations for volatile and non-volatile 25203 expressions or whether to use the same enumeration for both. 25204 25205 Another way of defining an enumeration is to use `define_enum': 25206 25207 (define_enum "NAME" [ 25208 VALUE0 25209 VALUE1 25210 ... 25211 VALUEN 25212 ]) 25213 25214 This directive implies: 25215 25216 (define_c_enum "NAME" [ 25217 CNAME_CVALUE0 25218 CNAME_CVALUE1 25219 ... 25220 CNAME_CVALUEN 25221 ]) 25222 25223 where CVALUEI is the capitalized form of VALUEI. However, unlike 25224 `define_c_enum', the enumerations defined by `define_enum' can be used 25225 in attribute specifications (*note define_enum_attr::). 25226 25227 25228 File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 25229 25230 16.22 Iterators 25231 =============== 25232 25233 Ports often need to define similar patterns for more than one machine 25234 mode or for more than one rtx code. GCC provides some simple iterator 25235 facilities to make this process easier. 25236 25237 * Menu: 25238 25239 * Mode Iterators:: Generating variations of patterns for different modes. 25240 * Code Iterators:: Doing the same for codes. 25241 25242 25243 File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 25244 25245 16.22.1 Mode Iterators 25246 ---------------------- 25247 25248 Ports often need to define similar patterns for two or more different 25249 modes. For example: 25250 25251 * If a processor has hardware support for both single and double 25252 floating-point arithmetic, the `SFmode' patterns tend to be very 25253 similar to the `DFmode' ones. 25254 25255 * If a port uses `SImode' pointers in one configuration and `DImode' 25256 pointers in another, it will usually have very similar `SImode' 25257 and `DImode' patterns for manipulating pointers. 25258 25259 Mode iterators allow several patterns to be instantiated from one 25260 `.md' file template. They can be used with any type of rtx-based 25261 construct, such as a `define_insn', `define_split', or 25262 `define_peephole2'. 25263 25264 * Menu: 25265 25266 * Defining Mode Iterators:: Defining a new mode iterator. 25267 * Substitutions:: Combining mode iterators with substitutions 25268 * Examples:: Examples 25269 25270 25271 File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 25272 25273 16.22.1.1 Defining Mode Iterators 25274 ................................. 25275 25276 The syntax for defining a mode iterator is: 25277 25278 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 25279 25280 This allows subsequent `.md' file constructs to use the mode suffix 25281 `:NAME'. Every construct that does so will be expanded N times, once 25282 with every use of `:NAME' replaced by `:MODE1', once with every use 25283 replaced by `:MODE2', and so on. In the expansion for a particular 25284 MODEI, every C condition will also require that CONDI be true. 25285 25286 For example: 25287 25288 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 25289 25290 defines a new mode suffix `:P'. Every construct that uses `:P' will 25291 be expanded twice, once with every `:P' replaced by `:SI' and once with 25292 every `:P' replaced by `:DI'. The `:SI' version will only apply if 25293 `Pmode == SImode' and the `:DI' version will only apply if `Pmode == 25294 DImode'. 25295 25296 As with other `.md' conditions, an empty string is treated as "always 25297 true". `(MODE "")' can also be abbreviated to `MODE'. For example: 25298 25299 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 25300 25301 means that the `:DI' expansion only applies if `TARGET_64BIT' but that 25302 the `:SI' expansion has no such constraint. 25303 25304 Iterators are applied in the order they are defined. This can be 25305 significant if two iterators are used in a construct that requires 25306 substitutions. *Note Substitutions::. 25307 25308 25309 File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 25310 25311 16.22.1.2 Substitution in Mode Iterators 25312 ........................................ 25313 25314 If an `.md' file construct uses mode iterators, each version of the 25315 construct will often need slightly different strings or modes. For 25316 example: 25317 25318 * When a `define_expand' defines several `addM3' patterns (*note 25319 Standard Names::), each expander will need to use the appropriate 25320 mode name for M. 25321 25322 * When a `define_insn' defines several instruction patterns, each 25323 instruction will often use a different assembler mnemonic. 25324 25325 * When a `define_insn' requires operands with different modes, using 25326 an iterator for one of the operand modes usually requires a 25327 specific mode for the other operand(s). 25328 25329 GCC supports such variations through a system of "mode attributes". 25330 There are two standard attributes: `mode', which is the name of the 25331 mode in lower case, and `MODE', which is the same thing in upper case. 25332 You can define other attributes using: 25333 25334 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 25335 25336 where NAME is the name of the attribute and VALUEI is the value 25337 associated with MODEI. 25338 25339 When GCC replaces some :ITERATOR with :MODE, it will scan each string 25340 and mode in the pattern for sequences of the form `<ITERATOR:ATTR>', 25341 where ATTR is the name of a mode attribute. If the attribute is 25342 defined for MODE, the whole `<...>' sequence will be replaced by the 25343 appropriate attribute value. 25344 25345 For example, suppose an `.md' file has: 25346 25347 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 25348 (define_mode_attr load [(SI "lw") (DI "ld")]) 25349 25350 If one of the patterns that uses `:P' contains the string 25351 `"<P:load>\t%0,%1"', the `SI' version of that pattern will use 25352 `"lw\t%0,%1"' and the `DI' version will use `"ld\t%0,%1"'. 25353 25354 Here is an example of using an attribute for a mode: 25355 25356 (define_mode_iterator LONG [SI DI]) 25357 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 25358 (define_insn ... 25359 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 25360 25361 The `ITERATOR:' prefix may be omitted, in which case the substitution 25362 will be attempted for every iterator expansion. 25363 25364 25365 File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 25366 25367 16.22.1.3 Mode Iterator Examples 25368 ................................ 25369 25370 Here is an example from the MIPS port. It defines the following modes 25371 and attributes (among others): 25372 25373 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 25374 (define_mode_attr d [(SI "") (DI "d")]) 25375 25376 and uses the following template to define both `subsi3' and `subdi3': 25377 25378 (define_insn "sub<mode>3" 25379 [(set (match_operand:GPR 0 "register_operand" "=d") 25380 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 25381 (match_operand:GPR 2 "register_operand" "d")))] 25382 "" 25383 "<d>subu\t%0,%1,%2" 25384 [(set_attr "type" "arith") 25385 (set_attr "mode" "<MODE>")]) 25386 25387 This is exactly equivalent to: 25388 25389 (define_insn "subsi3" 25390 [(set (match_operand:SI 0 "register_operand" "=d") 25391 (minus:SI (match_operand:SI 1 "register_operand" "d") 25392 (match_operand:SI 2 "register_operand" "d")))] 25393 "" 25394 "subu\t%0,%1,%2" 25395 [(set_attr "type" "arith") 25396 (set_attr "mode" "SI")]) 25397 25398 (define_insn "subdi3" 25399 [(set (match_operand:DI 0 "register_operand" "=d") 25400 (minus:DI (match_operand:DI 1 "register_operand" "d") 25401 (match_operand:DI 2 "register_operand" "d")))] 25402 "" 25403 "dsubu\t%0,%1,%2" 25404 [(set_attr "type" "arith") 25405 (set_attr "mode" "DI")]) 25406 25407 25408 File: gccint.info, Node: Code Iterators, Prev: Mode Iterators, Up: Iterators 25409 25410 16.22.2 Code Iterators 25411 ---------------------- 25412 25413 Code iterators operate in a similar way to mode iterators. *Note Mode 25414 Iterators::. 25415 25416 The construct: 25417 25418 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 25419 25420 defines a pseudo rtx code NAME that can be instantiated as CODEI if 25421 condition CONDI is true. Each CODEI must have the same rtx format. 25422 *Note RTL Classes::. 25423 25424 As with mode iterators, each pattern that uses NAME will be expanded N 25425 times, once with all uses of NAME replaced by CODE1, once with all uses 25426 replaced by CODE2, and so on. *Note Defining Mode Iterators::. 25427 25428 It is possible to define attributes for codes as well as for modes. 25429 There are two standard code attributes: `code', the name of the code in 25430 lower case, and `CODE', the name of the code in upper case. Other 25431 attributes are defined using: 25432 25433 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 25434 25435 Here's an example of code iterators in action, taken from the MIPS 25436 port: 25437 25438 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 25439 eq ne gt ge lt le gtu geu ltu leu]) 25440 25441 (define_expand "b<code>" 25442 [(set (pc) 25443 (if_then_else (any_cond:CC (cc0) 25444 (const_int 0)) 25445 (label_ref (match_operand 0 "")) 25446 (pc)))] 25447 "" 25448 { 25449 gen_conditional_branch (operands, <CODE>); 25450 DONE; 25451 }) 25452 25453 This is equivalent to: 25454 25455 (define_expand "bunordered" 25456 [(set (pc) 25457 (if_then_else (unordered:CC (cc0) 25458 (const_int 0)) 25459 (label_ref (match_operand 0 "")) 25460 (pc)))] 25461 "" 25462 { 25463 gen_conditional_branch (operands, UNORDERED); 25464 DONE; 25465 }) 25466 25467 (define_expand "bordered" 25468 [(set (pc) 25469 (if_then_else (ordered:CC (cc0) 25470 (const_int 0)) 25471 (label_ref (match_operand 0 "")) 25472 (pc)))] 25473 "" 25474 { 25475 gen_conditional_branch (operands, ORDERED); 25476 DONE; 25477 }) 25478 25479 ... 25480 25481 25482 File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 25483 25484 17 Target Description Macros and Functions 25485 ****************************************** 25486 25487 In addition to the file `MACHINE.md', a machine description includes a 25488 C header file conventionally given the name `MACHINE.h' and a C source 25489 file named `MACHINE.c'. The header file defines numerous macros that 25490 convey the information about the target machine that does not fit into 25491 the scheme of the `.md' file. The file `tm.h' should be a link to 25492 `MACHINE.h'. The header file `config.h' includes `tm.h' and most 25493 compiler source files include `config.h'. The source file defines a 25494 variable `targetm', which is a structure containing pointers to 25495 functions and data relating to the target machine. `MACHINE.c' should 25496 also contain their definitions, if they are not defined elsewhere in 25497 GCC, and other functions called through the macros defined in the `.h' 25498 file. 25499 25500 * Menu: 25501 25502 * Target Structure:: The `targetm' variable. 25503 * Driver:: Controlling how the driver runs the compilation passes. 25504 * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. 25505 * Per-Function Data:: Defining data structures for per-function information. 25506 * Storage Layout:: Defining sizes and alignments of data. 25507 * Type Layout:: Defining sizes and properties of basic user data types. 25508 * Registers:: Naming and describing the hardware registers. 25509 * Register Classes:: Defining the classes of hardware registers. 25510 * Old Constraints:: The old way to define machine-specific constraints. 25511 * Stack and Calling:: Defining which way the stack grows and by how much. 25512 * Varargs:: Defining the varargs macros. 25513 * Trampolines:: Code set up at run time to enter a nested function. 25514 * Library Calls:: Controlling how library routines are implicitly called. 25515 * Addressing Modes:: Defining addressing modes valid for memory operands. 25516 * Anchored Addresses:: Defining how `-fsection-anchors' should work. 25517 * Condition Code:: Defining how insns update the condition code. 25518 * Costs:: Defining relative costs of different operations. 25519 * Scheduling:: Adjusting the behavior of the instruction scheduler. 25520 * Sections:: Dividing storage into text, data, and other sections. 25521 * PIC:: Macros for position independent code. 25522 * Assembler Format:: Defining how to write insns and pseudo-ops to output. 25523 * Debugging Info:: Defining the format of debugging output. 25524 * Floating Point:: Handling floating point for cross-compilers. 25525 * Mode Switching:: Insertion of mode-switching instructions. 25526 * Target Attributes:: Defining target-specific uses of `__attribute__'. 25527 * Emulated TLS:: Emulated TLS support. 25528 * MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 25529 * PCH Target:: Validity checking for precompiled headers. 25530 * C++ ABI:: Controlling C++ ABI changes. 25531 * Named Address Spaces:: Adding support for named address spaces 25532 * Misc:: Everything else. 25533 25534 25535 File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 25536 25537 17.1 The Global `targetm' Variable 25538 ================================== 25539 25540 -- Variable: struct gcc_target targetm 25541 The target `.c' file must define the global `targetm' variable 25542 which contains pointers to functions and data relating to the 25543 target machine. The variable is declared in `target.h'; 25544 `target-def.h' defines the macro `TARGET_INITIALIZER' which is 25545 used to initialize the variable, and macros for the default 25546 initializers for elements of the structure. The `.c' file should 25547 override those macros for which the default definition is 25548 inappropriate. For example: 25549 #include "target.h" 25550 #include "target-def.h" 25551 25552 /* Initialize the GCC target structure. */ 25553 25554 #undef TARGET_COMP_TYPE_ATTRIBUTES 25555 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 25556 25557 struct gcc_target targetm = TARGET_INITIALIZER; 25558 25559 Where a macro should be defined in the `.c' file in this manner to form 25560 part of the `targetm' structure, it is documented below as a "Target 25561 Hook" with a prototype. Many macros will change in future from being 25562 defined in the `.h' file to being part of the `targetm' structure. 25563 25564 25565 File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 25566 25567 17.2 Controlling the Compilation Driver, `gcc' 25568 ============================================== 25569 25570 You can control the compilation driver. 25571 25572 -- Macro: DRIVER_SELF_SPECS 25573 A list of specs for the driver itself. It should be a suitable 25574 initializer for an array of strings, with no surrounding braces. 25575 25576 The driver applies these specs to its own command line between 25577 loading default `specs' files (but not command-line specified 25578 ones) and choosing the multilib directory or running any 25579 subcommands. It applies them in the order given, so each spec can 25580 depend on the options added by earlier ones. It is also possible 25581 to remove options using `%<OPTION' in the usual way. 25582 25583 This macro can be useful when a port has several interdependent 25584 target options. It provides a way of standardizing the command 25585 line so that the other specs are easier to write. 25586 25587 Do not define this macro if it does not need to do anything. 25588 25589 -- Macro: OPTION_DEFAULT_SPECS 25590 A list of specs used to support configure-time default options 25591 (i.e. `--with' options) in the driver. It should be a suitable 25592 initializer for an array of structures, each containing two 25593 strings, without the outermost pair of surrounding braces. 25594 25595 The first item in the pair is the name of the default. This must 25596 match the code in `config.gcc' for the target. The second item is 25597 a spec to apply if a default with this name was specified. The 25598 string `%(VALUE)' in the spec will be replaced by the value of the 25599 default everywhere it occurs. 25600 25601 The driver will apply these specs to its own command line between 25602 loading default `specs' files and processing `DRIVER_SELF_SPECS', 25603 using the same mechanism as `DRIVER_SELF_SPECS'. 25604 25605 Do not define this macro if it does not need to do anything. 25606 25607 -- Macro: CPP_SPEC 25608 A C string constant that tells the GCC driver program options to 25609 pass to CPP. It can also specify how to translate options you 25610 give to GCC into options for GCC to pass to the CPP. 25611 25612 Do not define this macro if it does not need to do anything. 25613 25614 -- Macro: CPLUSPLUS_CPP_SPEC 25615 This macro is just like `CPP_SPEC', but is used for C++, rather 25616 than C. If you do not define this macro, then the value of 25617 `CPP_SPEC' (if any) will be used instead. 25618 25619 -- Macro: CC1_SPEC 25620 A C string constant that tells the GCC driver program options to 25621 pass to `cc1', `cc1plus', `f771', and the other language front 25622 ends. It can also specify how to translate options you give to 25623 GCC into options for GCC to pass to front ends. 25624 25625 Do not define this macro if it does not need to do anything. 25626 25627 -- Macro: CC1PLUS_SPEC 25628 A C string constant that tells the GCC driver program options to 25629 pass to `cc1plus'. It can also specify how to translate options 25630 you give to GCC into options for GCC to pass to the `cc1plus'. 25631 25632 Do not define this macro if it does not need to do anything. Note 25633 that everything defined in CC1_SPEC is already passed to `cc1plus' 25634 so there is no need to duplicate the contents of CC1_SPEC in 25635 CC1PLUS_SPEC. 25636 25637 -- Macro: ASM_SPEC 25638 A C string constant that tells the GCC driver program options to 25639 pass to the assembler. It can also specify how to translate 25640 options you give to GCC into options for GCC to pass to the 25641 assembler. See the file `sun3.h' for an example of this. 25642 25643 Do not define this macro if it does not need to do anything. 25644 25645 -- Macro: ASM_FINAL_SPEC 25646 A C string constant that tells the GCC driver program how to run 25647 any programs which cleanup after the normal assembler. Normally, 25648 this is not needed. See the file `mips.h' for an example of this. 25649 25650 Do not define this macro if it does not need to do anything. 25651 25652 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 25653 Define this macro, with no value, if the driver should give the 25654 assembler an argument consisting of a single dash, `-', to 25655 instruct it to read from its standard input (which will be a pipe 25656 connected to the output of the compiler proper). This argument is 25657 given after any `-o' option specifying the name of the output file. 25658 25659 If you do not define this macro, the assembler is assumed to read 25660 its standard input if given no non-option arguments. If your 25661 assembler cannot read standard input at all, use a `%{pipe:%e}' 25662 construct; see `mips.h' for instance. 25663 25664 -- Macro: LINK_SPEC 25665 A C string constant that tells the GCC driver program options to 25666 pass to the linker. It can also specify how to translate options 25667 you give to GCC into options for GCC to pass to the linker. 25668 25669 Do not define this macro if it does not need to do anything. 25670 25671 -- Macro: LIB_SPEC 25672 Another C string constant used much like `LINK_SPEC'. The 25673 difference between the two is that `LIB_SPEC' is used at the end 25674 of the command given to the linker. 25675 25676 If this macro is not defined, a default is provided that loads the 25677 standard C library from the usual place. See `gcc.c'. 25678 25679 -- Macro: LIBGCC_SPEC 25680 Another C string constant that tells the GCC driver program how 25681 and when to place a reference to `libgcc.a' into the linker 25682 command line. This constant is placed both before and after the 25683 value of `LIB_SPEC'. 25684 25685 If this macro is not defined, the GCC driver provides a default 25686 that passes the string `-lgcc' to the linker. 25687 25688 -- Macro: REAL_LIBGCC_SPEC 25689 By default, if `ENABLE_SHARED_LIBGCC' is defined, the 25690 `LIBGCC_SPEC' is not directly used by the driver program but is 25691 instead modified to refer to different versions of `libgcc.a' 25692 depending on the values of the command line flags `-static', 25693 `-shared', `-static-libgcc', and `-shared-libgcc'. On targets 25694 where these modifications are inappropriate, define 25695 `REAL_LIBGCC_SPEC' instead. `REAL_LIBGCC_SPEC' tells the driver 25696 how to place a reference to `libgcc' on the link command line, 25697 but, unlike `LIBGCC_SPEC', it is used unmodified. 25698 25699 -- Macro: USE_LD_AS_NEEDED 25700 A macro that controls the modifications to `LIBGCC_SPEC' mentioned 25701 in `REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 25702 uses -as-needed and the shared libgcc in place of the static 25703 exception handler library, when linking without any of `-static', 25704 `-static-libgcc', or `-shared-libgcc'. 25705 25706 -- Macro: LINK_EH_SPEC 25707 If defined, this C string constant is added to `LINK_SPEC'. When 25708 `USE_LD_AS_NEEDED' is zero or undefined, it also affects the 25709 modifications to `LIBGCC_SPEC' mentioned in `REAL_LIBGCC_SPEC'. 25710 25711 -- Macro: STARTFILE_SPEC 25712 Another C string constant used much like `LINK_SPEC'. The 25713 difference between the two is that `STARTFILE_SPEC' is used at the 25714 very beginning of the command given to the linker. 25715 25716 If this macro is not defined, a default is provided that loads the 25717 standard C startup file from the usual place. See `gcc.c'. 25718 25719 -- Macro: ENDFILE_SPEC 25720 Another C string constant used much like `LINK_SPEC'. The 25721 difference between the two is that `ENDFILE_SPEC' is used at the 25722 very end of the command given to the linker. 25723 25724 Do not define this macro if it does not need to do anything. 25725 25726 -- Macro: THREAD_MODEL_SPEC 25727 GCC `-v' will print the thread model GCC was configured to use. 25728 However, this doesn't work on platforms that are multilibbed on 25729 thread models, such as AIX 4.3. On such platforms, define 25730 `THREAD_MODEL_SPEC' such that it evaluates to a string without 25731 blanks that names one of the recognized thread models. `%*', the 25732 default value of this macro, will expand to the value of 25733 `thread_file' set in `config.gcc'. 25734 25735 -- Macro: SYSROOT_SUFFIX_SPEC 25736 Define this macro to add a suffix to the target sysroot when GCC is 25737 configured with a sysroot. This will cause GCC to search for 25738 usr/lib, et al, within sysroot+suffix. 25739 25740 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 25741 Define this macro to add a headers_suffix to the target sysroot 25742 when GCC is configured with a sysroot. This will cause GCC to 25743 pass the updated sysroot+headers_suffix to CPP, causing it to 25744 search for usr/include, et al, within sysroot+headers_suffix. 25745 25746 -- Macro: EXTRA_SPECS 25747 Define this macro to provide additional specifications to put in 25748 the `specs' file that can be used in various specifications like 25749 `CC1_SPEC'. 25750 25751 The definition should be an initializer for an array of structures, 25752 containing a string constant, that defines the specification name, 25753 and a string constant that provides the specification. 25754 25755 Do not define this macro if it does not need to do anything. 25756 25757 `EXTRA_SPECS' is useful when an architecture contains several 25758 related targets, which have various `..._SPECS' which are similar 25759 to each other, and the maintainer would like one central place to 25760 keep these definitions. 25761 25762 For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to 25763 define either `_CALL_SYSV' when the System V calling sequence is 25764 used or `_CALL_AIX' when the older AIX-based calling sequence is 25765 used. 25766 25767 The `config/rs6000/rs6000.h' target file defines: 25768 25769 #define EXTRA_SPECS \ 25770 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 25771 25772 #define CPP_SYS_DEFAULT "" 25773 25774 The `config/rs6000/sysv.h' target file defines: 25775 #undef CPP_SPEC 25776 #define CPP_SPEC \ 25777 "%{posix: -D_POSIX_SOURCE } \ 25778 %{mcall-sysv: -D_CALL_SYSV } \ 25779 %{!mcall-sysv: %(cpp_sysv_default) } \ 25780 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 25781 25782 #undef CPP_SYSV_DEFAULT 25783 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 25784 25785 while the `config/rs6000/eabiaix.h' target file defines 25786 `CPP_SYSV_DEFAULT' as: 25787 25788 #undef CPP_SYSV_DEFAULT 25789 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 25790 25791 -- Macro: LINK_LIBGCC_SPECIAL_1 25792 Define this macro if the driver program should find the library 25793 `libgcc.a'. If you do not define this macro, the driver program 25794 will pass the argument `-lgcc' to tell the linker to do the search. 25795 25796 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 25797 The sequence in which libgcc and libc are specified to the linker. 25798 By default this is `%G %L %G'. 25799 25800 -- Macro: LINK_COMMAND_SPEC 25801 A C string constant giving the complete command line need to 25802 execute the linker. When you do this, you will need to update 25803 your port each time a change is made to the link command line 25804 within `gcc.c'. Therefore, define this macro only if you need to 25805 completely redefine the command line for invoking the linker and 25806 there is no other way to accomplish the effect you need. 25807 Overriding this macro may be avoidable by overriding 25808 `LINK_GCC_C_SEQUENCE_SPEC' instead. 25809 25810 -- Macro: LINK_ELIMINATE_DUPLICATE_LDIRECTORIES 25811 A nonzero value causes `collect2' to remove duplicate 25812 `-LDIRECTORY' search directories from linking commands. Do not 25813 give it a nonzero value if removing duplicate search directories 25814 changes the linker's semantics. 25815 25816 -- Macro: MULTILIB_DEFAULTS 25817 Define this macro as a C expression for the initializer of an 25818 array of string to tell the driver program which options are 25819 defaults for this target and thus do not need to be handled 25820 specially when using `MULTILIB_OPTIONS'. 25821 25822 Do not define this macro if `MULTILIB_OPTIONS' is not defined in 25823 the target makefile fragment or if none of the options listed in 25824 `MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 25825 25826 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 25827 Define this macro to tell `gcc' that it should only translate a 25828 `-B' prefix into a `-L' linker option if the prefix indicates an 25829 absolute file name. 25830 25831 -- Macro: MD_EXEC_PREFIX 25832 If defined, this macro is an additional prefix to try after 25833 `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the 25834 compiler is built as a cross compiler. If you define 25835 `MD_EXEC_PREFIX', then be sure to add it to the list of 25836 directories used to find the assembler in `configure.in'. 25837 25838 -- Macro: STANDARD_STARTFILE_PREFIX 25839 Define this macro as a C string constant if you wish to override 25840 the standard choice of `libdir' as the default prefix to try when 25841 searching for startup files such as `crt0.o'. 25842 `STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 25843 built as a cross compiler. 25844 25845 -- Macro: STANDARD_STARTFILE_PREFIX_1 25846 Define this macro as a C string constant if you wish to override 25847 the standard choice of `/lib' as a prefix to try after the default 25848 prefix when searching for startup files such as `crt0.o'. 25849 `STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 25850 built as a cross compiler. 25851 25852 -- Macro: STANDARD_STARTFILE_PREFIX_2 25853 Define this macro as a C string constant if you wish to override 25854 the standard choice of `/lib' as yet another prefix to try after 25855 the default prefix when searching for startup files such as 25856 `crt0.o'. `STANDARD_STARTFILE_PREFIX_2' is not searched when the 25857 compiler is built as a cross compiler. 25858 25859 -- Macro: MD_STARTFILE_PREFIX 25860 If defined, this macro supplies an additional prefix to try after 25861 the standard prefixes. `MD_EXEC_PREFIX' is not searched when the 25862 compiler is built as a cross compiler. 25863 25864 -- Macro: MD_STARTFILE_PREFIX_1 25865 If defined, this macro supplies yet another prefix to try after the 25866 standard prefixes. It is not searched when the compiler is built 25867 as a cross compiler. 25868 25869 -- Macro: INIT_ENVIRONMENT 25870 Define this macro as a C string constant if you wish to set 25871 environment variables for programs called by the driver, such as 25872 the assembler and loader. The driver passes the value of this 25873 macro to `putenv' to initialize the necessary environment 25874 variables. 25875 25876 -- Macro: LOCAL_INCLUDE_DIR 25877 Define this macro as a C string constant if you wish to override 25878 the standard choice of `/usr/local/include' as the default prefix 25879 to try when searching for local header files. `LOCAL_INCLUDE_DIR' 25880 comes before `SYSTEM_INCLUDE_DIR' in the search order. 25881 25882 Cross compilers do not search either `/usr/local/include' or its 25883 replacement. 25884 25885 -- Macro: SYSTEM_INCLUDE_DIR 25886 Define this macro as a C string constant if you wish to specify a 25887 system-specific directory to search for header files before the 25888 standard directory. `SYSTEM_INCLUDE_DIR' comes before 25889 `STANDARD_INCLUDE_DIR' in the search order. 25890 25891 Cross compilers do not use this macro and do not search the 25892 directory specified. 25893 25894 -- Macro: STANDARD_INCLUDE_DIR 25895 Define this macro as a C string constant if you wish to override 25896 the standard choice of `/usr/include' as the default prefix to try 25897 when searching for header files. 25898 25899 Cross compilers ignore this macro and do not search either 25900 `/usr/include' or its replacement. 25901 25902 -- Macro: STANDARD_INCLUDE_COMPONENT 25903 The "component" corresponding to `STANDARD_INCLUDE_DIR'. See 25904 `INCLUDE_DEFAULTS', below, for the description of components. If 25905 you do not define this macro, no component is used. 25906 25907 -- Macro: INCLUDE_DEFAULTS 25908 Define this macro if you wish to override the entire default 25909 search path for include files. For a native compiler, the default 25910 search path usually consists of `GCC_INCLUDE_DIR', 25911 `LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR', 25912 `GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition, 25913 `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined 25914 automatically by `Makefile', and specify private search areas for 25915 GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++ 25916 programs. 25917 25918 The definition should be an initializer for an array of structures. 25919 Each array element should have four elements: the directory name (a 25920 string constant), the component name (also a string constant), a 25921 flag for C++-only directories, and a flag showing that the 25922 includes in the directory don't need to be wrapped in `extern `C'' 25923 when compiling C++. Mark the end of the array with a null element. 25924 25925 The component name denotes what GNU package the include file is 25926 part of, if any, in all uppercase letters. For example, it might 25927 be `GCC' or `BINUTILS'. If the package is part of a 25928 vendor-supplied operating system, code the component name as `0'. 25929 25930 For example, here is the definition used for VAX/VMS: 25931 25932 #define INCLUDE_DEFAULTS \ 25933 { \ 25934 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 25935 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 25936 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 25937 { ".", 0, 0, 0}, \ 25938 { 0, 0, 0, 0} \ 25939 } 25940 25941 Here is the order of prefixes tried for exec files: 25942 25943 1. Any prefixes specified by the user with `-B'. 25944 25945 2. The environment variable `GCC_EXEC_PREFIX' or, if `GCC_EXEC_PREFIX' 25946 is not set and the compiler has not been installed in the 25947 configure-time PREFIX, the location in which the compiler has 25948 actually been installed. 25949 25950 3. The directories specified by the environment variable 25951 `COMPILER_PATH'. 25952 25953 4. The macro `STANDARD_EXEC_PREFIX', if the compiler has been 25954 installed in the configured-time PREFIX. 25955 25956 5. The location `/usr/libexec/gcc/', but only if this is a native 25957 compiler. 25958 25959 6. The location `/usr/lib/gcc/', but only if this is a native 25960 compiler. 25961 25962 7. The macro `MD_EXEC_PREFIX', if defined, but only if this is a 25963 native compiler. 25964 25965 Here is the order of prefixes tried for startfiles: 25966 25967 1. Any prefixes specified by the user with `-B'. 25968 25969 2. The environment variable `GCC_EXEC_PREFIX' or its automatically 25970 determined value based on the installed toolchain location. 25971 25972 3. The directories specified by the environment variable 25973 `LIBRARY_PATH' (or port-specific name; native only, cross 25974 compilers do not use this). 25975 25976 4. The macro `STANDARD_EXEC_PREFIX', but only if the toolchain is 25977 installed in the configured PREFIX or this is a native compiler. 25978 25979 5. The location `/usr/lib/gcc/', but only if this is a native 25980 compiler. 25981 25982 6. The macro `MD_EXEC_PREFIX', if defined, but only if this is a 25983 native compiler. 25984 25985 7. The macro `MD_STARTFILE_PREFIX', if defined, but only if this is a 25986 native compiler, or we have a target system root. 25987 25988 8. The macro `MD_STARTFILE_PREFIX_1', if defined, but only if this is 25989 a native compiler, or we have a target system root. 25990 25991 9. The macro `STANDARD_STARTFILE_PREFIX', with any sysroot 25992 modifications. If this path is relative it will be prefixed by 25993 `GCC_EXEC_PREFIX' and the machine suffix or `STANDARD_EXEC_PREFIX' 25994 and the machine suffix. 25995 25996 10. The macro `STANDARD_STARTFILE_PREFIX_1', but only if this is a 25997 native compiler, or we have a target system root. The default for 25998 this macro is `/lib/'. 25999 26000 11. The macro `STANDARD_STARTFILE_PREFIX_2', but only if this is a 26001 native compiler, or we have a target system root. The default for 26002 this macro is `/usr/lib/'. 26003 26004 26005 File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 26006 26007 17.3 Run-time Target Specification 26008 ================================== 26009 26010 Here are run-time target specifications. 26011 26012 -- Macro: TARGET_CPU_CPP_BUILTINS () 26013 This function-like macro expands to a block of code that defines 26014 built-in preprocessor macros and assertions for the target CPU, 26015 using the functions `builtin_define', `builtin_define_std' and 26016 `builtin_assert'. When the front end calls this macro it provides 26017 a trailing semicolon, and since it has finished command line 26018 option processing your code can use those results freely. 26019 26020 `builtin_assert' takes a string in the form you pass to the 26021 command-line option `-A', such as `cpu=mips', and creates the 26022 assertion. `builtin_define' takes a string in the form accepted 26023 by option `-D' and unconditionally defines the macro. 26024 26025 `builtin_define_std' takes a string representing the name of an 26026 object-like macro. If it doesn't lie in the user's namespace, 26027 `builtin_define_std' defines it unconditionally. Otherwise, it 26028 defines a version with two leading underscores, and another version 26029 with two leading and trailing underscores, and defines the original 26030 only if an ISO standard was not requested on the command line. For 26031 example, passing `unix' defines `__unix', `__unix__' and possibly 26032 `unix'; passing `_mips' defines `__mips', `__mips__' and possibly 26033 `_mips', and passing `_ABI64' defines only `_ABI64'. 26034 26035 You can also test for the C dialect being compiled. The variable 26036 `c_language' is set to one of `clk_c', `clk_cplusplus' or 26037 `clk_objective_c'. Note that if we are preprocessing assembler, 26038 this variable will be `clk_c' but the function-like macro 26039 `preprocessing_asm_p()' will return true, so you might want to 26040 check for that first. If you need to check for strict ANSI, the 26041 variable `flag_iso' can be used. The function-like macro 26042 `preprocessing_trad_p()' can be used to check for traditional 26043 preprocessing. 26044 26045 -- Macro: TARGET_OS_CPP_BUILTINS () 26046 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 26047 and is used for the target operating system instead. 26048 26049 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 26050 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 26051 and is used for the target object format. `elfos.h' uses this 26052 macro to define `__ELF__', so you probably do not need to define 26053 it yourself. 26054 26055 -- Variable: extern int target_flags 26056 This variable is declared in `options.h', which is included before 26057 any target-specific headers. 26058 26059 -- Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 26060 This variable specifies the initial value of `target_flags'. Its 26061 default setting is 0. 26062 26063 -- Target Hook: bool TARGET_HANDLE_OPTION (size_t CODE, const char 26064 *ARG, int VALUE) 26065 This hook is called whenever the user specifies one of the 26066 target-specific options described by the `.opt' definition files 26067 (*note Options::). It has the opportunity to do some 26068 option-specific processing and should return true if the option is 26069 valid. The default definition does nothing but return true. 26070 26071 CODE specifies the `OPT_NAME' enumeration value associated with 26072 the selected option; NAME is just a rendering of the option name 26073 in which non-alphanumeric characters are replaced by underscores. 26074 ARG specifies the string argument and is null if no argument was 26075 given. If the option is flagged as a `UInteger' (*note Option 26076 properties::), VALUE is the numeric value of the argument. 26077 Otherwise VALUE is 1 if the positive form of the option was used 26078 and 0 if the "no-" form was. 26079 26080 -- Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 26081 *ARG, int VALUE) 26082 This target hook is called whenever the user specifies one of the 26083 target-specific C language family options described by the `.opt' 26084 definition files(*note Options::). It has the opportunity to do 26085 some option-specific processing and should return true if the 26086 option is valid. The arguments are like for 26087 `TARGET_HANDLE_OPTION'. The default definition does nothing but 26088 return false. 26089 26090 In general, you should use `TARGET_HANDLE_OPTION' to handle 26091 options. However, if processing an option requires routines that 26092 are only available in the C (and related language) front ends, 26093 then you should use `TARGET_HANDLE_C_OPTION' instead. 26094 26095 -- Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree STRING) 26096 Targets may provide a string object type that can be used within 26097 and between C, C++ and their respective Objective-C dialects. A 26098 string object might, for example, embed encoding and length 26099 information. These objects are considered opaque to the compiler 26100 and handled as references. An ideal implementation makes the 26101 composition of the string object match that of the Objective-C 26102 `NSString' (`NXString' for GNUStep), allowing efficient 26103 interworking between C-only and Objective-C code. If a target 26104 implements string objects then this hook should return a reference 26105 to such an object constructed from the normal `C' string 26106 representation provided in STRING. At present, the hook is used by 26107 Objective-C only, to obtain a common-format string object when the 26108 target provides one. 26109 26110 -- Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 26111 STRINGREF) 26112 If a target implements string objects then this hook should return 26113 `true' if STRINGREF is a valid reference to such an object. 26114 26115 -- Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree 26116 FORMAT_ARG, tree ARGS_LIST) 26117 If a target implements string objects then this hook should should 26118 provide a facility to check the function arguments in ARGS_LIST 26119 against the format specifiers in FORMAT_ARG where the type of 26120 FORMAT_ARG is one recognized as a valid string reference type. 26121 26122 -- Macro: TARGET_VERSION 26123 This macro is a C statement to print on `stderr' a string 26124 describing the particular machine description choice. Every 26125 machine description should define `TARGET_VERSION'. For example: 26126 26127 #ifdef MOTOROLA 26128 #define TARGET_VERSION \ 26129 fprintf (stderr, " (68k, Motorola syntax)"); 26130 #else 26131 #define TARGET_VERSION \ 26132 fprintf (stderr, " (68k, MIT syntax)"); 26133 #endif 26134 26135 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 26136 This target function is similar to the hook 26137 `TARGET_OPTION_OVERRIDE' but is called when the optimize level is 26138 changed via an attribute or pragma or when it is reset at the end 26139 of the code affected by the attribute or pragma. It is not called 26140 at the beginning of compilation when `TARGET_OPTION_OVERRIDE' is 26141 called so if you want to perform these actions then, you should 26142 have `TARGET_OPTION_OVERRIDE' call 26143 `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 26144 26145 -- Macro: C_COMMON_OVERRIDE_OPTIONS 26146 This is similar to the `TARGET_OPTION_OVERRIDE' hook but is only 26147 used in the C language frontends (C, Objective-C, C++, 26148 Objective-C++) and so can be used to alter option flag variables 26149 which only exist in those frontends. 26150 26151 -- Target Hook: const struct default_options * 26152 TARGET_OPTION_OPTIMIZATION_TABLE 26153 Some machines may desire to change what optimizations are 26154 performed for various optimization levels. This variable, if 26155 defined, describes options to enable at particular sets of 26156 optimization levels. These options are processed once just after 26157 the optimization level is determined and before the remainder of 26158 the command options have been parsed, so may be overridden by other 26159 options passed explicitly. 26160 26161 This processing is run once at program startup and when the 26162 optimization options are changed via `#pragma GCC optimize' or by 26163 using the `optimize' attribute. 26164 26165 -- Target Hook: void TARGET_OPTION_INIT_STRUCT (struct gcc_options 26166 *OPTS) 26167 Set target-dependent initial values of fields in OPTS. 26168 26169 -- Target Hook: void TARGET_OPTION_DEFAULT_PARAMS (void) 26170 Set target-dependent default values for `--param' settings, using 26171 calls to `set_default_param_value'. 26172 26173 -- Target Hook: void TARGET_HELP (void) 26174 This hook is called in response to the user invoking 26175 `--target-help' on the command line. It gives the target a chance 26176 to display extra information on the target specific command line 26177 options found in its `.opt' file. 26178 26179 -- Macro: SWITCHABLE_TARGET 26180 Some targets need to switch between substantially different 26181 subtargets during compilation. For example, the MIPS target has 26182 one subtarget for the traditional MIPS architecture and another 26183 for MIPS16. Source code can switch between these two 26184 subarchitectures using the `mips16' and `nomips16' attributes. 26185 26186 Such subtargets can differ in things like the set of available 26187 registers, the set of available instructions, the costs of various 26188 operations, and so on. GCC caches a lot of this type of 26189 information in global variables, and recomputing them for each 26190 subtarget takes a significant amount of time. The compiler 26191 therefore provides a facility for maintaining several versions of 26192 the global variables and quickly switching between them; see 26193 `target-globals.h' for details. 26194 26195 Define this macro to 1 if your target needs this facility. The 26196 default is 0. 26197 26198 26199 File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 26200 26201 17.4 Defining data structures for per-function information. 26202 =========================================================== 26203 26204 If the target needs to store information on a per-function basis, GCC 26205 provides a macro and a couple of variables to allow this. Note, just 26206 using statics to store the information is a bad idea, since GCC supports 26207 nested functions, so you can be halfway through encoding one function 26208 when another one comes along. 26209 26210 GCC defines a data structure called `struct function' which contains 26211 all of the data specific to an individual function. This structure 26212 contains a field called `machine' whose type is `struct 26213 machine_function *', which can be used by targets to point to their own 26214 specific data. 26215 26216 If a target needs per-function specific data it should define the type 26217 `struct machine_function' and also the macro `INIT_EXPANDERS'. This 26218 macro should be used to initialize the function pointer 26219 `init_machine_status'. This pointer is explained below. 26220 26221 One typical use of per-function, target specific data is to create an 26222 RTX to hold the register containing the function's return address. This 26223 RTX can then be used to implement the `__builtin_return_address' 26224 function, for level 0. 26225 26226 Note--earlier implementations of GCC used a single data area to hold 26227 all of the per-function information. Thus when processing of a nested 26228 function began the old per-function data had to be pushed onto a stack, 26229 and when the processing was finished, it had to be popped off the 26230 stack. GCC used to provide function pointers called 26231 `save_machine_status' and `restore_machine_status' to handle the saving 26232 and restoring of the target specific information. Since the single 26233 data area approach is no longer used, these pointers are no longer 26234 supported. 26235 26236 -- Macro: INIT_EXPANDERS 26237 Macro called to initialize any target specific information. This 26238 macro is called once per function, before generation of any RTL 26239 has begun. The intention of this macro is to allow the 26240 initialization of the function pointer `init_machine_status'. 26241 26242 -- Variable: void (*)(struct function *) init_machine_status 26243 If this function pointer is non-`NULL' it will be called once per 26244 function, before function compilation starts, in order to allow the 26245 target to perform any target specific initialization of the 26246 `struct function' structure. It is intended that this would be 26247 used to initialize the `machine' of that structure. 26248 26249 `struct machine_function' structures are expected to be freed by 26250 GC. Generally, any memory that they reference must be allocated 26251 by using GC allocation, including the structure itself. 26252 26253 26254 File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 26255 26256 17.5 Storage Layout 26257 =================== 26258 26259 Note that the definitions of the macros in this table which are sizes or 26260 alignments measured in bits do not need to be constant. They can be C 26261 expressions that refer to static variables, such as the `target_flags'. 26262 *Note Run-time Target::. 26263 26264 -- Macro: BITS_BIG_ENDIAN 26265 Define this macro to have the value 1 if the most significant bit 26266 in a byte has the lowest number; otherwise define it to have the 26267 value zero. This means that bit-field instructions count from the 26268 most significant bit. If the machine has no bit-field 26269 instructions, then this must still be defined, but it doesn't 26270 matter which value it is defined to. This macro need not be a 26271 constant. 26272 26273 This macro does not affect the way structure fields are packed into 26274 bytes or words; that is controlled by `BYTES_BIG_ENDIAN'. 26275 26276 -- Macro: BYTES_BIG_ENDIAN 26277 Define this macro to have the value 1 if the most significant byte 26278 in a word has the lowest number. This macro need not be a 26279 constant. 26280 26281 -- Macro: WORDS_BIG_ENDIAN 26282 Define this macro to have the value 1 if, in a multiword object, 26283 the most significant word has the lowest number. This applies to 26284 both memory locations and registers; GCC fundamentally assumes 26285 that the order of words in memory is the same as the order in 26286 registers. This macro need not be a constant. 26287 26288 -- Macro: FLOAT_WORDS_BIG_ENDIAN 26289 Define this macro to have the value 1 if `DFmode', `XFmode' or 26290 `TFmode' floating point numbers are stored in memory with the word 26291 containing the sign bit at the lowest address; otherwise define it 26292 to have the value 0. This macro need not be a constant. 26293 26294 You need not define this macro if the ordering is the same as for 26295 multi-word integers. 26296 26297 -- Macro: BITS_PER_UNIT 26298 Define this macro to be the number of bits in an addressable 26299 storage unit (byte). If you do not define this macro the default 26300 is 8. 26301 26302 -- Macro: BITS_PER_WORD 26303 Number of bits in a word. If you do not define this macro, the 26304 default is `BITS_PER_UNIT * UNITS_PER_WORD'. 26305 26306 -- Macro: MAX_BITS_PER_WORD 26307 Maximum number of bits in a word. If this is undefined, the 26308 default is `BITS_PER_WORD'. Otherwise, it is the constant value 26309 that is the largest value that `BITS_PER_WORD' can have at 26310 run-time. 26311 26312 -- Macro: UNITS_PER_WORD 26313 Number of storage units in a word; normally the size of a 26314 general-purpose register, a power of two from 1 or 8. 26315 26316 -- Macro: MIN_UNITS_PER_WORD 26317 Minimum number of units in a word. If this is undefined, the 26318 default is `UNITS_PER_WORD'. Otherwise, it is the constant value 26319 that is the smallest value that `UNITS_PER_WORD' can have at 26320 run-time. 26321 26322 -- Macro: POINTER_SIZE 26323 Width of a pointer, in bits. You must specify a value no wider 26324 than the width of `Pmode'. If it is not equal to the width of 26325 `Pmode', you must define `POINTERS_EXTEND_UNSIGNED'. If you do 26326 not specify a value the default is `BITS_PER_WORD'. 26327 26328 -- Macro: POINTERS_EXTEND_UNSIGNED 26329 A C expression that determines how pointers should be extended from 26330 `ptr_mode' to either `Pmode' or `word_mode'. It is greater than 26331 zero if pointers should be zero-extended, zero if they should be 26332 sign-extended, and negative if some other sort of conversion is 26333 needed. In the last case, the extension is done by the target's 26334 `ptr_extend' instruction. 26335 26336 You need not define this macro if the `ptr_mode', `Pmode' and 26337 `word_mode' are all the same width. 26338 26339 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 26340 A macro to update M and UNSIGNEDP when an object whose type is 26341 TYPE and which has the specified mode and signedness is to be 26342 stored in a register. This macro is only called when TYPE is a 26343 scalar type. 26344 26345 On most RISC machines, which only have operations that operate on 26346 a full register, define this macro to set M to `word_mode' if M is 26347 an integer mode narrower than `BITS_PER_WORD'. In most cases, 26348 only integer modes should be widened because wider-precision 26349 floating-point operations are usually more expensive than their 26350 narrower counterparts. 26351 26352 For most machines, the macro definition does not change UNSIGNEDP. 26353 However, some machines, have instructions that preferentially 26354 handle either signed or unsigned quantities of certain modes. For 26355 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 26356 instructions sign-extend the result to 64 bits. On such machines, 26357 set UNSIGNEDP according to which kind of extension is more 26358 efficient. 26359 26360 Do not define this macro if it would never modify M. 26361 26362 -- Target Hook: enum machine_mode TARGET_PROMOTE_FUNCTION_MODE 26363 (const_tree TYPE, enum machine_mode MODE, int *PUNSIGNEDP, 26364 const_tree FUNTYPE, int FOR_RETURN) 26365 Like `PROMOTE_MODE', but it is applied to outgoing function 26366 arguments or function return values. The target hook should 26367 return the new mode and possibly change `*PUNSIGNEDP' if the 26368 promotion should change signedness. This function is called only 26369 for scalar _or pointer_ types. 26370 26371 FOR_RETURN allows to distinguish the promotion of arguments and 26372 return values. If it is `1', a return value is being promoted and 26373 `TARGET_FUNCTION_VALUE' must perform the same promotions done here. 26374 If it is `2', the returned mode should be that of the register in 26375 which an incoming parameter is copied, or the outgoing result is 26376 computed; then the hook should return the same mode as 26377 `promote_mode', though the signedness may be different. 26378 26379 The default is to not promote arguments and return values. You can 26380 also define the hook to 26381 `default_promote_function_mode_always_promote' if you would like 26382 to apply the same rules given by `PROMOTE_MODE'. 26383 26384 -- Macro: PARM_BOUNDARY 26385 Normal alignment required for function parameters on the stack, in 26386 bits. All stack parameters receive at least this much alignment 26387 regardless of data type. On most machines, this is the same as the 26388 size of an integer. 26389 26390 -- Macro: STACK_BOUNDARY 26391 Define this macro to the minimum alignment enforced by hardware 26392 for the stack pointer on this machine. The definition is a C 26393 expression for the desired alignment (measured in bits). This 26394 value is used as a default if `PREFERRED_STACK_BOUNDARY' is not 26395 defined. On most machines, this should be the same as 26396 `PARM_BOUNDARY'. 26397 26398 -- Macro: PREFERRED_STACK_BOUNDARY 26399 Define this macro if you wish to preserve a certain alignment for 26400 the stack pointer, greater than what the hardware enforces. The 26401 definition is a C expression for the desired alignment (measured 26402 in bits). This macro must evaluate to a value equal to or larger 26403 than `STACK_BOUNDARY'. 26404 26405 -- Macro: INCOMING_STACK_BOUNDARY 26406 Define this macro if the incoming stack boundary may be different 26407 from `PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 26408 value equal to or larger than `STACK_BOUNDARY'. 26409 26410 -- Macro: FUNCTION_BOUNDARY 26411 Alignment required for a function entry point, in bits. 26412 26413 -- Macro: BIGGEST_ALIGNMENT 26414 Biggest alignment that any data type can require on this machine, 26415 in bits. Note that this is not the biggest alignment that is 26416 supported, just the biggest alignment that, when violated, may 26417 cause a fault. 26418 26419 -- Macro: MALLOC_ABI_ALIGNMENT 26420 Alignment, in bits, a C conformant malloc implementation has to 26421 provide. If not defined, the default value is `BITS_PER_WORD'. 26422 26423 -- Macro: ATTRIBUTE_ALIGNED_VALUE 26424 Alignment used by the `__attribute__ ((aligned))' construct. If 26425 not defined, the default value is `BIGGEST_ALIGNMENT'. 26426 26427 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 26428 If defined, the smallest alignment, in bits, that can be given to 26429 an object that can be referenced in one operation, without 26430 disturbing any nearby object. Normally, this is `BITS_PER_UNIT', 26431 but may be larger on machines that don't have byte or half-word 26432 store operations. 26433 26434 -- Macro: BIGGEST_FIELD_ALIGNMENT 26435 Biggest alignment that any structure or union field can require on 26436 this machine, in bits. If defined, this overrides 26437 `BIGGEST_ALIGNMENT' for structure and union fields only, unless 26438 the field alignment has been set by the `__attribute__ ((aligned 26439 (N)))' construct. 26440 26441 -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED) 26442 An expression for the alignment of a structure field FIELD if the 26443 alignment computed in the usual way (including applying of 26444 `BIGGEST_ALIGNMENT' and `BIGGEST_FIELD_ALIGNMENT' to the 26445 alignment) is COMPUTED. It overrides alignment only if the field 26446 alignment has not been set by the `__attribute__ ((aligned (N)))' 26447 construct. 26448 26449 -- Macro: MAX_STACK_ALIGNMENT 26450 Biggest stack alignment guaranteed by the backend. Use this macro 26451 to specify the maximum alignment of a variable on stack. 26452 26453 If not defined, the default value is `STACK_BOUNDARY'. 26454 26455 26456 -- Macro: MAX_OFILE_ALIGNMENT 26457 Biggest alignment supported by the object file format of this 26458 machine. Use this macro to limit the alignment which can be 26459 specified using the `__attribute__ ((aligned (N)))' construct. If 26460 not defined, the default value is `BIGGEST_ALIGNMENT'. 26461 26462 On systems that use ELF, the default (in `config/elfos.h') is the 26463 largest supported 32-bit ELF section alignment representable on a 26464 32-bit host e.g. `(((unsigned HOST_WIDEST_INT) 1 << 28) * 8)'. On 26465 32-bit ELF the largest supported section alignment in bits is 26466 `(0x80000000 * 8)', but this is not representable on 32-bit hosts. 26467 26468 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 26469 If defined, a C expression to compute the alignment for a variable 26470 in the static store. TYPE is the data type, and BASIC-ALIGN is 26471 the alignment that the object would ordinarily have. The value of 26472 this macro is used instead of that alignment to align the object. 26473 26474 If this macro is not defined, then BASIC-ALIGN is used. 26475 26476 One use of this macro is to increase alignment of medium-size data 26477 to make it all fit in fewer cache lines. Another is to cause 26478 character arrays to be word-aligned so that `strcpy' calls that 26479 copy constants to character arrays can be done inline. 26480 26481 -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN) 26482 If defined, a C expression to compute the alignment given to a 26483 constant that is being placed in memory. CONSTANT is the constant 26484 and BASIC-ALIGN is the alignment that the object would ordinarily 26485 have. The value of this macro is used instead of that alignment to 26486 align the object. 26487 26488 If this macro is not defined, then BASIC-ALIGN is used. 26489 26490 The typical use of this macro is to increase alignment for string 26491 constants to be word aligned so that `strcpy' calls that copy 26492 constants can be done inline. 26493 26494 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 26495 If defined, a C expression to compute the alignment for a variable 26496 in the local store. TYPE is the data type, and BASIC-ALIGN is the 26497 alignment that the object would ordinarily have. The value of this 26498 macro is used instead of that alignment to align the object. 26499 26500 If this macro is not defined, then BASIC-ALIGN is used. 26501 26502 One use of this macro is to increase alignment of medium-size data 26503 to make it all fit in fewer cache lines. 26504 26505 If the value of this macro has a type, it should be an unsigned 26506 type. 26507 26508 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 26509 If defined, a C expression to compute the alignment for stack slot. 26510 TYPE is the data type, MODE is the widest mode available, and 26511 BASIC-ALIGN is the alignment that the slot would ordinarily have. 26512 The value of this macro is used instead of that alignment to align 26513 the slot. 26514 26515 If this macro is not defined, then BASIC-ALIGN is used when TYPE 26516 is `NULL'. Otherwise, `LOCAL_ALIGNMENT' will be used. 26517 26518 This macro is to set alignment of stack slot to the maximum 26519 alignment of all possible modes which the slot may have. 26520 26521 If the value of this macro has a type, it should be an unsigned 26522 type. 26523 26524 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 26525 If defined, a C expression to compute the alignment for a local 26526 variable DECL. 26527 26528 If this macro is not defined, then `LOCAL_ALIGNMENT (TREE_TYPE 26529 (DECL), DECL_ALIGN (DECL))' is used. 26530 26531 One use of this macro is to increase alignment of medium-size data 26532 to make it all fit in fewer cache lines. 26533 26534 If the value of this macro has a type, it should be an unsigned 26535 type. 26536 26537 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 26538 If defined, a C expression to compute the minimum required 26539 alignment for dynamic stack realignment purposes for EXP (a type 26540 or decl), MODE, assuming normal alignment ALIGN. 26541 26542 If this macro is not defined, then ALIGN will be used. 26543 26544 -- Macro: EMPTY_FIELD_BOUNDARY 26545 Alignment in bits to be given to a structure bit-field that 26546 follows an empty field such as `int : 0;'. 26547 26548 If `PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 26549 26550 -- Macro: STRUCTURE_SIZE_BOUNDARY 26551 Number of bits which any structure or union's size must be a 26552 multiple of. Each structure or union's size is rounded up to a 26553 multiple of this. 26554 26555 If you do not define this macro, the default is the same as 26556 `BITS_PER_UNIT'. 26557 26558 -- Macro: STRICT_ALIGNMENT 26559 Define this macro to be the value 1 if instructions will fail to 26560 work if given data not on the nominal alignment. If instructions 26561 will merely go slower in that case, define this macro as 0. 26562 26563 -- Macro: PCC_BITFIELD_TYPE_MATTERS 26564 Define this if you wish to imitate the way many other C compilers 26565 handle alignment of bit-fields and the structures that contain 26566 them. 26567 26568 The behavior is that the type written for a named bit-field (`int', 26569 `short', or other integer type) imposes an alignment for the entire 26570 structure, as if the structure really did contain an ordinary 26571 field of that type. In addition, the bit-field is placed within 26572 the structure so that it would fit within such a field, not 26573 crossing a boundary for it. 26574 26575 Thus, on most machines, a named bit-field whose type is written as 26576 `int' would not cross a four-byte boundary, and would force 26577 four-byte alignment for the whole structure. (The alignment used 26578 may not be four bytes; it is controlled by the other alignment 26579 parameters.) 26580 26581 An unnamed bit-field will not affect the alignment of the 26582 containing structure. 26583 26584 If the macro is defined, its definition should be a C expression; 26585 a nonzero value for the expression enables this behavior. 26586 26587 Note that if this macro is not defined, or its value is zero, some 26588 bit-fields may cross more than one alignment boundary. The 26589 compiler can support such references if there are `insv', `extv', 26590 and `extzv' insns that can directly reference memory. 26591 26592 The other known way of making bit-fields work is to define 26593 `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then 26594 every structure can be accessed with fullwords. 26595 26596 Unless the machine has bit-field instructions or you define 26597 `STRUCTURE_SIZE_BOUNDARY' that way, you must define 26598 `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 26599 26600 If your aim is to make GCC use the same conventions for laying out 26601 bit-fields as are used by another compiler, here is how to 26602 investigate what the other compiler does. Compile and run this 26603 program: 26604 26605 struct foo1 26606 { 26607 char x; 26608 char :0; 26609 char y; 26610 }; 26611 26612 struct foo2 26613 { 26614 char x; 26615 int :0; 26616 char y; 26617 }; 26618 26619 main () 26620 { 26621 printf ("Size of foo1 is %d\n", 26622 sizeof (struct foo1)); 26623 printf ("Size of foo2 is %d\n", 26624 sizeof (struct foo2)); 26625 exit (0); 26626 } 26627 26628 If this prints 2 and 5, then the compiler's behavior is what you 26629 would get from `PCC_BITFIELD_TYPE_MATTERS'. 26630 26631 -- Macro: BITFIELD_NBYTES_LIMITED 26632 Like `PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 26633 to aligning a bit-field within the structure. 26634 26635 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 26636 When `PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 26637 whether unnamed bitfields affect the alignment of the containing 26638 structure. The hook should return true if the structure should 26639 inherit the alignment requirements of an unnamed bitfield's type. 26640 26641 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 26642 This target hook should return `true' if accesses to volatile 26643 bitfields should use the narrowest mode possible. It should 26644 return `false' if these accesses should use the bitfield container 26645 type. 26646 26647 The default is `!TARGET_STRICT_ALIGN'. 26648 26649 -- Macro: MEMBER_TYPE_FORCES_BLK (FIELD, MODE) 26650 Return 1 if a structure or array containing FIELD should be 26651 accessed using `BLKMODE'. 26652 26653 If FIELD is the only field in the structure, MODE is its mode, 26654 otherwise MODE is VOIDmode. MODE is provided in the case where 26655 structures of one field would require the structure's mode to 26656 retain the field's mode. 26657 26658 Normally, this is not needed. 26659 26660 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 26661 Define this macro as an expression for the alignment of a type 26662 (given by TYPE as a tree node) if the alignment computed in the 26663 usual way is COMPUTED and the alignment explicitly specified was 26664 SPECIFIED. 26665 26666 The default is to use SPECIFIED if it is larger; otherwise, use 26667 the smaller of COMPUTED and `BIGGEST_ALIGNMENT' 26668 26669 -- Macro: MAX_FIXED_MODE_SIZE 26670 An integer expression for the size in bits of the largest integer 26671 machine mode that should actually be used. All integer machine 26672 modes of this size or smaller can be used for structures and 26673 unions with the appropriate sizes. If this macro is undefined, 26674 `GET_MODE_BITSIZE (DImode)' is assumed. 26675 26676 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 26677 If defined, an expression of type `enum machine_mode' that 26678 specifies the mode of the save area operand of a 26679 `save_stack_LEVEL' named pattern (*note Standard Names::). 26680 SAVE_LEVEL is one of `SAVE_BLOCK', `SAVE_FUNCTION', or 26681 `SAVE_NONLOCAL' and selects which of the three named patterns is 26682 having its mode specified. 26683 26684 You need not define this macro if it always returns `Pmode'. You 26685 would most commonly define this macro if the `save_stack_LEVEL' 26686 patterns need to support both a 32- and a 64-bit mode. 26687 26688 -- Macro: STACK_SIZE_MODE 26689 If defined, an expression of type `enum machine_mode' that 26690 specifies the mode of the size increment operand of an 26691 `allocate_stack' named pattern (*note Standard Names::). 26692 26693 You need not define this macro if it always returns `word_mode'. 26694 You would most commonly define this macro if the `allocate_stack' 26695 pattern needs to support both a 32- and a 64-bit mode. 26696 26697 -- Target Hook: enum machine_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 26698 This target hook should return the mode to be used for the return 26699 value of compare instructions expanded to libgcc calls. If not 26700 defined `word_mode' is returned which is the right choice for a 26701 majority of targets. 26702 26703 -- Target Hook: enum machine_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 26704 This target hook should return the mode to be used for the shift 26705 count operand of shift instructions expanded to libgcc calls. If 26706 not defined `word_mode' is returned which is the right choice for 26707 a majority of targets. 26708 26709 -- Target Hook: enum machine_mode TARGET_UNWIND_WORD_MODE (void) 26710 Return machine mode to be used for `_Unwind_Word' type. The 26711 default is to use `word_mode'. 26712 26713 -- Macro: ROUND_TOWARDS_ZERO 26714 If defined, this macro should be true if the prevailing rounding 26715 mode is towards zero. 26716 26717 Defining this macro only affects the way `libgcc.a' emulates 26718 floating-point arithmetic. 26719 26720 Not defining this macro is equivalent to returning zero. 26721 26722 -- Macro: LARGEST_EXPONENT_IS_NORMAL (SIZE) 26723 This macro should return true if floats with SIZE bits do not have 26724 a NaN or infinity representation, but use the largest exponent for 26725 normal numbers instead. 26726 26727 Defining this macro only affects the way `libgcc.a' emulates 26728 floating-point arithmetic. 26729 26730 The default definition of this macro returns false for all sizes. 26731 26732 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 26733 RECORD_TYPE) 26734 This target hook returns `true' if bit-fields in the given 26735 RECORD_TYPE are to be laid out following the rules of Microsoft 26736 Visual C/C++, namely: (i) a bit-field won't share the same storage 26737 unit with the previous bit-field if their underlying types have 26738 different sizes, and the bit-field will be aligned to the highest 26739 alignment of the underlying types of itself and of the previous 26740 bit-field; (ii) a zero-sized bit-field will affect the alignment of 26741 the whole enclosing structure, even if it is unnamed; except that 26742 (iii) a zero-sized bit-field will be disregarded unless it follows 26743 another bit-field of nonzero size. If this hook returns `true', 26744 other macros that control bit-field layout are ignored. 26745 26746 When a bit-field is inserted into a packed record, the whole size 26747 of the underlying type is used by one or more same-size adjacent 26748 bit-fields (that is, if its long:3, 32 bits is used in the record, 26749 and any additional adjacent long bit-fields are packed into the 26750 same chunk of 32 bits. However, if the size changes, a new field 26751 of that size is allocated). In an unpacked record, this is the 26752 same as using alignment, but not equivalent when packing. 26753 26754 If both MS bit-fields and `__attribute__((packed))' are used, the 26755 latter will take precedence. If `__attribute__((packed))' is used 26756 on a single field when MS bit-fields are in use, it will take 26757 precedence for that field, but the alignment of the rest of the 26758 structure may affect its placement. 26759 26760 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 26761 Returns true if the target supports decimal floating point. 26762 26763 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 26764 Returns true if the target supports fixed-point arithmetic. 26765 26766 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 26767 This hook is called just before expansion into rtl, allowing the 26768 target to perform additional initializations or analysis before 26769 the expansion. For example, the rs6000 port uses it to allocate a 26770 scratch stack slot for use in copying SDmode values between memory 26771 and floating point registers whenever the function being expanded 26772 has any SDmode usage. 26773 26774 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 26775 This hook allows the backend to perform additional instantiations 26776 on rtl that are not actually in any insns yet, but will be later. 26777 26778 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 26779 If your target defines any fundamental types, or any types your 26780 target uses should be mangled differently from the default, define 26781 this hook to return the appropriate encoding for these types as 26782 part of a C++ mangled name. The TYPE argument is the tree 26783 structure representing the type to be mangled. The hook may be 26784 applied to trees which are not target-specific fundamental types; 26785 it should return `NULL' for all such types, as well as arguments 26786 it does not recognize. If the return value is not `NULL', it must 26787 point to a statically-allocated string constant. 26788 26789 Target-specific fundamental types might be new fundamental types or 26790 qualified versions of ordinary fundamental types. Encode new 26791 fundamental types as `u N NAME', where NAME is the name used for 26792 the type in source code, and N is the length of NAME in decimal. 26793 Encode qualified versions of ordinary types as `U N NAME CODE', 26794 where NAME is the name used for the type qualifier in source code, 26795 N is the length of NAME as above, and CODE is the code used to 26796 represent the unqualified version of this type. (See 26797 `write_builtin_type' in `cp/mangle.c' for the list of codes.) In 26798 both cases the spaces are for clarity; do not include any spaces 26799 in your string. 26800 26801 This hook is applied to types prior to typedef resolution. If the 26802 mangled name for a particular type depends only on that type's 26803 main variant, you can perform typedef resolution yourself using 26804 `TYPE_MAIN_VARIANT' before mangling. 26805 26806 The default version of this hook always returns `NULL', which is 26807 appropriate for a target that does not define any new fundamental 26808 types. 26809 26810 26811 File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 26812 26813 17.6 Layout of Source Language Data Types 26814 ========================================= 26815 26816 These macros define the sizes and other characteristics of the standard 26817 basic data types used in programs being compiled. Unlike the macros in 26818 the previous section, these apply to specific features of C and related 26819 languages, rather than to fundamental aspects of storage layout. 26820 26821 -- Macro: INT_TYPE_SIZE 26822 A C expression for the size in bits of the type `int' on the 26823 target machine. If you don't define this, the default is one word. 26824 26825 -- Macro: SHORT_TYPE_SIZE 26826 A C expression for the size in bits of the type `short' on the 26827 target machine. If you don't define this, the default is half a 26828 word. (If this would be less than one storage unit, it is rounded 26829 up to one unit.) 26830 26831 -- Macro: LONG_TYPE_SIZE 26832 A C expression for the size in bits of the type `long' on the 26833 target machine. If you don't define this, the default is one word. 26834 26835 -- Macro: ADA_LONG_TYPE_SIZE 26836 On some machines, the size used for the Ada equivalent of the type 26837 `long' by a native Ada compiler differs from that used by C. In 26838 that situation, define this macro to be a C expression to be used 26839 for the size of that type. If you don't define this, the default 26840 is the value of `LONG_TYPE_SIZE'. 26841 26842 -- Macro: LONG_LONG_TYPE_SIZE 26843 A C expression for the size in bits of the type `long long' on the 26844 target machine. If you don't define this, the default is two 26845 words. If you want to support GNU Ada on your machine, the value 26846 of this macro must be at least 64. 26847 26848 -- Macro: CHAR_TYPE_SIZE 26849 A C expression for the size in bits of the type `char' on the 26850 target machine. If you don't define this, the default is 26851 `BITS_PER_UNIT'. 26852 26853 -- Macro: BOOL_TYPE_SIZE 26854 A C expression for the size in bits of the C++ type `bool' and C99 26855 type `_Bool' on the target machine. If you don't define this, and 26856 you probably shouldn't, the default is `CHAR_TYPE_SIZE'. 26857 26858 -- Macro: FLOAT_TYPE_SIZE 26859 A C expression for the size in bits of the type `float' on the 26860 target machine. If you don't define this, the default is one word. 26861 26862 -- Macro: DOUBLE_TYPE_SIZE 26863 A C expression for the size in bits of the type `double' on the 26864 target machine. If you don't define this, the default is two 26865 words. 26866 26867 -- Macro: LONG_DOUBLE_TYPE_SIZE 26868 A C expression for the size in bits of the type `long double' on 26869 the target machine. If you don't define this, the default is two 26870 words. 26871 26872 -- Macro: SHORT_FRACT_TYPE_SIZE 26873 A C expression for the size in bits of the type `short _Fract' on 26874 the target machine. If you don't define this, the default is 26875 `BITS_PER_UNIT'. 26876 26877 -- Macro: FRACT_TYPE_SIZE 26878 A C expression for the size in bits of the type `_Fract' on the 26879 target machine. If you don't define this, the default is 26880 `BITS_PER_UNIT * 2'. 26881 26882 -- Macro: LONG_FRACT_TYPE_SIZE 26883 A C expression for the size in bits of the type `long _Fract' on 26884 the target machine. If you don't define this, the default is 26885 `BITS_PER_UNIT * 4'. 26886 26887 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 26888 A C expression for the size in bits of the type `long long _Fract' 26889 on the target machine. If you don't define this, the default is 26890 `BITS_PER_UNIT * 8'. 26891 26892 -- Macro: SHORT_ACCUM_TYPE_SIZE 26893 A C expression for the size in bits of the type `short _Accum' on 26894 the target machine. If you don't define this, the default is 26895 `BITS_PER_UNIT * 2'. 26896 26897 -- Macro: ACCUM_TYPE_SIZE 26898 A C expression for the size in bits of the type `_Accum' on the 26899 target machine. If you don't define this, the default is 26900 `BITS_PER_UNIT * 4'. 26901 26902 -- Macro: LONG_ACCUM_TYPE_SIZE 26903 A C expression for the size in bits of the type `long _Accum' on 26904 the target machine. If you don't define this, the default is 26905 `BITS_PER_UNIT * 8'. 26906 26907 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 26908 A C expression for the size in bits of the type `long long _Accum' 26909 on the target machine. If you don't define this, the default is 26910 `BITS_PER_UNIT * 16'. 26911 26912 -- Macro: LIBGCC2_LONG_DOUBLE_TYPE_SIZE 26913 Define this macro if `LONG_DOUBLE_TYPE_SIZE' is not constant or if 26914 you want routines in `libgcc2.a' for a size other than 26915 `LONG_DOUBLE_TYPE_SIZE'. If you don't define this, the default is 26916 `LONG_DOUBLE_TYPE_SIZE'. 26917 26918 -- Macro: LIBGCC2_HAS_DF_MODE 26919 Define this macro if neither `DOUBLE_TYPE_SIZE' nor 26920 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is `DFmode' but you want `DFmode' 26921 routines in `libgcc2.a' anyway. If you don't define this and 26922 either `DOUBLE_TYPE_SIZE' or `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64 26923 then the default is 1, otherwise it is 0. 26924 26925 -- Macro: LIBGCC2_HAS_XF_MODE 26926 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not 26927 `XFmode' but you want `XFmode' routines in `libgcc2.a' anyway. If 26928 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 80 26929 then the default is 1, otherwise it is 0. 26930 26931 -- Macro: LIBGCC2_HAS_TF_MODE 26932 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not 26933 `TFmode' but you want `TFmode' routines in `libgcc2.a' anyway. If 26934 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 128 26935 then the default is 1, otherwise it is 0. 26936 26937 -- Macro: SF_SIZE 26938 -- Macro: DF_SIZE 26939 -- Macro: XF_SIZE 26940 -- Macro: TF_SIZE 26941 Define these macros to be the size in bits of the mantissa of 26942 `SFmode', `DFmode', `XFmode' and `TFmode' values, if the defaults 26943 in `libgcc2.h' are inappropriate. By default, `FLT_MANT_DIG' is 26944 used for `SF_SIZE', `LDBL_MANT_DIG' for `XF_SIZE' and `TF_SIZE', 26945 and `DBL_MANT_DIG' or `LDBL_MANT_DIG' for `DF_SIZE' according to 26946 whether `DOUBLE_TYPE_SIZE' or `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 26947 64. 26948 26949 -- Macro: TARGET_FLT_EVAL_METHOD 26950 A C expression for the value for `FLT_EVAL_METHOD' in `float.h', 26951 assuming, if applicable, that the floating-point control word is 26952 in its default state. If you do not define this macro the value of 26953 `FLT_EVAL_METHOD' will be zero. 26954 26955 -- Macro: WIDEST_HARDWARE_FP_SIZE 26956 A C expression for the size in bits of the widest floating-point 26957 format supported by the hardware. If you define this macro, you 26958 must specify a value less than or equal to the value of 26959 `LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 26960 value of `LONG_DOUBLE_TYPE_SIZE' is the default. 26961 26962 -- Macro: DEFAULT_SIGNED_CHAR 26963 An expression whose value is 1 or 0, according to whether the type 26964 `char' should be signed or unsigned by default. The user can 26965 always override this default with the options `-fsigned-char' and 26966 `-funsigned-char'. 26967 26968 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 26969 This target hook should return true if the compiler should give an 26970 `enum' type only as many bytes as it takes to represent the range 26971 of possible values of that type. It should return false if all 26972 `enum' types should be allocated like `int'. 26973 26974 The default is to return false. 26975 26976 -- Macro: SIZE_TYPE 26977 A C expression for a string describing the name of the data type 26978 to use for size values. The typedef name `size_t' is defined 26979 using the contents of the string. 26980 26981 The string can contain more than one keyword. If so, separate 26982 them with spaces, and write first any length keyword, then 26983 `unsigned' if appropriate, and finally `int'. The string must 26984 exactly match one of the data type names defined in the function 26985 `init_decl_processing' in the file `c-decl.c'. You may not omit 26986 `int' or change the order--that would cause the compiler to crash 26987 on startup. 26988 26989 If you don't define this macro, the default is `"long unsigned 26990 int"'. 26991 26992 -- Macro: PTRDIFF_TYPE 26993 A C expression for a string describing the name of the data type 26994 to use for the result of subtracting two pointers. The typedef 26995 name `ptrdiff_t' is defined using the contents of the string. See 26996 `SIZE_TYPE' above for more information. 26997 26998 If you don't define this macro, the default is `"long int"'. 26999 27000 -- Macro: WCHAR_TYPE 27001 A C expression for a string describing the name of the data type 27002 to use for wide characters. The typedef name `wchar_t' is defined 27003 using the contents of the string. See `SIZE_TYPE' above for more 27004 information. 27005 27006 If you don't define this macro, the default is `"int"'. 27007 27008 -- Macro: WCHAR_TYPE_SIZE 27009 A C expression for the size in bits of the data type for wide 27010 characters. This is used in `cpp', which cannot make use of 27011 `WCHAR_TYPE'. 27012 27013 -- Macro: WINT_TYPE 27014 A C expression for a string describing the name of the data type to 27015 use for wide characters passed to `printf' and returned from 27016 `getwc'. The typedef name `wint_t' is defined using the contents 27017 of the string. See `SIZE_TYPE' above for more information. 27018 27019 If you don't define this macro, the default is `"unsigned int"'. 27020 27021 -- Macro: INTMAX_TYPE 27022 A C expression for a string describing the name of the data type 27023 that can represent any value of any standard or extended signed 27024 integer type. The typedef name `intmax_t' is defined using the 27025 contents of the string. See `SIZE_TYPE' above for more 27026 information. 27027 27028 If you don't define this macro, the default is the first of 27029 `"int"', `"long int"', or `"long long int"' that has as much 27030 precision as `long long int'. 27031 27032 -- Macro: UINTMAX_TYPE 27033 A C expression for a string describing the name of the data type 27034 that can represent any value of any standard or extended unsigned 27035 integer type. The typedef name `uintmax_t' is defined using the 27036 contents of the string. See `SIZE_TYPE' above for more 27037 information. 27038 27039 If you don't define this macro, the default is the first of 27040 `"unsigned int"', `"long unsigned int"', or `"long long unsigned 27041 int"' that has as much precision as `long long unsigned int'. 27042 27043 -- Macro: SIG_ATOMIC_TYPE 27044 -- Macro: INT8_TYPE 27045 -- Macro: INT16_TYPE 27046 -- Macro: INT32_TYPE 27047 -- Macro: INT64_TYPE 27048 -- Macro: UINT8_TYPE 27049 -- Macro: UINT16_TYPE 27050 -- Macro: UINT32_TYPE 27051 -- Macro: UINT64_TYPE 27052 -- Macro: INT_LEAST8_TYPE 27053 -- Macro: INT_LEAST16_TYPE 27054 -- Macro: INT_LEAST32_TYPE 27055 -- Macro: INT_LEAST64_TYPE 27056 -- Macro: UINT_LEAST8_TYPE 27057 -- Macro: UINT_LEAST16_TYPE 27058 -- Macro: UINT_LEAST32_TYPE 27059 -- Macro: UINT_LEAST64_TYPE 27060 -- Macro: INT_FAST8_TYPE 27061 -- Macro: INT_FAST16_TYPE 27062 -- Macro: INT_FAST32_TYPE 27063 -- Macro: INT_FAST64_TYPE 27064 -- Macro: UINT_FAST8_TYPE 27065 -- Macro: UINT_FAST16_TYPE 27066 -- Macro: UINT_FAST32_TYPE 27067 -- Macro: UINT_FAST64_TYPE 27068 -- Macro: INTPTR_TYPE 27069 -- Macro: UINTPTR_TYPE 27070 C expressions for the standard types `sig_atomic_t', `int8_t', 27071 `int16_t', `int32_t', `int64_t', `uint8_t', `uint16_t', 27072 `uint32_t', `uint64_t', `int_least8_t', `int_least16_t', 27073 `int_least32_t', `int_least64_t', `uint_least8_t', 27074 `uint_least16_t', `uint_least32_t', `uint_least64_t', 27075 `int_fast8_t', `int_fast16_t', `int_fast32_t', `int_fast64_t', 27076 `uint_fast8_t', `uint_fast16_t', `uint_fast32_t', `uint_fast64_t', 27077 `intptr_t', and `uintptr_t'. See `SIZE_TYPE' above for more 27078 information. 27079 27080 If any of these macros evaluates to a null pointer, the 27081 corresponding type is not supported; if GCC is configured to 27082 provide `<stdint.h>' in such a case, the header provided may not 27083 conform to C99, depending on the type in question. The defaults 27084 for all of these macros are null pointers. 27085 27086 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 27087 The C++ compiler represents a pointer-to-member-function with a 27088 struct that looks like: 27089 27090 struct { 27091 union { 27092 void (*fn)(); 27093 ptrdiff_t vtable_index; 27094 }; 27095 ptrdiff_t delta; 27096 }; 27097 27098 The C++ compiler must use one bit to indicate whether the function 27099 that will be called through a pointer-to-member-function is 27100 virtual. Normally, we assume that the low-order bit of a function 27101 pointer must always be zero. Then, by ensuring that the 27102 vtable_index is odd, we can distinguish which variant of the union 27103 is in use. But, on some platforms function pointers can be odd, 27104 and so this doesn't work. In that case, we use the low-order bit 27105 of the `delta' field, and shift the remainder of the `delta' field 27106 to the left. 27107 27108 GCC will automatically make the right selection about where to 27109 store this bit using the `FUNCTION_BOUNDARY' setting for your 27110 platform. However, some platforms such as ARM/Thumb have 27111 `FUNCTION_BOUNDARY' set such that functions always start at even 27112 addresses, but the lowest bit of pointers to functions indicate 27113 whether the function at that address is in ARM or Thumb mode. If 27114 this is the case of your architecture, you should define this 27115 macro to `ptrmemfunc_vbit_in_delta'. 27116 27117 In general, you should not have to define this macro. On 27118 architectures in which function addresses are always even, 27119 according to `FUNCTION_BOUNDARY', GCC will automatically define 27120 this macro to `ptrmemfunc_vbit_in_pfn'. 27121 27122 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 27123 Normally, the C++ compiler uses function pointers in vtables. This 27124 macro allows the target to change to use "function descriptors" 27125 instead. Function descriptors are found on targets for whom a 27126 function pointer is actually a small data structure. Normally the 27127 data structure consists of the actual code address plus a data 27128 pointer to which the function's data is relative. 27129 27130 If vtables are used, the value of this macro should be the number 27131 of words that the function descriptor occupies. 27132 27133 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 27134 By default, the vtable entries are void pointers, the so the 27135 alignment is the same as pointer alignment. The value of this 27136 macro specifies the alignment of the vtable entry in bits. It 27137 should be defined only when special alignment is necessary. */ 27138 27139 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 27140 There are a few non-descriptor entries in the vtable at offsets 27141 below zero. If these entries must be padded (say, to preserve the 27142 alignment specified by `TARGET_VTABLE_ENTRY_ALIGN'), set this to 27143 the number of words in each data entry. 27144 27145 27146 File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 27147 27148 17.7 Register Usage 27149 =================== 27150 27151 This section explains how to describe what registers the target machine 27152 has, and how (in general) they can be used. 27153 27154 The description of which registers a specific instruction can use is 27155 done with register classes; see *note Register Classes::. For 27156 information on using registers to access a stack frame, see *note Frame 27157 Registers::. For passing values in registers, see *note Register 27158 Arguments::. For returning values in registers, see *note Scalar 27159 Return::. 27160 27161 * Menu: 27162 27163 * Register Basics:: Number and kinds of registers. 27164 * Allocation Order:: Order in which registers are allocated. 27165 * Values in Registers:: What kinds of values each reg can hold. 27166 * Leaf Functions:: Renumbering registers for leaf functions. 27167 * Stack Registers:: Handling a register stack such as 80387. 27168 27169 27170 File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 27171 27172 17.7.1 Basic Characteristics of Registers 27173 ----------------------------------------- 27174 27175 Registers have various characteristics. 27176 27177 -- Macro: FIRST_PSEUDO_REGISTER 27178 Number of hardware registers known to the compiler. They receive 27179 numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first 27180 pseudo register's number really is assigned the number 27181 `FIRST_PSEUDO_REGISTER'. 27182 27183 -- Macro: FIXED_REGISTERS 27184 An initializer that says which registers are used for fixed 27185 purposes all throughout the compiled code and are therefore not 27186 available for general allocation. These would include the stack 27187 pointer, the frame pointer (except on machines where that can be 27188 used as a general register when no frame pointer is needed), the 27189 program counter on machines where that is considered one of the 27190 addressable registers, and any other numbered register with a 27191 standard use. 27192 27193 This information is expressed as a sequence of numbers, separated 27194 by commas and surrounded by braces. The Nth number is 1 if 27195 register N is fixed, 0 otherwise. 27196 27197 The table initialized from this macro, and the table initialized by 27198 the following one, may be overridden at run time either 27199 automatically, by the actions of the macro 27200 `CONDITIONAL_REGISTER_USAGE', or by the user with the command 27201 options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'. 27202 27203 -- Macro: CALL_USED_REGISTERS 27204 Like `FIXED_REGISTERS' but has 1 for each register that is 27205 clobbered (in general) by function calls as well as for fixed 27206 registers. This macro therefore identifies the registers that are 27207 not available for general allocation of values that must live 27208 across function calls. 27209 27210 If a register has 0 in `CALL_USED_REGISTERS', the compiler 27211 automatically saves it on function entry and restores it on 27212 function exit, if the register is used within the function. 27213 27214 -- Macro: CALL_REALLY_USED_REGISTERS 27215 Like `CALL_USED_REGISTERS' except this macro doesn't require that 27216 the entire set of `FIXED_REGISTERS' be included. 27217 (`CALL_USED_REGISTERS' must be a superset of `FIXED_REGISTERS'). 27218 This macro is optional. If not specified, it defaults to the value 27219 of `CALL_USED_REGISTERS'. 27220 27221 -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE) 27222 A C expression that is nonzero if it is not permissible to store a 27223 value of mode MODE in hard register number REGNO across a call 27224 without some part of it being clobbered. For most machines this 27225 macro need not be defined. It is only required for machines that 27226 do not preserve the entire contents of a register across a call. 27227 27228 -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void) 27229 This hook may conditionally modify five variables `fixed_regs', 27230 `call_used_regs', `global_regs', `reg_names', and 27231 `reg_class_contents', to take into account any dependence of these 27232 register sets on target flags. The first three of these are of 27233 type `char []' (interpreted as Boolean vectors). `global_regs' is 27234 a `const char *[]', and `reg_class_contents' is a `HARD_REG_SET'. 27235 Before the macro is called, `fixed_regs', `call_used_regs', 27236 `reg_class_contents', and `reg_names' have been initialized from 27237 `FIXED_REGISTERS', `CALL_USED_REGISTERS', `REG_CLASS_CONTENTS', 27238 and `REGISTER_NAMES', respectively. `global_regs' has been 27239 cleared, and any `-ffixed-REG', `-fcall-used-REG' and 27240 `-fcall-saved-REG' command options have been applied. 27241 27242 If the usage of an entire class of registers depends on the target 27243 flags, you may indicate this to GCC by using this macro to modify 27244 `fixed_regs' and `call_used_regs' to 1 for each of the registers 27245 in the classes which should not be used by GCC. Also define the 27246 macro `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' to 27247 return `NO_REGS' if it is called with a letter for a class that 27248 shouldn't be used. 27249 27250 (However, if this class is not included in `GENERAL_REGS' and all 27251 of the insn patterns whose constraints permit this class are 27252 controlled by target switches, then GCC will automatically avoid 27253 using these registers when the target switches are opposed to 27254 them.) 27255 27256 -- Macro: INCOMING_REGNO (OUT) 27257 Define this macro if the target machine has register windows. 27258 This C expression returns the register number as seen by the 27259 called function corresponding to the register number OUT as seen 27260 by the calling function. Return OUT if register number OUT is not 27261 an outbound register. 27262 27263 -- Macro: OUTGOING_REGNO (IN) 27264 Define this macro if the target machine has register windows. 27265 This C expression returns the register number as seen by the 27266 calling function corresponding to the register number IN as seen 27267 by the called function. Return IN if register number IN is not an 27268 inbound register. 27269 27270 -- Macro: LOCAL_REGNO (REGNO) 27271 Define this macro if the target machine has register windows. 27272 This C expression returns true if the register is call-saved but 27273 is in the register window. Unlike most call-saved registers, such 27274 registers need not be explicitly restored on function exit or 27275 during non-local gotos. 27276 27277 -- Macro: PC_REGNUM 27278 If the program counter has a register number, define this as that 27279 register number. Otherwise, do not define it. 27280 27281 27282 File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 27283 27284 17.7.2 Order of Allocation of Registers 27285 --------------------------------------- 27286 27287 Registers are allocated in order. 27288 27289 -- Macro: REG_ALLOC_ORDER 27290 If defined, an initializer for a vector of integers, containing the 27291 numbers of hard registers in the order in which GCC should prefer 27292 to use them (from most preferred to least). 27293 27294 If this macro is not defined, registers are used lowest numbered 27295 first (all else being equal). 27296 27297 One use of this macro is on machines where the highest numbered 27298 registers must always be saved and the save-multiple-registers 27299 instruction supports only sequences of consecutive registers. On 27300 such machines, define `REG_ALLOC_ORDER' to be an initializer that 27301 lists the highest numbered allocable register first. 27302 27303 -- Macro: ADJUST_REG_ALLOC_ORDER 27304 A C statement (sans semicolon) to choose the order in which to 27305 allocate hard registers for pseudo-registers local to a basic 27306 block. 27307 27308 Store the desired register order in the array `reg_alloc_order'. 27309 Element 0 should be the register to allocate first; element 1, the 27310 next register; and so on. 27311 27312 The macro body should not assume anything about the contents of 27313 `reg_alloc_order' before execution of the macro. 27314 27315 On most machines, it is not necessary to define this macro. 27316 27317 -- Macro: HONOR_REG_ALLOC_ORDER 27318 Normally, IRA tries to estimate the costs for saving a register in 27319 the prologue and restoring it in the epilogue. This discourages 27320 it from using call-saved registers. If a machine wants to ensure 27321 that IRA allocates registers in the order given by REG_ALLOC_ORDER 27322 even if some call-saved registers appear earlier than call-used 27323 ones, this macro should be defined. 27324 27325 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 27326 In some case register allocation order is not enough for the 27327 Integrated Register Allocator (IRA) to generate a good code. If 27328 this macro is defined, it should return a floating point value 27329 based on REGNO. The cost of using REGNO for a pseudo will be 27330 increased by approximately the pseudo's usage frequency times the 27331 value returned by this macro. Not defining this macro is 27332 equivalent to having it always return `0.0'. 27333 27334 On most machines, it is not necessary to define this macro. 27335 27336 27337 File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 27338 27339 17.7.3 How Values Fit in Registers 27340 ---------------------------------- 27341 27342 This section discusses the macros that describe which kinds of values 27343 (specifically, which machine modes) each register can hold, and how many 27344 consecutive registers are needed for a given mode. 27345 27346 -- Macro: HARD_REGNO_NREGS (REGNO, MODE) 27347 A C expression for the number of consecutive hard registers, 27348 starting at register number REGNO, required to hold a value of mode 27349 MODE. This macro must never return zero, even if a register 27350 cannot hold the requested mode - indicate that with 27351 HARD_REGNO_MODE_OK and/or CANNOT_CHANGE_MODE_CLASS instead. 27352 27353 On a machine where all registers are exactly one word, a suitable 27354 definition of this macro is 27355 27356 #define HARD_REGNO_NREGS(REGNO, MODE) \ 27357 ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ 27358 / UNITS_PER_WORD) 27359 27360 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 27361 A C expression that is nonzero if a value of mode MODE, stored in 27362 memory, ends with padding that causes it to take up more space than 27363 in registers starting at register number REGNO (as determined by 27364 multiplying GCC's notion of the size of the register when 27365 containing this mode by the number of registers returned by 27366 `HARD_REGNO_NREGS'). By default this is zero. 27367 27368 For example, if a floating-point value is stored in three 32-bit 27369 registers but takes up 128 bits in memory, then this would be 27370 nonzero. 27371 27372 This macros only needs to be defined if there are cases where 27373 `subreg_get_info' would otherwise wrongly determine that a 27374 `subreg' can be represented by an offset to the register number, 27375 when in fact such a `subreg' would contain some of the padding not 27376 stored in registers and so not be representable. 27377 27378 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 27379 For values of REGNO and MODE for which 27380 `HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 27381 returning the greater number of registers required to hold the 27382 value including any padding. In the example above, the value 27383 would be four. 27384 27385 -- Macro: REGMODE_NATURAL_SIZE (MODE) 27386 Define this macro if the natural size of registers that hold values 27387 of mode MODE is not the word size. It is a C expression that 27388 should give the natural size in bytes for the specified mode. It 27389 is used by the register allocator to try to optimize its results. 27390 This happens for example on SPARC 64-bit where the natural size of 27391 floating-point registers is still 32-bit. 27392 27393 -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE) 27394 A C expression that is nonzero if it is permissible to store a 27395 value of mode MODE in hard register number REGNO (or in several 27396 registers starting with that one). For a machine where all 27397 registers are equivalent, a suitable definition is 27398 27399 #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 27400 27401 You need not include code to check for the numbers of fixed 27402 registers, because the allocation mechanism considers them to be 27403 always occupied. 27404 27405 On some machines, double-precision values must be kept in even/odd 27406 register pairs. You can implement that by defining this macro to 27407 reject odd register numbers for such modes. 27408 27409 The minimum requirement for a mode to be OK in a register is that 27410 the `movMODE' instruction pattern support moves between the 27411 register and other hard register in the same class and that moving 27412 a value into the register and back out not alter it. 27413 27414 Since the same instruction used to move `word_mode' will work for 27415 all narrower integer modes, it is not necessary on any machine for 27416 `HARD_REGNO_MODE_OK' to distinguish between these modes, provided 27417 you define patterns `movhi', etc., to take advantage of this. This 27418 is useful because of the interaction between `HARD_REGNO_MODE_OK' 27419 and `MODES_TIEABLE_P'; it is very desirable for all integer modes 27420 to be tieable. 27421 27422 Many machines have special registers for floating point arithmetic. 27423 Often people assume that floating point machine modes are allowed 27424 only in floating point registers. This is not true. Any 27425 registers that can hold integers can safely _hold_ a floating 27426 point machine mode, whether or not floating arithmetic can be done 27427 on it in those registers. Integer move instructions can be used 27428 to move the values. 27429 27430 On some machines, though, the converse is true: fixed-point machine 27431 modes may not go in floating registers. This is true if the 27432 floating registers normalize any value stored in them, because 27433 storing a non-floating value there would garble it. In this case, 27434 `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in 27435 floating registers. But if the floating registers do not 27436 automatically normalize, if you can store any bit pattern in one 27437 and retrieve it unchanged without a trap, then any machine mode 27438 may go in a floating register, so you can define this macro to say 27439 so. 27440 27441 The primary significance of special floating registers is rather 27442 that they are the registers acceptable in floating point arithmetic 27443 instructions. However, this is of no concern to 27444 `HARD_REGNO_MODE_OK'. You handle it by writing the proper 27445 constraints for those instructions. 27446 27447 On some machines, the floating registers are especially slow to 27448 access, so that it is better to store a value in a stack frame 27449 than in such a register if floating point arithmetic is not being 27450 done. As long as the floating registers are not in class 27451 `GENERAL_REGS', they will not be used unless some pattern's 27452 constraint asks for one. 27453 27454 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 27455 A C expression that is nonzero if it is OK to rename a hard 27456 register FROM to another hard register TO. 27457 27458 One common use of this macro is to prevent renaming of a register 27459 to another register that is not saved by a prologue in an interrupt 27460 handler. 27461 27462 The default is always nonzero. 27463 27464 -- Macro: MODES_TIEABLE_P (MODE1, MODE2) 27465 A C expression that is nonzero if a value of mode MODE1 is 27466 accessible in mode MODE2 without copying. 27467 27468 If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, 27469 MODE2)' are always the same for any R, then `MODES_TIEABLE_P 27470 (MODE1, MODE2)' should be nonzero. If they differ for any R, you 27471 should define this macro to return zero unless some other 27472 mechanism ensures the accessibility of the value in a narrower 27473 mode. 27474 27475 You should define this macro to return nonzero in as many cases as 27476 possible since doing so will allow GCC to perform better register 27477 allocation. 27478 27479 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 27480 This target hook should return `true' if it is OK to use a hard 27481 register REGNO as scratch reg in peephole2. 27482 27483 One common use of this macro is to prevent using of a register that 27484 is not saved by a prologue in an interrupt handler. 27485 27486 The default version of this hook always returns `true'. 27487 27488 -- Macro: AVOID_CCMODE_COPIES 27489 Define this macro if the compiler should avoid copies to/from 27490 `CCmode' registers. You should only define this macro if support 27491 for copying to/from `CCmode' is incomplete. 27492 27493 27494 File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 27495 27496 17.7.4 Handling Leaf Functions 27497 ------------------------------ 27498 27499 On some machines, a leaf function (i.e., one which makes no calls) can 27500 run more efficiently if it does not make its own register window. 27501 Often this means it is required to receive its arguments in the 27502 registers where they are passed by the caller, instead of the registers 27503 where they would normally arrive. 27504 27505 The special treatment for leaf functions generally applies only when 27506 other conditions are met; for example, often they may use only those 27507 registers for its own variables and temporaries. We use the term "leaf 27508 function" to mean a function that is suitable for this special 27509 handling, so that functions with no calls are not necessarily "leaf 27510 functions". 27511 27512 GCC assigns register numbers before it knows whether the function is 27513 suitable for leaf function treatment. So it needs to renumber the 27514 registers in order to output a leaf function. The following macros 27515 accomplish this. 27516 27517 -- Macro: LEAF_REGISTERS 27518 Name of a char vector, indexed by hard register number, which 27519 contains 1 for a register that is allowable in a candidate for leaf 27520 function treatment. 27521 27522 If leaf function treatment involves renumbering the registers, 27523 then the registers marked here should be the ones before 27524 renumbering--those that GCC would ordinarily allocate. The 27525 registers which will actually be used in the assembler code, after 27526 renumbering, should not be marked with 1 in this vector. 27527 27528 Define this macro only if the target machine offers a way to 27529 optimize the treatment of leaf functions. 27530 27531 -- Macro: LEAF_REG_REMAP (REGNO) 27532 A C expression whose value is the register number to which REGNO 27533 should be renumbered, when a function is treated as a leaf 27534 function. 27535 27536 If REGNO is a register number which should not appear in a leaf 27537 function before renumbering, then the expression should yield -1, 27538 which will cause the compiler to abort. 27539 27540 Define this macro only if the target machine offers a way to 27541 optimize the treatment of leaf functions, and registers need to be 27542 renumbered to do this. 27543 27544 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' must 27545 usually treat leaf functions specially. They can test the C variable 27546 `current_function_is_leaf' which is nonzero for leaf functions. 27547 `current_function_is_leaf' is set prior to local register allocation 27548 and is valid for the remaining compiler passes. They can also test the 27549 C variable `current_function_uses_only_leaf_regs' which is nonzero for 27550 leaf functions which only use leaf registers. 27551 `current_function_uses_only_leaf_regs' is valid after all passes that 27552 modify the instructions have been run and is only useful if 27553 `LEAF_REGISTERS' is defined. 27554 27555 27556 File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 27557 27558 17.7.5 Registers That Form a Stack 27559 ---------------------------------- 27560 27561 There are special features to handle computers where some of the 27562 "registers" form a stack. Stack registers are normally written by 27563 pushing onto the stack, and are numbered relative to the top of the 27564 stack. 27565 27566 Currently, GCC can only handle one group of stack-like registers, and 27567 they must be consecutively numbered. Furthermore, the existing support 27568 for stack-like registers is specific to the 80387 floating point 27569 coprocessor. If you have a new architecture that uses stack-like 27570 registers, you will need to do substantial work on `reg-stack.c' and 27571 write your machine description to cooperate with it, as well as 27572 defining these macros. 27573 27574 -- Macro: STACK_REGS 27575 Define this if the machine has any stack-like registers. 27576 27577 -- Macro: STACK_REG_COVER_CLASS 27578 This is a cover class containing the stack registers. Define this 27579 if the machine has any stack-like registers. 27580 27581 -- Macro: FIRST_STACK_REG 27582 The number of the first stack-like register. This one is the top 27583 of the stack. 27584 27585 -- Macro: LAST_STACK_REG 27586 The number of the last stack-like register. This one is the 27587 bottom of the stack. 27588 27589 27590 File: gccint.info, Node: Register Classes, Next: Old Constraints, Prev: Registers, Up: Target Macros 27591 27592 17.8 Register Classes 27593 ===================== 27594 27595 On many machines, the numbered registers are not all equivalent. For 27596 example, certain registers may not be allowed for indexed addressing; 27597 certain registers may not be allowed in some instructions. These 27598 machine restrictions are described to the compiler using "register 27599 classes". 27600 27601 You define a number of register classes, giving each one a name and 27602 saying which of the registers belong to it. Then you can specify 27603 register classes that are allowed as operands to particular instruction 27604 patterns. 27605 27606 In general, each register will belong to several classes. In fact, one 27607 class must be named `ALL_REGS' and contain all the registers. Another 27608 class must be named `NO_REGS' and contain no registers. Often the 27609 union of two classes will be another class; however, this is not 27610 required. 27611 27612 One of the classes must be named `GENERAL_REGS'. There is nothing 27613 terribly special about the name, but the operand constraint letters `r' 27614 and `g' specify this class. If `GENERAL_REGS' is the same as 27615 `ALL_REGS', just define it as a macro which expands to `ALL_REGS'. 27616 27617 Order the classes so that if class X is contained in class Y then X 27618 has a lower class number than Y. 27619 27620 The way classes other than `GENERAL_REGS' are specified in operand 27621 constraints is through machine-dependent operand constraint letters. 27622 You can define such letters to correspond to various classes, then use 27623 them in operand constraints. 27624 27625 You should define a class for the union of two classes whenever some 27626 instruction allows both classes. For example, if an instruction allows 27627 either a floating point (coprocessor) register or a general register 27628 for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' 27629 which includes both of them. Otherwise you will get suboptimal code, 27630 or even internal compiler errors when reload cannot find a register in 27631 the the class computed via `reg_class_subunion'. 27632 27633 You must also specify certain redundant information about the register 27634 classes: for each class, which classes contain it and which ones are 27635 contained in it; for each pair of classes, the largest class contained 27636 in their union. 27637 27638 When a value occupying several consecutive registers is expected in a 27639 certain class, all the registers used must belong to that class. 27640 Therefore, register classes cannot be used to enforce a requirement for 27641 a register pair to start with an even-numbered register. The way to 27642 specify this requirement is with `HARD_REGNO_MODE_OK'. 27643 27644 Register classes used for input-operands of bitwise-and or shift 27645 instructions have a special requirement: each such class must have, for 27646 each fixed-point machine mode, a subclass whose registers can transfer 27647 that mode to or from memory. For example, on some machines, the 27648 operations for single-byte values (`QImode') are limited to certain 27649 registers. When this is so, each register class that is used in a 27650 bitwise-and or shift instruction must have a subclass consisting of 27651 registers from which single-byte values can be loaded or stored. This 27652 is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to 27653 return. 27654 27655 -- Data type: enum reg_class 27656 An enumerated type that must be defined with all the register 27657 class names as enumerated values. `NO_REGS' must be first. 27658 `ALL_REGS' must be the last register class, followed by one more 27659 enumerated value, `LIM_REG_CLASSES', which is not a register class 27660 but rather tells how many classes there are. 27661 27662 Each register class has a number, which is the value of casting 27663 the class name to type `int'. The number serves as an index in 27664 many of the tables described below. 27665 27666 -- Macro: N_REG_CLASSES 27667 The number of distinct register classes, defined as follows: 27668 27669 #define N_REG_CLASSES (int) LIM_REG_CLASSES 27670 27671 -- Macro: REG_CLASS_NAMES 27672 An initializer containing the names of the register classes as C 27673 string constants. These names are used in writing some of the 27674 debugging dumps. 27675 27676 -- Macro: REG_CLASS_CONTENTS 27677 An initializer containing the contents of the register classes, as 27678 integers which are bit masks. The Nth integer specifies the 27679 contents of class N. The way the integer MASK is interpreted is 27680 that register R is in the class if `MASK & (1 << R)' is 1. 27681 27682 When the machine has more than 32 registers, an integer does not 27683 suffice. Then the integers are replaced by sub-initializers, 27684 braced groupings containing several integers. Each 27685 sub-initializer must be suitable as an initializer for the type 27686 `HARD_REG_SET' which is defined in `hard-reg-set.h'. In this 27687 situation, the first integer in each sub-initializer corresponds to 27688 registers 0 through 31, the second integer to registers 32 through 27689 63, and so on. 27690 27691 -- Macro: REGNO_REG_CLASS (REGNO) 27692 A C expression whose value is a register class containing hard 27693 register REGNO. In general there is more than one such class; 27694 choose a class which is "minimal", meaning that no smaller class 27695 also contains the register. 27696 27697 -- Macro: BASE_REG_CLASS 27698 A macro whose definition is the name of the class to which a valid 27699 base register must belong. A base register is one used in an 27700 address which is the register value plus a displacement. 27701 27702 -- Macro: MODE_BASE_REG_CLASS (MODE) 27703 This is a variation of the `BASE_REG_CLASS' macro which allows the 27704 selection of a base register in a mode dependent manner. If MODE 27705 is VOIDmode then it should return the same value as 27706 `BASE_REG_CLASS'. 27707 27708 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 27709 A C expression whose value is the register class to which a valid 27710 base register must belong in order to be used in a base plus index 27711 register address. You should define this macro if base plus index 27712 addresses have different requirements than other base register 27713 uses. 27714 27715 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, OUTER_CODE, INDEX_CODE) 27716 A C expression whose value is the register class to which a valid 27717 base register must belong. OUTER_CODE and INDEX_CODE define the 27718 context in which the base register occurs. OUTER_CODE is the code 27719 of the immediately enclosing expression (`MEM' for the top level 27720 of an address, `ADDRESS' for something that occurs in an 27721 `address_operand'). INDEX_CODE is the code of the corresponding 27722 index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise. 27723 27724 -- Macro: INDEX_REG_CLASS 27725 A macro whose definition is the name of the class to which a valid 27726 index register must belong. An index register is one used in an 27727 address where its value is either multiplied by a scale factor or 27728 added to another register (as well as added to a displacement). 27729 27730 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 27731 A C expression which is nonzero if register number NUM is suitable 27732 for use as a base register in operand addresses. 27733 27734 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 27735 A C expression that is just like `REGNO_OK_FOR_BASE_P', except that 27736 that expression may examine the mode of the memory reference in 27737 MODE. You should define this macro if the mode of the memory 27738 reference affects whether a register may be used as a base 27739 register. If you define this macro, the compiler will use it 27740 instead of `REGNO_OK_FOR_BASE_P'. The mode may be `VOIDmode' for 27741 addresses that appear outside a `MEM', i.e., as an 27742 `address_operand'. 27743 27744 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 27745 A C expression which is nonzero if register number NUM is suitable 27746 for use as a base register in base plus index operand addresses, 27747 accessing memory in mode MODE. It may be either a suitable hard 27748 register or a pseudo register that has been allocated such a hard 27749 register. You should define this macro if base plus index 27750 addresses have different requirements than other base register 27751 uses. 27752 27753 Use of this macro is deprecated; please use the more general 27754 `REGNO_MODE_CODE_OK_FOR_BASE_P'. 27755 27756 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, OUTER_CODE, 27757 INDEX_CODE) 27758 A C expression that is just like `REGNO_MODE_OK_FOR_BASE_P', except 27759 that that expression may examine the context in which the register 27760 appears in the memory reference. OUTER_CODE is the code of the 27761 immediately enclosing expression (`MEM' if at the top level of the 27762 address, `ADDRESS' for something that occurs in an 27763 `address_operand'). INDEX_CODE is the code of the corresponding 27764 index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise. 27765 The mode may be `VOIDmode' for addresses that appear outside a 27766 `MEM', i.e., as an `address_operand'. 27767 27768 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 27769 A C expression which is nonzero if register number NUM is suitable 27770 for use as an index register in operand addresses. It may be 27771 either a suitable hard register or a pseudo register that has been 27772 allocated such a hard register. 27773 27774 The difference between an index register and a base register is 27775 that the index register may be scaled. If an address involves the 27776 sum of two registers, neither one of them scaled, then either one 27777 may be labeled the "base" and the other the "index"; but whichever 27778 labeling is used must fit the machine's constraints of which 27779 registers may serve in each capacity. The compiler will try both 27780 labelings, looking for one that is valid, and will reload one or 27781 both registers only if neither labeling works. 27782 27783 -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t 27784 RCLASS) 27785 A target hook that places additional preference on the register 27786 class to use when it is necessary to rename a register in class 27787 RCLASS to another class, or perhaps NO_REGS, if no preferred 27788 register class is found or hook `preferred_rename_class' is not 27789 implemented. Sometimes returning a more restrictive class makes 27790 better code. For example, on ARM, thumb-2 instructions using 27791 `LO_REGS' may be smaller than instructions using `GENERIC_REGS'. 27792 By returning `LO_REGS' from `preferred_rename_class', code size 27793 can be reduced. 27794 27795 -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X, 27796 reg_class_t RCLASS) 27797 A target hook that places additional restrictions on the register 27798 class to use when it is necessary to copy value X into a register 27799 in class RCLASS. The value is a register class; perhaps RCLASS, 27800 or perhaps another, smaller class. 27801 27802 The default version of this hook always returns value of `rclass' 27803 argument. 27804 27805 Sometimes returning a more restrictive class makes better code. 27806 For example, on the 68000, when X is an integer constant that is 27807 in range for a `moveq' instruction, the value of this macro is 27808 always `DATA_REGS' as long as RCLASS includes the data registers. 27809 Requiring a data register guarantees that a `moveq' will be used. 27810 27811 One case where `TARGET_PREFERRED_RELOAD_CLASS' must not return 27812 RCLASS is if X is a legitimate constant which cannot be loaded 27813 into some register class. By returning `NO_REGS' you can force X 27814 into a memory location. For example, rs6000 can load immediate 27815 values into general-purpose registers, but does not have an 27816 instruction for loading an immediate value into a floating-point 27817 register, so `TARGET_PREFERRED_RELOAD_CLASS' returns `NO_REGS' when 27818 X is a floating-point constant. If the constant can't be loaded 27819 into any kind of register, code generation will be better if 27820 `LEGITIMATE_CONSTANT_P' makes the constant illegitimate instead of 27821 using `TARGET_PREFERRED_RELOAD_CLASS'. 27822 27823 If an insn has pseudos in it after register allocation, reload 27824 will go through the alternatives and call repeatedly 27825 `TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning 27826 `NO_REGS', in this case, makes reload add a `!' in front of the 27827 constraint: the x86 back-end uses this feature to discourage usage 27828 of 387 registers when math is done in the SSE registers (and vice 27829 versa). 27830 27831 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 27832 A C expression that places additional restrictions on the register 27833 class to use when it is necessary to copy value X into a register 27834 in class CLASS. The value is a register class; perhaps CLASS, or 27835 perhaps another, smaller class. On many machines, the following 27836 definition is safe: 27837 27838 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 27839 27840 Sometimes returning a more restrictive class makes better code. 27841 For example, on the 68000, when X is an integer constant that is 27842 in range for a `moveq' instruction, the value of this macro is 27843 always `DATA_REGS' as long as CLASS includes the data registers. 27844 Requiring a data register guarantees that a `moveq' will be used. 27845 27846 One case where `PREFERRED_RELOAD_CLASS' must not return CLASS is 27847 if X is a legitimate constant which cannot be loaded into some 27848 register class. By returning `NO_REGS' you can force X into a 27849 memory location. For example, rs6000 can load immediate values 27850 into general-purpose registers, but does not have an instruction 27851 for loading an immediate value into a floating-point register, so 27852 `PREFERRED_RELOAD_CLASS' returns `NO_REGS' when X is a 27853 floating-point constant. If the constant can't be loaded into any 27854 kind of register, code generation will be better if 27855 `LEGITIMATE_CONSTANT_P' makes the constant illegitimate instead of 27856 using `PREFERRED_RELOAD_CLASS'. 27857 27858 If an insn has pseudos in it after register allocation, reload 27859 will go through the alternatives and call repeatedly 27860 `PREFERRED_RELOAD_CLASS' to find the best one. Returning 27861 `NO_REGS', in this case, makes reload add a `!' in front of the 27862 constraint: the x86 back-end uses this feature to discourage usage 27863 of 387 registers when math is done in the SSE registers (and vice 27864 versa). 27865 27866 -- Macro: PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS) 27867 Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of 27868 input reloads. If you don't define this macro, the default is to 27869 use CLASS, unchanged. 27870 27871 You can also use `PREFERRED_OUTPUT_RELOAD_CLASS' to discourage 27872 reload from using some alternatives, like `PREFERRED_RELOAD_CLASS'. 27873 27874 -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx 27875 X, reg_class_t RCLASS) 27876 Like `TARGET_PREFERRED_RELOAD_CLASS', but for output reloads 27877 instead of input reloads. 27878 27879 The default version of this hook always returns value of `rclass' 27880 argument. 27881 27882 You can also use `TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to 27883 discourage reload from using some alternatives, like 27884 `TARGET_PREFERRED_RELOAD_CLASS'. 27885 27886 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 27887 A C expression that places additional restrictions on the register 27888 class to use when it is necessary to be able to hold a value of 27889 mode MODE in a reload register for which class CLASS would 27890 ordinarily be used. 27891 27892 Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when 27893 there are certain modes that simply can't go in certain reload 27894 classes. 27895 27896 The value is a register class; perhaps CLASS, or perhaps another, 27897 smaller class. 27898 27899 Don't define this macro unless the target machine has limitations 27900 which require the macro to do something nontrivial. 27901 27902 -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X, 27903 reg_class_t RELOAD_CLASS, enum machine_mode RELOAD_MODE, 27904 secondary_reload_info *SRI) 27905 Many machines have some registers that cannot be copied directly 27906 to or from memory or even from other types of registers. An 27907 example is the `MQ' register, which on most machines, can only be 27908 copied to or from general registers, but not memory. Below, we 27909 shall be using the term 'intermediate register' when a move 27910 operation cannot be performed directly, but has to be done by 27911 copying the source into the intermediate register first, and then 27912 copying the intermediate register to the destination. An 27913 intermediate register always has the same mode as source and 27914 destination. Since it holds the actual value being copied, reload 27915 might apply optimizations to re-use an intermediate register and 27916 eliding the copy from the source when it can determine that the 27917 intermediate register still holds the required value. 27918 27919 Another kind of secondary reload is required on some machines which 27920 allow copying all registers to and from memory, but require a 27921 scratch register for stores to some memory locations (e.g., those 27922 with symbolic address on the RT, and those with certain symbolic 27923 address on the SPARC when compiling PIC). Scratch registers need 27924 not have the same mode as the value being copied, and usually hold 27925 a different value than that being copied. Special patterns in the 27926 md file are needed to describe how the copy is performed with the 27927 help of the scratch register; these patterns also describe the 27928 number, register class(es) and mode(s) of the scratch register(s). 27929 27930 In some cases, both an intermediate and a scratch register are 27931 required. 27932 27933 For input reloads, this target hook is called with nonzero IN_P, 27934 and X is an rtx that needs to be copied to a register of class 27935 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 27936 is called with zero IN_P, and a register of class RELOAD_CLASS 27937 needs to be copied to rtx X in RELOAD_MODE. 27938 27939 If copying a register of RELOAD_CLASS from/to X requires an 27940 intermediate register, the hook `secondary_reload' should return 27941 the register class required for this intermediate register. If no 27942 intermediate register is required, it should return NO_REGS. If 27943 more than one intermediate register is required, describe the one 27944 that is closest in the copy chain to the reload register. 27945 27946 If scratch registers are needed, you also have to describe how to 27947 perform the copy from/to the reload register to/from this closest 27948 intermediate register. Or if no intermediate register is 27949 required, but still a scratch register is needed, describe the 27950 copy from/to the reload register to/from the reload operand X. 27951 27952 You do this by setting `sri->icode' to the instruction code of a 27953 pattern in the md file which performs the move. Operands 0 and 1 27954 are the output and input of this copy, respectively. Operands 27955 from operand 2 onward are for scratch operands. These scratch 27956 operands must have a mode, and a single-register-class output 27957 constraint. 27958 27959 When an intermediate register is used, the `secondary_reload' hook 27960 will be called again to determine how to copy the intermediate 27961 register to/from the reload operand X, so your hook must also have 27962 code to handle the register class of the intermediate operand. 27963 27964 X might be a pseudo-register or a `subreg' of a pseudo-register, 27965 which could either be in a hard register or in memory. Use 27966 `true_regnum' to find out; it will return -1 if the pseudo is in 27967 memory and the hard register number if it is in a register. 27968 27969 Scratch operands in memory (constraint `"=m"' / `"=&m"') are 27970 currently not supported. For the time being, you will have to 27971 continue to use `SECONDARY_MEMORY_NEEDED' for that purpose. 27972 27973 `copy_cost' also uses this target hook to find out how values are 27974 copied. If you want it to include some extra cost for the need to 27975 allocate (a) scratch register(s), set `sri->extra_cost' to the 27976 additional cost. Or if two dependent moves are supposed to have a 27977 lower cost than the sum of the individual moves due to expected 27978 fortuitous scheduling and/or special forwarding logic, you can set 27979 `sri->extra_cost' to a negative amount. 27980 27981 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 27982 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 27983 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 27984 These macros are obsolete, new ports should use the target hook 27985 `TARGET_SECONDARY_RELOAD' instead. 27986 27987 These are obsolete macros, replaced by the 27988 `TARGET_SECONDARY_RELOAD' target hook. Older ports still define 27989 these macros to indicate to the reload phase that it may need to 27990 allocate at least one register for a reload in addition to the 27991 register to contain the data. Specifically, if copying X to a 27992 register CLASS in MODE requires an intermediate register, you were 27993 supposed to define `SECONDARY_INPUT_RELOAD_CLASS' to return the 27994 largest register class all of whose registers can be used as 27995 intermediate registers or scratch registers. 27996 27997 If copying a register CLASS in MODE to X requires an intermediate 27998 or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 27999 to be defined be defined to return the largest register class 28000 required. If the requirements for input and output reloads were 28001 the same, the macro `SECONDARY_RELOAD_CLASS' should have been used 28002 instead of defining both macros identically. 28003 28004 The values returned by these macros are often `GENERAL_REGS'. 28005 Return `NO_REGS' if no spare register is needed; i.e., if X can be 28006 directly copied to or from a register of CLASS in MODE without 28007 requiring a scratch register. Do not define this macro if it 28008 would always return `NO_REGS'. 28009 28010 If a scratch register is required (either with or without an 28011 intermediate register), you were supposed to define patterns for 28012 `reload_inM' or `reload_outM', as required (*note Standard 28013 Names::. These patterns, which were normally implemented with a 28014 `define_expand', should be similar to the `movM' patterns, except 28015 that operand 2 is the scratch register. 28016 28017 These patterns need constraints for the reload register and scratch 28018 register that contain a single register class. If the original 28019 reload register (whose class is CLASS) can meet the constraint 28020 given in the pattern, the value returned by these macros is used 28021 for the class of the scratch register. Otherwise, two additional 28022 reload registers are required. Their classes are obtained from 28023 the constraints in the insn pattern. 28024 28025 X might be a pseudo-register or a `subreg' of a pseudo-register, 28026 which could either be in a hard register or in memory. Use 28027 `true_regnum' to find out; it will return -1 if the pseudo is in 28028 memory and the hard register number if it is in a register. 28029 28030 These macros should not be used in the case where a particular 28031 class of registers can only be copied to memory and not to another 28032 class of registers. In that case, secondary reload registers are 28033 not needed and would not be helpful. Instead, a stack location 28034 must be used to perform the copy and the `movM' pattern should use 28035 memory as an intermediate storage. This case often occurs between 28036 floating-point and general registers. 28037 28038 -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M) 28039 Certain machines have the property that some registers cannot be 28040 copied to some other registers without using memory. Define this 28041 macro on those machines to be a C expression that is nonzero if 28042 objects of mode M in registers of CLASS1 can only be copied to 28043 registers of class CLASS2 by storing a register of CLASS1 into 28044 memory and loading that memory location into a register of CLASS2. 28045 28046 Do not define this macro if its value would always be zero. 28047 28048 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 28049 Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler 28050 allocates a stack slot for a memory location needed for register 28051 copies. If this macro is defined, the compiler instead uses the 28052 memory location defined by this macro. 28053 28054 Do not define this macro if you do not define 28055 `SECONDARY_MEMORY_NEEDED'. 28056 28057 -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE) 28058 When the compiler needs a secondary memory location to copy 28059 between two registers of mode MODE, it normally allocates 28060 sufficient memory to hold a quantity of `BITS_PER_WORD' bits and 28061 performs the store and load operations in a mode that many bits 28062 wide and whose class is the same as that of MODE. 28063 28064 This is right thing to do on most machines because it ensures that 28065 all bits of the register are copied and prevents accesses to the 28066 registers in a narrower mode, which some machines prohibit for 28067 floating-point registers. 28068 28069 However, this default behavior is not correct on some machines, 28070 such as the DEC Alpha, that store short integers in floating-point 28071 registers differently than in integer registers. On those 28072 machines, the default widening will not work correctly and you 28073 must define this macro to suppress that widening in some cases. 28074 See the file `alpha.h' for details. 28075 28076 Do not define this macro if you do not define 28077 `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is 28078 `BITS_PER_WORD' bits wide is correct for your machine. 28079 28080 -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS) 28081 A target hook which returns `true' if pseudos that have been 28082 assigned to registers of class RCLASS would likely be spilled 28083 because registers of RCLASS are needed for spill registers. 28084 28085 The default version of this target hook returns `true' if RCLASS 28086 has exactly one register and `false' otherwise. On most machines, 28087 this default should be used. Only use this target hook to some 28088 other expression if pseudos allocated by `local-alloc.c' end up in 28089 memory because their hard registers were needed for spill 28090 registers. If this target hook returns `false' for those classes, 28091 those pseudos will only be allocated by `global.c', which knows 28092 how to reallocate the pseudo to another register. If there would 28093 not be another register available for reallocation, you should not 28094 change the implementation of this target hook since the only 28095 effect of such implementation would be to slow down register 28096 allocation. 28097 28098 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 28099 A C expression for the maximum number of consecutive registers of 28100 class CLASS needed to hold a value of mode MODE. 28101 28102 This is closely related to the macro `HARD_REGNO_NREGS'. In fact, 28103 the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be 28104 the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all 28105 REGNO values in the class CLASS. 28106 28107 This macro helps control the handling of multiple-word values in 28108 the reload pass. 28109 28110 -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS) 28111 If defined, a C expression that returns nonzero for a CLASS for 28112 which a change from mode FROM to mode TO is invalid. 28113 28114 For the example, loading 32-bit integer or floating-point objects 28115 into floating-point registers on the Alpha extends them to 64 bits. 28116 Therefore loading a 64-bit object and then storing it as a 32-bit 28117 object does not store the low-order 32 bits, as would be the case 28118 for a normal register. Therefore, `alpha.h' defines 28119 `CANNOT_CHANGE_MODE_CLASS' as below: 28120 28121 #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ 28122 (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ 28123 ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0) 28124 28125 -- Target Hook: const reg_class_t * TARGET_IRA_COVER_CLASSES (void) 28126 Return an array of cover classes for the Integrated Register 28127 Allocator (IRA). Cover classes are a set of non-intersecting 28128 register classes covering all hard registers used for register 28129 allocation purposes. If a move between two registers in the same 28130 cover class is possible, it should be cheaper than a load or store 28131 of the registers. The array is terminated by a `LIM_REG_CLASSES' 28132 element. 28133 28134 The order of cover classes in the array is important. If two 28135 classes have the same cost of usage for a pseudo, the class 28136 occurred first in the array is chosen for the pseudo. 28137 28138 This hook is called once at compiler startup, after the 28139 command-line options have been processed. It is then re-examined 28140 by every call to `target_reinit'. 28141 28142 The default implementation returns `IRA_COVER_CLASSES', if defined, 28143 otherwise there is no default implementation. You must define 28144 either this macro or `IRA_COVER_CLASSES' in order to use the 28145 integrated register allocator with Chaitin-Briggs coloring. If the 28146 macro is not defined, the only available coloring algorithm is 28147 Chow's priority coloring. 28148 28149 This hook must not be modified from `NULL' to non-`NULL' or vice 28150 versa by command-line option processing. 28151 28152 -- Macro: IRA_COVER_CLASSES 28153 See the documentation for `TARGET_IRA_COVER_CLASSES'. 28154 28155 28156 File: gccint.info, Node: Old Constraints, Next: Stack and Calling, Prev: Register Classes, Up: Target Macros 28157 28158 17.9 Obsolete Macros for Defining Constraints 28159 ============================================= 28160 28161 Machine-specific constraints can be defined with these macros instead 28162 of the machine description constructs described in *note Define 28163 Constraints::. This mechanism is obsolete. New ports should not use 28164 it; old ports should convert to the new mechanism. 28165 28166 -- Macro: CONSTRAINT_LEN (CHAR, STR) 28167 For the constraint at the start of STR, which starts with the 28168 letter C, return the length. This allows you to have register 28169 class / constant / extra constraints that are longer than a single 28170 letter; you don't need to define this macro if you can do with 28171 single-letter constraints only. The definition of this macro 28172 should use DEFAULT_CONSTRAINT_LEN for all the characters that you 28173 don't want to handle specially. There are some sanity checks in 28174 genoutput.c that check the constraint lengths for the md file, so 28175 you can also use this macro to help you while you are 28176 transitioning from a byzantine single-letter-constraint scheme: 28177 when you return a negative length for a constraint you want to 28178 re-use, genoutput will complain about every instance where it is 28179 used in the md file. 28180 28181 -- Macro: REG_CLASS_FROM_LETTER (CHAR) 28182 A C expression which defines the machine-dependent operand 28183 constraint letters for register classes. If CHAR is such a 28184 letter, the value should be the register class corresponding to 28185 it. Otherwise, the value should be `NO_REGS'. The register 28186 letter `r', corresponding to class `GENERAL_REGS', will not be 28187 passed to this macro; you do not need to handle it. 28188 28189 -- Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR) 28190 Like `REG_CLASS_FROM_LETTER', but you also get the constraint 28191 string passed in STR, so that you can use suffixes to distinguish 28192 between different variants. 28193 28194 -- Macro: CONST_OK_FOR_LETTER_P (VALUE, C) 28195 A C expression that defines the machine-dependent operand 28196 constraint letters (`I', `J', `K', ... `P') that specify 28197 particular ranges of integer values. If C is one of those 28198 letters, the expression should check that VALUE, an integer, is in 28199 the appropriate range and return 1 if so, 0 otherwise. If C is 28200 not one of those letters, the value should be 0 regardless of 28201 VALUE. 28202 28203 -- Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 28204 Like `CONST_OK_FOR_LETTER_P', but you also get the constraint 28205 string passed in STR, so that you can use suffixes to distinguish 28206 between different variants. 28207 28208 -- Macro: CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C) 28209 A C expression that defines the machine-dependent operand 28210 constraint letters that specify particular ranges of 28211 `const_double' values (`G' or `H'). 28212 28213 If C is one of those letters, the expression should check that 28214 VALUE, an RTX of code `const_double', is in the appropriate range 28215 and return 1 if so, 0 otherwise. If C is not one of those 28216 letters, the value should be 0 regardless of VALUE. 28217 28218 `const_double' is used for all floating-point constants and for 28219 `DImode' fixed-point constants. A given letter can accept either 28220 or both kinds of values. It can use `GET_MODE' to distinguish 28221 between these kinds. 28222 28223 -- Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 28224 Like `CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the 28225 constraint string passed in STR, so that you can use suffixes to 28226 distinguish between different variants. 28227 28228 -- Macro: EXTRA_CONSTRAINT (VALUE, C) 28229 A C expression that defines the optional machine-dependent 28230 constraint letters that can be used to segregate specific types of 28231 operands, usually memory references, for the target machine. Any 28232 letter that is not elsewhere defined and not matched by 28233 `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' may be used. 28234 Normally this macro will not be defined. 28235 28236 If it is required for a particular target machine, it should 28237 return 1 if VALUE corresponds to the operand type represented by 28238 the constraint letter C. If C is not defined as an extra 28239 constraint, the value returned should be 0 regardless of VALUE. 28240 28241 For example, on the ROMP, load instructions cannot have their 28242 output in r0 if the memory reference contains a symbolic address. 28243 Constraint letter `Q' is defined as representing a memory address 28244 that does _not_ contain a symbolic address. An alternative is 28245 specified with a `Q' constraint on the input and `r' on the 28246 output. The next alternative specifies `m' on the input and a 28247 register class that does not include r0 on the output. 28248 28249 -- Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR) 28250 Like `EXTRA_CONSTRAINT', but you also get the constraint string 28251 passed in STR, so that you can use suffixes to distinguish between 28252 different variants. 28253 28254 -- Macro: EXTRA_MEMORY_CONSTRAINT (C, STR) 28255 A C expression that defines the optional machine-dependent 28256 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT', 28257 that should be treated like memory constraints by the reload pass. 28258 28259 It should return 1 if the operand type represented by the 28260 constraint at the start of STR, the first letter of which is the 28261 letter C, comprises a subset of all memory references including 28262 all those whose address is simply a base register. This allows 28263 the reload pass to reload an operand, if it does not directly 28264 correspond to the operand type of C, by copying its address into a 28265 base register. 28266 28267 For example, on the S/390, some instructions do not accept 28268 arbitrary memory references, but only those that do not make use 28269 of an index register. The constraint letter `Q' is defined via 28270 `EXTRA_CONSTRAINT' as representing a memory address of this type. 28271 If the letter `Q' is marked as `EXTRA_MEMORY_CONSTRAINT', a `Q' 28272 constraint can handle any memory operand, because the reload pass 28273 knows it can be reloaded by copying the memory address into a base 28274 register if required. This is analogous to the way an `o' 28275 constraint can handle any memory operand. 28276 28277 -- Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR) 28278 A C expression that defines the optional machine-dependent 28279 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT' / 28280 `EXTRA_CONSTRAINT_STR', that should be treated like address 28281 constraints by the reload pass. 28282 28283 It should return 1 if the operand type represented by the 28284 constraint at the start of STR, which starts with the letter C, 28285 comprises a subset of all memory addresses including all those 28286 that consist of just a base register. This allows the reload pass 28287 to reload an operand, if it does not directly correspond to the 28288 operand type of STR, by copying it into a base register. 28289 28290 Any constraint marked as `EXTRA_ADDRESS_CONSTRAINT' can only be 28291 used with the `address_operand' predicate. It is treated 28292 analogously to the `p' constraint. 28293 28294 28295 File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Old Constraints, Up: Target Macros 28296 28297 17.10 Stack Layout and Calling Conventions 28298 ========================================== 28299 28300 This describes the stack layout and calling conventions. 28301 28302 * Menu: 28303 28304 * Frame Layout:: 28305 * Exception Handling:: 28306 * Stack Checking:: 28307 * Frame Registers:: 28308 * Elimination:: 28309 * Stack Arguments:: 28310 * Register Arguments:: 28311 * Scalar Return:: 28312 * Aggregate Return:: 28313 * Caller Saves:: 28314 * Function Entry:: 28315 * Profiling:: 28316 * Tail Calls:: 28317 * Stack Smashing Protection:: 28318 28319 28320 File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 28321 28322 17.10.1 Basic Stack Layout 28323 -------------------------- 28324 28325 Here is the basic stack layout. 28326 28327 -- Macro: STACK_GROWS_DOWNWARD 28328 Define this macro if pushing a word onto the stack moves the stack 28329 pointer to a smaller address. 28330 28331 When we say, "define this macro if ...", it means that the 28332 compiler checks this macro only with `#ifdef' so the precise 28333 definition used does not matter. 28334 28335 -- Macro: STACK_PUSH_CODE 28336 This macro defines the operation used when something is pushed on 28337 the stack. In RTL, a push operation will be `(set (mem 28338 (STACK_PUSH_CODE (reg sp))) ...)' 28339 28340 The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'. 28341 Which of these is correct depends on the stack direction and on 28342 whether the stack pointer points to the last item on the stack or 28343 whether it points to the space for the next item on the stack. 28344 28345 The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined, 28346 which is almost always right, and `PRE_INC' otherwise, which is 28347 often wrong. 28348 28349 -- Macro: FRAME_GROWS_DOWNWARD 28350 Define this macro to nonzero value if the addresses of local 28351 variable slots are at negative offsets from the frame pointer. 28352 28353 -- Macro: ARGS_GROW_DOWNWARD 28354 Define this macro if successive arguments to a function occupy 28355 decreasing addresses on the stack. 28356 28357 -- Macro: STARTING_FRAME_OFFSET 28358 Offset from the frame pointer to the first local variable slot to 28359 be allocated. 28360 28361 If `FRAME_GROWS_DOWNWARD', find the next slot's offset by 28362 subtracting the first slot's length from `STARTING_FRAME_OFFSET'. 28363 Otherwise, it is found by adding the length of the first slot to 28364 the value `STARTING_FRAME_OFFSET'. 28365 28366 -- Macro: STACK_ALIGNMENT_NEEDED 28367 Define to zero to disable final alignment of the stack during 28368 reload. The nonzero default for this macro is suitable for most 28369 ports. 28370 28371 On ports where `STARTING_FRAME_OFFSET' is nonzero or where there 28372 is a register save block following the local block that doesn't 28373 require alignment to `STACK_BOUNDARY', it may be beneficial to 28374 disable stack alignment and do it in the backend. 28375 28376 -- Macro: STACK_POINTER_OFFSET 28377 Offset from the stack pointer register to the first location at 28378 which outgoing arguments are placed. If not specified, the 28379 default value of zero is used. This is the proper value for most 28380 machines. 28381 28382 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 28383 the first location at which outgoing arguments are placed. 28384 28385 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 28386 Offset from the argument pointer register to the first argument's 28387 address. On some machines it may depend on the data type of the 28388 function. 28389 28390 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 28391 the first argument's address. 28392 28393 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 28394 Offset from the stack pointer register to an item dynamically 28395 allocated on the stack, e.g., by `alloca'. 28396 28397 The default value for this macro is `STACK_POINTER_OFFSET' plus the 28398 length of the outgoing arguments. The default is correct for most 28399 machines. See `function.c' for details. 28400 28401 -- Macro: INITIAL_FRAME_ADDRESS_RTX 28402 A C expression whose value is RTL representing the address of the 28403 initial stack frame. This address is passed to `RETURN_ADDR_RTX' 28404 and `DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 28405 reasonable default value will be used. Define this macro in order 28406 to make frame pointer elimination work in the presence of 28407 `__builtin_frame_address (count)' and `__builtin_return_address 28408 (count)' for `count' not equal to zero. 28409 28410 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 28411 A C expression whose value is RTL representing the address in a 28412 stack frame where the pointer to the caller's frame is stored. 28413 Assume that FRAMEADDR is an RTL expression for the address of the 28414 stack frame itself. 28415 28416 If you don't define this macro, the default is to return the value 28417 of FRAMEADDR--that is, the stack frame address is also the address 28418 of the stack word that points to the previous frame. 28419 28420 -- Macro: SETUP_FRAME_ADDRESSES 28421 If defined, a C expression that produces the machine-specific code 28422 to setup the stack so that arbitrary frames can be accessed. For 28423 example, on the SPARC, we must flush all of the register windows 28424 to the stack before we can access arbitrary stack frames. You 28425 will seldom need to define this macro. 28426 28427 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 28428 This target hook should return an rtx that is used to store the 28429 address of the current frame into the built in `setjmp' buffer. 28430 The default value, `virtual_stack_vars_rtx', is correct for most 28431 machines. One reason you may need to define this target hook is if 28432 `hard_frame_pointer_rtx' is the appropriate value on your machine. 28433 28434 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 28435 A C expression whose value is RTL representing the value of the 28436 frame address for the current frame. FRAMEADDR is the frame 28437 pointer of the current frame. This is used for 28438 __builtin_frame_address. You need only define this macro if the 28439 frame address is not the same as the frame pointer. Most machines 28440 do not need to define it. 28441 28442 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 28443 A C expression whose value is RTL representing the value of the 28444 return address for the frame COUNT steps up from the current 28445 frame, after the prologue. FRAMEADDR is the frame pointer of the 28446 COUNT frame, or the frame pointer of the COUNT - 1 frame if 28447 `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined. 28448 28449 The value of the expression must always be the correct address when 28450 COUNT is zero, but may be `NULL_RTX' if there is no way to 28451 determine the return address of other frames. 28452 28453 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 28454 Define this if the return address of a particular stack frame is 28455 accessed from the frame pointer of the previous stack frame. 28456 28457 -- Macro: INCOMING_RETURN_ADDR_RTX 28458 A C expression whose value is RTL representing the location of the 28459 incoming return address at the beginning of any function, before 28460 the prologue. This RTL is either a `REG', indicating that the 28461 return value is saved in `REG', or a `MEM' representing a location 28462 in the stack. 28463 28464 You only need to define this macro if you want to support call 28465 frame debugging information like that provided by DWARF 2. 28466 28467 If this RTL is a `REG', you should also define 28468 `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'. 28469 28470 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 28471 A C expression whose value is an integer giving a DWARF 2 column 28472 number that may be used as an alternative return column. The 28473 column must not correspond to any gcc hard register (that is, it 28474 must not be in the range of `DWARF_FRAME_REGNUM'). 28475 28476 This macro can be useful if `DWARF_FRAME_RETURN_COLUMN' is set to a 28477 general register, but an alternative column needs to be used for 28478 signal frames. Some targets have also used different frame return 28479 columns over time. 28480 28481 -- Macro: DWARF_ZERO_REG 28482 A C expression whose value is an integer giving a DWARF 2 register 28483 number that is considered to always have the value zero. This 28484 should only be defined if the target has an architected zero 28485 register, and someone decided it was a good idea to use that 28486 register number to terminate the stack backtrace. New ports 28487 should avoid this. 28488 28489 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 28490 *LABEL, rtx PATTERN, int INDEX) 28491 This target hook allows the backend to emit frame-related insns 28492 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 28493 debugging info engine will invoke it on insns of the form 28494 (set (reg) (unspec [...] UNSPEC_INDEX)) 28495 and 28496 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 28497 to let the backend emit the call frame instructions. LABEL is the 28498 CFI label attached to the insn, PATTERN is the pattern of the insn 28499 and INDEX is `UNSPEC_INDEX' or `UNSPECV_INDEX'. 28500 28501 -- Macro: INCOMING_FRAME_SP_OFFSET 28502 A C expression whose value is an integer giving the offset, in 28503 bytes, from the value of the stack pointer register to the top of 28504 the stack frame at the beginning of any function, before the 28505 prologue. The top of the frame is defined to be the value of the 28506 stack pointer in the previous frame, just before the call 28507 instruction. 28508 28509 You only need to define this macro if you want to support call 28510 frame debugging information like that provided by DWARF 2. 28511 28512 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 28513 A C expression whose value is an integer giving the offset, in 28514 bytes, from the argument pointer to the canonical frame address 28515 (cfa). The final value should coincide with that calculated by 28516 `INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 28517 during virtual register instantiation. 28518 28519 The default value for this macro is `FIRST_PARM_OFFSET (fundecl) + 28520 crtl->args.pretend_args_size', which is correct for most machines; 28521 in general, the arguments are found immediately before the stack 28522 frame. Note that this is not the case on some targets that save 28523 registers into the caller's frame, such as SPARC and rs6000, and 28524 so such targets need to define this macro. 28525 28526 You only need to define this macro if the default is incorrect, 28527 and you want to support call frame debugging information like that 28528 provided by DWARF 2. 28529 28530 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 28531 If defined, a C expression whose value is an integer giving the 28532 offset in bytes from the frame pointer to the canonical frame 28533 address (cfa). The final value should coincide with that 28534 calculated by `INCOMING_FRAME_SP_OFFSET'. 28535 28536 Normally the CFA is calculated as an offset from the argument 28537 pointer, via `ARG_POINTER_CFA_OFFSET', but if the argument pointer 28538 is variable due to the ABI, this may not be possible. If this 28539 macro is defined, it implies that the virtual register 28540 instantiation should be based on the frame pointer instead of the 28541 argument pointer. Only one of `FRAME_POINTER_CFA_OFFSET' and 28542 `ARG_POINTER_CFA_OFFSET' should be defined. 28543 28544 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 28545 If defined, a C expression whose value is an integer giving the 28546 offset in bytes from the canonical frame address (cfa) to the 28547 frame base used in DWARF 2 debug information. The default is 28548 zero. A different value may reduce the size of debug information 28549 on some ports. 28550 28551 28552 File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 28553 28554 17.10.2 Exception Handling Support 28555 ---------------------------------- 28556 28557 -- Macro: EH_RETURN_DATA_REGNO (N) 28558 A C expression whose value is the Nth register number used for 28559 data by exception handlers, or `INVALID_REGNUM' if fewer than N 28560 registers are usable. 28561 28562 The exception handling library routines communicate with the 28563 exception handlers via a set of agreed upon registers. Ideally 28564 these registers should be call-clobbered; it is possible to use 28565 call-saved registers, but may negatively impact code size. The 28566 target must support at least 2 data registers, but should define 4 28567 if there are enough free registers. 28568 28569 You must define this macro if you want to support call frame 28570 exception handling like that provided by DWARF 2. 28571 28572 -- Macro: EH_RETURN_STACKADJ_RTX 28573 A C expression whose value is RTL representing a location in which 28574 to store a stack adjustment to be applied before function return. 28575 This is used to unwind the stack to an exception handler's call 28576 frame. It will be assigned zero on code paths that return 28577 normally. 28578 28579 Typically this is a call-clobbered hard register that is otherwise 28580 untouched by the epilogue, but could also be a stack slot. 28581 28582 Do not define this macro if the stack pointer is saved and restored 28583 by the regular prolog and epilog code in the call frame itself; in 28584 this case, the exception handling library routines will update the 28585 stack location to be restored in place. Otherwise, you must define 28586 this macro if you want to support call frame exception handling 28587 like that provided by DWARF 2. 28588 28589 -- Macro: EH_RETURN_HANDLER_RTX 28590 A C expression whose value is RTL representing a location in which 28591 to store the address of an exception handler to which we should 28592 return. It will not be assigned on code paths that return 28593 normally. 28594 28595 Typically this is the location in the call frame at which the 28596 normal return address is stored. For targets that return by 28597 popping an address off the stack, this might be a memory address 28598 just below the _target_ call frame rather than inside the current 28599 call frame. If defined, `EH_RETURN_STACKADJ_RTX' will have already 28600 been assigned, so it may be used to calculate the location of the 28601 target call frame. 28602 28603 Some targets have more complex requirements than storing to an 28604 address calculable during initial code generation. In that case 28605 the `eh_return' instruction pattern should be used instead. 28606 28607 If you want to support call frame exception handling, you must 28608 define either this macro or the `eh_return' instruction pattern. 28609 28610 -- Macro: RETURN_ADDR_OFFSET 28611 If defined, an integer-valued C expression for which rtl will be 28612 generated to add it to the exception handler address before it is 28613 searched in the exception handling tables, and to subtract it 28614 again from the address before using it to return to the exception 28615 handler. 28616 28617 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 28618 This macro chooses the encoding of pointers embedded in the 28619 exception handling sections. If at all possible, this should be 28620 defined such that the exception handling section will not require 28621 dynamic relocations, and so may be read-only. 28622 28623 CODE is 0 for data, 1 for code labels, 2 for function pointers. 28624 GLOBAL is true if the symbol may be affected by dynamic 28625 relocations. The macro should return a combination of the 28626 `DW_EH_PE_*' defines as found in `dwarf2.h'. 28627 28628 If this macro is not defined, pointers will not be encoded but 28629 represented directly. 28630 28631 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 28632 ADDR, DONE) 28633 This macro allows the target to emit whatever special magic is 28634 required to represent the encoding chosen by 28635 `ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 28636 pc-relative and indirect encodings; this must be defined if the 28637 target uses text-relative or data-relative encodings. 28638 28639 This is a C statement that branches to DONE if the format was 28640 handled. ENCODING is the format chosen, SIZE is the number of 28641 bytes that the format occupies, ADDR is the `SYMBOL_REF' to be 28642 emitted. 28643 28644 -- Macro: MD_UNWIND_SUPPORT 28645 A string specifying a file to be #include'd in unwind-dw2.c. The 28646 file so included typically defines `MD_FALLBACK_FRAME_STATE_FOR'. 28647 28648 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 28649 This macro allows the target to add CPU and operating system 28650 specific code to the call-frame unwinder for use when there is no 28651 unwind data available. The most common reason to implement this 28652 macro is to unwind through signal frames. 28653 28654 This macro is called from `uw_frame_state_for' in `unwind-dw2.c', 28655 `unwind-dw2-xtensa.c' and `unwind-ia64.c'. CONTEXT is an 28656 `_Unwind_Context'; FS is an `_Unwind_FrameState'. Examine 28657 `context->ra' for the address of the code being executed and 28658 `context->cfa' for the stack pointer value. If the frame can be 28659 decoded, the register save addresses should be updated in FS and 28660 the macro should evaluate to `_URC_NO_REASON'. If the frame 28661 cannot be decoded, the macro should evaluate to 28662 `_URC_END_OF_STACK'. 28663 28664 For proper signal handling in Java this macro is accompanied by 28665 `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h' 28666 headers. 28667 28668 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 28669 This macro allows the target to add operating system specific code 28670 to the call-frame unwinder to handle the IA-64 `.unwabi' unwinding 28671 directive, usually used for signal or interrupt frames. 28672 28673 This macro is called from `uw_update_context' in `unwind-ia64.c'. 28674 CONTEXT is an `_Unwind_Context'; FS is an `_Unwind_FrameState'. 28675 Examine `fs->unwabi' for the abi and context in the `.unwabi' 28676 directive. If the `.unwabi' directive can be handled, the 28677 register save addresses should be updated in FS. 28678 28679 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 28680 A C expression that evaluates to true if the target requires unwind 28681 info to be given comdat linkage. Define it to be `1' if comdat 28682 linkage is necessary. The default is `0'. 28683 28684 28685 File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 28686 28687 17.10.3 Specifying How Stack Checking is Done 28688 --------------------------------------------- 28689 28690 GCC will check that stack references are within the boundaries of the 28691 stack, if the option `-fstack-check' is specified, in one of three ways: 28692 28693 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC 28694 will assume that you have arranged for full stack checking to be 28695 done at appropriate places in the configuration files. GCC will 28696 not do other special processing. 28697 28698 2. If `STACK_CHECK_BUILTIN' is zero and the value of the 28699 `STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume 28700 that you have arranged for static stack checking (checking of the 28701 static stack frame of functions) to be done at appropriate places 28702 in the configuration files. GCC will only emit code to do dynamic 28703 stack checking (checking on dynamic stack allocations) using the 28704 third approach below. 28705 28706 3. If neither of the above are true, GCC will generate code to 28707 periodically "probe" the stack pointer using the values of the 28708 macros defined below. 28709 28710 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 28711 defined, GCC will change its allocation strategy for large objects if 28712 the option `-fstack-check' is specified: they will always be allocated 28713 dynamically if their size exceeds `STACK_CHECK_MAX_VAR_SIZE' bytes. 28714 28715 -- Macro: STACK_CHECK_BUILTIN 28716 A nonzero value if stack checking is done by the configuration 28717 files in a machine-dependent manner. You should define this macro 28718 if stack checking is required by the ABI of your machine or if you 28719 would like to do stack checking in some more efficient way than 28720 the generic approach. The default value of this macro is zero. 28721 28722 -- Macro: STACK_CHECK_STATIC_BUILTIN 28723 A nonzero value if static stack checking is done by the 28724 configuration files in a machine-dependent manner. You should 28725 define this macro if you would like to do static stack checking in 28726 some more efficient way than the generic approach. The default 28727 value of this macro is zero. 28728 28729 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 28730 An integer specifying the interval at which GCC must generate 28731 stack probe instructions, defined as 2 raised to this integer. 28732 You will normally define this macro so that the interval be no 28733 larger than the size of the "guard pages" at the end of a stack 28734 area. The default value of 12 (4096-byte interval) is suitable 28735 for most systems. 28736 28737 -- Macro: STACK_CHECK_MOVING_SP 28738 An integer which is nonzero if GCC should move the stack pointer 28739 page by page when doing probes. This can be necessary on systems 28740 where the stack pointer contains the bottom address of the memory 28741 area accessible to the executing thread at any point in time. In 28742 this situation an alternate signal stack is required in order to 28743 be able to recover from a stack overflow. The default value of 28744 this macro is zero. 28745 28746 -- Macro: STACK_CHECK_PROTECT 28747 The number of bytes of stack needed to recover from a stack 28748 overflow, for languages where such a recovery is supported. The 28749 default value of 75 words with the `setjmp'/`longjmp'-based 28750 exception handling mechanism and 8192 bytes with other exception 28751 handling mechanisms should be adequate for most machines. 28752 28753 The following macros are relevant only if neither STACK_CHECK_BUILTIN 28754 nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 28755 in the opposite case. 28756 28757 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 28758 The maximum size of a stack frame, in bytes. GCC will generate 28759 probe instructions in non-leaf functions to ensure at least this 28760 many bytes of stack are available. If a stack frame is larger 28761 than this size, stack checking will not be reliable and GCC will 28762 issue a warning. The default is chosen so that GCC only generates 28763 one instruction on most systems. You should normally not change 28764 the default value of this macro. 28765 28766 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 28767 GCC uses this value to generate the above warning message. It 28768 represents the amount of fixed frame used by a function, not 28769 including space for any callee-saved registers, temporaries and 28770 user variables. You need only specify an upper bound for this 28771 amount and will normally use the default of four words. 28772 28773 -- Macro: STACK_CHECK_MAX_VAR_SIZE 28774 The maximum size, in bytes, of an object that GCC will place in the 28775 fixed area of the stack frame when the user specifies 28776 `-fstack-check'. GCC computed the default from the values of the 28777 above macros and you will normally not need to override that 28778 default. 28779 28780 28781 File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 28782 28783 17.10.4 Registers That Address the Stack Frame 28784 ---------------------------------------------- 28785 28786 This discusses registers that address the stack frame. 28787 28788 -- Macro: STACK_POINTER_REGNUM 28789 The register number of the stack pointer register, which must also 28790 be a fixed register according to `FIXED_REGISTERS'. On most 28791 machines, the hardware determines which register this is. 28792 28793 -- Macro: FRAME_POINTER_REGNUM 28794 The register number of the frame pointer register, which is used to 28795 access automatic variables in the stack frame. On some machines, 28796 the hardware determines which register this is. On other 28797 machines, you can choose any register you wish for this purpose. 28798 28799 -- Macro: HARD_FRAME_POINTER_REGNUM 28800 On some machines the offset between the frame pointer and starting 28801 offset of the automatic variables is not known until after register 28802 allocation has been done (for example, because the saved registers 28803 are between these two locations). On those machines, define 28804 `FRAME_POINTER_REGNUM' the number of a special, fixed register to 28805 be used internally until the offset is known, and define 28806 `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 28807 used for the frame pointer. 28808 28809 You should define this macro only in the very rare circumstances 28810 when it is not possible to calculate the offset between the frame 28811 pointer and the automatic variables until after register 28812 allocation has been completed. When this macro is defined, you 28813 must also indicate in your definition of `ELIMINABLE_REGS' how to 28814 eliminate `FRAME_POINTER_REGNUM' into either 28815 `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'. 28816 28817 Do not define this macro if it would be the same as 28818 `FRAME_POINTER_REGNUM'. 28819 28820 -- Macro: ARG_POINTER_REGNUM 28821 The register number of the arg pointer register, which is used to 28822 access the function's argument list. On some machines, this is 28823 the same as the frame pointer register. On some machines, the 28824 hardware determines which register this is. On other machines, 28825 you can choose any register you wish for this purpose. If this is 28826 not the same register as the frame pointer register, then you must 28827 mark it as a fixed register according to `FIXED_REGISTERS', or 28828 arrange to be able to eliminate it (*note Elimination::). 28829 28830 -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER 28831 Define this to a preprocessor constant that is nonzero if 28832 `hard_frame_pointer_rtx' and `frame_pointer_rtx' should be the 28833 same. The default definition is `(HARD_FRAME_POINTER_REGNUM == 28834 FRAME_POINTER_REGNUM)'; you only need to define this macro if that 28835 definition is not suitable for use in preprocessor conditionals. 28836 28837 -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER 28838 Define this to a preprocessor constant that is nonzero if 28839 `hard_frame_pointer_rtx' and `arg_pointer_rtx' should be the same. 28840 The default definition is `(HARD_FRAME_POINTER_REGNUM == 28841 ARG_POINTER_REGNUM)'; you only need to define this macro if that 28842 definition is not suitable for use in preprocessor conditionals. 28843 28844 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 28845 The register number of the return address pointer register, which 28846 is used to access the current function's return address from the 28847 stack. On some machines, the return address is not at a fixed 28848 offset from the frame pointer or stack pointer or argument 28849 pointer. This register can be defined to point to the return 28850 address on the stack, and then be converted by `ELIMINABLE_REGS' 28851 into either the frame pointer or stack pointer. 28852 28853 Do not define this macro unless there is no other way to get the 28854 return address from the stack. 28855 28856 -- Macro: STATIC_CHAIN_REGNUM 28857 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 28858 Register numbers used for passing a function's static chain 28859 pointer. If register windows are used, the register number as 28860 seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM', 28861 while the register number as seen by the calling function is 28862 `STATIC_CHAIN_REGNUM'. If these registers are the same, 28863 `STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 28864 28865 The static chain register need not be a fixed register. 28866 28867 If the static chain is passed in memory, these macros should not be 28868 defined; instead, the `TARGET_STATIC_CHAIN' hook should be used. 28869 28870 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL, bool 28871 INCOMING_P) 28872 This hook replaces the use of `STATIC_CHAIN_REGNUM' et al for 28873 targets that may use different static chain locations for different 28874 nested functions. This may be required if the target has function 28875 attributes that affect the calling conventions of the function and 28876 those calling conventions use different static chain locations. 28877 28878 The default version of this hook uses `STATIC_CHAIN_REGNUM' et al. 28879 28880 If the static chain is passed in memory, this hook should be used 28881 to provide rtx giving `mem' expressions that denote where they are 28882 stored. Often the `mem' expression as seen by the caller will be 28883 at an offset from the stack pointer and the `mem' expression as 28884 seen by the callee will be at an offset from the frame pointer. The 28885 variables `stack_pointer_rtx', `frame_pointer_rtx', and 28886 `arg_pointer_rtx' will have been initialized and should be used to 28887 refer to those items. 28888 28889 -- Macro: DWARF_FRAME_REGISTERS 28890 This macro specifies the maximum number of hard registers that can 28891 be saved in a call frame. This is used to size data structures 28892 used in DWARF2 exception handling. 28893 28894 Prior to GCC 3.0, this macro was needed in order to establish a 28895 stable exception handling ABI in the face of adding new hard 28896 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 28897 insulated from changes in the number of hard registers. 28898 Nevertheless, this macro can still be used to reduce the runtime 28899 memory requirements of the exception handling routines, which can 28900 be substantial if the ISA contains a lot of registers that are not 28901 call-saved. 28902 28903 If this macro is not defined, it defaults to 28904 `FIRST_PSEUDO_REGISTER'. 28905 28906 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 28907 This macro is similar to `DWARF_FRAME_REGISTERS', but is provided 28908 for backward compatibility in pre GCC 3.0 compiled code. 28909 28910 If this macro is not defined, it defaults to 28911 `DWARF_FRAME_REGISTERS'. 28912 28913 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 28914 Define this macro if the target's representation for dwarf 28915 registers is different than the internal representation for unwind 28916 column. Given a dwarf register, this macro should return the 28917 internal unwind column number to use instead. 28918 28919 See the PowerPC's SPE target for an example. 28920 28921 -- Macro: DWARF_FRAME_REGNUM (REGNO) 28922 Define this macro if the target's representation for dwarf 28923 registers used in .eh_frame or .debug_frame is different from that 28924 used in other debug info sections. Given a GCC hard register 28925 number, this macro should return the .eh_frame register number. 28926 The default is `DBX_REGISTER_NUMBER (REGNO)'. 28927 28928 28929 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 28930 Define this macro to map register numbers held in the call frame 28931 info that GCC has collected using `DWARF_FRAME_REGNUM' to those 28932 that should be output in .debug_frame (`FOR_EH' is zero) and 28933 .eh_frame (`FOR_EH' is nonzero). The default is to return `REGNO'. 28934 28935 28936 28937 File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 28938 28939 17.10.5 Eliminating Frame Pointer and Arg Pointer 28940 ------------------------------------------------- 28941 28942 This is about eliminating the frame pointer and arg pointer. 28943 28944 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 28945 This target hook should return `true' if a function must have and 28946 use a frame pointer. This target hook is called in the reload 28947 pass. If its return value is `true' the function will have a 28948 frame pointer. 28949 28950 This target hook can in principle examine the current function and 28951 decide according to the facts, but on most machines the constant 28952 `false' or the constant `true' suffices. Use `false' when the 28953 machine allows code to be generated with no frame pointer, and 28954 doing so saves some time or space. Use `true' when there is no 28955 possible advantage to avoiding a frame pointer. 28956 28957 In certain cases, the compiler does not know how to produce valid 28958 code without a frame pointer. The compiler recognizes those cases 28959 and automatically gives the function a frame pointer regardless of 28960 what `TARGET_FRAME_POINTER_REQUIRED' returns. You don't need to 28961 worry about them. 28962 28963 In a function that does not require a frame pointer, the frame 28964 pointer register can be allocated for ordinary usage, unless you 28965 mark it as a fixed register. See `FIXED_REGISTERS' for more 28966 information. 28967 28968 Default return value is `false'. 28969 28970 -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR) 28971 A C statement to store in the variable DEPTH-VAR the difference 28972 between the frame pointer and the stack pointer values immediately 28973 after the function prologue. The value would be computed from 28974 information such as the result of `get_frame_size ()' and the 28975 tables of registers `regs_ever_live' and `call_used_regs'. 28976 28977 If `ELIMINABLE_REGS' is defined, this macro will be not be used and 28978 need not be defined. Otherwise, it must be defined even if 28979 `TARGET_FRAME_POINTER_REQUIRED' always returns true; in that case, 28980 you may set DEPTH-VAR to anything. 28981 28982 -- Macro: ELIMINABLE_REGS 28983 If defined, this macro specifies a table of register pairs used to 28984 eliminate unneeded registers that point into the stack frame. If 28985 it is not defined, the only elimination attempted by the compiler 28986 is to replace references to the frame pointer with references to 28987 the stack pointer. 28988 28989 The definition of this macro is a list of structure 28990 initializations, each of which specifies an original and 28991 replacement register. 28992 28993 On some machines, the position of the argument pointer is not 28994 known until the compilation is completed. In such a case, a 28995 separate hard register must be used for the argument pointer. 28996 This register can be eliminated by replacing it with either the 28997 frame pointer or the argument pointer, depending on whether or not 28998 the frame pointer has been eliminated. 28999 29000 In this case, you might specify: 29001 #define ELIMINABLE_REGS \ 29002 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 29003 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 29004 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 29005 29006 Note that the elimination of the argument pointer with the stack 29007 pointer is specified first since that is the preferred elimination. 29008 29009 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 29010 int TO_REG) 29011 This target hook should returns `true' if the compiler is allowed 29012 to try to replace register number FROM_REG with register number 29013 TO_REG. This target hook need only be defined if `ELIMINABLE_REGS' 29014 is defined, and will usually be `true', since most of the cases 29015 preventing register elimination are things that the compiler 29016 already knows about. 29017 29018 Default return value is `true'. 29019 29020 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 29021 This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It 29022 specifies the initial difference between the specified pair of 29023 registers. This macro must be defined if `ELIMINABLE_REGS' is 29024 defined. 29025 29026 29027 File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 29028 29029 17.10.6 Passing Function Arguments on the Stack 29030 ----------------------------------------------- 29031 29032 The macros in this section control how arguments are passed on the 29033 stack. See the following section for other macros that control passing 29034 certain arguments in registers. 29035 29036 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 29037 This target hook returns `true' if an argument declared in a 29038 prototype as an integral type smaller than `int' should actually be 29039 passed as an `int'. In addition to avoiding errors in certain 29040 cases of mismatch, it also makes for better code on certain 29041 machines. The default is to not promote prototypes. 29042 29043 -- Macro: PUSH_ARGS 29044 A C expression. If nonzero, push insns will be used to pass 29045 outgoing arguments. If the target machine does not have a push 29046 instruction, set it to zero. That directs GCC to use an alternate 29047 strategy: to allocate the entire argument block and then store the 29048 arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING' 29049 must be defined too. 29050 29051 -- Macro: PUSH_ARGS_REVERSED 29052 A C expression. If nonzero, function arguments will be evaluated 29053 from last to first, rather than from first to last. If this macro 29054 is not defined, it defaults to `PUSH_ARGS' on targets where the 29055 stack and args grow in opposite directions, and 0 otherwise. 29056 29057 -- Macro: PUSH_ROUNDING (NPUSHED) 29058 A C expression that is the number of bytes actually pushed onto the 29059 stack when an instruction attempts to push NPUSHED bytes. 29060 29061 On some machines, the definition 29062 29063 #define PUSH_ROUNDING(BYTES) (BYTES) 29064 29065 will suffice. But on other machines, instructions that appear to 29066 push one byte actually push two bytes in an attempt to maintain 29067 alignment. Then the definition should be 29068 29069 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 29070 29071 If the value of this macro has a type, it should be an unsigned 29072 type. 29073 29074 -- Macro: ACCUMULATE_OUTGOING_ARGS 29075 A C expression. If nonzero, the maximum amount of space required 29076 for outgoing arguments will be computed and placed into the 29077 variable `current_function_outgoing_args_size'. No space will be 29078 pushed onto the stack for each call; instead, the function 29079 prologue should increase the stack frame size by this amount. 29080 29081 Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not 29082 proper. 29083 29084 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 29085 Define this macro if functions should assume that stack space has 29086 been allocated for arguments even when their values are passed in 29087 registers. 29088 29089 The value of this macro is the size, in bytes, of the area 29090 reserved for arguments passed in registers for the function 29091 represented by FNDECL, which can be zero if GCC is calling a 29092 library function. The argument FNDECL can be the FUNCTION_DECL, 29093 or the type itself of the function. 29094 29095 This space can be allocated by the caller, or be a part of the 29096 machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says 29097 which. 29098 29099 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 29100 Define this to a nonzero value if it is the responsibility of the 29101 caller to allocate the area reserved for arguments passed in 29102 registers when calling a function of FNTYPE. FNTYPE may be NULL 29103 if the function called is a library function. 29104 29105 If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 29106 whether the space for these arguments counts in the value of 29107 `current_function_outgoing_args_size'. 29108 29109 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 29110 Define this macro if `REG_PARM_STACK_SPACE' is defined, but the 29111 stack parameters don't skip the area specified by it. 29112 29113 Normally, when a parameter is not passed in registers, it is 29114 placed on the stack beyond the `REG_PARM_STACK_SPACE' area. 29115 Defining this macro suppresses this behavior and causes the 29116 parameter to be passed on the stack in its natural location. 29117 29118 -- Target Hook: int TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree 29119 FUNTYPE, int SIZE) 29120 This target hook returns the number of bytes of its own arguments 29121 that a function pops on returning, or 0 if the function pops no 29122 arguments and the caller must therefore pop them all after the 29123 function returns. 29124 29125 FUNDECL is a C variable whose value is a tree node that describes 29126 the function in question. Normally it is a node of type 29127 `FUNCTION_DECL' that describes the declaration of the function. 29128 From this you can obtain the `DECL_ATTRIBUTES' of the function. 29129 29130 FUNTYPE is a C variable whose value is a tree node that describes 29131 the function in question. Normally it is a node of type 29132 `FUNCTION_TYPE' that describes the data type of the function. 29133 From this it is possible to obtain the data types of the value and 29134 arguments (if known). 29135 29136 When a call to a library function is being considered, FUNDECL 29137 will contain an identifier node for the library function. Thus, if 29138 you need to distinguish among various library functions, you can 29139 do so by their names. Note that "library function" in this 29140 context means a function used to perform arithmetic, whose name is 29141 known specially in the compiler and was not mentioned in the C 29142 code being compiled. 29143 29144 SIZE is the number of bytes of arguments passed on the stack. If 29145 a variable number of bytes is passed, it is zero, and argument 29146 popping will always be the responsibility of the calling function. 29147 29148 On the VAX, all functions always pop their arguments, so the 29149 definition of this macro is SIZE. On the 68000, using the standard 29150 calling convention, no functions pop their arguments, so the value 29151 of the macro is always 0 in this case. But an alternative calling 29152 convention is available in which functions that take a fixed 29153 number of arguments pop them but other functions (such as 29154 `printf') pop nothing (the caller pops all). When this convention 29155 is in use, FUNTYPE is examined to determine whether a function 29156 takes a fixed number of arguments. 29157 29158 -- Macro: CALL_POPS_ARGS (CUM) 29159 A C expression that should indicate the number of bytes a call 29160 sequence pops off the stack. It is added to the value of 29161 `RETURN_POPS_ARGS' when compiling a function call. 29162 29163 CUM is the variable in which all arguments to the called function 29164 have been accumulated. 29165 29166 On certain architectures, such as the SH5, a call trampoline is 29167 used that pops certain registers off the stack, depending on the 29168 arguments that have been passed to the function. Since this is a 29169 property of the call site, not of the called function, 29170 `RETURN_POPS_ARGS' is not appropriate. 29171 29172 29173 File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 29174 29175 17.10.7 Passing Arguments in Registers 29176 -------------------------------------- 29177 29178 This section describes the macros which let you control how various 29179 types of arguments are passed in registers or how they are arranged in 29180 the stack. 29181 29182 -- Macro: FUNCTION_ARG (CUM, MODE, TYPE, NAMED) 29183 A C expression that controls whether a function argument is passed 29184 in a register, and which register. 29185 29186 The arguments are CUM, which summarizes all the previous 29187 arguments; MODE, the machine mode of the argument; TYPE, the data 29188 type of the argument as a tree node or 0 if that is not known 29189 (which happens for C support library functions); and NAMED, which 29190 is 1 for an ordinary argument and 0 for nameless arguments that 29191 correspond to `...' in the called function's prototype. TYPE can 29192 be an incomplete type if a syntax error has previously occurred. 29193 29194 The value of the expression is usually either a `reg' RTX for the 29195 hard register in which to pass the argument, or zero to pass the 29196 argument on the stack. 29197 29198 For machines like the VAX and 68000, where normally all arguments 29199 are pushed, zero suffices as a definition. 29200 29201 The value of the expression can also be a `parallel' RTX. This is 29202 used when an argument is passed in multiple locations. The mode 29203 of the `parallel' should be the mode of the entire argument. The 29204 `parallel' holds any number of `expr_list' pairs; each one 29205 describes where part of the argument is passed. In each 29206 `expr_list' the first operand must be a `reg' RTX for the hard 29207 register in which to pass this part of the argument, and the mode 29208 of the register RTX indicates how large this part of the argument 29209 is. The second operand of the `expr_list' is a `const_int' which 29210 gives the offset in bytes into the entire argument of where this 29211 part starts. As a special exception the first `expr_list' in the 29212 `parallel' RTX may have a first operand of zero. This indicates 29213 that the entire argument is also stored on the stack. 29214 29215 The last time this macro is called, it is called with `MODE == 29216 VOIDmode', and its result is passed to the `call' or `call_value' 29217 pattern as operands 2 and 3 respectively. 29218 29219 The usual way to make the ISO library `stdarg.h' work on a machine 29220 where some arguments are usually passed in registers, is to cause 29221 nameless arguments to be passed on the stack instead. This is done 29222 by making `FUNCTION_ARG' return 0 whenever NAMED is 0. 29223 29224 You may use the hook `targetm.calls.must_pass_in_stack' in the 29225 definition of this macro to determine if this argument is of a 29226 type that must be passed in the stack. If `REG_PARM_STACK_SPACE' 29227 is not defined and `FUNCTION_ARG' returns nonzero for such an 29228 argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is 29229 defined, the argument will be computed in the stack and then 29230 loaded into a register. 29231 29232 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (enum machine_mode 29233 MODE, const_tree TYPE) 29234 This target hook should return `true' if we should not pass TYPE 29235 solely in registers. The file `expr.h' defines a definition that 29236 is usually appropriate, refer to `expr.h' for additional 29237 documentation. 29238 29239 -- Macro: FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED) 29240 Define this macro if the target machine has "register windows", so 29241 that the register in which a function sees an arguments is not 29242 necessarily the same as the one in which the caller passed the 29243 argument. 29244 29245 For such machines, `FUNCTION_ARG' computes the register in which 29246 the caller passes the value, and `FUNCTION_INCOMING_ARG' should be 29247 defined in a similar fashion to tell the function being called 29248 where the arguments will arrive. 29249 29250 If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves 29251 both purposes. 29252 29253 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (CUMULATIVE_ARGS *CUM, 29254 enum machine_mode MODE, tree TYPE, bool NAMED) 29255 This target hook returns the number of bytes at the beginning of an 29256 argument that must be put in registers. The value must be zero for 29257 arguments that are passed entirely in registers or that are 29258 entirely pushed on the stack. 29259 29260 On some machines, certain arguments must be passed partially in 29261 registers and partially in memory. On these machines, typically 29262 the first few words of arguments are passed in registers, and the 29263 rest on the stack. If a multi-word argument (a `double' or a 29264 structure) crosses that boundary, its first few words must be 29265 passed in registers and the rest must be pushed. This macro tells 29266 the compiler when this occurs, and how many bytes should go in 29267 registers. 29268 29269 `FUNCTION_ARG' for these arguments should return the first 29270 register to be used by the caller for this argument; likewise 29271 `FUNCTION_INCOMING_ARG', for the called function. 29272 29273 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (CUMULATIVE_ARGS *CUM, 29274 enum machine_mode MODE, const_tree TYPE, bool NAMED) 29275 This target hook should return `true' if an argument at the 29276 position indicated by CUM should be passed by reference. This 29277 predicate is queried after target independent reasons for being 29278 passed by reference, such as `TREE_ADDRESSABLE (type)'. 29279 29280 If the hook returns true, a copy of that argument is made in 29281 memory and a pointer to the argument is passed instead of the 29282 argument itself. The pointer is passed in whatever way is 29283 appropriate for passing a pointer to that type. 29284 29285 -- Target Hook: bool TARGET_CALLEE_COPIES (CUMULATIVE_ARGS *CUM, enum 29286 machine_mode MODE, const_tree TYPE, bool NAMED) 29287 The function argument described by the parameters to this hook is 29288 known to be passed by reference. The hook should return true if 29289 the function argument should be copied by the callee instead of 29290 copied by the caller. 29291 29292 For any argument for which the hook returns true, if it can be 29293 determined that the argument is not modified, then a copy need not 29294 be generated. 29295 29296 The default version of this hook always returns false. 29297 29298 -- Macro: CUMULATIVE_ARGS 29299 A C type for declaring a variable that is used as the first 29300 argument of `FUNCTION_ARG' and other related values. For some 29301 target machines, the type `int' suffices and can hold the number 29302 of bytes of argument so far. 29303 29304 There is no need to record in `CUMULATIVE_ARGS' anything about the 29305 arguments that have been passed on the stack. The compiler has 29306 other variables to keep track of that. For target machines on 29307 which all arguments are passed on the stack, there is no need to 29308 store anything in `CUMULATIVE_ARGS'; however, the data structure 29309 must exist and should not be empty, so use `int'. 29310 29311 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 29312 If defined, this macro is called before generating any code for a 29313 function, but after the CFUN descriptor for the function has been 29314 created. The back end may use this macro to update CFUN to 29315 reflect an ABI other than that which would normally be used by 29316 default. If the compiler is generating code for a 29317 compiler-generated function, FNDECL may be `NULL'. 29318 29319 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 29320 N_NAMED_ARGS) 29321 A C statement (sans semicolon) for initializing the variable CUM 29322 for the state at the beginning of the argument list. The variable 29323 has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 29324 for the data type of the function which will receive the args, or 29325 0 if the args are to a compiler support library function. For 29326 direct calls that are not libcalls, FNDECL contain the declaration 29327 node of the function. FNDECL is also set when 29328 `INIT_CUMULATIVE_ARGS' is used to find arguments for the function 29329 being compiled. N_NAMED_ARGS is set to the number of named 29330 arguments, including a structure return address if it is passed as 29331 a parameter, when making a call. When processing incoming 29332 arguments, N_NAMED_ARGS is set to -1. 29333 29334 When processing a call to a compiler support library function, 29335 LIBNAME identifies which one. It is a `symbol_ref' rtx which 29336 contains the name of the function, as a string. LIBNAME is 0 when 29337 an ordinary C function call is being processed. Thus, each time 29338 this macro is called, either LIBNAME or FNTYPE is nonzero, but 29339 never both of them at once. 29340 29341 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 29342 Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, 29343 it gets a `MODE' argument instead of FNTYPE, that would be `NULL'. 29344 INDIRECT would always be zero, too. If this macro is not defined, 29345 `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 29346 29347 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 29348 Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 29349 finding the arguments for the function being compiled. If this 29350 macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead. 29351 29352 The value passed for LIBNAME is always 0, since library routines 29353 with special calling conventions are never compiled with GCC. The 29354 argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'. 29355 29356 -- Macro: FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED) 29357 A C statement (sans semicolon) to update the summarizer variable 29358 CUM to advance past an argument in the argument list. The values 29359 MODE, TYPE and NAMED describe that argument. Once this is done, 29360 the variable CUM is suitable for analyzing the _following_ 29361 argument with `FUNCTION_ARG', etc. 29362 29363 This macro need not do anything if the argument in question was 29364 passed on the stack. The compiler knows how to track the amount 29365 of stack space used for arguments without any special help. 29366 29367 -- Macro: FUNCTION_ARG_OFFSET (MODE, TYPE) 29368 If defined, a C expression that is the number of bytes to add to 29369 the offset of the argument passed in memory. This is needed for 29370 the SPU, which passes `char' and `short' arguments in the preferred 29371 slot that is in the middle of the quad word instead of starting at 29372 the top. 29373 29374 -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE) 29375 If defined, a C expression which determines whether, and in which 29376 direction, to pad out an argument with extra space. The value 29377 should be of type `enum direction': either `upward' to pad above 29378 the argument, `downward' to pad below, or `none' to inhibit 29379 padding. 29380 29381 The _amount_ of padding is always just enough to reach the next 29382 multiple of `TARGET_FUNCTION_ARG_BOUNDARY'; this macro does not 29383 control it. 29384 29385 This macro has a default definition which is right for most 29386 systems. For little-endian machines, the default is to pad 29387 upward. For big-endian machines, the default is to pad downward 29388 for an argument of constant size shorter than an `int', and upward 29389 otherwise. 29390 29391 -- Macro: PAD_VARARGS_DOWN 29392 If defined, a C expression which determines whether the default 29393 implementation of va_arg will attempt to pad down before reading 29394 the next argument, if that argument is smaller than its aligned 29395 space as controlled by `PARM_BOUNDARY'. If this macro is not 29396 defined, all such arguments are padded down if `BYTES_BIG_ENDIAN' 29397 is true. 29398 29399 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 29400 Specify padding for the last element of a block move between 29401 registers and memory. FIRST is nonzero if this is the only 29402 element. Defining this macro allows better control of register 29403 function parameters on big-endian machines, without using 29404 `PARALLEL' rtl. In particular, `MUST_PASS_IN_STACK' need not test 29405 padding and mode of types in registers, as there is no longer a 29406 "wrong" part of a register; For example, a three byte aggregate 29407 may be passed in the high part of a register if so required. 29408 29409 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (enum 29410 machine_mode MODE, const_tree TYPE) 29411 This hook returns the alignment boundary, in bits, of an argument 29412 with the specified mode and type. The default hook returns 29413 `PARM_BOUNDARY' for all arguments. 29414 29415 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 29416 A C expression that is nonzero if REGNO is the number of a hard 29417 register in which function arguments are sometimes passed. This 29418 does _not_ include implicit arguments such as the static chain and 29419 the structure-value address. On many machines, no registers can be 29420 used for this purpose since all function arguments are pushed on 29421 the stack. 29422 29423 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 29424 This hook should return true if parameter of type TYPE are passed 29425 as two scalar parameters. By default, GCC will attempt to pack 29426 complex arguments into the target's word size. Some ABIs require 29427 complex arguments to be split and treated as their individual 29428 components. For example, on AIX64, complex floats should be 29429 passed in a pair of floating point registers, even though a 29430 complex float would fit in one 64-bit floating point register. 29431 29432 The default value of this hook is `NULL', which is treated as 29433 always false. 29434 29435 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 29436 This hook returns a type node for `va_list' for the target. The 29437 default version of the hook returns `void*'. 29438 29439 -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char 29440 **PNAME, tree *PTREE) 29441 This target hook is used in function `c_common_nodes_and_builtins' 29442 to iterate through the target specific builtin types for va_list. 29443 The variable IDX is used as iterator. PNAME has to be a pointer to 29444 a `const char *' and PTREE a pointer to a `tree' typed variable. 29445 The arguments PNAME and PTREE are used to store the result of this 29446 macro and are set to the name of the va_list builtin type and its 29447 internal type. If the return value of this macro is zero, then 29448 there is no more element. Otherwise the IDX should be increased 29449 for the next call of this macro to iterate through all types. 29450 29451 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 29452 This hook returns the va_list type of the calling convention 29453 specified by FNDECL. The default version of this hook returns 29454 `va_list_type_node'. 29455 29456 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 29457 This hook returns the va_list type of the calling convention 29458 specified by the type of TYPE. If TYPE is not a valid va_list 29459 type, it returns `NULL_TREE'. 29460 29461 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 29462 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 29463 This hook performs target-specific gimplification of 29464 `VA_ARG_EXPR'. The first two parameters correspond to the 29465 arguments to `va_arg'; the latter two are as in 29466 `gimplify.c:gimplify_expr'. 29467 29468 -- Target Hook: bool TARGET_VALID_POINTER_MODE (enum machine_mode MODE) 29469 Define this to return nonzero if the port can handle pointers with 29470 machine mode MODE. The default version of this hook returns true 29471 for both `ptr_mode' and `Pmode'. 29472 29473 -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (struct ao_ref_s *REF) 29474 Define this to return nonzero if the memory reference REF may 29475 alias with the system C library errno location. The default 29476 version of this hook assumes the system C library errno location 29477 is either a declaration of type int or accessed by dereferencing 29478 a pointer to int. 29479 29480 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (enum machine_mode 29481 MODE) 29482 Define this to return nonzero if the port is prepared to handle 29483 insns involving scalar mode MODE. For a scalar mode to be 29484 considered supported, all the basic arithmetic and comparisons 29485 must work. 29486 29487 The default version of this hook returns true for any mode 29488 required to handle the basic C types (as defined by the port). 29489 Included here are the double-word arithmetic supported by the code 29490 in `optabs.c'. 29491 29492 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (enum machine_mode 29493 MODE) 29494 Define this to return nonzero if the port is prepared to handle 29495 insns involving vector mode MODE. At the very least, it must have 29496 move patterns for this mode. 29497 29498 -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P (enum 29499 machine_mode MODE) 29500 Define this to return nonzero for machine modes for which the port 29501 has small register classes. If this target hook returns nonzero 29502 for a given MODE, the compiler will try to minimize the lifetime 29503 of registers in MODE. The hook may be called with `VOIDmode' as 29504 argument. In this case, the hook is expected to return nonzero if 29505 it returns nonzero for any mode. 29506 29507 On some machines, it is risky to let hard registers live across 29508 arbitrary insns. Typically, these machines have instructions that 29509 require values to be in specific registers (like an accumulator), 29510 and reload will fail if the required hard register is used for 29511 another purpose across such an insn. 29512 29513 Passes before reload do not know which hard registers will be used 29514 in an instruction, but the machine modes of the registers set or 29515 used in the instruction are already known. And for some machines, 29516 register classes are small for, say, integer registers but not for 29517 floating point registers. For example, the AMD x86-64 29518 architecture requires specific registers for the legacy x86 29519 integer instructions, but there are many SSE registers for 29520 floating point operations. On such targets, a good strategy may 29521 be to return nonzero from this hook for `INTEGRAL_MODE_P' machine 29522 modes but zero for the SSE register classes. 29523 29524 The default version of this hook returns false for any mode. It 29525 is always safe to redefine this hook to return with a nonzero 29526 value. But if you unnecessarily define it, you will reduce the 29527 amount of optimizations that can be performed in some cases. If 29528 you do not define this hook to return a nonzero value when it is 29529 required, the compiler will run out of spill registers and print a 29530 fatal error message. 29531 29532 -- Target Hook: unsigned int TARGET_FLAGS_REGNUM 29533 If the target has a dedicated flags register, and it needs to use 29534 the post-reload comparison elimination pass, then this value 29535 should be set appropriately. 29536 29537 29538 File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 29539 29540 17.10.8 How Scalar Function Values Are Returned 29541 ----------------------------------------------- 29542 29543 This section discusses the macros that control returning scalars as 29544 values--values that can fit in registers. 29545 29546 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 29547 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 29548 Define this to return an RTX representing the place where a 29549 function returns or receives a value of data type RET_TYPE, a tree 29550 node representing a data type. FN_DECL_OR_TYPE is a tree node 29551 representing `FUNCTION_DECL' or `FUNCTION_TYPE' of a function 29552 being called. If OUTGOING is false, the hook should compute the 29553 register in which the caller will see the return value. 29554 Otherwise, the hook should return an RTX representing the place 29555 where a function returns a value. 29556 29557 On many machines, only `TYPE_MODE (RET_TYPE)' is relevant. 29558 (Actually, on most machines, scalar values are returned in the same 29559 place regardless of mode.) The value of the expression is usually 29560 a `reg' RTX for the hard register where the return value is stored. 29561 The value can also be a `parallel' RTX, if the return value is in 29562 multiple places. See `FUNCTION_ARG' for an explanation of the 29563 `parallel' form. Note that the callee will populate every 29564 location specified in the `parallel', but if the first element of 29565 the `parallel' contains the whole return value, callers will use 29566 that element as the canonical location and ignore the others. The 29567 m68k port uses this type of `parallel' to return pointers in both 29568 `%a0' (the canonical location) and `%d0'. 29569 29570 If `TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 29571 the same promotion rules specified in `PROMOTE_MODE' if VALTYPE is 29572 a scalar type. 29573 29574 If the precise function being called is known, FUNC is a tree node 29575 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 29576 makes it possible to use a different value-returning convention 29577 for specific functions when all their calls are known. 29578 29579 Some target machines have "register windows" so that the register 29580 in which a function returns its value is not the same as the one 29581 in which the caller sees the value. For such machines, you should 29582 return different RTX depending on OUTGOING. 29583 29584 `TARGET_FUNCTION_VALUE' is not used for return values with 29585 aggregate data types, because these are returned in another way. 29586 See `TARGET_STRUCT_VALUE_RTX' and related macros, below. 29587 29588 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 29589 This macro has been deprecated. Use `TARGET_FUNCTION_VALUE' for a 29590 new target instead. 29591 29592 -- Macro: LIBCALL_VALUE (MODE) 29593 A C expression to create an RTX representing the place where a 29594 library function returns a value of mode MODE. 29595 29596 Note that "library function" in this context means a compiler 29597 support routine, used to perform arithmetic, whose name is known 29598 specially by the compiler and was not mentioned in the C code being 29599 compiled. 29600 29601 -- Target Hook: rtx TARGET_LIBCALL_VALUE (enum machine_mode MODE, 29602 const_rtx FUN) 29603 Define this hook if the back-end needs to know the name of the 29604 libcall function in order to determine where the result should be 29605 returned. 29606 29607 The mode of the result is given by MODE and the name of the called 29608 library function is given by FUN. The hook should return an RTX 29609 representing the place where the library function result will be 29610 returned. 29611 29612 If this hook is not defined, then LIBCALL_VALUE will be used. 29613 29614 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 29615 A C expression that is nonzero if REGNO is the number of a hard 29616 register in which the values of called function may come back. 29617 29618 A register whose use for returning values is limited to serving as 29619 the second of a pair (for a value of type `double', say) need not 29620 be recognized by this macro. So for most machines, this definition 29621 suffices: 29622 29623 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 29624 29625 If the machine has register windows, so that the caller and the 29626 called function use different registers for the return value, this 29627 macro should recognize only the caller's register numbers. 29628 29629 This macro has been deprecated. Use 29630 `TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead. 29631 29632 -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int 29633 REGNO) 29634 A target hook that return `true' if REGNO is the number of a hard 29635 register in which the values of called function may come back. 29636 29637 A register whose use for returning values is limited to serving as 29638 the second of a pair (for a value of type `double', say) need not 29639 be recognized by this target hook. 29640 29641 If the machine has register windows, so that the caller and the 29642 called function use different registers for the return value, this 29643 target hook should recognize only the caller's register numbers. 29644 29645 If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be 29646 used. 29647 29648 -- Macro: APPLY_RESULT_SIZE 29649 Define this macro if `untyped_call' and `untyped_return' need more 29650 space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and 29651 restoring an arbitrary return value. 29652 29653 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 29654 This hook should return true if values of type TYPE are returned 29655 at the most significant end of a register (in other words, if they 29656 are padded at the least significant end). You can assume that TYPE 29657 is returned in a register; the caller is required to check this. 29658 29659 Note that the register provided by `TARGET_FUNCTION_VALUE' must be 29660 able to hold the complete return value. For example, if a 1-, 2- 29661 or 3-byte structure is returned at the most significant end of a 29662 4-byte register, `TARGET_FUNCTION_VALUE' should provide an 29663 `SImode' rtx. 29664 29665 29666 File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 29667 29668 17.10.9 How Large Values Are Returned 29669 ------------------------------------- 29670 29671 When a function value's mode is `BLKmode' (and in some other cases), 29672 the value is not returned according to `TARGET_FUNCTION_VALUE' (*note 29673 Scalar Return::). Instead, the caller passes the address of a block of 29674 memory in which the value should be stored. This address is called the 29675 "structure value address". 29676 29677 This section describes how to control returning structure values in 29678 memory. 29679 29680 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 29681 const_tree FNTYPE) 29682 This target hook should return a nonzero value to say to return the 29683 function value in memory, just as large structures are always 29684 returned. Here TYPE will be the data type of the value, and FNTYPE 29685 will be the type of the function doing the returning, or `NULL' for 29686 libcalls. 29687 29688 Note that values of mode `BLKmode' must be explicitly handled by 29689 this function. Also, the option `-fpcc-struct-return' takes 29690 effect regardless of this macro. On most systems, it is possible 29691 to leave the hook undefined; this causes a default definition to 29692 be used, whose value is the constant 1 for `BLKmode' values, and 0 29693 otherwise. 29694 29695 Do not use this hook to indicate that structures and unions should 29696 always be returned in memory. You should instead use 29697 `DEFAULT_PCC_STRUCT_RETURN' to indicate this. 29698 29699 -- Macro: DEFAULT_PCC_STRUCT_RETURN 29700 Define this macro to be 1 if all structure and union return values 29701 must be in memory. Since this results in slower code, this should 29702 be defined only if needed for compatibility with other compilers 29703 or with an ABI. If you define this macro to be 0, then the 29704 conventions used for structure and union return values are decided 29705 by the `TARGET_RETURN_IN_MEMORY' target hook. 29706 29707 If not defined, this defaults to the value 1. 29708 29709 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 29710 This target hook should return the location of the structure value 29711 address (normally a `mem' or `reg'), or 0 if the address is passed 29712 as an "invisible" first argument. Note that FNDECL may be `NULL', 29713 for libcalls. You do not need to define this target hook if the 29714 address is always passed as an "invisible" first argument. 29715 29716 On some architectures the place where the structure value address 29717 is found by the called function is not the same place that the 29718 caller put it. This can be due to register windows, or it could 29719 be because the function prologue moves it to a different place. 29720 INCOMING is `1' or `2' when the location is needed in the context 29721 of the called function, and `0' in the context of the caller. 29722 29723 If INCOMING is nonzero and the address is to be found on the 29724 stack, return a `mem' which refers to the frame pointer. If 29725 INCOMING is `2', the result is being used to fetch the structure 29726 value address at the beginning of a function. If you need to emit 29727 adjusting code, you should do it at this point. 29728 29729 -- Macro: PCC_STATIC_STRUCT_RETURN 29730 Define this macro if the usual system convention on the target 29731 machine for returning structures and unions is for the called 29732 function to return the address of a static variable containing the 29733 value. 29734 29735 Do not define this if the usual system convention is for the 29736 caller to pass an address to the subroutine. 29737 29738 This macro has effect in `-fpcc-struct-return' mode, but it does 29739 nothing when you use `-freg-struct-return' mode. 29740 29741 -- Target Hook: enum machine_mode TARGET_GET_RAW_RESULT_MODE (int 29742 REGNO) 29743 This target hook returns the mode to be used when accessing raw 29744 return registers in `__builtin_return'. Define this macro if the 29745 value in REG_RAW_MODE is not correct. 29746 29747 -- Target Hook: enum machine_mode TARGET_GET_RAW_ARG_MODE (int REGNO) 29748 This target hook returns the mode to be used when accessing raw 29749 argument registers in `__builtin_apply_args'. Define this macro 29750 if the value in REG_RAW_MODE is not correct. 29751 29752 29753 File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 29754 29755 17.10.10 Caller-Saves Register Allocation 29756 ----------------------------------------- 29757 29758 If you enable it, GCC can save registers around function calls. This 29759 makes it possible to use call-clobbered registers to hold variables that 29760 must live across calls. 29761 29762 -- Macro: CALLER_SAVE_PROFITABLE (REFS, CALLS) 29763 A C expression to determine whether it is worthwhile to consider 29764 placing a pseudo-register in a call-clobbered hard register and 29765 saving and restoring it around each function call. The expression 29766 should be 1 when this is worth doing, and 0 otherwise. 29767 29768 If you don't define this macro, a default is used which is good on 29769 most machines: `4 * CALLS < REFS'. 29770 29771 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 29772 A C expression specifying which mode is required for saving NREGS 29773 of a pseudo-register in call-clobbered hard register REGNO. If 29774 REGNO is unsuitable for caller save, `VOIDmode' should be 29775 returned. For most machines this macro need not be defined since 29776 GCC will select the smallest suitable mode. 29777 29778 29779 File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 29780 29781 17.10.11 Function Entry and Exit 29782 -------------------------------- 29783 29784 This section describes the macros that output function entry 29785 ("prologue") and exit ("epilogue") code. 29786 29787 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE, 29788 HOST_WIDE_INT SIZE) 29789 If defined, a function that outputs the assembler code for entry 29790 to a function. The prologue is responsible for setting up the 29791 stack frame, initializing the frame pointer register, saving 29792 registers that must be saved, and allocating SIZE additional bytes 29793 of storage for the local variables. SIZE is an integer. FILE is 29794 a stdio stream to which the assembler code should be output. 29795 29796 The label for the beginning of the function need not be output by 29797 this macro. That has already been done when the macro is run. 29798 29799 To determine which registers to save, the macro can refer to the 29800 array `regs_ever_live': element R is nonzero if hard register R is 29801 used anywhere within the function. This implies the function 29802 prologue should save register R, provided it is not one of the 29803 call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must 29804 likewise use `regs_ever_live'.) 29805 29806 On machines that have "register windows", the function entry code 29807 does not save on the stack the registers that are in the windows, 29808 even if they are supposed to be preserved by function calls; 29809 instead it takes appropriate steps to "push" the register stack, 29810 if any non-call-used registers are used in the function. 29811 29812 On machines where functions may or may not have frame-pointers, the 29813 function entry code must vary accordingly; it must set up the frame 29814 pointer if one is wanted, and not otherwise. To determine whether 29815 a frame pointer is in wanted, the macro can refer to the variable 29816 `frame_pointer_needed'. The variable's value will be 1 at run 29817 time in a function that needs a frame pointer. *Note 29818 Elimination::. 29819 29820 The function entry code is responsible for allocating any stack 29821 space required for the function. This stack space consists of the 29822 regions listed below. In most cases, these regions are allocated 29823 in the order listed, with the last listed region closest to the 29824 top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is 29825 defined, and the highest address if it is not defined). You can 29826 use a different order for a machine if doing so is more convenient 29827 or required for compatibility reasons. Except in cases where 29828 required by standard or by a debugger, there is no reason why the 29829 stack layout used by GCC need agree with that used by other 29830 compilers for a machine. 29831 29832 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 29833 If defined, a function that outputs assembler code at the end of a 29834 prologue. This should be used when the function prologue is being 29835 emitted as RTL, and you have some extra assembler that needs to be 29836 emitted. *Note prologue instruction pattern::. 29837 29838 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 29839 If defined, a function that outputs assembler code at the start of 29840 an epilogue. This should be used when the function epilogue is 29841 being emitted as RTL, and you have some extra assembler that needs 29842 to be emitted. *Note epilogue instruction pattern::. 29843 29844 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE, 29845 HOST_WIDE_INT SIZE) 29846 If defined, a function that outputs the assembler code for exit 29847 from a function. The epilogue is responsible for restoring the 29848 saved registers and stack pointer to their values when the 29849 function was called, and returning control to the caller. This 29850 macro takes the same arguments as the macro 29851 `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are 29852 determined from `regs_ever_live' and `CALL_USED_REGISTERS' in the 29853 same way. 29854 29855 On some machines, there is a single instruction that does all the 29856 work of returning from the function. On these machines, give that 29857 instruction the name `return' and do not define the macro 29858 `TARGET_ASM_FUNCTION_EPILOGUE' at all. 29859 29860 Do not define a pattern named `return' if you want the 29861 `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 29862 switches to control whether return instructions or epilogues are 29863 used, define a `return' pattern with a validity condition that 29864 tests the target switches appropriately. If the `return' 29865 pattern's validity condition is false, epilogues will be used. 29866 29867 On machines where functions may or may not have frame-pointers, the 29868 function exit code must vary accordingly. Sometimes the code for 29869 these two cases is completely different. To determine whether a 29870 frame pointer is wanted, the macro can refer to the variable 29871 `frame_pointer_needed'. The variable's value will be 1 when 29872 compiling a function that needs a frame pointer. 29873 29874 Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and 29875 `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 29876 The C variable `current_function_is_leaf' is nonzero for such a 29877 function. *Note Leaf Functions::. 29878 29879 On some machines, some functions pop their arguments on exit while 29880 others leave that for the caller to do. For example, the 68020 29881 when given `-mrtd' pops arguments in functions that take a fixed 29882 number of arguments. 29883 29884 Your definition of the macro `RETURN_POPS_ARGS' decides which 29885 functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE' 29886 needs to know what was decided. The number of bytes of the current 29887 function's arguments that this function should pop is available in 29888 `crtl->args.pops_args'. *Note Scalar Return::. 29889 29890 * A region of `current_function_pretend_args_size' bytes of 29891 uninitialized space just underneath the first argument arriving on 29892 the stack. (This may not be at the very start of the allocated 29893 stack region if the calling sequence has pushed anything else 29894 since pushing the stack arguments. But usually, on such machines, 29895 nothing else has been pushed yet, because the function prologue 29896 itself does all the pushing.) This region is used on machines 29897 where an argument may be passed partly in registers and partly in 29898 memory, and, in some cases to support the features in `<stdarg.h>'. 29899 29900 * An area of memory used to save certain registers used by the 29901 function. The size of this area, which may also include space for 29902 such things as the return address and pointers to previous stack 29903 frames, is machine-specific and usually depends on which registers 29904 have been used in the function. Machines with register windows 29905 often do not require a save area. 29906 29907 * A region of at least SIZE bytes, possibly rounded up to an 29908 allocation boundary, to contain the local variables of the 29909 function. On some machines, this region and the save area may 29910 occur in the opposite order, with the save area closer to the top 29911 of the stack. 29912 29913 * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a region of 29914 `current_function_outgoing_args_size' bytes to be used for outgoing 29915 argument lists of the function. *Note Stack Arguments::. 29916 29917 -- Macro: EXIT_IGNORE_STACK 29918 Define this macro as a C expression that is nonzero if the return 29919 instruction or the function epilogue ignores the value of the stack 29920 pointer; in other words, if it is safe to delete an instruction to 29921 adjust the stack pointer before a return from the function. The 29922 default is 0. 29923 29924 Note that this macro's value is relevant only for functions for 29925 which frame pointers are maintained. It is never safe to delete a 29926 final stack adjustment in a function that has no frame pointer, 29927 and the compiler knows this regardless of `EXIT_IGNORE_STACK'. 29928 29929 -- Macro: EPILOGUE_USES (REGNO) 29930 Define this macro as a C expression that is nonzero for registers 29931 that are used by the epilogue or the `return' pattern. The stack 29932 and frame pointer registers are already assumed to be used as 29933 needed. 29934 29935 -- Macro: EH_USES (REGNO) 29936 Define this macro as a C expression that is nonzero for registers 29937 that are used by the exception handling mechanism, and so should 29938 be considered live on entry to an exception edge. 29939 29940 -- Macro: DELAY_SLOTS_FOR_EPILOGUE 29941 Define this macro if the function epilogue contains delay slots to 29942 which instructions from the rest of the function can be "moved". 29943 The definition should be a C expression whose value is an integer 29944 representing the number of delay slots there. 29945 29946 -- Macro: ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N) 29947 A C expression that returns 1 if INSN can be placed in delay slot 29948 number N of the epilogue. 29949 29950 The argument N is an integer which identifies the delay slot now 29951 being considered (since different slots may have different rules of 29952 eligibility). It is never negative and is always less than the 29953 number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE' 29954 returns). If you reject a particular insn for a given delay slot, 29955 in principle, it may be reconsidered for a subsequent delay slot. 29956 Also, other insns may (at least in principle) be considered for 29957 the so far unfilled delay slot. 29958 29959 The insns accepted to fill the epilogue delay slots are put in an 29960 RTL list made with `insn_list' objects, stored in the variable 29961 `current_function_epilogue_delay_list'. The insn for the first 29962 delay slot comes first in the list. Your definition of the macro 29963 `TARGET_ASM_FUNCTION_EPILOGUE' should fill the delay slots by 29964 outputting the insns in this list, usually by calling 29965 `final_scan_insn'. 29966 29967 You need not define this macro if you did not define 29968 `DELAY_SLOTS_FOR_EPILOGUE'. 29969 29970 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 29971 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 29972 VCALL_OFFSET, tree FUNCTION) 29973 A function that outputs the assembler code for a thunk function, 29974 used to implement C++ virtual function calls with multiple 29975 inheritance. The thunk acts as a wrapper around a virtual 29976 function, adjusting the implicit object parameter before handing 29977 control off to the real function. 29978 29979 First, emit code to add the integer DELTA to the location that 29980 contains the incoming first argument. Assume that this argument 29981 contains a pointer, and is the one used to pass the `this' pointer 29982 in C++. This is the incoming argument _before_ the function 29983 prologue, e.g. `%o0' on a sparc. The addition must preserve the 29984 values of all other incoming arguments. 29985 29986 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 29987 be made after adding `delta'. In particular, if P is the adjusted 29988 pointer, the following adjustment should be made: 29989 29990 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 29991 29992 After the additions, emit code to jump to FUNCTION, which is a 29993 `FUNCTION_DECL'. This is a direct pure jump, not a call, and does 29994 not touch the return address. Hence returning from FUNCTION will 29995 return to whoever called the current `thunk'. 29996 29997 The effect must be as if FUNCTION had been called directly with 29998 the adjusted first argument. This macro is responsible for 29999 emitting all of the code for a thunk function; 30000 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' 30001 are not invoked. 30002 30003 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 30004 been extracted from it.) It might possibly be useful on some 30005 targets, but probably not. 30006 30007 If you do not define this macro, the target-independent code in 30008 the C++ front end will generate a less efficient heavyweight thunk 30009 that calls FUNCTION instead of jumping to it. The generic 30010 approach does not support varargs. 30011 30012 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 30013 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 30014 VCALL_OFFSET, const_tree FUNCTION) 30015 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would 30016 be able to output the assembler code for the thunk function 30017 specified by the arguments it is passed, and false otherwise. In 30018 the latter case, the generic approach will be used by the C++ 30019 front end, with the limitations previously exposed. 30020 30021 30022 File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 30023 30024 17.10.12 Generating Code for Profiling 30025 -------------------------------------- 30026 30027 These macros will help you generate code for profiling. 30028 30029 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 30030 A C statement or compound statement to output to FILE some 30031 assembler code to call the profiling subroutine `mcount'. 30032 30033 The details of how `mcount' expects to be called are determined by 30034 your operating system environment, not by GCC. To figure them out, 30035 compile a small program for profiling using the system's installed 30036 C compiler and look at the assembler code that results. 30037 30038 Older implementations of `mcount' expect the address of a counter 30039 variable to be loaded into some register. The name of this 30040 variable is `LP' followed by the number LABELNO, so you would 30041 generate the name using `LP%d' in a `fprintf'. 30042 30043 -- Macro: PROFILE_HOOK 30044 A C statement or compound statement to output to FILE some assembly 30045 code to call the profiling subroutine `mcount' even the target does 30046 not support profiling. 30047 30048 -- Macro: NO_PROFILE_COUNTERS 30049 Define this macro to be an expression with a nonzero value if the 30050 `mcount' subroutine on your system does not need a counter variable 30051 allocated for each function. This is true for almost all modern 30052 implementations. If you define this macro, you must not use the 30053 LABELNO argument to `FUNCTION_PROFILER'. 30054 30055 -- Macro: PROFILE_BEFORE_PROLOGUE 30056 Define this macro if the code for function profiling should come 30057 before the function prologue. Normally, the profiling code comes 30058 after. 30059 30060 30061 File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling 30062 30063 17.10.13 Permitting tail calls 30064 ------------------------------ 30065 30066 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 30067 EXP) 30068 True if it is ok to do sibling call optimization for the specified 30069 call expression EXP. DECL will be the called function, or `NULL' 30070 if this is an indirect call. 30071 30072 It is not uncommon for limitations of calling conventions to 30073 prevent tail calls to functions outside the current unit of 30074 translation, or during PIC compilation. The hook is used to 30075 enforce these restrictions, as the `sibcall' md pattern can not 30076 fail, or fall over to a "normal" call. The criteria for 30077 successful sibling call optimization may vary greatly between 30078 different architectures. 30079 30080 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 30081 Add any hard registers to REGS that are live on entry to the 30082 function. This hook only needs to be defined to provide registers 30083 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 30084 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 30085 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, 30086 FRAME_POINTER_REGNUM, EH_USES, FRAME_POINTER_REGNUM, 30087 ARG_POINTER_REGNUM, and the PIC_OFFSET_TABLE_REGNUM. 30088 30089 30090 File: gccint.info, Node: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling 30091 30092 17.10.14 Stack smashing protection 30093 ---------------------------------- 30094 30095 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 30096 This hook returns a `DECL' node for the external variable to use 30097 for the stack protection guard. This variable is initialized by 30098 the runtime to some random value and is used to initialize the 30099 guard value that is placed at the top of the local stack frame. 30100 The type of this variable must be `ptr_type_node'. 30101 30102 The default version of this hook creates a variable called 30103 `__stack_chk_guard', which is normally defined in `libgcc2.c'. 30104 30105 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 30106 This hook returns a tree expression that alerts the runtime that 30107 the stack protect guard variable has been modified. This 30108 expression should involve a call to a `noreturn' function. 30109 30110 The default version of this hook invokes a function called 30111 `__stack_chk_fail', taking no arguments. This function is 30112 normally defined in `libgcc2.c'. 30113 30114 -- Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, struct 30115 gcc_options *OPTS) 30116 Whether this target supports splitting the stack when the options 30117 described in OPTS have been passed. This is called after options 30118 have been parsed, so the target may reject splitting the stack in 30119 some configurations. The default version of this hook returns 30120 false. If REPORT is true, this function may issue a warning or 30121 error; if REPORT is false, it must simply return a value 30122 30123 30124 File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 30125 30126 17.11 Implementing the Varargs Macros 30127 ===================================== 30128 30129 GCC comes with an implementation of `<varargs.h>' and `<stdarg.h>' that 30130 work without change on machines that pass arguments on the stack. 30131 Other machines require their own implementations of varargs, and the 30132 two machine independent header files must have conditionals to include 30133 it. 30134 30135 ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in the 30136 calling convention for `va_start'. The traditional implementation 30137 takes just one argument, which is the variable in which to store the 30138 argument pointer. The ISO implementation of `va_start' takes an 30139 additional second argument. The user is supposed to write the last 30140 named argument of the function here. 30141 30142 However, `va_start' should not use this argument. The way to find the 30143 end of the named arguments is with the built-in functions described 30144 below. 30145 30146 -- Macro: __builtin_saveregs () 30147 Use this built-in function to save the argument registers in 30148 memory so that the varargs mechanism can access them. Both ISO 30149 and traditional versions of `va_start' must use 30150 `__builtin_saveregs', unless you use 30151 `TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 30152 30153 On some machines, `__builtin_saveregs' is open-coded under the 30154 control of the target hook `TARGET_EXPAND_BUILTIN_SAVEREGS'. On 30155 other machines, it calls a routine written in assembler language, 30156 found in `libgcc2.c'. 30157 30158 Code generated for the call to `__builtin_saveregs' appears at the 30159 beginning of the function, as opposed to where the call to 30160 `__builtin_saveregs' is written, regardless of what the code is. 30161 This is because the registers must be saved before the function 30162 starts to use them for its own purposes. 30163 30164 -- Macro: __builtin_next_arg (LASTARG) 30165 This builtin returns the address of the first anonymous stack 30166 argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns 30167 the address of the location above the first anonymous stack 30168 argument. Use it in `va_start' to initialize the pointer for 30169 fetching arguments from the stack. Also use it in `va_start' to 30170 verify that the second parameter LASTARG is the last named argument 30171 of the current function. 30172 30173 -- Macro: __builtin_classify_type (OBJECT) 30174 Since each machine has its own conventions for which data types are 30175 passed in which kind of register, your implementation of `va_arg' 30176 has to embody these conventions. The easiest way to categorize the 30177 specified data type is to use `__builtin_classify_type' together 30178 with `sizeof' and `__alignof__'. 30179 30180 `__builtin_classify_type' ignores the value of OBJECT, considering 30181 only its data type. It returns an integer describing what kind of 30182 type that is--integer, floating, pointer, structure, and so on. 30183 30184 The file `typeclass.h' defines an enumeration that you can use to 30185 interpret the values of `__builtin_classify_type'. 30186 30187 These machine description macros help implement varargs: 30188 30189 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 30190 If defined, this hook produces the machine-specific code for a 30191 call to `__builtin_saveregs'. This code will be moved to the very 30192 beginning of the function, before any parameter access are made. 30193 The return value of this function should be an RTX that contains 30194 the value to use as the return of `__builtin_saveregs'. 30195 30196 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (CUMULATIVE_ARGS 30197 *ARGS_SO_FAR, enum machine_mode MODE, tree TYPE, int 30198 *PRETEND_ARGS_SIZE, int SECOND_TIME) 30199 This target hook offers an alternative to using 30200 `__builtin_saveregs' and defining the hook 30201 `TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 30202 register arguments into the stack so that all the arguments appear 30203 to have been passed consecutively on the stack. Once this is 30204 done, you can use the standard implementation of varargs that 30205 works for machines that pass all their arguments on the stack. 30206 30207 The argument ARGS_SO_FAR points to the `CUMULATIVE_ARGS' data 30208 structure, containing the values that are obtained after 30209 processing the named arguments. The arguments MODE and TYPE 30210 describe the last named argument--its machine mode and its data 30211 type as a tree node. 30212 30213 The target hook should do two things: first, push onto the stack 30214 all the argument registers _not_ used for the named arguments, and 30215 second, store the size of the data thus pushed into the 30216 `int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 30217 that you store here will serve as additional offset for setting up 30218 the stack frame. 30219 30220 Because you must generate code to push the anonymous arguments at 30221 compile time without knowing their data types, 30222 `TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 30223 have just a single category of argument register and use it 30224 uniformly for all data types. 30225 30226 If the argument SECOND_TIME is nonzero, it means that the 30227 arguments of the function are being analyzed for the second time. 30228 This happens for an inline function, which is not actually 30229 compiled until the end of the source file. The hook 30230 `TARGET_SETUP_INCOMING_VARARGS' should not generate any 30231 instructions in this case. 30232 30233 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (CUMULATIVE_ARGS 30234 *CA) 30235 Define this hook to return `true' if the location where a function 30236 argument is passed depends on whether or not it is a named 30237 argument. 30238 30239 This hook controls how the NAMED argument to `FUNCTION_ARG' is set 30240 for varargs and stdarg functions. If this hook returns `true', 30241 the NAMED argument is always true for named arguments, and false 30242 for unnamed arguments. If it returns `false', but 30243 `TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns `true', then all 30244 arguments are treated as named. Otherwise, all named arguments 30245 except the last are treated as named. 30246 30247 You need not define this hook if it always returns `false'. 30248 30249 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 30250 (CUMULATIVE_ARGS *CA) 30251 If you need to conditionally change ABIs so that one works with 30252 `TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 30253 `TARGET_SETUP_INCOMING_VARARGS' nor 30254 `TARGET_STRICT_ARGUMENT_NAMING' was defined, then define this hook 30255 to return `true' if `TARGET_SETUP_INCOMING_VARARGS' is used, 30256 `false' otherwise. Otherwise, you should not define this hook. 30257 30258 30259 File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 30260 30261 17.12 Trampolines for Nested Functions 30262 ====================================== 30263 30264 A "trampoline" is a small piece of code that is created at run time 30265 when the address of a nested function is taken. It normally resides on 30266 the stack, in the stack frame of the containing function. These macros 30267 tell GCC how to generate code to allocate and initialize a trampoline. 30268 30269 The instructions in the trampoline must do two things: load a constant 30270 address into the static chain register, and jump to the real address of 30271 the nested function. On CISC machines such as the m68k, this requires 30272 two instructions, a move immediate and a jump. Then the two addresses 30273 exist in the trampoline as word-long immediate operands. On RISC 30274 machines, it is often necessary to load each address into a register in 30275 two parts. Then pieces of each address form separate immediate 30276 operands. 30277 30278 The code generated to initialize the trampoline must store the variable 30279 parts--the static chain value and the function address--into the 30280 immediate operands of the instructions. On a CISC machine, this is 30281 simply a matter of copying each address to a memory reference at the 30282 proper offset from the start of the trampoline. On a RISC machine, it 30283 may be necessary to take out pieces of the address and store them 30284 separately. 30285 30286 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 30287 This hook is called by `assemble_trampoline_template' to output, 30288 on the stream F, assembler code for a block of data that contains 30289 the constant parts of a trampoline. This code should not include a 30290 label--the label is taken care of automatically. 30291 30292 If you do not define this hook, it means no template is needed for 30293 the target. Do not define this hook on systems where the block 30294 move code to copy the trampoline into place would be larger than 30295 the code to generate it on the spot. 30296 30297 -- Macro: TRAMPOLINE_SECTION 30298 Return the section into which the trampoline template is to be 30299 placed (*note Sections::). The default value is 30300 `readonly_data_section'. 30301 30302 -- Macro: TRAMPOLINE_SIZE 30303 A C expression for the size in bytes of the trampoline, as an 30304 integer. 30305 30306 -- Macro: TRAMPOLINE_ALIGNMENT 30307 Alignment required for trampolines, in bits. 30308 30309 If you don't define this macro, the value of `FUNCTION_ALIGNMENT' 30310 is used for aligning trampolines. 30311 30312 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 30313 rtx STATIC_CHAIN) 30314 This hook is called to initialize a trampoline. M_TRAMP is an RTX 30315 for the memory block for the trampoline; FNDECL is the 30316 `FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX 30317 for the static chain value that should be passed to the function 30318 when it is called. 30319 30320 If the target defines `TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 30321 first thing this hook should do is emit a block move into M_TRAMP 30322 from the memory block returned by `assemble_trampoline_template'. 30323 Note that the block move need only cover the constant parts of the 30324 trampoline. If the target isolates the variable parts of the 30325 trampoline to the end, not all `TRAMPOLINE_SIZE' bytes need be 30326 copied. 30327 30328 If the target requires any other actions, such as flushing caches 30329 or enabling stack execution, these actions should be performed 30330 after initializing the trampoline proper. 30331 30332 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 30333 This hook should perform any machine-specific adjustment in the 30334 address of the trampoline. Its argument contains the address of 30335 the memory block that was passed to `TARGET_TRAMPOLINE_INIT'. In 30336 case the address to be used for a function call should be 30337 different from the address at which the template was stored, the 30338 different address should be returned; otherwise ADDR should be 30339 returned unchanged. If this hook is not defined, ADDR will be 30340 used for function calls. 30341 30342 Implementing trampolines is difficult on many machines because they 30343 have separate instruction and data caches. Writing into a stack 30344 location fails to clear the memory in the instruction cache, so when 30345 the program jumps to that location, it executes the old contents. 30346 30347 Here are two possible solutions. One is to clear the relevant parts of 30348 the instruction cache whenever a trampoline is set up. The other is to 30349 make all trampolines identical, by having them jump to a standard 30350 subroutine. The former technique makes trampoline execution faster; the 30351 latter makes initialization faster. 30352 30353 To clear the instruction cache when a trampoline is initialized, define 30354 the following macro. 30355 30356 -- Macro: CLEAR_INSN_CACHE (BEG, END) 30357 If defined, expands to a C expression clearing the _instruction 30358 cache_ in the specified interval. The definition of this macro 30359 would typically be a series of `asm' statements. Both BEG and END 30360 are both pointer expressions. 30361 30362 The operating system may also require the stack to be made executable 30363 before calling the trampoline. To implement this requirement, define 30364 the following macro. 30365 30366 -- Macro: ENABLE_EXECUTE_STACK 30367 Define this macro if certain operations must be performed before 30368 executing code located on the stack. The macro should expand to a 30369 series of C file-scope constructs (e.g. functions) and provide a 30370 unique entry point named `__enable_execute_stack'. The target is 30371 responsible for emitting calls to the entry point in the code, for 30372 example from the `TARGET_TRAMPOLINE_INIT' hook. 30373 30374 To use a standard subroutine, define the following macro. In addition, 30375 you must make sure that the instructions in a trampoline fill an entire 30376 cache line with identical instructions, or else ensure that the 30377 beginning of the trampoline code is always aligned at the same point in 30378 its cache line. Look in `m68k.h' as a guide. 30379 30380 -- Macro: TRANSFER_FROM_TRAMPOLINE 30381 Define this macro if trampolines need a special subroutine to do 30382 their work. The macro should expand to a series of `asm' 30383 statements which will be compiled with GCC. They go in a library 30384 function named `__transfer_from_trampoline'. 30385 30386 If you need to avoid executing the ordinary prologue code of a 30387 compiled C function when you jump to the subroutine, you can do so 30388 by placing a special label of your own in the assembler code. Use 30389 one `asm' statement to generate an assembler label, and another to 30390 make the label global. Then trampolines can use that label to 30391 jump directly to your special assembler code. 30392 30393 30394 File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 30395 30396 17.13 Implicit Calls to Library Routines 30397 ======================================== 30398 30399 Here is an explanation of implicit calls to library routines. 30400 30401 -- Macro: DECLARE_LIBRARY_RENAMES 30402 This macro, if defined, should expand to a piece of C code that 30403 will get expanded when compiling functions for libgcc.a. It can 30404 be used to provide alternate names for GCC's internal library 30405 functions if there are ABI-mandated names that the compiler should 30406 provide. 30407 30408 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 30409 This hook should declare additional library routines or rename 30410 existing ones, using the functions `set_optab_libfunc' and 30411 `init_one_libfunc' defined in `optabs.c'. `init_optabs' calls 30412 this macro after initializing all the normal library routines. 30413 30414 The default is to do nothing. Most ports don't need to define 30415 this hook. 30416 30417 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 30418 This macro should return `true' if the library routine that 30419 implements the floating point comparison operator COMPARISON in 30420 mode MODE will return a boolean, and FALSE if it will return a 30421 tristate. 30422 30423 GCC's own floating point libraries return tristates from the 30424 comparison operators, so the default returns false always. Most 30425 ports don't need to define this macro. 30426 30427 -- Macro: TARGET_LIB_INT_CMP_BIASED 30428 This macro should evaluate to `true' if the integer comparison 30429 functions (like `__cmpdi2') return 0 to indicate that the first 30430 operand is smaller than the second, 1 to indicate that they are 30431 equal, and 2 to indicate that the first operand is greater than 30432 the second. If this macro evaluates to `false' the comparison 30433 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 30434 target uses the routines in `libgcc.a', you do not need to define 30435 this macro. 30436 30437 -- Macro: TARGET_EDOM 30438 The value of `EDOM' on the target machine, as a C integer constant 30439 expression. If you don't define this macro, GCC does not attempt 30440 to deposit the value of `EDOM' into `errno' directly. Look in 30441 `/usr/include/errno.h' to find the value of `EDOM' on your system. 30442 30443 If you do not define `TARGET_EDOM', then compiled code reports 30444 domain errors by calling the library function and letting it 30445 report the error. If mathematical functions on your system use 30446 `matherr' when there is an error, then you should leave 30447 `TARGET_EDOM' undefined so that `matherr' is used normally. 30448 30449 -- Macro: GEN_ERRNO_RTX 30450 Define this macro as a C expression to create an rtl expression 30451 that refers to the global "variable" `errno'. (On certain systems, 30452 `errno' may not actually be a variable.) If you don't define this 30453 macro, a reasonable default is used. 30454 30455 -- Macro: TARGET_C99_FUNCTIONS 30456 When this macro is nonzero, GCC will implicitly optimize `sin' 30457 calls into `sinf' and similarly for other functions defined by C99 30458 standard. The default is zero because a number of existing 30459 systems lack support for these functions in their runtime so this 30460 macro needs to be redefined to one on systems that do support the 30461 C99 runtime. 30462 30463 -- Macro: TARGET_HAS_SINCOS 30464 When this macro is nonzero, GCC will implicitly optimize calls to 30465 `sin' and `cos' with the same argument to a call to `sincos'. The 30466 default is zero. The target has to provide the following 30467 functions: 30468 void sincos(double x, double *sin, double *cos); 30469 void sincosf(float x, float *sin, float *cos); 30470 void sincosl(long double x, long double *sin, long double *cos); 30471 30472 -- Macro: NEXT_OBJC_RUNTIME 30473 Define this macro to generate code for Objective-C message sending 30474 using the calling convention of the NeXT system. This calling 30475 convention involves passing the object, the selector and the 30476 method arguments all at once to the method-lookup library function. 30477 30478 The default calling convention passes just the object and the 30479 selector to the lookup function, which returns a pointer to the 30480 method. 30481 30482 30483 File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 30484 30485 17.14 Addressing Modes 30486 ====================== 30487 30488 This is about addressing modes. 30489 30490 -- Macro: HAVE_PRE_INCREMENT 30491 -- Macro: HAVE_PRE_DECREMENT 30492 -- Macro: HAVE_POST_INCREMENT 30493 -- Macro: HAVE_POST_DECREMENT 30494 A C expression that is nonzero if the machine supports 30495 pre-increment, pre-decrement, post-increment, or post-decrement 30496 addressing respectively. 30497 30498 -- Macro: HAVE_PRE_MODIFY_DISP 30499 -- Macro: HAVE_POST_MODIFY_DISP 30500 A C expression that is nonzero if the machine supports pre- or 30501 post-address side-effect generation involving constants other than 30502 the size of the memory operand. 30503 30504 -- Macro: HAVE_PRE_MODIFY_REG 30505 -- Macro: HAVE_POST_MODIFY_REG 30506 A C expression that is nonzero if the machine supports pre- or 30507 post-address side-effect generation involving a register 30508 displacement. 30509 30510 -- Macro: CONSTANT_ADDRESS_P (X) 30511 A C expression that is 1 if the RTX X is a constant which is a 30512 valid address. On most machines the default definition of 30513 `(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 30514 but a few machines are more restrictive as to which constant 30515 addresses are supported. 30516 30517 -- Macro: CONSTANT_P (X) 30518 `CONSTANT_P', which is defined by target-independent code, accepts 30519 integer-values expressions whose values are not explicitly known, 30520 such as `symbol_ref', `label_ref', and `high' expressions and 30521 `const' arithmetic expressions, in addition to `const_int' and 30522 `const_double' expressions. 30523 30524 -- Macro: MAX_REGS_PER_ADDRESS 30525 A number, the maximum number of registers that can appear in a 30526 valid memory address. Note that it is up to you to specify a 30527 value equal to the maximum number that 30528 `TARGET_LEGITIMATE_ADDRESS_P' would ever accept. 30529 30530 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (enum machine_mode 30531 MODE, rtx X, bool STRICT) 30532 A function that returns whether X (an RTX) is a legitimate memory 30533 address on the target machine for a memory operand of mode MODE. 30534 30535 Legitimate addresses are defined in two variants: a strict variant 30536 and a non-strict one. The STRICT parameter chooses which variant 30537 is desired by the caller. 30538 30539 The strict variant is used in the reload pass. It must be defined 30540 so that any pseudo-register that has not been allocated a hard 30541 register is considered a memory reference. This is because in 30542 contexts where some kind of register is required, a 30543 pseudo-register with no hard register must be rejected. For 30544 non-hard registers, the strict variant should look up the 30545 `reg_renumber' array; it should then proceed using the hard 30546 register number in the array, or treat the pseudo as a memory 30547 reference if the array holds `-1'. 30548 30549 The non-strict variant is used in other passes. It must be 30550 defined to accept all pseudo-registers in every context where some 30551 kind of register is required. 30552 30553 Normally, constant addresses which are the sum of a `symbol_ref' 30554 and an integer are stored inside a `const' RTX to mark them as 30555 constant. Therefore, there is no need to recognize such sums 30556 specifically as legitimate addresses. Normally you would simply 30557 recognize any `const' as legitimate. 30558 30559 Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant 30560 sums that are not marked with `const'. It assumes that a naked 30561 `plus' indicates indexing. If so, then you _must_ reject such 30562 naked constant sums as illegitimate addresses, so that none of 30563 them will be given to `PRINT_OPERAND_ADDRESS'. 30564 30565 On some machines, whether a symbolic address is legitimate depends 30566 on the section that the address refers to. On these machines, 30567 define the target hook `TARGET_ENCODE_SECTION_INFO' to store the 30568 information into the `symbol_ref', and then check for it here. 30569 When you see a `const', you will have to look inside it to find the 30570 `symbol_ref' in order to determine the section. *Note Assembler 30571 Format::. 30572 30573 Some ports are still using a deprecated legacy substitute for this 30574 hook, the `GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 30575 syntax: 30576 30577 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 30578 30579 and should `goto LABEL' if the address X is a valid address on the 30580 target machine for a memory operand of mode MODE. 30581 30582 Compiler source files that want to use the strict variant of this 30583 macro define the macro `REG_OK_STRICT'. You should use an `#ifdef 30584 REG_OK_STRICT' conditional to define the strict variant in that 30585 case and the non-strict variant otherwise. 30586 30587 Using the hook is usually simpler because it limits the number of 30588 files that are recompiled when changes are made. 30589 30590 -- Macro: TARGET_MEM_CONSTRAINT 30591 A single character to be used instead of the default `'m'' 30592 character for general memory addresses. This defines the 30593 constraint letter which matches the memory addresses accepted by 30594 `TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 30595 support new address formats in your back end without changing the 30596 semantics of the `'m'' constraint. This is necessary in order to 30597 preserve functionality of inline assembly constructs using the 30598 `'m'' constraint. 30599 30600 -- Macro: FIND_BASE_TERM (X) 30601 A C expression to determine the base term of address X, or to 30602 provide a simplified version of X from which `alias.c' can easily 30603 find the base term. This macro is used in only two places: 30604 `find_base_value' and `find_base_term' in `alias.c'. 30605 30606 It is always safe for this macro to not be defined. It exists so 30607 that alias analysis can understand machine-dependent addresses. 30608 30609 The typical use of this macro is to handle addresses containing a 30610 label_ref or symbol_ref within an UNSPEC. 30611 30612 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, enum 30613 machine_mode MODE) 30614 This hook is given an invalid memory address X for an operand of 30615 mode MODE and should try to return a valid memory address. 30616 30617 X will always be the result of a call to `break_out_memory_refs', 30618 and OLDX will be the operand that was given to that function to 30619 produce X. 30620 30621 The code of the hook should not alter the substructure of X. If 30622 it transforms X into a more legitimate form, it should return the 30623 new X. 30624 30625 It is not necessary for this hook to come up with a legitimate 30626 address. The compiler has standard ways of doing so in all cases. 30627 In fact, it is safe to omit this hook or make it return X if it 30628 cannot find a valid way to legitimize the address. But often a 30629 machine-dependent strategy can generate better code. 30630 30631 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 30632 WIN) 30633 A C compound statement that attempts to replace X, which is an 30634 address that needs reloading, with a valid memory address for an 30635 operand of mode MODE. WIN will be a C statement label elsewhere 30636 in the code. It is not necessary to define this macro, but it 30637 might be useful for performance reasons. 30638 30639 For example, on the i386, it is sometimes possible to use a single 30640 reload register instead of two by reloading a sum of two pseudo 30641 registers into a register. On the other hand, for number of RISC 30642 processors offsets are limited so that often an intermediate 30643 address needs to be generated in order to address a stack slot. 30644 By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 30645 intermediate addresses generated for adjacent some stack slots can 30646 be made identical, and thus be shared. 30647 30648 _Note_: This macro should be used with caution. It is necessary 30649 to know something of how reload works in order to effectively use 30650 this, and it is quite easy to produce macros that build in too 30651 much knowledge of reload internals. 30652 30653 _Note_: This macro must be able to reload an address created by a 30654 previous invocation of this macro. If it fails to handle such 30655 addresses then the compiler may generate incorrect code or abort. 30656 30657 The macro definition should use `push_reload' to indicate parts 30658 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 30659 suitable to be passed unaltered to `push_reload'. 30660 30661 The code generated by this macro must not alter the substructure of 30662 X. If it transforms X into a more legitimate form, it should 30663 assign X (which will always be a C variable) a new value. This 30664 also applies to parts that you change indirectly by calling 30665 `push_reload'. 30666 30667 The macro definition may use `strict_memory_address_p' to test if 30668 the address has become legitimate. 30669 30670 If you want to change only a part of X, one standard way of doing 30671 this is to use `copy_rtx'. Note, however, that it unshares only a 30672 single level of rtl. Thus, if the part to be changed is not at the 30673 top level, you'll need to replace first the top level. It is not 30674 necessary for this macro to come up with a legitimate address; 30675 but often a machine-dependent strategy can generate better code. 30676 30677 -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR) 30678 This hook returns `true' if memory address ADDR can have different 30679 meanings depending on the machine mode of the memory reference it 30680 is used for or if the address is valid for some modes but not 30681 others. 30682 30683 Autoincrement and autodecrement addresses typically have 30684 mode-dependent effects because the amount of the increment or 30685 decrement is the size of the operand being addressed. Some 30686 machines have other mode-dependent addresses. Many RISC machines 30687 have no mode-dependent addresses. 30688 30689 You may assume that ADDR is a valid address for the machine. 30690 30691 The default version of this hook returns `false'. 30692 30693 -- Macro: GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL) 30694 A C statement or compound statement with a conditional `goto 30695 LABEL;' executed if memory address X (an RTX) can have different 30696 meanings depending on the machine mode of the memory reference it 30697 is used for or if the address is valid for some modes but not 30698 others. 30699 30700 Autoincrement and autodecrement addresses typically have 30701 mode-dependent effects because the amount of the increment or 30702 decrement is the size of the operand being addressed. Some 30703 machines have other mode-dependent addresses. Many RISC machines 30704 have no mode-dependent addresses. 30705 30706 You may assume that ADDR is a valid address for the machine. 30707 30708 These are obsolete macros, replaced by the 30709 `TARGET_MODE_DEPENDENT_ADDRESS_P' target hook. 30710 30711 -- Macro: LEGITIMATE_CONSTANT_P (X) 30712 A C expression that is nonzero if X is a legitimate constant for 30713 an immediate operand on the target machine. You can assume that X 30714 satisfies `CONSTANT_P', so you need not check this. In fact, `1' 30715 is a suitable definition for this macro on machines where anything 30716 `CONSTANT_P' is valid. 30717 30718 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 30719 This hook is used to undo the possibly obfuscating effects of the 30720 `LEGITIMIZE_ADDRESS' and `LEGITIMIZE_RELOAD_ADDRESS' target 30721 macros. Some backend implementations of these macros wrap symbol 30722 references inside an `UNSPEC' rtx to represent PIC or similar 30723 addressing modes. This target hook allows GCC's optimizers to 30724 understand the semantics of these opaque `UNSPEC's by converting 30725 them back into their original form. 30726 30727 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (rtx X) 30728 This hook should return true if X is of a form that cannot (or 30729 should not) be spilled to the constant pool. The default version 30730 of this hook returns false. 30731 30732 The primary reason to define this hook is to prevent reload from 30733 deciding that a non-legitimate constant would be better reloaded 30734 from the constant pool instead of spilling and reloading a register 30735 holding the constant. This restriction is often true of addresses 30736 of TLS symbols for various targets. 30737 30738 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (enum 30739 machine_mode MODE, const_rtx X) 30740 This hook should return true if pool entries for constant X can be 30741 placed in an `object_block' structure. MODE is the mode of X. 30742 30743 The default version returns false for all constants. 30744 30745 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (unsigned FN, bool 30746 MD_FN, bool SQRT) 30747 This hook should return the DECL of a function that implements 30748 reciprocal of the builtin function with builtin function code FN, 30749 or `NULL_TREE' if such a function is not available. MD_FN is true 30750 when FN is a code of a machine-dependent builtin function. When 30751 SQRT is true, additional optimizations that apply only to the 30752 reciprocal of a square root function are performed, and only 30753 reciprocals of `sqrt' function are valid. 30754 30755 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 30756 This hook should return the DECL of a function F that given an 30757 address ADDR as an argument returns a mask M that can be used to 30758 extract from two vectors the relevant data that resides in ADDR in 30759 case ADDR is not properly aligned. 30760 30761 The autovectorizer, when vectorizing a load operation from an 30762 address ADDR that may be unaligned, will generate two vector loads 30763 from the two aligned addresses around ADDR. It then generates a 30764 `REALIGN_LOAD' operation to extract the relevant data from the two 30765 loaded vectors. The first two arguments to `REALIGN_LOAD', V1 and 30766 V2, are the two vectors, each of size VS, and the third argument, 30767 OFF, defines how the data will be extracted from these two 30768 vectors: if OFF is 0, then the returned vector is V2; otherwise, 30769 the returned vector is composed from the last VS-OFF elements of 30770 V1 concatenated to the first OFF elements of V2. 30771 30772 If this hook is defined, the autovectorizer will generate a call 30773 to F (using the DECL tree that this hook returns) and will use the 30774 return value of F as the argument OFF to `REALIGN_LOAD'. 30775 Therefore, the mask M returned by F should comply with the 30776 semantics expected by `REALIGN_LOAD' described above. If this 30777 hook is not defined, then ADDR will be used as the argument OFF to 30778 `REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 30779 will be considered. 30780 30781 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN (tree X) 30782 This hook should return the DECL of a function F that implements 30783 widening multiplication of the even elements of two input vectors 30784 of type X. 30785 30786 If this hook is defined, the autovectorizer will use it along with 30787 the `TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD' target hook when 30788 vectorizing widening multiplication in cases that the order of the 30789 results does not have to be preserved (e.g. used only by a 30790 reduction computation). Otherwise, the `widen_mult_hi/lo' idioms 30791 will be used. 30792 30793 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD (tree X) 30794 This hook should return the DECL of a function F that implements 30795 widening multiplication of the odd elements of two input vectors 30796 of type X. 30797 30798 If this hook is defined, the autovectorizer will use it along with 30799 the `TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN' target hook when 30800 vectorizing widening multiplication in cases that the order of the 30801 results does not have to be preserved (e.g. used only by a 30802 reduction computation). Otherwise, the `widen_mult_hi/lo' idioms 30803 will be used. 30804 30805 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum 30806 vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN) 30807 Returns cost of different scalar or vector statements for 30808 vectorization cost model. For vector memory operations the cost 30809 may depend on type (VECTYPE) and misalignment value (MISALIGN). 30810 30811 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 30812 (const_tree TYPE, bool IS_PACKED) 30813 Return true if vector alignment is reachable (by peeling N 30814 iterations) for the given type. 30815 30816 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VEC_PERM (tree TYPE, 30817 tree *MASK_ELEMENT_TYPE) 30818 Target builtin that implements vector permute. 30819 30820 -- Target Hook: bool TARGET_VECTORIZE_BUILTIN_VEC_PERM_OK (tree 30821 VEC_TYPE, tree MASK) 30822 Return true if a vector created for `builtin_vec_perm' is valid. 30823 30824 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned 30825 CODE, tree DEST_TYPE, tree SRC_TYPE) 30826 This hook should return the DECL of a function that implements 30827 conversion of the input vector of type SRC_TYPE to type DEST_TYPE. 30828 The value of CODE is one of the enumerators in `enum tree_code' and 30829 specifies how the conversion is to be applied (truncation, 30830 rounding, etc.). 30831 30832 If this hook is defined, the autovectorizer will use the 30833 `TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing 30834 conversion. Otherwise, it will return `NULL_TREE'. 30835 30836 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION 30837 (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 30838 This hook should return the decl of a function that implements the 30839 vectorized variant of the builtin function with builtin function 30840 code CODE or `NULL_TREE' if such a function is not available. The 30841 value of FNDECL is the builtin function declaration. The return 30842 type of the vectorized function shall be of vector type 30843 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 30844 30845 -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT 30846 (enum machine_mode MODE, const_tree TYPE, int MISALIGNMENT, 30847 bool IS_PACKED) 30848 This hook should return true if the target supports misaligned 30849 vector store/load of a specific factor denoted in the MISALIGNMENT 30850 parameter. The vector store/load should be of machine mode MODE 30851 and the elements in the vectors should be of type TYPE. IS_PACKED 30852 parameter is true if the memory access is defined in a packed 30853 struct. 30854 30855 -- Target Hook: enum machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE 30856 (enum machine_mode MODE) 30857 This hook should return the preferred mode for vectorizing scalar 30858 mode MODE. The default is equal to `word_mode', because the 30859 vectorizer can do some transformations even in absence of 30860 specialized SIMD hardware. 30861 30862 -- Target Hook: unsigned int 30863 TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES (void) 30864 This hook should return a mask of sizes that should be iterated 30865 over after trying to autovectorize using the vector size derived 30866 from the mode returned by `TARGET_VECTORIZE_PREFERRED_SIMD_MODE'. 30867 The default is zero which means to not iterate over other vector 30868 sizes. 30869 30870 30871 File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 30872 30873 17.15 Anchored Addresses 30874 ======================== 30875 30876 GCC usually addresses every static object as a separate entity. For 30877 example, if we have: 30878 30879 static int a, b, c; 30880 int foo (void) { return a + b + c; } 30881 30882 the code for `foo' will usually calculate three separate symbolic 30883 addresses: those of `a', `b' and `c'. On some targets, it would be 30884 better to calculate just one symbolic address and access the three 30885 variables relative to it. The equivalent pseudocode would be something 30886 like: 30887 30888 int foo (void) 30889 { 30890 register int *xr = &x; 30891 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 30892 } 30893 30894 (which isn't valid C). We refer to shared addresses like `x' as 30895 "section anchors". Their use is controlled by `-fsection-anchors'. 30896 30897 The hooks below describe the target properties that GCC needs to know 30898 in order to make effective use of section anchors. It won't use 30899 section anchors at all unless either `TARGET_MIN_ANCHOR_OFFSET' or 30900 `TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 30901 30902 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 30903 The minimum offset that should be applied to a section anchor. On 30904 most targets, it should be the smallest offset that can be applied 30905 to a base register while still giving a legitimate address for 30906 every mode. The default value is 0. 30907 30908 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 30909 Like `TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) 30910 offset that should be applied to section anchors. The default 30911 value is 0. 30912 30913 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 30914 Write the assembly code to define section anchor X, which is a 30915 `SYMBOL_REF' for which `SYMBOL_REF_ANCHOR_P (X)' is true. The 30916 hook is called with the assembly output position set to the 30917 beginning of `SYMBOL_REF_BLOCK (X)'. 30918 30919 If `ASM_OUTPUT_DEF' is available, the hook's default definition 30920 uses it to define the symbol as `. + SYMBOL_REF_BLOCK_OFFSET (X)'. 30921 If `ASM_OUTPUT_DEF' is not available, the hook's default definition 30922 is `NULL', which disables the use of section anchors altogether. 30923 30924 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 30925 Return true if GCC should attempt to use anchors to access 30926 `SYMBOL_REF' X. You can assume `SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 30927 and `!SYMBOL_REF_ANCHOR_P (X)'. 30928 30929 The default version is correct for most targets, but you might 30930 need to intercept this hook to handle things like target-specific 30931 attributes or target-specific sections. 30932 30933 30934 File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 30935 30936 17.16 Condition Code Status 30937 =========================== 30938 30939 The macros in this section can be split in two families, according to 30940 the two ways of representing condition codes in GCC. 30941 30942 The first representation is the so called `(cc0)' representation 30943 (*note Jump Patterns::), where all instructions can have an implicit 30944 clobber of the condition codes. The second is the condition code 30945 register representation, which provides better schedulability for 30946 architectures that do have a condition code register, but on which most 30947 instructions do not affect it. The latter category includes most RISC 30948 machines. 30949 30950 The implicit clobbering poses a strong restriction on the placement of 30951 the definition and use of the condition code, which need to be in 30952 adjacent insns for machines using `(cc0)'. This can prevent important 30953 optimizations on some machines. For example, on the IBM RS/6000, there 30954 is a delay for taken branches unless the condition code register is set 30955 three instructions earlier than the conditional branch. The instruction 30956 scheduler cannot perform this optimization if it is not permitted to 30957 separate the definition and use of the condition code register. 30958 30959 For this reason, it is possible and suggested to use a register to 30960 represent the condition code for new ports. If there is a specific 30961 condition code register in the machine, use a hard register. If the 30962 condition code or comparison result can be placed in any general 30963 register, or if there are multiple condition registers, use a pseudo 30964 register. Registers used to store the condition code value will 30965 usually have a mode that is in class `MODE_CC'. 30966 30967 Alternatively, you can use `BImode' if the comparison operator is 30968 specified already in the compare instruction. In this case, you are not 30969 interested in most macros in this section. 30970 30971 * Menu: 30972 30973 * CC0 Condition Codes:: Old style representation of condition codes. 30974 * MODE_CC Condition Codes:: Modern representation of condition codes. 30975 * Cond Exec Macros:: Macros to control conditional execution. 30976 30977 30978 File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 30979 30980 17.16.1 Representation of condition codes using `(cc0)' 30981 ------------------------------------------------------- 30982 30983 The file `conditions.h' defines a variable `cc_status' to describe how 30984 the condition code was computed (in case the interpretation of the 30985 condition code depends on the instruction that it was set by). This 30986 variable contains the RTL expressions on which the condition code is 30987 currently based, and several standard flags. 30988 30989 Sometimes additional machine-specific flags must be defined in the 30990 machine description header file. It can also add additional 30991 machine-specific information by defining `CC_STATUS_MDEP'. 30992 30993 -- Macro: CC_STATUS_MDEP 30994 C code for a data type which is used for declaring the `mdep' 30995 component of `cc_status'. It defaults to `int'. 30996 30997 This macro is not used on machines that do not use `cc0'. 30998 30999 -- Macro: CC_STATUS_MDEP_INIT 31000 A C expression to initialize the `mdep' field to "empty". The 31001 default definition does nothing, since most machines don't use the 31002 field anyway. If you want to use the field, you should probably 31003 define this macro to initialize it. 31004 31005 This macro is not used on machines that do not use `cc0'. 31006 31007 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 31008 A C compound statement to set the components of `cc_status' 31009 appropriately for an insn INSN whose body is EXP. It is this 31010 macro's responsibility to recognize insns that set the condition 31011 code as a byproduct of other activity as well as those that 31012 explicitly set `(cc0)'. 31013 31014 This macro is not used on machines that do not use `cc0'. 31015 31016 If there are insns that do not set the condition code but do alter 31017 other machine registers, this macro must check to see whether they 31018 invalidate the expressions that the condition code is recorded as 31019 reflecting. For example, on the 68000, insns that store in address 31020 registers do not set the condition code, which means that usually 31021 `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns. 31022 But suppose that the previous insn set the condition code based on 31023 location `a4@(102)' and the current insn stores a new value in 31024 `a4'. Although the condition code is not changed by this, it will 31025 no longer be true that it reflects the contents of `a4@(102)'. 31026 Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case 31027 to say that nothing is known about the condition code value. 31028 31029 The definition of `NOTICE_UPDATE_CC' must be prepared to deal with 31030 the results of peephole optimization: insns whose patterns are 31031 `parallel' RTXs containing various `reg', `mem' or constants which 31032 are just the operands. The RTL structure of these insns is not 31033 sufficient to indicate what the insns actually do. What 31034 `NOTICE_UPDATE_CC' should do when it sees one is just to run 31035 `CC_STATUS_INIT'. 31036 31037 A possible definition of `NOTICE_UPDATE_CC' is to call a function 31038 that looks at an attribute (*note Insn Attributes::) named, for 31039 example, `cc'. This avoids having detailed information about 31040 patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. 31041 31042 31043 File: gccint.info, Node: MODE_CC Condition Codes, Next: Cond Exec Macros, Prev: CC0 Condition Codes, Up: Condition Code 31044 31045 17.16.2 Representation of condition codes using registers 31046 --------------------------------------------------------- 31047 31048 -- Macro: SELECT_CC_MODE (OP, X, Y) 31049 On many machines, the condition code may be produced by other 31050 instructions than compares, for example the branch can use 31051 directly the condition code set by a subtract instruction. 31052 However, on some machines when the condition code is set this way 31053 some bits (such as the overflow bit) are not set in the same way 31054 as a test instruction, so that a different branch instruction must 31055 be used for some conditional branches. When this happens, use the 31056 machine mode of the condition code register to record different 31057 formats of the condition code register. Modes can also be used to 31058 record which compare instruction (e.g. a signed or an unsigned 31059 comparison) produced the condition codes. 31060 31061 If other modes than `CCmode' are required, add them to 31062 `MACHINE-modes.def' and define `SELECT_CC_MODE' to choose a mode 31063 given an operand of a compare. This is needed because the modes 31064 have to be chosen not only during RTL generation but also, for 31065 example, by instruction combination. The result of 31066 `SELECT_CC_MODE' should be consistent with the mode used in the 31067 patterns; for example to support the case of the add on the SPARC 31068 discussed above, we have the pattern 31069 31070 (define_insn "" 31071 [(set (reg:CC_NOOV 0) 31072 (compare:CC_NOOV 31073 (plus:SI (match_operand:SI 0 "register_operand" "%r") 31074 (match_operand:SI 1 "arith_operand" "rI")) 31075 (const_int 0)))] 31076 "" 31077 "...") 31078 31079 together with a `SELECT_CC_MODE' that returns `CC_NOOVmode' for 31080 comparisons whose argument is a `plus': 31081 31082 #define SELECT_CC_MODE(OP,X,Y) \ 31083 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 31084 ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \ 31085 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 31086 || GET_CODE (X) == NEG) \ 31087 ? CC_NOOVmode : CCmode)) 31088 31089 Another reason to use modes is to retain information on which 31090 operands were used by the comparison; see `REVERSIBLE_CC_MODE' 31091 later in this section. 31092 31093 You should define this macro if and only if you define extra CC 31094 modes in `MACHINE-modes.def'. 31095 31096 -- Macro: CANONICALIZE_COMPARISON (CODE, OP0, OP1) 31097 On some machines not all possible comparisons are defined, but you 31098 can convert an invalid comparison into a valid one. For example, 31099 the Alpha does not have a `GT' comparison, but you can use an `LT' 31100 comparison instead and swap the order of the operands. 31101 31102 On such machines, define this macro to be a C statement to do any 31103 required conversions. CODE is the initial comparison code and OP0 31104 and OP1 are the left and right operands of the comparison, 31105 respectively. You should modify CODE, OP0, and OP1 as required. 31106 31107 GCC will not assume that the comparison resulting from this macro 31108 is valid but will see if the resulting insn matches a pattern in 31109 the `md' file. 31110 31111 You need not define this macro if it would never change the 31112 comparison code or operands. 31113 31114 -- Macro: REVERSIBLE_CC_MODE (MODE) 31115 A C expression whose value is one if it is always safe to reverse a 31116 comparison whose mode is MODE. If `SELECT_CC_MODE' can ever 31117 return MODE for a floating-point inequality comparison, then 31118 `REVERSIBLE_CC_MODE (MODE)' must be zero. 31119 31120 You need not define this macro if it would always returns zero or 31121 if the floating-point format is anything other than 31122 `IEEE_FLOAT_FORMAT'. For example, here is the definition used on 31123 the SPARC, where floating-point inequality comparisons are always 31124 given `CCFPEmode': 31125 31126 #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode) 31127 31128 -- Macro: REVERSE_CONDITION (CODE, MODE) 31129 A C expression whose value is reversed condition code of the CODE 31130 for comparison done in CC_MODE MODE. The macro is used only in 31131 case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 31132 case machine has some non-standard way how to reverse certain 31133 conditionals. For instance in case all floating point conditions 31134 are non-trapping, compiler may freely convert unordered compares 31135 to ordered one. Then definition may look like: 31136 31137 #define REVERSE_CONDITION(CODE, MODE) \ 31138 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 31139 : reverse_condition_maybe_unordered (CODE)) 31140 31141 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 31142 *P1, unsigned int *P2) 31143 On targets which do not use `(cc0)', and which use a hard register 31144 rather than a pseudo-register to hold condition codes, the regular 31145 CSE passes are often not able to identify cases in which the hard 31146 register is set to a common value. Use this hook to enable a 31147 small pass which optimizes such cases. This hook should return 31148 true to enable this pass, and it should set the integers to which 31149 its arguments point to the hard register numbers used for 31150 condition codes. When there is only one such register, as is true 31151 on most systems, the integer pointed to by P2 should be set to 31152 `INVALID_REGNUM'. 31153 31154 The default version of this hook returns false. 31155 31156 -- Target Hook: enum machine_mode TARGET_CC_MODES_COMPATIBLE (enum 31157 machine_mode M1, enum machine_mode M2) 31158 On targets which use multiple condition code modes in class 31159 `MODE_CC', it is sometimes the case that a comparison can be 31160 validly done in more than one mode. On such a system, define this 31161 target hook to take two mode arguments and to return a mode in 31162 which both comparisons may be validly done. If there is no such 31163 mode, return `VOIDmode'. 31164 31165 The default version of this hook checks whether the modes are the 31166 same. If they are, it returns that mode. If they are different, 31167 it returns `VOIDmode'. 31168 31169 31170 File: gccint.info, Node: Cond Exec Macros, Prev: MODE_CC Condition Codes, Up: Condition Code 31171 31172 17.16.3 Macros to control conditional execution 31173 ----------------------------------------------- 31174 31175 There is one macro that may need to be defined for targets supporting 31176 conditional execution, independent of how they represent conditional 31177 branches. 31178 31179 -- Macro: REVERSE_CONDEXEC_PREDICATES_P (OP1, OP2) 31180 A C expression that returns true if the conditional execution 31181 predicate OP1, a comparison operation, is the inverse of OP2 and 31182 vice versa. Define this to return 0 if the target has conditional 31183 execution predicates that cannot be reversed safely. There is no 31184 need to validate that the arguments of op1 and op2 are the same, 31185 this is done separately. If no expansion is specified, this macro 31186 is defined as follows: 31187 31188 #define REVERSE_CONDEXEC_PREDICATES_P (x, y) \ 31189 (GET_CODE ((x)) == reversed_comparison_code ((y), NULL)) 31190 31191 31192 File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 31193 31194 17.17 Describing Relative Costs of Operations 31195 ============================================= 31196 31197 These macros let you describe the relative speed of various operations 31198 on the target machine. 31199 31200 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 31201 A C expression for the cost of moving data of mode MODE from a 31202 register in class FROM to one in class TO. The classes are 31203 expressed using the enumeration values such as `GENERAL_REGS'. A 31204 value of 2 is the default; other values are interpreted relative to 31205 that. 31206 31207 It is not required that the cost always equal 2 when FROM is the 31208 same as TO; on some machines it is expensive to move between 31209 registers if they are not general registers. 31210 31211 If reload sees an insn consisting of a single `set' between two 31212 hard registers, and if `REGISTER_MOVE_COST' applied to their 31213 classes returns a value of 2, reload does not check to ensure that 31214 the constraints of the insn are met. Setting a cost of other than 31215 2 will allow reload to verify that the constraints are met. You 31216 should do this if the `movM' pattern's constraints do not allow 31217 such copying. 31218 31219 These macros are obsolete, new ports should use the target hook 31220 `TARGET_REGISTER_MOVE_COST' instead. 31221 31222 -- Target Hook: int TARGET_REGISTER_MOVE_COST (enum machine_mode MODE, 31223 reg_class_t FROM, reg_class_t TO) 31224 This target hook should return the cost of moving data of mode MODE 31225 from a register in class FROM to one in class TO. The classes are 31226 expressed using the enumeration values such as `GENERAL_REGS'. A 31227 value of 2 is the default; other values are interpreted relative to 31228 that. 31229 31230 It is not required that the cost always equal 2 when FROM is the 31231 same as TO; on some machines it is expensive to move between 31232 registers if they are not general registers. 31233 31234 If reload sees an insn consisting of a single `set' between two 31235 hard registers, and if `TARGET_REGISTER_MOVE_COST' applied to their 31236 classes returns a value of 2, reload does not check to ensure that 31237 the constraints of the insn are met. Setting a cost of other than 31238 2 will allow reload to verify that the constraints are met. You 31239 should do this if the `movM' pattern's constraints do not allow 31240 such copying. 31241 31242 The default version of this function returns 2. 31243 31244 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 31245 A C expression for the cost of moving data of mode MODE between a 31246 register of class CLASS and memory; IN is zero if the value is to 31247 be written to memory, nonzero if it is to be read in. This cost 31248 is relative to those in `REGISTER_MOVE_COST'. If moving between 31249 registers and memory is more expensive than between two registers, 31250 you should define this macro to express the relative cost. 31251 31252 If you do not define this macro, GCC uses a default cost of 4 plus 31253 the cost of copying via a secondary reload register, if one is 31254 needed. If your machine requires a secondary reload register to 31255 copy between memory and a register of CLASS but the reload 31256 mechanism is more complex than copying via an intermediate, define 31257 this macro to reflect the actual cost of the move. 31258 31259 GCC defines the function `memory_move_secondary_cost' if secondary 31260 reloads are needed. It computes the costs due to copying via a 31261 secondary register. If your machine copies from memory using a 31262 secondary register in the conventional way but the default base 31263 value of 4 is not correct for your machine, define this macro to 31264 add some other value to the result of that function. The 31265 arguments to that function are the same as to this macro. 31266 31267 These macros are obsolete, new ports should use the target hook 31268 `TARGET_MEMORY_MOVE_COST' instead. 31269 31270 -- Target Hook: int TARGET_MEMORY_MOVE_COST (enum machine_mode MODE, 31271 reg_class_t RCLASS, bool IN) 31272 This target hook should return the cost of moving data of mode MODE 31273 between a register of class RCLASS and memory; IN is `false' if 31274 the value is to be written to memory, `true' if it is to be read 31275 in. This cost is relative to those in `TARGET_REGISTER_MOVE_COST'. 31276 If moving between registers and memory is more expensive than 31277 between two registers, you should add this target hook to express 31278 the relative cost. 31279 31280 If you do not add this target hook, GCC uses a default cost of 4 31281 plus the cost of copying via a secondary reload register, if one is 31282 needed. If your machine requires a secondary reload register to 31283 copy between memory and a register of RCLASS but the reload 31284 mechanism is more complex than copying via an intermediate, use 31285 this target hook to reflect the actual cost of the move. 31286 31287 GCC defines the function `memory_move_secondary_cost' if secondary 31288 reloads are needed. It computes the costs due to copying via a 31289 secondary register. If your machine copies from memory using a 31290 secondary register in the conventional way but the default base 31291 value of 4 is not correct for your machine, use this target hook 31292 to add some other value to the result of that function. The 31293 arguments to that function are the same as to this target hook. 31294 31295 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 31296 A C expression for the cost of a branch instruction. A value of 1 31297 is the default; other values are interpreted relative to that. 31298 Parameter SPEED_P is true when the branch in question should be 31299 optimized for speed. When it is false, `BRANCH_COST' should 31300 return a value optimal for code size rather than performance. 31301 PREDICTABLE_P is true for well-predicted branches. On many 31302 architectures the `BRANCH_COST' can be reduced then. 31303 31304 Here are additional macros which do not specify precise relative costs, 31305 but only that certain actions are more expensive than GCC would 31306 ordinarily expect. 31307 31308 -- Macro: SLOW_BYTE_ACCESS 31309 Define this macro as a C expression which is nonzero if accessing 31310 less than a word of memory (i.e. a `char' or a `short') is no 31311 faster than accessing a word of memory, i.e., if such access 31312 require more than one instruction or if there is no difference in 31313 cost between byte and (aligned) word loads. 31314 31315 When this macro is not defined, the compiler will access a field by 31316 finding the smallest containing object; when it is defined, a 31317 fullword load will be used if alignment permits. Unless bytes 31318 accesses are faster than word accesses, using word accesses is 31319 preferable since it may eliminate subsequent memory access if 31320 subsequent accesses occur to other fields in the same word of the 31321 structure, but to different bytes. 31322 31323 -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT) 31324 Define this macro to be the value 1 if memory accesses described 31325 by the MODE and ALIGNMENT parameters have a cost many times greater 31326 than aligned accesses, for example if they are emulated in a trap 31327 handler. 31328 31329 When this macro is nonzero, the compiler will act as if 31330 `STRICT_ALIGNMENT' were nonzero when generating code for block 31331 moves. This can cause significantly more instructions to be 31332 produced. Therefore, do not set this macro nonzero if unaligned 31333 accesses only add a cycle or two to the time for a memory access. 31334 31335 If the value of this macro is always zero, it need not be defined. 31336 If this macro is defined, it should produce a nonzero value when 31337 `STRICT_ALIGNMENT' is nonzero. 31338 31339 -- Macro: MOVE_RATIO (SPEED) 31340 The threshold of number of scalar memory-to-memory move insns, 31341 _below_ which a sequence of insns should be generated instead of a 31342 string move insn or a library call. Increasing the value will 31343 always make code faster, but eventually incurs high cost in 31344 increased code size. 31345 31346 Note that on machines where the corresponding move insn is a 31347 `define_expand' that emits a sequence of insns, this macro counts 31348 the number of such sequences. 31349 31350 The parameter SPEED is true if the code is currently being 31351 optimized for speed rather than size. 31352 31353 If you don't define this, a reasonable default is used. 31354 31355 -- Macro: MOVE_BY_PIECES_P (SIZE, ALIGNMENT) 31356 A C expression used to determine whether `move_by_pieces' will be 31357 used to copy a chunk of memory, or whether some other block move 31358 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 31359 returns less than `MOVE_RATIO'. 31360 31361 -- Macro: MOVE_MAX_PIECES 31362 A C expression used by `move_by_pieces' to determine the largest 31363 unit a load or store used to copy memory is. Defaults to 31364 `MOVE_MAX'. 31365 31366 -- Macro: CLEAR_RATIO (SPEED) 31367 The threshold of number of scalar move insns, _below_ which a 31368 sequence of insns should be generated to clear memory instead of a 31369 string clear insn or a library call. Increasing the value will 31370 always make code faster, but eventually incurs high cost in 31371 increased code size. 31372 31373 The parameter SPEED is true if the code is currently being 31374 optimized for speed rather than size. 31375 31376 If you don't define this, a reasonable default is used. 31377 31378 -- Macro: CLEAR_BY_PIECES_P (SIZE, ALIGNMENT) 31379 A C expression used to determine whether `clear_by_pieces' will be 31380 used to clear a chunk of memory, or whether some other block clear 31381 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 31382 returns less than `CLEAR_RATIO'. 31383 31384 -- Macro: SET_RATIO (SPEED) 31385 The threshold of number of scalar move insns, _below_ which a 31386 sequence of insns should be generated to set memory to a constant 31387 value, instead of a block set insn or a library call. Increasing 31388 the value will always make code faster, but eventually incurs high 31389 cost in increased code size. 31390 31391 The parameter SPEED is true if the code is currently being 31392 optimized for speed rather than size. 31393 31394 If you don't define this, it defaults to the value of `MOVE_RATIO'. 31395 31396 -- Macro: SET_BY_PIECES_P (SIZE, ALIGNMENT) 31397 A C expression used to determine whether `store_by_pieces' will be 31398 used to set a chunk of memory to a constant value, or whether some 31399 other mechanism will be used. Used by `__builtin_memset' when 31400 storing values other than constant zero. Defaults to 1 if 31401 `move_by_pieces_ninsns' returns less than `SET_RATIO'. 31402 31403 -- Macro: STORE_BY_PIECES_P (SIZE, ALIGNMENT) 31404 A C expression used to determine whether `store_by_pieces' will be 31405 used to set a chunk of memory to a constant string value, or 31406 whether some other mechanism will be used. Used by 31407 `__builtin_strcpy' when called with a constant source string. 31408 Defaults to 1 if `move_by_pieces_ninsns' returns less than 31409 `MOVE_RATIO'. 31410 31411 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 31412 A C expression used to determine whether a load postincrement is a 31413 good thing to use for a given mode. Defaults to the value of 31414 `HAVE_POST_INCREMENT'. 31415 31416 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 31417 A C expression used to determine whether a load postdecrement is a 31418 good thing to use for a given mode. Defaults to the value of 31419 `HAVE_POST_DECREMENT'. 31420 31421 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 31422 A C expression used to determine whether a load preincrement is a 31423 good thing to use for a given mode. Defaults to the value of 31424 `HAVE_PRE_INCREMENT'. 31425 31426 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 31427 A C expression used to determine whether a load predecrement is a 31428 good thing to use for a given mode. Defaults to the value of 31429 `HAVE_PRE_DECREMENT'. 31430 31431 -- Macro: USE_STORE_POST_INCREMENT (MODE) 31432 A C expression used to determine whether a store postincrement is 31433 a good thing to use for a given mode. Defaults to the value of 31434 `HAVE_POST_INCREMENT'. 31435 31436 -- Macro: USE_STORE_POST_DECREMENT (MODE) 31437 A C expression used to determine whether a store postdecrement is 31438 a good thing to use for a given mode. Defaults to the value of 31439 `HAVE_POST_DECREMENT'. 31440 31441 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 31442 This macro is used to determine whether a store preincrement is a 31443 good thing to use for a given mode. Defaults to the value of 31444 `HAVE_PRE_INCREMENT'. 31445 31446 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 31447 This macro is used to determine whether a store predecrement is a 31448 good thing to use for a given mode. Defaults to the value of 31449 `HAVE_PRE_DECREMENT'. 31450 31451 -- Macro: NO_FUNCTION_CSE 31452 Define this macro if it is as good or better to call a constant 31453 function address than to call an address kept in a register. 31454 31455 -- Macro: RANGE_TEST_NON_SHORT_CIRCUIT 31456 Define this macro if a non-short-circuit operation produced by 31457 `fold_range_test ()' is optimal. This macro defaults to true if 31458 `BRANCH_COST' is greater than or equal to the value 2. 31459 31460 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int 31461 OUTER_CODE, int *TOTAL, bool SPEED) 31462 This target hook describes the relative costs of RTL expressions. 31463 31464 The cost may depend on the precise form of the expression, which is 31465 available for examination in X, and the rtx code of the expression 31466 in which it is contained, found in OUTER_CODE. CODE is the 31467 expression code--redundant, since it can be obtained with 31468 `GET_CODE (X)'. 31469 31470 In implementing this hook, you can use the construct 31471 `COSTS_N_INSNS (N)' to specify a cost equal to N fast instructions. 31472 31473 On entry to the hook, `*TOTAL' contains a default estimate for the 31474 cost of the expression. The hook should modify this value as 31475 necessary. Traditionally, the default costs are `COSTS_N_INSNS 31476 (5)' for multiplications, `COSTS_N_INSNS (7)' for division and 31477 modulus operations, and `COSTS_N_INSNS (1)' for all other 31478 operations. 31479 31480 When optimizing for code size, i.e. when `speed' is false, this 31481 target hook should be used to estimate the relative size cost of 31482 an expression, again relative to `COSTS_N_INSNS'. 31483 31484 The hook returns true when all subexpressions of X have been 31485 processed, and false when `rtx_cost' should recurse. 31486 31487 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, bool SPEED) 31488 This hook computes the cost of an addressing mode that contains 31489 ADDRESS. If not defined, the cost is computed from the ADDRESS 31490 expression and the `TARGET_RTX_COST' hook. 31491 31492 For most CISC machines, the default cost is a good approximation 31493 of the true cost of the addressing mode. However, on RISC 31494 machines, all instructions normally have the same length and 31495 execution time. Hence all addresses will have equal costs. 31496 31497 In cases where more than one form of an address is known, the form 31498 with the lowest cost will be used. If multiple forms have the 31499 same, lowest, cost, the one that is the most complex will be used. 31500 31501 For example, suppose an address that is equal to the sum of a 31502 register and a constant is used twice in the same basic block. 31503 When this macro is not defined, the address will be computed in a 31504 register and memory references will be indirect through that 31505 register. On machines where the cost of the addressing mode 31506 containing the sum is no higher than that of a simple indirect 31507 reference, this will produce an additional instruction and 31508 possibly require an additional register. Proper specification of 31509 this macro eliminates this overhead for such machines. 31510 31511 This hook is never called with an invalid address. 31512 31513 On machines where an address involving more than one register is as 31514 cheap as an address computation involving only one register, 31515 defining `TARGET_ADDRESS_COST' to reflect this can cause two 31516 registers to be live over a region of code where only one would 31517 have been if `TARGET_ADDRESS_COST' were not defined in that 31518 manner. This effect should be considered in the definition of 31519 this macro. Equivalent costs should probably only be given to 31520 addresses with different numbers of registers on machines with 31521 lots of registers. 31522 31523 31524 File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 31525 31526 17.18 Adjusting the Instruction Scheduler 31527 ========================================= 31528 31529 The instruction scheduler may need a fair amount of machine-specific 31530 adjustment in order to produce good code. GCC provides several target 31531 hooks for this purpose. It is usually enough to define just a few of 31532 them: try the first ones in this list first. 31533 31534 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 31535 This hook returns the maximum number of instructions that can ever 31536 issue at the same time on the target machine. The default is one. 31537 Although the insn scheduler can define itself the possibility of 31538 issue an insn on the same cycle, the value can serve as an 31539 additional constraint to issue insns on the same simulated 31540 processor cycle (see hooks `TARGET_SCHED_REORDER' and 31541 `TARGET_SCHED_REORDER2'). This value must be constant over the 31542 entire compilation. If you need it to vary depending on what the 31543 instructions are, you must use `TARGET_SCHED_VARIABLE_ISSUE'. 31544 31545 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 31546 VERBOSE, rtx INSN, int MORE) 31547 This hook is executed by the scheduler after it has scheduled an 31548 insn from the ready list. It should return the number of insns 31549 which can still be issued in the current cycle. The default is 31550 `MORE - 1' for insns other than `CLOBBER' and `USE', which 31551 normally are not counted against the issue rate. You should 31552 define this hook if some insns take more machine resources than 31553 others, so that fewer insns can follow them in the same cycle. 31554 FILE is either a null pointer, or a stdio stream to write any 31555 debug output to. VERBOSE is the verbose level provided by 31556 `-fsched-verbose-N'. INSN is the instruction that was scheduled. 31557 31558 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx 31559 DEP_INSN, int COST) 31560 This function corrects the value of COST based on the relationship 31561 between INSN and DEP_INSN through the dependence LINK. It should 31562 return the new value. The default is to make no adjustment to 31563 COST. This can be used for example to specify to the scheduler 31564 using the traditional pipeline description that an output- or 31565 anti-dependence does not incur the same cost as a data-dependence. 31566 If the scheduler using the automaton based pipeline description, 31567 the cost of anti-dependence is zero and the cost of 31568 output-dependence is maximum of one and the difference of latency 31569 times of the first and the second insns. If these values are not 31570 acceptable, you could use the hook to modify them too. See also 31571 *note Processor pipeline description::. 31572 31573 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int 31574 PRIORITY) 31575 This hook adjusts the integer scheduling priority PRIORITY of 31576 INSN. It should return the new priority. Increase the priority to 31577 execute INSN earlier, reduce the priority to execute INSN later. 31578 Do not define this hook if you do not need to adjust the 31579 scheduling priorities of insns. 31580 31581 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx 31582 *READY, int *N_READYP, int CLOCK) 31583 This hook is executed by the scheduler after it has scheduled the 31584 ready list, to allow the machine description to reorder it (for 31585 example to combine two small instructions together on `VLIW' 31586 machines). FILE is either a null pointer, or a stdio stream to 31587 write any debug output to. VERBOSE is the verbose level provided 31588 by `-fsched-verbose-N'. READY is a pointer to the ready list of 31589 instructions that are ready to be scheduled. N_READYP is a 31590 pointer to the number of elements in the ready list. The scheduler 31591 reads the ready list in reverse order, starting with 31592 READY[*N_READYP - 1] and going to READY[0]. CLOCK is the timer 31593 tick of the scheduler. You may modify the ready list and the 31594 number of ready insns. The return value is the number of insns 31595 that can issue this cycle; normally this is just `issue_rate'. 31596 See also `TARGET_SCHED_REORDER2'. 31597 31598 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 31599 rtx *READY, int *N_READYP, int CLOCK) 31600 Like `TARGET_SCHED_REORDER', but called at a different time. That 31601 function is called whenever the scheduler starts a new cycle. 31602 This one is called once per iteration over a cycle, immediately 31603 after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list 31604 and return the number of insns to be scheduled in the same cycle. 31605 Defining this hook can be useful if there are frequent situations 31606 where scheduling one insn causes other insns to become ready in 31607 the same cycle. These other insns can then be taken into account 31608 properly. 31609 31610 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx 31611 HEAD, rtx TAIL) 31612 This hook is called after evaluation forward dependencies of insns 31613 in chain given by two parameter values (HEAD and TAIL 31614 correspondingly) but before insns scheduling of the insn chain. 31615 For example, it can be used for better insn classification if it 31616 requires analysis of dependencies. This hook can use backward and 31617 forward dependencies of the insn scheduler because they are already 31618 calculated. 31619 31620 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 31621 MAX_READY) 31622 This hook is executed by the scheduler at the beginning of each 31623 block of instructions that are to be scheduled. FILE is either a 31624 null pointer, or a stdio stream to write any debug output to. 31625 VERBOSE is the verbose level provided by `-fsched-verbose-N'. 31626 MAX_READY is the maximum number of insns in the current scheduling 31627 region that can be live at the same time. This can be used to 31628 allocate scratch space if it is needed, e.g. by 31629 `TARGET_SCHED_REORDER'. 31630 31631 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 31632 This hook is executed by the scheduler at the end of each block of 31633 instructions that are to be scheduled. It can be used to perform 31634 cleanup of any actions done by the other scheduling hooks. FILE 31635 is either a null pointer, or a stdio stream to write any debug 31636 output to. VERBOSE is the verbose level provided by 31637 `-fsched-verbose-N'. 31638 31639 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int 31640 VERBOSE, int OLD_MAX_UID) 31641 This hook is executed by the scheduler after function level 31642 initializations. FILE is either a null pointer, or a stdio stream 31643 to write any debug output to. VERBOSE is the verbose level 31644 provided by `-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 31645 uid when scheduling begins. 31646 31647 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 31648 VERBOSE) 31649 This is the cleanup hook corresponding to 31650 `TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 31651 stdio stream to write any debug output to. VERBOSE is the verbose 31652 level provided by `-fsched-verbose-N'. 31653 31654 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 31655 The hook returns an RTL insn. The automaton state used in the 31656 pipeline hazard recognizer is changed as if the insn were scheduled 31657 when the new simulated processor cycle starts. Usage of the hook 31658 may simplify the automaton pipeline description for some VLIW 31659 processors. If the hook is defined, it is used only for the 31660 automaton based pipeline description. The default is not to 31661 change the state when the new simulated processor cycle starts. 31662 31663 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 31664 The hook can be used to initialize data used by the previous hook. 31665 31666 -- Target Hook: rtx TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 31667 The hook is analogous to `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 31668 to changed the state as if the insn were scheduled when the new 31669 simulated processor cycle finishes. 31670 31671 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 31672 The hook is analogous to `TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 31673 used to initialize data used by the previous hook. 31674 31675 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 31676 The hook to notify target that the current simulated cycle is 31677 about to finish. The hook is analogous to 31678 `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 31679 more complicated situations - e.g., when advancing state on a 31680 single insn is not enough. 31681 31682 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 31683 The hook to notify target that new simulated cycle has just 31684 started. The hook is analogous to 31685 `TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 31686 more complicated situations - e.g., when advancing state on a 31687 single insn is not enough. 31688 31689 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 31690 (void) 31691 This hook controls better choosing an insn from the ready insn 31692 queue for the DFA-based insn scheduler. Usually the scheduler 31693 chooses the first insn from the queue. If the hook returns a 31694 positive value, an additional scheduler code tries all 31695 permutations of `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 31696 ()' subsequent ready insns to choose an insn whose issue will 31697 result in maximal number of issued insns on the same cycle. For 31698 the VLIW processor, the code could actually solve the problem of 31699 packing simple insns into the VLIW insn. Of course, if the rules 31700 of VLIW packing are described in the automaton. 31701 31702 This code also could be used for superscalar RISC processors. Let 31703 us consider a superscalar RISC processor with 3 pipelines. Some 31704 insns can be executed in pipelines A or B, some insns can be 31705 executed only in pipelines B or C, and one insn can be executed in 31706 pipeline B. The processor may issue the 1st insn into A and the 31707 2nd one into B. In this case, the 3rd insn will wait for freeing B 31708 until the next cycle. If the scheduler issues the 3rd insn the 31709 first, the processor could issue all 3 insns per cycle. 31710 31711 Actually this code demonstrates advantages of the automaton based 31712 pipeline hazard recognizer. We try quickly and easy many insn 31713 schedules to choose the best one. 31714 31715 The default is no multipass scheduling. 31716 31717 -- Target Hook: int 31718 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx INSN) 31719 This hook controls what insns from the ready insn queue will be 31720 considered for the multipass insn scheduling. If the hook returns 31721 zero for INSN, the insn will be not chosen to be issued. 31722 31723 The default is that any ready insns can be chosen to be issued. 31724 31725 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void 31726 *DATA, char *READY_TRY, int N_READY, bool FIRST_CYCLE_INSN_P) 31727 This hook prepares the target backend for a new round of multipass 31728 scheduling. 31729 31730 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void 31731 *DATA, char *READY_TRY, int N_READY, rtx INSN, const void 31732 *PREV_DATA) 31733 This hook is called when multipass scheduling evaluates 31734 instruction INSN. 31735 31736 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK 31737 (const void *DATA, char *READY_TRY, int N_READY) 31738 This is called when multipass scheduling backtracks from 31739 evaluation of an instruction. 31740 31741 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const 31742 void *DATA) 31743 This hook notifies the target about the result of the concluded 31744 current round of multipass scheduling. 31745 31746 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void 31747 *DATA) 31748 This hook initializes target-specific data used in multipass 31749 scheduling. 31750 31751 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void 31752 *DATA) 31753 This hook finalizes target-specific data used in multipass 31754 scheduling. 31755 31756 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 31757 VERBOSE, rtx INSN, int LAST_CLOCK, int CLOCK, int *SORT_P) 31758 This hook is called by the insn scheduler before issuing INSN on 31759 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 31760 this processor cycle. Instead, the processor cycle is advanced. 31761 If *SORT_P is zero, the insn ready queue is not sorted on the new 31762 cycle start as usually. DUMP and VERBOSE specify the file and 31763 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 31764 are, respectively, the processor cycle on which the previous insn 31765 has been issued, and the current processor cycle. 31766 31767 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 31768 *_DEP, int COST, int DISTANCE) 31769 This hook is used to define which dependences are considered 31770 costly by the target, so costly that it is not advisable to 31771 schedule the insns that are involved in the dependence too close 31772 to one another. The parameters to this hook are as follows: The 31773 first parameter _DEP is the dependence being evaluated. The 31774 second parameter COST is the cost of the dependence as estimated 31775 by the scheduler, and the third parameter DISTANCE is the distance 31776 in cycles between the two insns. The hook returns `true' if 31777 considering the distance between the two insns the dependence 31778 between them is considered costly by the target, and `false' 31779 otherwise. 31780 31781 Defining this hook can be useful in multiple-issue out-of-order 31782 machines, where (a) it's practically hopeless to predict the 31783 actual data/resource delays, however: (b) there's a better chance 31784 to predict the actual grouping that will be formed, and (c) 31785 correctly emulating the grouping can be very important. In such 31786 targets one may want to allow issuing dependent insns closer to 31787 one another--i.e., closer than the dependence distance; however, 31788 not in cases of "costly dependences", which this hooks allows to 31789 define. 31790 31791 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 31792 This hook is called by the insn scheduler after emitting a new 31793 instruction to the instruction stream. The hook notifies a target 31794 backend to extend its per instruction data structures. 31795 31796 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 31797 Return a pointer to a store large enough to hold target scheduling 31798 context. 31799 31800 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 31801 CLEAN_P) 31802 Initialize store pointed to by TC to hold target scheduling 31803 context. It CLEAN_P is true then initialize TC as if scheduler is 31804 at the beginning of the block. Otherwise, copy the current 31805 context into TC. 31806 31807 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 31808 Copy target scheduling context pointed to by TC to the current 31809 context. 31810 31811 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 31812 Deallocate internal data in target scheduling context pointed to 31813 by TC. 31814 31815 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 31816 Deallocate a store for target scheduling context pointed to by TC. 31817 31818 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx INSN, int 31819 REQUEST, rtx *NEW_PAT) 31820 This hook is called by the insn scheduler when INSN has only 31821 speculative dependencies and therefore can be scheduled 31822 speculatively. The hook is used to check if the pattern of INSN 31823 has a speculative version and, in case of successful check, to 31824 generate that speculative pattern. The hook should return 1, if 31825 the instruction has a speculative form, or -1, if it doesn't. 31826 REQUEST describes the type of requested speculation. If the 31827 return value equals 1 then NEW_PAT is assigned the generated 31828 speculative pattern. 31829 31830 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (int DEP_STATUS) 31831 This hook is called by the insn scheduler during generation of 31832 recovery code for INSN. It should return `true', if the 31833 corresponding check instruction should branch to recovery code, or 31834 `false' otherwise. 31835 31836 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx INSN, rtx LABEL, 31837 int MUTATE_P) 31838 This hook is called by the insn scheduler to generate a pattern 31839 for recovery check instruction. If MUTATE_P is zero, then INSN is 31840 a speculative instruction for which the check should be generated. 31841 LABEL is either a label of a basic block, where recovery code 31842 should be emitted, or a null pointer, when requested check doesn't 31843 branch to recovery code (a simple check). If MUTATE_P is nonzero, 31844 then a pattern for a branchy check corresponding to a simple check 31845 denoted by INSN should be generated. In this case LABEL can't be 31846 null. 31847 31848 -- Target Hook: bool 31849 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC (const_rtx 31850 INSN) 31851 This hook is used as a workaround for 31852 `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD' not being 31853 called on the first instruction of the ready list. The hook is 31854 used to discard speculative instructions that stand first in the 31855 ready list from being scheduled on the current cycle. If the hook 31856 returns `false', INSN will not be chosen to be issued. For 31857 non-speculative instructions, the hook should always return 31858 `true'. For example, in the ia64 backend the hook is used to 31859 cancel data speculative insns when the ALAT table is nearly full. 31860 31861 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct 31862 spec_info_def *SPEC_INFO) 31863 This hook is used by the insn scheduler to find out what features 31864 should be enabled/used. The structure *SPEC_INFO should be filled 31865 in by the target. The structure describes speculation types that 31866 can be used in the scheduler. 31867 31868 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 31869 This hook is called by the swing modulo scheduler to calculate a 31870 resource-based lower bound which is based on the resources 31871 available in the machine and the resources required by each 31872 instruction. The target backend can use G to calculate such 31873 bound. A very simple lower bound will be used in case this hook 31874 is not implemented: the total number of instructions divided by 31875 the issue rate. 31876 31877 -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx INSN, int X) 31878 This hook is called by Haifa Scheduler. It returns true if 31879 dispatch scheduling is supported in hardware and the condition 31880 specified in the parameter is true. 31881 31882 -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx INSN, int X) 31883 This hook is called by Haifa Scheduler. It performs the operation 31884 specified in its second parameter. 31885 31886 31887 File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 31888 31889 17.19 Dividing the Output into Sections (Texts, Data, ...) 31890 ========================================================== 31891 31892 An object file is divided into sections containing different types of 31893 data. In the most common case, there are three sections: the "text 31894 section", which holds instructions and read-only data; the "data 31895 section", which holds initialized writable data; and the "bss section", 31896 which holds uninitialized data. Some systems have other kinds of 31897 sections. 31898 31899 `varasm.c' provides several well-known sections, such as 31900 `text_section', `data_section' and `bss_section'. The normal way of 31901 controlling a `FOO_section' variable is to define the associated 31902 `FOO_SECTION_ASM_OP' macro, as described below. The macros are only 31903 read once, when `varasm.c' initializes itself, so their values must be 31904 run-time constants. They may however depend on command-line flags. 31905 31906 _Note:_ Some run-time files, such `crtstuff.c', also make use of the 31907 `FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 31908 31909 Some assemblers require a different string to be written every time a 31910 section is selected. If your assembler falls into this category, you 31911 should define the `TARGET_ASM_INIT_SECTIONS' hook and use 31912 `get_unnamed_section' to set up the sections. 31913 31914 You must always create a `text_section', either by defining 31915 `TEXT_SECTION_ASM_OP' or by initializing `text_section' in 31916 `TARGET_ASM_INIT_SECTIONS'. The same is true of `data_section' and 31917 `DATA_SECTION_ASM_OP'. If you do not create a distinct 31918 `readonly_data_section', the default is to reuse `text_section'. 31919 31920 All the other `varasm.c' sections are optional, and are null if the 31921 target does not provide them. 31922 31923 -- Macro: TEXT_SECTION_ASM_OP 31924 A C expression whose value is a string, including spacing, 31925 containing the assembler operation that should precede 31926 instructions and read-only data. Normally `"\t.text"' is right. 31927 31928 -- Macro: HOT_TEXT_SECTION_NAME 31929 If defined, a C string constant for the name of the section 31930 containing most frequently executed functions of the program. If 31931 not defined, GCC will provide a default definition if the target 31932 supports named sections. 31933 31934 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 31935 If defined, a C string constant for the name of the section 31936 containing unlikely executed functions in the program. 31937 31938 -- Macro: DATA_SECTION_ASM_OP 31939 A C expression whose value is a string, including spacing, 31940 containing the assembler operation to identify the following data 31941 as writable initialized data. Normally `"\t.data"' is right. 31942 31943 -- Macro: SDATA_SECTION_ASM_OP 31944 If defined, a C expression whose value is a string, including 31945 spacing, containing the assembler operation to identify the 31946 following data as initialized, writable small data. 31947 31948 -- Macro: READONLY_DATA_SECTION_ASM_OP 31949 A C expression whose value is a string, including spacing, 31950 containing the assembler operation to identify the following data 31951 as read-only initialized data. 31952 31953 -- Macro: BSS_SECTION_ASM_OP 31954 If defined, a C expression whose value is a string, including 31955 spacing, containing the assembler operation to identify the 31956 following data as uninitialized global data. If not defined, and 31957 neither `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined, 31958 uninitialized global data will be output in the data section if 31959 `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be 31960 used. 31961 31962 -- Macro: SBSS_SECTION_ASM_OP 31963 If defined, a C expression whose value is a string, including 31964 spacing, containing the assembler operation to identify the 31965 following data as uninitialized, writable small data. 31966 31967 -- Macro: TLS_COMMON_ASM_OP 31968 If defined, a C expression whose value is a string containing the 31969 assembler operation to identify the following data as thread-local 31970 common data. The default is `".tls_common"'. 31971 31972 -- Macro: TLS_SECTION_ASM_FLAG 31973 If defined, a C expression whose value is a character constant 31974 containing the flag used to mark a section as a TLS section. The 31975 default is `'T''. 31976 31977 -- Macro: INIT_SECTION_ASM_OP 31978 If defined, a C expression whose value is a string, including 31979 spacing, containing the assembler operation to identify the 31980 following data as initialization code. If not defined, GCC will 31981 assume such a section does not exist. This section has no 31982 corresponding `init_section' variable; it is used entirely in 31983 runtime code. 31984 31985 -- Macro: FINI_SECTION_ASM_OP 31986 If defined, a C expression whose value is a string, including 31987 spacing, containing the assembler operation to identify the 31988 following data as finalization code. If not defined, GCC will 31989 assume such a section does not exist. This section has no 31990 corresponding `fini_section' variable; it is used entirely in 31991 runtime code. 31992 31993 -- Macro: INIT_ARRAY_SECTION_ASM_OP 31994 If defined, a C expression whose value is a string, including 31995 spacing, containing the assembler operation to identify the 31996 following data as part of the `.init_array' (or equivalent) 31997 section. If not defined, GCC will assume such a section does not 31998 exist. Do not define both this macro and `INIT_SECTION_ASM_OP'. 31999 32000 -- Macro: FINI_ARRAY_SECTION_ASM_OP 32001 If defined, a C expression whose value is a string, including 32002 spacing, containing the assembler operation to identify the 32003 following data as part of the `.fini_array' (or equivalent) 32004 section. If not defined, GCC will assume such a section does not 32005 exist. Do not define both this macro and `FINI_SECTION_ASM_OP'. 32006 32007 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 32008 If defined, an ASM statement that switches to a different section 32009 via SECTION_OP, calls FUNCTION, and switches back to the text 32010 section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or 32011 `FINI_SECTION_ASM_OP' to calls to initialization and finalization 32012 functions from the init and fini sections. By default, this macro 32013 uses a simple function call. Some ports need hand-crafted 32014 assembly code to avoid dependencies on registers initialized in 32015 the function prologue or to ensure that constant pools don't end 32016 up too far way in the text section. 32017 32018 -- Macro: TARGET_LIBGCC_SDATA_SECTION 32019 If defined, a string which names the section into which small 32020 variables defined in crtstuff and libgcc should go. This is useful 32021 when the target has options for optimizing access to small data, 32022 and you want the crtstuff and libgcc routines to be conservative 32023 in what they expect of your application yet liberal in what your 32024 application expects. For example, for targets with a `.sdata' 32025 section (like MIPS), you could compile crtstuff with `-G 0' so 32026 that it doesn't require small data support from your application, 32027 but use this macro to put small data into `.sdata' so that your 32028 application can access these variables whether it uses small data 32029 or not. 32030 32031 -- Macro: FORCE_CODE_SECTION_ALIGN 32032 If defined, an ASM statement that aligns a code section to some 32033 arbitrary boundary. This is used to force all fragments of the 32034 `.init' and `.fini' sections to have to same alignment and thus 32035 prevent the linker from having to add any padding. 32036 32037 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 32038 Define this macro to be an expression with a nonzero value if jump 32039 tables (for `tablejump' insns) should be output in the text 32040 section, along with the assembler instructions. Otherwise, the 32041 readonly data section is used. 32042 32043 This macro is irrelevant if there is no separate readonly data 32044 section. 32045 32046 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 32047 Define this hook if you need to do something special to set up the 32048 `varasm.c' sections, or if your target has some special sections 32049 of its own that you need to create. 32050 32051 GCC calls this hook after processing the command line, but before 32052 writing any assembly code, and before calling any of the 32053 section-returning hooks described below. 32054 32055 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 32056 Return a mask describing how relocations should be treated when 32057 selecting sections. Bit 1 should be set if global relocations 32058 should be placed in a read-write section; bit 0 should be set if 32059 local relocations should be placed in a read-write section. 32060 32061 The default version of this function returns 3 when `-fpic' is in 32062 effect, and 0 otherwise. The hook is typically redefined when the 32063 target cannot support (some kinds of) dynamic relocations in 32064 read-only sections even in executables. 32065 32066 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 32067 RELOC, unsigned HOST_WIDE_INT ALIGN) 32068 Return the section into which EXP should be placed. You can 32069 assume that EXP is either a `VAR_DECL' node or a constant of some 32070 sort. RELOC indicates whether the initial value of EXP requires 32071 link-time relocations. Bit 0 is set when variable contains local 32072 relocations only, while bit 1 is set for global relocations. 32073 ALIGN is the constant alignment in bits. 32074 32075 The default version of this function takes care of putting 32076 read-only variables in `readonly_data_section'. 32077 32078 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 32079 32080 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 32081 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 32082 called for `FUNCTION_DECL's as well as for variables and constants. 32083 32084 In the case of a `FUNCTION_DECL', RELOC will be zero if the 32085 function has been determined to be likely to be called, and 32086 nonzero if it is unlikely to be called. 32087 32088 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 32089 Build up a unique section name, expressed as a `STRING_CST' node, 32090 and assign it to `DECL_SECTION_NAME (DECL)'. As with 32091 `TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 32092 value of EXP requires link-time relocations. 32093 32094 The default version of this function appends the symbol name to the 32095 ELF section name that would normally be used for the symbol. For 32096 example, the function `foo' would be placed in `.text.foo'. 32097 Whatever the actual target object format, this is often good 32098 enough. 32099 32100 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 32101 DECL) 32102 Return the readonly data section associated with 32103 `DECL_SECTION_NAME (DECL)'. The default version of this function 32104 selects `.gnu.linkonce.r.name' if the function's section is 32105 `.gnu.linkonce.t.name', `.rodata.name' if function is in 32106 `.text.name', and the normal readonly-data section otherwise. 32107 32108 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (enum 32109 machine_mode MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 32110 Return the section into which a constant X, of mode MODE, should 32111 be placed. You can assume that X is some kind of constant in RTL. 32112 The argument MODE is redundant except in the case of a `const_int' 32113 rtx. ALIGN is the constant alignment in bits. 32114 32115 The default version of this function takes care of putting symbolic 32116 constants in `flag_pic' mode in `data_section' and everything else 32117 in `readonly_data_section'. 32118 32119 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, 32120 tree ID) 32121 Define this hook if you need to postprocess the assembler name 32122 generated by target-independent code. The ID provided to this 32123 hook will be the computed name (e.g., the macro `DECL_NAME' of the 32124 DECL in C, or the mangled name of the DECL in C++). The return 32125 value of the hook is an `IDENTIFIER_NODE' for the appropriate 32126 mangled name on your target system. The default implementation of 32127 this hook just returns the ID provided. 32128 32129 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 32130 int NEW_DECL_P) 32131 Define this hook if references to a symbol or a constant must be 32132 treated differently depending on something about the variable or 32133 function named by the symbol (such as what section it is in). 32134 32135 The hook is executed immediately after rtl has been created for 32136 DECL, which may be a variable or function declaration or an entry 32137 in the constant pool. In either case, RTL is the rtl in question. 32138 Do _not_ use `DECL_RTL (DECL)' in this hook; that field may not 32139 have been initialized yet. 32140 32141 In the case of a constant, it is safe to assume that the rtl is a 32142 `mem' whose address is a `symbol_ref'. Most decls will also have 32143 this form, but that is not guaranteed. Global register variables, 32144 for instance, will have a `reg' for their rtl. (Normally the 32145 right thing to do with such unusual rtl is leave it alone.) 32146 32147 The NEW_DECL_P argument will be true if this is the first time 32148 that `TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. 32149 It will be false for subsequent invocations, which will happen for 32150 duplicate declarations. Whether or not anything must be done for 32151 the duplicate declaration depends on whether the hook examines 32152 `DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 32153 called for a constant. 32154 32155 The usual thing for this hook to do is to record flags in the 32156 `symbol_ref', using `SYMBOL_REF_FLAG' or `SYMBOL_REF_FLAGS'. 32157 Historically, the name string was modified if it was necessary to 32158 encode more than one bit of information, but this practice is now 32159 discouraged; use `SYMBOL_REF_FLAGS'. 32160 32161 The default definition of this hook, `default_encode_section_info' 32162 in `varasm.c', sets a number of commonly-useful bits in 32163 `SYMBOL_REF_FLAGS'. Check whether the default does what you need 32164 before overriding it. 32165 32166 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 32167 *NAME) 32168 Decode NAME and return the real name part, sans the characters 32169 that `TARGET_ENCODE_SECTION_INFO' may have added. 32170 32171 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 32172 Returns true if EXP should be placed into a "small data" section. 32173 The default version of this hook always returns false. 32174 32175 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 32176 Contains the value true if the target places read-only "small 32177 data" into a separate section. The default value is false. 32178 32179 -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void) 32180 It returns true if target wants profile code emitted before 32181 prologue. 32182 32183 The default version of this hook use the target macro 32184 `PROFILE_BEFORE_PROLOGUE'. 32185 32186 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 32187 Returns true if EXP names an object for which name resolution 32188 rules must resolve to the current "module" (dynamic shared library 32189 or executable image). 32190 32191 The default version of this hook implements the name resolution 32192 rules for ELF, which has a looser model of global name binding 32193 than other currently supported object file formats. 32194 32195 -- Target Hook: bool TARGET_HAVE_TLS 32196 Contains the value true if the target supports thread-local 32197 storage. The default value is false. 32198 32199 32200 File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 32201 32202 17.20 Position Independent Code 32203 =============================== 32204 32205 This section describes macros that help implement generation of position 32206 independent code. Simply defining these macros is not enough to 32207 generate valid PIC; you must also add support to the hook 32208 `TARGET_LEGITIMATE_ADDRESS_P' and to the macro `PRINT_OPERAND_ADDRESS', 32209 as well as `LEGITIMIZE_ADDRESS'. You must modify the definition of 32210 `movsi' to do something appropriate when the source operand contains a 32211 symbolic address. You may also need to alter the handling of switch 32212 statements so that they use relative addresses. 32213 32214 -- Macro: PIC_OFFSET_TABLE_REGNUM 32215 The register number of the register used to address a table of 32216 static data addresses in memory. In some cases this register is 32217 defined by a processor's "application binary interface" (ABI). 32218 When this macro is defined, RTL is generated for this register 32219 once, as with the stack pointer and frame pointer registers. If 32220 this macro is not defined, it is up to the machine-dependent files 32221 to allocate such a register (if necessary). Note that this 32222 register must be fixed when in use (e.g. when `flag_pic' is true). 32223 32224 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 32225 A C expression that is nonzero if the register defined by 32226 `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined, 32227 the default is zero. Do not define this macro if 32228 `PIC_OFFSET_TABLE_REGNUM' is not defined. 32229 32230 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 32231 A C expression that is nonzero if X is a legitimate immediate 32232 operand on the target machine when generating position independent 32233 code. You can assume that X satisfies `CONSTANT_P', so you need 32234 not check this. You can also assume FLAG_PIC is true, so you need 32235 not check it either. You need not define this macro if all 32236 constants (including `SYMBOL_REF') can be immediate operands when 32237 generating position independent code. 32238 32239 32240 File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 32241 32242 17.21 Defining the Output Assembler Language 32243 ============================================ 32244 32245 This section describes macros whose principal purpose is to describe how 32246 to write instructions in assembler language--rather than what the 32247 instructions do. 32248 32249 * Menu: 32250 32251 * File Framework:: Structural information for the assembler file. 32252 * Data Output:: Output of constants (numbers, strings, addresses). 32253 * Uninitialized Data:: Output of uninitialized variables. 32254 * Label Output:: Output and generation of labels. 32255 * Initialization:: General principles of initialization 32256 and termination routines. 32257 * Macros for Initialization:: 32258 Specific macros that control the handling of 32259 initialization and termination routines. 32260 * Instruction Output:: Output of actual instructions. 32261 * Dispatch Tables:: Output of jump tables. 32262 * Exception Region Output:: Output of exception region code. 32263 * Alignment Output:: Pseudo ops for alignment and skipping data. 32264 32265 32266 File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 32267 32268 17.21.1 The Overall Framework of an Assembler File 32269 -------------------------------------------------- 32270 32271 This describes the overall framework of an assembly file. 32272 32273 -- Target Hook: void TARGET_ASM_FILE_START (void) 32274 Output to `asm_out_file' any text which the assembler expects to 32275 find at the beginning of a file. The default behavior is 32276 controlled by two flags, documented below. Unless your target's 32277 assembler is quite unusual, if you override the default, you 32278 should call `default_file_start' at some point in your target 32279 hook. This lets other target files rely on these variables. 32280 32281 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 32282 If this flag is true, the text of the macro `ASM_APP_OFF' will be 32283 printed as the very first line in the assembly file, unless 32284 `-fverbose-asm' is in effect. (If that macro has been defined to 32285 the empty string, this variable has no effect.) With the normal 32286 definition of `ASM_APP_OFF', the effect is to notify the GNU 32287 assembler that it need not bother stripping comments or extra 32288 whitespace from its input. This allows it to work a bit faster. 32289 32290 The default is false. You should not set it to true unless you 32291 have verified that your port does not generate any extra 32292 whitespace or comments that will cause GAS to issue errors in 32293 NO_APP mode. 32294 32295 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 32296 If this flag is true, `output_file_directive' will be called for 32297 the primary source file, immediately after printing `ASM_APP_OFF' 32298 (if that is enabled). Most ELF assemblers expect this to be done. 32299 The default is false. 32300 32301 -- Target Hook: void TARGET_ASM_FILE_END (void) 32302 Output to `asm_out_file' any text which the assembler expects to 32303 find at the end of a file. The default is to output nothing. 32304 32305 -- Function: void file_end_indicate_exec_stack () 32306 Some systems use a common convention, the `.note.GNU-stack' 32307 special section, to indicate whether or not an object file relies 32308 on the stack being executable. If your system uses this 32309 convention, you should define `TARGET_ASM_FILE_END' to this 32310 function. If you need to do other things in that hook, have your 32311 hook function call this function. 32312 32313 -- Target Hook: void TARGET_ASM_LTO_START (void) 32314 Output to `asm_out_file' any text which the assembler expects to 32315 find at the start of an LTO section. The default is to output 32316 nothing. 32317 32318 -- Target Hook: void TARGET_ASM_LTO_END (void) 32319 Output to `asm_out_file' any text which the assembler expects to 32320 find at the end of an LTO section. The default is to output 32321 nothing. 32322 32323 -- Target Hook: void TARGET_ASM_CODE_END (void) 32324 Output to `asm_out_file' any text which is needed before emitting 32325 unwind info and debug info at the end of a file. Some targets emit 32326 here PIC setup thunks that cannot be emitted at the end of file, 32327 because they couldn't have unwind info then. The default is to 32328 output nothing. 32329 32330 -- Macro: ASM_COMMENT_START 32331 A C string constant describing how to begin a comment in the target 32332 assembler language. The compiler assumes that the comment will 32333 end at the end of the line. 32334 32335 -- Macro: ASM_APP_ON 32336 A C string constant for text to be output before each `asm' 32337 statement or group of consecutive ones. Normally this is 32338 `"#APP"', which is a comment that has no effect on most assemblers 32339 but tells the GNU assembler that it must check the lines that 32340 follow for all valid assembler constructs. 32341 32342 -- Macro: ASM_APP_OFF 32343 A C string constant for text to be output after each `asm' 32344 statement or group of consecutive ones. Normally this is 32345 `"#NO_APP"', which tells the GNU assembler to resume making the 32346 time-saving assumptions that are valid for ordinary compiler 32347 output. 32348 32349 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 32350 A C statement to output COFF information or DWARF debugging 32351 information which indicates that filename NAME is the current 32352 source file to the stdio stream STREAM. 32353 32354 This macro need not be defined if the standard form of output for 32355 the file format in use is appropriate. 32356 32357 -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE, 32358 const char *NAME) 32359 Output COFF information or DWARF debugging information which 32360 indicates that filename NAME is the current source file to the 32361 stdio stream FILE. 32362 32363 This target hook need not be defined if the standard form of 32364 output for the file format in use is appropriate. 32365 32366 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 32367 A C statement to output the string STRING to the stdio stream 32368 STREAM. If you do not call the function `output_quoted_string' in 32369 your config files, GCC will only call it to output filenames to 32370 the assembler source. So you can use it to canonicalize the format 32371 of the filename using this macro. 32372 32373 -- Macro: ASM_OUTPUT_IDENT (STREAM, STRING) 32374 A C statement to output something to the assembler file to handle a 32375 `#ident' directive containing the text STRING. If this macro is 32376 not defined, nothing is output for a `#ident' directive. 32377 32378 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 32379 unsigned int FLAGS, tree DECL) 32380 Output assembly directives to switch to section NAME. The section 32381 should have attributes as specified by FLAGS, which is a bit mask 32382 of the `SECTION_*' flags defined in `output.h'. If DECL is 32383 non-NULL, it is the `VAR_DECL' or `FUNCTION_DECL' with which this 32384 section is associated. 32385 32386 -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum 32387 node_frequency FREQ, bool STARTUP, bool EXIT) 32388 Return preferred text (sub)section for function DECL. Main 32389 purpose of this function is to separate cold, normal and hot 32390 functions. STARTUP is true when function is known to be used only 32391 at startup (from static constructors or it is `main()'). EXIT is 32392 true when function is known to be used only at exit (from static 32393 destructors). Return NULL if function should go to default text 32394 section. 32395 32396 -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE 32397 *FILE, tree DECL, bool NEW_IS_COLD) 32398 Used by the target to emit any assembler directives or additional 32399 labels needed when a function is partitioned between different 32400 sections. Output should be written to FILE. The function decl 32401 is available as DECL and the new section is `cold' if NEW_IS_COLD 32402 is `true'. 32403 32404 -- Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 32405 This flag is true if the target supports 32406 `TARGET_ASM_NAMED_SECTION'. It must not be modified by 32407 command-line option processing. 32408 32409 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 32410 This flag is true if we can create zeroed data by switching to a 32411 BSS section and then using `ASM_OUTPUT_SKIP' to allocate the space. 32412 This is true on most ELF targets. 32413 32414 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 32415 const char *NAME, int RELOC) 32416 Choose a set of section attributes for use by 32417 `TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 32418 section name, and whether or not the declaration's initializer may 32419 contain runtime relocations. DECL may be null, in which case 32420 read-write data should be assumed. 32421 32422 The default version of this function handles choosing code vs data, 32423 read-only vs read-write data, and `flag_pic'. You should only 32424 need to override this if your target has special flags that might 32425 be set via `__attribute__'. 32426 32427 -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type 32428 TYPE, const char *TEXT) 32429 Provides the target with the ability to record the gcc command line 32430 switches that have been passed to the compiler, and options that 32431 are enabled. The TYPE argument specifies what is being recorded. 32432 It can take the following values: 32433 32434 `SWITCH_TYPE_PASSED' 32435 TEXT is a command line switch that has been set by the user. 32436 32437 `SWITCH_TYPE_ENABLED' 32438 TEXT is an option which has been enabled. This might be as a 32439 direct result of a command line switch, or because it is 32440 enabled by default or because it has been enabled as a side 32441 effect of a different command line switch. For example, the 32442 `-O2' switch enables various different individual 32443 optimization passes. 32444 32445 `SWITCH_TYPE_DESCRIPTIVE' 32446 TEXT is either NULL or some descriptive text which should be 32447 ignored. If TEXT is NULL then it is being used to warn the 32448 target hook that either recording is starting or ending. The 32449 first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL, 32450 the warning is for start up and the second time the warning 32451 is for wind down. This feature is to allow the target hook 32452 to make any necessary preparations before it starts to record 32453 switches and to perform any necessary tidying up after it has 32454 finished recording switches. 32455 32456 `SWITCH_TYPE_LINE_START' 32457 This option can be ignored by this target hook. 32458 32459 `SWITCH_TYPE_LINE_END' 32460 This option can be ignored by this target hook. 32461 32462 The hook's return value must be zero. Other return values may be 32463 supported in the future. 32464 32465 By default this hook is set to NULL, but an example implementation 32466 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 32467 it records the switches as ASCII text inside a new, string 32468 mergeable section in the assembler output file. The name of the 32469 new section is provided by the 32470 `TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 32471 32472 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 32473 This is the name of the section that will be created by the example 32474 ELF implementation of the `TARGET_ASM_RECORD_GCC_SWITCHES' target 32475 hook. 32476 32477 32478 File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 32479 32480 17.21.2 Output of Data 32481 ---------------------- 32482 32483 -- Target Hook: const char * TARGET_ASM_BYTE_OP 32484 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 32485 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 32486 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 32487 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 32488 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 32489 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 32490 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 32491 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 32492 These hooks specify assembly directives for creating certain kinds 32493 of integer object. The `TARGET_ASM_BYTE_OP' directive creates a 32494 byte-sized object, the `TARGET_ASM_ALIGNED_HI_OP' one creates an 32495 aligned two-byte object, and so on. Any of the hooks may be 32496 `NULL', indicating that no suitable directive is available. 32497 32498 The compiler will print these strings at the start of a new line, 32499 followed immediately by the object's initial value. In most cases, 32500 the string should contain a tab, a pseudo-op, and then another tab. 32501 32502 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 32503 ALIGNED_P) 32504 The `assemble_integer' function uses this hook to output an 32505 integer object. X is the object's value, SIZE is its size in 32506 bytes and ALIGNED_P indicates whether it is aligned. The function 32507 should return `true' if it was able to output the object. If it 32508 returns false, `assemble_integer' will try to split the object 32509 into smaller parts. 32510 32511 The default implementation of this hook will use the 32512 `TARGET_ASM_BYTE_OP' family of strings, returning `false' when the 32513 relevant string is `NULL'. 32514 32515 -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE, 32516 rtx X) 32517 A target hook to recognize RTX patterns that `output_addr_const' 32518 can't deal with, and output assembly code to FILE corresponding to 32519 the pattern X. This may be used to allow machine-dependent 32520 `UNSPEC's to appear within constants. 32521 32522 If target hook fails to recognize a pattern, it must return 32523 `false', so that a standard error message is printed. If it 32524 prints an error message itself, by calling, for example, 32525 `output_operand_lossage', it may just return `true'. 32526 32527 -- Macro: OUTPUT_ADDR_CONST_EXTRA (STREAM, X, FAIL) 32528 A C statement to recognize RTX patterns that `output_addr_const' 32529 can't deal with, and output assembly code to STREAM corresponding 32530 to the pattern X. This may be used to allow machine-dependent 32531 `UNSPEC's to appear within constants. 32532 32533 If `OUTPUT_ADDR_CONST_EXTRA' fails to recognize a pattern, it must 32534 `goto fail', so that a standard error message is printed. If it 32535 prints an error message itself, by calling, for example, 32536 `output_operand_lossage', it may just complete normally. 32537 32538 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 32539 A C statement to output to the stdio stream STREAM an assembler 32540 instruction to assemble a string constant containing the LEN bytes 32541 at PTR. PTR will be a C expression of type `char *' and LEN a C 32542 expression of type `int'. 32543 32544 If the assembler has a `.ascii' pseudo-op as found in the Berkeley 32545 Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'. 32546 32547 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 32548 A C statement to output word N of a function descriptor for DECL. 32549 This must be defined if `TARGET_VTABLE_USES_DESCRIPTORS' is 32550 defined, and is otherwise unused. 32551 32552 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 32553 You may define this macro as a C expression. You should define the 32554 expression to have a nonzero value if GCC should output the 32555 constant pool for a function before the code for the function, or 32556 a zero value if GCC should output the constant pool after the 32557 function. If you do not define this macro, the usual case, GCC 32558 will output the constant pool before the function. 32559 32560 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 32561 A C statement to output assembler commands to define the start of 32562 the constant pool for a function. FUNNAME is a string giving the 32563 name of the function. Should the return type of the function be 32564 required, it can be obtained via FUNDECL. SIZE is the size, in 32565 bytes, of the constant pool that will be written immediately after 32566 this call. 32567 32568 If no constant-pool prefix is required, the usual case, this macro 32569 need not be defined. 32570 32571 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, 32572 LABELNO, JUMPTO) 32573 A C statement (with or without semicolon) to output a constant in 32574 the constant pool, if it needs special treatment. (This macro 32575 need not do anything for RTL expressions that can be output 32576 normally.) 32577 32578 The argument FILE is the standard I/O stream to output the 32579 assembler code on. X is the RTL expression for the constant to 32580 output, and MODE is the machine mode (in case X is a `const_int'). 32581 ALIGN is the required alignment for the value X; you should output 32582 an assembler directive to force this much alignment. 32583 32584 The argument LABELNO is a number to use in an internal label for 32585 the address of this pool entry. The definition of this macro is 32586 responsible for outputting the label definition at the proper 32587 place. Here is how to do this: 32588 32589 `(*targetm.asm_out.internal_label)' (FILE, "LC", LABELNO); 32590 32591 When you output a pool entry specially, you should end with a 32592 `goto' to the label JUMPTO. This will prevent the same pool entry 32593 from being output a second time in the usual manner. 32594 32595 You need not define this macro if it would do nothing. 32596 32597 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 32598 A C statement to output assembler commands to at the end of the 32599 constant pool for a function. FUNNAME is a string giving the name 32600 of the function. Should the return type of the function be 32601 required, you can obtain it via FUNDECL. SIZE is the size, in 32602 bytes, of the constant pool that GCC wrote immediately before this 32603 call. 32604 32605 If no constant-pool epilogue is required, the usual case, you need 32606 not define this macro. 32607 32608 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 32609 Define this macro as a C expression which is nonzero if C is used 32610 as a logical line separator by the assembler. STR points to the 32611 position in the string where C was found; this can be used if a 32612 line separator uses multiple characters. 32613 32614 If you do not define this macro, the default is that only the 32615 character `;' is treated as a logical line separator. 32616 32617 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 32618 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 32619 These target hooks are C string constants, describing the syntax 32620 in the assembler for grouping arithmetic expressions. If not 32621 overridden, they default to normal parentheses, which is correct 32622 for most assemblers. 32623 32624 These macros are provided by `real.h' for writing the definitions of 32625 `ASM_OUTPUT_DOUBLE' and the like: 32626 32627 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 32628 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 32629 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 32630 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 32631 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 32632 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 32633 These translate X, of type `REAL_VALUE_TYPE', to the target's 32634 floating point representation, and store its bit pattern in the 32635 variable L. For `REAL_VALUE_TO_TARGET_SINGLE' and 32636 `REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 32637 `long int'. For the others, it should be an array of `long int'. 32638 The number of elements in this array is determined by the size of 32639 the desired target floating point data type: 32 bits of it go in 32640 each `long int' array element. Each array element holds 32 bits 32641 of the result, even if `long int' is wider than 32 bits on the 32642 host machine. 32643 32644 The array element values are designed so that you can print them 32645 out using `fprintf' in the order they should appear in the target 32646 machine's memory. 32647 32648 32649 File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 32650 32651 17.21.3 Output of Uninitialized Variables 32652 ----------------------------------------- 32653 32654 Each of the macros in this section is used to do the whole job of 32655 outputting a single uninitialized variable. 32656 32657 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 32658 A C statement (sans semicolon) to output to the stdio stream 32659 STREAM the assembler definition of a common-label named NAME whose 32660 size is SIZE bytes. The variable ROUNDED is the size rounded up 32661 to whatever alignment the caller wants. It is possible that SIZE 32662 may be zero, for instance if a struct with no other member than a 32663 zero-length array is defined. In this case, the backend must 32664 output a symbol definition that allocates at least one byte, both 32665 so that the address of the resulting object does not compare equal 32666 to any other, and because some object formats cannot even express 32667 the concept of a zero-sized common symbol, as that is how they 32668 represent an ordinary undefined external. 32669 32670 Use the expression `assemble_name (STREAM, NAME)' to output the 32671 name itself; before and after that, output the additional 32672 assembler syntax for defining the name, and a newline. 32673 32674 This macro controls how the assembler definitions of uninitialized 32675 common global variables are output. 32676 32677 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 32678 Like `ASM_OUTPUT_COMMON' except takes the required alignment as a 32679 separate, explicit argument. If you define this macro, it is used 32680 in place of `ASM_OUTPUT_COMMON', and gives you more flexibility in 32681 handling the required alignment of the variable. The alignment is 32682 specified as the number of bits. 32683 32684 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 32685 ALIGNMENT) 32686 Like `ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 32687 to be output, if there is one, or `NULL_TREE' if there is no 32688 corresponding variable. If you define this macro, GCC will use it 32689 in place of both `ASM_OUTPUT_COMMON' and 32690 `ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 32691 see the variable's decl in order to chose what to output. 32692 32693 -- Macro: ASM_OUTPUT_BSS (STREAM, DECL, NAME, SIZE, ROUNDED) 32694 A C statement (sans semicolon) to output to the stdio stream 32695 STREAM the assembler definition of uninitialized global DECL named 32696 NAME whose size is SIZE bytes. The variable ROUNDED is the size 32697 rounded up to whatever alignment the caller wants. 32698 32699 Try to use function `asm_output_bss' defined in `varasm.c' when 32700 defining this macro. If unable, use the expression `assemble_name 32701 (STREAM, NAME)' to output the name itself; before and after that, 32702 output the additional assembler syntax for defining the name, and 32703 a newline. 32704 32705 There are two ways of handling global BSS. One is to define either 32706 this macro or its aligned counterpart, `ASM_OUTPUT_ALIGNED_BSS'. 32707 The other is to have `TARGET_ASM_SELECT_SECTION' return a 32708 switchable BSS section (*note 32709 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 32710 both. 32711 32712 Some languages do not have `common' data, and require a non-common 32713 form of global BSS in order to handle uninitialized globals 32714 efficiently. C++ is one example of this. However, if the target 32715 does not support global BSS, the front end may choose to make 32716 globals common in order to save space in the object file. 32717 32718 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 32719 Like `ASM_OUTPUT_BSS' except takes the required alignment as a 32720 separate, explicit argument. If you define this macro, it is used 32721 in place of `ASM_OUTPUT_BSS', and gives you more flexibility in 32722 handling the required alignment of the variable. The alignment is 32723 specified as the number of bits. 32724 32725 Try to use function `asm_output_aligned_bss' defined in file 32726 `varasm.c' when defining this macro. 32727 32728 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 32729 A C statement (sans semicolon) to output to the stdio stream 32730 STREAM the assembler definition of a local-common-label named NAME 32731 whose size is SIZE bytes. The variable ROUNDED is the size 32732 rounded up to whatever alignment the caller wants. 32733 32734 Use the expression `assemble_name (STREAM, NAME)' to output the 32735 name itself; before and after that, output the additional 32736 assembler syntax for defining the name, and a newline. 32737 32738 This macro controls how the assembler definitions of uninitialized 32739 static variables are output. 32740 32741 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 32742 Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a 32743 separate, explicit argument. If you define this macro, it is used 32744 in place of `ASM_OUTPUT_LOCAL', and gives you more flexibility in 32745 handling the required alignment of the variable. The alignment is 32746 specified as the number of bits. 32747 32748 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 32749 ALIGNMENT) 32750 Like `ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to 32751 be output, if there is one, or `NULL_TREE' if there is no 32752 corresponding variable. If you define this macro, GCC will use it 32753 in place of both `ASM_OUTPUT_DECL' and `ASM_OUTPUT_ALIGNED_DECL'. 32754 Define this macro when you need to see the variable's decl in 32755 order to chose what to output. 32756 32757 32758 File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 32759 32760 17.21.4 Output and Generation of Labels 32761 --------------------------------------- 32762 32763 This is about outputting labels. 32764 32765 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 32766 A C statement (sans semicolon) to output to the stdio stream 32767 STREAM the assembler definition of a label named NAME. Use the 32768 expression `assemble_name (STREAM, NAME)' to output the name 32769 itself; before and after that, output the additional assembler 32770 syntax for defining the name, and a newline. A default definition 32771 of this macro is provided which is correct for most systems. 32772 32773 -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL) 32774 A C statement (sans semicolon) to output to the stdio stream 32775 STREAM the assembler definition of a label named NAME of a 32776 function. Use the expression `assemble_name (STREAM, NAME)' to 32777 output the name itself; before and after that, output the 32778 additional assembler syntax for defining the name, and a newline. 32779 A default definition of this macro is provided which is correct 32780 for most systems. 32781 32782 If this macro is not defined, then the function name is defined in 32783 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 32784 32785 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 32786 Identical to `ASM_OUTPUT_LABEL', except that NAME is known to 32787 refer to a compiler-generated label. The default definition uses 32788 `assemble_name_raw', which is like `assemble_name' except that it 32789 is more efficient. 32790 32791 -- Macro: SIZE_ASM_OP 32792 A C string containing the appropriate assembler directive to 32793 specify the size of a symbol, without any arguments. On systems 32794 that use ELF, the default (in `config/elfos.h') is `"\t.size\t"'; 32795 on other systems, the default is not to define this macro. 32796 32797 Define this macro only if it is correct to use the default 32798 definitions of `ASM_OUTPUT_SIZE_DIRECTIVE' and 32799 `ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 32800 custom definitions of those macros, or if you do not need explicit 32801 symbol sizes at all, do not define this macro. 32802 32803 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 32804 A C statement (sans semicolon) to output to the stdio stream 32805 STREAM a directive telling the assembler that the size of the 32806 symbol NAME is SIZE. SIZE is a `HOST_WIDE_INT'. If you define 32807 `SIZE_ASM_OP', a default definition of this macro is provided. 32808 32809 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 32810 A C statement (sans semicolon) to output to the stdio stream 32811 STREAM a directive telling the assembler to calculate the size of 32812 the symbol NAME by subtracting its address from the current 32813 address. 32814 32815 If you define `SIZE_ASM_OP', a default definition of this macro is 32816 provided. The default assumes that the assembler recognizes a 32817 special `.' symbol as referring to the current address, and can 32818 calculate the difference between this and another symbol. If your 32819 assembler does not recognize `.' or cannot do calculations with 32820 it, you will need to redefine `ASM_OUTPUT_MEASURED_SIZE' to use 32821 some other technique. 32822 32823 -- Macro: TYPE_ASM_OP 32824 A C string containing the appropriate assembler directive to 32825 specify the type of a symbol, without any arguments. On systems 32826 that use ELF, the default (in `config/elfos.h') is `"\t.type\t"'; 32827 on other systems, the default is not to define this macro. 32828 32829 Define this macro only if it is correct to use the default 32830 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 32831 need your own custom definition of this macro, or if you do not 32832 need explicit symbol types at all, do not define this macro. 32833 32834 -- Macro: TYPE_OPERAND_FMT 32835 A C string which specifies (using `printf' syntax) the format of 32836 the second operand to `TYPE_ASM_OP'. On systems that use ELF, the 32837 default (in `config/elfos.h') is `"@%s"'; on other systems, the 32838 default is not to define this macro. 32839 32840 Define this macro only if it is correct to use the default 32841 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 32842 need your own custom definition of this macro, or if you do not 32843 need explicit symbol types at all, do not define this macro. 32844 32845 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 32846 A C statement (sans semicolon) to output to the stdio stream 32847 STREAM a directive telling the assembler that the type of the 32848 symbol NAME is TYPE. TYPE is a C string; currently, that string 32849 is always either `"function"' or `"object"', but you should not 32850 count on this. 32851 32852 If you define `TYPE_ASM_OP' and `TYPE_OPERAND_FMT', a default 32853 definition of this macro is provided. 32854 32855 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 32856 A C statement (sans semicolon) to output to the stdio stream 32857 STREAM any text necessary for declaring the name NAME of a 32858 function which is being defined. This macro is responsible for 32859 outputting the label definition (perhaps using 32860 `ASM_OUTPUT_FUNCTION_LABEL'). The argument DECL is the 32861 `FUNCTION_DECL' tree node representing the function. 32862 32863 If this macro is not defined, then the function name is defined in 32864 the usual manner as a label (by means of 32865 `ASM_OUTPUT_FUNCTION_LABEL'). 32866 32867 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 32868 of this macro. 32869 32870 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 32871 A C statement (sans semicolon) to output to the stdio stream 32872 STREAM any text necessary for declaring the size of a function 32873 which is being defined. The argument NAME is the name of the 32874 function. The argument DECL is the `FUNCTION_DECL' tree node 32875 representing the function. 32876 32877 If this macro is not defined, then the function size is not 32878 defined. 32879 32880 You may wish to use `ASM_OUTPUT_MEASURED_SIZE' in the definition 32881 of this macro. 32882 32883 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 32884 A C statement (sans semicolon) to output to the stdio stream 32885 STREAM any text necessary for declaring the name NAME of an 32886 initialized variable which is being defined. This macro must 32887 output the label definition (perhaps using `ASM_OUTPUT_LABEL'). 32888 The argument DECL is the `VAR_DECL' tree node representing the 32889 variable. 32890 32891 If this macro is not defined, then the variable name is defined in 32892 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 32893 32894 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' and/or 32895 `ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 32896 32897 -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE, 32898 const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE) 32899 A target hook to output to the stdio stream FILE any text necessary 32900 for declaring the name NAME of a constant which is being defined. 32901 This target hook is responsible for outputting the label 32902 definition (perhaps using `assemble_label'). The argument EXP is 32903 the value of the constant, and SIZE is the size of the constant in 32904 bytes. The NAME will be an internal label. 32905 32906 The default version of this target hook, define the NAME in the 32907 usual manner as a label (by means of `assemble_label'). 32908 32909 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in this target 32910 hook. 32911 32912 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 32913 A C statement (sans semicolon) to output to the stdio stream 32914 STREAM any text necessary for claiming a register REGNO for a 32915 global variable DECL with name NAME. 32916 32917 If you don't define this macro, that is equivalent to defining it 32918 to do nothing. 32919 32920 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 32921 A C statement (sans semicolon) to finish up declaring a variable 32922 name once the compiler has processed its initializer fully and 32923 thus has had a chance to determine the size of an array when 32924 controlled by an initializer. This is used on systems where it's 32925 necessary to declare something about the size of the object. 32926 32927 If you don't define this macro, that is equivalent to defining it 32928 to do nothing. 32929 32930 You may wish to use `ASM_OUTPUT_SIZE_DIRECTIVE' and/or 32931 `ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 32932 32933 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 32934 char *NAME) 32935 This target hook is a function to output to the stdio stream 32936 STREAM some commands that will make the label NAME global; that 32937 is, available for reference from other files. 32938 32939 The default implementation relies on a proper definition of 32940 `GLOBAL_ASM_OP'. 32941 32942 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, 32943 tree DECL) 32944 This target hook is a function to output to the stdio stream 32945 STREAM some commands that will make the name associated with DECL 32946 global; that is, available for reference from other files. 32947 32948 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 32949 target hook. 32950 32951 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 32952 A C statement (sans semicolon) to output to the stdio stream 32953 STREAM some commands that will make the label NAME weak; that is, 32954 available for reference from other files but only used if no other 32955 definition is available. Use the expression `assemble_name 32956 (STREAM, NAME)' to output the name itself; before and after that, 32957 output the additional assembler syntax for making that name weak, 32958 and a newline. 32959 32960 If you don't define this macro or `ASM_WEAKEN_DECL', GCC will not 32961 support weak symbols and you should not define the `SUPPORTS_WEAK' 32962 macro. 32963 32964 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 32965 Combines (and replaces) the function of `ASM_WEAKEN_LABEL' and 32966 `ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 32967 or variable decl. If VALUE is not `NULL', this C statement should 32968 output to the stdio stream STREAM assembler code which defines 32969 (equates) the weak symbol NAME to have the value VALUE. If VALUE 32970 is `NULL', it should output commands to make NAME weak. 32971 32972 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 32973 Outputs a directive that enables NAME to be used to refer to 32974 symbol VALUE with weak-symbol semantics. `decl' is the 32975 declaration of `name'. 32976 32977 -- Macro: SUPPORTS_WEAK 32978 A preprocessor constant expression which evaluates to true if the 32979 target supports weak symbols. 32980 32981 If you don't define this macro, `defaults.h' provides a default 32982 definition. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is 32983 defined, the default definition is `1'; otherwise, it is `0'. 32984 32985 -- Macro: TARGET_SUPPORTS_WEAK 32986 A C expression which evaluates to true if the target supports weak 32987 symbols. 32988 32989 If you don't define this macro, `defaults.h' provides a default 32990 definition. The default definition is `(SUPPORTS_WEAK)'. Define 32991 this macro if you want to control weak symbol support with a 32992 compiler flag such as `-melf'. 32993 32994 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 32995 A C statement (sans semicolon) to mark DECL to be emitted as a 32996 public symbol such that extra copies in multiple translation units 32997 will be discarded by the linker. Define this macro if your object 32998 file format provides support for this concept, such as the `COMDAT' 32999 section flags in the Microsoft Windows PE/COFF format, and this 33000 support requires changes to DECL, such as putting it in a separate 33001 section. 33002 33003 -- Macro: SUPPORTS_ONE_ONLY 33004 A C expression which evaluates to true if the target supports 33005 one-only semantics. 33006 33007 If you don't define this macro, `varasm.c' provides a default 33008 definition. If `MAKE_DECL_ONE_ONLY' is defined, the default 33009 definition is `1'; otherwise, it is `0'. Define this macro if you 33010 want to control one-only symbol support with a compiler flag, or if 33011 setting the `DECL_ONE_ONLY' flag is enough to mark a declaration to 33012 be emitted as one-only. 33013 33014 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 33015 VISIBILITY) 33016 This target hook is a function to output to ASM_OUT_FILE some 33017 commands that will make the symbol(s) associated with DECL have 33018 hidden, protected or internal visibility as specified by 33019 VISIBILITY. 33020 33021 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 33022 A C expression that evaluates to true if the target's linker 33023 expects that weak symbols do not appear in a static archive's 33024 table of contents. The default is `0'. 33025 33026 Leaving weak symbols out of an archive's table of contents means 33027 that, if a symbol will only have a definition in one translation 33028 unit and will have undefined references from other translation 33029 units, that symbol should not be weak. Defining this macro to be 33030 nonzero will thus have the effect that certain symbols that would 33031 normally be weak (explicit template instantiations, and vtables 33032 for polymorphic classes with noninline key methods) will instead 33033 be nonweak. 33034 33035 The C++ ABI requires this macro to be zero. Define this macro for 33036 targets where full C++ ABI compliance is impossible and where 33037 linker restrictions require weak symbols to be left out of a 33038 static archive's table of contents. 33039 33040 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 33041 A C statement (sans semicolon) to output to the stdio stream 33042 STREAM any text necessary for declaring the name of an external 33043 symbol named NAME which is referenced in this compilation but not 33044 defined. The value of DECL is the tree node for the declaration. 33045 33046 This macro need not be defined if it does not need to output 33047 anything. The GNU assembler and most Unix assemblers don't 33048 require anything. 33049 33050 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 33051 This target hook is a function to output to ASM_OUT_FILE an 33052 assembler pseudo-op to declare a library function name external. 33053 The name of the library function is given by SYMREF, which is a 33054 `symbol_ref'. 33055 33056 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 33057 *SYMBOL) 33058 This target hook is a function to output to ASM_OUT_FILE an 33059 assembler directive to annotate SYMBOL as used. The Darwin target 33060 uses the .no_dead_code_strip directive. 33061 33062 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 33063 A C statement (sans semicolon) to output to the stdio stream 33064 STREAM a reference in assembler syntax to a label named NAME. 33065 This should add `_' to the front of the name, if that is customary 33066 on your operating system, as it is in most Berkeley Unix systems. 33067 This macro is used in `assemble_name'. 33068 33069 -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME) 33070 Given a symbol NAME, perform same mangling as `varasm.c''s 33071 `assemble_name', but in memory rather than to a file stream, 33072 returning result as an `IDENTIFIER_NODE'. Required for correct 33073 LTO symtabs. The default implementation calls the 33074 `TARGET_STRIP_NAME_ENCODING' hook and then prepends the 33075 `USER_LABEL_PREFIX', if any. 33076 33077 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 33078 A C statement (sans semicolon) to output a reference to 33079 `SYMBOL_REF' SYM. If not defined, `assemble_name' will be used to 33080 output the name of the symbol. This macro may be used to modify 33081 the way a symbol is referenced depending on information encoded by 33082 `TARGET_ENCODE_SECTION_INFO'. 33083 33084 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 33085 A C statement (sans semicolon) to output a reference to BUF, the 33086 result of `ASM_GENERATE_INTERNAL_LABEL'. If not defined, 33087 `assemble_name' will be used to output the name of the symbol. 33088 This macro is not used by `output_asm_label', or the `%l' 33089 specifier that calls it; the intention is that this macro should 33090 be set when it is necessary to output a label differently when its 33091 address is being taken. 33092 33093 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 33094 char *PREFIX, unsigned long LABELNO) 33095 A function to output to the stdio stream STREAM a label whose name 33096 is made from the string PREFIX and the number LABELNO. 33097 33098 It is absolutely essential that these labels be distinct from the 33099 labels used for user-level functions and variables. Otherwise, 33100 certain programs will have name conflicts with internal labels. 33101 33102 It is desirable to exclude internal labels from the symbol table 33103 of the object file. Most assemblers have a naming convention for 33104 labels that should be excluded; on many systems, the letter `L' at 33105 the beginning of a label has this effect. You should find out what 33106 convention your system uses, and follow it. 33107 33108 The default version of this function utilizes 33109 `ASM_GENERATE_INTERNAL_LABEL'. 33110 33111 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 33112 A C statement to output to the stdio stream STREAM a debug info 33113 label whose name is made from the string PREFIX and the number 33114 NUM. This is useful for VLIW targets, where debug info labels may 33115 need to be treated differently than branch target labels. On some 33116 systems, branch target labels must be at the beginning of 33117 instruction bundles, but debug info labels can occur in the middle 33118 of instruction bundles. 33119 33120 If this macro is not defined, then 33121 `(*targetm.asm_out.internal_label)' will be used. 33122 33123 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 33124 A C statement to store into the string STRING a label whose name 33125 is made from the string PREFIX and the number NUM. 33126 33127 This string, when output subsequently by `assemble_name', should 33128 produce the output that `(*targetm.asm_out.internal_label)' would 33129 produce with the same PREFIX and NUM. 33130 33131 If the string begins with `*', then `assemble_name' will output 33132 the rest of the string unchanged. It is often convenient for 33133 `ASM_GENERATE_INTERNAL_LABEL' to use `*' in this way. If the 33134 string doesn't start with `*', then `ASM_OUTPUT_LABELREF' gets to 33135 output the string, and may change it. (Of course, 33136 `ASM_OUTPUT_LABELREF' is also part of your machine description, so 33137 you should know what it does on your machine.) 33138 33139 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 33140 A C expression to assign to OUTVAR (which is a variable of type 33141 `char *') a newly allocated string made from the string NAME and 33142 the number NUMBER, with some suitable punctuation added. Use 33143 `alloca' to get space for the string. 33144 33145 The string will be used as an argument to `ASM_OUTPUT_LABELREF' to 33146 produce an assembler label for an internal static variable whose 33147 name is NAME. Therefore, the string must be such as to result in 33148 valid assembler code. The argument NUMBER is different each time 33149 this macro is executed; it prevents conflicts between 33150 similarly-named internal static variables in different scopes. 33151 33152 Ideally this string should not be a valid C identifier, to prevent 33153 any conflict with the user's own symbols. Most assemblers allow 33154 periods or percent signs in assembler symbols; putting at least 33155 one of these between the name and the number will suffice. 33156 33157 If this macro is not defined, a default definition will be provided 33158 which is correct for most systems. 33159 33160 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 33161 A C statement to output to the stdio stream STREAM assembler code 33162 which defines (equates) the symbol NAME to have the value VALUE. 33163 33164 If `SET_ASM_OP' is defined, a default definition is provided which 33165 is correct for most systems. 33166 33167 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 33168 DECL_OF_VALUE) 33169 A C statement to output to the stdio stream STREAM assembler code 33170 which defines (equates) the symbol whose tree node is DECL_OF_NAME 33171 to have the value of the tree node DECL_OF_VALUE. This macro will 33172 be used in preference to `ASM_OUTPUT_DEF' if it is defined and if 33173 the tree nodes are available. 33174 33175 If `SET_ASM_OP' is defined, a default definition is provided which 33176 is correct for most systems. 33177 33178 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 33179 A C statement that evaluates to true if the assembler code which 33180 defines (equates) the symbol whose tree node is DECL_OF_NAME to 33181 have the value of the tree node DECL_OF_VALUE should be emitted 33182 near the end of the current compilation unit. The default is to 33183 not defer output of defines. This macro affects defines output by 33184 `ASM_OUTPUT_DEF' and `ASM_OUTPUT_DEF_FROM_DECLS'. 33185 33186 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 33187 A C statement to output to the stdio stream STREAM assembler code 33188 which defines (equates) the weak symbol NAME to have the value 33189 VALUE. If VALUE is `NULL', it defines NAME as an undefined weak 33190 symbol. 33191 33192 Define this macro if the target only supports weak aliases; define 33193 `ASM_OUTPUT_DEF' instead if possible. 33194 33195 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 33196 SEL_NAME) 33197 Define this macro to override the default assembler names used for 33198 Objective-C methods. 33199 33200 The default name is a unique method number followed by the name of 33201 the class (e.g. `_1_Foo'). For methods in categories, the name of 33202 the category is also included in the assembler name (e.g. 33203 `_1_Foo_Bar'). 33204 33205 These names are safe on most systems, but make debugging difficult 33206 since the method's selector is not present in the name. 33207 Therefore, particular systems define other ways of computing names. 33208 33209 BUF is an expression of type `char *' which gives you a buffer in 33210 which to store the name; its length is as long as CLASS_NAME, 33211 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 33212 33213 The argument IS_INST specifies whether the method is an instance 33214 method or a class method; CLASS_NAME is the name of the class; 33215 CAT_NAME is the name of the category (or `NULL' if the method is 33216 not in a category); and SEL_NAME is the name of the selector. 33217 33218 On systems where the assembler can handle quoted names, you can 33219 use this macro to provide more human-readable names. 33220 33221 -- Macro: ASM_DECLARE_CLASS_REFERENCE (STREAM, NAME) 33222 A C statement (sans semicolon) to output to the stdio stream 33223 STREAM commands to declare that the label NAME is an Objective-C 33224 class reference. This is only needed for targets whose linkers 33225 have special support for NeXT-style runtimes. 33226 33227 -- Macro: ASM_DECLARE_UNRESOLVED_REFERENCE (STREAM, NAME) 33228 A C statement (sans semicolon) to output to the stdio stream 33229 STREAM commands to declare that the label NAME is an unresolved 33230 Objective-C class reference. This is only needed for targets 33231 whose linkers have special support for NeXT-style runtimes. 33232 33233 33234 File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 33235 33236 17.21.5 How Initialization Functions Are Handled 33237 ------------------------------------------------ 33238 33239 The compiled code for certain languages includes "constructors" (also 33240 called "initialization routines")--functions to initialize data in the 33241 program when the program is started. These functions need to be called 33242 before the program is "started"--that is to say, before `main' is 33243 called. 33244 33245 Compiling some languages generates "destructors" (also called 33246 "termination routines") that should be called when the program 33247 terminates. 33248 33249 To make the initialization and termination functions work, the compiler 33250 must output something in the assembler code to cause those functions to 33251 be called at the appropriate time. When you port the compiler to a new 33252 system, you need to specify how to do this. 33253 33254 There are two major ways that GCC currently supports the execution of 33255 initialization and termination functions. Each way has two variants. 33256 Much of the structure is common to all four variations. 33257 33258 The linker must build two lists of these functions--a list of 33259 initialization functions, called `__CTOR_LIST__', and a list of 33260 termination functions, called `__DTOR_LIST__'. 33261 33262 Each list always begins with an ignored function pointer (which may 33263 hold 0, -1, or a count of the function pointers after it, depending on 33264 the environment). This is followed by a series of zero or more function 33265 pointers to constructors (or destructors), followed by a function 33266 pointer containing zero. 33267 33268 Depending on the operating system and its executable file format, 33269 either `crtstuff.c' or `libgcc2.c' traverses these lists at startup 33270 time and exit time. Constructors are called in reverse order of the 33271 list; destructors in forward order. 33272 33273 The best way to handle static constructors works only for object file 33274 formats which provide arbitrarily-named sections. A section is set 33275 aside for a list of constructors, and another for a list of destructors. 33276 Traditionally these are called `.ctors' and `.dtors'. Each object file 33277 that defines an initialization function also puts a word in the 33278 constructor section to point to that function. The linker accumulates 33279 all these words into one contiguous `.ctors' section. Termination 33280 functions are handled similarly. 33281 33282 This method will be chosen as the default by `target-def.h' if 33283 `TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 33284 arbitrary sections, but does support special designated constructor and 33285 destructor sections may define `CTORS_SECTION_ASM_OP' and 33286 `DTORS_SECTION_ASM_OP' to achieve the same effect. 33287 33288 When arbitrary sections are available, there are two variants, 33289 depending upon how the code in `crtstuff.c' is called. On systems that 33290 support a ".init" section which is executed at program startup, parts 33291 of `crtstuff.c' are compiled into that section. The program is linked 33292 by the `gcc' driver like this: 33293 33294 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 33295 33296 The prologue of a function (`__init') appears in the `.init' section 33297 of `crti.o'; the epilogue appears in `crtn.o'. Likewise for the 33298 function `__fini' in the ".fini" section. Normally these files are 33299 provided by the operating system or by the GNU C library, but are 33300 provided by GCC for a few targets. 33301 33302 The objects `crtbegin.o' and `crtend.o' are (for most targets) 33303 compiled from `crtstuff.c'. They contain, among other things, code 33304 fragments within the `.init' and `.fini' sections that branch to 33305 routines in the `.text' section. The linker will pull all parts of a 33306 section together, which results in a complete `__init' function that 33307 invokes the routines we need at startup. 33308 33309 To use this variant, you must define the `INIT_SECTION_ASM_OP' macro 33310 properly. 33311 33312 If no init section is available, when GCC compiles any function called 33313 `main' (or more accurately, any function designated as a program entry 33314 point by the language front end calling `expand_main_function'), it 33315 inserts a procedure call to `__main' as the first executable code after 33316 the function prologue. The `__main' function is defined in `libgcc2.c' 33317 and runs the global constructors. 33318 33319 In file formats that don't support arbitrary sections, there are again 33320 two variants. In the simplest variant, the GNU linker (GNU `ld') and 33321 an `a.out' format must be used. In this case, `TARGET_ASM_CONSTRUCTOR' 33322 is defined to produce a `.stabs' entry of type `N_SETT', referencing 33323 the name `__CTOR_LIST__', and with the address of the void function 33324 containing the initialization code as its value. The GNU linker 33325 recognizes this as a request to add the value to a "set"; the values 33326 are accumulated, and are eventually placed in the executable as a 33327 vector in the format described above, with a leading (ignored) count 33328 and a trailing zero element. `TARGET_ASM_DESTRUCTOR' is handled 33329 similarly. Since no init section is available, the absence of 33330 `INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main' 33331 as above, starting the initialization process. 33332 33333 The last variant uses neither arbitrary sections nor the GNU linker. 33334 This is preferable when you want to do dynamic linking and when using 33335 file formats which the GNU linker does not support, such as `ECOFF'. In 33336 this case, `TARGET_HAVE_CTORS_DTORS' is false, initialization and 33337 termination functions are recognized simply by their names. This 33338 requires an extra program in the linkage step, called `collect2'. This 33339 program pretends to be the linker, for use with GCC; it does its job by 33340 running the ordinary linker, but also arranges to include the vectors of 33341 initialization and termination functions. These functions are called 33342 via `__main' as described above. In order to use this method, 33343 `use_collect2' must be defined in the target in `config.gcc'. 33344 33345 The following section describes the specific macros that control and 33346 customize the handling of initialization and termination functions. 33347 33348 33349 File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 33350 33351 17.21.6 Macros Controlling Initialization Routines 33352 -------------------------------------------------- 33353 33354 Here are the macros that control how the compiler handles initialization 33355 and termination functions: 33356 33357 -- Macro: INIT_SECTION_ASM_OP 33358 If defined, a C string constant, including spacing, for the 33359 assembler operation to identify the following data as 33360 initialization code. If not defined, GCC will assume such a 33361 section does not exist. When you are using special sections for 33362 initialization and termination functions, this macro also controls 33363 how `crtstuff.c' and `libgcc2.c' arrange to run the initialization 33364 functions. 33365 33366 -- Macro: HAS_INIT_SECTION 33367 If defined, `main' will not call `__main' as described above. 33368 This macro should be defined for systems that control start-up code 33369 on a symbol-by-symbol basis, such as OSF/1, and should not be 33370 defined explicitly for systems that support `INIT_SECTION_ASM_OP'. 33371 33372 -- Macro: LD_INIT_SWITCH 33373 If defined, a C string constant for a switch that tells the linker 33374 that the following symbol is an initialization routine. 33375 33376 -- Macro: LD_FINI_SWITCH 33377 If defined, a C string constant for a switch that tells the linker 33378 that the following symbol is a finalization routine. 33379 33380 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 33381 If defined, a C statement that will write a function that can be 33382 automatically called when a shared library is loaded. The function 33383 should call FUNC, which takes no arguments. If not defined, and 33384 the object format requires an explicit initialization function, 33385 then a function called `_GLOBAL__DI' will be generated. 33386 33387 This function and the following one are used by collect2 when 33388 linking a shared library that needs constructors or destructors, 33389 or has DWARF2 exception tables embedded in the code. 33390 33391 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 33392 If defined, a C statement that will write a function that can be 33393 automatically called when a shared library is unloaded. The 33394 function should call FUNC, which takes no arguments. If not 33395 defined, and the object format requires an explicit finalization 33396 function, then a function called `_GLOBAL__DD' will be generated. 33397 33398 -- Macro: INVOKE__main 33399 If defined, `main' will call `__main' despite the presence of 33400 `INIT_SECTION_ASM_OP'. This macro should be defined for systems 33401 where the init section is not actually run automatically, but is 33402 still useful for collecting the lists of constructors and 33403 destructors. 33404 33405 -- Macro: SUPPORTS_INIT_PRIORITY 33406 If nonzero, the C++ `init_priority' attribute is supported and the 33407 compiler should emit instructions to control the order of 33408 initialization of objects. If zero, the compiler will issue an 33409 error message upon encountering an `init_priority' attribute. 33410 33411 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 33412 This value is true if the target supports some "native" method of 33413 collecting constructors and destructors to be run at startup and 33414 exit. It is false if we must use `collect2'. 33415 33416 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 33417 If defined, a function that outputs assembler code to arrange to 33418 call the function referenced by SYMBOL at initialization time. 33419 33420 Assume that SYMBOL is a `SYMBOL_REF' for a function taking no 33421 arguments and with no return value. If the target supports 33422 initialization priorities, PRIORITY is a value between 0 and 33423 `MAX_INIT_PRIORITY'; otherwise it must be `DEFAULT_INIT_PRIORITY'. 33424 33425 If this macro is not defined by the target, a suitable default will 33426 be chosen if (1) the target supports arbitrary section names, (2) 33427 the target defines `CTORS_SECTION_ASM_OP', or (3) `USE_COLLECT2' 33428 is not defined. 33429 33430 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 33431 This is like `TARGET_ASM_CONSTRUCTOR' but used for termination 33432 functions rather than initialization functions. 33433 33434 If `TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 33435 generated for the generated object file will have static linkage. 33436 33437 If your system uses `collect2' as the means of processing 33438 constructors, then that program normally uses `nm' to scan an object 33439 file for constructor functions to be called. 33440 33441 On certain kinds of systems, you can define this macro to make 33442 `collect2' work faster (and, in some cases, make it work at all): 33443 33444 -- Macro: OBJECT_FORMAT_COFF 33445 Define this macro if the system uses COFF (Common Object File 33446 Format) object files, so that `collect2' can assume this format 33447 and scan object files directly for dynamic constructor/destructor 33448 functions. 33449 33450 This macro is effective only in a native compiler; `collect2' as 33451 part of a cross compiler always uses `nm' for the target machine. 33452 33453 -- Macro: REAL_NM_FILE_NAME 33454 Define this macro as a C string constant containing the file name 33455 to use to execute `nm'. The default is to search the path 33456 normally for `nm'. 33457 33458 -- Macro: NM_FLAGS 33459 `collect2' calls `nm' to scan object files for static constructors 33460 and destructors and LTO info. By default, `-n' is passed. Define 33461 `NM_FLAGS' to a C string constant if other options are needed to 33462 get the same output format as GNU `nm -n' produces. 33463 33464 If your system supports shared libraries and has a program to list the 33465 dynamic dependencies of a given library or executable, you can define 33466 these macros to enable support for running initialization and 33467 termination functions in shared libraries: 33468 33469 -- Macro: LDD_SUFFIX 33470 Define this macro to a C string constant containing the name of 33471 the program which lists dynamic dependencies, like `ldd' under 33472 SunOS 4. 33473 33474 -- Macro: PARSE_LDD_OUTPUT (PTR) 33475 Define this macro to be C code that extracts filenames from the 33476 output of the program denoted by `LDD_SUFFIX'. PTR is a variable 33477 of type `char *' that points to the beginning of a line of output 33478 from `LDD_SUFFIX'. If the line lists a dynamic dependency, the 33479 code must advance PTR to the beginning of the filename on that 33480 line. Otherwise, it must set PTR to `NULL'. 33481 33482 -- Macro: SHLIB_SUFFIX 33483 Define this macro to a C string constant containing the default 33484 shared library extension of the target (e.g., `".so"'). `collect2' 33485 strips version information after this suffix when generating global 33486 constructor and destructor names. This define is only needed on 33487 targets that use `collect2' to process constructors and 33488 destructors. 33489 33490 33491 File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 33492 33493 17.21.7 Output of Assembler Instructions 33494 ---------------------------------------- 33495 33496 This describes assembler instruction output. 33497 33498 -- Macro: REGISTER_NAMES 33499 A C initializer containing the assembler's names for the machine 33500 registers, each one as a C string constant. This is what 33501 translates register numbers in the compiler into assembler 33502 language. 33503 33504 -- Macro: ADDITIONAL_REGISTER_NAMES 33505 If defined, a C initializer for an array of structures containing 33506 a name and a register number. This macro defines additional names 33507 for hard registers, thus allowing the `asm' option in declarations 33508 to refer to registers using alternate names. 33509 33510 -- Macro: OVERLAPPING_REGISTER_NAMES 33511 If defined, a C initializer for an array of structures containing a 33512 name, a register number and a count of the number of consecutive 33513 machine registers the name overlaps. This macro defines additional 33514 names for hard registers, thus allowing the `asm' option in 33515 declarations to refer to registers using alternate names. Unlike 33516 `ADDITIONAL_REGISTER_NAMES', this macro should be used when the 33517 register name implies multiple underlying registers. 33518 33519 This macro should be used when it is important that a clobber in an 33520 `asm' statement clobbers all the underlying values implied by the 33521 register name. For example, on ARM, clobbering the 33522 double-precision VFP register "d0" implies clobbering both 33523 single-precision registers "s0" and "s1". 33524 33525 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 33526 Define this macro if you are using an unusual assembler that 33527 requires different names for the machine instructions. 33528 33529 The definition is a C statement or statements which output an 33530 assembler instruction opcode to the stdio stream STREAM. The 33531 macro-operand PTR is a variable of type `char *' which points to 33532 the opcode name in its "internal" form--the form that is written 33533 in the machine description. The definition should output the 33534 opcode name to STREAM, performing any translation you desire, and 33535 increment the variable PTR to point at the end of the opcode so 33536 that it will not be output twice. 33537 33538 In fact, your macro definition may process less than the entire 33539 opcode name, or more than the opcode name; but if you want to 33540 process text that includes `%'-sequences to substitute operands, 33541 you must take care of the substitution yourself. Just be sure to 33542 increment PTR over whatever text should not be output normally. 33543 33544 If you need to look at the operand values, they can be found as the 33545 elements of `recog_data.operand'. 33546 33547 If the macro definition does nothing, the instruction is output in 33548 the usual way. 33549 33550 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 33551 If defined, a C statement to be executed just prior to the output 33552 of assembler code for INSN, to modify the extracted operands so 33553 they will be output differently. 33554 33555 Here the argument OPVEC is the vector containing the operands 33556 extracted from INSN, and NOPERANDS is the number of elements of 33557 the vector which contain meaningful data for this insn. The 33558 contents of this vector are what will be used to convert the insn 33559 template into assembler code, so you can change the assembler 33560 output by changing the contents of the vector. 33561 33562 This macro is useful when various assembler syntaxes share a single 33563 file of instruction patterns; by defining this macro differently, 33564 you can cause a large class of instructions to be output 33565 differently (such as with rearranged operands). Naturally, 33566 variations in assembler syntax affecting individual insn patterns 33567 ought to be handled by writing conditional output routines in 33568 those patterns. 33569 33570 If this macro is not defined, it is equivalent to a null statement. 33571 33572 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, rtx 33573 INSN, rtx *OPVEC, int NOPERANDS) 33574 If defined, this target hook is a function which is executed just 33575 after the output of assembler code for INSN, to change the mode of 33576 the assembler if necessary. 33577 33578 Here the argument OPVEC is the vector containing the operands 33579 extracted from INSN, and NOPERANDS is the number of elements of 33580 the vector which contain meaningful data for this insn. The 33581 contents of this vector are what was used to convert the insn 33582 template into assembler code, so you can change the assembler mode 33583 by checking the contents of the vector. 33584 33585 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 33586 A C compound statement to output to stdio stream STREAM the 33587 assembler syntax for an instruction operand X. X is an RTL 33588 expression. 33589 33590 CODE is a value that can be used to specify one of several ways of 33591 printing the operand. It is used when identical operands must be 33592 printed differently depending on the context. CODE comes from the 33593 `%' specification that was used to request printing of the 33594 operand. If the specification was just `%DIGIT' then CODE is 0; 33595 if the specification was `%LTR DIGIT' then CODE is the ASCII code 33596 for LTR. 33597 33598 If X is a register, this macro should print the register's name. 33599 The names can be found in an array `reg_names' whose type is `char 33600 *[]'. `reg_names' is initialized from `REGISTER_NAMES'. 33601 33602 When the machine description has a specification `%PUNCT' (a `%' 33603 followed by a punctuation character), this macro is called with a 33604 null pointer for X and the punctuation character for CODE. 33605 33606 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 33607 A C expression which evaluates to true if CODE is a valid 33608 punctuation character for use in the `PRINT_OPERAND' macro. If 33609 `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 33610 punctuation characters (except for the standard one, `%') are used 33611 in this way. 33612 33613 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 33614 A C compound statement to output to stdio stream STREAM the 33615 assembler syntax for an instruction operand that is a memory 33616 reference whose address is X. X is an RTL expression. 33617 33618 On some machines, the syntax for a symbolic address depends on the 33619 section that the address refers to. On these machines, define the 33620 hook `TARGET_ENCODE_SECTION_INFO' to store the information into the 33621 `symbol_ref', and then check for it here. *Note Assembler 33622 Format::. 33623 33624 -- Macro: DBR_OUTPUT_SEQEND (FILE) 33625 A C statement, to be executed after all slot-filler instructions 33626 have been output. If necessary, call `dbr_sequence_length' to 33627 determine the number of slots filled in a sequence (zero if not 33628 currently outputting a sequence), to decide how many no-ops to 33629 output, or whatever. 33630 33631 Don't define this macro if it has nothing to do, but it is helpful 33632 in reading assembly output if the extent of the delay sequence is 33633 made explicit (e.g. with white space). 33634 33635 Note that output routines for instructions with delay slots must be 33636 prepared to deal with not being output as part of a sequence (i.e. when 33637 the scheduling pass is not run, or when no slot fillers could be 33638 found.) The variable `final_sequence' is null when not processing a 33639 sequence, otherwise it contains the `sequence' rtx being output. 33640 33641 -- Macro: REGISTER_PREFIX 33642 -- Macro: LOCAL_LABEL_PREFIX 33643 -- Macro: USER_LABEL_PREFIX 33644 -- Macro: IMMEDIATE_PREFIX 33645 If defined, C string expressions to be used for the `%R', `%L', 33646 `%U', and `%I' options of `asm_fprintf' (see `final.c'). These 33647 are useful when a single `md' file must support multiple assembler 33648 formats. In that case, the various `tm.h' files can define these 33649 macros differently. 33650 33651 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 33652 If defined this macro should expand to a series of `case' 33653 statements which will be parsed inside the `switch' statement of 33654 the `asm_fprintf' function. This allows targets to define extra 33655 printf formats which may useful when generating their assembler 33656 statements. Note that uppercase letters are reserved for future 33657 generic extensions to asm_fprintf, and so are not available to 33658 target specific code. The output file is given by the parameter 33659 FILE. The varargs input pointer is ARGPTR and the rest of the 33660 format string, starting the character after the one that is being 33661 switched upon, is pointed to by FORMAT. 33662 33663 -- Macro: ASSEMBLER_DIALECT 33664 If your target supports multiple dialects of assembler language 33665 (such as different opcodes), define this macro as a C expression 33666 that gives the numeric index of the assembler language dialect to 33667 use, with zero as the first variant. 33668 33669 If this macro is defined, you may use constructs of the form 33670 `{option0|option1|option2...}' 33671 in the output templates of patterns (*note Output Template::) or 33672 in the first argument of `asm_fprintf'. This construct outputs 33673 `option0', `option1', `option2', etc., if the value of 33674 `ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 33675 within these strings retain their usual meaning. If there are 33676 fewer alternatives within the braces than the value of 33677 `ASSEMBLER_DIALECT', the construct outputs nothing. 33678 33679 If you do not define this macro, the characters `{', `|' and `}' 33680 do not have any special meaning when used in templates or operands 33681 to `asm_fprintf'. 33682 33683 Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX', 33684 `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the 33685 variations in assembler language syntax with that mechanism. 33686 Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax 33687 if the syntax variant are larger and involve such things as 33688 different opcodes or operand order. 33689 33690 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 33691 A C expression to output to STREAM some assembler code which will 33692 push hard register number REGNO onto the stack. The code need not 33693 be optimal, since this macro is used only when profiling. 33694 33695 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 33696 A C expression to output to STREAM some assembler code which will 33697 pop hard register number REGNO off of the stack. The code need 33698 not be optimal, since this macro is used only when profiling. 33699 33700 33701 File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 33702 33703 17.21.8 Output of Dispatch Tables 33704 --------------------------------- 33705 33706 This concerns dispatch tables. 33707 33708 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 33709 A C statement to output to the stdio stream STREAM an assembler 33710 pseudo-instruction to generate a difference between two labels. 33711 VALUE and REL are the numbers of two internal labels. The 33712 definitions of these labels are output using 33713 `(*targetm.asm_out.internal_label)', and they must be printed in 33714 the same way here. For example, 33715 33716 fprintf (STREAM, "\t.word L%d-L%d\n", 33717 VALUE, REL) 33718 33719 You must provide this macro on machines where the addresses in a 33720 dispatch table are relative to the table's own address. If 33721 defined, GCC will also use this macro on all machines when 33722 producing PIC. BODY is the body of the `ADDR_DIFF_VEC'; it is 33723 provided so that the mode and flags can be read. 33724 33725 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 33726 This macro should be provided on machines where the addresses in a 33727 dispatch table are absolute. 33728 33729 The definition should be a C statement to output to the stdio 33730 stream STREAM an assembler pseudo-instruction to generate a 33731 reference to a label. VALUE is the number of an internal label 33732 whose definition is output using 33733 `(*targetm.asm_out.internal_label)'. For example, 33734 33735 fprintf (STREAM, "\t.word L%d\n", VALUE) 33736 33737 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 33738 Define this if the label before a jump-table needs to be output 33739 specially. The first three arguments are the same as for 33740 `(*targetm.asm_out.internal_label)'; the fourth argument is the 33741 jump-table which follows (a `jump_insn' containing an `addr_vec' 33742 or `addr_diff_vec'). 33743 33744 This feature is used on system V to output a `swbeg' statement for 33745 the table. 33746 33747 If this macro is not defined, these labels are output with 33748 `(*targetm.asm_out.internal_label)'. 33749 33750 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 33751 Define this if something special must be output at the end of a 33752 jump-table. The definition should be a C statement to be executed 33753 after the assembler code for the table is written. It should write 33754 the appropriate code to stdio stream STREAM. The argument TABLE 33755 is the jump-table insn, and NUM is the label-number of the 33756 preceding label. 33757 33758 If this macro is not defined, nothing special is output at the end 33759 of the jump-table. 33760 33761 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 33762 DECL, int FOR_EH, int EMPTY) 33763 This target hook emits a label at the beginning of each FDE. It 33764 should be defined on targets where FDEs need special labels, and it 33765 should write the appropriate label, for the FDE associated with the 33766 function declaration DECL, to the stdio stream STREAM. The third 33767 argument, FOR_EH, is a boolean: true if this is for an exception 33768 table. The fourth argument, EMPTY, is a boolean: true if this is 33769 a placeholder label for an omitted FDE. 33770 33771 The default is that FDEs are not given nonlocal labels. 33772 33773 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 33774 This target hook emits a label at the beginning of the exception 33775 table. It should be defined on targets where it is desirable for 33776 the table to be broken up according to function. 33777 33778 The default is that no label is emitted. 33779 33780 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx 33781 PERSONALITY) 33782 If the target implements `TARGET_ASM_UNWIND_EMIT', this hook may 33783 be used to emit a directive to install a personality hook into the 33784 unwind info. This hook should not be used if dwarf2 unwind info 33785 is used. 33786 33787 -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx INSN) 33788 This target hook emits assembly directives required to unwind the 33789 given instruction. This is only used when 33790 `TARGET_EXCEPT_UNWIND_INFO' returns `UI_TARGET'. 33791 33792 -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN 33793 True if the `TARGET_ASM_UNWIND_EMIT' hook should be called before 33794 the assembly for INSN has been emitted, false if the hook should 33795 be called afterward. 33796 33797 33798 File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 33799 33800 17.21.9 Assembler Commands for Exception Regions 33801 ------------------------------------------------ 33802 33803 This describes commands marking the start and the end of an exception 33804 region. 33805 33806 -- Macro: EH_FRAME_SECTION_NAME 33807 If defined, a C string constant for the name of the section 33808 containing exception handling frame unwind information. If not 33809 defined, GCC will provide a default definition if the target 33810 supports named sections. `crtstuff.c' uses this macro to switch 33811 to the appropriate section. 33812 33813 You should define this symbol if your target supports DWARF 2 frame 33814 unwind information and the default definition does not work. 33815 33816 -- Macro: EH_FRAME_IN_DATA_SECTION 33817 If defined, DWARF 2 frame unwind information will be placed in the 33818 data section even though the target supports named sections. This 33819 might be necessary, for instance, if the system linker does garbage 33820 collection and sections cannot be marked as not to be collected. 33821 33822 Do not define this macro unless `TARGET_ASM_NAMED_SECTION' is also 33823 defined. 33824 33825 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 33826 Define this macro to 1 if your target is such that no frame unwind 33827 information encoding used with non-PIC code will ever require a 33828 runtime relocation, but the linker may not support merging 33829 read-only and read-write sections into a single read-write section. 33830 33831 -- Macro: MASK_RETURN_ADDR 33832 An rtx used to mask the return address found via 33833 `RETURN_ADDR_RTX', so that it does not contain any extraneous set 33834 bits in it. 33835 33836 -- Macro: DWARF2_UNWIND_INFO 33837 Define this macro to 0 if your target supports DWARF 2 frame unwind 33838 information, but it does not yet work with exception handling. 33839 Otherwise, if your target supports this information (if it defines 33840 `INCOMING_RETURN_ADDR_RTX' and either `UNALIGNED_INT_ASM_OP' or 33841 `OBJECT_FORMAT_ELF'), GCC will provide a default definition of 1. 33842 33843 -- Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO 33844 (struct gcc_options *OPTS) 33845 This hook defines the mechanism that will be used for exception 33846 handling by the target. If the target has ABI specified unwind 33847 tables, the hook should return `UI_TARGET'. If the target is to 33848 use the `setjmp'/`longjmp'-based exception handling scheme, the 33849 hook should return `UI_SJLJ'. If the target supports DWARF 2 33850 frame unwind information, the hook should return `UI_DWARF2'. 33851 33852 A target may, if exceptions are disabled, choose to return 33853 `UI_NONE'. This may end up simplifying other parts of 33854 target-specific code. The default implementation of this hook 33855 never returns `UI_NONE'. 33856 33857 Note that the value returned by this hook should be constant. It 33858 should not depend on anything except the command-line switches 33859 described by OPTS. In particular, the setting `UI_SJLJ' must be 33860 fixed at compiler start-up as C pre-processor macros and builtin 33861 functions related to exception handling are set up depending on 33862 this setting. 33863 33864 The default implementation of the hook first honors the 33865 `--enable-sjlj-exceptions' configure option, then 33866 `DWARF2_UNWIND_INFO', and finally defaults to `UI_SJLJ'. If 33867 `DWARF2_UNWIND_INFO' depends on command-line options, the target 33868 must define this hook so that OPTS is used correctly. 33869 33870 -- Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 33871 This variable should be set to `true' if the target ABI requires 33872 unwinding tables even when exceptions are not used. It must not 33873 be modified by command-line option processing. 33874 33875 -- Macro: DONT_USE_BUILTIN_SETJMP 33876 Define this macro to 1 if the `setjmp'/`longjmp'-based scheme 33877 should use the `setjmp'/`longjmp' functions from the C library 33878 instead of the `__builtin_setjmp'/`__builtin_longjmp' machinery. 33879 33880 -- Macro: DWARF_CIE_DATA_ALIGNMENT 33881 This macro need only be defined if the target might save registers 33882 in the function prologue at an offset to the stack pointer that is 33883 not aligned to `UNITS_PER_WORD'. The definition should be the 33884 negative minimum alignment if `STACK_GROWS_DOWNWARD' is defined, 33885 and the positive minimum alignment otherwise. *Note SDB and 33886 DWARF::. Only applicable if the target supports DWARF 2 frame 33887 unwind information. 33888 33889 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 33890 Contains the value true if the target should add a zero word onto 33891 the end of a Dwarf-2 frame info section when used for exception 33892 handling. Default value is false if `EH_FRAME_SECTION_NAME' is 33893 defined, and true otherwise. 33894 33895 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 33896 Given a register, this hook should return a parallel of registers 33897 to represent where to find the register pieces. Define this hook 33898 if the register and its mode are represented in Dwarf in 33899 non-contiguous locations, or if the register should be represented 33900 in more than one register in Dwarf. Otherwise, this hook should 33901 return `NULL_RTX'. If not defined, the default is to return 33902 `NULL_RTX'. 33903 33904 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 33905 If some registers are represented in Dwarf-2 unwind information in 33906 multiple pieces, define this hook to fill in information about the 33907 sizes of those pieces in the table used by the unwinder at runtime. 33908 It will be called by `expand_builtin_init_dwarf_reg_sizes' after 33909 filling in a single size corresponding to each hard register; 33910 ADDRESS is the address of the table. 33911 33912 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 33913 This hook is used to output a reference from a frame unwinding 33914 table to the type_info object identified by SYM. It should return 33915 `true' if the reference was output. Returning `false' will cause 33916 the reference to be output using the normal Dwarf2 routines. 33917 33918 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 33919 This flag should be set to `true' on targets that use an ARM EABI 33920 based unwinding library, and `false' on other targets. This 33921 effects the format of unwinding tables, and how the unwinder in 33922 entered after running a cleanup. The default is `false'. 33923 33924 33925 File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 33926 33927 17.21.10 Assembler Commands for Alignment 33928 ----------------------------------------- 33929 33930 This describes commands for alignment. 33931 33932 -- Macro: JUMP_ALIGN (LABEL) 33933 The alignment (log base 2) to put in front of LABEL, which is a 33934 common destination of jumps and has no fallthru incoming edge. 33935 33936 This macro need not be defined if you don't want any special 33937 alignment to be done at such a time. Most machine descriptions do 33938 not currently define the macro. 33939 33940 Unless it's necessary to inspect the LABEL parameter, it is better 33941 to set the variable ALIGN_JUMPS in the target's 33942 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 33943 user's selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation. 33944 33945 -- Target Hook: int TARGET_ASM_JUMP_ALIGN_MAX_SKIP (rtx LABEL) 33946 The maximum number of bytes to skip before LABEL when applying 33947 `JUMP_ALIGN'. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is 33948 defined. 33949 33950 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 33951 The alignment (log base 2) to put in front of LABEL, which follows 33952 a `BARRIER'. 33953 33954 This macro need not be defined if you don't want any special 33955 alignment to be done at such a time. Most machine descriptions do 33956 not currently define the macro. 33957 33958 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP (rtx 33959 LABEL) 33960 The maximum number of bytes to skip before LABEL when applying 33961 `LABEL_ALIGN_AFTER_BARRIER'. This works only if 33962 `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 33963 33964 -- Macro: LOOP_ALIGN (LABEL) 33965 The alignment (log base 2) to put in front of LABEL, which follows 33966 a `NOTE_INSN_LOOP_BEG' note. 33967 33968 This macro need not be defined if you don't want any special 33969 alignment to be done at such a time. Most machine descriptions do 33970 not currently define the macro. 33971 33972 Unless it's necessary to inspect the LABEL parameter, it is better 33973 to set the variable `align_loops' in the target's 33974 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 33975 user's selection in `align_loops' in a `LOOP_ALIGN' implementation. 33976 33977 -- Target Hook: int TARGET_ASM_LOOP_ALIGN_MAX_SKIP (rtx LABEL) 33978 The maximum number of bytes to skip when applying `LOOP_ALIGN' to 33979 LABEL. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 33980 33981 -- Macro: LABEL_ALIGN (LABEL) 33982 The alignment (log base 2) to put in front of LABEL. If 33983 `LABEL_ALIGN_AFTER_BARRIER' / `LOOP_ALIGN' specify a different 33984 alignment, the maximum of the specified values is used. 33985 33986 Unless it's necessary to inspect the LABEL parameter, it is better 33987 to set the variable `align_labels' in the target's 33988 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 33989 user's selection in `align_labels' in a `LABEL_ALIGN' 33990 implementation. 33991 33992 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_MAX_SKIP (rtx LABEL) 33993 The maximum number of bytes to skip when applying `LABEL_ALIGN' to 33994 LABEL. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 33995 33996 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 33997 A C statement to output to the stdio stream STREAM an assembler 33998 instruction to advance the location counter by NBYTES bytes. 33999 Those bytes should be zero when loaded. NBYTES will be a C 34000 expression of type `unsigned HOST_WIDE_INT'. 34001 34002 -- Macro: ASM_NO_SKIP_IN_TEXT 34003 Define this macro if `ASM_OUTPUT_SKIP' should not be used in the 34004 text section because it fails to put zeros in the bytes that are 34005 skipped. This is true on many Unix systems, where the pseudo-op 34006 to skip bytes produces no-op instructions rather than zeros when 34007 used in the text section. 34008 34009 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 34010 A C statement to output to the stdio stream STREAM an assembler 34011 command to advance the location counter to a multiple of 2 to the 34012 POWER bytes. POWER will be a C expression of type `int'. 34013 34014 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 34015 Like `ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 34016 for padding, if necessary. 34017 34018 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 34019 A C statement to output to the stdio stream STREAM an assembler 34020 command to advance the location counter to a multiple of 2 to the 34021 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 34022 satisfy the alignment request. POWER and MAX_SKIP will be a C 34023 expression of type `int'. 34024 34025 34026 File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 34027 34028 17.22 Controlling Debugging Information Format 34029 ============================================== 34030 34031 This describes how to specify debugging information. 34032 34033 * Menu: 34034 34035 * All Debuggers:: Macros that affect all debugging formats uniformly. 34036 * DBX Options:: Macros enabling specific options in DBX format. 34037 * DBX Hooks:: Hook macros for varying DBX format. 34038 * File Names and DBX:: Macros controlling output of file names in DBX format. 34039 * SDB and DWARF:: Macros for SDB (COFF) and DWARF formats. 34040 * VMS Debug:: Macros for VMS debug format. 34041 34042 34043 File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 34044 34045 17.22.1 Macros Affecting All Debugging Formats 34046 ---------------------------------------------- 34047 34048 These macros affect all debugging formats. 34049 34050 -- Macro: DBX_REGISTER_NUMBER (REGNO) 34051 A C expression that returns the DBX register number for the 34052 compiler register number REGNO. In the default macro provided, 34053 the value of this expression will be REGNO itself. But sometimes 34054 there are some registers that the compiler knows about and DBX 34055 does not, or vice versa. In such cases, some register may need to 34056 have one number in the compiler and another for DBX. 34057 34058 If two registers have consecutive numbers inside GCC, and they can 34059 be used as a pair to hold a multiword value, then they _must_ have 34060 consecutive numbers after renumbering with `DBX_REGISTER_NUMBER'. 34061 Otherwise, debuggers will be unable to access such a pair, because 34062 they expect register pairs to be consecutive in their own 34063 numbering scheme. 34064 34065 If you find yourself defining `DBX_REGISTER_NUMBER' in way that 34066 does not preserve register pairs, then what you must do instead is 34067 redefine the actual register numbering scheme. 34068 34069 -- Macro: DEBUGGER_AUTO_OFFSET (X) 34070 A C expression that returns the integer offset value for an 34071 automatic variable having address X (an RTL expression). The 34072 default computation assumes that X is based on the frame-pointer 34073 and gives the offset from the frame-pointer. This is required for 34074 targets that produce debugging output for DBX or COFF-style 34075 debugging output for SDB and allow the frame-pointer to be 34076 eliminated when the `-g' options is used. 34077 34078 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 34079 A C expression that returns the integer offset value for an 34080 argument having address X (an RTL expression). The nominal offset 34081 is OFFSET. 34082 34083 -- Macro: PREFERRED_DEBUGGING_TYPE 34084 A C expression that returns the type of debugging output GCC should 34085 produce when the user specifies just `-g'. Define this if you 34086 have arranged for GCC to support more than one format of debugging 34087 output. Currently, the allowable values are `DBX_DEBUG', 34088 `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', `XCOFF_DEBUG', 34089 `VMS_DEBUG', and `VMS_AND_DWARF2_DEBUG'. 34090 34091 When the user specifies `-ggdb', GCC normally also uses the value 34092 of this macro to select the debugging output format, but with two 34093 exceptions. If `DWARF2_DEBUGGING_INFO' is defined, GCC uses the 34094 value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is 34095 defined, GCC uses `DBX_DEBUG'. 34096 34097 The value of this macro only affects the default debugging output; 34098 the user can always get a specific type of output by using 34099 `-gstabs', `-gcoff', `-gdwarf-2', `-gxcoff', or `-gvms'. 34100 34101 34102 File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 34103 34104 17.22.2 Specific Options for DBX Output 34105 --------------------------------------- 34106 34107 These are specific options for DBX output. 34108 34109 -- Macro: DBX_DEBUGGING_INFO 34110 Define this macro if GCC should produce debugging output for DBX 34111 in response to the `-g' option. 34112 34113 -- Macro: XCOFF_DEBUGGING_INFO 34114 Define this macro if GCC should produce XCOFF format debugging 34115 output in response to the `-g' option. This is a variant of DBX 34116 format. 34117 34118 -- Macro: DEFAULT_GDB_EXTENSIONS 34119 Define this macro to control whether GCC should by default generate 34120 GDB's extended version of DBX debugging information (assuming 34121 DBX-format debugging information is enabled at all). If you don't 34122 define the macro, the default is 1: always generate the extended 34123 information if there is any occasion to. 34124 34125 -- Macro: DEBUG_SYMS_TEXT 34126 Define this macro if all `.stabs' commands should be output while 34127 in the text section. 34128 34129 -- Macro: ASM_STABS_OP 34130 A C string constant, including spacing, naming the assembler 34131 pseudo op to use instead of `"\t.stabs\t"' to define an ordinary 34132 debugging symbol. If you don't define this macro, `"\t.stabs\t"' 34133 is used. This macro applies only to DBX debugging information 34134 format. 34135 34136 -- Macro: ASM_STABD_OP 34137 A C string constant, including spacing, naming the assembler 34138 pseudo op to use instead of `"\t.stabd\t"' to define a debugging 34139 symbol whose value is the current location. If you don't define 34140 this macro, `"\t.stabd\t"' is used. This macro applies only to 34141 DBX debugging information format. 34142 34143 -- Macro: ASM_STABN_OP 34144 A C string constant, including spacing, naming the assembler 34145 pseudo op to use instead of `"\t.stabn\t"' to define a debugging 34146 symbol with no name. If you don't define this macro, 34147 `"\t.stabn\t"' is used. This macro applies only to DBX debugging 34148 information format. 34149 34150 -- Macro: DBX_NO_XREFS 34151 Define this macro if DBX on your system does not support the 34152 construct `xsTAGNAME'. On some systems, this construct is used to 34153 describe a forward reference to a structure named TAGNAME. On 34154 other systems, this construct is not supported at all. 34155 34156 -- Macro: DBX_CONTIN_LENGTH 34157 A symbol name in DBX-format debugging information is normally 34158 continued (split into two separate `.stabs' directives) when it 34159 exceeds a certain length (by default, 80 characters). On some 34160 operating systems, DBX requires this splitting; on others, 34161 splitting must not be done. You can inhibit splitting by defining 34162 this macro with the value zero. You can override the default 34163 splitting-length by defining this macro as an expression for the 34164 length you desire. 34165 34166 -- Macro: DBX_CONTIN_CHAR 34167 Normally continuation is indicated by adding a `\' character to 34168 the end of a `.stabs' string when a continuation follows. To use 34169 a different character instead, define this macro as a character 34170 constant for the character you want to use. Do not define this 34171 macro if backslash is correct for your system. 34172 34173 -- Macro: DBX_STATIC_STAB_DATA_SECTION 34174 Define this macro if it is necessary to go to the data section 34175 before outputting the `.stabs' pseudo-op for a non-global static 34176 variable. 34177 34178 -- Macro: DBX_TYPE_DECL_STABS_CODE 34179 The value to use in the "code" field of the `.stabs' directive for 34180 a typedef. The default is `N_LSYM'. 34181 34182 -- Macro: DBX_STATIC_CONST_VAR_CODE 34183 The value to use in the "code" field of the `.stabs' directive for 34184 a static variable located in the text section. DBX format does not 34185 provide any "right" way to do this. The default is `N_FUN'. 34186 34187 -- Macro: DBX_REGPARM_STABS_CODE 34188 The value to use in the "code" field of the `.stabs' directive for 34189 a parameter passed in registers. DBX format does not provide any 34190 "right" way to do this. The default is `N_RSYM'. 34191 34192 -- Macro: DBX_REGPARM_STABS_LETTER 34193 The letter to use in DBX symbol data to identify a symbol as a 34194 parameter passed in registers. DBX format does not customarily 34195 provide any way to do this. The default is `'P''. 34196 34197 -- Macro: DBX_FUNCTION_FIRST 34198 Define this macro if the DBX information for a function and its 34199 arguments should precede the assembler code for the function. 34200 Normally, in DBX format, the debugging information entirely 34201 follows the assembler code. 34202 34203 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 34204 Define this macro, with value 1, if the value of a symbol 34205 describing the scope of a block (`N_LBRAC' or `N_RBRAC') should be 34206 relative to the start of the enclosing function. Normally, GCC 34207 uses an absolute address. 34208 34209 -- Macro: DBX_LINES_FUNCTION_RELATIVE 34210 Define this macro, with value 1, if the value of a symbol 34211 indicating the current line number (`N_SLINE') should be relative 34212 to the start of the enclosing function. Normally, GCC uses an 34213 absolute address. 34214 34215 -- Macro: DBX_USE_BINCL 34216 Define this macro if GCC should generate `N_BINCL' and `N_EINCL' 34217 stabs for included header files, as on Sun systems. This macro 34218 also directs GCC to output a type number as a pair of a file 34219 number and a type number within the file. Normally, GCC does not 34220 generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single 34221 number for a type number. 34222 34223 34224 File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 34225 34226 17.22.3 Open-Ended Hooks for DBX Format 34227 --------------------------------------- 34228 34229 These are hooks for DBX format. 34230 34231 -- Macro: DBX_OUTPUT_LBRAC (STREAM, NAME) 34232 Define this macro to say how to output to STREAM the debugging 34233 information for the start of a scope level for variable names. The 34234 argument NAME is the name of an assembler symbol (for use with 34235 `assemble_name') whose value is the address where the scope begins. 34236 34237 -- Macro: DBX_OUTPUT_RBRAC (STREAM, NAME) 34238 Like `DBX_OUTPUT_LBRAC', but for the end of a scope level. 34239 34240 -- Macro: DBX_OUTPUT_NFUN (STREAM, LSCOPE_LABEL, DECL) 34241 Define this macro if the target machine requires special handling 34242 to output an `N_FUN' entry for the function DECL. 34243 34244 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 34245 A C statement to output DBX debugging information before code for 34246 line number LINE of the current source file to the stdio stream 34247 STREAM. COUNTER is the number of time the macro was invoked, 34248 including the current invocation; it is intended to generate 34249 unique labels in the assembly output. 34250 34251 This macro should not be defined if the default output is correct, 34252 or if it can be made correct by defining 34253 `DBX_LINES_FUNCTION_RELATIVE'. 34254 34255 -- Macro: NO_DBX_FUNCTION_END 34256 Some stabs encapsulation formats (in particular ECOFF), cannot 34257 handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 34258 extension construct. On those machines, define this macro to turn 34259 this feature off without disturbing the rest of the gdb extensions. 34260 34261 -- Macro: NO_DBX_BNSYM_ENSYM 34262 Some assemblers cannot handle the `.stabd BNSYM/ENSYM,0,0' gdb dbx 34263 extension construct. On those machines, define this macro to turn 34264 this feature off without disturbing the rest of the gdb extensions. 34265 34266 34267 File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info 34268 34269 17.22.4 File Names in DBX Format 34270 -------------------------------- 34271 34272 This describes file names in DBX format. 34273 34274 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 34275 A C statement to output DBX debugging information to the stdio 34276 stream STREAM, which indicates that file NAME is the main source 34277 file--the file specified as the input file for compilation. This 34278 macro is called only once, at the beginning of compilation. 34279 34280 This macro need not be defined if the standard form of output for 34281 DBX debugging information is appropriate. 34282 34283 It may be necessary to refer to a label equal to the beginning of 34284 the text section. You can use `assemble_name (stream, 34285 ltext_label_name)' to do so. If you do this, you must also set 34286 the variable USED_LTEXT_LABEL_NAME to `true'. 34287 34288 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 34289 Define this macro, with value 1, if GCC should not emit an 34290 indication of the current directory for compilation and current 34291 source language at the beginning of the file. 34292 34293 -- Macro: NO_DBX_GCC_MARKER 34294 Define this macro, with value 1, if GCC should not emit an 34295 indication that this object file was compiled by GCC. The default 34296 is to emit an `N_OPT' stab at the beginning of every source file, 34297 with `gcc2_compiled.' for the string and value 0. 34298 34299 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 34300 A C statement to output DBX debugging information at the end of 34301 compilation of the main source file NAME. Output should be 34302 written to the stdio stream STREAM. 34303 34304 If you don't define this macro, nothing special is output at the 34305 end of compilation, which is correct for most machines. 34306 34307 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 34308 Define this macro _instead of_ defining 34309 `DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 34310 the end of compilation is an `N_SO' stab with an empty string, 34311 whose value is the highest absolute text address in the file. 34312 34313 34314 File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 34315 34316 17.22.5 Macros for SDB and DWARF Output 34317 --------------------------------------- 34318 34319 Here are macros for SDB and DWARF output. 34320 34321 -- Macro: SDB_DEBUGGING_INFO 34322 Define this macro if GCC should produce COFF-style debugging output 34323 for SDB in response to the `-g' option. 34324 34325 -- Macro: DWARF2_DEBUGGING_INFO 34326 Define this macro if GCC should produce dwarf version 2 format 34327 debugging output in response to the `-g' option. 34328 34329 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 34330 FUNCTION) 34331 Define this to enable the dwarf attribute 34332 `DW_AT_calling_convention' to be emitted for each function. 34333 Instead of an integer return the enum value for the `DW_CC_' 34334 tag. 34335 34336 To support optional call frame debugging information, you must also 34337 define `INCOMING_RETURN_ADDR_RTX' and either set 34338 `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 34339 prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as 34340 appropriate from `TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 34341 34342 -- Macro: DWARF2_FRAME_INFO 34343 Define this macro to a nonzero value if GCC should always output 34344 Dwarf 2 frame information. If `TARGET_EXCEPT_UNWIND_INFO' (*note 34345 Exception Region Output::) returns `UI_DWARF2', and exceptions are 34346 enabled, GCC will output this information not matter how you 34347 define `DWARF2_FRAME_INFO'. 34348 34349 -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void) 34350 This hook defines the mechanism that will be used for describing 34351 frame unwind information to the debugger. Normally the hook will 34352 return `UI_DWARF2' if DWARF 2 debug information is enabled, and 34353 return `UI_NONE' otherwise. 34354 34355 A target may return `UI_DWARF2' even when DWARF 2 debug information 34356 is disabled in order to always output DWARF 2 frame information. 34357 34358 A target may return `UI_TARGET' if it has ABI specified unwind 34359 tables. This will suppress generation of the normal debug frame 34360 unwind information. 34361 34362 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 34363 Define this macro to be a nonzero value if the assembler can 34364 generate Dwarf 2 line debug info sections. This will result in 34365 much more compact line number tables, and hence is desirable if it 34366 works. 34367 34368 -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS 34369 True if the `.debug_pubtypes' and `.debug_pubnames' sections 34370 should be emitted. These sections are not used on most platforms, 34371 and in particular GDB does not use them. 34372 34373 -- Target Hook: bool TARGET_DELAY_SCHED2 34374 True if sched2 is not to be run at its normal place. This usually 34375 means it will be run as part of machine-specific reorg. 34376 34377 -- Target Hook: bool TARGET_DELAY_VARTRACK 34378 True if vartrack is not to be run at its normal place. This 34379 usually means it will be run as part of machine-specific reorg. 34380 34381 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 34382 A C statement to issue assembly directives that create a difference 34383 LAB1 minus LAB2, using an integer of the given SIZE. 34384 34385 -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2) 34386 A C statement to issue assembly directives that create a difference 34387 between the two given labels in system defined units, e.g. 34388 instruction slots on IA64 VMS, using an integer of the given size. 34389 34390 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, SECTION) 34391 A C statement to issue assembly directives that create a 34392 section-relative reference to the given LABEL, using an integer of 34393 the given SIZE. The label is known to be defined in the given 34394 SECTION. 34395 34396 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 34397 A C statement to issue assembly directives that create a 34398 self-relative reference to the given LABEL, using an integer of 34399 the given SIZE. 34400 34401 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 34402 A C statement to issue assembly directives that create a reference 34403 to the DWARF table identifier LABEL from the current section. This 34404 is used on some systems to avoid garbage collecting a DWARF table 34405 which is referenced by a function. 34406 34407 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 34408 SIZE, rtx X) 34409 If defined, this target hook is a function which outputs a 34410 DTP-relative reference to the given TLS symbol of the specified 34411 size. 34412 34413 -- Macro: PUT_SDB_... 34414 Define these macros to override the assembler syntax for the 34415 special SDB assembler directives. See `sdbout.c' for a list of 34416 these macros and their arguments. If the standard syntax is used, 34417 you need not define them yourself. 34418 34419 -- Macro: SDB_DELIM 34420 Some assemblers do not support a semicolon as a delimiter, even 34421 between SDB assembler directives. In that case, define this macro 34422 to be the delimiter to use (usually `\n'). It is not necessary to 34423 define a new set of `PUT_SDB_OP' macros if this is the only change 34424 required. 34425 34426 -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES 34427 Define this macro to allow references to unknown structure, union, 34428 or enumeration tags to be emitted. Standard COFF does not allow 34429 handling of unknown references, MIPS ECOFF has support for it. 34430 34431 -- Macro: SDB_ALLOW_FORWARD_REFERENCES 34432 Define this macro to allow references to structure, union, or 34433 enumeration tags that have not yet been seen to be handled. Some 34434 assemblers choke if forward tags are used, while some require it. 34435 34436 -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE) 34437 A C statement to output SDB debugging information before code for 34438 line number LINE of the current source file to the stdio stream 34439 STREAM. The default is to emit an `.ln' directive. 34440 34441 34442 File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info 34443 34444 17.22.6 Macros for VMS Debug Format 34445 ----------------------------------- 34446 34447 Here are macros for VMS debug format. 34448 34449 -- Macro: VMS_DEBUGGING_INFO 34450 Define this macro if GCC should produce debugging output for VMS 34451 in response to the `-g' option. The default behavior for VMS is 34452 to generate minimal debug info for a traceback in the absence of 34453 `-g' unless explicitly overridden with `-g0'. This behavior is 34454 controlled by `TARGET_OPTION_OPTIMIZATION' and 34455 `TARGET_OPTION_OVERRIDE'. 34456 34457 34458 File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 34459 34460 17.23 Cross Compilation and Floating Point 34461 ========================================== 34462 34463 While all modern machines use twos-complement representation for 34464 integers, there are a variety of representations for floating point 34465 numbers. This means that in a cross-compiler the representation of 34466 floating point numbers in the compiled program may be different from 34467 that used in the machine doing the compilation. 34468 34469 Because different representation systems may offer different amounts of 34470 range and precision, all floating point constants must be represented in 34471 the target machine's format. Therefore, the cross compiler cannot 34472 safely use the host machine's floating point arithmetic; it must emulate 34473 the target's arithmetic. To ensure consistency, GCC always uses 34474 emulation to work with floating point values, even when the host and 34475 target floating point formats are identical. 34476 34477 The following macros are provided by `real.h' for the compiler to use. 34478 All parts of the compiler which generate or optimize floating-point 34479 calculations must use these macros. They may evaluate their operands 34480 more than once, so operands must not have side effects. 34481 34482 -- Macro: REAL_VALUE_TYPE 34483 The C data type to be used to hold a floating point value in the 34484 target machine's format. Typically this is a `struct' containing 34485 an array of `HOST_WIDE_INT', but all code should treat it as an 34486 opaque quantity. 34487 34488 -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 34489 Compares for equality the two values, X and Y. If the target 34490 floating point format supports negative zeroes and/or NaNs, 34491 `REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and `REAL_VALUES_EQUAL 34492 (NaN, NaN)' is false. 34493 34494 -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 34495 Tests whether X is less than Y. 34496 34497 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 34498 Truncates X to a signed integer, rounding toward zero. 34499 34500 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 34501 (REAL_VALUE_TYPE X) 34502 Truncates X to an unsigned integer, rounding toward zero. If X is 34503 negative, returns zero. 34504 34505 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum 34506 machine_mode MODE) 34507 Converts STRING into a floating point number in the target 34508 machine's representation for mode MODE. This routine can handle 34509 both decimal and hexadecimal floating point constants, using the 34510 syntax defined by the C language for both. 34511 34512 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 34513 Returns 1 if X is negative (including negative zero), 0 otherwise. 34514 34515 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 34516 Determines whether X represents infinity (positive or negative). 34517 34518 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 34519 Determines whether X represents a "NaN" (not-a-number). 34520 34521 -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code 34522 CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 34523 Calculates an arithmetic operation on the two floating point values 34524 X and Y, storing the result in OUTPUT (which must be a variable). 34525 34526 The operation to be performed is specified by CODE. Only the 34527 following codes are supported: `PLUS_EXPR', `MINUS_EXPR', 34528 `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'. 34529 34530 If `REAL_ARITHMETIC' is asked to evaluate division by zero and the 34531 target's floating point format cannot represent infinity, it will 34532 call `abort'. Callers should check for this situation first, using 34533 `MODE_HAS_INFINITIES'. *Note Storage Layout::. 34534 34535 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 34536 Returns the negative of the floating point value X. 34537 34538 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 34539 Returns the absolute value of X. 34540 34541 -- Macro: REAL_VALUE_TYPE REAL_VALUE_TRUNCATE (REAL_VALUE_TYPE MODE, 34542 enum machine_mode X) 34543 Truncates the floating point value X to fit in MODE. The return 34544 value is still a full-size `REAL_VALUE_TYPE', but it has an 34545 appropriate bit pattern to be output as a floating constant whose 34546 precision accords with mode MODE. 34547 34548 -- Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT 34549 HIGH, REAL_VALUE_TYPE X) 34550 Converts a floating point value X into a double-precision integer 34551 which is then stored into LOW and HIGH. If the value is not 34552 integral, it is truncated. 34553 34554 -- Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT 34555 LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE) 34556 Converts a double-precision integer found in LOW and HIGH, into a 34557 floating point value which is then stored into X. The value is 34558 truncated to fit in mode MODE. 34559 34560 34561 File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 34562 34563 17.24 Mode Switching Instructions 34564 ================================= 34565 34566 The following macros control mode switching optimizations: 34567 34568 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 34569 Define this macro if the port needs extra instructions inserted 34570 for mode switching in an optimizing compilation. 34571 34572 For an example, the SH4 can perform both single and double 34573 precision floating point operations, but to perform a single 34574 precision operation, the FPSCR PR bit has to be cleared, while for 34575 a double precision operation, this bit has to be set. Changing 34576 the PR bit requires a general purpose register as a scratch 34577 register, hence these FPSCR sets have to be inserted before 34578 reload, i.e. you can't put this into instruction emitting or 34579 `TARGET_MACHINE_DEPENDENT_REORG'. 34580 34581 You can have multiple entities that are mode-switched, and select 34582 at run time which entities actually need it. 34583 `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY 34584 that needs mode-switching. If you define this macro, you also 34585 have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED', 34586 `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'. `MODE_AFTER', 34587 `MODE_ENTRY', and `MODE_EXIT' are optional. 34588 34589 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 34590 If you define `OPTIMIZE_MODE_SWITCHING', you have to define this as 34591 initializer for an array of integers. Each initializer element N 34592 refers to an entity that needs mode switching, and specifies the 34593 number of different modes that might need to be set for this 34594 entity. The position of the initializer in the 34595 initializer--starting counting at zero--determines the integer 34596 that is used to refer to the mode-switched entity in question. In 34597 macros that take mode arguments / yield a mode result, modes are 34598 represented as numbers 0 ... N - 1. N is used to specify that no 34599 mode switch is needed / supplied. 34600 34601 -- Macro: MODE_NEEDED (ENTITY, INSN) 34602 ENTITY is an integer specifying a mode-switched entity. If 34603 `OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 34604 return an integer value not larger than the corresponding element 34605 in `NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 34606 must be switched into prior to the execution of INSN. 34607 34608 -- Macro: MODE_AFTER (MODE, INSN) 34609 If this macro is defined, it is evaluated for every INSN during 34610 mode switching. It determines the mode that an insn results in (if 34611 different from the incoming mode). 34612 34613 -- Macro: MODE_ENTRY (ENTITY) 34614 If this macro is defined, it is evaluated for every ENTITY that 34615 needs mode switching. It should evaluate to an integer, which is 34616 a mode that ENTITY is assumed to be switched to at function entry. 34617 If `MODE_ENTRY' is defined then `MODE_EXIT' must be defined. 34618 34619 -- Macro: MODE_EXIT (ENTITY) 34620 If this macro is defined, it is evaluated for every ENTITY that 34621 needs mode switching. It should evaluate to an integer, which is 34622 a mode that ENTITY is assumed to be switched to at function exit. 34623 If `MODE_EXIT' is defined then `MODE_ENTRY' must be defined. 34624 34625 -- Macro: MODE_PRIORITY_TO_MODE (ENTITY, N) 34626 This macro specifies the order in which modes for ENTITY are 34627 processed. 0 is the highest priority, 34628 `NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 34629 of the macro should be an integer designating a mode for ENTITY. 34630 For any fixed ENTITY, `mode_priority_to_mode' (ENTITY, N) shall be 34631 a bijection in 0 ... `num_modes_for_mode_switching[ENTITY] - 1'. 34632 34633 -- Macro: EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE) 34634 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE 34635 is the set of hard registers live at the point where the insn(s) 34636 are to be inserted. 34637 34638 34639 File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 34640 34641 17.25 Defining target-specific uses of `__attribute__' 34642 ====================================================== 34643 34644 Target-specific attributes may be defined for functions, data and types. 34645 These are described using the following target hooks; they also need to 34646 be documented in `extend.texi'. 34647 34648 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 34649 If defined, this target hook points to an array of `struct 34650 attribute_spec' (defined in `tree.h') specifying the machine 34651 specific attributes for this target and some of the restrictions 34652 on the entities to which these attributes are applied and the 34653 arguments they take. 34654 34655 -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree 34656 NAME) 34657 If defined, this target hook is a function which returns true if 34658 the machine-specific attribute named NAME expects an identifier 34659 given as its first argument to be passed on as a plain identifier, 34660 not subjected to name lookup. If this is not defined, the default 34661 is false for all machine-specific attributes. 34662 34663 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 34664 const_tree TYPE2) 34665 If defined, this target hook is a function which returns zero if 34666 the attributes on TYPE1 and TYPE2 are incompatible, one if they 34667 are compatible, and two if they are nearly compatible (which 34668 causes a warning to be generated). If this is not defined, 34669 machine-specific attributes are supposed always to be compatible. 34670 34671 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 34672 If defined, this target hook is a function which assigns default 34673 attributes to the newly defined TYPE. 34674 34675 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 34676 TYPE2) 34677 Define this target hook if the merging of type attributes needs 34678 special handling. If defined, the result is a list of the combined 34679 `TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 34680 `comptypes' has already been called and returned 1. This function 34681 may call `merge_attributes' to handle machine-independent merging. 34682 34683 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 34684 NEWDECL) 34685 Define this target hook if the merging of decl attributes needs 34686 special handling. If defined, the result is a list of the combined 34687 `DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 34688 declaration of OLDDECL. Examples of when this is needed are when 34689 one attribute overrides another, or when an attribute is nullified 34690 by a subsequent definition. This function may call 34691 `merge_attributes' to handle machine-independent merging. 34692 34693 If the only target-specific handling you require is `dllimport' 34694 for Microsoft Windows targets, you should define the macro 34695 `TARGET_DLLIMPORT_DECL_ATTRIBUTES' to `1'. The compiler will then 34696 define a function called `merge_dllimport_decl_attributes' which 34697 can then be defined as the expansion of 34698 `TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 34699 `handle_dll_attribute' in the attribute table for your port to 34700 perform initial processing of the `dllimport' and `dllexport' 34701 attributes. This is done in `i386/cygwin.h' and `i386/i386.c', 34702 for example. 34703 34704 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 34705 DECL) 34706 DECL is a variable or function with `__attribute__((dllimport))' 34707 specified. Use this hook if the target needs to add extra 34708 validation checks to `handle_dll_attribute'. 34709 34710 -- Macro: TARGET_DECLSPEC 34711 Define this macro to a nonzero value if you want to treat 34712 `__declspec(X)' as equivalent to `__attribute((X))'. By default, 34713 this behavior is enabled only for targets that define 34714 `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 34715 `__declspec' is via a built-in macro, but you should not rely on 34716 this implementation detail. 34717 34718 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 34719 *ATTR_PTR) 34720 Define this target hook if you want to be able to add attributes 34721 to a decl when it is being created. This is normally useful for 34722 back ends which wish to implement a pragma by using the attributes 34723 which correspond to the pragma's effect. The NODE argument is the 34724 decl which is being created. The ATTR_PTR argument is a pointer 34725 to the attribute list for this decl. The list itself should not 34726 be modified, since it may be shared with other decls, but 34727 attributes may be chained on the head of the list and `*ATTR_PTR' 34728 modified to point to the new attributes, or a copy of the list may 34729 be made if further changes are needed. 34730 34731 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 34732 FNDECL) 34733 This target hook returns `true' if it is ok to inline FNDECL into 34734 the current function, despite its having target-specific 34735 attributes, `false' otherwise. By default, if a function has a 34736 target specific attribute attached to it, it will not be inlined. 34737 34738 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, 34739 tree NAME, tree ARGS, int FLAGS) 34740 This hook is called to parse the `attribute(option("..."))', and 34741 it allows the function to set different target machine compile time 34742 options for the current function that might be different than the 34743 options specified on the command line. The hook should return 34744 `true' if the options are valid. 34745 34746 The hook should set the DECL_FUNCTION_SPECIFIC_TARGET field in the 34747 function declaration to hold a pointer to a target specific STRUCT 34748 CL_TARGET_OPTION structure. 34749 34750 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR) 34751 This hook is called to save any additional target specific 34752 information in the STRUCT CL_TARGET_OPTION structure for function 34753 specific options. *Note Option file format::. 34754 34755 -- Target Hook: void TARGET_OPTION_RESTORE (struct cl_target_option 34756 *PTR) 34757 This hook is called to restore any additional target specific 34758 information in the STRUCT CL_TARGET_OPTION structure for function 34759 specific options. 34760 34761 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 34762 struct cl_target_option *PTR) 34763 This hook is called to print any additional target specific 34764 information in the STRUCT CL_TARGET_OPTION structure for function 34765 specific options. 34766 34767 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree 34768 POP_TARGET) 34769 This target hook parses the options for `#pragma GCC option' to 34770 set the machine specific options for functions that occur later in 34771 the input stream. The options should be the same as handled by the 34772 `TARGET_OPTION_VALID_ATTRIBUTE_P' hook. 34773 34774 -- Target Hook: void TARGET_OPTION_OVERRIDE (void) 34775 Sometimes certain combinations of command options do not make 34776 sense on a particular target machine. You can override the hook 34777 `TARGET_OPTION_OVERRIDE' to take account of this. This hooks is 34778 called once just after all the command options have been parsed. 34779 34780 Don't use this hook to turn on various extra optimizations for 34781 `-O'. That is what `TARGET_OPTION_OPTIMIZATION' is for. 34782 34783 If you need to do something whenever the optimization level is 34784 changed via the optimize attribute or pragma, see 34785 `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 34786 34787 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 34788 This target hook returns `false' if the CALLER function cannot 34789 inline CALLEE, based on target specific information. By default, 34790 inlining is not allowed if the callee function has function 34791 specific target options and the caller does not use the same 34792 options. 34793 34794 34795 File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 34796 34797 17.26 Emulating TLS 34798 =================== 34799 34800 For targets whose psABI does not provide Thread Local Storage via 34801 specific relocations and instruction sequences, an emulation layer is 34802 used. A set of target hooks allows this emulation layer to be 34803 configured for the requirements of a particular target. For instance 34804 the psABI may in fact specify TLS support in terms of an emulation 34805 layer. 34806 34807 The emulation layer works by creating a control object for every TLS 34808 object. To access the TLS object, a lookup function is provided which, 34809 when given the address of the control object, will return the address 34810 of the current thread's instance of the TLS object. 34811 34812 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 34813 Contains the name of the helper function that uses a TLS control 34814 object to locate a TLS instance. The default causes libgcc's 34815 emulated TLS helper function to be used. 34816 34817 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 34818 Contains the name of the helper function that should be used at 34819 program startup to register TLS objects that are implicitly 34820 initialized to zero. If this is `NULL', all TLS objects will have 34821 explicit initializers. The default causes libgcc's emulated TLS 34822 registration function to be used. 34823 34824 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 34825 Contains the name of the section in which TLS control variables 34826 should be placed. The default of `NULL' allows these to be placed 34827 in any section. 34828 34829 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 34830 Contains the name of the section in which TLS initializers should 34831 be placed. The default of `NULL' allows these to be placed in any 34832 section. 34833 34834 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 34835 Contains the prefix to be prepended to TLS control variable names. 34836 The default of `NULL' uses a target-specific prefix. 34837 34838 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 34839 Contains the prefix to be prepended to TLS initializer objects. 34840 The default of `NULL' uses a target-specific prefix. 34841 34842 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 34843 Specifies a function that generates the FIELD_DECLs for a TLS 34844 control object type. TYPE is the RECORD_TYPE the fields are for 34845 and NAME should be filled with the structure tag, if the default of 34846 `__emutls_object' is unsuitable. The default creates a type 34847 suitable for libgcc's emulated TLS function. 34848 34849 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 34850 TMPL_ADDR) 34851 Specifies a function that generates the CONSTRUCTOR to initialize a 34852 TLS control object. VAR is the TLS control object, DECL is the 34853 TLS object and TMPL_ADDR is the address of the initializer. The 34854 default initializes libgcc's emulated TLS control object. 34855 34856 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 34857 Specifies whether the alignment of TLS control variable objects is 34858 fixed and should not be increased as some backends may do to 34859 optimize single objects. The default is false. 34860 34861 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 34862 Specifies whether a DWARF `DW_OP_form_tls_address' location 34863 descriptor may be used to describe emulated TLS control objects. 34864 34865 34866 File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 34867 34868 17.27 Defining coprocessor specifics for MIPS targets. 34869 ====================================================== 34870 34871 The MIPS specification allows MIPS implementations to have as many as 4 34872 coprocessors, each with as many as 32 private registers. GCC supports 34873 accessing these registers and transferring values between the registers 34874 and memory using asm-ized variables. For example: 34875 34876 register unsigned int cp0count asm ("c0r1"); 34877 unsigned int d; 34878 34879 d = cp0count + 3; 34880 34881 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 34882 names may be added as described below, or the default names may be 34883 overridden entirely in `SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 34884 34885 Coprocessor registers are assumed to be epilogue-used; sets to them 34886 will be preserved even if it does not appear that the register is used 34887 again later in the function. 34888 34889 Another note: according to the MIPS spec, coprocessor 1 (if present) is 34890 the FPU. One accesses COP1 registers through standard mips 34891 floating-point support; they are not included in this mechanism. 34892 34893 There is one macro used in defining the MIPS coprocessor interface 34894 which you may want to override in subtargets; it is described below. 34895 34896 -- Macro: ALL_COP_ADDITIONAL_REGISTER_NAMES 34897 A comma-separated list (with leading comma) of pairs describing the 34898 alternate names of coprocessor registers. The format of each 34899 entry should be 34900 { ALTERNATENAME, REGISTER_NUMBER} 34901 Default: empty. 34902 34903 34904 File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 34905 34906 17.28 Parameters for Precompiled Header Validity Checking 34907 ========================================================= 34908 34909 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 34910 This hook returns a pointer to the data needed by 34911 `TARGET_PCH_VALID_P' and sets `*SZ' to the size of the data in 34912 bytes. 34913 34914 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 34915 size_t SZ) 34916 This hook checks whether the options used to create a PCH file are 34917 compatible with the current settings. It returns `NULL' if so and 34918 a suitable error message if not. Error messages will be presented 34919 to the user and must be localized using `_(MSG)'. 34920 34921 DATA is the data that was returned by `TARGET_GET_PCH_VALIDITY' 34922 when the PCH file was created and SZ is the size of that data in 34923 bytes. It's safe to assume that the data was created by the same 34924 version of the compiler, so no format checking is needed. 34925 34926 The default definition of `default_pch_valid_p' should be suitable 34927 for most targets. 34928 34929 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 34930 PCH_FLAGS) 34931 If this hook is nonnull, the default implementation of 34932 `TARGET_PCH_VALID_P' will use it to check for compatible values of 34933 `target_flags'. PCH_FLAGS specifies the value that `target_flags' 34934 had when the PCH file was created. The return value is the same 34935 as for `TARGET_PCH_VALID_P'. 34936 34937 34938 File: gccint.info, Node: C++ ABI, Next: Named Address Spaces, Prev: PCH Target, Up: Target Macros 34939 34940 17.29 C++ ABI parameters 34941 ======================== 34942 34943 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 34944 Define this hook to override the integer type used for guard 34945 variables. These are used to implement one-time construction of 34946 static objects. The default is long_long_integer_type_node. 34947 34948 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 34949 This hook determines how guard variables are used. It should 34950 return `false' (the default) if the first byte should be used. A 34951 return value of `true' indicates that only the least significant 34952 bit should be used. 34953 34954 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 34955 This hook returns the size of the cookie to use when allocating an 34956 array whose elements have the indicated TYPE. Assumes that it is 34957 already known that a cookie is needed. The default is `max(sizeof 34958 (size_t), alignof(type))', as defined in section 2.7 of the 34959 IA64/Generic C++ ABI. 34960 34961 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 34962 This hook should return `true' if the element size should be 34963 stored in array cookies. The default is to return `false'. 34964 34965 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 34966 IMPORT_EXPORT) 34967 If defined by a backend this hook allows the decision made to 34968 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 34969 contain 1 if the class is going to be exported, -1 if it is going 34970 to be imported and 0 otherwise. This function should return the 34971 modified value and perform any other actions necessary to support 34972 the backend's targeted operating system. 34973 34974 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 34975 This hook should return `true' if constructors and destructors 34976 return the address of the object created/destroyed. The default 34977 is to return `false'. 34978 34979 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 34980 This hook returns true if the key method for a class (i.e., the 34981 method which, if defined in the current translation unit, causes 34982 the virtual table to be emitted) may be an inline function. Under 34983 the standard Itanium C++ ABI the key method may be an inline 34984 function so long as the function is not declared inline in the 34985 class definition. Under some variants of the ABI, an inline 34986 function can never be the key method. The default is to return 34987 `true'. 34988 34989 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 34990 DECL) 34991 DECL is a virtual table, virtual table table, typeinfo object, or 34992 other similar implicit class data object that will be emitted with 34993 external linkage in this translation unit. No ELF visibility has 34994 been explicitly specified. If the target needs to specify a 34995 visibility other than that of the containing class, use this hook 34996 to set `DECL_VISIBILITY' and `DECL_VISIBILITY_SPECIFIED'. 34997 34998 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 34999 This hook returns true (the default) if virtual tables and other 35000 similar implicit class data objects are always COMDAT if they have 35001 external linkage. If this hook returns false, then class data for 35002 classes whose virtual table will be emitted in only one translation 35003 unit will not be COMDAT. 35004 35005 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 35006 This hook returns true (the default) if the RTTI information for 35007 the basic types which is defined in the C++ runtime should always 35008 be COMDAT, false if it should not be COMDAT. 35009 35010 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 35011 This hook returns true if `__aeabi_atexit' (as defined by the ARM 35012 EABI) should be used to register static destructors when 35013 `-fuse-cxa-atexit' is in effect. The default is to return false 35014 to use `__cxa_atexit'. 35015 35016 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 35017 This hook returns true if the target `atexit' function can be used 35018 in the same manner as `__cxa_atexit' to register C++ static 35019 destructors. This requires that `atexit'-registered functions in 35020 shared libraries are run in the correct order when the libraries 35021 are unloaded. The default is to return false. 35022 35023 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 35024 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has 35025 just been defined. Use this hook to make adjustments to the class 35026 (eg, tweak visibility or perform any other required target 35027 modifications). 35028 35029 35030 File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: C++ ABI, Up: Target Macros 35031 35032 17.30 Adding support for named address spaces 35033 ============================================= 35034 35035 The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 35036 committee, `Programming Languages - C - Extensions to support embedded 35037 processors', specifies a syntax for embedded processors to specify 35038 alternate address spaces. You can configure a GCC port to support 35039 section 5.1 of the draft report to add support for address spaces other 35040 than the default address space. These address spaces are new keywords 35041 that are similar to the `volatile' and `const' type attributes. 35042 35043 Pointers to named address spaces can have a different size than 35044 pointers to the generic address space. 35045 35046 For example, the SPU port uses the `__ea' address space to refer to 35047 memory in the host processor, rather than memory local to the SPU 35048 processor. Access to memory in the `__ea' address space involves 35049 issuing DMA operations to move data between the host processor and the 35050 local processor memory address space. Pointers in the `__ea' address 35051 space are either 32 bits or 64 bits based on the `-mea32' or `-mea64' 35052 switches (native SPU pointers are always 32 bits). 35053 35054 Internally, address spaces are represented as a small integer in the 35055 range 0 to 15 with address space 0 being reserved for the generic 35056 address space. 35057 35058 To register a named address space qualifier keyword with the C front 35059 end, the target may call the `c_register_addr_space' routine. For 35060 example, the SPU port uses the following to declare `__ea' as the 35061 keyword for named address space #1: 35062 #define ADDR_SPACE_EA 1 35063 c_register_addr_space ("__ea", ADDR_SPACE_EA); 35064 35065 -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_POINTER_MODE 35066 (addr_space_t ADDRESS_SPACE) 35067 Define this to return the machine mode to use for pointers to 35068 ADDRESS_SPACE if the target supports named address spaces. The 35069 default version of this hook returns `ptr_mode' for the generic 35070 address space only. 35071 35072 -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_ADDRESS_MODE 35073 (addr_space_t ADDRESS_SPACE) 35074 Define this to return the machine mode to use for addresses in 35075 ADDRESS_SPACE if the target supports named address spaces. The 35076 default version of this hook returns `Pmode' for the generic 35077 address space only. 35078 35079 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE (enum 35080 machine_mode MODE, addr_space_t AS) 35081 Define this to return nonzero if the port can handle pointers with 35082 machine mode MODE to address space AS. This target hook is the 35083 same as the `TARGET_VALID_POINTER_MODE' target hook, except that 35084 it includes explicit named address space support. The default 35085 version of this hook returns true for the modes returned by either 35086 the `TARGET_ADDR_SPACE_POINTER_MODE' or 35087 `TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given 35088 address space. 35089 35090 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P (enum 35091 machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 35092 Define this to return true if EXP is a valid address for mode MODE 35093 in the named address space AS. The STRICT parameter says whether 35094 strict addressing is in effect after reload has finished. This 35095 target hook is the same as the `TARGET_LEGITIMATE_ADDRESS_P' 35096 target hook, except that it includes explicit named address space 35097 support. 35098 35099 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 35100 OLDX, enum machine_mode MODE, addr_space_t AS) 35101 Define this to modify an invalid address X to be a valid address 35102 with mode MODE in the named address space AS. This target hook is 35103 the same as the `TARGET_LEGITIMIZE_ADDRESS' target hook, except 35104 that it includes explicit named address space support. 35105 35106 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t 35107 SUPERSET, addr_space_t SUBSET) 35108 Define this to return whether the SUBSET named address space is 35109 contained within the SUPERSET named address space. Pointers to a 35110 named address space that is a subset of another named address space 35111 will be converted automatically without a cast if used together in 35112 arithmetic operations. Pointers to a superset address space can be 35113 converted to pointers to a subset address space via explicit casts. 35114 35115 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 35116 tree TO_TYPE) 35117 Define this to convert the pointer expression represented by the 35118 RTL OP with type FROM_TYPE that points to a named address space to 35119 a new pointer expression with type TO_TYPE that points to a 35120 different named address space. When this hook it called, it is 35121 guaranteed that one of the two address spaces is a subset of the 35122 other, as determined by the `TARGET_ADDR_SPACE_SUBSET_P' target 35123 hook. 35124 35125 35126 File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 35127 35128 17.31 Miscellaneous Parameters 35129 ============================== 35130 35131 Here are several miscellaneous parameters. 35132 35133 -- Macro: HAS_LONG_COND_BRANCH 35134 Define this boolean macro to indicate whether or not your 35135 architecture has conditional branches that can span all of memory. 35136 It is used in conjunction with an optimization that partitions hot 35137 and cold basic blocks into separate sections of the executable. 35138 If this macro is set to false, gcc will convert any conditional 35139 branches that attempt to cross between sections into unconditional 35140 branches or indirect jumps. 35141 35142 -- Macro: HAS_LONG_UNCOND_BRANCH 35143 Define this boolean macro to indicate whether or not your 35144 architecture has unconditional branches that can span all of 35145 memory. It is used in conjunction with an optimization that 35146 partitions hot and cold basic blocks into separate sections of the 35147 executable. If this macro is set to false, gcc will convert any 35148 unconditional branches that attempt to cross between sections into 35149 indirect jumps. 35150 35151 -- Macro: CASE_VECTOR_MODE 35152 An alias for a machine mode name. This is the machine mode that 35153 elements of a jump-table should have. 35154 35155 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 35156 Optional: return the preferred mode for an `addr_diff_vec' when 35157 the minimum and maximum offset are known. If you define this, it 35158 enables extra code in branch shortening to deal with 35159 `addr_diff_vec'. To make this work, you also have to define 35160 `INSN_ALIGN' and make the alignment for `addr_diff_vec' explicit. 35161 The BODY argument is provided so that the offset_unsigned and scale 35162 flags can be updated. 35163 35164 -- Macro: CASE_VECTOR_PC_RELATIVE 35165 Define this macro to be a C expression to indicate when jump-tables 35166 should contain relative addresses. You need not define this macro 35167 if jump-tables never contain relative addresses, or jump-tables 35168 should contain relative addresses only when `-fPIC' or `-fPIC' is 35169 in effect. 35170 35171 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 35172 This function return the smallest number of different values for 35173 which it is best to use a jump-table instead of a tree of 35174 conditional branches. The default is four for machines with a 35175 `casesi' instruction and five otherwise. This is best for most 35176 machines. 35177 35178 -- Macro: CASE_USE_BIT_TESTS 35179 Define this macro to be a C expression to indicate whether C switch 35180 statements may be implemented by a sequence of bit tests. This is 35181 advantageous on processors that can efficiently implement left 35182 shift of 1 by the number of bits held in a register, but 35183 inappropriate on targets that would require a loop. By default, 35184 this macro returns `true' if the target defines an `ashlsi3' 35185 pattern, and `false' otherwise. 35186 35187 -- Macro: WORD_REGISTER_OPERATIONS 35188 Define this macro if operations between registers with integral 35189 mode smaller than a word are always performed on the entire 35190 register. Most RISC machines have this property and most CISC 35191 machines do not. 35192 35193 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 35194 Define this macro to be a C expression indicating when insns that 35195 read memory in MEM_MODE, an integral mode narrower than a word, 35196 set the bits outside of MEM_MODE to be either the sign-extension 35197 or the zero-extension of the data read. Return `SIGN_EXTEND' for 35198 values of MEM_MODE for which the insn sign-extends, `ZERO_EXTEND' 35199 for which it zero-extends, and `UNKNOWN' for other modes. 35200 35201 This macro is not called with MEM_MODE non-integral or with a width 35202 greater than or equal to `BITS_PER_WORD', so you may return any 35203 value in this case. Do not define this macro if it would always 35204 return `UNKNOWN'. On machines where this macro is defined, you 35205 will normally define it as the constant `SIGN_EXTEND' or 35206 `ZERO_EXTEND'. 35207 35208 You may return a non-`UNKNOWN' value even if for some hard 35209 registers the sign extension is not performed, if for the 35210 `REGNO_REG_CLASS' of these hard registers 35211 `CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is 35212 MEM_MODE and the TO mode is any integral mode larger than this but 35213 not larger than `word_mode'. 35214 35215 You must return `UNKNOWN' if for some hard registers that allow 35216 this mode, `CANNOT_CHANGE_MODE_CLASS' says that they cannot change 35217 to `word_mode', but that they can change to another integral mode 35218 that is larger then MEM_MODE but still smaller than `word_mode'. 35219 35220 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 35221 Define this macro if loading short immediate values into registers 35222 sign extends. 35223 35224 -- Macro: FIXUNS_TRUNC_LIKE_FIX_TRUNC 35225 Define this macro if the same instructions that convert a floating 35226 point number to a signed fixed point number also convert validly 35227 to an unsigned one. 35228 35229 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL (enum 35230 machine_mode MODE) 35231 When `-ffast-math' is in effect, GCC tries to optimize divisions 35232 by the same divisor, by turning them into multiplications by the 35233 reciprocal. This target hook specifies the minimum number of 35234 divisions that should be there for GCC to perform the optimization 35235 for a variable of mode MODE. The default implementation returns 3 35236 if the machine has an instruction for the division, and 2 if it 35237 does not. 35238 35239 -- Macro: MOVE_MAX 35240 The maximum number of bytes that a single instruction can move 35241 quickly between memory and registers or between two memory 35242 locations. 35243 35244 -- Macro: MAX_MOVE_MAX 35245 The maximum number of bytes that a single instruction can move 35246 quickly between memory and registers or between two memory 35247 locations. If this is undefined, the default is `MOVE_MAX'. 35248 Otherwise, it is the constant value that is the largest value that 35249 `MOVE_MAX' can have at run-time. 35250 35251 -- Macro: SHIFT_COUNT_TRUNCATED 35252 A C expression that is nonzero if on this machine the number of 35253 bits actually used for the count of a shift operation is equal to 35254 the number of bits needed to represent the size of the object 35255 being shifted. When this macro is nonzero, the compiler will 35256 assume that it is safe to omit a sign-extend, zero-extend, and 35257 certain bitwise `and' instructions that truncates the count of a 35258 shift operation. On machines that have instructions that act on 35259 bit-fields at variable positions, which may include `bit test' 35260 instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables 35261 deletion of truncations of the values that serve as arguments to 35262 bit-field instructions. 35263 35264 If both types of instructions truncate the count (for shifts) and 35265 position (for bit-field operations), or if no variable-position 35266 bit-field instructions exist, you should define this macro. 35267 35268 However, on some machines, such as the 80386 and the 680x0, 35269 truncation only applies to shift operations and not the (real or 35270 pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED' 35271 to be zero on such machines. Instead, add patterns to the `md' 35272 file that include the implied truncation of the shift instructions. 35273 35274 You need not define this macro if it would always have the value 35275 of zero. 35276 35277 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 35278 (enum machine_mode MODE) 35279 This function describes how the standard shift patterns for MODE 35280 deal with shifts by negative amounts or by more than the width of 35281 the mode. *Note shift patterns::. 35282 35283 On many machines, the shift patterns will apply a mask M to the 35284 shift count, meaning that a fixed-width shift of X by Y is 35285 equivalent to an arbitrary-width shift of X by Y & M. If this is 35286 true for mode MODE, the function should return M, otherwise it 35287 should return 0. A return value of 0 indicates that no particular 35288 behavior is guaranteed. 35289 35290 Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does 35291 _not_ apply to general shift rtxes; it applies only to instructions 35292 that are generated by the named shift patterns. 35293 35294 The default implementation of this function returns 35295 `GET_MODE_BITSIZE (MODE) - 1' if `SHIFT_COUNT_TRUNCATED' and 0 35296 otherwise. This definition is always safe, but if 35297 `SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 35298 nevertheless truncate the shift count, you may get better code by 35299 overriding it. 35300 35301 -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC) 35302 A C expression which is nonzero if on this machine it is safe to 35303 "convert" an integer of INPREC bits to one of OUTPREC bits (where 35304 OUTPREC is smaller than INPREC) by merely operating on it as if it 35305 had only OUTPREC bits. 35306 35307 On many machines, this expression can be 1. 35308 35309 When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for 35310 modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result. 35311 If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in 35312 such cases may improve things. 35313 35314 -- Target Hook: int TARGET_MODE_REP_EXTENDED (enum machine_mode MODE, 35315 enum machine_mode REP_MODE) 35316 The representation of an integral mode can be such that the values 35317 are always extended to a wider integral mode. Return 35318 `SIGN_EXTEND' if values of MODE are represented in sign-extended 35319 form to REP_MODE. Return `UNKNOWN' otherwise. (Currently, none 35320 of the targets use zero-extended representation this way so unlike 35321 `LOAD_EXTEND_OP', `TARGET_MODE_REP_EXTENDED' is expected to return 35322 either `SIGN_EXTEND' or `UNKNOWN'. Also no target extends MODE to 35323 REP_MODE so that REP_MODE is not the next widest integral mode and 35324 currently we take advantage of this fact.) 35325 35326 Similarly to `LOAD_EXTEND_OP' you may return a non-`UNKNOWN' value 35327 even if the extension is not performed on certain hard registers 35328 as long as for the `REGNO_REG_CLASS' of these hard registers 35329 `CANNOT_CHANGE_MODE_CLASS' returns nonzero. 35330 35331 Note that `TARGET_MODE_REP_EXTENDED' and `LOAD_EXTEND_OP' describe 35332 two related properties. If you define `TARGET_MODE_REP_EXTENDED 35333 (mode, word_mode)' you probably also want to define 35334 `LOAD_EXTEND_OP (mode)' to return the same type of extension. 35335 35336 In order to enforce the representation of `mode', 35337 `TRULY_NOOP_TRUNCATION' should return false when truncating to 35338 `mode'. 35339 35340 -- Macro: STORE_FLAG_VALUE 35341 A C expression describing the value returned by a comparison 35342 operator with an integral mode and stored by a store-flag 35343 instruction (`cstoreMODE4') when the condition is true. This 35344 description must apply to _all_ the `cstoreMODE4' patterns and all 35345 the comparison operators whose results have a `MODE_INT' mode. 35346 35347 A value of 1 or -1 means that the instruction implementing the 35348 comparison operator returns exactly 1 or -1 when the comparison is 35349 true and 0 when the comparison is false. Otherwise, the value 35350 indicates which bits of the result are guaranteed to be 1 when the 35351 comparison is true. This value is interpreted in the mode of the 35352 comparison operation, which is given by the mode of the first 35353 operand in the `cstoreMODE4' pattern. Either the low bit or the 35354 sign bit of `STORE_FLAG_VALUE' be on. Presently, only those bits 35355 are used by the compiler. 35356 35357 If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 35358 generate code that depends only on the specified bits. It can also 35359 replace comparison operators with equivalent operations if they 35360 cause the required bits to be set, even if the remaining bits are 35361 undefined. For example, on a machine whose comparison operators 35362 return an `SImode' value and where `STORE_FLAG_VALUE' is defined as 35363 `0x80000000', saying that just the sign bit is relevant, the 35364 expression 35365 35366 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 35367 35368 can be converted to 35369 35370 (ashift:SI X (const_int N)) 35371 35372 where N is the appropriate shift count to move the bit being 35373 tested into the sign bit. 35374 35375 There is no way to describe a machine that always sets the 35376 low-order bit for a true value, but does not guarantee the value 35377 of any other bits, but we do not know of any machine that has such 35378 an instruction. If you are trying to port GCC to such a machine, 35379 include an instruction to perform a logical-and of the result with 35380 1 in the pattern for the comparison operators and let us know at 35381 <gcc (a] gcc.gnu.org>. 35382 35383 Often, a machine will have multiple instructions that obtain a 35384 value from a comparison (or the condition codes). Here are rules 35385 to guide the choice of value for `STORE_FLAG_VALUE', and hence the 35386 instructions to be used: 35387 35388 * Use the shortest sequence that yields a valid definition for 35389 `STORE_FLAG_VALUE'. It is more efficient for the compiler to 35390 "normalize" the value (convert it to, e.g., 1 or 0) than for 35391 the comparison operators to do so because there may be 35392 opportunities to combine the normalization with other 35393 operations. 35394 35395 * For equal-length sequences, use a value of 1 or -1, with -1 35396 being slightly preferred on machines with expensive jumps and 35397 1 preferred on other machines. 35398 35399 * As a second choice, choose a value of `0x80000001' if 35400 instructions exist that set both the sign and low-order bits 35401 but do not define the others. 35402 35403 * Otherwise, use a value of `0x80000000'. 35404 35405 Many machines can produce both the value chosen for 35406 `STORE_FLAG_VALUE' and its negation in the same number of 35407 instructions. On those machines, you should also define a pattern 35408 for those cases, e.g., one matching 35409 35410 (set A (neg:M (ne:M B C))) 35411 35412 Some machines can also perform `and' or `plus' operations on 35413 condition code values with less instructions than the corresponding 35414 `cstoreMODE4' insn followed by `and' or `plus'. On those 35415 machines, define the appropriate patterns. Use the names `incscc' 35416 and `decscc', respectively, for the patterns which perform `plus' 35417 or `minus' operations on condition code values. See `rs6000.md' 35418 for some examples. The GNU Superoptimizer can be used to find 35419 such instruction sequences on other machines. 35420 35421 If this macro is not defined, the default value, 1, is used. You 35422 need not define `STORE_FLAG_VALUE' if the machine has no store-flag 35423 instructions, or if the value generated by these instructions is 1. 35424 35425 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 35426 A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is 35427 returned when comparison operators with floating-point results are 35428 true. Define this macro on machines that have comparison 35429 operations that return floating-point values. If there are no 35430 such operations, do not define this macro. 35431 35432 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 35433 A C expression that gives a rtx representing the nonzero true 35434 element for vector comparisons. The returned rtx should be valid 35435 for the inner mode of MODE which is guaranteed to be a vector 35436 mode. Define this macro on machines that have vector comparison 35437 operations that return a vector result. If there are no such 35438 operations, do not define this macro. Typically, this macro is 35439 defined as `const1_rtx' or `constm1_rtx'. This macro may return 35440 `NULL_RTX' to prevent the compiler optimizing such vector 35441 comparison operations for the given mode. 35442 35443 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 35444 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 35445 A C expression that indicates whether the architecture defines a 35446 value for `clz' or `ctz' with a zero operand. A result of `0' 35447 indicates the value is undefined. If the value is defined for 35448 only the RTL expression, the macro should evaluate to `1'; if the 35449 value applies also to the corresponding optab entry (which is 35450 normally the case if it expands directly into the corresponding 35451 RTL), then the macro should evaluate to `2'. In the cases where 35452 the value is defined, VALUE should be set to this value. 35453 35454 If this macro is not defined, the value of `clz' or `ctz' at zero 35455 is assumed to be undefined. 35456 35457 This macro must be defined if the target's expansion for `ffs' 35458 relies on a particular value to get correct results. Otherwise it 35459 is not necessary, though it may be used to optimize some corner 35460 cases, and to provide a default expansion for the `ffs' optab. 35461 35462 Note that regardless of this macro the "definedness" of `clz' and 35463 `ctz' at zero do _not_ extend to the builtin functions visible to 35464 the user. Thus one may be free to adjust the value at will to 35465 match the target expansion of these operations without fear of 35466 breaking the API. 35467 35468 -- Macro: Pmode 35469 An alias for the machine mode for pointers. On most machines, 35470 define this to be the integer mode corresponding to the width of a 35471 hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit 35472 machines. On some machines you must define this to be one of the 35473 partial integer modes, such as `PSImode'. 35474 35475 The width of `Pmode' must be at least as large as the value of 35476 `POINTER_SIZE'. If it is not equal, you must define the macro 35477 `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 35478 `Pmode'. 35479 35480 -- Macro: FUNCTION_MODE 35481 An alias for the machine mode used for memory references to 35482 functions being called, in `call' RTL expressions. On most CISC 35483 machines, where an instruction can begin at any byte address, this 35484 should be `QImode'. On most RISC machines, where all instructions 35485 have fixed size and alignment, this should be a mode with the same 35486 size and alignment as the machine instruction words - typically 35487 `SImode' or `HImode'. 35488 35489 -- Macro: STDC_0_IN_SYSTEM_HEADERS 35490 In normal operation, the preprocessor expands `__STDC__' to the 35491 constant 1, to signify that GCC conforms to ISO Standard C. On 35492 some hosts, like Solaris, the system compiler uses a different 35493 convention, where `__STDC__' is normally 0, but is 1 if the user 35494 specifies strict conformance to the C Standard. 35495 35496 Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 35497 convention when processing system header files, but when 35498 processing user files `__STDC__' will always expand to 1. 35499 35500 -- Macro: NO_IMPLICIT_EXTERN_C 35501 Define this macro if the system header files support C++ as well 35502 as C. This macro inhibits the usual method of using system header 35503 files in C++, which is to pretend that the file's contents are 35504 enclosed in `extern "C" {...}'. 35505 35506 -- Macro: REGISTER_TARGET_PRAGMAS () 35507 Define this macro if you want to implement any target-specific 35508 pragmas. If defined, it is a C expression which makes a series of 35509 calls to `c_register_pragma' or `c_register_pragma_with_expansion' 35510 for each pragma. The macro may also do any setup required for the 35511 pragmas. 35512 35513 The primary reason to define this macro is to provide 35514 compatibility with other compilers for the same target. In 35515 general, we discourage definition of target-specific pragmas for 35516 GCC. 35517 35518 If the pragma can be implemented by attributes then you should 35519 consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as 35520 well. 35521 35522 Preprocessor macros that appear on pragma lines are not expanded. 35523 All `#pragma' directives that do not match any registered pragma 35524 are silently ignored, unless the user specifies 35525 `-Wunknown-pragmas'. 35526 35527 -- Function: void c_register_pragma (const char *SPACE, const char 35528 *NAME, void (*CALLBACK) (struct cpp_reader *)) 35529 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 35530 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 35531 Each call to `c_register_pragma' or 35532 `c_register_pragma_with_expansion' establishes one pragma. The 35533 CALLBACK routine will be called when the preprocessor encounters a 35534 pragma of the form 35535 35536 #pragma [SPACE] NAME ... 35537 35538 SPACE is the case-sensitive namespace of the pragma, or `NULL' to 35539 put the pragma in the global namespace. The callback routine 35540 receives PFILE as its first argument, which can be passed on to 35541 cpplib's functions if necessary. You can lex tokens after the 35542 NAME by calling `pragma_lex'. Tokens that are not read by the 35543 callback will be silently ignored. The end of the line is 35544 indicated by a token of type `CPP_EOF'. Macro expansion occurs on 35545 the arguments of pragmas registered with 35546 `c_register_pragma_with_expansion' but not on the arguments of 35547 pragmas registered with `c_register_pragma'. 35548 35549 Note that the use of `pragma_lex' is specific to the C and C++ 35550 compilers. It will not work in the Java or Fortran compilers, or 35551 any other language compilers for that matter. Thus if 35552 `pragma_lex' is going to be called from target-specific code, it 35553 must only be done so when building the C and C++ compilers. This 35554 can be done by defining the variables `c_target_objs' and 35555 `cxx_target_objs' in the target entry in the `config.gcc' file. 35556 These variables should name the target-specific, language-specific 35557 object file which contains the code that uses `pragma_lex'. Note 35558 it will also be necessary to add a rule to the makefile fragment 35559 pointed to by `tmake_file' that shows how to build this object 35560 file. 35561 35562 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 35563 Define this macro if macros should be expanded in the arguments of 35564 `#pragma pack'. 35565 35566 -- Target Hook: bool TARGET_HANDLE_PRAGMA_EXTERN_PREFIX 35567 True if `#pragma extern_prefix' is to be supported. 35568 35569 -- Macro: TARGET_DEFAULT_PACK_STRUCT 35570 If your target requires a structure packing default other than 0 35571 (meaning the machine default), define this macro to the necessary 35572 value (in bytes). This must be a value that would also be valid 35573 to use with `#pragma pack()' (that is, a small power of two). 35574 35575 -- Macro: DOLLARS_IN_IDENTIFIERS 35576 Define this macro to control use of the character `$' in 35577 identifier names for the C family of languages. 0 means `$' is 35578 not allowed by default; 1 means it is allowed. 1 is the default; 35579 there is no need to define this macro in that case. 35580 35581 -- Macro: NO_DOLLAR_IN_LABEL 35582 Define this macro if the assembler does not accept the character 35583 `$' in label names. By default constructors and destructors in 35584 G++ have `$' in the identifiers. If this macro is defined, `.' is 35585 used instead. 35586 35587 -- Macro: NO_DOT_IN_LABEL 35588 Define this macro if the assembler does not accept the character 35589 `.' in label names. By default constructors and destructors in G++ 35590 have names that use `.'. If this macro is defined, these names 35591 are rewritten to avoid `.'. 35592 35593 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 35594 Define this macro as a C expression that is nonzero if it is safe 35595 for the delay slot scheduler to place instructions in the delay 35596 slot of INSN, even if they appear to use a resource set or 35597 clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC 35598 knows that every `call_insn' has this behavior. On machines where 35599 some `insn' or `jump_insn' is really a function call and hence has 35600 this behavior, you should define this macro. 35601 35602 You need not define this macro if it would always return zero. 35603 35604 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 35605 Define this macro as a C expression that is nonzero if it is safe 35606 for the delay slot scheduler to place instructions in the delay 35607 slot of INSN, even if they appear to set or clobber a resource 35608 referenced in INSN. INSN is always a `jump_insn' or an `insn'. 35609 On machines where some `insn' or `jump_insn' is really a function 35610 call and its operands are registers whose use is actually in the 35611 subroutine it calls, you should define this macro. Doing so 35612 allows the delay slot scheduler to move instructions which copy 35613 arguments into the argument registers into the delay slot of INSN. 35614 35615 You need not define this macro if it would always return zero. 35616 35617 -- Macro: MULTIPLE_SYMBOL_SPACES 35618 Define this macro as a C expression that is nonzero if, in some 35619 cases, global symbols from one translation unit may not be bound 35620 to undefined symbols in another translation unit without user 35621 intervention. For instance, under Microsoft Windows symbols must 35622 be explicitly imported from shared libraries (DLLs). 35623 35624 You need not define this macro if it would always evaluate to zero. 35625 35626 -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree 35627 INPUTS, tree CLOBBERS) 35628 This target hook should add to CLOBBERS `STRING_CST' trees for any 35629 hard regs the port wishes to automatically clobber for an asm. It 35630 should return the result of the last `tree_cons' used to add a 35631 clobber. The OUTPUTS, INPUTS and CLOBBER lists are the 35632 corresponding parameters to the asm and may be inspected to avoid 35633 clobbering a register that is an input or output of the asm. You 35634 can use `tree_overlaps_hard_reg_set', declared in `tree.h', to test 35635 for overlap with regards to asm-declared registers. 35636 35637 -- Macro: MATH_LIBRARY 35638 Define this macro as a C string constant for the linker argument 35639 to link in the system math library, minus the initial `"-l"', or 35640 `""' if the target does not have a separate math library. 35641 35642 You need only define this macro if the default of `"m"' is wrong. 35643 35644 -- Macro: LIBRARY_PATH_ENV 35645 Define this macro as a C string constant for the environment 35646 variable that specifies where the linker should look for libraries. 35647 35648 You need only define this macro if the default of `"LIBRARY_PATH"' 35649 is wrong. 35650 35651 -- Macro: TARGET_POSIX_IO 35652 Define this macro if the target supports the following POSIX file 35653 functions, access, mkdir and file locking with fcntl / F_SETLKW. 35654 Defining `TARGET_POSIX_IO' will enable the test coverage code to 35655 use file locking when exiting a program, which avoids race 35656 conditions if the program has forked. It will also create 35657 directories at run-time for cross-profiling. 35658 35659 -- Macro: MAX_CONDITIONAL_EXECUTE 35660 A C expression for the maximum number of instructions to execute 35661 via conditional execution instructions instead of a branch. A 35662 value of `BRANCH_COST'+1 is the default if the machine does not 35663 use cc0, and 1 if it does use cc0. 35664 35665 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 35666 Used if the target needs to perform machine-dependent 35667 modifications on the conditionals used for turning basic blocks 35668 into conditionally executed code. CE_INFO points to a data 35669 structure, `struct ce_if_block', which contains information about 35670 the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the 35671 tests that are used for converting the then-block and the 35672 else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a 35673 null pointer if the tests cannot be converted. 35674 35675 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 35676 FALSE_EXPR) 35677 Like `IFCVT_MODIFY_TESTS', but used when converting more 35678 complicated if-statements into conditions combined by `and' and 35679 `or' operations. BB contains the basic block that contains the 35680 test that is currently being processed and about to be turned into 35681 a condition. 35682 35683 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 35684 A C expression to modify the PATTERN of an INSN that is to be 35685 converted to conditional execution format. CE_INFO points to a 35686 data structure, `struct ce_if_block', which contains information 35687 about the currently processed blocks. 35688 35689 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 35690 A C expression to perform any final machine dependent 35691 modifications in converting code to conditional execution. The 35692 involved basic blocks can be found in the `struct ce_if_block' 35693 structure that is pointed to by CE_INFO. 35694 35695 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 35696 A C expression to cancel any machine dependent modifications in 35697 converting code to conditional execution. The involved basic 35698 blocks can be found in the `struct ce_if_block' structure that is 35699 pointed to by CE_INFO. 35700 35701 -- Macro: IFCVT_INIT_EXTRA_FIELDS (CE_INFO) 35702 A C expression to initialize any extra fields in a `struct 35703 ce_if_block' structure, which are defined by the 35704 `IFCVT_EXTRA_FIELDS' macro. 35705 35706 -- Macro: IFCVT_EXTRA_FIELDS 35707 If defined, it should expand to a set of field declarations that 35708 will be added to the `struct ce_if_block' structure. These should 35709 be initialized by the `IFCVT_INIT_EXTRA_FIELDS' macro. 35710 35711 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 35712 If non-null, this hook performs a target-specific pass over the 35713 instruction stream. The compiler will run it at all optimization 35714 levels, just before the point at which it normally does 35715 delayed-branch scheduling. 35716 35717 The exact purpose of the hook varies from target to target. Some 35718 use it to do transformations that are necessary for correctness, 35719 such as laying out in-function constant pools or avoiding hardware 35720 hazards. Others use it as an opportunity to do some 35721 machine-dependent optimizations. 35722 35723 You need not implement the hook if it has nothing to do. The 35724 default definition is null. 35725 35726 -- Target Hook: void TARGET_INIT_BUILTINS (void) 35727 Define this hook if you have any machine-specific built-in 35728 functions that need to be defined. It should be a function that 35729 performs the necessary setup. 35730 35731 Machine specific built-in functions can be useful to expand 35732 special machine instructions that would otherwise not normally be 35733 generated because they have no equivalent in the source language 35734 (for example, SIMD vector instructions or prefetch instructions). 35735 35736 To create a built-in function, call the function 35737 `lang_hooks.builtin_function' which is defined by the language 35738 front end. You can use any type nodes set up by 35739 `build_common_tree_nodes' and `build_common_tree_nodes_2'; only 35740 language front ends that use those two functions will call 35741 `TARGET_INIT_BUILTINS'. 35742 35743 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 35744 INITIALIZE_P) 35745 Define this hook if you have any machine-specific built-in 35746 functions that need to be defined. It should be a function that 35747 returns the builtin function declaration for the builtin function 35748 code CODE. If there is no such builtin and it cannot be 35749 initialized at this time if INITIALIZE_P is true the function 35750 should return `NULL_TREE'. If CODE is out of range the function 35751 should return `error_mark_node'. 35752 35753 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 35754 SUBTARGET, enum machine_mode MODE, int IGNORE) 35755 Expand a call to a machine specific built-in function that was set 35756 up by `TARGET_INIT_BUILTINS'. EXP is the expression for the 35757 function call; the result should go to TARGET if that is 35758 convenient, and have mode MODE if that is convenient. SUBTARGET 35759 may be used as the target for computing one of EXP's operands. 35760 IGNORE is nonzero if the value is to be ignored. This function 35761 should return the result of the call to the built-in function. 35762 35763 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 35764 LOC, tree FNDECL, void *ARGLIST) 35765 Select a replacement for a machine specific built-in function that 35766 was set up by `TARGET_INIT_BUILTINS'. This is done _before_ 35767 regular type checking, and so allows the target to implement a 35768 crude form of function overloading. FNDECL is the declaration of 35769 the built-in function. ARGLIST is the list of arguments passed to 35770 the built-in function. The result is a complete expression that 35771 implements the operation, usually another `CALL_EXPR'. ARGLIST 35772 really has type `VEC(tree,gc)*' 35773 35774 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, 35775 tree *ARGP, bool IGNORE) 35776 Fold a call to a machine specific built-in function that was set 35777 up by `TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 35778 built-in function. N_ARGS is the number of arguments passed to 35779 the function; the arguments themselves are pointed to by ARGP. 35780 The result is another tree containing a simplified expression for 35781 the call's result. If IGNORE is true the value will be ignored. 35782 35783 -- Target Hook: int TARGET_MVERSION_FUNCTION (tree FNDECL, tree 35784 *OPTIMIZATION_NODE_CHAIN, tree *COND_FUNC_DECL) 35785 Check if a function needs to be multi-versioned to support 35786 variants of this architecture. FNDECL is the declaration of the 35787 function. 35788 35789 -- Target Hook: bool TARGET_SLOW_UNALIGNED_VECTOR_MEMOP (void) 35790 Return true if unaligned vector memory load/store is a slow 35791 operation on this target. 35792 35793 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const_rtx 35794 INSN) 35795 Take an instruction in INSN and return NULL if it is valid within a 35796 low-overhead loop, otherwise return a string explaining why doloop 35797 could not be applied. 35798 35799 Many targets use special registers for low-overhead looping. For 35800 any instruction that clobbers these this function should return a 35801 string indicating the reason why the doloop could not be applied. 35802 By default, the RTL loop optimizer does not use a present doloop 35803 pattern for loops containing function calls or branch on table 35804 instructions. 35805 35806 -- Macro: MD_CAN_REDIRECT_BRANCH (BRANCH1, BRANCH2) 35807 Take a branch insn in BRANCH1 and another in BRANCH2. Return true 35808 if redirecting BRANCH1 to the destination of BRANCH2 is possible. 35809 35810 On some targets, branches may have a limited range. Optimizing the 35811 filling of delay slots can result in branches being redirected, 35812 and this may in turn cause a branch offset to overflow. 35813 35814 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 35815 This target hook returns `true' if X is considered to be 35816 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 35817 PA doesn't consider PLUS to be commutative inside a MEM. 35818 OUTER_CODE is the rtx code of the enclosing rtl, if known, 35819 otherwise it is UNKNOWN. 35820 35821 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 35822 When the initial value of a hard register has been copied in a 35823 pseudo register, it is often not necessary to actually allocate 35824 another register to this pseudo register, because the original 35825 hard register or a stack slot it has been saved into can be used. 35826 `TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 35827 allocation once for each hard register that had its initial value 35828 copied by using `get_func_hard_reg_initial_val' or 35829 `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if 35830 you don't want to do any special allocation, a `REG' rtx--that 35831 would typically be the hard register itself, if it is known not to 35832 be clobbered--or a `MEM'. If you are returning a `MEM', this is 35833 only a hint for the allocator; it might decide to use another 35834 register anyways. You may use `current_function_leaf_function' in 35835 the hook, functions that use `REG_N_SETS', to determine if the hard 35836 register in question will not be clobbered. The default value of 35837 this hook is `NULL', which disables any special allocation. 35838 35839 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 35840 FLAGS) 35841 This target hook returns nonzero if X, an `unspec' or 35842 `unspec_volatile' operation, might cause a trap. Targets can use 35843 this hook to enhance precision of analysis for `unspec' and 35844 `unspec_volatile' operations. You may call `may_trap_p_1' to 35845 analyze inner elements of X in which case FLAGS should be passed 35846 along. 35847 35848 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 35849 The compiler invokes this hook whenever it changes its current 35850 function context (`cfun'). You can define this function if the 35851 back end needs to perform any initialization or reset actions on a 35852 per-function basis. For example, it may be used to implement 35853 function attributes that affect register usage or code generation 35854 patterns. The argument DECL is the declaration for the new 35855 function context, and may be null to indicate that the compiler 35856 has left a function context and is returning to processing at the 35857 top level. The default hook function does nothing. 35858 35859 GCC sets `cfun' to a dummy function context during initialization 35860 of some parts of the back end. The hook function is not invoked 35861 in this situation; you need not worry about the hook being invoked 35862 recursively, or when the back end is in a partially-initialized 35863 state. `cfun' might be `NULL' to indicate processing at top level, 35864 outside of any function scope. 35865 35866 -- Macro: TARGET_OBJECT_SUFFIX 35867 Define this macro to be a C string representing the suffix for 35868 object files on your target machine. If you do not define this 35869 macro, GCC will use `.o' as the suffix for object files. 35870 35871 -- Macro: TARGET_EXECUTABLE_SUFFIX 35872 Define this macro to be a C string representing the suffix to be 35873 automatically added to executable files on your target machine. 35874 If you do not define this macro, GCC will use the null string as 35875 the suffix for executable files. 35876 35877 -- Macro: COLLECT_EXPORT_LIST 35878 If defined, `collect2' will scan the individual object files 35879 specified on its command line and create an export list for the 35880 linker. Define this macro for systems like AIX, where the linker 35881 discards object files that are not referenced from `main' and uses 35882 export lists. 35883 35884 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 35885 Define this macro to a C expression representing a variant of the 35886 method call MDECL, if Java Native Interface (JNI) methods must be 35887 invoked differently from other methods on your target. For 35888 example, on 32-bit Microsoft Windows, JNI methods must be invoked 35889 using the `stdcall' calling convention and this macro is then 35890 defined as this expression: 35891 35892 build_type_attribute_variant (MDECL, 35893 build_tree_list 35894 (get_identifier ("stdcall"), 35895 NULL)) 35896 35897 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 35898 This target hook returns `true' past the point in which new jump 35899 instructions could be created. On machines that require a 35900 register for every jump such as the SHmedia ISA of SH5, this point 35901 would typically be reload, so this target hook should be defined 35902 to a function such as: 35903 35904 static bool 35905 cannot_modify_jumps_past_reload_p () 35906 { 35907 return (reload_completed || reload_in_progress); 35908 } 35909 35910 -- Target Hook: reg_class_t TARGET_BRANCH_TARGET_REGISTER_CLASS (void) 35911 This target hook returns a register class for which branch target 35912 register optimizations should be applied. All registers in this 35913 class should be usable interchangeably. After reload, registers 35914 in this class will be re-allocated and loads will be hoisted out 35915 of loops and be subjected to inter-block scheduling. 35916 35917 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 35918 AFTER_PROLOGUE_EPILOGUE_GEN) 35919 Branch target register optimization will by default exclude 35920 callee-saved registers that are not already live during the 35921 current function; if this target hook returns true, they will be 35922 included. The target code must than make sure that all target 35923 registers in the class returned by 35924 `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are 35925 saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and 35926 epilogues have already been generated. Note, even if you only 35927 return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still 35928 are likely to have to make special provisions in 35929 `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 35930 target registers. 35931 35932 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 35933 This target hook returns true if the target supports conditional 35934 execution. This target hook is required only when the target has 35935 several different modes and they have different conditional 35936 execution capability, such as ARM. 35937 35938 -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL, 35939 struct loop *LOOP) 35940 This target hook returns a new value for the number of times LOOP 35941 should be unrolled. The parameter NUNROLL is the number of times 35942 the loop is to be unrolled. The parameter LOOP is a pointer to the 35943 loop, which is going to be checked for unrolling. This target hook 35944 is required only when the target has special constraints like 35945 maximum number of memory accesses. 35946 35947 -- Macro: POWI_MAX_MULTS 35948 If defined, this macro is interpreted as a signed integer C 35949 expression that specifies the maximum number of floating point 35950 multiplications that should be emitted when expanding 35951 exponentiation by an integer constant inline. When this value is 35952 defined, exponentiation requiring more than this number of 35953 multiplications is implemented by calling the system library's 35954 `pow', `powf' or `powl' routines. The default value places no 35955 upper bound on the multiplication count. 35956 35957 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 35958 *IPREFIX, int STDINC) 35959 This target hook should register any extra include files for the 35960 target. The parameter STDINC indicates if normal include files 35961 are present. The parameter SYSROOT is the system root directory. 35962 The parameter IPREFIX is the prefix for the gcc directory. 35963 35964 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 35965 char *IPREFIX, int STDINC) 35966 This target hook should register any extra include files for the 35967 target before any standard headers. The parameter STDINC 35968 indicates if normal include files are present. The parameter 35969 SYSROOT is the system root directory. The parameter IPREFIX is 35970 the prefix for the gcc directory. 35971 35972 -- Macro: void TARGET_OPTF (char *PATH) 35973 This target hook should register special include paths for the 35974 target. The parameter PATH is the include to register. On Darwin 35975 systems, this is used for Framework includes, which have semantics 35976 that are different from `-I'. 35977 35978 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 35979 This target macro returns `true' if it is safe to use a local alias 35980 for a virtual function FNDECL when constructing thunks, `false' 35981 otherwise. By default, the macro returns `true' for all 35982 functions, if a target supports aliases (i.e. defines 35983 `ASM_OUTPUT_DEF'), `false' otherwise, 35984 35985 -- Macro: TARGET_FORMAT_TYPES 35986 If defined, this macro is the name of a global variable containing 35987 target-specific format checking information for the `-Wformat' 35988 option. The default is to have no target-specific format checks. 35989 35990 -- Macro: TARGET_N_FORMAT_TYPES 35991 If defined, this macro is the number of entries in 35992 `TARGET_FORMAT_TYPES'. 35993 35994 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 35995 If defined, this macro is the name of a global variable containing 35996 target-specific format overrides for the `-Wformat' option. The 35997 default is to have no target-specific format overrides. If defined, 35998 `TARGET_FORMAT_TYPES' must be defined, too. 35999 36000 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 36001 If defined, this macro specifies the number of entries in 36002 `TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 36003 36004 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 36005 If defined, this macro specifies the optional initialization 36006 routine for target specific customizations of the system printf 36007 and scanf formatter settings. 36008 36009 -- Target Hook: bool TARGET_RELAXED_ORDERING 36010 If set to `true', means that the target's memory model does not 36011 guarantee that loads which do not depend on one another will access 36012 main memory in the order of the instruction stream; if ordering is 36013 important, an explicit memory barrier must be used. This is true 36014 of many recent processors which implement a policy of "relaxed," 36015 "weak," or "release" memory consistency, such as Alpha, PowerPC, 36016 and ia64. The default is `false'. 36017 36018 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 36019 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 36020 If defined, this macro returns the diagnostic message when it is 36021 illegal to pass argument VAL to function FUNCDECL with prototype 36022 TYPELIST. 36023 36024 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 36025 FROMTYPE, const_tree TOTYPE) 36026 If defined, this macro returns the diagnostic message when it is 36027 invalid to convert from FROMTYPE to TOTYPE, or `NULL' if validity 36028 should be determined by the front end. 36029 36030 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 36031 const_tree TYPE) 36032 If defined, this macro returns the diagnostic message when it is 36033 invalid to apply operation OP (where unary plus is denoted by 36034 `CONVERT_EXPR') to an operand of type TYPE, or `NULL' if validity 36035 should be determined by the front end. 36036 36037 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 36038 const_tree TYPE1, const_tree TYPE2) 36039 If defined, this macro returns the diagnostic message when it is 36040 invalid to apply operation OP to operands of types TYPE1 and 36041 TYPE2, or `NULL' if validity should be determined by the front end. 36042 36043 -- Target Hook: const char * TARGET_INVALID_PARAMETER_TYPE (const_tree 36044 TYPE) 36045 If defined, this macro returns the diagnostic message when it is 36046 invalid for functions to include parameters of type TYPE, or 36047 `NULL' if validity should be determined by the front end. This is 36048 currently used only by the C and C++ front ends. 36049 36050 -- Target Hook: const char * TARGET_INVALID_RETURN_TYPE (const_tree 36051 TYPE) 36052 If defined, this macro returns the diagnostic message when it is 36053 invalid for functions to have return type TYPE, or `NULL' if 36054 validity should be determined by the front end. This is currently 36055 used only by the C and C++ front ends. 36056 36057 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 36058 If defined, this target hook returns the type to which values of 36059 TYPE should be promoted when they appear in expressions, analogous 36060 to the integer promotions, or `NULL_TREE' to use the front end's 36061 normal promotion rules. This hook is useful when there are 36062 target-specific types with special promotion rules. This is 36063 currently used only by the C and C++ front ends. 36064 36065 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 36066 If defined, this hook returns the result of converting EXPR to 36067 TYPE. It should return the converted expression, or `NULL_TREE' 36068 to apply the front end's normal conversion rules. This hook is 36069 useful when there are target-specific types with special 36070 conversion rules. This is currently used only by the C and C++ 36071 front ends. 36072 36073 -- Macro: TARGET_USE_JCR_SECTION 36074 This macro determines whether to use the JCR section to register 36075 Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1 36076 if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true, 36077 else 0. 36078 36079 -- Macro: OBJC_JBLEN 36080 This macro determines the size of the objective C jump buffer for 36081 the NeXT runtime. By default, OBJC_JBLEN is defined to an 36082 innocuous value. 36083 36084 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 36085 Define this macro if any target-specific attributes need to be 36086 attached to the functions in `libgcc' that provide low-level 36087 support for call stack unwinding. It is used in declarations in 36088 `unwind-generic.h' and the associated definitions of those 36089 functions. 36090 36091 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 36092 Define this macro to update the current function stack boundary if 36093 necessary. 36094 36095 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 36096 This hook should return an rtx for Dynamic Realign Argument 36097 Pointer (DRAP) if a different argument pointer register is needed 36098 to access the function's argument list due to stack realignment. 36099 Return `NULL' if no DRAP is needed. 36100 36101 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 36102 When optimization is disabled, this hook indicates whether or not 36103 arguments should be allocated to stack slots. Normally, GCC 36104 allocates stacks slots for arguments when not optimizing in order 36105 to make debugging easier. However, when a function is declared 36106 with `__attribute__((naked))', there is no stack frame, and the 36107 compiler cannot safely move arguments from the registers in which 36108 they are passed to the stack. Therefore, this hook should return 36109 true in general, but false for naked functions. The default 36110 implementation always returns true. 36111 36112 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 36113 On some architectures it can take multiple instructions to 36114 synthesize a constant. If there is another constant already in a 36115 register that is close enough in value then it is preferable that 36116 the new constant is computed from this register using immediate 36117 addition or subtraction. We accomplish this through CSE. Besides 36118 the value of the constant we also add a lower and an upper 36119 constant anchor to the available expressions. These are then 36120 queried when encountering new constants. The anchors are computed 36121 by rounding the constant up and down to a multiple of the value of 36122 `TARGET_CONST_ANCHOR'. `TARGET_CONST_ANCHOR' should be the 36123 maximum positive value accepted by immediate-add plus one. We 36124 currently assume that the value of `TARGET_CONST_ANCHOR' is a 36125 power of 2. For example, on MIPS, where add-immediate takes a 36126 16-bit signed value, `TARGET_CONST_ANCHOR' is set to `0x8000'. 36127 The default value is zero, which disables this optimization. 36128 36129 36130 File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 36131 36132 18 Host Configuration 36133 ********************* 36134 36135 Most details about the machine and system on which the compiler is 36136 actually running are detected by the `configure' script. Some things 36137 are impossible for `configure' to detect; these are described in two 36138 ways, either by macros defined in a file named `xm-MACHINE.h' or by 36139 hook functions in the file specified by the OUT_HOST_HOOK_OBJ variable 36140 in `config.gcc'. (The intention is that very few hosts will need a 36141 header file but nearly every fully supported host will need to override 36142 some hooks.) 36143 36144 If you need to define only a few macros, and they have simple 36145 definitions, consider using the `xm_defines' variable in your 36146 `config.gcc' entry instead of creating a host configuration header. 36147 *Note System Config::. 36148 36149 * Menu: 36150 36151 * Host Common:: Things every host probably needs implemented. 36152 * Filesystem:: Your host can't have the letter `a' in filenames? 36153 * Host Misc:: Rare configuration options for hosts. 36154 36155 36156 File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 36157 36158 18.1 Host Common 36159 ================ 36160 36161 Some things are just not portable, even between similar operating 36162 systems, and are too difficult for autoconf to detect. They get 36163 implemented using hook functions in the file specified by the 36164 HOST_HOOK_OBJ variable in `config.gcc'. 36165 36166 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 36167 This host hook is used to set up handling for extra signals. The 36168 most common thing to do in this hook is to detect stack overflow. 36169 36170 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 36171 FD) 36172 This host hook returns the address of some space that is likely to 36173 be free in some subsequent invocation of the compiler. We intend 36174 to load the PCH data at this address such that the data need not 36175 be relocated. The area should be able to hold SIZE bytes. If the 36176 host uses `mmap', FD is an open file descriptor that can be used 36177 for probing. 36178 36179 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, 36180 size_t SIZE, int FD, size_t OFFSET) 36181 This host hook is called when a PCH file is about to be loaded. 36182 We want to load SIZE bytes from FD at OFFSET into memory at 36183 ADDRESS. The given address will be the result of a previous 36184 invocation of `HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we 36185 couldn't allocate SIZE bytes at ADDRESS. Return 0 if the memory 36186 is allocated but the data is not loaded. Return 1 if the hook has 36187 performed everything. 36188 36189 If the implementation uses reserved address space, free any 36190 reserved space beyond SIZE, regardless of the return value. If no 36191 PCH will be loaded, this hook may be called with SIZE zero, in 36192 which case all reserved address space should be freed. 36193 36194 Do not try to handle values of ADDRESS that could not have been 36195 returned by this executable; just return -1. Such values usually 36196 indicate an out-of-date PCH file (built by some other GCC 36197 executable), and such a PCH file won't work. 36198 36199 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 36200 This host hook returns the alignment required for allocating 36201 virtual memory. Usually this is the same as getpagesize, but on 36202 some hosts the alignment for reserving memory differs from the 36203 pagesize for committing memory. 36204 36205 36206 File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 36207 36208 18.2 Host Filesystem 36209 ==================== 36210 36211 GCC needs to know a number of things about the semantics of the host 36212 machine's filesystem. Filesystems with Unix and MS-DOS semantics are 36213 automatically detected. For other systems, you can define the 36214 following macros in `xm-MACHINE.h'. 36215 36216 `HAVE_DOS_BASED_FILE_SYSTEM' 36217 This macro is automatically defined by `system.h' if the host file 36218 system obeys the semantics defined by MS-DOS instead of Unix. DOS 36219 file systems are case insensitive, file specifications may begin 36220 with a drive letter, and both forward slash and backslash (`/' and 36221 `\') are directory separators. 36222 36223 `DIR_SEPARATOR' 36224 `DIR_SEPARATOR_2' 36225 If defined, these macros expand to character constants specifying 36226 separators for directory names within a file specification. 36227 `system.h' will automatically give them appropriate values on Unix 36228 and MS-DOS file systems. If your file system is neither of these, 36229 define one or both appropriately in `xm-MACHINE.h'. 36230 36231 However, operating systems like VMS, where constructing a pathname 36232 is more complicated than just stringing together directory names 36233 separated by a special character, should not define either of these 36234 macros. 36235 36236 `PATH_SEPARATOR' 36237 If defined, this macro should expand to a character constant 36238 specifying the separator for elements of search paths. The default 36239 value is a colon (`:'). DOS-based systems usually, but not 36240 always, use semicolon (`;'). 36241 36242 `VMS' 36243 Define this macro if the host system is VMS. 36244 36245 `HOST_OBJECT_SUFFIX' 36246 Define this macro to be a C string representing the suffix for 36247 object files on your host machine. If you do not define this 36248 macro, GCC will use `.o' as the suffix for object files. 36249 36250 `HOST_EXECUTABLE_SUFFIX' 36251 Define this macro to be a C string representing the suffix for 36252 executable files on your host machine. If you do not define this 36253 macro, GCC will use the null string as the suffix for executable 36254 files. 36255 36256 `HOST_BIT_BUCKET' 36257 A pathname defined by the host operating system, which can be 36258 opened as a file and written to, but all the information written 36259 is discarded. This is commonly known as a "bit bucket" or "null 36260 device". If you do not define this macro, GCC will use 36261 `/dev/null' as the bit bucket. If the host does not support a bit 36262 bucket, define this macro to an invalid filename. 36263 36264 `UPDATE_PATH_HOST_CANONICALIZE (PATH)' 36265 If defined, a C statement (sans semicolon) that performs 36266 host-dependent canonicalization when a path used in a compilation 36267 driver or preprocessor is canonicalized. PATH is a malloc-ed path 36268 to be canonicalized. If the C statement does canonicalize PATH 36269 into a different buffer, the old path should be freed and the new 36270 buffer should have been allocated with malloc. 36271 36272 `DUMPFILE_FORMAT' 36273 Define this macro to be a C string representing the format to use 36274 for constructing the index part of debugging dump file names. The 36275 resultant string must fit in fifteen bytes. The full filename 36276 will be the concatenation of: the prefix of the assembler file 36277 name, the string resulting from applying this format to an index 36278 number, and a string unique to each dump file kind, e.g. `rtl'. 36279 36280 If you do not define this macro, GCC will use `.%02d.'. You should 36281 define this macro if using the default will create an invalid file 36282 name. 36283 36284 `DELETE_IF_ORDINARY' 36285 Define this macro to be a C statement (sans semicolon) that 36286 performs host-dependent removal of ordinary temp files in the 36287 compilation driver. 36288 36289 If you do not define this macro, GCC will use the default version. 36290 You should define this macro if the default version does not 36291 reliably remove the temp file as, for example, on VMS which allows 36292 multiple versions of a file. 36293 36294 `HOST_LACKS_INODE_NUMBERS' 36295 Define this macro if the host filesystem does not report 36296 meaningful inode numbers in struct stat. 36297 36298 36299 File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 36300 36301 18.3 Host Misc 36302 ============== 36303 36304 `FATAL_EXIT_CODE' 36305 A C expression for the status code to be returned when the compiler 36306 exits after serious errors. The default is the system-provided 36307 macro `EXIT_FAILURE', or `1' if the system doesn't define that 36308 macro. Define this macro only if these defaults are incorrect. 36309 36310 `SUCCESS_EXIT_CODE' 36311 A C expression for the status code to be returned when the compiler 36312 exits without serious errors. (Warnings are not serious errors.) 36313 The default is the system-provided macro `EXIT_SUCCESS', or `0' if 36314 the system doesn't define that macro. Define this macro only if 36315 these defaults are incorrect. 36316 36317 `USE_C_ALLOCA' 36318 Define this macro if GCC should use the C implementation of 36319 `alloca' provided by `libiberty.a'. This only affects how some 36320 parts of the compiler itself allocate memory. It does not change 36321 code generation. 36322 36323 When GCC is built with a compiler other than itself, the C `alloca' 36324 is always used. This is because most other implementations have 36325 serious bugs. You should define this macro only on a system where 36326 no stack-based `alloca' can possibly work. For instance, if a 36327 system has a small limit on the size of the stack, GCC's builtin 36328 `alloca' will not work reliably. 36329 36330 `COLLECT2_HOST_INITIALIZATION' 36331 If defined, a C statement (sans semicolon) that performs 36332 host-dependent initialization when `collect2' is being initialized. 36333 36334 `GCC_DRIVER_HOST_INITIALIZATION' 36335 If defined, a C statement (sans semicolon) that performs 36336 host-dependent initialization when a compilation driver is being 36337 initialized. 36338 36339 `HOST_LONG_LONG_FORMAT' 36340 If defined, the string used to indicate an argument of type `long 36341 long' to functions like `printf'. The default value is `"ll"'. 36342 36343 `HOST_LONG_FORMAT' 36344 If defined, the string used to indicate an argument of type `long' 36345 to functions like `printf'. The default value is `"l"'. 36346 36347 `HOST_PTR_PRINTF' 36348 If defined, the string used to indicate an argument of type `void 36349 *' to functions like `printf'. The default value is `"%p"'. 36350 36351 In addition, if `configure' generates an incorrect definition of any 36352 of the macros in `auto-host.h', you can override that definition in a 36353 host configuration header. If you need to do this, first see if it is 36354 possible to fix `configure'. 36355 36356 36357 File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 36358 36359 19 Makefile Fragments 36360 ********************* 36361 36362 When you configure GCC using the `configure' script, it will construct 36363 the file `Makefile' from the template file `Makefile.in'. When it does 36364 this, it can incorporate makefile fragments from the `config' 36365 directory. These are used to set Makefile parameters that are not 36366 amenable to being calculated by autoconf. The list of fragments to 36367 incorporate is set by `config.gcc' (and occasionally `config.build' and 36368 `config.host'); *Note System Config::. 36369 36370 Fragments are named either `t-TARGET' or `x-HOST', depending on 36371 whether they are relevant to configuring GCC to produce code for a 36372 particular target, or to configuring GCC to run on a particular host. 36373 Here TARGET and HOST are mnemonics which usually have some relationship 36374 to the canonical system name, but no formal connection. 36375 36376 If these files do not exist, it means nothing needs to be added for a 36377 given target or host. Most targets need a few `t-TARGET' fragments, 36378 but needing `x-HOST' fragments is rare. 36379 36380 * Menu: 36381 36382 * Target Fragment:: Writing `t-TARGET' files. 36383 * Host Fragment:: Writing `x-HOST' files. 36384 36385 36386 File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 36387 36388 19.1 Target Makefile Fragments 36389 ============================== 36390 36391 Target makefile fragments can set these Makefile variables. 36392 36393 `LIBGCC2_CFLAGS' 36394 Compiler flags to use when compiling `libgcc2.c'. 36395 36396 `LIB2FUNCS_EXTRA' 36397 A list of source file names to be compiled or assembled and 36398 inserted into `libgcc.a'. 36399 36400 `Floating Point Emulation' 36401 To have GCC include software floating point libraries in `libgcc.a' 36402 define `FPBIT' and `DPBIT' along with a few rules as follows: 36403 # We want fine grained libraries, so use the new code 36404 # to build the floating point emulation libraries. 36405 FPBIT = fp-bit.c 36406 DPBIT = dp-bit.c 36407 36408 36409 fp-bit.c: $(srcdir)/config/fp-bit.c 36410 echo '#define FLOAT' > fp-bit.c 36411 cat $(srcdir)/config/fp-bit.c >> fp-bit.c 36412 36413 dp-bit.c: $(srcdir)/config/fp-bit.c 36414 cat $(srcdir)/config/fp-bit.c > dp-bit.c 36415 36416 You may need to provide additional #defines at the beginning of 36417 `fp-bit.c' and `dp-bit.c' to control target endianness and other 36418 options. 36419 36420 `CRTSTUFF_T_CFLAGS' 36421 Special flags used when compiling `crtstuff.c'. *Note 36422 Initialization::. 36423 36424 `CRTSTUFF_T_CFLAGS_S' 36425 Special flags used when compiling `crtstuff.c' for shared linking. 36426 Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'. 36427 *Note Initialization::. 36428 36429 `MULTILIB_OPTIONS' 36430 For some targets, invoking GCC in different ways produces objects 36431 that can not be linked together. For example, for some targets GCC 36432 produces both big and little endian code. For these targets, you 36433 must arrange for multiple versions of `libgcc.a' to be compiled, 36434 one for each set of incompatible options. When GCC invokes the 36435 linker, it arranges to link in the right version of `libgcc.a', 36436 based on the command line options used. 36437 36438 The `MULTILIB_OPTIONS' macro lists the set of options for which 36439 special versions of `libgcc.a' must be built. Write options that 36440 are mutually incompatible side by side, separated by a slash. 36441 Write options that may be used together separated by a space. The 36442 build procedure will build all combinations of compatible options. 36443 36444 For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020 36445 msoft-float', `Makefile' will build special versions of `libgcc.a' 36446 using the following sets of options: `-m68000', `-m68020', 36447 `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'. 36448 36449 `MULTILIB_DIRNAMES' 36450 If `MULTILIB_OPTIONS' is used, this variable specifies the 36451 directory names that should be used to hold the various libraries. 36452 Write one element in `MULTILIB_DIRNAMES' for each element in 36453 `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the 36454 default value will be `MULTILIB_OPTIONS', with all slashes treated 36455 as spaces. 36456 36457 For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020 36458 msoft-float', then the default value of `MULTILIB_DIRNAMES' is 36459 `m68000 m68020 msoft-float'. You may specify a different value if 36460 you desire a different set of directory names. 36461 36462 `MULTILIB_MATCHES' 36463 Sometimes the same option may be written in two different ways. 36464 If an option is listed in `MULTILIB_OPTIONS', GCC needs to know 36465 about any synonyms. In that case, set `MULTILIB_MATCHES' to a 36466 list of items of the form `option=option' to describe all relevant 36467 synonyms. For example, `m68000=mc68000 m68020=mc68020'. 36468 36469 `MULTILIB_EXCEPTIONS' 36470 Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being 36471 specified, there are combinations that should not be built. In 36472 that case, set `MULTILIB_EXCEPTIONS' to be all of the switch 36473 exceptions in shell case syntax that should not be built. 36474 36475 For example the ARM processor cannot execute both hardware floating 36476 point instructions and the reduced size THUMB instructions at the 36477 same time, so there is no need to build libraries with both of 36478 these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to: 36479 *mthumb/*mhard-float* 36480 36481 `MULTILIB_EXTRA_OPTS' 36482 Sometimes it is desirable that when building multiple versions of 36483 `libgcc.a' certain options should always be passed on to the 36484 compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list 36485 of options to be used for all builds. If you set this, you should 36486 probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it. 36487 36488 `NATIVE_SYSTEM_HEADER_DIR' 36489 If the default location for system headers is not `/usr/include', 36490 you must set this to the directory containing the headers. This 36491 value should match the value of the `SYSTEM_INCLUDE_DIR' macro. 36492 36493 `SPECS' 36494 Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since 36495 it does not affect the build of target libraries, at least not the 36496 build of the default multilib. One possible work-around is to use 36497 `DRIVER_SELF_SPECS' to bring options from the `specs' file as if 36498 they had been passed in the compiler driver command line. 36499 However, you don't want to be adding these options after the 36500 toolchain is installed, so you can instead tweak the `specs' file 36501 that will be used during the toolchain build, while you still 36502 install the original, built-in `specs'. The trick is to set 36503 `SPECS' to some other filename (say `specs.install'), that will 36504 then be created out of the built-in specs, and introduce a 36505 `Makefile' rule to generate the `specs' file that's going to be 36506 used at build time out of your `specs.install'. 36507 36508 `T_CFLAGS' 36509 These are extra flags to pass to the C compiler. They are used 36510 both when building GCC, and when compiling things with the 36511 just-built GCC. This variable is deprecated and should not be 36512 used. 36513 36514 36515 File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 36516 36517 19.2 Host Makefile Fragments 36518 ============================ 36519 36520 The use of `x-HOST' fragments is discouraged. You should only use it 36521 for makefile dependencies. 36522 36523 36524 File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 36525 36526 20 `collect2' 36527 ************* 36528 36529 GCC uses a utility called `collect2' on nearly all systems to arrange 36530 to call various initialization functions at start time. 36531 36532 The program `collect2' works by linking the program once and looking 36533 through the linker output file for symbols with particular names 36534 indicating they are constructor functions. If it finds any, it creates 36535 a new temporary `.c' file containing a table of them, compiles it, and 36536 links the program a second time including that file. 36537 36538 The actual calls to the constructors are carried out by a subroutine 36539 called `__main', which is called (automatically) at the beginning of 36540 the body of `main' (provided `main' was compiled with GNU CC). Calling 36541 `__main' is necessary, even when compiling C code, to allow linking C 36542 and C++ object code together. (If you use `-nostdlib', you get an 36543 unresolved reference to `__main', since it's defined in the standard 36544 GCC library. Include `-lgcc' at the end of your compiler command line 36545 to resolve this reference.) 36546 36547 The program `collect2' is installed as `ld' in the directory where the 36548 passes of the compiler are installed. When `collect2' needs to find 36549 the _real_ `ld', it tries the following file names: 36550 36551 * a hard coded linker file name, if GCC was configured with the 36552 `--with-ld' option. 36553 36554 * `real-ld' in the directories listed in the compiler's search 36555 directories. 36556 36557 * `real-ld' in the directories listed in the environment variable 36558 `PATH'. 36559 36560 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 36561 if specified. 36562 36563 * `ld' in the compiler's search directories, except that `collect2' 36564 will not execute itself recursively. 36565 36566 * `ld' in `PATH'. 36567 36568 "The compiler's search directories" means all the directories where 36569 `gcc' searches for passes of the compiler. This includes directories 36570 that you specify with `-B'. 36571 36572 Cross-compilers search a little differently: 36573 36574 * `real-ld' in the compiler's search directories. 36575 36576 * `TARGET-real-ld' in `PATH'. 36577 36578 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 36579 if specified. 36580 36581 * `ld' in the compiler's search directories. 36582 36583 * `TARGET-ld' in `PATH'. 36584 36585 `collect2' explicitly avoids running `ld' using the file name under 36586 which `collect2' itself was invoked. In fact, it remembers up a list 36587 of such names--in case one copy of `collect2' finds another copy (or 36588 version) of `collect2' installed as `ld' in a second place in the 36589 search path. 36590 36591 `collect2' searches for the utilities `nm' and `strip' using the same 36592 algorithm as above for `ld'. 36593 36594 36595 File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 36596 36597 21 Standard Header File Directories 36598 *********************************** 36599 36600 `GCC_INCLUDE_DIR' means the same thing for native and cross. It is 36601 where GCC stores its private include files, and also where GCC stores 36602 the fixed include files. A cross compiled GCC runs `fixincludes' on 36603 the header files in `$(tooldir)/include'. (If the cross compilation 36604 header files need to be fixed, they must be installed before GCC is 36605 built. If the cross compilation header files are already suitable for 36606 GCC, nothing special need be done). 36607 36608 `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 36609 is where `g++' looks first for header files. The C++ library installs 36610 only target independent header files in that directory. 36611 36612 `LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 36613 install anything there. It is normally `/usr/local/include'. This is 36614 where local additions to a packaged system should place header files. 36615 36616 `CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 36617 install anything there. 36618 36619 `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 36620 the place for other packages to install header files that GCC will use. 36621 For a cross-compiler, this is the equivalent of `/usr/include'. When 36622 you build a cross-compiler, `fixincludes' processes any header files in 36623 this directory. 36624 36625 36626 File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 36627 36628 22 Memory Management and Type Information 36629 ***************************************** 36630 36631 GCC uses some fairly sophisticated memory management techniques, which 36632 involve determining information about GCC's data structures from GCC's 36633 source code and using this information to perform garbage collection and 36634 implement precompiled headers. 36635 36636 A full C parser would be too complicated for this task, so a limited 36637 subset of C is interpreted and special markers are used to determine 36638 what parts of the source to look at. All `struct' and `union' 36639 declarations that define data structures that are allocated under 36640 control of the garbage collector must be marked. All global variables 36641 that hold pointers to garbage-collected memory must also be marked. 36642 Finally, all global variables that need to be saved and restored by a 36643 precompiled header must be marked. (The precompiled header mechanism 36644 can only save static variables if they're scalar. Complex data 36645 structures must be allocated in garbage-collected memory to be saved in 36646 a precompiled header.) 36647 36648 The full format of a marker is 36649 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 36650 but in most cases no options are needed. The outer double parentheses 36651 are still necessary, though: `GTY(())'. Markers can appear: 36652 36653 * In a structure definition, before the open brace; 36654 36655 * In a global variable declaration, after the keyword `static' or 36656 `extern'; and 36657 36658 * In a structure field definition, before the name of the field. 36659 36660 Here are some examples of marking simple data structures and globals. 36661 36662 struct GTY(()) TAG 36663 { 36664 FIELDS... 36665 }; 36666 36667 typedef struct GTY(()) TAG 36668 { 36669 FIELDS... 36670 } *TYPENAME; 36671 36672 static GTY(()) struct TAG *LIST; /* points to GC memory */ 36673 static GTY(()) int COUNTER; /* save counter in a PCH */ 36674 36675 The parser understands simple typedefs such as `typedef struct TAG 36676 *NAME;' and `typedef int NAME;'. These don't need to be marked. 36677 36678 * Menu: 36679 36680 * GTY Options:: What goes inside a `GTY(())'. 36681 * GGC Roots:: Making global variables GGC roots. 36682 * Files:: How the generated files work. 36683 * Invoking the garbage collector:: How to invoke the garbage collector. 36684 * Troubleshooting:: When something does not work as expected. 36685 36686 36687 File: gccint.info, Node: GTY Options, Next: GGC Roots, Up: Type Information 36688 36689 22.1 The Inside of a `GTY(())' 36690 ============================== 36691 36692 Sometimes the C code is not enough to fully describe the type 36693 structure. Extra information can be provided with `GTY' options and 36694 additional markers. Some options take a parameter, which may be either 36695 a string or a type name, depending on the parameter. If an option 36696 takes no parameter, it is acceptable either to omit the parameter 36697 entirely, or to provide an empty string as a parameter. For example, 36698 `GTY ((skip))' and `GTY ((skip ("")))' are equivalent. 36699 36700 When the parameter is a string, often it is a fragment of C code. Four 36701 special escapes may be used in these strings, to refer to pieces of the 36702 data structure being marked: 36703 36704 `%h' 36705 The current structure. 36706 36707 `%1' 36708 The structure that immediately contains the current structure. 36709 36710 `%0' 36711 The outermost structure that contains the current structure. 36712 36713 `%a' 36714 A partial expression of the form `[i1][i2]...' that indexes the 36715 array item currently being marked. 36716 36717 For instance, suppose that you have a structure of the form 36718 struct A { 36719 ... 36720 }; 36721 struct B { 36722 struct A foo[12]; 36723 }; 36724 and `b' is a variable of type `struct B'. When marking `b.foo[11]', 36725 `%h' would expand to `b.foo[11]', `%0' and `%1' would both expand to 36726 `b', and `%a' would expand to `[11]'. 36727 36728 As in ordinary C, adjacent strings will be concatenated; this is 36729 helpful when you have a complicated expression. 36730 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 36731 " ? TYPE_NEXT_VARIANT (&%h.generic)" 36732 " : TREE_CHAIN (&%h.generic)"))) 36733 36734 The available options are: 36735 36736 `length ("EXPRESSION")' 36737 There are two places the type machinery will need to be explicitly 36738 told the length of an array. The first case is when a structure 36739 ends in a variable-length array, like this: 36740 struct GTY(()) rtvec_def { 36741 int num_elem; /* number of elements */ 36742 rtx GTY ((length ("%h.num_elem"))) elem[1]; 36743 }; 36744 36745 In this case, the `length' option is used to override the specified 36746 array length (which should usually be `1'). The parameter of the 36747 option is a fragment of C code that calculates the length. 36748 36749 The second case is when a structure or a global variable contains a 36750 pointer to an array, like this: 36751 struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter; 36752 In this case, `iter' has been allocated by writing something like 36753 x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse); 36754 and the `collapse' provides the length of the field. 36755 36756 This second use of `length' also works on global variables, like: static GTY((length("reg_known_value_size"))) rtx *reg_known_value; 36757 36758 `skip' 36759 If `skip' is applied to a field, the type machinery will ignore it. 36760 This is somewhat dangerous; the only safe use is in a union when 36761 one field really isn't ever used. 36762 36763 `desc ("EXPRESSION")' 36764 `tag ("CONSTANT")' 36765 `default' 36766 The type machinery needs to be told which field of a `union' is 36767 currently active. This is done by giving each field a constant 36768 `tag' value, and then specifying a discriminator using `desc'. 36769 The value of the expression given by `desc' is compared against 36770 each `tag' value, each of which should be different. If no `tag' 36771 is matched, the field marked with `default' is used if there is 36772 one, otherwise no field in the union will be marked. 36773 36774 In the `desc' option, the "current structure" is the union that it 36775 discriminates. Use `%1' to mean the structure containing it. 36776 There are no escapes available to the `tag' option, since it is a 36777 constant. 36778 36779 For example, 36780 struct GTY(()) tree_binding 36781 { 36782 struct tree_common common; 36783 union tree_binding_u { 36784 tree GTY ((tag ("0"))) scope; 36785 struct cp_binding_level * GTY ((tag ("1"))) level; 36786 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 36787 tree value; 36788 }; 36789 36790 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 36791 `struct tree_binding *' is presumed to be 0 or 1. If 1, the type 36792 mechanism will treat the field `level' as being present and if 0, 36793 will treat the field `scope' as being present. 36794 36795 `param_is (TYPE)' 36796 `use_param' 36797 Sometimes it's convenient to define some data structure to work on 36798 generic pointers (that is, `PTR') and then use it with a specific 36799 type. `param_is' specifies the real type pointed to, and 36800 `use_param' says where in the generic data structure that type 36801 should be put. 36802 36803 For instance, to have a `htab_t' that points to trees, one would 36804 write the definition of `htab_t' like this: 36805 typedef struct GTY(()) { 36806 ... 36807 void ** GTY ((use_param, ...)) entries; 36808 ... 36809 } htab_t; 36810 and then declare variables like this: 36811 static htab_t GTY ((param_is (union tree_node))) ict; 36812 36813 `paramN_is (TYPE)' 36814 `use_paramN' 36815 In more complicated cases, the data structure might need to work on 36816 several different types, which might not necessarily all be 36817 pointers. For this, `param1_is' through `param9_is' may be used to 36818 specify the real type of a field identified by `use_param1' through 36819 `use_param9'. 36820 36821 `use_params' 36822 When a structure contains another structure that is parameterized, 36823 there's no need to do anything special, the inner structure 36824 inherits the parameters of the outer one. When a structure 36825 contains a pointer to a parameterized structure, the type 36826 machinery won't automatically detect this (it could, it just 36827 doesn't yet), so it's necessary to tell it that the pointed-to 36828 structure should use the same parameters as the outer structure. 36829 This is done by marking the pointer with the `use_params' option. 36830 36831 `deletable' 36832 `deletable', when applied to a global variable, indicates that when 36833 garbage collection runs, there's no need to mark anything pointed 36834 to by this variable, it can just be set to `NULL' instead. This 36835 is used to keep a list of free structures around for re-use. 36836 36837 `if_marked ("EXPRESSION")' 36838 Suppose you want some kinds of object to be unique, and so you put 36839 them in a hash table. If garbage collection marks the hash table, 36840 these objects will never be freed, even if the last other 36841 reference to them goes away. GGC has special handling to deal 36842 with this: if you use the `if_marked' option on a global hash 36843 table, GGC will call the routine whose name is the parameter to 36844 the option on each hash table entry. If the routine returns 36845 nonzero, the hash table entry will be marked as usual. If the 36846 routine returns zero, the hash table entry will be deleted. 36847 36848 The routine `ggc_marked_p' can be used to determine if an element 36849 has been marked already; in fact, the usual case is to use 36850 `if_marked ("ggc_marked_p")'. 36851 36852 `mark_hook ("HOOK-ROUTINE-NAME")' 36853 If provided for a structure or union type, the given 36854 HOOK-ROUTINE-NAME (between double-quotes) is the name of a routine 36855 called when the garbage collector has just marked the data as 36856 reachable. This routine should not change the data, or call any ggc 36857 routine. Its only argument is a pointer to the just marked (const) 36858 structure or union. 36859 36860 `maybe_undef' 36861 When applied to a field, `maybe_undef' indicates that it's OK if 36862 the structure that this fields points to is never defined, so long 36863 as this field is always `NULL'. This is used to avoid requiring 36864 backends to define certain optional structures. It doesn't work 36865 with language frontends. 36866 36867 `nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 36868 The type machinery expects all pointers to point to the start of an 36869 object. Sometimes for abstraction purposes it's convenient to have 36870 a pointer which points inside an object. So long as it's possible 36871 to convert the original object to and from the pointer, such 36872 pointers can still be used. TYPE is the type of the original 36873 object, the TO EXPRESSION returns the pointer given the original 36874 object, and the FROM EXPRESSION returns the original object given 36875 the pointer. The pointer will be available using the `%h' escape. 36876 36877 `chain_next ("EXPRESSION")' 36878 `chain_prev ("EXPRESSION")' 36879 `chain_circular ("EXPRESSION")' 36880 It's helpful for the type machinery to know if objects are often 36881 chained together in long lists; this lets it generate code that 36882 uses less stack space by iterating along the list instead of 36883 recursing down it. `chain_next' is an expression for the next 36884 item in the list, `chain_prev' is an expression for the previous 36885 item. For singly linked lists, use only `chain_next'; for doubly 36886 linked lists, use both. The machinery requires that taking the 36887 next item of the previous item gives the original item. 36888 `chain_circular' is similar to `chain_next', but can be used for 36889 circular single linked lists. 36890 36891 `reorder ("FUNCTION NAME")' 36892 Some data structures depend on the relative ordering of pointers. 36893 If the precompiled header machinery needs to change that ordering, 36894 it will call the function referenced by the `reorder' option, 36895 before changing the pointers in the object that's pointed to by 36896 the field the option applies to. The function must take four 36897 arguments, with the signature 36898 `void *, void *, gt_pointer_operator, void *'. The first 36899 parameter is a pointer to the structure that contains the object 36900 being updated, or the object itself if there is no containing 36901 structure. The second parameter is a cookie that should be 36902 ignored. The third parameter is a routine that, given a pointer, 36903 will update it to its correct new value. The fourth parameter is 36904 a cookie that must be passed to the second parameter. 36905 36906 PCH cannot handle data structures that depend on the absolute 36907 values of pointers. `reorder' functions can be expensive. When 36908 possible, it is better to depend on properties of the data, like 36909 an ID number or the hash of a string instead. 36910 36911 `variable_size' 36912 The type machinery expects the types to be of constant size. When 36913 this is not true, for example, with structs that have array fields 36914 or unions, the type machinery cannot tell how many bytes need to 36915 be allocated at each allocation. The `variable_size' is used to 36916 mark such types. The type machinery then provides allocators that 36917 take a parameter indicating an exact size of object being 36918 allocated. Note that the size must be provided in bytes whereas 36919 the `length' option works with array lengths in number of elements. 36920 36921 For example, 36922 struct GTY((variable_size)) sorted_fields_type { 36923 int len; 36924 tree GTY((length ("%h.len"))) elts[1]; 36925 }; 36926 36927 Then the objects of `struct sorted_fields_type' are allocated in GC 36928 memory as follows: 36929 field_vec = ggc_alloc_sorted_fields_type (size); 36930 36931 If FIELD_VEC->ELTS stores N elements, then SIZE could be 36932 calculated as follows: 36933 size_t size = sizeof (struct sorted_fields_type) + n * sizeof (tree); 36934 36935 `special ("NAME")' 36936 The `special' option is used to mark types that have to be dealt 36937 with by special case machinery. The parameter is the name of the 36938 special case. See `gengtype.c' for further details. Avoid adding 36939 new special cases unless there is no other alternative. 36940 36941 36942 File: gccint.info, Node: GGC Roots, Next: Files, Prev: GTY Options, Up: Type Information 36943 36944 22.2 Marking Roots for the Garbage Collector 36945 ============================================ 36946 36947 In addition to keeping track of types, the type machinery also locates 36948 the global variables ("roots") that the garbage collector starts at. 36949 Roots must be declared using one of the following syntaxes: 36950 36951 * `extern GTY(([OPTIONS])) TYPE NAME;' 36952 36953 * `static GTY(([OPTIONS])) TYPE NAME;' 36954 The syntax 36955 * `GTY(([OPTIONS])) TYPE NAME;' 36956 is _not_ accepted. There should be an `extern' declaration of such a 36957 variable in a header somewhere--mark that, not the definition. Or, if 36958 the variable is only used in one file, make it `static'. 36959 36960 36961 File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 36962 36963 22.3 Source Files Containing Type Information 36964 ============================================= 36965 36966 Whenever you add `GTY' markers to a source file that previously had 36967 none, or create a new source file containing `GTY' markers, there are 36968 three things you need to do: 36969 36970 1. You need to add the file to the list of source files the type 36971 machinery scans. There are four cases: 36972 36973 a. For a back-end file, this is usually done automatically; if 36974 not, you should add it to `target_gtfiles' in the appropriate 36975 port's entries in `config.gcc'. 36976 36977 b. For files shared by all front ends, add the filename to the 36978 `GTFILES' variable in `Makefile.in'. 36979 36980 c. For files that are part of one front end, add the filename to 36981 the `gtfiles' variable defined in the appropriate 36982 `config-lang.in'. For C, the file is `c-config-lang.in'. 36983 Headers should appear before non-headers in this list. 36984 36985 d. For files that are part of some but not all front ends, add 36986 the filename to the `gtfiles' variable of _all_ the front ends 36987 that use it. 36988 36989 2. If the file was a header file, you'll need to check that it's 36990 included in the right place to be visible to the generated files. 36991 For a back-end header file, this should be done automatically. 36992 For a front-end header file, it needs to be included by the same 36993 file that includes `gtype-LANG.h'. For other header files, it 36994 needs to be included in `gtype-desc.c', which is a generated file, 36995 so add it to `ifiles' in `open_base_file' in `gengtype.c'. 36996 36997 For source files that aren't header files, the machinery will 36998 generate a header file that should be included in the source file 36999 you just changed. The file will be called `gt-PATH.h' where PATH 37000 is the pathname relative to the `gcc' directory with slashes 37001 replaced by -, so for example the header file to be included in 37002 `cp/parser.c' is called `gt-cp-parser.c'. The generated header 37003 file should be included after everything else in the source file. 37004 Don't forget to mention this file as a dependency in the 37005 `Makefile'! 37006 37007 37008 For language frontends, there is another file that needs to be included 37009 somewhere. It will be called `gtype-LANG.h', where LANG is the name of 37010 the subdirectory the language is contained in. 37011 37012 Plugins can add additional root tables. Run the `gengtype' utility in 37013 plugin mode as `gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 37014 with your plugin files PLUGIN*.C using `GTY' to generate the 37015 PLUGINOUT.H file. The GCC build tree is needed to be present in that 37016 mode. 37017 37018 37019 File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information 37020 37021 22.4 How to invoke the garbage collector 37022 ======================================== 37023 37024 The GCC garbage collector GGC is only invoked explicitly. In contrast 37025 with many other garbage collectors, it is not implicitly invoked by 37026 allocation routines when a lot of memory has been consumed. So the only 37027 way to have GGC reclaim storage it to call the `ggc_collect' function 37028 explicitly. This call is an expensive operation, as it may have to 37029 scan the entire heap. Beware that local variables (on the GCC call 37030 stack) are not followed by such an invocation (as many other garbage 37031 collectors do): you should reference all your data from static or 37032 external `GTY'-ed variables, and it is advised to call `ggc_collect' 37033 with a shallow call stack. The GGC is an exact mark and sweep garbage 37034 collector (so it does not scan the call stack for pointers). In 37035 practice GCC passes don't often call `ggc_collect' themselves, because 37036 it is called by the pass manager between passes. 37037 37038 At the time of the `ggc_collect' call all pointers in the GC-marked 37039 structures must be valid or `NULL'. In practice this means that there 37040 should not be uninitialized pointer fields in the structures even if 37041 your code never reads or writes those fields at a particular instance. 37042 One way to ensure this is to use cleared versions of allocators unless 37043 all the fields are initialized manually immediately after allocation. 37044 37045 37046 File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information 37047 37048 22.5 Troubleshooting the garbage collector 37049 ========================================== 37050 37051 With the current garbage collector implementation, most issues should 37052 show up as GCC compilation errors. Some of the most commonly 37053 encountered issues are described below. 37054 37055 * Gengtype does not produce allocators for a `GTY'-marked type. 37056 Gengtype checks if there is at least one possible path from GC 37057 roots to at least one instance of each type before outputting 37058 allocators. If there is no such path, the `GTY' markers will be 37059 ignored and no allocators will be output. Solve this by making 37060 sure that there exists at least one such path. If creating it is 37061 unfeasible or raises a "code smell", consider if you really must 37062 use GC for allocating such type. 37063 37064 * Link-time errors about undefined `gt_ggc_r_foo_bar' and 37065 similarly-named symbols. Check if your `foo_bar' source file has 37066 `#include "gt-foo_bar.h"' as its very last line. 37067 37068 37069 37070 File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top 37071 37072 23 Plugins 37073 ********** 37074 37075 23.1 Loading Plugins 37076 ==================== 37077 37078 Plugins are supported on platforms that support `-ldl -rdynamic'. They 37079 are loaded by the compiler using `dlopen' and invoked at pre-determined 37080 locations in the compilation process. 37081 37082 Plugins are loaded with 37083 37084 `-fplugin=/path/to/NAME.so' `-fplugin-arg-NAME-KEY1[=VALUE1]' 37085 37086 The plugin arguments are parsed by GCC and passed to respective 37087 plugins as key-value pairs. Multiple plugins can be invoked by 37088 specifying multiple `-fplugin' arguments. 37089 37090 A plugin can be simply given by its short name (no dots or slashes). 37091 When simply passing `-fplugin=NAME', the plugin is loaded from the 37092 `plugin' directory, so `-fplugin=NAME' is the same as `-fplugin=`gcc 37093 -print-file-name=plugin`/NAME.so', using backquote shell syntax to 37094 query the `plugin' directory. 37095 37096 23.2 Plugin API 37097 =============== 37098 37099 Plugins are activated by the compiler at specific events as defined in 37100 `gcc-plugin.h'. For each event of interest, the plugin should call 37101 `register_callback' specifying the name of the event and address of the 37102 callback function that will handle that event. 37103 37104 The header `gcc-plugin.h' must be the first gcc header to be included. 37105 37106 23.2.1 Plugin license check 37107 --------------------------- 37108 37109 Every plugin should define the global symbol `plugin_is_GPL_compatible' 37110 to assert that it has been licensed under a GPL-compatible license. If 37111 this symbol does not exist, the compiler will emit a fatal error and 37112 exit with the error message: 37113 37114 fatal error: plugin NAME is not licensed under a GPL-compatible license 37115 NAME: undefined symbol: plugin_is_GPL_compatible 37116 compilation terminated 37117 37118 The declared type of the symbol should be int, to match a forward 37119 declaration in `gcc-plugin.h' that suppresses C++ mangling. It does 37120 not need to be in any allocated section, though. The compiler merely 37121 asserts that the symbol exists in the global scope. Something like 37122 this is enough: 37123 37124 int plugin_is_GPL_compatible; 37125 37126 23.2.2 Plugin initialization 37127 ---------------------------- 37128 37129 Every plugin should export a function called `plugin_init' that is 37130 called right after the plugin is loaded. This function is responsible 37131 for registering all the callbacks required by the plugin and do any 37132 other required initialization. 37133 37134 This function is called from `compile_file' right before invoking the 37135 parser. The arguments to `plugin_init' are: 37136 37137 * `plugin_info': Plugin invocation information. 37138 37139 * `version': GCC version. 37140 37141 The `plugin_info' struct is defined as follows: 37142 37143 struct plugin_name_args 37144 { 37145 char *base_name; /* Short name of the plugin 37146 (filename without .so suffix). */ 37147 const char *full_name; /* Path to the plugin as specified with 37148 -fplugin=. */ 37149 int argc; /* Number of arguments specified with 37150 -fplugin-arg-.... */ 37151 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 37152 const char *version; /* Version string provided by plugin. */ 37153 const char *help; /* Help string provided by plugin. */ 37154 } 37155 37156 If initialization fails, `plugin_init' must return a non-zero value. 37157 Otherwise, it should return 0. 37158 37159 The version of the GCC compiler loading the plugin is described by the 37160 following structure: 37161 37162 struct plugin_gcc_version 37163 { 37164 const char *basever; 37165 const char *datestamp; 37166 const char *devphase; 37167 const char *revision; 37168 const char *configuration_arguments; 37169 }; 37170 37171 The function `plugin_default_version_check' takes two pointers to such 37172 structure and compare them field by field. It can be used by the 37173 plugin's `plugin_init' function. 37174 37175 The version of GCC used to compile the plugin can be found in the 37176 symbol `gcc_version' defined in the header `plugin-version.h'. The 37177 recommended version check to perform looks like 37178 37179 #include "plugin-version.h" 37180 ... 37181 37182 int 37183 plugin_init (struct plugin_name_args *plugin_info, 37184 struct plugin_gcc_version *version) 37185 { 37186 if (!plugin_default_version_check (version, &gcc_version)) 37187 return 1; 37188 37189 } 37190 37191 but you can also check the individual fields if you want a less strict 37192 check. 37193 37194 23.2.3 Plugin callbacks 37195 ----------------------- 37196 37197 Callback functions have the following prototype: 37198 37199 /* The prototype for a plugin callback function. 37200 gcc_data - event-specific data provided by GCC 37201 user_data - plugin-specific data provided by the plug-in. */ 37202 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 37203 37204 Callbacks can be invoked at the following pre-determined events: 37205 37206 enum plugin_event 37207 { 37208 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 37209 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 37210 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 37211 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 37212 PLUGIN_FINISH, /* Called before GCC exits. */ 37213 PLUGIN_INFO, /* Information about the plugin. */ 37214 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 37215 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 37216 PLUGIN_GGC_END, /* Called at end of GGC. */ 37217 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 37218 PLUGIN_REGISTER_GGC_CACHES, /* Register an extra GGC cache table. */ 37219 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 37220 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 37221 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 37222 /* Called before first pass from all_passes. */ 37223 PLUGIN_ALL_PASSES_START, 37224 /* Called after last pass from all_passes. */ 37225 PLUGIN_ALL_PASSES_END, 37226 /* Called before first ipa pass. */ 37227 PLUGIN_ALL_IPA_PASSES_START, 37228 /* Called after last ipa pass. */ 37229 PLUGIN_ALL_IPA_PASSES_END, 37230 /* Allows to override pass gate decision for current_pass. */ 37231 PLUGIN_OVERRIDE_GATE, 37232 /* Called before executing a pass. */ 37233 PLUGIN_PASS_EXECUTION, 37234 /* Called before executing subpasses of a GIMPLE_PASS in 37235 execute_ipa_pass_list. */ 37236 PLUGIN_EARLY_GIMPLE_PASSES_START, 37237 /* Called after executing subpasses of a GIMPLE_PASS in 37238 execute_ipa_pass_list. */ 37239 PLUGIN_EARLY_GIMPLE_PASSES_END, 37240 /* Called when a pass is first instantiated. */ 37241 PLUGIN_NEW_PASS, 37242 37243 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 37244 array. */ 37245 }; 37246 37247 In addition, plugins can also look up the enumerator of a named event, 37248 and / or generate new events dynamically, by calling the function 37249 `get_named_event_id'. 37250 37251 To register a callback, the plugin calls `register_callback' with the 37252 arguments: 37253 37254 * `char *name': Plugin name. 37255 37256 * `int event': The event code. 37257 37258 * `plugin_callback_func callback': The function that handles `event'. 37259 37260 * `void *user_data': Pointer to plugin-specific data. 37261 37262 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, 37263 PLUGIN_REGISTER_GGC_ROOTS and PLUGIN_REGISTER_GGC_CACHES pseudo-events 37264 the `callback' should be null, and the `user_data' is specific. 37265 37266 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as 37267 data from GCC), plugins may register their own pragmas using functions 37268 like `c_register_pragma' or `c_register_pragma_with_expansion'. 37269 37270 23.3 Interacting with the pass manager 37271 ====================================== 37272 37273 There needs to be a way to add/reorder/remove passes dynamically. This 37274 is useful for both analysis plugins (plugging in after a certain pass 37275 such as CFG or an IPA pass) and optimization plugins. 37276 37277 Basic support for inserting new passes or replacing existing passes is 37278 provided. A plugin registers a new pass with GCC by calling 37279 `register_callback' with the `PLUGIN_PASS_MANAGER_SETUP' event and a 37280 pointer to a `struct register_pass_info' object defined as follows 37281 37282 enum pass_positioning_ops 37283 { 37284 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 37285 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 37286 PASS_POS_REPLACE // Replace the reference pass. 37287 }; 37288 37289 struct register_pass_info 37290 { 37291 struct opt_pass *pass; /* New pass provided by the plugin. */ 37292 const char *reference_pass_name; /* Name of the reference pass for hooking 37293 up the new pass. */ 37294 int ref_pass_instance_number; /* Insert the pass at the specified 37295 instance number of the reference pass. */ 37296 /* Do it for every instance if it is 0. */ 37297 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 37298 }; 37299 37300 37301 /* Sample plugin code that registers a new pass. */ 37302 int 37303 plugin_init (struct plugin_name_args *plugin_info, 37304 struct plugin_gcc_version *version) 37305 { 37306 struct register_pass_info pass_info; 37307 37308 ... 37309 37310 /* Code to fill in the pass_info object with new pass information. */ 37311 37312 ... 37313 37314 /* Register the new pass. */ 37315 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 37316 37317 ... 37318 } 37319 37320 23.4 Interacting with the GCC Garbage Collector 37321 =============================================== 37322 37323 Some plugins may want to be informed when GGC (the GCC Garbage 37324 Collector) is running. They can register callbacks for the 37325 `PLUGIN_GGC_START' and `PLUGIN_GGC_END' events (for which the callback 37326 is called with a null `gcc_data') to be notified of the start or end of 37327 the GCC garbage collection. 37328 37329 Some plugins may need to have GGC mark additional data. This can be 37330 done by registering a callback (called with a null `gcc_data') for the 37331 `PLUGIN_GGC_MARKING' event. Such callbacks can call the `ggc_set_mark' 37332 routine, preferably thru the `ggc_mark' macro (and conversely, these 37333 routines should usually not be used in plugins outside of the 37334 `PLUGIN_GGC_MARKING' event). 37335 37336 Some plugins may need to add extra GGC root tables, e.g. to handle 37337 their own `GTY'-ed data. This can be done with the 37338 `PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 37339 extra root table (of type `struct ggc_root_tab*') as `user_data'. 37340 Plugins that want to use the `if_marked' hash table option can add the 37341 extra GGC cache tables generated by `gengtype' using the 37342 `PLUGIN_REGISTER_GGC_CACHES' pseudo-event with a null callback and the 37343 extra cache table (of type `struct ggc_cache_tab*') as `user_data'. 37344 Running the `gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 37345 generates these extra root tables. 37346 37347 You should understand the details of memory management inside GCC 37348 before using `PLUGIN_GGC_MARKING', `PLUGIN_REGISTER_GGC_ROOTS' or 37349 `PLUGIN_REGISTER_GGC_CACHES'. 37350 37351 23.5 Giving information about a plugin 37352 ====================================== 37353 37354 A plugin should give some information to the user about itself. This 37355 uses the following structure: 37356 37357 struct plugin_info 37358 { 37359 const char *version; 37360 const char *help; 37361 }; 37362 37363 Such a structure is passed as the `user_data' by the plugin's init 37364 routine using `register_callback' with the `PLUGIN_INFO' pseudo-event 37365 and a null callback. 37366 37367 23.6 Registering custom attributes or pragmas 37368 ============================================= 37369 37370 For analysis (or other) purposes it is useful to be able to add custom 37371 attributes or pragmas. 37372 37373 The `PLUGIN_ATTRIBUTES' callback is called during attribute 37374 registration. Use the `register_attribute' function to register custom 37375 attributes. 37376 37377 /* Attribute handler callback */ 37378 static tree 37379 handle_user_attribute (tree *node, tree name, tree args, 37380 int flags, bool *no_add_attrs) 37381 { 37382 return NULL_TREE; 37383 } 37384 37385 /* Attribute definition */ 37386 static struct attribute_spec user_attr = 37387 { "user", 1, 1, false, false, false, handle_user_attribute }; 37388 37389 /* Plugin callback called during attribute registration. 37390 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 37391 */ 37392 static void 37393 register_attributes (void *event_data, void *data) 37394 { 37395 warning (0, G_("Callback to register attributes")); 37396 register_attribute (&user_attr); 37397 } 37398 37399 The `PLUGIN_PRAGMAS' callback is called during pragmas registration. 37400 Use the `c_register_pragma' or `c_register_pragma_with_expansion' 37401 functions to register custom pragmas. 37402 37403 /* Plugin callback called during pragmas registration. Registered with 37404 register_callback (plugin_name, PLUGIN_PRAGMAS, 37405 register_my_pragma, NULL); 37406 */ 37407 static void 37408 register_my_pragma (void *event_data, void *data) 37409 { 37410 warning (0, G_("Callback to register pragmas")); 37411 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 37412 } 37413 37414 It is suggested to pass `"GCCPLUGIN"' (or a short name identifying 37415 your plugin) as the "space" argument of your pragma. 37416 37417 23.7 Recording information about pass execution 37418 =============================================== 37419 37420 The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 37421 (the same as current_pass) as `gcc_data' to the callback. You can also 37422 inspect cfun to find out about which function this pass is executed for. 37423 Note that this event will only be invoked if the gate check (if 37424 applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 37425 other hooks, like `PLUGIN_ALL_PASSES_START', `PLUGIN_ALL_PASSES_END', 37426 `PLUGIN_ALL_IPA_PASSES_START', `PLUGIN_ALL_IPA_PASSES_END', 37427 `PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 37428 `PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 37429 plugin(s) in order to get context for the pass execution. 37430 37431 23.8 Controlling which passes are being run 37432 =========================================== 37433 37434 After the original gate function for a pass is called, its result - the 37435 gate status - is stored as an integer. Then the event 37436 `PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 37437 the `gcc_data' parameter to the callback function. A nonzero value of 37438 the gate status means that the pass is to be executed. You can both 37439 read and write the gate status via the passed pointer. 37440 37441 23.9 Keeping track of available passes 37442 ====================================== 37443 37444 When your plugin is loaded, you can inspect the various pass lists to 37445 determine what passes are available. However, other plugins might add 37446 new passes. Also, future changes to GCC might cause generic passes to 37447 be added after plugin loading. When a pass is first added to one of 37448 the pass lists, the event `PLUGIN_NEW_PASS' is invoked, with the 37449 callback parameter `gcc_data' pointing to the new pass. 37450 37451 23.10 Building GCC plugins 37452 ========================== 37453 37454 If plugins are enabled, GCC installs the headers needed to build a 37455 plugin (somewhere in the installation tree, e.g. under `/usr/local'). 37456 In particular a `plugin/include' directory is installed, containing all 37457 the header files needed to build plugins. 37458 37459 On most systems, you can query this `plugin' directory by invoking 37460 `gcc -print-file-name=plugin' (replace if needed `gcc' with the 37461 appropriate program path). 37462 37463 Inside plugins, this `plugin' directory name can be queried by calling 37464 `default_plugin_dir_name ()'. 37465 37466 The following GNU Makefile excerpt shows how to build a simple plugin: 37467 37468 GCC=gcc 37469 PLUGIN_SOURCE_FILES= plugin1.c plugin2.c 37470 PLUGIN_OBJECT_FILES= $(patsubst %.c,%.o,$(PLUGIN_SOURCE_FILES)) 37471 GCCPLUGINS_DIR:= $(shell $(GCC) -print-file-name=plugin) 37472 CFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -O2 37473 37474 plugin.so: $(PLUGIN_OBJECT_FILES) 37475 $(GCC) -shared $^ -o $@ 37476 37477 A single source file plugin may be built with `gcc -I`gcc 37478 -print-file-name=plugin`/include -fPIC -shared -O2 plugin.c -o 37479 plugin.so', using backquote shell syntax to query the `plugin' 37480 directory. 37481 37482 Plugins needing to use `gengtype' require a GCC build directory for 37483 the same version of GCC that they will be linked against. 37484 37485 37486 File: gccint.info, Node: LTO, Next: Funding, Prev: Plugins, Up: Top 37487 37488 24 Link Time Optimization 37489 ************************* 37490 37491 24.1 Design Overview 37492 ==================== 37493 37494 Link time optimization is implemented as a GCC front end for a bytecode 37495 representation of GIMPLE that is emitted in special sections of `.o' 37496 files. Currently, LTO support is enabled in most ELF-based systems, as 37497 well as darwin, cygwin and mingw systems. 37498 37499 Since GIMPLE bytecode is saved alongside final object code, object 37500 files generated with LTO support are larger than regular object files. 37501 This "fat" object format makes it easy to integrate LTO into existing 37502 build systems, as one can, for instance, produce archives of the files. 37503 Additionally, one might be able to ship one set of fat objects which 37504 could be used both for development and the production of optimized 37505 builds. A, perhaps surprising, side effect of this feature is that any 37506 mistake in the toolchain that leads to LTO information not being used 37507 (e.g. an older `libtool' calling `ld' directly). This is both an 37508 advantage, as the system is more robust, and a disadvantage, as the 37509 user is not informed that the optimization has been disabled. 37510 37511 The current implementation only produces "fat" objects, effectively 37512 doubling compilation time and increasing file sizes up to 5x the 37513 original size. This hides the problem that some tools, such as `ar' 37514 and `nm', need to understand symbol tables of LTO sections. These 37515 tools were extended to use the plugin infrastructure, and with these 37516 problems solved, GCC will also support "slim" objects consisting of the 37517 intermediate code alone. 37518 37519 At the highest level, LTO splits the compiler in two. The first half 37520 (the "writer") produces a streaming representation of all the internal 37521 data structures needed to optimize and generate code. This includes 37522 declarations, types, the callgraph and the GIMPLE representation of 37523 function bodies. 37524 37525 When `-flto' is given during compilation of a source file, the pass 37526 manager executes all the passes in `all_lto_gen_passes'. Currently, 37527 this phase is composed of two IPA passes: 37528 37529 * `pass_ipa_lto_gimple_out' This pass executes the function 37530 `lto_output' in `lto-streamer-out.c', which traverses the call 37531 graph encoding every reachable declaration, type and function. 37532 This generates a memory representation of all the file sections 37533 described below. 37534 37535 * `pass_ipa_lto_finish_out' This pass executes the function 37536 `produce_asm_for_decls' in `lto-streamer-out.c', which takes the 37537 memory image built in the previous pass and encodes it in the 37538 corresponding ELF file sections. 37539 37540 The second half of LTO support is the "reader". This is implemented 37541 as the GCC front end `lto1' in `lto/lto.c'. When `collect2' detects a 37542 link set of `.o'/`.a' files with LTO information and the `-flto' is 37543 enabled, it invokes `lto1' which reads the set of files and aggregates 37544 them into a single translation unit for optimization. The main entry 37545 point for the reader is `lto/lto.c':`lto_main'. 37546 37547 24.1.1 LTO modes of operation 37548 ----------------------------- 37549 37550 One of the main goals of the GCC link-time infrastructure was to allow 37551 effective compilation of large programs. For this reason GCC 37552 implements two link-time compilation modes. 37553 37554 1. _LTO mode_, in which the whole program is read into the compiler 37555 at link-time and optimized in a similar way as if it were a single 37556 source-level compilation unit. 37557 37558 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs 37559 and/or a distributed compilation environment to quickly link large 37560 applications. WHOPR stands for WHOle Program optimizeR (not to be 37561 confused with the semantics of `-fwhole-program'). It partitions 37562 the aggregated callgraph from many different `.o' files and 37563 distributes the compilation of the sub-graphs to different CPUs. 37564 37565 Note that distributed compilation is not implemented yet, but since 37566 the parallelism is facilitated via generating a `Makefile', it 37567 would be easy to implement. 37568 37569 WHOPR splits LTO into three main stages: 37570 1. Local generation (LGEN) This stage executes in parallel. Every 37571 file in the program is compiled into the intermediate language and 37572 packaged together with the local call-graph and summary 37573 information. This stage is the same for both the LTO and WHOPR 37574 compilation mode. 37575 37576 2. Whole Program Analysis (WPA) WPA is performed sequentially. The 37577 global call-graph is generated, and a global analysis procedure 37578 makes transformation decisions. The global call-graph is 37579 partitioned to facilitate parallel optimization during phase 3. 37580 The results of the WPA stage are stored into new object files 37581 which contain the partitions of program expressed in the 37582 intermediate language and the optimization decisions. 37583 37584 3. Local transformations (LTRANS) This stage executes in parallel. 37585 All the decisions made during phase 2 are implemented locally in 37586 each partitioned object file, and the final object code is 37587 generated. Optimizations which cannot be decided efficiently 37588 during the phase 2 may be performed on the local call-graph 37589 partitions. 37590 37591 WHOPR can be seen as an extension of the usual LTO mode of 37592 compilation. In LTO, WPA and LTRANS are executed within a single 37593 execution of the compiler, after the whole program has been read into 37594 memory. 37595 37596 When compiling in WHOPR mode, the callgraph is partitioned during the 37597 WPA stage. The whole program is split into a given number of 37598 partitions of roughly the same size. The compiler tries to minimize 37599 the number of references which cross partition boundaries. The main 37600 advantage of WHOPR is to allow the parallel execution of LTRANS stages, 37601 which are the most time-consuming part of the compilation process. 37602 Additionally, it avoids the need to load the whole program into memory. 37603 37604 24.2 LTO file sections 37605 ====================== 37606 37607 LTO information is stored in several ELF sections inside object files. 37608 Data structures and enum codes for sections are defined in 37609 `lto-streamer.h'. 37610 37611 These sections are emitted from `lto-streamer-out.c' and mapped in all 37612 at once from `lto/lto.c':`lto_file_read'. The individual functions 37613 dealing with the reading/writing of each section are described below. 37614 37615 * Command line options (`.gnu.lto_.opts') 37616 37617 This section contains the command line options used to generate the 37618 object files. This is used at link time to determine the 37619 optimization level and other settings when they are not explicitly 37620 specified at the linker command line. 37621 37622 Currently, GCC does not support combining LTO object files compiled 37623 with different set of the command line options into a single 37624 binary. At link time, the options given on the command line and 37625 the options saved on all the files in a link-time set are applied 37626 globally. No attempt is made at validating the combination of 37627 flags (other than the usual validation done by option processing). 37628 This is implemented in `lto/lto.c':`lto_read_all_file_options'. 37629 37630 * Symbol table (`.gnu.lto_.symtab') 37631 37632 This table replaces the ELF symbol table for functions and 37633 variables represented in the LTO IL. Symbols used and exported by 37634 the optimized assembly code of "fat" objects might not match the 37635 ones used and exported by the intermediate code. This table is 37636 necessary because the intermediate code is less optimized and thus 37637 requires a separate symbol table. 37638 37639 Additionally, the binary code in the "fat" object will lack a call 37640 to a function, since the call was optimized out at compilation time 37641 after the intermediate language was streamed out. In some special 37642 cases, the same optimization may not happen during link-time 37643 optimization. This would lead to an undefined symbol if only one 37644 symbol table was used. 37645 37646 The symbol table is emitted in 37647 `lto-streamer-out.c':`produce_symtab'. 37648 37649 * Global declarations and types (`.gnu.lto_.decls') 37650 37651 This section contains an intermediate language dump of all 37652 declarations and types required to represent the callgraph, static 37653 variables and top-level debug info. 37654 37655 The contents of this section are emitted in 37656 `lto-streamer-out.c':`produce_asm_for_decls'. Types and symbols 37657 are emitted in a topological order that preserves the sharing of 37658 pointers when the file is read back in 37659 (`lto.c':`read_cgraph_and_symbols'). 37660 37661 * The callgraph (`.gnu.lto_.cgraph') 37662 37663 This section contains the basic data structure used by the GCC 37664 inter-procedural optimization infrastructure. This section stores 37665 an annotated multi-graph which represents the functions and call 37666 sites as well as the variables, aliases and top-level `asm' 37667 statements. 37668 37669 This section is emitted in `lto-streamer-out.c':`output_cgraph' 37670 and read in `lto-cgraph.c':`input_cgraph'. 37671 37672 * IPA references (`.gnu.lto_.refs') 37673 37674 This section contains references between function and static 37675 variables. It is emitted by `lto-cgraph.c':`output_refs' and read 37676 by `lto-cgraph.c':`input_refs'. 37677 37678 * Function bodies (`.gnu.lto_.function_body.<name>') 37679 37680 This section contains function bodies in the intermediate language 37681 representation. Every function body is in a separate section to 37682 allow copying of the section independently to different object 37683 files or reading the function on demand. 37684 37685 Functions are emitted in `lto-streamer-out.c':`output_function' 37686 and read in `lto-streamer-in.c':`input_function'. 37687 37688 * Static variable initializers (`.gnu.lto_.vars') 37689 37690 This section contains all the symbols in the global variable pool. 37691 It is emitted by `lto-cgraph.c':`output_varpool' and read in 37692 `lto-cgraph.c':`input_cgraph'. 37693 37694 * Summaries and optimization summaries used by IPA passes 37695 (`.gnu.lto_.<xxx>', where `<xxx>' is one of `jmpfuncs', 37696 `pureconst' or `reference') 37697 37698 These sections are used by IPA passes that need to emit summary 37699 information during LTO generation to be read and aggregated at 37700 link time. Each pass is responsible for implementing two pass 37701 manager hooks: one for writing the summary and another for reading 37702 it in. The format of these sections is entirely up to each 37703 individual pass. The only requirement is that the writer and 37704 reader hooks agree on the format. 37705 37706 24.3 Using summary information in IPA passes 37707 ============================================ 37708 37709 Programs are represented internally as a _callgraph_ (a multi-graph 37710 where nodes are functions and edges are call sites) and a _varpool_ (a 37711 list of static and external variables in the program). 37712 37713 The inter-procedural optimization is organized as a sequence of 37714 individual passes, which operate on the callgraph and the varpool. To 37715 make the implementation of WHOPR possible, every inter-procedural 37716 optimization pass is split into several stages that are executed at 37717 different times during WHOPR compilation: 37718 37719 * LGEN time 37720 1. _Generate summary_ (`generate_summary' in `struct 37721 ipa_opt_pass_d'). This stage analyzes every function body 37722 and variable initializer is examined and stores relevant 37723 information into a pass-specific data structure. 37724 37725 2. _Write summary_ (`write_summary' in `struct ipa_opt_pass_d'). 37726 This stage writes all the pass-specific information generated 37727 by `generate_summary'. Summaries go into their own 37728 `LTO_section_*' sections that have to be declared in 37729 `lto-streamer.h':`enum lto_section_type'. A new section is 37730 created by calling `create_output_block' and data can be 37731 written using the `lto_output_*' routines. 37732 37733 * WPA time 37734 1. _Read summary_ (`read_summary' in `struct ipa_opt_pass_d'). 37735 This stage reads all the pass-specific information in exactly 37736 the same order that it was written by `write_summary'. 37737 37738 2. _Execute_ (`execute' in `struct opt_pass'). This performs 37739 inter-procedural propagation. This must be done without 37740 actual access to the individual function bodies or variable 37741 initializers. Typically, this results in a transitive 37742 closure operation over the summary information of all the 37743 nodes in the callgraph. 37744 37745 3. _Write optimization summary_ (`write_optimization_summary' in 37746 `struct ipa_opt_pass_d'). This writes the result of the 37747 inter-procedural propagation into the object file. This can 37748 use the same data structures and helper routines used in 37749 `write_summary'. 37750 37751 * LTRANS time 37752 1. _Read optimization summary_ (`read_optimization_summary' in 37753 `struct ipa_opt_pass_d'). The counterpart to 37754 `write_optimization_summary'. This reads the interprocedural 37755 optimization decisions in exactly the same format emitted by 37756 `write_optimization_summary'. 37757 37758 2. _Transform_ (`function_transform' and `variable_transform' in 37759 `struct ipa_opt_pass_d'). The actual function bodies and 37760 variable initializers are updated based on the information 37761 passed down from the _Execute_ stage. 37762 37763 The implementation of the inter-procedural passes are shared between 37764 LTO, WHOPR and classic non-LTO compilation. 37765 37766 * During the traditional file-by-file mode every pass executes its 37767 own _Generate summary_, _Execute_, and _Transform_ stages within 37768 the single execution context of the compiler. 37769 37770 * In LTO compilation mode, every pass uses _Generate summary_ and 37771 _Write summary_ stages at compilation time, while the _Read 37772 summary_, _Execute_, and _Transform_ stages are executed at link 37773 time. 37774 37775 * In WHOPR mode all stages are used. 37776 37777 To simplify development, the GCC pass manager differentiates between 37778 normal inter-procedural passes and small inter-procedural passes. A 37779 _small inter-procedural pass_ (`SIMPLE_IPA_PASS') is a pass that does 37780 everything at once and thus it can not be executed during WPA in WHOPR 37781 mode. It defines only the _Execute_ stage and during this stage it 37782 accesses and modifies the function bodies. Such passes are useful for 37783 optimization at LGEN or LTRANS time and are used, for example, to 37784 implement early optimization before writing object files. The simple 37785 inter-procedural passes can also be used for easier prototyping and 37786 development of a new inter-procedural pass. 37787 37788 24.3.1 Virtual clones 37789 --------------------- 37790 37791 One of the main challenges of introducing the WHOPR compilation mode 37792 was addressing the interactions between optimization passes. In LTO 37793 compilation mode, the passes are executed in a sequence, each of which 37794 consists of analysis (or _Generate summary_), propagation (or 37795 _Execute_) and _Transform_ stages. Once the work of one pass is 37796 finished, the next pass sees the updated program representation and can 37797 execute. This makes the individual passes dependent on each other. 37798 37799 In WHOPR mode all passes first execute their _Generate summary_ stage. 37800 Then summary writing marks the end of the LGEN stage. At WPA time, the 37801 summaries are read back into memory and all passes run the _Execute_ 37802 stage. Optimization summaries are streamed and sent to LTRANS, where 37803 all the passes execute the _Transform_ stage. 37804 37805 Most optimization passes split naturally into analysis, propagation 37806 and transformation stages. But some do not. The main problem arises 37807 when one pass performs changes and the following pass gets confused by 37808 seeing different callgraphs between the _Transform_ stage and the 37809 _Generate summary_ or _Execute_ stage. This means that the passes are 37810 required to communicate their decisions with each other. 37811 37812 To facilitate this communication, the GCC callgraph infrastructure 37813 implements _virtual clones_, a method of representing the changes 37814 performed by the optimization passes in the callgraph without needing 37815 to update function bodies. 37816 37817 A _virtual clone_ in the callgraph is a function that has no 37818 associated body, just a description of how to create its body based on 37819 a different function (which itself may be a virtual clone). 37820 37821 The description of function modifications includes adjustments to the 37822 function's signature (which allows, for example, removing or adding 37823 function arguments), substitutions to perform on the function body, 37824 and, for inlined functions, a pointer to the function that it will be 37825 inlined into. 37826 37827 It is also possible to redirect any edge of the callgraph from a 37828 function to its virtual clone. This implies updating of the call site 37829 to adjust for the new function signature. 37830 37831 Most of the transformations performed by inter-procedural 37832 optimizations can be represented via virtual clones. For instance, a 37833 constant propagation pass can produce a virtual clone of the function 37834 which replaces one of its arguments by a constant. The inliner can 37835 represent its decisions by producing a clone of a function whose body 37836 will be later integrated into a given function. 37837 37838 Using _virtual clones_, the program can be easily updated during the 37839 _Execute_ stage, solving most of pass interactions problems that would 37840 otherwise occur during _Transform_. 37841 37842 Virtual clones are later materialized in the LTRANS stage and turned 37843 into real functions. Passes executed after the virtual clone were 37844 introduced also perform their _Transform_ stage on new functions, so 37845 for a pass there is no significant difference between operating on a 37846 real function or a virtual clone introduced before its _Execute_ stage. 37847 37848 Optimization passes then work on virtual clones introduced before 37849 their _Execute_ stage as if they were real functions. The only 37850 difference is that clones are not visible during the _Generate Summary_ 37851 stage. 37852 37853 To keep function summaries updated, the callgraph interface allows an 37854 optimizer to register a callback that is called every time a new clone 37855 is introduced as well as when the actual function or variable is 37856 generated or when a function or variable is removed. These hooks are 37857 registered in the _Generate summary_ stage and allow the pass to keep 37858 its information intact until the _Execute_ stage. The same hooks can 37859 also be registered during the _Execute_ stage to keep the optimization 37860 summaries updated for the _Transform_ stage. 37861 37862 24.3.2 IPA references 37863 --------------------- 37864 37865 GCC represents IPA references in the callgraph. For a function or 37866 variable `A', the _IPA reference_ is a list of all locations where the 37867 address of `A' is taken and, when `A' is a variable, a list of all 37868 direct stores and reads to/from `A'. References represent an oriented 37869 multi-graph on the union of nodes of the callgraph and the varpool. See 37870 `ipa-reference.c':`ipa_reference_write_optimization_summary' and 37871 `ipa-reference.c':`ipa_reference_read_optimization_summary' for details. 37872 37873 24.3.3 Jump functions 37874 --------------------- 37875 37876 Suppose that an optimization pass sees a function `A' and it knows the 37877 values of (some of) its arguments. The _jump function_ describes the 37878 value of a parameter of a given function call in function `A' based on 37879 this knowledge. 37880 37881 Jump functions are used by several optimizations, such as the 37882 inter-procedural constant propagation pass and the devirtualization 37883 pass. The inliner also uses jump functions to perform inlining of 37884 callbacks. 37885 37886 24.4 Whole program assumptions, linker plugin and symbol visibilities 37887 ===================================================================== 37888 37889 Link-time optimization gives relatively minor benefits when used alone. 37890 The problem is that propagation of inter-procedural information does 37891 not work well across functions and variables that are called or 37892 referenced by other compilation units (such as from a dynamically 37893 linked library). We say that such functions are variables are 37894 _externally visible_. 37895 37896 To make the situation even more difficult, many applications organize 37897 themselves as a set of shared libraries, and the default ELF visibility 37898 rules allow one to overwrite any externally visible symbol with a 37899 different symbol at runtime. This basically disables any optimizations 37900 across such functions and variables, because the compiler cannot be 37901 sure that the function body it is seeing is the same function body that 37902 will be used at runtime. Any function or variable not declared 37903 `static' in the sources degrades the quality of inter-procedural 37904 optimization. 37905 37906 To avoid this problem the compiler must assume that it sees the whole 37907 program when doing link-time optimization. Strictly speaking, the 37908 whole program is rarely visible even at link-time. Standard system 37909 libraries are usually linked dynamically or not provided with the 37910 link-time information. In GCC, the whole program option 37911 (`-fwhole-program') asserts that every function and variable defined in 37912 the current compilation unit is static, except for function `main' 37913 (note: at link time, the current unit is the union of all objects 37914 compiled with LTO). Since some functions and variables need to be 37915 referenced externally, for example by another DSO or from an assembler 37916 file, GCC also provides the function and variable attribute 37917 `externally_visible' which can be used to disable the effect of 37918 `-fwhole-program' on a specific symbol. 37919 37920 The whole program mode assumptions are slightly more complex in C++, 37921 where inline functions in headers are put into _COMDAT_ sections. 37922 COMDAT function and variables can be defined by multiple object files 37923 and their bodies are unified at link-time and dynamic link-time. 37924 COMDAT functions are changed to local only when their address is not 37925 taken and thus un-sharing them with a library is not harmful. COMDAT 37926 variables always remain externally visible, however for readonly 37927 variables it is assumed that their initializers cannot be overwritten 37928 by a different value. 37929 37930 GCC provides the function and variable attribute `visibility' that can 37931 be used to specify the visibility of externally visible symbols (or 37932 alternatively an `-fdefault-visibility' command line option). ELF 37933 defines the `default', `protected', `hidden' and `internal' 37934 visibilities. 37935 37936 The most commonly used is visibility is `hidden'. It specifies that 37937 the symbol cannot be referenced from outside of the current shared 37938 library. Unfortunately, this information cannot be used directly by 37939 the link-time optimization in the compiler since the whole shared 37940 library also might contain non-LTO objects and those are not visible to 37941 the compiler. 37942 37943 GCC solves this problem using linker plugins. A _linker plugin_ is an 37944 interface to the linker that allows an external program to claim the 37945 ownership of a given object file. The linker then performs the linking 37946 procedure by querying the plugin about the symbol table of the claimed 37947 objects and once the linking decisions are complete, the plugin is 37948 allowed to provide the final object file before the actual linking is 37949 made. The linker plugin obtains the symbol resolution information 37950 which specifies which symbols provided by the claimed objects are bound 37951 from the rest of a binary being linked. 37952 37953 Currently, the linker plugin works only in combination with the Gold 37954 linker, but a GNU ld implementation is under development. 37955 37956 GCC is designed to be independent of the rest of the toolchain and 37957 aims to support linkers without plugin support. For this reason it 37958 does not use the linker plugin by default. Instead, the object files 37959 are examined by `collect2' before being passed to the linker and 37960 objects found to have LTO sections are passed to `lto1' first. This 37961 mode does not work for library archives. The decision on what object 37962 files from the archive are needed depends on the actual linking and 37963 thus GCC would have to implement the linker itself. The resolution 37964 information is missing too and thus GCC needs to make an educated guess 37965 based on `-fwhole-program'. Without the linker plugin GCC also assumes 37966 that symbols are declared `hidden' and not referred by non-LTO code by 37967 default. 37968 37969 24.5 Internal flags controlling `lto1' 37970 ====================================== 37971 37972 The following flags are passed into `lto1' and are not meant to be used 37973 directly from the command line. 37974 37975 * -fwpa This option runs the serial part of the link-time optimizer 37976 performing the inter-procedural propagation (WPA mode). The 37977 compiler reads in summary information from all inputs and performs 37978 an analysis based on summary information only. It generates 37979 object files for subsequent runs of the link-time optimizer where 37980 individual object files are optimized using both summary 37981 information from the WPA mode and the actual function bodies. It 37982 then drives the LTRANS phase. 37983 37984 * -fltrans This option runs the link-time optimizer in the 37985 local-transformation (LTRANS) mode, which reads in output from a 37986 previous run of the LTO in WPA mode. In the LTRANS mode, LTO 37987 optimizes an object and produces the final assembly. 37988 37989 * -fltrans-output-list=FILE This option specifies a file to which 37990 the names of LTRANS output files are written. This option is only 37991 meaningful in conjunction with `-fwpa'. 37992 37993 37994 File: gccint.info, Node: Funding, Next: GNU Project, Prev: LTO, Up: Top 37995 37996 Funding Free Software 37997 ********************* 37998 37999 If you want to have more free software a few years from now, it makes 38000 sense for you to help encourage people to contribute funds for its 38001 development. The most effective approach known is to encourage 38002 commercial redistributors to donate. 38003 38004 Users of free software systems can boost the pace of development by 38005 encouraging for-a-fee distributors to donate part of their selling price 38006 to free software developers--the Free Software Foundation, and others. 38007 38008 The way to convince distributors to do this is to demand it and expect 38009 it from them. So when you compare distributors, judge them partly by 38010 how much they give to free software development. Show distributors 38011 they must compete to be the one who gives the most. 38012 38013 To make this approach work, you must insist on numbers that you can 38014 compare, such as, "We will donate ten dollars to the Frobnitz project 38015 for each disk sold." Don't be satisfied with a vague promise, such as 38016 "A portion of the profits are donated," since it doesn't give a basis 38017 for comparison. 38018 38019 Even a precise fraction "of the profits from this disk" is not very 38020 meaningful, since creative accounting and unrelated business decisions 38021 can greatly alter what fraction of the sales price counts as profit. 38022 If the price you pay is $50, ten percent of the profit is probably less 38023 than a dollar; it might be a few cents, or nothing at all. 38024 38025 Some redistributors do development work themselves. This is useful 38026 too; but to keep everyone honest, you need to inquire how much they do, 38027 and what kind. Some kinds of development make much more long-term 38028 difference than others. For example, maintaining a separate version of 38029 a program contributes very little; maintaining the standard version of a 38030 program for the whole community contributes much. Easy new ports 38031 contribute little, since someone else would surely do them; difficult 38032 ports such as adding a new CPU to the GNU Compiler Collection 38033 contribute more; major new features or packages contribute the most. 38034 38035 By establishing the idea that supporting further development is "the 38036 proper thing to do" when distributing free software for a fee, we can 38037 assure a steady flow of resources into making more free software. 38038 38039 Copyright (C) 1994 Free Software Foundation, Inc. 38040 Verbatim copying and redistribution of this section is permitted 38041 without royalty; alteration is not permitted. 38042 38043 38044 File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 38045 38046 The GNU Project and GNU/Linux 38047 ***************************** 38048 38049 The GNU Project was launched in 1984 to develop a complete Unix-like 38050 operating system which is free software: the GNU system. (GNU is a 38051 recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 38052 Variants of the GNU operating system, which use the kernel Linux, are 38053 now widely used; though these systems are often referred to as "Linux", 38054 they are more accurately called GNU/Linux systems. 38055 38056 For more information, see: 38057 `http://www.gnu.org/' 38058 `http://www.gnu.org/gnu/linux-and-gnu.html' 38059 38060 38061 File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 38062 38063 GNU General Public License 38064 ************************** 38065 38066 Version 3, 29 June 2007 38067 38068 Copyright (C) 2007 Free Software Foundation, Inc. `http://fsf.org/' 38069 38070 Everyone is permitted to copy and distribute verbatim copies of this 38071 license document, but changing it is not allowed. 38072 38073 Preamble 38074 ======== 38075 38076 The GNU General Public License is a free, copyleft license for software 38077 and other kinds of works. 38078 38079 The licenses for most software and other practical works are designed 38080 to take away your freedom to share and change the works. By contrast, 38081 the GNU General Public License is intended to guarantee your freedom to 38082 share and change all versions of a program-to make sure it remains free 38083 software for all its users. We, the Free Software Foundation, use the 38084 GNU General Public License for most of our software; it applies also to 38085 any other work released this way by its authors. You can apply it to 38086 your programs, too. 38087 38088 When we speak of free software, we are referring to freedom, not 38089 price. Our General Public Licenses are designed to make sure that you 38090 have the freedom to distribute copies of free software (and charge for 38091 them if you wish), that you receive source code or can get it if you 38092 want it, that you can change the software or use pieces of it in new 38093 free programs, and that you know you can do these things. 38094 38095 To protect your rights, we need to prevent others from denying you 38096 these rights or asking you to surrender the rights. Therefore, you 38097 have certain responsibilities if you distribute copies of the software, 38098 or if you modify it: responsibilities to respect the freedom of others. 38099 38100 For example, if you distribute copies of such a program, whether 38101 gratis or for a fee, you must pass on to the recipients the same 38102 freedoms that you received. You must make sure that they, too, receive 38103 or can get the source code. And you must show them these terms so they 38104 know their rights. 38105 38106 Developers that use the GNU GPL protect your rights with two steps: 38107 (1) assert copyright on the software, and (2) offer you this License 38108 giving you legal permission to copy, distribute and/or modify it. 38109 38110 For the developers' and authors' protection, the GPL clearly explains 38111 that there is no warranty for this free software. For both users' and 38112 authors' sake, the GPL requires that modified versions be marked as 38113 changed, so that their problems will not be attributed erroneously to 38114 authors of previous versions. 38115 38116 Some devices are designed to deny users access to install or run 38117 modified versions of the software inside them, although the 38118 manufacturer can do so. This is fundamentally incompatible with the 38119 aim of protecting users' freedom to change the software. The 38120 systematic pattern of such abuse occurs in the area of products for 38121 individuals to use, which is precisely where it is most unacceptable. 38122 Therefore, we have designed this version of the GPL to prohibit the 38123 practice for those products. If such problems arise substantially in 38124 other domains, we stand ready to extend this provision to those domains 38125 in future versions of the GPL, as needed to protect the freedom of 38126 users. 38127 38128 Finally, every program is threatened constantly by software patents. 38129 States should not allow patents to restrict development and use of 38130 software on general-purpose computers, but in those that do, we wish to 38131 avoid the special danger that patents applied to a free program could 38132 make it effectively proprietary. To prevent this, the GPL assures that 38133 patents cannot be used to render the program non-free. 38134 38135 The precise terms and conditions for copying, distribution and 38136 modification follow. 38137 38138 TERMS AND CONDITIONS 38139 ==================== 38140 38141 0. Definitions. 38142 38143 "This License" refers to version 3 of the GNU General Public 38144 License. 38145 38146 "Copyright" also means copyright-like laws that apply to other 38147 kinds of works, such as semiconductor masks. 38148 38149 "The Program" refers to any copyrightable work licensed under this 38150 License. Each licensee is addressed as "you". "Licensees" and 38151 "recipients" may be individuals or organizations. 38152 38153 To "modify" a work means to copy from or adapt all or part of the 38154 work in a fashion requiring copyright permission, other than the 38155 making of an exact copy. The resulting work is called a "modified 38156 version" of the earlier work or a work "based on" the earlier work. 38157 38158 A "covered work" means either the unmodified Program or a work 38159 based on the Program. 38160 38161 To "propagate" a work means to do anything with it that, without 38162 permission, would make you directly or secondarily liable for 38163 infringement under applicable copyright law, except executing it 38164 on a computer or modifying a private copy. Propagation includes 38165 copying, distribution (with or without modification), making 38166 available to the public, and in some countries other activities as 38167 well. 38168 38169 To "convey" a work means any kind of propagation that enables other 38170 parties to make or receive copies. Mere interaction with a user 38171 through a computer network, with no transfer of a copy, is not 38172 conveying. 38173 38174 An interactive user interface displays "Appropriate Legal Notices" 38175 to the extent that it includes a convenient and prominently visible 38176 feature that (1) displays an appropriate copyright notice, and (2) 38177 tells the user that there is no warranty for the work (except to 38178 the extent that warranties are provided), that licensees may 38179 convey the work under this License, and how to view a copy of this 38180 License. If the interface presents a list of user commands or 38181 options, such as a menu, a prominent item in the list meets this 38182 criterion. 38183 38184 1. Source Code. 38185 38186 The "source code" for a work means the preferred form of the work 38187 for making modifications to it. "Object code" means any 38188 non-source form of a work. 38189 38190 A "Standard Interface" means an interface that either is an 38191 official standard defined by a recognized standards body, or, in 38192 the case of interfaces specified for a particular programming 38193 language, one that is widely used among developers working in that 38194 language. 38195 38196 The "System Libraries" of an executable work include anything, 38197 other than the work as a whole, that (a) is included in the normal 38198 form of packaging a Major Component, but which is not part of that 38199 Major Component, and (b) serves only to enable use of the work 38200 with that Major Component, or to implement a Standard Interface 38201 for which an implementation is available to the public in source 38202 code form. A "Major Component", in this context, means a major 38203 essential component (kernel, window system, and so on) of the 38204 specific operating system (if any) on which the executable work 38205 runs, or a compiler used to produce the work, or an object code 38206 interpreter used to run it. 38207 38208 The "Corresponding Source" for a work in object code form means all 38209 the source code needed to generate, install, and (for an executable 38210 work) run the object code and to modify the work, including 38211 scripts to control those activities. However, it does not include 38212 the work's System Libraries, or general-purpose tools or generally 38213 available free programs which are used unmodified in performing 38214 those activities but which are not part of the work. For example, 38215 Corresponding Source includes interface definition files 38216 associated with source files for the work, and the source code for 38217 shared libraries and dynamically linked subprograms that the work 38218 is specifically designed to require, such as by intimate data 38219 communication or control flow between those subprograms and other 38220 parts of the work. 38221 38222 The Corresponding Source need not include anything that users can 38223 regenerate automatically from other parts of the Corresponding 38224 Source. 38225 38226 The Corresponding Source for a work in source code form is that 38227 same work. 38228 38229 2. Basic Permissions. 38230 38231 All rights granted under this License are granted for the term of 38232 copyright on the Program, and are irrevocable provided the stated 38233 conditions are met. This License explicitly affirms your unlimited 38234 permission to run the unmodified Program. The output from running 38235 a covered work is covered by this License only if the output, 38236 given its content, constitutes a covered work. This License 38237 acknowledges your rights of fair use or other equivalent, as 38238 provided by copyright law. 38239 38240 You may make, run and propagate covered works that you do not 38241 convey, without conditions so long as your license otherwise 38242 remains in force. You may convey covered works to others for the 38243 sole purpose of having them make modifications exclusively for 38244 you, or provide you with facilities for running those works, 38245 provided that you comply with the terms of this License in 38246 conveying all material for which you do not control copyright. 38247 Those thus making or running the covered works for you must do so 38248 exclusively on your behalf, under your direction and control, on 38249 terms that prohibit them from making any copies of your 38250 copyrighted material outside their relationship with you. 38251 38252 Conveying under any other circumstances is permitted solely under 38253 the conditions stated below. Sublicensing is not allowed; section 38254 10 makes it unnecessary. 38255 38256 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 38257 38258 No covered work shall be deemed part of an effective technological 38259 measure under any applicable law fulfilling obligations under 38260 article 11 of the WIPO copyright treaty adopted on 20 December 38261 1996, or similar laws prohibiting or restricting circumvention of 38262 such measures. 38263 38264 When you convey a covered work, you waive any legal power to forbid 38265 circumvention of technological measures to the extent such 38266 circumvention is effected by exercising rights under this License 38267 with respect to the covered work, and you disclaim any intention 38268 to limit operation or modification of the work as a means of 38269 enforcing, against the work's users, your or third parties' legal 38270 rights to forbid circumvention of technological measures. 38271 38272 4. Conveying Verbatim Copies. 38273 38274 You may convey verbatim copies of the Program's source code as you 38275 receive it, in any medium, provided that you conspicuously and 38276 appropriately publish on each copy an appropriate copyright notice; 38277 keep intact all notices stating that this License and any 38278 non-permissive terms added in accord with section 7 apply to the 38279 code; keep intact all notices of the absence of any warranty; and 38280 give all recipients a copy of this License along with the Program. 38281 38282 You may charge any price or no price for each copy that you convey, 38283 and you may offer support or warranty protection for a fee. 38284 38285 5. Conveying Modified Source Versions. 38286 38287 You may convey a work based on the Program, or the modifications to 38288 produce it from the Program, in the form of source code under the 38289 terms of section 4, provided that you also meet all of these 38290 conditions: 38291 38292 a. The work must carry prominent notices stating that you 38293 modified it, and giving a relevant date. 38294 38295 b. The work must carry prominent notices stating that it is 38296 released under this License and any conditions added under 38297 section 7. This requirement modifies the requirement in 38298 section 4 to "keep intact all notices". 38299 38300 c. You must license the entire work, as a whole, under this 38301 License to anyone who comes into possession of a copy. This 38302 License will therefore apply, along with any applicable 38303 section 7 additional terms, to the whole of the work, and all 38304 its parts, regardless of how they are packaged. This License 38305 gives no permission to license the work in any other way, but 38306 it does not invalidate such permission if you have separately 38307 received it. 38308 38309 d. If the work has interactive user interfaces, each must display 38310 Appropriate Legal Notices; however, if the Program has 38311 interactive interfaces that do not display Appropriate Legal 38312 Notices, your work need not make them do so. 38313 38314 A compilation of a covered work with other separate and independent 38315 works, which are not by their nature extensions of the covered 38316 work, and which are not combined with it such as to form a larger 38317 program, in or on a volume of a storage or distribution medium, is 38318 called an "aggregate" if the compilation and its resulting 38319 copyright are not used to limit the access or legal rights of the 38320 compilation's users beyond what the individual works permit. 38321 Inclusion of a covered work in an aggregate does not cause this 38322 License to apply to the other parts of the aggregate. 38323 38324 6. Conveying Non-Source Forms. 38325 38326 You may convey a covered work in object code form under the terms 38327 of sections 4 and 5, provided that you also convey the 38328 machine-readable Corresponding Source under the terms of this 38329 License, in one of these ways: 38330 38331 a. Convey the object code in, or embodied in, a physical product 38332 (including a physical distribution medium), accompanied by the 38333 Corresponding Source fixed on a durable physical medium 38334 customarily used for software interchange. 38335 38336 b. Convey the object code in, or embodied in, a physical product 38337 (including a physical distribution medium), accompanied by a 38338 written offer, valid for at least three years and valid for 38339 as long as you offer spare parts or customer support for that 38340 product model, to give anyone who possesses the object code 38341 either (1) a copy of the Corresponding Source for all the 38342 software in the product that is covered by this License, on a 38343 durable physical medium customarily used for software 38344 interchange, for a price no more than your reasonable cost of 38345 physically performing this conveying of source, or (2) access 38346 to copy the Corresponding Source from a network server at no 38347 charge. 38348 38349 c. Convey individual copies of the object code with a copy of 38350 the written offer to provide the Corresponding Source. This 38351 alternative is allowed only occasionally and noncommercially, 38352 and only if you received the object code with such an offer, 38353 in accord with subsection 6b. 38354 38355 d. Convey the object code by offering access from a designated 38356 place (gratis or for a charge), and offer equivalent access 38357 to the Corresponding Source in the same way through the same 38358 place at no further charge. You need not require recipients 38359 to copy the Corresponding Source along with the object code. 38360 If the place to copy the object code is a network server, the 38361 Corresponding Source may be on a different server (operated 38362 by you or a third party) that supports equivalent copying 38363 facilities, provided you maintain clear directions next to 38364 the object code saying where to find the Corresponding Source. 38365 Regardless of what server hosts the Corresponding Source, you 38366 remain obligated to ensure that it is available for as long 38367 as needed to satisfy these requirements. 38368 38369 e. Convey the object code using peer-to-peer transmission, 38370 provided you inform other peers where the object code and 38371 Corresponding Source of the work are being offered to the 38372 general public at no charge under subsection 6d. 38373 38374 38375 A separable portion of the object code, whose source code is 38376 excluded from the Corresponding Source as a System Library, need 38377 not be included in conveying the object code work. 38378 38379 A "User Product" is either (1) a "consumer product", which means 38380 any tangible personal property which is normally used for personal, 38381 family, or household purposes, or (2) anything designed or sold for 38382 incorporation into a dwelling. In determining whether a product 38383 is a consumer product, doubtful cases shall be resolved in favor of 38384 coverage. For a particular product received by a particular user, 38385 "normally used" refers to a typical or common use of that class of 38386 product, regardless of the status of the particular user or of the 38387 way in which the particular user actually uses, or expects or is 38388 expected to use, the product. A product is a consumer product 38389 regardless of whether the product has substantial commercial, 38390 industrial or non-consumer uses, unless such uses represent the 38391 only significant mode of use of the product. 38392 38393 "Installation Information" for a User Product means any methods, 38394 procedures, authorization keys, or other information required to 38395 install and execute modified versions of a covered work in that 38396 User Product from a modified version of its Corresponding Source. 38397 The information must suffice to ensure that the continued 38398 functioning of the modified object code is in no case prevented or 38399 interfered with solely because modification has been made. 38400 38401 If you convey an object code work under this section in, or with, 38402 or specifically for use in, a User Product, and the conveying 38403 occurs as part of a transaction in which the right of possession 38404 and use of the User Product is transferred to the recipient in 38405 perpetuity or for a fixed term (regardless of how the transaction 38406 is characterized), the Corresponding Source conveyed under this 38407 section must be accompanied by the Installation Information. But 38408 this requirement does not apply if neither you nor any third party 38409 retains the ability to install modified object code on the User 38410 Product (for example, the work has been installed in ROM). 38411 38412 The requirement to provide Installation Information does not 38413 include a requirement to continue to provide support service, 38414 warranty, or updates for a work that has been modified or 38415 installed by the recipient, or for the User Product in which it 38416 has been modified or installed. Access to a network may be denied 38417 when the modification itself materially and adversely affects the 38418 operation of the network or violates the rules and protocols for 38419 communication across the network. 38420 38421 Corresponding Source conveyed, and Installation Information 38422 provided, in accord with this section must be in a format that is 38423 publicly documented (and with an implementation available to the 38424 public in source code form), and must require no special password 38425 or key for unpacking, reading or copying. 38426 38427 7. Additional Terms. 38428 38429 "Additional permissions" are terms that supplement the terms of 38430 this License by making exceptions from one or more of its 38431 conditions. Additional permissions that are applicable to the 38432 entire Program shall be treated as though they were included in 38433 this License, to the extent that they are valid under applicable 38434 law. If additional permissions apply only to part of the Program, 38435 that part may be used separately under those permissions, but the 38436 entire Program remains governed by this License without regard to 38437 the additional permissions. 38438 38439 When you convey a copy of a covered work, you may at your option 38440 remove any additional permissions from that copy, or from any part 38441 of it. (Additional permissions may be written to require their own 38442 removal in certain cases when you modify the work.) You may place 38443 additional permissions on material, added by you to a covered work, 38444 for which you have or can give appropriate copyright permission. 38445 38446 Notwithstanding any other provision of this License, for material 38447 you add to a covered work, you may (if authorized by the copyright 38448 holders of that material) supplement the terms of this License 38449 with terms: 38450 38451 a. Disclaiming warranty or limiting liability differently from 38452 the terms of sections 15 and 16 of this License; or 38453 38454 b. Requiring preservation of specified reasonable legal notices 38455 or author attributions in that material or in the Appropriate 38456 Legal Notices displayed by works containing it; or 38457 38458 c. Prohibiting misrepresentation of the origin of that material, 38459 or requiring that modified versions of such material be 38460 marked in reasonable ways as different from the original 38461 version; or 38462 38463 d. Limiting the use for publicity purposes of names of licensors 38464 or authors of the material; or 38465 38466 e. Declining to grant rights under trademark law for use of some 38467 trade names, trademarks, or service marks; or 38468 38469 f. Requiring indemnification of licensors and authors of that 38470 material by anyone who conveys the material (or modified 38471 versions of it) with contractual assumptions of liability to 38472 the recipient, for any liability that these contractual 38473 assumptions directly impose on those licensors and authors. 38474 38475 All other non-permissive additional terms are considered "further 38476 restrictions" within the meaning of section 10. If the Program as 38477 you received it, or any part of it, contains a notice stating that 38478 it is governed by this License along with a term that is a further 38479 restriction, you may remove that term. If a license document 38480 contains a further restriction but permits relicensing or 38481 conveying under this License, you may add to a covered work 38482 material governed by the terms of that license document, provided 38483 that the further restriction does not survive such relicensing or 38484 conveying. 38485 38486 If you add terms to a covered work in accord with this section, you 38487 must place, in the relevant source files, a statement of the 38488 additional terms that apply to those files, or a notice indicating 38489 where to find the applicable terms. 38490 38491 Additional terms, permissive or non-permissive, may be stated in 38492 the form of a separately written license, or stated as exceptions; 38493 the above requirements apply either way. 38494 38495 8. Termination. 38496 38497 You may not propagate or modify a covered work except as expressly 38498 provided under this License. Any attempt otherwise to propagate or 38499 modify it is void, and will automatically terminate your rights 38500 under this License (including any patent licenses granted under 38501 the third paragraph of section 11). 38502 38503 However, if you cease all violation of this License, then your 38504 license from a particular copyright holder is reinstated (a) 38505 provisionally, unless and until the copyright holder explicitly 38506 and finally terminates your license, and (b) permanently, if the 38507 copyright holder fails to notify you of the violation by some 38508 reasonable means prior to 60 days after the cessation. 38509 38510 Moreover, your license from a particular copyright holder is 38511 reinstated permanently if the copyright holder notifies you of the 38512 violation by some reasonable means, this is the first time you have 38513 received notice of violation of this License (for any work) from 38514 that copyright holder, and you cure the violation prior to 30 days 38515 after your receipt of the notice. 38516 38517 Termination of your rights under this section does not terminate 38518 the licenses of parties who have received copies or rights from 38519 you under this License. If your rights have been terminated and 38520 not permanently reinstated, you do not qualify to receive new 38521 licenses for the same material under section 10. 38522 38523 9. Acceptance Not Required for Having Copies. 38524 38525 You are not required to accept this License in order to receive or 38526 run a copy of the Program. Ancillary propagation of a covered work 38527 occurring solely as a consequence of using peer-to-peer 38528 transmission to receive a copy likewise does not require 38529 acceptance. However, nothing other than this License grants you 38530 permission to propagate or modify any covered work. These actions 38531 infringe copyright if you do not accept this License. Therefore, 38532 by modifying or propagating a covered work, you indicate your 38533 acceptance of this License to do so. 38534 38535 10. Automatic Licensing of Downstream Recipients. 38536 38537 Each time you convey a covered work, the recipient automatically 38538 receives a license from the original licensors, to run, modify and 38539 propagate that work, subject to this License. You are not 38540 responsible for enforcing compliance by third parties with this 38541 License. 38542 38543 An "entity transaction" is a transaction transferring control of an 38544 organization, or substantially all assets of one, or subdividing an 38545 organization, or merging organizations. If propagation of a 38546 covered work results from an entity transaction, each party to that 38547 transaction who receives a copy of the work also receives whatever 38548 licenses to the work the party's predecessor in interest had or 38549 could give under the previous paragraph, plus a right to 38550 possession of the Corresponding Source of the work from the 38551 predecessor in interest, if the predecessor has it or can get it 38552 with reasonable efforts. 38553 38554 You may not impose any further restrictions on the exercise of the 38555 rights granted or affirmed under this License. For example, you 38556 may not impose a license fee, royalty, or other charge for 38557 exercise of rights granted under this License, and you may not 38558 initiate litigation (including a cross-claim or counterclaim in a 38559 lawsuit) alleging that any patent claim is infringed by making, 38560 using, selling, offering for sale, or importing the Program or any 38561 portion of it. 38562 38563 11. Patents. 38564 38565 A "contributor" is a copyright holder who authorizes use under this 38566 License of the Program or a work on which the Program is based. 38567 The work thus licensed is called the contributor's "contributor 38568 version". 38569 38570 A contributor's "essential patent claims" are all patent claims 38571 owned or controlled by the contributor, whether already acquired or 38572 hereafter acquired, that would be infringed by some manner, 38573 permitted by this License, of making, using, or selling its 38574 contributor version, but do not include claims that would be 38575 infringed only as a consequence of further modification of the 38576 contributor version. For purposes of this definition, "control" 38577 includes the right to grant patent sublicenses in a manner 38578 consistent with the requirements of this License. 38579 38580 Each contributor grants you a non-exclusive, worldwide, 38581 royalty-free patent license under the contributor's essential 38582 patent claims, to make, use, sell, offer for sale, import and 38583 otherwise run, modify and propagate the contents of its 38584 contributor version. 38585 38586 In the following three paragraphs, a "patent license" is any 38587 express agreement or commitment, however denominated, not to 38588 enforce a patent (such as an express permission to practice a 38589 patent or covenant not to sue for patent infringement). To 38590 "grant" such a patent license to a party means to make such an 38591 agreement or commitment not to enforce a patent against the party. 38592 38593 If you convey a covered work, knowingly relying on a patent 38594 license, and the Corresponding Source of the work is not available 38595 for anyone to copy, free of charge and under the terms of this 38596 License, through a publicly available network server or other 38597 readily accessible means, then you must either (1) cause the 38598 Corresponding Source to be so available, or (2) arrange to deprive 38599 yourself of the benefit of the patent license for this particular 38600 work, or (3) arrange, in a manner consistent with the requirements 38601 of this License, to extend the patent license to downstream 38602 recipients. "Knowingly relying" means you have actual knowledge 38603 that, but for the patent license, your conveying the covered work 38604 in a country, or your recipient's use of the covered work in a 38605 country, would infringe one or more identifiable patents in that 38606 country that you have reason to believe are valid. 38607 38608 If, pursuant to or in connection with a single transaction or 38609 arrangement, you convey, or propagate by procuring conveyance of, a 38610 covered work, and grant a patent license to some of the parties 38611 receiving the covered work authorizing them to use, propagate, 38612 modify or convey a specific copy of the covered work, then the 38613 patent license you grant is automatically extended to all 38614 recipients of the covered work and works based on it. 38615 38616 A patent license is "discriminatory" if it does not include within 38617 the scope of its coverage, prohibits the exercise of, or is 38618 conditioned on the non-exercise of one or more of the rights that 38619 are specifically granted under this License. You may not convey a 38620 covered work if you are a party to an arrangement with a third 38621 party that is in the business of distributing software, under 38622 which you make payment to the third party based on the extent of 38623 your activity of conveying the work, and under which the third 38624 party grants, to any of the parties who would receive the covered 38625 work from you, a discriminatory patent license (a) in connection 38626 with copies of the covered work conveyed by you (or copies made 38627 from those copies), or (b) primarily for and in connection with 38628 specific products or compilations that contain the covered work, 38629 unless you entered into that arrangement, or that patent license 38630 was granted, prior to 28 March 2007. 38631 38632 Nothing in this License shall be construed as excluding or limiting 38633 any implied license or other defenses to infringement that may 38634 otherwise be available to you under applicable patent law. 38635 38636 12. No Surrender of Others' Freedom. 38637 38638 If conditions are imposed on you (whether by court order, 38639 agreement or otherwise) that contradict the conditions of this 38640 License, they do not excuse you from the conditions of this 38641 License. If you cannot convey a covered work so as to satisfy 38642 simultaneously your obligations under this License and any other 38643 pertinent obligations, then as a consequence you may not convey it 38644 at all. For example, if you agree to terms that obligate you to 38645 collect a royalty for further conveying from those to whom you 38646 convey the Program, the only way you could satisfy both those 38647 terms and this License would be to refrain entirely from conveying 38648 the Program. 38649 38650 13. Use with the GNU Affero General Public License. 38651 38652 Notwithstanding any other provision of this License, you have 38653 permission to link or combine any covered work with a work licensed 38654 under version 3 of the GNU Affero General Public License into a 38655 single combined work, and to convey the resulting work. The terms 38656 of this License will continue to apply to the part which is the 38657 covered work, but the special requirements of the GNU Affero 38658 General Public License, section 13, concerning interaction through 38659 a network will apply to the combination as such. 38660 38661 14. Revised Versions of this License. 38662 38663 The Free Software Foundation may publish revised and/or new 38664 versions of the GNU General Public License from time to time. 38665 Such new versions will be similar in spirit to the present 38666 version, but may differ in detail to address new problems or 38667 concerns. 38668 38669 Each version is given a distinguishing version number. If the 38670 Program specifies that a certain numbered version of the GNU 38671 General Public License "or any later version" applies to it, you 38672 have the option of following the terms and conditions either of 38673 that numbered version or of any later version published by the 38674 Free Software Foundation. If the Program does not specify a 38675 version number of the GNU General Public License, you may choose 38676 any version ever published by the Free Software Foundation. 38677 38678 If the Program specifies that a proxy can decide which future 38679 versions of the GNU General Public License can be used, that 38680 proxy's public statement of acceptance of a version permanently 38681 authorizes you to choose that version for the Program. 38682 38683 Later license versions may give you additional or different 38684 permissions. However, no additional obligations are imposed on any 38685 author or copyright holder as a result of your choosing to follow a 38686 later version. 38687 38688 15. Disclaimer of Warranty. 38689 38690 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 38691 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 38692 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 38693 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 38694 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 38695 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 38696 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 38697 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 38698 NECESSARY SERVICING, REPAIR OR CORRECTION. 38699 38700 16. Limitation of Liability. 38701 38702 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 38703 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 38704 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU 38705 FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 38706 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 38707 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 38708 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 38709 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 38710 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 38711 THE POSSIBILITY OF SUCH DAMAGES. 38712 38713 17. Interpretation of Sections 15 and 16. 38714 38715 If the disclaimer of warranty and limitation of liability provided 38716 above cannot be given local legal effect according to their terms, 38717 reviewing courts shall apply local law that most closely 38718 approximates an absolute waiver of all civil liability in 38719 connection with the Program, unless a warranty or assumption of 38720 liability accompanies a copy of the Program in return for a fee. 38721 38722 38723 END OF TERMS AND CONDITIONS 38724 =========================== 38725 38726 How to Apply These Terms to Your New Programs 38727 ============================================= 38728 38729 If you develop a new program, and you want it to be of the greatest 38730 possible use to the public, the best way to achieve this is to make it 38731 free software which everyone can redistribute and change under these 38732 terms. 38733 38734 To do so, attach the following notices to the program. It is safest 38735 to attach them to the start of each source file to most effectively 38736 state the exclusion of warranty; and each file should have at least the 38737 "copyright" line and a pointer to where the full notice is found. 38738 38739 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 38740 Copyright (C) YEAR NAME OF AUTHOR 38741 38742 This program is free software: you can redistribute it and/or modify 38743 it under the terms of the GNU General Public License as published by 38744 the Free Software Foundation, either version 3 of the License, or (at 38745 your option) any later version. 38746 38747 This program is distributed in the hope that it will be useful, but 38748 WITHOUT ANY WARRANTY; without even the implied warranty of 38749 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 38750 General Public License for more details. 38751 38752 You should have received a copy of the GNU General Public License 38753 along with this program. If not, see `http://www.gnu.org/licenses/'. 38754 38755 Also add information on how to contact you by electronic and paper 38756 mail. 38757 38758 If the program does terminal interaction, make it output a short 38759 notice like this when it starts in an interactive mode: 38760 38761 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 38762 This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. 38763 This is free software, and you are welcome to redistribute it 38764 under certain conditions; type `show c' for details. 38765 38766 The hypothetical commands `show w' and `show c' should show the 38767 appropriate parts of the General Public License. Of course, your 38768 program's commands might be different; for a GUI interface, you would 38769 use an "about box". 38770 38771 You should also get your employer (if you work as a programmer) or 38772 school, if any, to sign a "copyright disclaimer" for the program, if 38773 necessary. For more information on this, and how to apply and follow 38774 the GNU GPL, see `http://www.gnu.org/licenses/'. 38775 38776 The GNU General Public License does not permit incorporating your 38777 program into proprietary programs. If your program is a subroutine 38778 library, you may consider it more useful to permit linking proprietary 38779 applications with the library. If this is what you want to do, use the 38780 GNU Lesser General Public License instead of this License. But first, 38781 please read `http://www.gnu.org/philosophy/why-not-lgpl.html'. 38782 38783 38784 File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 38785 38786 GNU Free Documentation License 38787 ****************************** 38788 38789 Version 1.3, 3 November 2008 38790 38791 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 38792 `http://fsf.org/' 38793 38794 Everyone is permitted to copy and distribute verbatim copies 38795 of this license document, but changing it is not allowed. 38796 38797 0. PREAMBLE 38798 38799 The purpose of this License is to make a manual, textbook, or other 38800 functional and useful document "free" in the sense of freedom: to 38801 assure everyone the effective freedom to copy and redistribute it, 38802 with or without modifying it, either commercially or 38803 noncommercially. Secondarily, this License preserves for the 38804 author and publisher a way to get credit for their work, while not 38805 being considered responsible for modifications made by others. 38806 38807 This License is a kind of "copyleft", which means that derivative 38808 works of the document must themselves be free in the same sense. 38809 It complements the GNU General Public License, which is a copyleft 38810 license designed for free software. 38811 38812 We have designed this License in order to use it for manuals for 38813 free software, because free software needs free documentation: a 38814 free program should come with manuals providing the same freedoms 38815 that the software does. But this License is not limited to 38816 software manuals; it can be used for any textual work, regardless 38817 of subject matter or whether it is published as a printed book. 38818 We recommend this License principally for works whose purpose is 38819 instruction or reference. 38820 38821 1. APPLICABILITY AND DEFINITIONS 38822 38823 This License applies to any manual or other work, in any medium, 38824 that contains a notice placed by the copyright holder saying it 38825 can be distributed under the terms of this License. Such a notice 38826 grants a world-wide, royalty-free license, unlimited in duration, 38827 to use that work under the conditions stated herein. The 38828 "Document", below, refers to any such manual or work. Any member 38829 of the public is a licensee, and is addressed as "you". You 38830 accept the license if you copy, modify or distribute the work in a 38831 way requiring permission under copyright law. 38832 38833 A "Modified Version" of the Document means any work containing the 38834 Document or a portion of it, either copied verbatim, or with 38835 modifications and/or translated into another language. 38836 38837 A "Secondary Section" is a named appendix or a front-matter section 38838 of the Document that deals exclusively with the relationship of the 38839 publishers or authors of the Document to the Document's overall 38840 subject (or to related matters) and contains nothing that could 38841 fall directly within that overall subject. (Thus, if the Document 38842 is in part a textbook of mathematics, a Secondary Section may not 38843 explain any mathematics.) The relationship could be a matter of 38844 historical connection with the subject or with related matters, or 38845 of legal, commercial, philosophical, ethical or political position 38846 regarding them. 38847 38848 The "Invariant Sections" are certain Secondary Sections whose 38849 titles are designated, as being those of Invariant Sections, in 38850 the notice that says that the Document is released under this 38851 License. If a section does not fit the above definition of 38852 Secondary then it is not allowed to be designated as Invariant. 38853 The Document may contain zero Invariant Sections. If the Document 38854 does not identify any Invariant Sections then there are none. 38855 38856 The "Cover Texts" are certain short passages of text that are 38857 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 38858 that says that the Document is released under this License. A 38859 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 38860 be at most 25 words. 38861 38862 A "Transparent" copy of the Document means a machine-readable copy, 38863 represented in a format whose specification is available to the 38864 general public, that is suitable for revising the document 38865 straightforwardly with generic text editors or (for images 38866 composed of pixels) generic paint programs or (for drawings) some 38867 widely available drawing editor, and that is suitable for input to 38868 text formatters or for automatic translation to a variety of 38869 formats suitable for input to text formatters. A copy made in an 38870 otherwise Transparent file format whose markup, or absence of 38871 markup, has been arranged to thwart or discourage subsequent 38872 modification by readers is not Transparent. An image format is 38873 not Transparent if used for any substantial amount of text. A 38874 copy that is not "Transparent" is called "Opaque". 38875 38876 Examples of suitable formats for Transparent copies include plain 38877 ASCII without markup, Texinfo input format, LaTeX input format, 38878 SGML or XML using a publicly available DTD, and 38879 standard-conforming simple HTML, PostScript or PDF designed for 38880 human modification. Examples of transparent image formats include 38881 PNG, XCF and JPG. Opaque formats include proprietary formats that 38882 can be read and edited only by proprietary word processors, SGML or 38883 XML for which the DTD and/or processing tools are not generally 38884 available, and the machine-generated HTML, PostScript or PDF 38885 produced by some word processors for output purposes only. 38886 38887 The "Title Page" means, for a printed book, the title page itself, 38888 plus such following pages as are needed to hold, legibly, the 38889 material this License requires to appear in the title page. For 38890 works in formats which do not have any title page as such, "Title 38891 Page" means the text near the most prominent appearance of the 38892 work's title, preceding the beginning of the body of the text. 38893 38894 The "publisher" means any person or entity that distributes copies 38895 of the Document to the public. 38896 38897 A section "Entitled XYZ" means a named subunit of the Document 38898 whose title either is precisely XYZ or contains XYZ in parentheses 38899 following text that translates XYZ in another language. (Here XYZ 38900 stands for a specific section name mentioned below, such as 38901 "Acknowledgements", "Dedications", "Endorsements", or "History".) 38902 To "Preserve the Title" of such a section when you modify the 38903 Document means that it remains a section "Entitled XYZ" according 38904 to this definition. 38905 38906 The Document may include Warranty Disclaimers next to the notice 38907 which states that this License applies to the Document. These 38908 Warranty Disclaimers are considered to be included by reference in 38909 this License, but only as regards disclaiming warranties: any other 38910 implication that these Warranty Disclaimers may have is void and 38911 has no effect on the meaning of this License. 38912 38913 2. VERBATIM COPYING 38914 38915 You may copy and distribute the Document in any medium, either 38916 commercially or noncommercially, provided that this License, the 38917 copyright notices, and the license notice saying this License 38918 applies to the Document are reproduced in all copies, and that you 38919 add no other conditions whatsoever to those of this License. You 38920 may not use technical measures to obstruct or control the reading 38921 or further copying of the copies you make or distribute. However, 38922 you may accept compensation in exchange for copies. If you 38923 distribute a large enough number of copies you must also follow 38924 the conditions in section 3. 38925 38926 You may also lend copies, under the same conditions stated above, 38927 and you may publicly display copies. 38928 38929 3. COPYING IN QUANTITY 38930 38931 If you publish printed copies (or copies in media that commonly 38932 have printed covers) of the Document, numbering more than 100, and 38933 the Document's license notice requires Cover Texts, you must 38934 enclose the copies in covers that carry, clearly and legibly, all 38935 these Cover Texts: Front-Cover Texts on the front cover, and 38936 Back-Cover Texts on the back cover. Both covers must also clearly 38937 and legibly identify you as the publisher of these copies. The 38938 front cover must present the full title with all words of the 38939 title equally prominent and visible. You may add other material 38940 on the covers in addition. Copying with changes limited to the 38941 covers, as long as they preserve the title of the Document and 38942 satisfy these conditions, can be treated as verbatim copying in 38943 other respects. 38944 38945 If the required texts for either cover are too voluminous to fit 38946 legibly, you should put the first ones listed (as many as fit 38947 reasonably) on the actual cover, and continue the rest onto 38948 adjacent pages. 38949 38950 If you publish or distribute Opaque copies of the Document 38951 numbering more than 100, you must either include a 38952 machine-readable Transparent copy along with each Opaque copy, or 38953 state in or with each Opaque copy a computer-network location from 38954 which the general network-using public has access to download 38955 using public-standard network protocols a complete Transparent 38956 copy of the Document, free of added material. If you use the 38957 latter option, you must take reasonably prudent steps, when you 38958 begin distribution of Opaque copies in quantity, to ensure that 38959 this Transparent copy will remain thus accessible at the stated 38960 location until at least one year after the last time you 38961 distribute an Opaque copy (directly or through your agents or 38962 retailers) of that edition to the public. 38963 38964 It is requested, but not required, that you contact the authors of 38965 the Document well before redistributing any large number of 38966 copies, to give them a chance to provide you with an updated 38967 version of the Document. 38968 38969 4. MODIFICATIONS 38970 38971 You may copy and distribute a Modified Version of the Document 38972 under the conditions of sections 2 and 3 above, provided that you 38973 release the Modified Version under precisely this License, with 38974 the Modified Version filling the role of the Document, thus 38975 licensing distribution and modification of the Modified Version to 38976 whoever possesses a copy of it. In addition, you must do these 38977 things in the Modified Version: 38978 38979 A. Use in the Title Page (and on the covers, if any) a title 38980 distinct from that of the Document, and from those of 38981 previous versions (which should, if there were any, be listed 38982 in the History section of the Document). You may use the 38983 same title as a previous version if the original publisher of 38984 that version gives permission. 38985 38986 B. List on the Title Page, as authors, one or more persons or 38987 entities responsible for authorship of the modifications in 38988 the Modified Version, together with at least five of the 38989 principal authors of the Document (all of its principal 38990 authors, if it has fewer than five), unless they release you 38991 from this requirement. 38992 38993 C. State on the Title page the name of the publisher of the 38994 Modified Version, as the publisher. 38995 38996 D. Preserve all the copyright notices of the Document. 38997 38998 E. Add an appropriate copyright notice for your modifications 38999 adjacent to the other copyright notices. 39000 39001 F. Include, immediately after the copyright notices, a license 39002 notice giving the public permission to use the Modified 39003 Version under the terms of this License, in the form shown in 39004 the Addendum below. 39005 39006 G. Preserve in that license notice the full lists of Invariant 39007 Sections and required Cover Texts given in the Document's 39008 license notice. 39009 39010 H. Include an unaltered copy of this License. 39011 39012 I. Preserve the section Entitled "History", Preserve its Title, 39013 and add to it an item stating at least the title, year, new 39014 authors, and publisher of the Modified Version as given on 39015 the Title Page. If there is no section Entitled "History" in 39016 the Document, create one stating the title, year, authors, 39017 and publisher of the Document as given on its Title Page, 39018 then add an item describing the Modified Version as stated in 39019 the previous sentence. 39020 39021 J. Preserve the network location, if any, given in the Document 39022 for public access to a Transparent copy of the Document, and 39023 likewise the network locations given in the Document for 39024 previous versions it was based on. These may be placed in 39025 the "History" section. You may omit a network location for a 39026 work that was published at least four years before the 39027 Document itself, or if the original publisher of the version 39028 it refers to gives permission. 39029 39030 K. For any section Entitled "Acknowledgements" or "Dedications", 39031 Preserve the Title of the section, and preserve in the 39032 section all the substance and tone of each of the contributor 39033 acknowledgements and/or dedications given therein. 39034 39035 L. Preserve all the Invariant Sections of the Document, 39036 unaltered in their text and in their titles. Section numbers 39037 or the equivalent are not considered part of the section 39038 titles. 39039 39040 M. Delete any section Entitled "Endorsements". Such a section 39041 may not be included in the Modified Version. 39042 39043 N. Do not retitle any existing section to be Entitled 39044 "Endorsements" or to conflict in title with any Invariant 39045 Section. 39046 39047 O. Preserve any Warranty Disclaimers. 39048 39049 If the Modified Version includes new front-matter sections or 39050 appendices that qualify as Secondary Sections and contain no 39051 material copied from the Document, you may at your option 39052 designate some or all of these sections as invariant. To do this, 39053 add their titles to the list of Invariant Sections in the Modified 39054 Version's license notice. These titles must be distinct from any 39055 other section titles. 39056 39057 You may add a section Entitled "Endorsements", provided it contains 39058 nothing but endorsements of your Modified Version by various 39059 parties--for example, statements of peer review or that the text 39060 has been approved by an organization as the authoritative 39061 definition of a standard. 39062 39063 You may add a passage of up to five words as a Front-Cover Text, 39064 and a passage of up to 25 words as a Back-Cover Text, to the end 39065 of the list of Cover Texts in the Modified Version. Only one 39066 passage of Front-Cover Text and one of Back-Cover Text may be 39067 added by (or through arrangements made by) any one entity. If the 39068 Document already includes a cover text for the same cover, 39069 previously added by you or by arrangement made by the same entity 39070 you are acting on behalf of, you may not add another; but you may 39071 replace the old one, on explicit permission from the previous 39072 publisher that added the old one. 39073 39074 The author(s) and publisher(s) of the Document do not by this 39075 License give permission to use their names for publicity for or to 39076 assert or imply endorsement of any Modified Version. 39077 39078 5. COMBINING DOCUMENTS 39079 39080 You may combine the Document with other documents released under 39081 this License, under the terms defined in section 4 above for 39082 modified versions, provided that you include in the combination 39083 all of the Invariant Sections of all of the original documents, 39084 unmodified, and list them all as Invariant Sections of your 39085 combined work in its license notice, and that you preserve all 39086 their Warranty Disclaimers. 39087 39088 The combined work need only contain one copy of this License, and 39089 multiple identical Invariant Sections may be replaced with a single 39090 copy. If there are multiple Invariant Sections with the same name 39091 but different contents, make the title of each such section unique 39092 by adding at the end of it, in parentheses, the name of the 39093 original author or publisher of that section if known, or else a 39094 unique number. Make the same adjustment to the section titles in 39095 the list of Invariant Sections in the license notice of the 39096 combined work. 39097 39098 In the combination, you must combine any sections Entitled 39099 "History" in the various original documents, forming one section 39100 Entitled "History"; likewise combine any sections Entitled 39101 "Acknowledgements", and any sections Entitled "Dedications". You 39102 must delete all sections Entitled "Endorsements." 39103 39104 6. COLLECTIONS OF DOCUMENTS 39105 39106 You may make a collection consisting of the Document and other 39107 documents released under this License, and replace the individual 39108 copies of this License in the various documents with a single copy 39109 that is included in the collection, provided that you follow the 39110 rules of this License for verbatim copying of each of the 39111 documents in all other respects. 39112 39113 You may extract a single document from such a collection, and 39114 distribute it individually under this License, provided you insert 39115 a copy of this License into the extracted document, and follow 39116 this License in all other respects regarding verbatim copying of 39117 that document. 39118 39119 7. AGGREGATION WITH INDEPENDENT WORKS 39120 39121 A compilation of the Document or its derivatives with other 39122 separate and independent documents or works, in or on a volume of 39123 a storage or distribution medium, is called an "aggregate" if the 39124 copyright resulting from the compilation is not used to limit the 39125 legal rights of the compilation's users beyond what the individual 39126 works permit. When the Document is included in an aggregate, this 39127 License does not apply to the other works in the aggregate which 39128 are not themselves derivative works of the Document. 39129 39130 If the Cover Text requirement of section 3 is applicable to these 39131 copies of the Document, then if the Document is less than one half 39132 of the entire aggregate, the Document's Cover Texts may be placed 39133 on covers that bracket the Document within the aggregate, or the 39134 electronic equivalent of covers if the Document is in electronic 39135 form. Otherwise they must appear on printed covers that bracket 39136 the whole aggregate. 39137 39138 8. TRANSLATION 39139 39140 Translation is considered a kind of modification, so you may 39141 distribute translations of the Document under the terms of section 39142 4. Replacing Invariant Sections with translations requires special 39143 permission from their copyright holders, but you may include 39144 translations of some or all Invariant Sections in addition to the 39145 original versions of these Invariant Sections. You may include a 39146 translation of this License, and all the license notices in the 39147 Document, and any Warranty Disclaimers, provided that you also 39148 include the original English version of this License and the 39149 original versions of those notices and disclaimers. In case of a 39150 disagreement between the translation and the original version of 39151 this License or a notice or disclaimer, the original version will 39152 prevail. 39153 39154 If a section in the Document is Entitled "Acknowledgements", 39155 "Dedications", or "History", the requirement (section 4) to 39156 Preserve its Title (section 1) will typically require changing the 39157 actual title. 39158 39159 9. TERMINATION 39160 39161 You may not copy, modify, sublicense, or distribute the Document 39162 except as expressly provided under this License. Any attempt 39163 otherwise to copy, modify, sublicense, or distribute it is void, 39164 and will automatically terminate your rights under this License. 39165 39166 However, if you cease all violation of this License, then your 39167 license from a particular copyright holder is reinstated (a) 39168 provisionally, unless and until the copyright holder explicitly 39169 and finally terminates your license, and (b) permanently, if the 39170 copyright holder fails to notify you of the violation by some 39171 reasonable means prior to 60 days after the cessation. 39172 39173 Moreover, your license from a particular copyright holder is 39174 reinstated permanently if the copyright holder notifies you of the 39175 violation by some reasonable means, this is the first time you have 39176 received notice of violation of this License (for any work) from 39177 that copyright holder, and you cure the violation prior to 30 days 39178 after your receipt of the notice. 39179 39180 Termination of your rights under this section does not terminate 39181 the licenses of parties who have received copies or rights from 39182 you under this License. If your rights have been terminated and 39183 not permanently reinstated, receipt of a copy of some or all of 39184 the same material does not give you any rights to use it. 39185 39186 10. FUTURE REVISIONS OF THIS LICENSE 39187 39188 The Free Software Foundation may publish new, revised versions of 39189 the GNU Free Documentation License from time to time. Such new 39190 versions will be similar in spirit to the present version, but may 39191 differ in detail to address new problems or concerns. See 39192 `http://www.gnu.org/copyleft/'. 39193 39194 Each version of the License is given a distinguishing version 39195 number. If the Document specifies that a particular numbered 39196 version of this License "or any later version" applies to it, you 39197 have the option of following the terms and conditions either of 39198 that specified version or of any later version that has been 39199 published (not as a draft) by the Free Software Foundation. If 39200 the Document does not specify a version number of this License, 39201 you may choose any version ever published (not as a draft) by the 39202 Free Software Foundation. If the Document specifies that a proxy 39203 can decide which future versions of this License can be used, that 39204 proxy's public statement of acceptance of a version permanently 39205 authorizes you to choose that version for the Document. 39206 39207 11. RELICENSING 39208 39209 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 39210 World Wide Web server that publishes copyrightable works and also 39211 provides prominent facilities for anybody to edit those works. A 39212 public wiki that anybody can edit is an example of such a server. 39213 A "Massive Multiauthor Collaboration" (or "MMC") contained in the 39214 site means any set of copyrightable works thus published on the MMC 39215 site. 39216 39217 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 39218 license published by Creative Commons Corporation, a not-for-profit 39219 corporation with a principal place of business in San Francisco, 39220 California, as well as future copyleft versions of that license 39221 published by that same organization. 39222 39223 "Incorporate" means to publish or republish a Document, in whole or 39224 in part, as part of another Document. 39225 39226 An MMC is "eligible for relicensing" if it is licensed under this 39227 License, and if all works that were first published under this 39228 License somewhere other than this MMC, and subsequently 39229 incorporated in whole or in part into the MMC, (1) had no cover 39230 texts or invariant sections, and (2) were thus incorporated prior 39231 to November 1, 2008. 39232 39233 The operator of an MMC Site may republish an MMC contained in the 39234 site under CC-BY-SA on the same site at any time before August 1, 39235 2009, provided the MMC is eligible for relicensing. 39236 39237 39238 ADDENDUM: How to use this License for your documents 39239 ==================================================== 39240 39241 To use this License in a document you have written, include a copy of 39242 the License in the document and put the following copyright and license 39243 notices just after the title page: 39244 39245 Copyright (C) YEAR YOUR NAME. 39246 Permission is granted to copy, distribute and/or modify this document 39247 under the terms of the GNU Free Documentation License, Version 1.3 39248 or any later version published by the Free Software Foundation; 39249 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 39250 Texts. A copy of the license is included in the section entitled ``GNU 39251 Free Documentation License''. 39252 39253 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 39254 replace the "with...Texts." line with this: 39255 39256 with the Invariant Sections being LIST THEIR TITLES, with 39257 the Front-Cover Texts being LIST, and with the Back-Cover Texts 39258 being LIST. 39259 39260 If you have Invariant Sections without Cover Texts, or some other 39261 combination of the three, merge those two alternatives to suit the 39262 situation. 39263 39264 If your document contains nontrivial examples of program code, we 39265 recommend releasing these examples in parallel under your choice of 39266 free software license, such as the GNU General Public License, to 39267 permit their use in free software. 39268 39269 39270 File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 39271 39272 Contributors to GCC 39273 ******************* 39274 39275 The GCC project would like to thank its many contributors. Without 39276 them the project would not have been nearly as successful as it has 39277 been. Any omissions in this list are accidental. Feel free to contact 39278 <law (a] redhat.com> or <gerald (a] pfeifer.com> if you have been left out or 39279 some of your contributions are not listed. Please keep this list in 39280 alphabetical order. 39281 39282 * Analog Devices helped implement the support for complex data types 39283 and iterators. 39284 39285 * John David Anglin for threading-related fixes and improvements to 39286 libstdc++-v3, and the HP-UX port. 39287 39288 * James van Artsdalen wrote the code that makes efficient use of the 39289 Intel 80387 register stack. 39290 39291 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 39292 Series port. 39293 39294 * Alasdair Baird for various bug fixes. 39295 39296 * Giovanni Bajo for analyzing lots of complicated C++ problem 39297 reports. 39298 39299 * Peter Barada for his work to improve code generation for new 39300 ColdFire cores. 39301 39302 * Gerald Baumgartner added the signature extension to the C++ front 39303 end. 39304 39305 * Godmar Back for his Java improvements and encouragement. 39306 39307 * Scott Bambrough for help porting the Java compiler. 39308 39309 * Wolfgang Bangerth for processing tons of bug reports. 39310 39311 * Jon Beniston for his Microsoft Windows port of Java and port to 39312 Lattice Mico32. 39313 39314 * Daniel Berlin for better DWARF2 support, faster/better 39315 optimizations, improved alias analysis, plus migrating GCC to 39316 Bugzilla. 39317 39318 * Geoff Berry for his Java object serialization work and various 39319 patches. 39320 39321 * Uros Bizjak for the implementation of x87 math built-in functions 39322 and for various middle end and i386 back end improvements and bug 39323 fixes. 39324 39325 * Eric Blake for helping to make GCJ and libgcj conform to the 39326 specifications. 39327 39328 * Janne Blomqvist for contributions to GNU Fortran. 39329 39330 * Segher Boessenkool for various fixes. 39331 39332 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 39333 other Java work. 39334 39335 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 39336 miscellaneous clean-ups. 39337 39338 * Steven Bosscher for integrating the GNU Fortran front end into GCC 39339 and for contributing to the tree-ssa branch. 39340 39341 * Eric Botcazou for fixing middle- and backend bugs left and right. 39342 39343 * Per Bothner for his direction via the steering committee and 39344 various improvements to the infrastructure for supporting new 39345 languages. Chill front end implementation. Initial 39346 implementations of cpplib, fix-header, config.guess, libio, and 39347 past C++ library (libg++) maintainer. Dreaming up, designing and 39348 implementing much of GCJ. 39349 39350 * Devon Bowen helped port GCC to the Tahoe. 39351 39352 * Don Bowman for mips-vxworks contributions. 39353 39354 * Dave Brolley for work on cpplib and Chill. 39355 39356 * Paul Brook for work on the ARM architecture and maintaining GNU 39357 Fortran. 39358 39359 * Robert Brown implemented the support for Encore 32000 systems. 39360 39361 * Christian Bruel for improvements to local store elimination. 39362 39363 * Herman A.J. ten Brugge for various fixes. 39364 39365 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 39366 FAQ. 39367 39368 * Joe Buck for his direction via the steering committee. 39369 39370 * Craig Burley for leadership of the G77 Fortran effort. 39371 39372 * Stephan Buys for contributing Doxygen notes for libstdc++. 39373 39374 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 39375 to the C++ strings, streambufs and formatted I/O, hard detective 39376 work on the frustrating localization issues, and keeping up with 39377 the problem reports. 39378 39379 * John Carr for his alias work, SPARC hacking, infrastructure 39380 improvements, previous contributions to the steering committee, 39381 loop optimizations, etc. 39382 39383 * Stephane Carrez for 68HC11 and 68HC12 ports. 39384 39385 * Steve Chamberlain for support for the Renesas SH and H8 processors 39386 and the PicoJava processor, and for GCJ config fixes. 39387 39388 * Glenn Chambers for help with the GCJ FAQ. 39389 39390 * John-Marc Chandonia for various libgcj patches. 39391 39392 * Denis Chertykov for contributing and maintaining the AVR port, the 39393 first GCC port for an 8-bit architecture. 39394 39395 * Scott Christley for his Objective-C contributions. 39396 39397 * Eric Christopher for his Java porting help and clean-ups. 39398 39399 * Branko Cibej for more warning contributions. 39400 39401 * The GNU Classpath project for all of their merged runtime code. 39402 39403 * Nick Clifton for arm, mcore, fr30, v850, m32r, rx work, `--help', 39404 and other random hacking. 39405 39406 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 39407 39408 * R. Kelley Cook for making GCC buildable from a read-only directory 39409 as well as other miscellaneous build process and documentation 39410 clean-ups. 39411 39412 * Ralf Corsepius for SH testing and minor bug fixing. 39413 39414 * Stan Cox for care and feeding of the x86 port and lots of behind 39415 the scenes hacking. 39416 39417 * Alex Crain provided changes for the 3b1. 39418 39419 * Ian Dall for major improvements to the NS32k port. 39420 39421 * Paul Dale for his work to add uClinux platform support to the m68k 39422 backend. 39423 39424 * Dario Dariol contributed the four varieties of sample programs 39425 that print a copy of their source. 39426 39427 * Russell Davidson for fstream and stringstream fixes in libstdc++. 39428 39429 * Bud Davis for work on the G77 and GNU Fortran compilers. 39430 39431 * Mo DeJong for GCJ and libgcj bug fixes. 39432 39433 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 39434 various bug fixes, and the M32C and MeP ports. 39435 39436 * Arnaud Desitter for helping to debug GNU Fortran. 39437 39438 * Gabriel Dos Reis for contributions to G++, contributions and 39439 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 39440 including `valarray<>', `complex<>', maintaining the numerics 39441 library (including that pesky `<limits>' :-) and keeping 39442 up-to-date anything to do with numbers. 39443 39444 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 39445 ISO C99 support, CFG dumping support, etc., plus support of the 39446 C++ runtime libraries including for all kinds of C interface 39447 issues, contributing and maintaining `complex<>', sanity checking 39448 and disbursement, configuration architecture, libio maintenance, 39449 and early math work. 39450 39451 * Zdenek Dvorak for a new loop unroller and various fixes. 39452 39453 * Michael Eager for his work on the Xilinx MicroBlaze port. 39454 39455 * Richard Earnshaw for his ongoing work with the ARM. 39456 39457 * David Edelsohn for his direction via the steering committee, 39458 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 39459 loop changes, doing the entire AIX port of libstdc++ with his bare 39460 hands, and for ensuring GCC properly keeps working on AIX. 39461 39462 * Kevin Ediger for the floating point formatting of num_put::do_put 39463 in libstdc++. 39464 39465 * Phil Edwards for libstdc++ work including configuration hackery, 39466 documentation maintainer, chief breaker of the web pages, the 39467 occasional iostream bug fix, and work on shared library symbol 39468 versioning. 39469 39470 * Paul Eggert for random hacking all over GCC. 39471 39472 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 39473 configuration support for locales and fstream-related fixes. 39474 39475 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 39476 iostreams. 39477 39478 * Christian Ehrhardt for dealing with bug reports. 39479 39480 * Ben Elliston for his work to move the Objective-C runtime into its 39481 own subdirectory and for his work on autoconf. 39482 39483 * Revital Eres for work on the PowerPC 750CL port. 39484 39485 * Marc Espie for OpenBSD support. 39486 39487 * Doug Evans for much of the global optimization framework, arc, 39488 m32r, and SPARC work. 39489 39490 * Christopher Faylor for his work on the Cygwin port and for caring 39491 and feeding the gcc.gnu.org box and saving its users tons of spam. 39492 39493 * Fred Fish for BeOS support and Ada fixes. 39494 39495 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 39496 39497 * Peter Gerwinski for various bug fixes and the Pascal front end. 39498 39499 * Kaveh R. Ghazi for his direction via the steering committee, 39500 amazing work to make `-W -Wall -W* -Werror' useful, and 39501 continuously testing GCC on a plethora of platforms. Kaveh 39502 extends his gratitude to the CAIP Center at Rutgers University for 39503 providing him with computing resources to work on Free Software 39504 since the late 1980s. 39505 39506 * John Gilmore for a donation to the FSF earmarked improving GNU 39507 Java. 39508 39509 * Judy Goldberg for c++ contributions. 39510 39511 * Torbjorn Granlund for various fixes and the c-torture testsuite, 39512 multiply- and divide-by-constant optimization, improved long long 39513 support, improved leaf function register allocation, and his 39514 direction via the steering committee. 39515 39516 * Anthony Green for his `-Os' contributions, the moxie port, and 39517 Java front end work. 39518 39519 * Stu Grossman for gdb hacking, allowing GCJ developers to debug 39520 Java code. 39521 39522 * Michael K. Gschwind contributed the port to the PDP-11. 39523 39524 * Richard Guenther for his ongoing middle-end contributions and bug 39525 fixes and for release management. 39526 39527 * Ron Guilmette implemented the `protoize' and `unprotoize' tools, 39528 the support for Dwarf symbolic debugging information, and much of 39529 the support for System V Release 4. He has also worked heavily on 39530 the Intel 386 and 860 support. 39531 39532 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 39533 GCSE. 39534 39535 * Bruno Haible for improvements in the runtime overhead for EH, new 39536 warnings and assorted bug fixes. 39537 39538 * Andrew Haley for his amazing Java compiler and library efforts. 39539 39540 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 39541 series 300. 39542 39543 * Michael Hayes for various thankless work he's done trying to get 39544 the c30/c40 ports functional. Lots of loop and unroll 39545 improvements and fixes. 39546 39547 * Dara Hazeghi for wading through myriads of target-specific bug 39548 reports. 39549 39550 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 39551 39552 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 39553 work, loop opts, and generally fixing lots of old problems we've 39554 ignored for years, flow rewrite and lots of further stuff, 39555 including reviewing tons of patches. 39556 39557 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 39558 various fixes. 39559 39560 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 39561 contributed the support for the Sony NEWS machine. 39562 39563 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 39564 various fixes. 39565 39566 * Katherine Holcomb for work on GNU Fortran. 39567 39568 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 39569 of testing and bug fixing, particularly of GCC configury code. 39570 39571 * Steve Holmgren for MachTen patches. 39572 39573 * Jan Hubicka for his x86 port improvements. 39574 39575 * Falk Hueffner for working on C and optimization bug reports. 39576 39577 * Bernardo Innocenti for his m68k work, including merging of 39578 ColdFire improvements and uClinux support. 39579 39580 * Christian Iseli for various bug fixes. 39581 39582 * Kamil Iskra for general m68k hacking. 39583 39584 * Lee Iverson for random fixes and MIPS testing. 39585 39586 * Andreas Jaeger for testing and benchmarking of GCC and various bug 39587 fixes. 39588 39589 * Jakub Jelinek for his SPARC work and sibling call optimizations as 39590 well as lots of bug fixes and test cases, and for improving the 39591 Java build system. 39592 39593 * Janis Johnson for ia64 testing and fixes, her quality improvement 39594 sidetracks, and web page maintenance. 39595 39596 * Kean Johnston for SCO OpenServer support and various fixes. 39597 39598 * Tim Josling for the sample language treelang based originally on 39599 Richard Kenner's "toy" language. 39600 39601 * Nicolai Josuttis for additional libstdc++ documentation. 39602 39603 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 39604 target. 39605 39606 * Steven G. Kargl for work on GNU Fortran. 39607 39608 * David Kashtan of SRI adapted GCC to VMS. 39609 39610 * Ryszard Kabatek for many, many libstdc++ bug fixes and 39611 optimizations of strings, especially member functions, and for 39612 auto_ptr fixes. 39613 39614 * Geoffrey Keating for his ongoing work to make the PPC work for 39615 GNU/Linux and his automatic regression tester. 39616 39617 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 39618 work in just about every part of libstdc++. 39619 39620 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 39621 MIL-STD-1750A. 39622 39623 * Richard Kenner of the New York University Ultracomputer Research 39624 Laboratory wrote the machine descriptions for the AMD 29000, the 39625 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 39626 support for instruction attributes. He also made changes to 39627 better support RISC processors including changes to common 39628 subexpression elimination, strength reduction, function calling 39629 sequence handling, and condition code support, in addition to 39630 generalizing the code for frame pointer elimination and delay slot 39631 scheduling. Richard Kenner was also the head maintainer of GCC 39632 for several years. 39633 39634 * Mumit Khan for various contributions to the Cygwin and Mingw32 39635 ports and maintaining binary releases for Microsoft Windows hosts, 39636 and for massive libstdc++ porting work to Cygwin/Mingw32. 39637 39638 * Robin Kirkham for cpu32 support. 39639 39640 * Mark Klein for PA improvements. 39641 39642 * Thomas Koenig for various bug fixes. 39643 39644 * Bruce Korb for the new and improved fixincludes code. 39645 39646 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 39647 effort. 39648 39649 * Charles LaBrec contributed the support for the Integrated Solutions 39650 68020 system. 39651 39652 * Asher Langton and Mike Kumbera for contributing Cray pointer 39653 support to GNU Fortran, and for other GNU Fortran improvements. 39654 39655 * Jeff Law for his direction via the steering committee, 39656 coordinating the entire egcs project and GCC 2.95, rolling out 39657 snapshots and releases, handling merges from GCC2, reviewing tons 39658 of patches that might have fallen through the cracks else, and 39659 random but extensive hacking. 39660 39661 * Marc Lehmann for his direction via the steering committee and 39662 helping with analysis and improvements of x86 performance. 39663 39664 * Victor Leikehman for work on GNU Fortran. 39665 39666 * Ted Lemon wrote parts of the RTL reader and printer. 39667 39668 * Kriang Lerdsuwanakij for C++ improvements including template as 39669 template parameter support, and many C++ fixes. 39670 39671 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 39672 and random work on the Java front end. 39673 39674 * Alain Lichnewsky ported GCC to the MIPS CPU. 39675 39676 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 39677 and patches. 39678 39679 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 39680 39681 * Chen Liqin for various S+core related fixes/improvement, and for 39682 maintaining the S+core port. 39683 39684 * Weiwen Liu for testing and various bug fixes. 39685 39686 * Manuel Lo'pez-Iba'n~ez for improving `-Wconversion' and many other 39687 diagnostics fixes and improvements. 39688 39689 * Dave Love for his ongoing work with the Fortran front end and 39690 runtime libraries. 39691 39692 * Martin von Lo"wis for internal consistency checking infrastructure, 39693 various C++ improvements including namespace support, and tons of 39694 assistance with libstdc++/compiler merges. 39695 39696 * H.J. Lu for his previous contributions to the steering committee, 39697 many x86 bug reports, prototype patches, and keeping the GNU/Linux 39698 ports working. 39699 39700 * Greg McGary for random fixes and (someday) bounded pointers. 39701 39702 * Andrew MacLeod for his ongoing work in building a real EH system, 39703 various code generation improvements, work on the global 39704 optimizer, etc. 39705 39706 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 39707 hacking improvements to compile-time performance, overall 39708 knowledge and direction in the area of instruction scheduling, and 39709 design and implementation of the automaton based instruction 39710 scheduler. 39711 39712 * Bob Manson for his behind the scenes work on dejagnu. 39713 39714 * Philip Martin for lots of libstdc++ string and vector iterator 39715 fixes and improvements, and string clean up and testsuites. 39716 39717 * All of the Mauve project contributors, for Java test code. 39718 39719 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 39720 39721 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 39722 39723 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 39724 powerpc, haifa, ECOFF debug support, and other assorted hacking. 39725 39726 * Jason Merrill for his direction via the steering committee and 39727 leading the G++ effort. 39728 39729 * Martin Michlmayr for testing GCC on several architectures using the 39730 entire Debian archive. 39731 39732 * David Miller for his direction via the steering committee, lots of 39733 SPARC work, improvements in jump.c and interfacing with the Linux 39734 kernel developers. 39735 39736 * Gary Miller ported GCC to Charles River Data Systems machines. 39737 39738 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 39739 the entire libstdc++ testsuite namespace-compatible. 39740 39741 * Mark Mitchell for his direction via the steering committee, 39742 mountains of C++ work, load/store hoisting out of loops, alias 39743 analysis improvements, ISO C `restrict' support, and serving as 39744 release manager for GCC 3.x. 39745 39746 * Alan Modra for various GNU/Linux bits and testing. 39747 39748 * Toon Moene for his direction via the steering committee, Fortran 39749 maintenance, and his ongoing work to make us make Fortran run fast. 39750 39751 * Jason Molenda for major help in the care and feeding of all the 39752 services on the gcc.gnu.org (formerly egcs.cygnus.com) 39753 machine--mail, web services, ftp services, etc etc. Doing all 39754 this work on scrap paper and the backs of envelopes would have 39755 been... difficult. 39756 39757 * Catherine Moore for fixing various ugly problems we have sent her 39758 way, including the haifa bug which was killing the Alpha & PowerPC 39759 Linux kernels. 39760 39761 * Mike Moreton for his various Java patches. 39762 39763 * David Mosberger-Tang for various Alpha improvements, and for the 39764 initial IA-64 port. 39765 39766 * Stephen Moshier contributed the floating point emulator that 39767 assists in cross-compilation and permits support for floating 39768 point numbers wider than 64 bits and for ISO C99 support. 39769 39770 * Bill Moyer for his behind the scenes work on various issues. 39771 39772 * Philippe De Muyter for his work on the m68k port. 39773 39774 * Joseph S. Myers for his work on the PDP-11 port, format checking 39775 and ISO C99 support, and continuous emphasis on (and contributions 39776 to) documentation. 39777 39778 * Nathan Myers for his work on libstdc++-v3: architecture and 39779 authorship through the first three snapshots, including 39780 implementation of locale infrastructure, string, shadow C headers, 39781 and the initial project documentation (DESIGN, CHECKLIST, and so 39782 forth). Later, more work on MT-safe string and shadow headers. 39783 39784 * Felix Natter for documentation on porting libstdc++. 39785 39786 * Nathanael Nerode for cleaning up the configuration/build process. 39787 39788 * NeXT, Inc. donated the front end that supports the Objective-C 39789 language. 39790 39791 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to 39792 the search engine setup, various documentation fixes and other 39793 small fixes. 39794 39795 * Geoff Noer for his work on getting cygwin native builds working. 39796 39797 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 39798 tracking web pages, GIMPLE tuples, and assorted fixes. 39799 39800 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 39801 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and 39802 related infrastructure improvements. 39803 39804 * Alexandre Oliva for various build infrastructure improvements, 39805 scripts and amazing testing work, including keeping libtool issues 39806 sane and happy. 39807 39808 * Stefan Olsson for work on mt_alloc. 39809 39810 * Melissa O'Neill for various NeXT fixes. 39811 39812 * Rainer Orth for random MIPS work, including improvements to GCC's 39813 o32 ABI support, improvements to dejagnu's MIPS support, Java 39814 configuration clean-ups and porting work, and maintaining the 39815 IRIX, Solaris 2, and Tru64 UNIX ports. 39816 39817 * Hartmut Penner for work on the s390 port. 39818 39819 * Paul Petersen wrote the machine description for the Alliant FX/8. 39820 39821 * Alexandre Petit-Bianco for implementing much of the Java compiler 39822 and continued Java maintainership. 39823 39824 * Matthias Pfaller for major improvements to the NS32k port. 39825 39826 * Gerald Pfeifer for his direction via the steering committee, 39827 pointing out lots of problems we need to solve, maintenance of the 39828 web pages, and taking care of documentation maintenance in general. 39829 39830 * Andrew Pinski for processing bug reports by the dozen. 39831 39832 * Ovidiu Predescu for his work on the Objective-C front end and 39833 runtime libraries. 39834 39835 * Jerry Quinn for major performance improvements in C++ formatted 39836 I/O. 39837 39838 * Ken Raeburn for various improvements to checker, MIPS ports and 39839 various cleanups in the compiler. 39840 39841 * Rolf W. Rasmussen for hacking on AWT. 39842 39843 * David Reese of Sun Microsystems contributed to the Solaris on 39844 PowerPC port. 39845 39846 * Volker Reichelt for keeping up with the problem reports. 39847 39848 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 39849 hacking. 39850 39851 * Loren J. Rittle for improvements to libstdc++-v3 including the 39852 FreeBSD port, threading fixes, thread-related configury changes, 39853 critical threading documentation, and solutions to really tricky 39854 I/O problems, as well as keeping GCC properly working on FreeBSD 39855 and continuous testing. 39856 39857 * Craig Rodrigues for processing tons of bug reports. 39858 39859 * Ola Ro"nnerup for work on mt_alloc. 39860 39861 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 39862 39863 * David Ronis inspired and encouraged Craig to rewrite the G77 39864 documentation in texinfo format by contributing a first pass at a 39865 translation of the old `g77-0.5.16/f/DOC' file. 39866 39867 * Ken Rose for fixes to GCC's delay slot filling code. 39868 39869 * Paul Rubin wrote most of the preprocessor. 39870 39871 * Pe'tur Runo'lfsson for major performance improvements in C++ 39872 formatted I/O and large file support in C++ filebuf. 39873 39874 * Chip Salzenberg for libstdc++ patches and improvements to locales, 39875 traits, Makefiles, libio, libtool hackery, and "long long" support. 39876 39877 * Juha Sarlin for improvements to the H8 code generator. 39878 39879 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 39880 300. 39881 39882 * Roger Sayle for improvements to constant folding and GCC's RTL 39883 optimizers as well as for fixing numerous bugs. 39884 39885 * Bradley Schatz for his work on the GCJ FAQ. 39886 39887 * Peter Schauer wrote the code to allow debugging to work on the 39888 Alpha. 39889 39890 * William Schelter did most of the work on the Intel 80386 support. 39891 39892 * Tobias Schlu"ter for work on GNU Fortran. 39893 39894 * Bernd Schmidt for various code generation improvements and major 39895 work in the reload pass as well a serving as release manager for 39896 GCC 2.95.3. 39897 39898 * Peter Schmid for constant testing of libstdc++--especially 39899 application testing, going above and beyond what was requested for 39900 the release criteria--and libstdc++ header file tweaks. 39901 39902 * Jason Schroeder for jcf-dump patches. 39903 39904 * Andreas Schwab for his work on the m68k port. 39905 39906 * Lars Segerlund for work on GNU Fortran. 39907 39908 * Dodji Seketeli for numerous C++ bug fixes and debug info 39909 improvements. 39910 39911 * Joel Sherrill for his direction via the steering committee, RTEMS 39912 contributions and RTEMS testing. 39913 39914 * Nathan Sidwell for many C++ fixes/improvements. 39915 39916 * Jeffrey Siegal for helping RMS with the original design of GCC, 39917 some code which handles the parse tree and RTL data structures, 39918 constant folding and help with the original VAX & m68k ports. 39919 39920 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 39921 from the LWG (thereby keeping GCC in line with updates from the 39922 ISO). 39923 39924 * Franz Sirl for his ongoing work with making the PPC port stable 39925 for GNU/Linux. 39926 39927 * Andrey Slepuhin for assorted AIX hacking. 39928 39929 * Trevor Smigiel for contributing the SPU port. 39930 39931 * Christopher Smith did the port for Convex machines. 39932 39933 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 39934 39935 * Randy Smith finished the Sun FPA support. 39936 39937 * Scott Snyder for queue, iterator, istream, and string fixes and 39938 libstdc++ testsuite entries. Also for providing the patch to G77 39939 to add rudimentary support for `INTEGER*1', `INTEGER*2', and 39940 `LOGICAL*1'. 39941 39942 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 39943 39944 * Richard Stallman, for writing the original GCC and launching the 39945 GNU project. 39946 39947 * Jan Stein of the Chalmers Computer Society provided support for 39948 Genix, as well as part of the 32000 machine description. 39949 39950 * Nigel Stephens for various mips16 related fixes/improvements. 39951 39952 * Jonathan Stone wrote the machine description for the Pyramid 39953 computer. 39954 39955 * Graham Stott for various infrastructure improvements. 39956 39957 * John Stracke for his Java HTTP protocol fixes. 39958 39959 * Mike Stump for his Elxsi port, G++ contributions over the years 39960 and more recently his vxworks contributions 39961 39962 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 39963 39964 * Shigeya Suzuki for this fixes for the bsdi platforms. 39965 39966 * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64 39967 support, general configury hacking, fixincludes, etc. 39968 39969 * Holger Teutsch provided the support for the Clipper CPU. 39970 39971 * Gary Thomas for his ongoing work to make the PPC work for 39972 GNU/Linux. 39973 39974 * Philipp Thomas for random bug fixes throughout the compiler 39975 39976 * Jason Thorpe for thread support in libstdc++ on NetBSD. 39977 39978 * Kresten Krab Thorup wrote the run time support for the Objective-C 39979 language and the fantastic Java bytecode interpreter. 39980 39981 * Michael Tiemann for random bug fixes, the first instruction 39982 scheduler, initial C++ support, function integration, NS32k, SPARC 39983 and M88k machine description work, delay slot scheduling. 39984 39985 * Andreas Tobler for his work porting libgcj to Darwin. 39986 39987 * Teemu Torma for thread safe exception handling support. 39988 39989 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 39990 definitions, and of the VAX machine description. 39991 39992 * Daniel Towner and Hariharan Sandanagobalane contributed and 39993 maintain the picoChip port. 39994 39995 * Tom Tromey for internationalization support and for his many Java 39996 contributions and libgcj maintainership. 39997 39998 * Lassi Tuura for improvements to config.guess to determine HP 39999 processor types. 40000 40001 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 40002 40003 * Andy Vaught for the design and initial implementation of the GNU 40004 Fortran front end. 40005 40006 * Brent Verner for work with the libstdc++ cshadow files and their 40007 associated configure steps. 40008 40009 * Todd Vierling for contributions for NetBSD ports. 40010 40011 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 40012 guidance. 40013 40014 * Dean Wakerley for converting the install documentation from HTML 40015 to texinfo in time for GCC 3.0. 40016 40017 * Krister Walfridsson for random bug fixes. 40018 40019 * Feng Wang for contributions to GNU Fortran. 40020 40021 * Stephen M. Webb for time and effort on making libstdc++ shadow 40022 files work with the tricky Solaris 8+ headers, and for pushing the 40023 build-time header tree. 40024 40025 * John Wehle for various improvements for the x86 code generator, 40026 related infrastructure improvements to help x86 code generation, 40027 value range propagation and other work, WE32k port. 40028 40029 * Ulrich Weigand for work on the s390 port. 40030 40031 * Zack Weinberg for major work on cpplib and various other bug fixes. 40032 40033 * Matt Welsh for help with Linux Threads support in GCJ. 40034 40035 * Urban Widmark for help fixing java.io. 40036 40037 * Mark Wielaard for new Java library code and his work integrating 40038 with Classpath. 40039 40040 * Dale Wiles helped port GCC to the Tahoe. 40041 40042 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 40043 40044 * Jim Wilson for his direction via the steering committee, tackling 40045 hard problems in various places that nobody else wanted to work 40046 on, strength reduction and other loop optimizations. 40047 40048 * Paul Woegerer and Tal Agmon for the CRX port. 40049 40050 * Carlo Wood for various fixes. 40051 40052 * Tom Wood for work on the m88k port. 40053 40054 * Canqun Yang for work on GNU Fortran. 40055 40056 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 40057 description for the Tron architecture (specifically, the Gmicro). 40058 40059 * Kevin Zachmann helped port GCC to the Tahoe. 40060 40061 * Ayal Zaks for Swing Modulo Scheduling (SMS). 40062 40063 * Xiaoqiang Zhang for work on GNU Fortran. 40064 40065 * Gilles Zunino for help porting Java to Irix. 40066 40067 40068 The following people are recognized for their contributions to GNAT, 40069 the Ada front end of GCC: 40070 * Bernard Banner 40071 40072 * Romain Berrendonner 40073 40074 * Geert Bosch 40075 40076 * Emmanuel Briot 40077 40078 * Joel Brobecker 40079 40080 * Ben Brosgol 40081 40082 * Vincent Celier 40083 40084 * Arnaud Charlet 40085 40086 * Chien Chieng 40087 40088 * Cyrille Comar 40089 40090 * Cyrille Crozes 40091 40092 * Robert Dewar 40093 40094 * Gary Dismukes 40095 40096 * Robert Duff 40097 40098 * Ed Falis 40099 40100 * Ramon Fernandez 40101 40102 * Sam Figueroa 40103 40104 * Vasiliy Fofanov 40105 40106 * Michael Friess 40107 40108 * Franco Gasperoni 40109 40110 * Ted Giering 40111 40112 * Matthew Gingell 40113 40114 * Laurent Guerby 40115 40116 * Jerome Guitton 40117 40118 * Olivier Hainque 40119 40120 * Jerome Hugues 40121 40122 * Hristian Kirtchev 40123 40124 * Jerome Lambourg 40125 40126 * Bruno Leclerc 40127 40128 * Albert Lee 40129 40130 * Sean McNeil 40131 40132 * Javier Miranda 40133 40134 * Laurent Nana 40135 40136 * Pascal Obry 40137 40138 * Dong-Ik Oh 40139 40140 * Laurent Pautet 40141 40142 * Brett Porter 40143 40144 * Thomas Quinot 40145 40146 * Nicolas Roche 40147 40148 * Pat Rogers 40149 40150 * Jose Ruiz 40151 40152 * Douglas Rupp 40153 40154 * Sergey Rybin 40155 40156 * Gail Schenker 40157 40158 * Ed Schonberg 40159 40160 * Nicolas Setton 40161 40162 * Samuel Tardieu 40163 40164 40165 The following people are recognized for their contributions of new 40166 features, bug reports, testing and integration of classpath/libgcj for 40167 GCC version 4.1: 40168 * Lillian Angel for `JTree' implementation and lots Free Swing 40169 additions and bug fixes. 40170 40171 * Wolfgang Baer for `GapContent' bug fixes. 40172 40173 * Anthony Balkissoon for `JList', Free Swing 1.5 updates and mouse 40174 event fixes, lots of Free Swing work including `JTable' editing. 40175 40176 * Stuart Ballard for RMI constant fixes. 40177 40178 * Goffredo Baroncelli for `HTTPURLConnection' fixes. 40179 40180 * Gary Benson for `MessageFormat' fixes. 40181 40182 * Daniel Bonniot for `Serialization' fixes. 40183 40184 * Chris Burdess for lots of gnu.xml and http protocol fixes, `StAX' 40185 and `DOM xml:id' support. 40186 40187 * Ka-Hing Cheung for `TreePath' and `TreeSelection' fixes. 40188 40189 * Archie Cobbs for build fixes, VM interface updates, 40190 `URLClassLoader' updates. 40191 40192 * Kelley Cook for build fixes. 40193 40194 * Martin Cordova for Suggestions for better `SocketTimeoutException'. 40195 40196 * David Daney for `BitSet' bug fixes, `HttpURLConnection' rewrite 40197 and improvements. 40198 40199 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 40200 2D support. Lots of imageio framework additions, lots of AWT and 40201 Free Swing bug fixes. 40202 40203 * Jeroen Frijters for `ClassLoader' and nio cleanups, serialization 40204 fixes, better `Proxy' support, bug fixes and IKVM integration. 40205 40206 * Santiago Gala for `AccessControlContext' fixes. 40207 40208 * Nicolas Geoffray for `VMClassLoader' and `AccessController' 40209 improvements. 40210 40211 * David Gilbert for `basic' and `metal' icon and plaf support and 40212 lots of documenting, Lots of Free Swing and metal theme additions. 40213 `MetalIconFactory' implementation. 40214 40215 * Anthony Green for `MIDI' framework, `ALSA' and `DSSI' providers. 40216 40217 * Andrew Haley for `Serialization' and `URLClassLoader' fixes, gcj 40218 build speedups. 40219 40220 * Kim Ho for `JFileChooser' implementation. 40221 40222 * Andrew John Hughes for `Locale' and net fixes, URI RFC2986 40223 updates, `Serialization' fixes, `Properties' XML support and 40224 generic branch work, VMIntegration guide update. 40225 40226 * Bastiaan Huisman for `TimeZone' bug fixing. 40227 40228 * Andreas Jaeger for mprec updates. 40229 40230 * Paul Jenner for better `-Werror' support. 40231 40232 * Ito Kazumitsu for `NetworkInterface' implementation and updates. 40233 40234 * Roman Kennke for `BoxLayout', `GrayFilter' and `SplitPane', plus 40235 bug fixes all over. Lots of Free Swing work including styled text. 40236 40237 * Simon Kitching for `String' cleanups and optimization suggestions. 40238 40239 * Michael Koch for configuration fixes, `Locale' updates, bug and 40240 build fixes. 40241 40242 * Guilhem Lavaux for configuration, thread and channel fixes and 40243 Kaffe integration. JCL native `Pointer' updates. Logger bug fixes. 40244 40245 * David Lichteblau for JCL support library global/local reference 40246 cleanups. 40247 40248 * Aaron Luchko for JDWP updates and documentation fixes. 40249 40250 * Ziga Mahkovec for `Graphics2D' upgraded to Cairo 0.5 and new regex 40251 features. 40252 40253 * Sven de Marothy for BMP imageio support, CSS and `TextLayout' 40254 fixes. `GtkImage' rewrite, 2D, awt, free swing and date/time fixes 40255 and implementing the Qt4 peers. 40256 40257 * Casey Marshall for crypto algorithm fixes, `FileChannel' lock, 40258 `SystemLogger' and `FileHandler' rotate implementations, NIO 40259 `FileChannel.map' support, security and policy updates. 40260 40261 * Bryce McKinlay for RMI work. 40262 40263 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 40264 testing and documenting. 40265 40266 * Kalle Olavi Niemitalo for build fixes. 40267 40268 * Rainer Orth for build fixes. 40269 40270 * Andrew Overholt for `File' locking fixes. 40271 40272 * Ingo Proetel for `Image', `Logger' and `URLClassLoader' updates. 40273 40274 * Olga Rodimina for `MenuSelectionManager' implementation. 40275 40276 * Jan Roehrich for `BasicTreeUI' and `JTree' fixes. 40277 40278 * Julian Scheid for documentation updates and gjdoc support. 40279 40280 * Christian Schlichtherle for zip fixes and cleanups. 40281 40282 * Robert Schuster for documentation updates and beans fixes, 40283 `TreeNode' enumerations and `ActionCommand' and various fixes, XML 40284 and URL, AWT and Free Swing bug fixes. 40285 40286 * Keith Seitz for lots of JDWP work. 40287 40288 * Christian Thalinger for 64-bit cleanups, Configuration and VM 40289 interface fixes and `CACAO' integration, `fdlibm' updates. 40290 40291 * Gael Thomas for `VMClassLoader' boot packages support suggestions. 40292 40293 * Andreas Tobler for Darwin and Solaris testing and fixing, `Qt4' 40294 support for Darwin/OS X, `Graphics2D' support, `gtk+' updates. 40295 40296 * Dalibor Topic for better `DEBUG' support, build cleanups and Kaffe 40297 integration. `Qt4' build infrastructure, `SHA1PRNG' and 40298 `GdkPixbugDecoder' updates. 40299 40300 * Tom Tromey for Eclipse integration, generics work, lots of bug 40301 fixes and gcj integration including coordinating The Big Merge. 40302 40303 * Mark Wielaard for bug fixes, packaging and release management, 40304 `Clipboard' implementation, system call interrupts and network 40305 timeouts and `GdkPixpufDecoder' fixes. 40306 40307 40308 In addition to the above, all of which also contributed time and 40309 energy in testing GCC, we would like to thank the following for their 40310 contributions to testing: 40311 40312 * Michael Abd-El-Malek 40313 40314 * Thomas Arend 40315 40316 * Bonzo Armstrong 40317 40318 * Steven Ashe 40319 40320 * Chris Baldwin 40321 40322 * David Billinghurst 40323 40324 * Jim Blandy 40325 40326 * Stephane Bortzmeyer 40327 40328 * Horst von Brand 40329 40330 * Frank Braun 40331 40332 * Rodney Brown 40333 40334 * Sidney Cadot 40335 40336 * Bradford Castalia 40337 40338 * Robert Clark 40339 40340 * Jonathan Corbet 40341 40342 * Ralph Doncaster 40343 40344 * Richard Emberson 40345 40346 * Levente Farkas 40347 40348 * Graham Fawcett 40349 40350 * Mark Fernyhough 40351 40352 * Robert A. French 40353 40354 * Jo"rgen Freyh 40355 40356 * Mark K. Gardner 40357 40358 * Charles-Antoine Gauthier 40359 40360 * Yung Shing Gene 40361 40362 * David Gilbert 40363 40364 * Simon Gornall 40365 40366 * Fred Gray 40367 40368 * John Griffin 40369 40370 * Patrik Hagglund 40371 40372 * Phil Hargett 40373 40374 * Amancio Hasty 40375 40376 * Takafumi Hayashi 40377 40378 * Bryan W. Headley 40379 40380 * Kevin B. Hendricks 40381 40382 * Joep Jansen 40383 40384 * Christian Joensson 40385 40386 * Michel Kern 40387 40388 * David Kidd 40389 40390 * Tobias Kuipers 40391 40392 * Anand Krishnaswamy 40393 40394 * A. O. V. Le Blanc 40395 40396 * llewelly 40397 40398 * Damon Love 40399 40400 * Brad Lucier 40401 40402 * Matthias Klose 40403 40404 * Martin Knoblauch 40405 40406 * Rick Lutowski 40407 40408 * Jesse Macnish 40409 40410 * Stefan Morrell 40411 40412 * Anon A. Mous 40413 40414 * Matthias Mueller 40415 40416 * Pekka Nikander 40417 40418 * Rick Niles 40419 40420 * Jon Olson 40421 40422 * Magnus Persson 40423 40424 * Chris Pollard 40425 40426 * Richard Polton 40427 40428 * Derk Reefman 40429 40430 * David Rees 40431 40432 * Paul Reilly 40433 40434 * Tom Reilly 40435 40436 * Torsten Rueger 40437 40438 * Danny Sadinoff 40439 40440 * Marc Schifer 40441 40442 * Erik Schnetter 40443 40444 * Wayne K. Schroll 40445 40446 * David Schuler 40447 40448 * Vin Shelton 40449 40450 * Tim Souder 40451 40452 * Adam Sulmicki 40453 40454 * Bill Thorson 40455 40456 * George Talbot 40457 40458 * Pedro A. M. Vazquez 40459 40460 * Gregory Warnes 40461 40462 * Ian Watson 40463 40464 * David E. Young 40465 40466 * And many others 40467 40468 And finally we'd like to thank everyone who uses the compiler, provides 40469 feedback and generally reminds us why we're doing this work in the first 40470 place. 40471 40472 40473 File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 40474 40475 Option Index 40476 ************ 40477 40478 GCC's command line options are indexed here without any initial `-' or 40479 `--'. Where an option has both positive and negative forms (such as 40480 `-fOPTION' and `-fno-OPTION'), relevant entries in the manual are 40481 indexed under the most appropriate form; it may sometimes be useful to 40482 look up both forms. 40483 40484 [index] 40485 * Menu: 40486 40487 * fltrans: LTO. (line 499) 40488 * fltrans-output-list: LTO. (line 504) 40489 * fwpa: LTO. (line 490) 40490 * msoft-float: Soft float library routines. 40491 (line 6) 40492 40493 40494 File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 40495 40496 Concept Index 40497 ************* 40498 40499 [index] 40500 * Menu: 40501 40502 * ! in constraint: Multi-Alternative. (line 47) 40503 * # in constraint: Modifiers. (line 67) 40504 * # in template: Output Template. (line 66) 40505 * #pragma: Misc. (line 381) 40506 * % in constraint: Modifiers. (line 45) 40507 * % in GTY option: GTY Options. (line 18) 40508 * % in template: Output Template. (line 6) 40509 * & in constraint: Modifiers. (line 25) 40510 * (nil): RTL Objects. (line 73) 40511 * * in constraint: Modifiers. (line 72) 40512 * * in template: Output Statement. (line 29) 40513 * + in constraint: Modifiers. (line 12) 40514 * -fsection-anchors <1>: Anchored Addresses. (line 6) 40515 * -fsection-anchors: Special Accessors. (line 110) 40516 * /c in RTL dump: Flags. (line 239) 40517 * /f in RTL dump: Flags. (line 247) 40518 * /i in RTL dump: Flags. (line 299) 40519 * /j in RTL dump: Flags. (line 314) 40520 * /s in RTL dump: Flags. (line 263) 40521 * /u in RTL dump: Flags. (line 324) 40522 * /v in RTL dump: Flags. (line 356) 40523 * 0 in constraint: Simple Constraints. (line 130) 40524 * < in constraint: Simple Constraints. (line 48) 40525 * = in constraint: Modifiers. (line 8) 40526 * > in constraint: Simple Constraints. (line 61) 40527 * ? in constraint: Multi-Alternative. (line 41) 40528 * \: Output Template. (line 46) 40529 * __absvdi2: Integer library routines. 40530 (line 107) 40531 * __absvsi2: Integer library routines. 40532 (line 106) 40533 * __addda3: Fixed-point fractional library routines. 40534 (line 45) 40535 * __adddf3: Soft float library routines. 40536 (line 23) 40537 * __adddq3: Fixed-point fractional library routines. 40538 (line 33) 40539 * __addha3: Fixed-point fractional library routines. 40540 (line 43) 40541 * __addhq3: Fixed-point fractional library routines. 40542 (line 30) 40543 * __addqq3: Fixed-point fractional library routines. 40544 (line 29) 40545 * __addsa3: Fixed-point fractional library routines. 40546 (line 44) 40547 * __addsf3: Soft float library routines. 40548 (line 22) 40549 * __addsq3: Fixed-point fractional library routines. 40550 (line 31) 40551 * __addta3: Fixed-point fractional library routines. 40552 (line 47) 40553 * __addtf3: Soft float library routines. 40554 (line 25) 40555 * __adduda3: Fixed-point fractional library routines. 40556 (line 53) 40557 * __addudq3: Fixed-point fractional library routines. 40558 (line 41) 40559 * __adduha3: Fixed-point fractional library routines. 40560 (line 49) 40561 * __adduhq3: Fixed-point fractional library routines. 40562 (line 37) 40563 * __adduqq3: Fixed-point fractional library routines. 40564 (line 35) 40565 * __addusa3: Fixed-point fractional library routines. 40566 (line 51) 40567 * __addusq3: Fixed-point fractional library routines. 40568 (line 39) 40569 * __adduta3: Fixed-point fractional library routines. 40570 (line 55) 40571 * __addvdi3: Integer library routines. 40572 (line 111) 40573 * __addvsi3: Integer library routines. 40574 (line 110) 40575 * __addxf3: Soft float library routines. 40576 (line 27) 40577 * __ashlda3: Fixed-point fractional library routines. 40578 (line 351) 40579 * __ashldi3: Integer library routines. 40580 (line 14) 40581 * __ashldq3: Fixed-point fractional library routines. 40582 (line 340) 40583 * __ashlha3: Fixed-point fractional library routines. 40584 (line 349) 40585 * __ashlhq3: Fixed-point fractional library routines. 40586 (line 337) 40587 * __ashlqq3: Fixed-point fractional library routines. 40588 (line 336) 40589 * __ashlsa3: Fixed-point fractional library routines. 40590 (line 350) 40591 * __ashlsi3: Integer library routines. 40592 (line 13) 40593 * __ashlsq3: Fixed-point fractional library routines. 40594 (line 338) 40595 * __ashlta3: Fixed-point fractional library routines. 40596 (line 353) 40597 * __ashlti3: Integer library routines. 40598 (line 15) 40599 * __ashluda3: Fixed-point fractional library routines. 40600 (line 359) 40601 * __ashludq3: Fixed-point fractional library routines. 40602 (line 348) 40603 * __ashluha3: Fixed-point fractional library routines. 40604 (line 355) 40605 * __ashluhq3: Fixed-point fractional library routines. 40606 (line 344) 40607 * __ashluqq3: Fixed-point fractional library routines. 40608 (line 342) 40609 * __ashlusa3: Fixed-point fractional library routines. 40610 (line 357) 40611 * __ashlusq3: Fixed-point fractional library routines. 40612 (line 346) 40613 * __ashluta3: Fixed-point fractional library routines. 40614 (line 361) 40615 * __ashrda3: Fixed-point fractional library routines. 40616 (line 371) 40617 * __ashrdi3: Integer library routines. 40618 (line 19) 40619 * __ashrdq3: Fixed-point fractional library routines. 40620 (line 368) 40621 * __ashrha3: Fixed-point fractional library routines. 40622 (line 369) 40623 * __ashrhq3: Fixed-point fractional library routines. 40624 (line 365) 40625 * __ashrqq3: Fixed-point fractional library routines. 40626 (line 364) 40627 * __ashrsa3: Fixed-point fractional library routines. 40628 (line 370) 40629 * __ashrsi3: Integer library routines. 40630 (line 18) 40631 * __ashrsq3: Fixed-point fractional library routines. 40632 (line 366) 40633 * __ashrta3: Fixed-point fractional library routines. 40634 (line 373) 40635 * __ashrti3: Integer library routines. 40636 (line 20) 40637 * __bid_adddd3: Decimal float library routines. 40638 (line 25) 40639 * __bid_addsd3: Decimal float library routines. 40640 (line 21) 40641 * __bid_addtd3: Decimal float library routines. 40642 (line 29) 40643 * __bid_divdd3: Decimal float library routines. 40644 (line 68) 40645 * __bid_divsd3: Decimal float library routines. 40646 (line 64) 40647 * __bid_divtd3: Decimal float library routines. 40648 (line 72) 40649 * __bid_eqdd2: Decimal float library routines. 40650 (line 259) 40651 * __bid_eqsd2: Decimal float library routines. 40652 (line 257) 40653 * __bid_eqtd2: Decimal float library routines. 40654 (line 261) 40655 * __bid_extendddtd2: Decimal float library routines. 40656 (line 92) 40657 * __bid_extendddtf: Decimal float library routines. 40658 (line 140) 40659 * __bid_extendddxf: Decimal float library routines. 40660 (line 134) 40661 * __bid_extenddfdd: Decimal float library routines. 40662 (line 147) 40663 * __bid_extenddftd: Decimal float library routines. 40664 (line 107) 40665 * __bid_extendsddd2: Decimal float library routines. 40666 (line 88) 40667 * __bid_extendsddf: Decimal float library routines. 40668 (line 128) 40669 * __bid_extendsdtd2: Decimal float library routines. 40670 (line 90) 40671 * __bid_extendsdtf: Decimal float library routines. 40672 (line 138) 40673 * __bid_extendsdxf: Decimal float library routines. 40674 (line 132) 40675 * __bid_extendsfdd: Decimal float library routines. 40676 (line 103) 40677 * __bid_extendsfsd: Decimal float library routines. 40678 (line 145) 40679 * __bid_extendsftd: Decimal float library routines. 40680 (line 105) 40681 * __bid_extendtftd: Decimal float library routines. 40682 (line 149) 40683 * __bid_extendxftd: Decimal float library routines. 40684 (line 109) 40685 * __bid_fixdddi: Decimal float library routines. 40686 (line 170) 40687 * __bid_fixddsi: Decimal float library routines. 40688 (line 162) 40689 * __bid_fixsddi: Decimal float library routines. 40690 (line 168) 40691 * __bid_fixsdsi: Decimal float library routines. 40692 (line 160) 40693 * __bid_fixtddi: Decimal float library routines. 40694 (line 172) 40695 * __bid_fixtdsi: Decimal float library routines. 40696 (line 164) 40697 * __bid_fixunsdddi: Decimal float library routines. 40698 (line 187) 40699 * __bid_fixunsddsi: Decimal float library routines. 40700 (line 178) 40701 * __bid_fixunssddi: Decimal float library routines. 40702 (line 185) 40703 * __bid_fixunssdsi: Decimal float library routines. 40704 (line 176) 40705 * __bid_fixunstddi: Decimal float library routines. 40706 (line 189) 40707 * __bid_fixunstdsi: Decimal float library routines. 40708 (line 180) 40709 * __bid_floatdidd: Decimal float library routines. 40710 (line 205) 40711 * __bid_floatdisd: Decimal float library routines. 40712 (line 203) 40713 * __bid_floatditd: Decimal float library routines. 40714 (line 207) 40715 * __bid_floatsidd: Decimal float library routines. 40716 (line 196) 40717 * __bid_floatsisd: Decimal float library routines. 40718 (line 194) 40719 * __bid_floatsitd: Decimal float library routines. 40720 (line 198) 40721 * __bid_floatunsdidd: Decimal float library routines. 40722 (line 223) 40723 * __bid_floatunsdisd: Decimal float library routines. 40724 (line 221) 40725 * __bid_floatunsditd: Decimal float library routines. 40726 (line 225) 40727 * __bid_floatunssidd: Decimal float library routines. 40728 (line 214) 40729 * __bid_floatunssisd: Decimal float library routines. 40730 (line 212) 40731 * __bid_floatunssitd: Decimal float library routines. 40732 (line 216) 40733 * __bid_gedd2: Decimal float library routines. 40734 (line 277) 40735 * __bid_gesd2: Decimal float library routines. 40736 (line 275) 40737 * __bid_getd2: Decimal float library routines. 40738 (line 279) 40739 * __bid_gtdd2: Decimal float library routines. 40740 (line 304) 40741 * __bid_gtsd2: Decimal float library routines. 40742 (line 302) 40743 * __bid_gttd2: Decimal float library routines. 40744 (line 306) 40745 * __bid_ledd2: Decimal float library routines. 40746 (line 295) 40747 * __bid_lesd2: Decimal float library routines. 40748 (line 293) 40749 * __bid_letd2: Decimal float library routines. 40750 (line 297) 40751 * __bid_ltdd2: Decimal float library routines. 40752 (line 286) 40753 * __bid_ltsd2: Decimal float library routines. 40754 (line 284) 40755 * __bid_lttd2: Decimal float library routines. 40756 (line 288) 40757 * __bid_muldd3: Decimal float library routines. 40758 (line 54) 40759 * __bid_mulsd3: Decimal float library routines. 40760 (line 50) 40761 * __bid_multd3: Decimal float library routines. 40762 (line 58) 40763 * __bid_nedd2: Decimal float library routines. 40764 (line 268) 40765 * __bid_negdd2: Decimal float library routines. 40766 (line 78) 40767 * __bid_negsd2: Decimal float library routines. 40768 (line 76) 40769 * __bid_negtd2: Decimal float library routines. 40770 (line 80) 40771 * __bid_nesd2: Decimal float library routines. 40772 (line 266) 40773 * __bid_netd2: Decimal float library routines. 40774 (line 270) 40775 * __bid_subdd3: Decimal float library routines. 40776 (line 39) 40777 * __bid_subsd3: Decimal float library routines. 40778 (line 35) 40779 * __bid_subtd3: Decimal float library routines. 40780 (line 43) 40781 * __bid_truncdddf: Decimal float library routines. 40782 (line 153) 40783 * __bid_truncddsd2: Decimal float library routines. 40784 (line 94) 40785 * __bid_truncddsf: Decimal float library routines. 40786 (line 124) 40787 * __bid_truncdfsd: Decimal float library routines. 40788 (line 111) 40789 * __bid_truncsdsf: Decimal float library routines. 40790 (line 151) 40791 * __bid_trunctddd2: Decimal float library routines. 40792 (line 98) 40793 * __bid_trunctddf: Decimal float library routines. 40794 (line 130) 40795 * __bid_trunctdsd2: Decimal float library routines. 40796 (line 96) 40797 * __bid_trunctdsf: Decimal float library routines. 40798 (line 126) 40799 * __bid_trunctdtf: Decimal float library routines. 40800 (line 155) 40801 * __bid_trunctdxf: Decimal float library routines. 40802 (line 136) 40803 * __bid_trunctfdd: Decimal float library routines. 40804 (line 119) 40805 * __bid_trunctfsd: Decimal float library routines. 40806 (line 115) 40807 * __bid_truncxfdd: Decimal float library routines. 40808 (line 117) 40809 * __bid_truncxfsd: Decimal float library routines. 40810 (line 113) 40811 * __bid_unorddd2: Decimal float library routines. 40812 (line 235) 40813 * __bid_unordsd2: Decimal float library routines. 40814 (line 233) 40815 * __bid_unordtd2: Decimal float library routines. 40816 (line 237) 40817 * __bswapdi2: Integer library routines. 40818 (line 162) 40819 * __bswapsi2: Integer library routines. 40820 (line 161) 40821 * __builtin_classify_type: Varargs. (line 51) 40822 * __builtin_next_arg: Varargs. (line 42) 40823 * __builtin_saveregs: Varargs. (line 24) 40824 * __clear_cache: Miscellaneous routines. 40825 (line 10) 40826 * __clzdi2: Integer library routines. 40827 (line 131) 40828 * __clzsi2: Integer library routines. 40829 (line 130) 40830 * __clzti2: Integer library routines. 40831 (line 132) 40832 * __cmpda2: Fixed-point fractional library routines. 40833 (line 451) 40834 * __cmpdf2: Soft float library routines. 40835 (line 164) 40836 * __cmpdi2: Integer library routines. 40837 (line 87) 40838 * __cmpdq2: Fixed-point fractional library routines. 40839 (line 441) 40840 * __cmpha2: Fixed-point fractional library routines. 40841 (line 449) 40842 * __cmphq2: Fixed-point fractional library routines. 40843 (line 438) 40844 * __cmpqq2: Fixed-point fractional library routines. 40845 (line 437) 40846 * __cmpsa2: Fixed-point fractional library routines. 40847 (line 450) 40848 * __cmpsf2: Soft float library routines. 40849 (line 163) 40850 * __cmpsq2: Fixed-point fractional library routines. 40851 (line 439) 40852 * __cmpta2: Fixed-point fractional library routines. 40853 (line 453) 40854 * __cmptf2: Soft float library routines. 40855 (line 165) 40856 * __cmpti2: Integer library routines. 40857 (line 88) 40858 * __cmpuda2: Fixed-point fractional library routines. 40859 (line 458) 40860 * __cmpudq2: Fixed-point fractional library routines. 40861 (line 448) 40862 * __cmpuha2: Fixed-point fractional library routines. 40863 (line 455) 40864 * __cmpuhq2: Fixed-point fractional library routines. 40865 (line 444) 40866 * __cmpuqq2: Fixed-point fractional library routines. 40867 (line 443) 40868 * __cmpusa2: Fixed-point fractional library routines. 40869 (line 456) 40870 * __cmpusq2: Fixed-point fractional library routines. 40871 (line 446) 40872 * __cmputa2: Fixed-point fractional library routines. 40873 (line 460) 40874 * __CTOR_LIST__: Initialization. (line 25) 40875 * __ctzdi2: Integer library routines. 40876 (line 138) 40877 * __ctzsi2: Integer library routines. 40878 (line 137) 40879 * __ctzti2: Integer library routines. 40880 (line 139) 40881 * __divda3: Fixed-point fractional library routines. 40882 (line 227) 40883 * __divdc3: Soft float library routines. 40884 (line 252) 40885 * __divdf3: Soft float library routines. 40886 (line 48) 40887 * __divdi3: Integer library routines. 40888 (line 25) 40889 * __divdq3: Fixed-point fractional library routines. 40890 (line 223) 40891 * __divha3: Fixed-point fractional library routines. 40892 (line 225) 40893 * __divhq3: Fixed-point fractional library routines. 40894 (line 220) 40895 * __divqq3: Fixed-point fractional library routines. 40896 (line 219) 40897 * __divsa3: Fixed-point fractional library routines. 40898 (line 226) 40899 * __divsc3: Soft float library routines. 40900 (line 250) 40901 * __divsf3: Soft float library routines. 40902 (line 47) 40903 * __divsi3: Integer library routines. 40904 (line 24) 40905 * __divsq3: Fixed-point fractional library routines. 40906 (line 221) 40907 * __divta3: Fixed-point fractional library routines. 40908 (line 229) 40909 * __divtc3: Soft float library routines. 40910 (line 254) 40911 * __divtf3: Soft float library routines. 40912 (line 50) 40913 * __divti3: Integer library routines. 40914 (line 26) 40915 * __divxc3: Soft float library routines. 40916 (line 256) 40917 * __divxf3: Soft float library routines. 40918 (line 52) 40919 * __dpd_adddd3: Decimal float library routines. 40920 (line 23) 40921 * __dpd_addsd3: Decimal float library routines. 40922 (line 19) 40923 * __dpd_addtd3: Decimal float library routines. 40924 (line 27) 40925 * __dpd_divdd3: Decimal float library routines. 40926 (line 66) 40927 * __dpd_divsd3: Decimal float library routines. 40928 (line 62) 40929 * __dpd_divtd3: Decimal float library routines. 40930 (line 70) 40931 * __dpd_eqdd2: Decimal float library routines. 40932 (line 258) 40933 * __dpd_eqsd2: Decimal float library routines. 40934 (line 256) 40935 * __dpd_eqtd2: Decimal float library routines. 40936 (line 260) 40937 * __dpd_extendddtd2: Decimal float library routines. 40938 (line 91) 40939 * __dpd_extendddtf: Decimal float library routines. 40940 (line 139) 40941 * __dpd_extendddxf: Decimal float library routines. 40942 (line 133) 40943 * __dpd_extenddfdd: Decimal float library routines. 40944 (line 146) 40945 * __dpd_extenddftd: Decimal float library routines. 40946 (line 106) 40947 * __dpd_extendsddd2: Decimal float library routines. 40948 (line 87) 40949 * __dpd_extendsddf: Decimal float library routines. 40950 (line 127) 40951 * __dpd_extendsdtd2: Decimal float library routines. 40952 (line 89) 40953 * __dpd_extendsdtf: Decimal float library routines. 40954 (line 137) 40955 * __dpd_extendsdxf: Decimal float library routines. 40956 (line 131) 40957 * __dpd_extendsfdd: Decimal float library routines. 40958 (line 102) 40959 * __dpd_extendsfsd: Decimal float library routines. 40960 (line 144) 40961 * __dpd_extendsftd: Decimal float library routines. 40962 (line 104) 40963 * __dpd_extendtftd: Decimal float library routines. 40964 (line 148) 40965 * __dpd_extendxftd: Decimal float library routines. 40966 (line 108) 40967 * __dpd_fixdddi: Decimal float library routines. 40968 (line 169) 40969 * __dpd_fixddsi: Decimal float library routines. 40970 (line 161) 40971 * __dpd_fixsddi: Decimal float library routines. 40972 (line 167) 40973 * __dpd_fixsdsi: Decimal float library routines. 40974 (line 159) 40975 * __dpd_fixtddi: Decimal float library routines. 40976 (line 171) 40977 * __dpd_fixtdsi: Decimal float library routines. 40978 (line 163) 40979 * __dpd_fixunsdddi: Decimal float library routines. 40980 (line 186) 40981 * __dpd_fixunsddsi: Decimal float library routines. 40982 (line 177) 40983 * __dpd_fixunssddi: Decimal float library routines. 40984 (line 184) 40985 * __dpd_fixunssdsi: Decimal float library routines. 40986 (line 175) 40987 * __dpd_fixunstddi: Decimal float library routines. 40988 (line 188) 40989 * __dpd_fixunstdsi: Decimal float library routines. 40990 (line 179) 40991 * __dpd_floatdidd: Decimal float library routines. 40992 (line 204) 40993 * __dpd_floatdisd: Decimal float library routines. 40994 (line 202) 40995 * __dpd_floatditd: Decimal float library routines. 40996 (line 206) 40997 * __dpd_floatsidd: Decimal float library routines. 40998 (line 195) 40999 * __dpd_floatsisd: Decimal float library routines. 41000 (line 193) 41001 * __dpd_floatsitd: Decimal float library routines. 41002 (line 197) 41003 * __dpd_floatunsdidd: Decimal float library routines. 41004 (line 222) 41005 * __dpd_floatunsdisd: Decimal float library routines. 41006 (line 220) 41007 * __dpd_floatunsditd: Decimal float library routines. 41008 (line 224) 41009 * __dpd_floatunssidd: Decimal float library routines. 41010 (line 213) 41011 * __dpd_floatunssisd: Decimal float library routines. 41012 (line 211) 41013 * __dpd_floatunssitd: Decimal float library routines. 41014 (line 215) 41015 * __dpd_gedd2: Decimal float library routines. 41016 (line 276) 41017 * __dpd_gesd2: Decimal float library routines. 41018 (line 274) 41019 * __dpd_getd2: Decimal float library routines. 41020 (line 278) 41021 * __dpd_gtdd2: Decimal float library routines. 41022 (line 303) 41023 * __dpd_gtsd2: Decimal float library routines. 41024 (line 301) 41025 * __dpd_gttd2: Decimal float library routines. 41026 (line 305) 41027 * __dpd_ledd2: Decimal float library routines. 41028 (line 294) 41029 * __dpd_lesd2: Decimal float library routines. 41030 (line 292) 41031 * __dpd_letd2: Decimal float library routines. 41032 (line 296) 41033 * __dpd_ltdd2: Decimal float library routines. 41034 (line 285) 41035 * __dpd_ltsd2: Decimal float library routines. 41036 (line 283) 41037 * __dpd_lttd2: Decimal float library routines. 41038 (line 287) 41039 * __dpd_muldd3: Decimal float library routines. 41040 (line 52) 41041 * __dpd_mulsd3: Decimal float library routines. 41042 (line 48) 41043 * __dpd_multd3: Decimal float library routines. 41044 (line 56) 41045 * __dpd_nedd2: Decimal float library routines. 41046 (line 267) 41047 * __dpd_negdd2: Decimal float library routines. 41048 (line 77) 41049 * __dpd_negsd2: Decimal float library routines. 41050 (line 75) 41051 * __dpd_negtd2: Decimal float library routines. 41052 (line 79) 41053 * __dpd_nesd2: Decimal float library routines. 41054 (line 265) 41055 * __dpd_netd2: Decimal float library routines. 41056 (line 269) 41057 * __dpd_subdd3: Decimal float library routines. 41058 (line 37) 41059 * __dpd_subsd3: Decimal float library routines. 41060 (line 33) 41061 * __dpd_subtd3: Decimal float library routines. 41062 (line 41) 41063 * __dpd_truncdddf: Decimal float library routines. 41064 (line 152) 41065 * __dpd_truncddsd2: Decimal float library routines. 41066 (line 93) 41067 * __dpd_truncddsf: Decimal float library routines. 41068 (line 123) 41069 * __dpd_truncdfsd: Decimal float library routines. 41070 (line 110) 41071 * __dpd_truncsdsf: Decimal float library routines. 41072 (line 150) 41073 * __dpd_trunctddd2: Decimal float library routines. 41074 (line 97) 41075 * __dpd_trunctddf: Decimal float library routines. 41076 (line 129) 41077 * __dpd_trunctdsd2: Decimal float library routines. 41078 (line 95) 41079 * __dpd_trunctdsf: Decimal float library routines. 41080 (line 125) 41081 * __dpd_trunctdtf: Decimal float library routines. 41082 (line 154) 41083 * __dpd_trunctdxf: Decimal float library routines. 41084 (line 135) 41085 * __dpd_trunctfdd: Decimal float library routines. 41086 (line 118) 41087 * __dpd_trunctfsd: Decimal float library routines. 41088 (line 114) 41089 * __dpd_truncxfdd: Decimal float library routines. 41090 (line 116) 41091 * __dpd_truncxfsd: Decimal float library routines. 41092 (line 112) 41093 * __dpd_unorddd2: Decimal float library routines. 41094 (line 234) 41095 * __dpd_unordsd2: Decimal float library routines. 41096 (line 232) 41097 * __dpd_unordtd2: Decimal float library routines. 41098 (line 236) 41099 * __DTOR_LIST__: Initialization. (line 25) 41100 * __eqdf2: Soft float library routines. 41101 (line 194) 41102 * __eqsf2: Soft float library routines. 41103 (line 193) 41104 * __eqtf2: Soft float library routines. 41105 (line 195) 41106 * __extenddftf2: Soft float library routines. 41107 (line 68) 41108 * __extenddfxf2: Soft float library routines. 41109 (line 69) 41110 * __extendsfdf2: Soft float library routines. 41111 (line 65) 41112 * __extendsftf2: Soft float library routines. 41113 (line 66) 41114 * __extendsfxf2: Soft float library routines. 41115 (line 67) 41116 * __ffsdi2: Integer library routines. 41117 (line 144) 41118 * __ffsti2: Integer library routines. 41119 (line 145) 41120 * __fixdfdi: Soft float library routines. 41121 (line 88) 41122 * __fixdfsi: Soft float library routines. 41123 (line 81) 41124 * __fixdfti: Soft float library routines. 41125 (line 94) 41126 * __fixsfdi: Soft float library routines. 41127 (line 87) 41128 * __fixsfsi: Soft float library routines. 41129 (line 80) 41130 * __fixsfti: Soft float library routines. 41131 (line 93) 41132 * __fixtfdi: Soft float library routines. 41133 (line 89) 41134 * __fixtfsi: Soft float library routines. 41135 (line 82) 41136 * __fixtfti: Soft float library routines. 41137 (line 95) 41138 * __fixunsdfdi: Soft float library routines. 41139 (line 108) 41140 * __fixunsdfsi: Soft float library routines. 41141 (line 101) 41142 * __fixunsdfti: Soft float library routines. 41143 (line 115) 41144 * __fixunssfdi: Soft float library routines. 41145 (line 107) 41146 * __fixunssfsi: Soft float library routines. 41147 (line 100) 41148 * __fixunssfti: Soft float library routines. 41149 (line 114) 41150 * __fixunstfdi: Soft float library routines. 41151 (line 109) 41152 * __fixunstfsi: Soft float library routines. 41153 (line 102) 41154 * __fixunstfti: Soft float library routines. 41155 (line 116) 41156 * __fixunsxfdi: Soft float library routines. 41157 (line 110) 41158 * __fixunsxfsi: Soft float library routines. 41159 (line 103) 41160 * __fixunsxfti: Soft float library routines. 41161 (line 117) 41162 * __fixxfdi: Soft float library routines. 41163 (line 90) 41164 * __fixxfsi: Soft float library routines. 41165 (line 83) 41166 * __fixxfti: Soft float library routines. 41167 (line 96) 41168 * __floatdidf: Soft float library routines. 41169 (line 128) 41170 * __floatdisf: Soft float library routines. 41171 (line 127) 41172 * __floatditf: Soft float library routines. 41173 (line 129) 41174 * __floatdixf: Soft float library routines. 41175 (line 130) 41176 * __floatsidf: Soft float library routines. 41177 (line 122) 41178 * __floatsisf: Soft float library routines. 41179 (line 121) 41180 * __floatsitf: Soft float library routines. 41181 (line 123) 41182 * __floatsixf: Soft float library routines. 41183 (line 124) 41184 * __floattidf: Soft float library routines. 41185 (line 134) 41186 * __floattisf: Soft float library routines. 41187 (line 133) 41188 * __floattitf: Soft float library routines. 41189 (line 135) 41190 * __floattixf: Soft float library routines. 41191 (line 136) 41192 * __floatundidf: Soft float library routines. 41193 (line 146) 41194 * __floatundisf: Soft float library routines. 41195 (line 145) 41196 * __floatunditf: Soft float library routines. 41197 (line 147) 41198 * __floatundixf: Soft float library routines. 41199 (line 148) 41200 * __floatunsidf: Soft float library routines. 41201 (line 140) 41202 * __floatunsisf: Soft float library routines. 41203 (line 139) 41204 * __floatunsitf: Soft float library routines. 41205 (line 141) 41206 * __floatunsixf: Soft float library routines. 41207 (line 142) 41208 * __floatuntidf: Soft float library routines. 41209 (line 152) 41210 * __floatuntisf: Soft float library routines. 41211 (line 151) 41212 * __floatuntitf: Soft float library routines. 41213 (line 153) 41214 * __floatuntixf: Soft float library routines. 41215 (line 154) 41216 * __fractdadf: Fixed-point fractional library routines. 41217 (line 636) 41218 * __fractdadi: Fixed-point fractional library routines. 41219 (line 633) 41220 * __fractdadq: Fixed-point fractional library routines. 41221 (line 616) 41222 * __fractdaha2: Fixed-point fractional library routines. 41223 (line 617) 41224 * __fractdahi: Fixed-point fractional library routines. 41225 (line 631) 41226 * __fractdahq: Fixed-point fractional library routines. 41227 (line 614) 41228 * __fractdaqi: Fixed-point fractional library routines. 41229 (line 630) 41230 * __fractdaqq: Fixed-point fractional library routines. 41231 (line 613) 41232 * __fractdasa2: Fixed-point fractional library routines. 41233 (line 618) 41234 * __fractdasf: Fixed-point fractional library routines. 41235 (line 635) 41236 * __fractdasi: Fixed-point fractional library routines. 41237 (line 632) 41238 * __fractdasq: Fixed-point fractional library routines. 41239 (line 615) 41240 * __fractdata2: Fixed-point fractional library routines. 41241 (line 619) 41242 * __fractdati: Fixed-point fractional library routines. 41243 (line 634) 41244 * __fractdauda: Fixed-point fractional library routines. 41245 (line 627) 41246 * __fractdaudq: Fixed-point fractional library routines. 41247 (line 624) 41248 * __fractdauha: Fixed-point fractional library routines. 41249 (line 625) 41250 * __fractdauhq: Fixed-point fractional library routines. 41251 (line 621) 41252 * __fractdauqq: Fixed-point fractional library routines. 41253 (line 620) 41254 * __fractdausa: Fixed-point fractional library routines. 41255 (line 626) 41256 * __fractdausq: Fixed-point fractional library routines. 41257 (line 622) 41258 * __fractdauta: Fixed-point fractional library routines. 41259 (line 629) 41260 * __fractdfda: Fixed-point fractional library routines. 41261 (line 1025) 41262 * __fractdfdq: Fixed-point fractional library routines. 41263 (line 1022) 41264 * __fractdfha: Fixed-point fractional library routines. 41265 (line 1023) 41266 * __fractdfhq: Fixed-point fractional library routines. 41267 (line 1020) 41268 * __fractdfqq: Fixed-point fractional library routines. 41269 (line 1019) 41270 * __fractdfsa: Fixed-point fractional library routines. 41271 (line 1024) 41272 * __fractdfsq: Fixed-point fractional library routines. 41273 (line 1021) 41274 * __fractdfta: Fixed-point fractional library routines. 41275 (line 1026) 41276 * __fractdfuda: Fixed-point fractional library routines. 41277 (line 1033) 41278 * __fractdfudq: Fixed-point fractional library routines. 41279 (line 1030) 41280 * __fractdfuha: Fixed-point fractional library routines. 41281 (line 1031) 41282 * __fractdfuhq: Fixed-point fractional library routines. 41283 (line 1028) 41284 * __fractdfuqq: Fixed-point fractional library routines. 41285 (line 1027) 41286 * __fractdfusa: Fixed-point fractional library routines. 41287 (line 1032) 41288 * __fractdfusq: Fixed-point fractional library routines. 41289 (line 1029) 41290 * __fractdfuta: Fixed-point fractional library routines. 41291 (line 1034) 41292 * __fractdida: Fixed-point fractional library routines. 41293 (line 975) 41294 * __fractdidq: Fixed-point fractional library routines. 41295 (line 972) 41296 * __fractdiha: Fixed-point fractional library routines. 41297 (line 973) 41298 * __fractdihq: Fixed-point fractional library routines. 41299 (line 970) 41300 * __fractdiqq: Fixed-point fractional library routines. 41301 (line 969) 41302 * __fractdisa: Fixed-point fractional library routines. 41303 (line 974) 41304 * __fractdisq: Fixed-point fractional library routines. 41305 (line 971) 41306 * __fractdita: Fixed-point fractional library routines. 41307 (line 976) 41308 * __fractdiuda: Fixed-point fractional library routines. 41309 (line 983) 41310 * __fractdiudq: Fixed-point fractional library routines. 41311 (line 980) 41312 * __fractdiuha: Fixed-point fractional library routines. 41313 (line 981) 41314 * __fractdiuhq: Fixed-point fractional library routines. 41315 (line 978) 41316 * __fractdiuqq: Fixed-point fractional library routines. 41317 (line 977) 41318 * __fractdiusa: Fixed-point fractional library routines. 41319 (line 982) 41320 * __fractdiusq: Fixed-point fractional library routines. 41321 (line 979) 41322 * __fractdiuta: Fixed-point fractional library routines. 41323 (line 984) 41324 * __fractdqda: Fixed-point fractional library routines. 41325 (line 544) 41326 * __fractdqdf: Fixed-point fractional library routines. 41327 (line 566) 41328 * __fractdqdi: Fixed-point fractional library routines. 41329 (line 563) 41330 * __fractdqha: Fixed-point fractional library routines. 41331 (line 542) 41332 * __fractdqhi: Fixed-point fractional library routines. 41333 (line 561) 41334 * __fractdqhq2: Fixed-point fractional library routines. 41335 (line 540) 41336 * __fractdqqi: Fixed-point fractional library routines. 41337 (line 560) 41338 * __fractdqqq2: Fixed-point fractional library routines. 41339 (line 539) 41340 * __fractdqsa: Fixed-point fractional library routines. 41341 (line 543) 41342 * __fractdqsf: Fixed-point fractional library routines. 41343 (line 565) 41344 * __fractdqsi: Fixed-point fractional library routines. 41345 (line 562) 41346 * __fractdqsq2: Fixed-point fractional library routines. 41347 (line 541) 41348 * __fractdqta: Fixed-point fractional library routines. 41349 (line 545) 41350 * __fractdqti: Fixed-point fractional library routines. 41351 (line 564) 41352 * __fractdquda: Fixed-point fractional library routines. 41353 (line 557) 41354 * __fractdqudq: Fixed-point fractional library routines. 41355 (line 552) 41356 * __fractdquha: Fixed-point fractional library routines. 41357 (line 554) 41358 * __fractdquhq: Fixed-point fractional library routines. 41359 (line 548) 41360 * __fractdquqq: Fixed-point fractional library routines. 41361 (line 547) 41362 * __fractdqusa: Fixed-point fractional library routines. 41363 (line 555) 41364 * __fractdqusq: Fixed-point fractional library routines. 41365 (line 550) 41366 * __fractdquta: Fixed-point fractional library routines. 41367 (line 559) 41368 * __fracthada2: Fixed-point fractional library routines. 41369 (line 572) 41370 * __fracthadf: Fixed-point fractional library routines. 41371 (line 590) 41372 * __fracthadi: Fixed-point fractional library routines. 41373 (line 587) 41374 * __fracthadq: Fixed-point fractional library routines. 41375 (line 570) 41376 * __fracthahi: Fixed-point fractional library routines. 41377 (line 585) 41378 * __fracthahq: Fixed-point fractional library routines. 41379 (line 568) 41380 * __fracthaqi: Fixed-point fractional library routines. 41381 (line 584) 41382 * __fracthaqq: Fixed-point fractional library routines. 41383 (line 567) 41384 * __fracthasa2: Fixed-point fractional library routines. 41385 (line 571) 41386 * __fracthasf: Fixed-point fractional library routines. 41387 (line 589) 41388 * __fracthasi: Fixed-point fractional library routines. 41389 (line 586) 41390 * __fracthasq: Fixed-point fractional library routines. 41391 (line 569) 41392 * __fracthata2: Fixed-point fractional library routines. 41393 (line 573) 41394 * __fracthati: Fixed-point fractional library routines. 41395 (line 588) 41396 * __fracthauda: Fixed-point fractional library routines. 41397 (line 581) 41398 * __fracthaudq: Fixed-point fractional library routines. 41399 (line 578) 41400 * __fracthauha: Fixed-point fractional library routines. 41401 (line 579) 41402 * __fracthauhq: Fixed-point fractional library routines. 41403 (line 575) 41404 * __fracthauqq: Fixed-point fractional library routines. 41405 (line 574) 41406 * __fracthausa: Fixed-point fractional library routines. 41407 (line 580) 41408 * __fracthausq: Fixed-point fractional library routines. 41409 (line 576) 41410 * __fracthauta: Fixed-point fractional library routines. 41411 (line 583) 41412 * __fracthida: Fixed-point fractional library routines. 41413 (line 943) 41414 * __fracthidq: Fixed-point fractional library routines. 41415 (line 940) 41416 * __fracthiha: Fixed-point fractional library routines. 41417 (line 941) 41418 * __fracthihq: Fixed-point fractional library routines. 41419 (line 938) 41420 * __fracthiqq: Fixed-point fractional library routines. 41421 (line 937) 41422 * __fracthisa: Fixed-point fractional library routines. 41423 (line 942) 41424 * __fracthisq: Fixed-point fractional library routines. 41425 (line 939) 41426 * __fracthita: Fixed-point fractional library routines. 41427 (line 944) 41428 * __fracthiuda: Fixed-point fractional library routines. 41429 (line 951) 41430 * __fracthiudq: Fixed-point fractional library routines. 41431 (line 948) 41432 * __fracthiuha: Fixed-point fractional library routines. 41433 (line 949) 41434 * __fracthiuhq: Fixed-point fractional library routines. 41435 (line 946) 41436 * __fracthiuqq: Fixed-point fractional library routines. 41437 (line 945) 41438 * __fracthiusa: Fixed-point fractional library routines. 41439 (line 950) 41440 * __fracthiusq: Fixed-point fractional library routines. 41441 (line 947) 41442 * __fracthiuta: Fixed-point fractional library routines. 41443 (line 952) 41444 * __fracthqda: Fixed-point fractional library routines. 41445 (line 498) 41446 * __fracthqdf: Fixed-point fractional library routines. 41447 (line 514) 41448 * __fracthqdi: Fixed-point fractional library routines. 41449 (line 511) 41450 * __fracthqdq2: Fixed-point fractional library routines. 41451 (line 495) 41452 * __fracthqha: Fixed-point fractional library routines. 41453 (line 496) 41454 * __fracthqhi: Fixed-point fractional library routines. 41455 (line 509) 41456 * __fracthqqi: Fixed-point fractional library routines. 41457 (line 508) 41458 * __fracthqqq2: Fixed-point fractional library routines. 41459 (line 493) 41460 * __fracthqsa: Fixed-point fractional library routines. 41461 (line 497) 41462 * __fracthqsf: Fixed-point fractional library routines. 41463 (line 513) 41464 * __fracthqsi: Fixed-point fractional library routines. 41465 (line 510) 41466 * __fracthqsq2: Fixed-point fractional library routines. 41467 (line 494) 41468 * __fracthqta: Fixed-point fractional library routines. 41469 (line 499) 41470 * __fracthqti: Fixed-point fractional library routines. 41471 (line 512) 41472 * __fracthquda: Fixed-point fractional library routines. 41473 (line 506) 41474 * __fracthqudq: Fixed-point fractional library routines. 41475 (line 503) 41476 * __fracthquha: Fixed-point fractional library routines. 41477 (line 504) 41478 * __fracthquhq: Fixed-point fractional library routines. 41479 (line 501) 41480 * __fracthquqq: Fixed-point fractional library routines. 41481 (line 500) 41482 * __fracthqusa: Fixed-point fractional library routines. 41483 (line 505) 41484 * __fracthqusq: Fixed-point fractional library routines. 41485 (line 502) 41486 * __fracthquta: Fixed-point fractional library routines. 41487 (line 507) 41488 * __fractqida: Fixed-point fractional library routines. 41489 (line 925) 41490 * __fractqidq: Fixed-point fractional library routines. 41491 (line 922) 41492 * __fractqiha: Fixed-point fractional library routines. 41493 (line 923) 41494 * __fractqihq: Fixed-point fractional library routines. 41495 (line 920) 41496 * __fractqiqq: Fixed-point fractional library routines. 41497 (line 919) 41498 * __fractqisa: Fixed-point fractional library routines. 41499 (line 924) 41500 * __fractqisq: Fixed-point fractional library routines. 41501 (line 921) 41502 * __fractqita: Fixed-point fractional library routines. 41503 (line 926) 41504 * __fractqiuda: Fixed-point fractional library routines. 41505 (line 934) 41506 * __fractqiudq: Fixed-point fractional library routines. 41507 (line 931) 41508 * __fractqiuha: Fixed-point fractional library routines. 41509 (line 932) 41510 * __fractqiuhq: Fixed-point fractional library routines. 41511 (line 928) 41512 * __fractqiuqq: Fixed-point fractional library routines. 41513 (line 927) 41514 * __fractqiusa: Fixed-point fractional library routines. 41515 (line 933) 41516 * __fractqiusq: Fixed-point fractional library routines. 41517 (line 929) 41518 * __fractqiuta: Fixed-point fractional library routines. 41519 (line 936) 41520 * __fractqqda: Fixed-point fractional library routines. 41521 (line 474) 41522 * __fractqqdf: Fixed-point fractional library routines. 41523 (line 492) 41524 * __fractqqdi: Fixed-point fractional library routines. 41525 (line 489) 41526 * __fractqqdq2: Fixed-point fractional library routines. 41527 (line 471) 41528 * __fractqqha: Fixed-point fractional library routines. 41529 (line 472) 41530 * __fractqqhi: Fixed-point fractional library routines. 41531 (line 487) 41532 * __fractqqhq2: Fixed-point fractional library routines. 41533 (line 469) 41534 * __fractqqqi: Fixed-point fractional library routines. 41535 (line 486) 41536 * __fractqqsa: Fixed-point fractional library routines. 41537 (line 473) 41538 * __fractqqsf: Fixed-point fractional library routines. 41539 (line 491) 41540 * __fractqqsi: Fixed-point fractional library routines. 41541 (line 488) 41542 * __fractqqsq2: Fixed-point fractional library routines. 41543 (line 470) 41544 * __fractqqta: Fixed-point fractional library routines. 41545 (line 475) 41546 * __fractqqti: Fixed-point fractional library routines. 41547 (line 490) 41548 * __fractqquda: Fixed-point fractional library routines. 41549 (line 483) 41550 * __fractqqudq: Fixed-point fractional library routines. 41551 (line 480) 41552 * __fractqquha: Fixed-point fractional library routines. 41553 (line 481) 41554 * __fractqquhq: Fixed-point fractional library routines. 41555 (line 477) 41556 * __fractqquqq: Fixed-point fractional library routines. 41557 (line 476) 41558 * __fractqqusa: Fixed-point fractional library routines. 41559 (line 482) 41560 * __fractqqusq: Fixed-point fractional library routines. 41561 (line 478) 41562 * __fractqquta: Fixed-point fractional library routines. 41563 (line 485) 41564 * __fractsada2: Fixed-point fractional library routines. 41565 (line 596) 41566 * __fractsadf: Fixed-point fractional library routines. 41567 (line 612) 41568 * __fractsadi: Fixed-point fractional library routines. 41569 (line 609) 41570 * __fractsadq: Fixed-point fractional library routines. 41571 (line 594) 41572 * __fractsaha2: Fixed-point fractional library routines. 41573 (line 595) 41574 * __fractsahi: Fixed-point fractional library routines. 41575 (line 607) 41576 * __fractsahq: Fixed-point fractional library routines. 41577 (line 592) 41578 * __fractsaqi: Fixed-point fractional library routines. 41579 (line 606) 41580 * __fractsaqq: Fixed-point fractional library routines. 41581 (line 591) 41582 * __fractsasf: Fixed-point fractional library routines. 41583 (line 611) 41584 * __fractsasi: Fixed-point fractional library routines. 41585 (line 608) 41586 * __fractsasq: Fixed-point fractional library routines. 41587 (line 593) 41588 * __fractsata2: Fixed-point fractional library routines. 41589 (line 597) 41590 * __fractsati: Fixed-point fractional library routines. 41591 (line 610) 41592 * __fractsauda: Fixed-point fractional library routines. 41593 (line 604) 41594 * __fractsaudq: Fixed-point fractional library routines. 41595 (line 601) 41596 * __fractsauha: Fixed-point fractional library routines. 41597 (line 602) 41598 * __fractsauhq: Fixed-point fractional library routines. 41599 (line 599) 41600 * __fractsauqq: Fixed-point fractional library routines. 41601 (line 598) 41602 * __fractsausa: Fixed-point fractional library routines. 41603 (line 603) 41604 * __fractsausq: Fixed-point fractional library routines. 41605 (line 600) 41606 * __fractsauta: Fixed-point fractional library routines. 41607 (line 605) 41608 * __fractsfda: Fixed-point fractional library routines. 41609 (line 1009) 41610 * __fractsfdq: Fixed-point fractional library routines. 41611 (line 1006) 41612 * __fractsfha: Fixed-point fractional library routines. 41613 (line 1007) 41614 * __fractsfhq: Fixed-point fractional library routines. 41615 (line 1004) 41616 * __fractsfqq: Fixed-point fractional library routines. 41617 (line 1003) 41618 * __fractsfsa: Fixed-point fractional library routines. 41619 (line 1008) 41620 * __fractsfsq: Fixed-point fractional library routines. 41621 (line 1005) 41622 * __fractsfta: Fixed-point fractional library routines. 41623 (line 1010) 41624 * __fractsfuda: Fixed-point fractional library routines. 41625 (line 1017) 41626 * __fractsfudq: Fixed-point fractional library routines. 41627 (line 1014) 41628 * __fractsfuha: Fixed-point fractional library routines. 41629 (line 1015) 41630 * __fractsfuhq: Fixed-point fractional library routines. 41631 (line 1012) 41632 * __fractsfuqq: Fixed-point fractional library routines. 41633 (line 1011) 41634 * __fractsfusa: Fixed-point fractional library routines. 41635 (line 1016) 41636 * __fractsfusq: Fixed-point fractional library routines. 41637 (line 1013) 41638 * __fractsfuta: Fixed-point fractional library routines. 41639 (line 1018) 41640 * __fractsida: Fixed-point fractional library routines. 41641 (line 959) 41642 * __fractsidq: Fixed-point fractional library routines. 41643 (line 956) 41644 * __fractsiha: Fixed-point fractional library routines. 41645 (line 957) 41646 * __fractsihq: Fixed-point fractional library routines. 41647 (line 954) 41648 * __fractsiqq: Fixed-point fractional library routines. 41649 (line 953) 41650 * __fractsisa: Fixed-point fractional library routines. 41651 (line 958) 41652 * __fractsisq: Fixed-point fractional library routines. 41653 (line 955) 41654 * __fractsita: Fixed-point fractional library routines. 41655 (line 960) 41656 * __fractsiuda: Fixed-point fractional library routines. 41657 (line 967) 41658 * __fractsiudq: Fixed-point fractional library routines. 41659 (line 964) 41660 * __fractsiuha: Fixed-point fractional library routines. 41661 (line 965) 41662 * __fractsiuhq: Fixed-point fractional library routines. 41663 (line 962) 41664 * __fractsiuqq: Fixed-point fractional library routines. 41665 (line 961) 41666 * __fractsiusa: Fixed-point fractional library routines. 41667 (line 966) 41668 * __fractsiusq: Fixed-point fractional library routines. 41669 (line 963) 41670 * __fractsiuta: Fixed-point fractional library routines. 41671 (line 968) 41672 * __fractsqda: Fixed-point fractional library routines. 41673 (line 520) 41674 * __fractsqdf: Fixed-point fractional library routines. 41675 (line 538) 41676 * __fractsqdi: Fixed-point fractional library routines. 41677 (line 535) 41678 * __fractsqdq2: Fixed-point fractional library routines. 41679 (line 517) 41680 * __fractsqha: Fixed-point fractional library routines. 41681 (line 518) 41682 * __fractsqhi: Fixed-point fractional library routines. 41683 (line 533) 41684 * __fractsqhq2: Fixed-point fractional library routines. 41685 (line 516) 41686 * __fractsqqi: Fixed-point fractional library routines. 41687 (line 532) 41688 * __fractsqqq2: Fixed-point fractional library routines. 41689 (line 515) 41690 * __fractsqsa: Fixed-point fractional library routines. 41691 (line 519) 41692 * __fractsqsf: Fixed-point fractional library routines. 41693 (line 537) 41694 * __fractsqsi: Fixed-point fractional library routines. 41695 (line 534) 41696 * __fractsqta: Fixed-point fractional library routines. 41697 (line 521) 41698 * __fractsqti: Fixed-point fractional library routines. 41699 (line 536) 41700 * __fractsquda: Fixed-point fractional library routines. 41701 (line 529) 41702 * __fractsqudq: Fixed-point fractional library routines. 41703 (line 526) 41704 * __fractsquha: Fixed-point fractional library routines. 41705 (line 527) 41706 * __fractsquhq: Fixed-point fractional library routines. 41707 (line 523) 41708 * __fractsquqq: Fixed-point fractional library routines. 41709 (line 522) 41710 * __fractsqusa: Fixed-point fractional library routines. 41711 (line 528) 41712 * __fractsqusq: Fixed-point fractional library routines. 41713 (line 524) 41714 * __fractsquta: Fixed-point fractional library routines. 41715 (line 531) 41716 * __fracttada2: Fixed-point fractional library routines. 41717 (line 643) 41718 * __fracttadf: Fixed-point fractional library routines. 41719 (line 664) 41720 * __fracttadi: Fixed-point fractional library routines. 41721 (line 661) 41722 * __fracttadq: Fixed-point fractional library routines. 41723 (line 640) 41724 * __fracttaha2: Fixed-point fractional library routines. 41725 (line 641) 41726 * __fracttahi: Fixed-point fractional library routines. 41727 (line 659) 41728 * __fracttahq: Fixed-point fractional library routines. 41729 (line 638) 41730 * __fracttaqi: Fixed-point fractional library routines. 41731 (line 658) 41732 * __fracttaqq: Fixed-point fractional library routines. 41733 (line 637) 41734 * __fracttasa2: Fixed-point fractional library routines. 41735 (line 642) 41736 * __fracttasf: Fixed-point fractional library routines. 41737 (line 663) 41738 * __fracttasi: Fixed-point fractional library routines. 41739 (line 660) 41740 * __fracttasq: Fixed-point fractional library routines. 41741 (line 639) 41742 * __fracttati: Fixed-point fractional library routines. 41743 (line 662) 41744 * __fracttauda: Fixed-point fractional library routines. 41745 (line 655) 41746 * __fracttaudq: Fixed-point fractional library routines. 41747 (line 650) 41748 * __fracttauha: Fixed-point fractional library routines. 41749 (line 652) 41750 * __fracttauhq: Fixed-point fractional library routines. 41751 (line 646) 41752 * __fracttauqq: Fixed-point fractional library routines. 41753 (line 645) 41754 * __fracttausa: Fixed-point fractional library routines. 41755 (line 653) 41756 * __fracttausq: Fixed-point fractional library routines. 41757 (line 648) 41758 * __fracttauta: Fixed-point fractional library routines. 41759 (line 657) 41760 * __fracttida: Fixed-point fractional library routines. 41761 (line 991) 41762 * __fracttidq: Fixed-point fractional library routines. 41763 (line 988) 41764 * __fracttiha: Fixed-point fractional library routines. 41765 (line 989) 41766 * __fracttihq: Fixed-point fractional library routines. 41767 (line 986) 41768 * __fracttiqq: Fixed-point fractional library routines. 41769 (line 985) 41770 * __fracttisa: Fixed-point fractional library routines. 41771 (line 990) 41772 * __fracttisq: Fixed-point fractional library routines. 41773 (line 987) 41774 * __fracttita: Fixed-point fractional library routines. 41775 (line 992) 41776 * __fracttiuda: Fixed-point fractional library routines. 41777 (line 1000) 41778 * __fracttiudq: Fixed-point fractional library routines. 41779 (line 997) 41780 * __fracttiuha: Fixed-point fractional library routines. 41781 (line 998) 41782 * __fracttiuhq: Fixed-point fractional library routines. 41783 (line 994) 41784 * __fracttiuqq: Fixed-point fractional library routines. 41785 (line 993) 41786 * __fracttiusa: Fixed-point fractional library routines. 41787 (line 999) 41788 * __fracttiusq: Fixed-point fractional library routines. 41789 (line 995) 41790 * __fracttiuta: Fixed-point fractional library routines. 41791 (line 1002) 41792 * __fractudada: Fixed-point fractional library routines. 41793 (line 858) 41794 * __fractudadf: Fixed-point fractional library routines. 41795 (line 881) 41796 * __fractudadi: Fixed-point fractional library routines. 41797 (line 878) 41798 * __fractudadq: Fixed-point fractional library routines. 41799 (line 855) 41800 * __fractudaha: Fixed-point fractional library routines. 41801 (line 856) 41802 * __fractudahi: Fixed-point fractional library routines. 41803 (line 876) 41804 * __fractudahq: Fixed-point fractional library routines. 41805 (line 852) 41806 * __fractudaqi: Fixed-point fractional library routines. 41807 (line 875) 41808 * __fractudaqq: Fixed-point fractional library routines. 41809 (line 851) 41810 * __fractudasa: Fixed-point fractional library routines. 41811 (line 857) 41812 * __fractudasf: Fixed-point fractional library routines. 41813 (line 880) 41814 * __fractudasi: Fixed-point fractional library routines. 41815 (line 877) 41816 * __fractudasq: Fixed-point fractional library routines. 41817 (line 853) 41818 * __fractudata: Fixed-point fractional library routines. 41819 (line 860) 41820 * __fractudati: Fixed-point fractional library routines. 41821 (line 879) 41822 * __fractudaudq: Fixed-point fractional library routines. 41823 (line 868) 41824 * __fractudauha2: Fixed-point fractional library routines. 41825 (line 870) 41826 * __fractudauhq: Fixed-point fractional library routines. 41827 (line 864) 41828 * __fractudauqq: Fixed-point fractional library routines. 41829 (line 862) 41830 * __fractudausa2: Fixed-point fractional library routines. 41831 (line 872) 41832 * __fractudausq: Fixed-point fractional library routines. 41833 (line 866) 41834 * __fractudauta2: Fixed-point fractional library routines. 41835 (line 874) 41836 * __fractudqda: Fixed-point fractional library routines. 41837 (line 766) 41838 * __fractudqdf: Fixed-point fractional library routines. 41839 (line 791) 41840 * __fractudqdi: Fixed-point fractional library routines. 41841 (line 787) 41842 * __fractudqdq: Fixed-point fractional library routines. 41843 (line 761) 41844 * __fractudqha: Fixed-point fractional library routines. 41845 (line 763) 41846 * __fractudqhi: Fixed-point fractional library routines. 41847 (line 785) 41848 * __fractudqhq: Fixed-point fractional library routines. 41849 (line 757) 41850 * __fractudqqi: Fixed-point fractional library routines. 41851 (line 784) 41852 * __fractudqqq: Fixed-point fractional library routines. 41853 (line 756) 41854 * __fractudqsa: Fixed-point fractional library routines. 41855 (line 764) 41856 * __fractudqsf: Fixed-point fractional library routines. 41857 (line 790) 41858 * __fractudqsi: Fixed-point fractional library routines. 41859 (line 786) 41860 * __fractudqsq: Fixed-point fractional library routines. 41861 (line 759) 41862 * __fractudqta: Fixed-point fractional library routines. 41863 (line 768) 41864 * __fractudqti: Fixed-point fractional library routines. 41865 (line 789) 41866 * __fractudquda: Fixed-point fractional library routines. 41867 (line 780) 41868 * __fractudquha: Fixed-point fractional library routines. 41869 (line 776) 41870 * __fractudquhq2: Fixed-point fractional library routines. 41871 (line 772) 41872 * __fractudquqq2: Fixed-point fractional library routines. 41873 (line 770) 41874 * __fractudqusa: Fixed-point fractional library routines. 41875 (line 778) 41876 * __fractudqusq2: Fixed-point fractional library routines. 41877 (line 774) 41878 * __fractudquta: Fixed-point fractional library routines. 41879 (line 782) 41880 * __fractuhada: Fixed-point fractional library routines. 41881 (line 799) 41882 * __fractuhadf: Fixed-point fractional library routines. 41883 (line 822) 41884 * __fractuhadi: Fixed-point fractional library routines. 41885 (line 819) 41886 * __fractuhadq: Fixed-point fractional library routines. 41887 (line 796) 41888 * __fractuhaha: Fixed-point fractional library routines. 41889 (line 797) 41890 * __fractuhahi: Fixed-point fractional library routines. 41891 (line 817) 41892 * __fractuhahq: Fixed-point fractional library routines. 41893 (line 793) 41894 * __fractuhaqi: Fixed-point fractional library routines. 41895 (line 816) 41896 * __fractuhaqq: Fixed-point fractional library routines. 41897 (line 792) 41898 * __fractuhasa: Fixed-point fractional library routines. 41899 (line 798) 41900 * __fractuhasf: Fixed-point fractional library routines. 41901 (line 821) 41902 * __fractuhasi: Fixed-point fractional library routines. 41903 (line 818) 41904 * __fractuhasq: Fixed-point fractional library routines. 41905 (line 794) 41906 * __fractuhata: Fixed-point fractional library routines. 41907 (line 801) 41908 * __fractuhati: Fixed-point fractional library routines. 41909 (line 820) 41910 * __fractuhauda2: Fixed-point fractional library routines. 41911 (line 813) 41912 * __fractuhaudq: Fixed-point fractional library routines. 41913 (line 809) 41914 * __fractuhauhq: Fixed-point fractional library routines. 41915 (line 805) 41916 * __fractuhauqq: Fixed-point fractional library routines. 41917 (line 803) 41918 * __fractuhausa2: Fixed-point fractional library routines. 41919 (line 811) 41920 * __fractuhausq: Fixed-point fractional library routines. 41921 (line 807) 41922 * __fractuhauta2: Fixed-point fractional library routines. 41923 (line 815) 41924 * __fractuhqda: Fixed-point fractional library routines. 41925 (line 702) 41926 * __fractuhqdf: Fixed-point fractional library routines. 41927 (line 723) 41928 * __fractuhqdi: Fixed-point fractional library routines. 41929 (line 720) 41930 * __fractuhqdq: Fixed-point fractional library routines. 41931 (line 699) 41932 * __fractuhqha: Fixed-point fractional library routines. 41933 (line 700) 41934 * __fractuhqhi: Fixed-point fractional library routines. 41935 (line 718) 41936 * __fractuhqhq: Fixed-point fractional library routines. 41937 (line 697) 41938 * __fractuhqqi: Fixed-point fractional library routines. 41939 (line 717) 41940 * __fractuhqqq: Fixed-point fractional library routines. 41941 (line 696) 41942 * __fractuhqsa: Fixed-point fractional library routines. 41943 (line 701) 41944 * __fractuhqsf: Fixed-point fractional library routines. 41945 (line 722) 41946 * __fractuhqsi: Fixed-point fractional library routines. 41947 (line 719) 41948 * __fractuhqsq: Fixed-point fractional library routines. 41949 (line 698) 41950 * __fractuhqta: Fixed-point fractional library routines. 41951 (line 703) 41952 * __fractuhqti: Fixed-point fractional library routines. 41953 (line 721) 41954 * __fractuhquda: Fixed-point fractional library routines. 41955 (line 714) 41956 * __fractuhqudq2: Fixed-point fractional library routines. 41957 (line 709) 41958 * __fractuhquha: Fixed-point fractional library routines. 41959 (line 711) 41960 * __fractuhquqq2: Fixed-point fractional library routines. 41961 (line 705) 41962 * __fractuhqusa: Fixed-point fractional library routines. 41963 (line 712) 41964 * __fractuhqusq2: Fixed-point fractional library routines. 41965 (line 707) 41966 * __fractuhquta: Fixed-point fractional library routines. 41967 (line 716) 41968 * __fractunsdadi: Fixed-point fractional library routines. 41969 (line 1555) 41970 * __fractunsdahi: Fixed-point fractional library routines. 41971 (line 1553) 41972 * __fractunsdaqi: Fixed-point fractional library routines. 41973 (line 1552) 41974 * __fractunsdasi: Fixed-point fractional library routines. 41975 (line 1554) 41976 * __fractunsdati: Fixed-point fractional library routines. 41977 (line 1556) 41978 * __fractunsdida: Fixed-point fractional library routines. 41979 (line 1707) 41980 * __fractunsdidq: Fixed-point fractional library routines. 41981 (line 1704) 41982 * __fractunsdiha: Fixed-point fractional library routines. 41983 (line 1705) 41984 * __fractunsdihq: Fixed-point fractional library routines. 41985 (line 1702) 41986 * __fractunsdiqq: Fixed-point fractional library routines. 41987 (line 1701) 41988 * __fractunsdisa: Fixed-point fractional library routines. 41989 (line 1706) 41990 * __fractunsdisq: Fixed-point fractional library routines. 41991 (line 1703) 41992 * __fractunsdita: Fixed-point fractional library routines. 41993 (line 1708) 41994 * __fractunsdiuda: Fixed-point fractional library routines. 41995 (line 1720) 41996 * __fractunsdiudq: Fixed-point fractional library routines. 41997 (line 1715) 41998 * __fractunsdiuha: Fixed-point fractional library routines. 41999 (line 1717) 42000 * __fractunsdiuhq: Fixed-point fractional library routines. 42001 (line 1711) 42002 * __fractunsdiuqq: Fixed-point fractional library routines. 42003 (line 1710) 42004 * __fractunsdiusa: Fixed-point fractional library routines. 42005 (line 1718) 42006 * __fractunsdiusq: Fixed-point fractional library routines. 42007 (line 1713) 42008 * __fractunsdiuta: Fixed-point fractional library routines. 42009 (line 1722) 42010 * __fractunsdqdi: Fixed-point fractional library routines. 42011 (line 1539) 42012 * __fractunsdqhi: Fixed-point fractional library routines. 42013 (line 1537) 42014 * __fractunsdqqi: Fixed-point fractional library routines. 42015 (line 1536) 42016 * __fractunsdqsi: Fixed-point fractional library routines. 42017 (line 1538) 42018 * __fractunsdqti: Fixed-point fractional library routines. 42019 (line 1541) 42020 * __fractunshadi: Fixed-point fractional library routines. 42021 (line 1545) 42022 * __fractunshahi: Fixed-point fractional library routines. 42023 (line 1543) 42024 * __fractunshaqi: Fixed-point fractional library routines. 42025 (line 1542) 42026 * __fractunshasi: Fixed-point fractional library routines. 42027 (line 1544) 42028 * __fractunshati: Fixed-point fractional library routines. 42029 (line 1546) 42030 * __fractunshida: Fixed-point fractional library routines. 42031 (line 1663) 42032 * __fractunshidq: Fixed-point fractional library routines. 42033 (line 1660) 42034 * __fractunshiha: Fixed-point fractional library routines. 42035 (line 1661) 42036 * __fractunshihq: Fixed-point fractional library routines. 42037 (line 1658) 42038 * __fractunshiqq: Fixed-point fractional library routines. 42039 (line 1657) 42040 * __fractunshisa: Fixed-point fractional library routines. 42041 (line 1662) 42042 * __fractunshisq: Fixed-point fractional library routines. 42043 (line 1659) 42044 * __fractunshita: Fixed-point fractional library routines. 42045 (line 1664) 42046 * __fractunshiuda: Fixed-point fractional library routines. 42047 (line 1676) 42048 * __fractunshiudq: Fixed-point fractional library routines. 42049 (line 1671) 42050 * __fractunshiuha: Fixed-point fractional library routines. 42051 (line 1673) 42052 * __fractunshiuhq: Fixed-point fractional library routines. 42053 (line 1667) 42054 * __fractunshiuqq: Fixed-point fractional library routines. 42055 (line 1666) 42056 * __fractunshiusa: Fixed-point fractional library routines. 42057 (line 1674) 42058 * __fractunshiusq: Fixed-point fractional library routines. 42059 (line 1669) 42060 * __fractunshiuta: Fixed-point fractional library routines. 42061 (line 1678) 42062 * __fractunshqdi: Fixed-point fractional library routines. 42063 (line 1529) 42064 * __fractunshqhi: Fixed-point fractional library routines. 42065 (line 1527) 42066 * __fractunshqqi: Fixed-point fractional library routines. 42067 (line 1526) 42068 * __fractunshqsi: Fixed-point fractional library routines. 42069 (line 1528) 42070 * __fractunshqti: Fixed-point fractional library routines. 42071 (line 1530) 42072 * __fractunsqida: Fixed-point fractional library routines. 42073 (line 1641) 42074 * __fractunsqidq: Fixed-point fractional library routines. 42075 (line 1638) 42076 * __fractunsqiha: Fixed-point fractional library routines. 42077 (line 1639) 42078 * __fractunsqihq: Fixed-point fractional library routines. 42079 (line 1636) 42080 * __fractunsqiqq: Fixed-point fractional library routines. 42081 (line 1635) 42082 * __fractunsqisa: Fixed-point fractional library routines. 42083 (line 1640) 42084 * __fractunsqisq: Fixed-point fractional library routines. 42085 (line 1637) 42086 * __fractunsqita: Fixed-point fractional library routines. 42087 (line 1642) 42088 * __fractunsqiuda: Fixed-point fractional library routines. 42089 (line 1654) 42090 * __fractunsqiudq: Fixed-point fractional library routines. 42091 (line 1649) 42092 * __fractunsqiuha: Fixed-point fractional library routines. 42093 (line 1651) 42094 * __fractunsqiuhq: Fixed-point fractional library routines. 42095 (line 1645) 42096 * __fractunsqiuqq: Fixed-point fractional library routines. 42097 (line 1644) 42098 * __fractunsqiusa: Fixed-point fractional library routines. 42099 (line 1652) 42100 * __fractunsqiusq: Fixed-point fractional library routines. 42101 (line 1647) 42102 * __fractunsqiuta: Fixed-point fractional library routines. 42103 (line 1656) 42104 * __fractunsqqdi: Fixed-point fractional library routines. 42105 (line 1524) 42106 * __fractunsqqhi: Fixed-point fractional library routines. 42107 (line 1522) 42108 * __fractunsqqqi: Fixed-point fractional library routines. 42109 (line 1521) 42110 * __fractunsqqsi: Fixed-point fractional library routines. 42111 (line 1523) 42112 * __fractunsqqti: Fixed-point fractional library routines. 42113 (line 1525) 42114 * __fractunssadi: Fixed-point fractional library routines. 42115 (line 1550) 42116 * __fractunssahi: Fixed-point fractional library routines. 42117 (line 1548) 42118 * __fractunssaqi: Fixed-point fractional library routines. 42119 (line 1547) 42120 * __fractunssasi: Fixed-point fractional library routines. 42121 (line 1549) 42122 * __fractunssati: Fixed-point fractional library routines. 42123 (line 1551) 42124 * __fractunssida: Fixed-point fractional library routines. 42125 (line 1685) 42126 * __fractunssidq: Fixed-point fractional library routines. 42127 (line 1682) 42128 * __fractunssiha: Fixed-point fractional library routines. 42129 (line 1683) 42130 * __fractunssihq: Fixed-point fractional library routines. 42131 (line 1680) 42132 * __fractunssiqq: Fixed-point fractional library routines. 42133 (line 1679) 42134 * __fractunssisa: Fixed-point fractional library routines. 42135 (line 1684) 42136 * __fractunssisq: Fixed-point fractional library routines. 42137 (line 1681) 42138 * __fractunssita: Fixed-point fractional library routines. 42139 (line 1686) 42140 * __fractunssiuda: Fixed-point fractional library routines. 42141 (line 1698) 42142 * __fractunssiudq: Fixed-point fractional library routines. 42143 (line 1693) 42144 * __fractunssiuha: Fixed-point fractional library routines. 42145 (line 1695) 42146 * __fractunssiuhq: Fixed-point fractional library routines. 42147 (line 1689) 42148 * __fractunssiuqq: Fixed-point fractional library routines. 42149 (line 1688) 42150 * __fractunssiusa: Fixed-point fractional library routines. 42151 (line 1696) 42152 * __fractunssiusq: Fixed-point fractional library routines. 42153 (line 1691) 42154 * __fractunssiuta: Fixed-point fractional library routines. 42155 (line 1700) 42156 * __fractunssqdi: Fixed-point fractional library routines. 42157 (line 1534) 42158 * __fractunssqhi: Fixed-point fractional library routines. 42159 (line 1532) 42160 * __fractunssqqi: Fixed-point fractional library routines. 42161 (line 1531) 42162 * __fractunssqsi: Fixed-point fractional library routines. 42163 (line 1533) 42164 * __fractunssqti: Fixed-point fractional library routines. 42165 (line 1535) 42166 * __fractunstadi: Fixed-point fractional library routines. 42167 (line 1560) 42168 * __fractunstahi: Fixed-point fractional library routines. 42169 (line 1558) 42170 * __fractunstaqi: Fixed-point fractional library routines. 42171 (line 1557) 42172 * __fractunstasi: Fixed-point fractional library routines. 42173 (line 1559) 42174 * __fractunstati: Fixed-point fractional library routines. 42175 (line 1562) 42176 * __fractunstida: Fixed-point fractional library routines. 42177 (line 1730) 42178 * __fractunstidq: Fixed-point fractional library routines. 42179 (line 1727) 42180 * __fractunstiha: Fixed-point fractional library routines. 42181 (line 1728) 42182 * __fractunstihq: Fixed-point fractional library routines. 42183 (line 1724) 42184 * __fractunstiqq: Fixed-point fractional library routines. 42185 (line 1723) 42186 * __fractunstisa: Fixed-point fractional library routines. 42187 (line 1729) 42188 * __fractunstisq: Fixed-point fractional library routines. 42189 (line 1725) 42190 * __fractunstita: Fixed-point fractional library routines. 42191 (line 1732) 42192 * __fractunstiuda: Fixed-point fractional library routines. 42193 (line 1746) 42194 * __fractunstiudq: Fixed-point fractional library routines. 42195 (line 1740) 42196 * __fractunstiuha: Fixed-point fractional library routines. 42197 (line 1742) 42198 * __fractunstiuhq: Fixed-point fractional library routines. 42199 (line 1736) 42200 * __fractunstiuqq: Fixed-point fractional library routines. 42201 (line 1734) 42202 * __fractunstiusa: Fixed-point fractional library routines. 42203 (line 1744) 42204 * __fractunstiusq: Fixed-point fractional library routines. 42205 (line 1738) 42206 * __fractunstiuta: Fixed-point fractional library routines. 42207 (line 1748) 42208 * __fractunsudadi: Fixed-point fractional library routines. 42209 (line 1622) 42210 * __fractunsudahi: Fixed-point fractional library routines. 42211 (line 1618) 42212 * __fractunsudaqi: Fixed-point fractional library routines. 42213 (line 1616) 42214 * __fractunsudasi: Fixed-point fractional library routines. 42215 (line 1620) 42216 * __fractunsudati: Fixed-point fractional library routines. 42217 (line 1624) 42218 * __fractunsudqdi: Fixed-point fractional library routines. 42219 (line 1596) 42220 * __fractunsudqhi: Fixed-point fractional library routines. 42221 (line 1592) 42222 * __fractunsudqqi: Fixed-point fractional library routines. 42223 (line 1590) 42224 * __fractunsudqsi: Fixed-point fractional library routines. 42225 (line 1594) 42226 * __fractunsudqti: Fixed-point fractional library routines. 42227 (line 1598) 42228 * __fractunsuhadi: Fixed-point fractional library routines. 42229 (line 1606) 42230 * __fractunsuhahi: Fixed-point fractional library routines. 42231 (line 1602) 42232 * __fractunsuhaqi: Fixed-point fractional library routines. 42233 (line 1600) 42234 * __fractunsuhasi: Fixed-point fractional library routines. 42235 (line 1604) 42236 * __fractunsuhati: Fixed-point fractional library routines. 42237 (line 1608) 42238 * __fractunsuhqdi: Fixed-point fractional library routines. 42239 (line 1576) 42240 * __fractunsuhqhi: Fixed-point fractional library routines. 42241 (line 1574) 42242 * __fractunsuhqqi: Fixed-point fractional library routines. 42243 (line 1573) 42244 * __fractunsuhqsi: Fixed-point fractional library routines. 42245 (line 1575) 42246 * __fractunsuhqti: Fixed-point fractional library routines. 42247 (line 1578) 42248 * __fractunsuqqdi: Fixed-point fractional library routines. 42249 (line 1570) 42250 * __fractunsuqqhi: Fixed-point fractional library routines. 42251 (line 1566) 42252 * __fractunsuqqqi: Fixed-point fractional library routines. 42253 (line 1564) 42254 * __fractunsuqqsi: Fixed-point fractional library routines. 42255 (line 1568) 42256 * __fractunsuqqti: Fixed-point fractional library routines. 42257 (line 1572) 42258 * __fractunsusadi: Fixed-point fractional library routines. 42259 (line 1612) 42260 * __fractunsusahi: Fixed-point fractional library routines. 42261 (line 1610) 42262 * __fractunsusaqi: Fixed-point fractional library routines. 42263 (line 1609) 42264 * __fractunsusasi: Fixed-point fractional library routines. 42265 (line 1611) 42266 * __fractunsusati: Fixed-point fractional library routines. 42267 (line 1614) 42268 * __fractunsusqdi: Fixed-point fractional library routines. 42269 (line 1586) 42270 * __fractunsusqhi: Fixed-point fractional library routines. 42271 (line 1582) 42272 * __fractunsusqqi: Fixed-point fractional library routines. 42273 (line 1580) 42274 * __fractunsusqsi: Fixed-point fractional library routines. 42275 (line 1584) 42276 * __fractunsusqti: Fixed-point fractional library routines. 42277 (line 1588) 42278 * __fractunsutadi: Fixed-point fractional library routines. 42279 (line 1632) 42280 * __fractunsutahi: Fixed-point fractional library routines. 42281 (line 1628) 42282 * __fractunsutaqi: Fixed-point fractional library routines. 42283 (line 1626) 42284 * __fractunsutasi: Fixed-point fractional library routines. 42285 (line 1630) 42286 * __fractunsutati: Fixed-point fractional library routines. 42287 (line 1634) 42288 * __fractuqqda: Fixed-point fractional library routines. 42289 (line 672) 42290 * __fractuqqdf: Fixed-point fractional library routines. 42291 (line 695) 42292 * __fractuqqdi: Fixed-point fractional library routines. 42293 (line 692) 42294 * __fractuqqdq: Fixed-point fractional library routines. 42295 (line 669) 42296 * __fractuqqha: Fixed-point fractional library routines. 42297 (line 670) 42298 * __fractuqqhi: Fixed-point fractional library routines. 42299 (line 690) 42300 * __fractuqqhq: Fixed-point fractional library routines. 42301 (line 666) 42302 * __fractuqqqi: Fixed-point fractional library routines. 42303 (line 689) 42304 * __fractuqqqq: Fixed-point fractional library routines. 42305 (line 665) 42306 * __fractuqqsa: Fixed-point fractional library routines. 42307 (line 671) 42308 * __fractuqqsf: Fixed-point fractional library routines. 42309 (line 694) 42310 * __fractuqqsi: Fixed-point fractional library routines. 42311 (line 691) 42312 * __fractuqqsq: Fixed-point fractional library routines. 42313 (line 667) 42314 * __fractuqqta: Fixed-point fractional library routines. 42315 (line 674) 42316 * __fractuqqti: Fixed-point fractional library routines. 42317 (line 693) 42318 * __fractuqquda: Fixed-point fractional library routines. 42319 (line 686) 42320 * __fractuqqudq2: Fixed-point fractional library routines. 42321 (line 680) 42322 * __fractuqquha: Fixed-point fractional library routines. 42323 (line 682) 42324 * __fractuqquhq2: Fixed-point fractional library routines. 42325 (line 676) 42326 * __fractuqqusa: Fixed-point fractional library routines. 42327 (line 684) 42328 * __fractuqqusq2: Fixed-point fractional library routines. 42329 (line 678) 42330 * __fractuqquta: Fixed-point fractional library routines. 42331 (line 688) 42332 * __fractusada: Fixed-point fractional library routines. 42333 (line 829) 42334 * __fractusadf: Fixed-point fractional library routines. 42335 (line 850) 42336 * __fractusadi: Fixed-point fractional library routines. 42337 (line 847) 42338 * __fractusadq: Fixed-point fractional library routines. 42339 (line 826) 42340 * __fractusaha: Fixed-point fractional library routines. 42341 (line 827) 42342 * __fractusahi: Fixed-point fractional library routines. 42343 (line 845) 42344 * __fractusahq: Fixed-point fractional library routines. 42345 (line 824) 42346 * __fractusaqi: Fixed-point fractional library routines. 42347 (line 844) 42348 * __fractusaqq: Fixed-point fractional library routines. 42349 (line 823) 42350 * __fractusasa: Fixed-point fractional library routines. 42351 (line 828) 42352 * __fractusasf: Fixed-point fractional library routines. 42353 (line 849) 42354 * __fractusasi: Fixed-point fractional library routines. 42355 (line 846) 42356 * __fractusasq: Fixed-point fractional library routines. 42357 (line 825) 42358 * __fractusata: Fixed-point fractional library routines. 42359 (line 830) 42360 * __fractusati: Fixed-point fractional library routines. 42361 (line 848) 42362 * __fractusauda2: Fixed-point fractional library routines. 42363 (line 841) 42364 * __fractusaudq: Fixed-point fractional library routines. 42365 (line 837) 42366 * __fractusauha2: Fixed-point fractional library routines. 42367 (line 839) 42368 * __fractusauhq: Fixed-point fractional library routines. 42369 (line 833) 42370 * __fractusauqq: Fixed-point fractional library routines. 42371 (line 832) 42372 * __fractusausq: Fixed-point fractional library routines. 42373 (line 835) 42374 * __fractusauta2: Fixed-point fractional library routines. 42375 (line 843) 42376 * __fractusqda: Fixed-point fractional library routines. 42377 (line 731) 42378 * __fractusqdf: Fixed-point fractional library routines. 42379 (line 754) 42380 * __fractusqdi: Fixed-point fractional library routines. 42381 (line 751) 42382 * __fractusqdq: Fixed-point fractional library routines. 42383 (line 728) 42384 * __fractusqha: Fixed-point fractional library routines. 42385 (line 729) 42386 * __fractusqhi: Fixed-point fractional library routines. 42387 (line 749) 42388 * __fractusqhq: Fixed-point fractional library routines. 42389 (line 725) 42390 * __fractusqqi: Fixed-point fractional library routines. 42391 (line 748) 42392 * __fractusqqq: Fixed-point fractional library routines. 42393 (line 724) 42394 * __fractusqsa: Fixed-point fractional library routines. 42395 (line 730) 42396 * __fractusqsf: Fixed-point fractional library routines. 42397 (line 753) 42398 * __fractusqsi: Fixed-point fractional library routines. 42399 (line 750) 42400 * __fractusqsq: Fixed-point fractional library routines. 42401 (line 726) 42402 * __fractusqta: Fixed-point fractional library routines. 42403 (line 733) 42404 * __fractusqti: Fixed-point fractional library routines. 42405 (line 752) 42406 * __fractusquda: Fixed-point fractional library routines. 42407 (line 745) 42408 * __fractusqudq2: Fixed-point fractional library routines. 42409 (line 739) 42410 * __fractusquha: Fixed-point fractional library routines. 42411 (line 741) 42412 * __fractusquhq2: Fixed-point fractional library routines. 42413 (line 737) 42414 * __fractusquqq2: Fixed-point fractional library routines. 42415 (line 735) 42416 * __fractusqusa: Fixed-point fractional library routines. 42417 (line 743) 42418 * __fractusquta: Fixed-point fractional library routines. 42419 (line 747) 42420 * __fractutada: Fixed-point fractional library routines. 42421 (line 893) 42422 * __fractutadf: Fixed-point fractional library routines. 42423 (line 918) 42424 * __fractutadi: Fixed-point fractional library routines. 42425 (line 914) 42426 * __fractutadq: Fixed-point fractional library routines. 42427 (line 888) 42428 * __fractutaha: Fixed-point fractional library routines. 42429 (line 890) 42430 * __fractutahi: Fixed-point fractional library routines. 42431 (line 912) 42432 * __fractutahq: Fixed-point fractional library routines. 42433 (line 884) 42434 * __fractutaqi: Fixed-point fractional library routines. 42435 (line 911) 42436 * __fractutaqq: Fixed-point fractional library routines. 42437 (line 883) 42438 * __fractutasa: Fixed-point fractional library routines. 42439 (line 891) 42440 * __fractutasf: Fixed-point fractional library routines. 42441 (line 917) 42442 * __fractutasi: Fixed-point fractional library routines. 42443 (line 913) 42444 * __fractutasq: Fixed-point fractional library routines. 42445 (line 886) 42446 * __fractutata: Fixed-point fractional library routines. 42447 (line 895) 42448 * __fractutati: Fixed-point fractional library routines. 42449 (line 916) 42450 * __fractutauda2: Fixed-point fractional library routines. 42451 (line 909) 42452 * __fractutaudq: Fixed-point fractional library routines. 42453 (line 903) 42454 * __fractutauha2: Fixed-point fractional library routines. 42455 (line 905) 42456 * __fractutauhq: Fixed-point fractional library routines. 42457 (line 899) 42458 * __fractutauqq: Fixed-point fractional library routines. 42459 (line 897) 42460 * __fractutausa2: Fixed-point fractional library routines. 42461 (line 907) 42462 * __fractutausq: Fixed-point fractional library routines. 42463 (line 901) 42464 * __gedf2: Soft float library routines. 42465 (line 206) 42466 * __gesf2: Soft float library routines. 42467 (line 205) 42468 * __getf2: Soft float library routines. 42469 (line 207) 42470 * __gtdf2: Soft float library routines. 42471 (line 224) 42472 * __gtsf2: Soft float library routines. 42473 (line 223) 42474 * __gttf2: Soft float library routines. 42475 (line 225) 42476 * __ledf2: Soft float library routines. 42477 (line 218) 42478 * __lesf2: Soft float library routines. 42479 (line 217) 42480 * __letf2: Soft float library routines. 42481 (line 219) 42482 * __lshrdi3: Integer library routines. 42483 (line 31) 42484 * __lshrsi3: Integer library routines. 42485 (line 30) 42486 * __lshrti3: Integer library routines. 42487 (line 32) 42488 * __lshruda3: Fixed-point fractional library routines. 42489 (line 390) 42490 * __lshrudq3: Fixed-point fractional library routines. 42491 (line 384) 42492 * __lshruha3: Fixed-point fractional library routines. 42493 (line 386) 42494 * __lshruhq3: Fixed-point fractional library routines. 42495 (line 380) 42496 * __lshruqq3: Fixed-point fractional library routines. 42497 (line 378) 42498 * __lshrusa3: Fixed-point fractional library routines. 42499 (line 388) 42500 * __lshrusq3: Fixed-point fractional library routines. 42501 (line 382) 42502 * __lshruta3: Fixed-point fractional library routines. 42503 (line 392) 42504 * __ltdf2: Soft float library routines. 42505 (line 212) 42506 * __ltsf2: Soft float library routines. 42507 (line 211) 42508 * __lttf2: Soft float library routines. 42509 (line 213) 42510 * __main: Collect2. (line 15) 42511 * __moddi3: Integer library routines. 42512 (line 37) 42513 * __modsi3: Integer library routines. 42514 (line 36) 42515 * __modti3: Integer library routines. 42516 (line 38) 42517 * __morestack_current_segment: Miscellaneous routines. 42518 (line 46) 42519 * __morestack_initial_sp: Miscellaneous routines. 42520 (line 47) 42521 * __morestack_segments: Miscellaneous routines. 42522 (line 45) 42523 * __mulda3: Fixed-point fractional library routines. 42524 (line 171) 42525 * __muldc3: Soft float library routines. 42526 (line 241) 42527 * __muldf3: Soft float library routines. 42528 (line 40) 42529 * __muldi3: Integer library routines. 42530 (line 43) 42531 * __muldq3: Fixed-point fractional library routines. 42532 (line 159) 42533 * __mulha3: Fixed-point fractional library routines. 42534 (line 169) 42535 * __mulhq3: Fixed-point fractional library routines. 42536 (line 156) 42537 * __mulqq3: Fixed-point fractional library routines. 42538 (line 155) 42539 * __mulsa3: Fixed-point fractional library routines. 42540 (line 170) 42541 * __mulsc3: Soft float library routines. 42542 (line 239) 42543 * __mulsf3: Soft float library routines. 42544 (line 39) 42545 * __mulsi3: Integer library routines. 42546 (line 42) 42547 * __mulsq3: Fixed-point fractional library routines. 42548 (line 157) 42549 * __multa3: Fixed-point fractional library routines. 42550 (line 173) 42551 * __multc3: Soft float library routines. 42552 (line 243) 42553 * __multf3: Soft float library routines. 42554 (line 42) 42555 * __multi3: Integer library routines. 42556 (line 44) 42557 * __muluda3: Fixed-point fractional library routines. 42558 (line 179) 42559 * __muludq3: Fixed-point fractional library routines. 42560 (line 167) 42561 * __muluha3: Fixed-point fractional library routines. 42562 (line 175) 42563 * __muluhq3: Fixed-point fractional library routines. 42564 (line 163) 42565 * __muluqq3: Fixed-point fractional library routines. 42566 (line 161) 42567 * __mulusa3: Fixed-point fractional library routines. 42568 (line 177) 42569 * __mulusq3: Fixed-point fractional library routines. 42570 (line 165) 42571 * __muluta3: Fixed-point fractional library routines. 42572 (line 181) 42573 * __mulvdi3: Integer library routines. 42574 (line 115) 42575 * __mulvsi3: Integer library routines. 42576 (line 114) 42577 * __mulxc3: Soft float library routines. 42578 (line 245) 42579 * __mulxf3: Soft float library routines. 42580 (line 44) 42581 * __nedf2: Soft float library routines. 42582 (line 200) 42583 * __negda2: Fixed-point fractional library routines. 42584 (line 299) 42585 * __negdf2: Soft float library routines. 42586 (line 56) 42587 * __negdi2: Integer library routines. 42588 (line 47) 42589 * __negdq2: Fixed-point fractional library routines. 42590 (line 289) 42591 * __negha2: Fixed-point fractional library routines. 42592 (line 297) 42593 * __neghq2: Fixed-point fractional library routines. 42594 (line 287) 42595 * __negqq2: Fixed-point fractional library routines. 42596 (line 286) 42597 * __negsa2: Fixed-point fractional library routines. 42598 (line 298) 42599 * __negsf2: Soft float library routines. 42600 (line 55) 42601 * __negsq2: Fixed-point fractional library routines. 42602 (line 288) 42603 * __negta2: Fixed-point fractional library routines. 42604 (line 300) 42605 * __negtf2: Soft float library routines. 42606 (line 57) 42607 * __negti2: Integer library routines. 42608 (line 48) 42609 * __neguda2: Fixed-point fractional library routines. 42610 (line 305) 42611 * __negudq2: Fixed-point fractional library routines. 42612 (line 296) 42613 * __neguha2: Fixed-point fractional library routines. 42614 (line 302) 42615 * __neguhq2: Fixed-point fractional library routines. 42616 (line 292) 42617 * __neguqq2: Fixed-point fractional library routines. 42618 (line 291) 42619 * __negusa2: Fixed-point fractional library routines. 42620 (line 303) 42621 * __negusq2: Fixed-point fractional library routines. 42622 (line 294) 42623 * __neguta2: Fixed-point fractional library routines. 42624 (line 307) 42625 * __negvdi2: Integer library routines. 42626 (line 119) 42627 * __negvsi2: Integer library routines. 42628 (line 118) 42629 * __negxf2: Soft float library routines. 42630 (line 58) 42631 * __nesf2: Soft float library routines. 42632 (line 199) 42633 * __netf2: Soft float library routines. 42634 (line 201) 42635 * __paritydi2: Integer library routines. 42636 (line 151) 42637 * __paritysi2: Integer library routines. 42638 (line 150) 42639 * __parityti2: Integer library routines. 42640 (line 152) 42641 * __popcountdi2: Integer library routines. 42642 (line 157) 42643 * __popcountsi2: Integer library routines. 42644 (line 156) 42645 * __popcountti2: Integer library routines. 42646 (line 158) 42647 * __powidf2: Soft float library routines. 42648 (line 233) 42649 * __powisf2: Soft float library routines. 42650 (line 232) 42651 * __powitf2: Soft float library routines. 42652 (line 234) 42653 * __powixf2: Soft float library routines. 42654 (line 235) 42655 * __satfractdadq: Fixed-point fractional library routines. 42656 (line 1153) 42657 * __satfractdaha2: Fixed-point fractional library routines. 42658 (line 1154) 42659 * __satfractdahq: Fixed-point fractional library routines. 42660 (line 1151) 42661 * __satfractdaqq: Fixed-point fractional library routines. 42662 (line 1150) 42663 * __satfractdasa2: Fixed-point fractional library routines. 42664 (line 1155) 42665 * __satfractdasq: Fixed-point fractional library routines. 42666 (line 1152) 42667 * __satfractdata2: Fixed-point fractional library routines. 42668 (line 1156) 42669 * __satfractdauda: Fixed-point fractional library routines. 42670 (line 1166) 42671 * __satfractdaudq: Fixed-point fractional library routines. 42672 (line 1162) 42673 * __satfractdauha: Fixed-point fractional library routines. 42674 (line 1164) 42675 * __satfractdauhq: Fixed-point fractional library routines. 42676 (line 1159) 42677 * __satfractdauqq: Fixed-point fractional library routines. 42678 (line 1158) 42679 * __satfractdausa: Fixed-point fractional library routines. 42680 (line 1165) 42681 * __satfractdausq: Fixed-point fractional library routines. 42682 (line 1160) 42683 * __satfractdauta: Fixed-point fractional library routines. 42684 (line 1168) 42685 * __satfractdfda: Fixed-point fractional library routines. 42686 (line 1506) 42687 * __satfractdfdq: Fixed-point fractional library routines. 42688 (line 1503) 42689 * __satfractdfha: Fixed-point fractional library routines. 42690 (line 1504) 42691 * __satfractdfhq: Fixed-point fractional library routines. 42692 (line 1501) 42693 * __satfractdfqq: Fixed-point fractional library routines. 42694 (line 1500) 42695 * __satfractdfsa: Fixed-point fractional library routines. 42696 (line 1505) 42697 * __satfractdfsq: Fixed-point fractional library routines. 42698 (line 1502) 42699 * __satfractdfta: Fixed-point fractional library routines. 42700 (line 1507) 42701 * __satfractdfuda: Fixed-point fractional library routines. 42702 (line 1515) 42703 * __satfractdfudq: Fixed-point fractional library routines. 42704 (line 1512) 42705 * __satfractdfuha: Fixed-point fractional library routines. 42706 (line 1513) 42707 * __satfractdfuhq: Fixed-point fractional library routines. 42708 (line 1509) 42709 * __satfractdfuqq: Fixed-point fractional library routines. 42710 (line 1508) 42711 * __satfractdfusa: Fixed-point fractional library routines. 42712 (line 1514) 42713 * __satfractdfusq: Fixed-point fractional library routines. 42714 (line 1510) 42715 * __satfractdfuta: Fixed-point fractional library routines. 42716 (line 1517) 42717 * __satfractdida: Fixed-point fractional library routines. 42718 (line 1456) 42719 * __satfractdidq: Fixed-point fractional library routines. 42720 (line 1453) 42721 * __satfractdiha: Fixed-point fractional library routines. 42722 (line 1454) 42723 * __satfractdihq: Fixed-point fractional library routines. 42724 (line 1451) 42725 * __satfractdiqq: Fixed-point fractional library routines. 42726 (line 1450) 42727 * __satfractdisa: Fixed-point fractional library routines. 42728 (line 1455) 42729 * __satfractdisq: Fixed-point fractional library routines. 42730 (line 1452) 42731 * __satfractdita: Fixed-point fractional library routines. 42732 (line 1457) 42733 * __satfractdiuda: Fixed-point fractional library routines. 42734 (line 1464) 42735 * __satfractdiudq: Fixed-point fractional library routines. 42736 (line 1461) 42737 * __satfractdiuha: Fixed-point fractional library routines. 42738 (line 1462) 42739 * __satfractdiuhq: Fixed-point fractional library routines. 42740 (line 1459) 42741 * __satfractdiuqq: Fixed-point fractional library routines. 42742 (line 1458) 42743 * __satfractdiusa: Fixed-point fractional library routines. 42744 (line 1463) 42745 * __satfractdiusq: Fixed-point fractional library routines. 42746 (line 1460) 42747 * __satfractdiuta: Fixed-point fractional library routines. 42748 (line 1465) 42749 * __satfractdqda: Fixed-point fractional library routines. 42750 (line 1098) 42751 * __satfractdqha: Fixed-point fractional library routines. 42752 (line 1096) 42753 * __satfractdqhq2: Fixed-point fractional library routines. 42754 (line 1094) 42755 * __satfractdqqq2: Fixed-point fractional library routines. 42756 (line 1093) 42757 * __satfractdqsa: Fixed-point fractional library routines. 42758 (line 1097) 42759 * __satfractdqsq2: Fixed-point fractional library routines. 42760 (line 1095) 42761 * __satfractdqta: Fixed-point fractional library routines. 42762 (line 1099) 42763 * __satfractdquda: Fixed-point fractional library routines. 42764 (line 1111) 42765 * __satfractdqudq: Fixed-point fractional library routines. 42766 (line 1106) 42767 * __satfractdquha: Fixed-point fractional library routines. 42768 (line 1108) 42769 * __satfractdquhq: Fixed-point fractional library routines. 42770 (line 1102) 42771 * __satfractdquqq: Fixed-point fractional library routines. 42772 (line 1101) 42773 * __satfractdqusa: Fixed-point fractional library routines. 42774 (line 1109) 42775 * __satfractdqusq: Fixed-point fractional library routines. 42776 (line 1104) 42777 * __satfractdquta: Fixed-point fractional library routines. 42778 (line 1113) 42779 * __satfracthada2: Fixed-point fractional library routines. 42780 (line 1119) 42781 * __satfracthadq: Fixed-point fractional library routines. 42782 (line 1117) 42783 * __satfracthahq: Fixed-point fractional library routines. 42784 (line 1115) 42785 * __satfracthaqq: Fixed-point fractional library routines. 42786 (line 1114) 42787 * __satfracthasa2: Fixed-point fractional library routines. 42788 (line 1118) 42789 * __satfracthasq: Fixed-point fractional library routines. 42790 (line 1116) 42791 * __satfracthata2: Fixed-point fractional library routines. 42792 (line 1120) 42793 * __satfracthauda: Fixed-point fractional library routines. 42794 (line 1132) 42795 * __satfracthaudq: Fixed-point fractional library routines. 42796 (line 1127) 42797 * __satfracthauha: Fixed-point fractional library routines. 42798 (line 1129) 42799 * __satfracthauhq: Fixed-point fractional library routines. 42800 (line 1123) 42801 * __satfracthauqq: Fixed-point fractional library routines. 42802 (line 1122) 42803 * __satfracthausa: Fixed-point fractional library routines. 42804 (line 1130) 42805 * __satfracthausq: Fixed-point fractional library routines. 42806 (line 1125) 42807 * __satfracthauta: Fixed-point fractional library routines. 42808 (line 1134) 42809 * __satfracthida: Fixed-point fractional library routines. 42810 (line 1424) 42811 * __satfracthidq: Fixed-point fractional library routines. 42812 (line 1421) 42813 * __satfracthiha: Fixed-point fractional library routines. 42814 (line 1422) 42815 * __satfracthihq: Fixed-point fractional library routines. 42816 (line 1419) 42817 * __satfracthiqq: Fixed-point fractional library routines. 42818 (line 1418) 42819 * __satfracthisa: Fixed-point fractional library routines. 42820 (line 1423) 42821 * __satfracthisq: Fixed-point fractional library routines. 42822 (line 1420) 42823 * __satfracthita: Fixed-point fractional library routines. 42824 (line 1425) 42825 * __satfracthiuda: Fixed-point fractional library routines. 42826 (line 1432) 42827 * __satfracthiudq: Fixed-point fractional library routines. 42828 (line 1429) 42829 * __satfracthiuha: Fixed-point fractional library routines. 42830 (line 1430) 42831 * __satfracthiuhq: Fixed-point fractional library routines. 42832 (line 1427) 42833 * __satfracthiuqq: Fixed-point fractional library routines. 42834 (line 1426) 42835 * __satfracthiusa: Fixed-point fractional library routines. 42836 (line 1431) 42837 * __satfracthiusq: Fixed-point fractional library routines. 42838 (line 1428) 42839 * __satfracthiuta: Fixed-point fractional library routines. 42840 (line 1433) 42841 * __satfracthqda: Fixed-point fractional library routines. 42842 (line 1064) 42843 * __satfracthqdq2: Fixed-point fractional library routines. 42844 (line 1061) 42845 * __satfracthqha: Fixed-point fractional library routines. 42846 (line 1062) 42847 * __satfracthqqq2: Fixed-point fractional library routines. 42848 (line 1059) 42849 * __satfracthqsa: Fixed-point fractional library routines. 42850 (line 1063) 42851 * __satfracthqsq2: Fixed-point fractional library routines. 42852 (line 1060) 42853 * __satfracthqta: Fixed-point fractional library routines. 42854 (line 1065) 42855 * __satfracthquda: Fixed-point fractional library routines. 42856 (line 1072) 42857 * __satfracthqudq: Fixed-point fractional library routines. 42858 (line 1069) 42859 * __satfracthquha: Fixed-point fractional library routines. 42860 (line 1070) 42861 * __satfracthquhq: Fixed-point fractional library routines. 42862 (line 1067) 42863 * __satfracthquqq: Fixed-point fractional library routines. 42864 (line 1066) 42865 * __satfracthqusa: Fixed-point fractional library routines. 42866 (line 1071) 42867 * __satfracthqusq: Fixed-point fractional library routines. 42868 (line 1068) 42869 * __satfracthquta: Fixed-point fractional library routines. 42870 (line 1073) 42871 * __satfractqida: Fixed-point fractional library routines. 42872 (line 1402) 42873 * __satfractqidq: Fixed-point fractional library routines. 42874 (line 1399) 42875 * __satfractqiha: Fixed-point fractional library routines. 42876 (line 1400) 42877 * __satfractqihq: Fixed-point fractional library routines. 42878 (line 1397) 42879 * __satfractqiqq: Fixed-point fractional library routines. 42880 (line 1396) 42881 * __satfractqisa: Fixed-point fractional library routines. 42882 (line 1401) 42883 * __satfractqisq: Fixed-point fractional library routines. 42884 (line 1398) 42885 * __satfractqita: Fixed-point fractional library routines. 42886 (line 1403) 42887 * __satfractqiuda: Fixed-point fractional library routines. 42888 (line 1415) 42889 * __satfractqiudq: Fixed-point fractional library routines. 42890 (line 1410) 42891 * __satfractqiuha: Fixed-point fractional library routines. 42892 (line 1412) 42893 * __satfractqiuhq: Fixed-point fractional library routines. 42894 (line 1406) 42895 * __satfractqiuqq: Fixed-point fractional library routines. 42896 (line 1405) 42897 * __satfractqiusa: Fixed-point fractional library routines. 42898 (line 1413) 42899 * __satfractqiusq: Fixed-point fractional library routines. 42900 (line 1408) 42901 * __satfractqiuta: Fixed-point fractional library routines. 42902 (line 1417) 42903 * __satfractqqda: Fixed-point fractional library routines. 42904 (line 1043) 42905 * __satfractqqdq2: Fixed-point fractional library routines. 42906 (line 1040) 42907 * __satfractqqha: Fixed-point fractional library routines. 42908 (line 1041) 42909 * __satfractqqhq2: Fixed-point fractional library routines. 42910 (line 1038) 42911 * __satfractqqsa: Fixed-point fractional library routines. 42912 (line 1042) 42913 * __satfractqqsq2: Fixed-point fractional library routines. 42914 (line 1039) 42915 * __satfractqqta: Fixed-point fractional library routines. 42916 (line 1044) 42917 * __satfractqquda: Fixed-point fractional library routines. 42918 (line 1056) 42919 * __satfractqqudq: Fixed-point fractional library routines. 42920 (line 1051) 42921 * __satfractqquha: Fixed-point fractional library routines. 42922 (line 1053) 42923 * __satfractqquhq: Fixed-point fractional library routines. 42924 (line 1047) 42925 * __satfractqquqq: Fixed-point fractional library routines. 42926 (line 1046) 42927 * __satfractqqusa: Fixed-point fractional library routines. 42928 (line 1054) 42929 * __satfractqqusq: Fixed-point fractional library routines. 42930 (line 1049) 42931 * __satfractqquta: Fixed-point fractional library routines. 42932 (line 1058) 42933 * __satfractsada2: Fixed-point fractional library routines. 42934 (line 1140) 42935 * __satfractsadq: Fixed-point fractional library routines. 42936 (line 1138) 42937 * __satfractsaha2: Fixed-point fractional library routines. 42938 (line 1139) 42939 * __satfractsahq: Fixed-point fractional library routines. 42940 (line 1136) 42941 * __satfractsaqq: Fixed-point fractional library routines. 42942 (line 1135) 42943 * __satfractsasq: Fixed-point fractional library routines. 42944 (line 1137) 42945 * __satfractsata2: Fixed-point fractional library routines. 42946 (line 1141) 42947 * __satfractsauda: Fixed-point fractional library routines. 42948 (line 1148) 42949 * __satfractsaudq: Fixed-point fractional library routines. 42950 (line 1145) 42951 * __satfractsauha: Fixed-point fractional library routines. 42952 (line 1146) 42953 * __satfractsauhq: Fixed-point fractional library routines. 42954 (line 1143) 42955 * __satfractsauqq: Fixed-point fractional library routines. 42956 (line 1142) 42957 * __satfractsausa: Fixed-point fractional library routines. 42958 (line 1147) 42959 * __satfractsausq: Fixed-point fractional library routines. 42960 (line 1144) 42961 * __satfractsauta: Fixed-point fractional library routines. 42962 (line 1149) 42963 * __satfractsfda: Fixed-point fractional library routines. 42964 (line 1490) 42965 * __satfractsfdq: Fixed-point fractional library routines. 42966 (line 1487) 42967 * __satfractsfha: Fixed-point fractional library routines. 42968 (line 1488) 42969 * __satfractsfhq: Fixed-point fractional library routines. 42970 (line 1485) 42971 * __satfractsfqq: Fixed-point fractional library routines. 42972 (line 1484) 42973 * __satfractsfsa: Fixed-point fractional library routines. 42974 (line 1489) 42975 * __satfractsfsq: Fixed-point fractional library routines. 42976 (line 1486) 42977 * __satfractsfta: Fixed-point fractional library routines. 42978 (line 1491) 42979 * __satfractsfuda: Fixed-point fractional library routines. 42980 (line 1498) 42981 * __satfractsfudq: Fixed-point fractional library routines. 42982 (line 1495) 42983 * __satfractsfuha: Fixed-point fractional library routines. 42984 (line 1496) 42985 * __satfractsfuhq: Fixed-point fractional library routines. 42986 (line 1493) 42987 * __satfractsfuqq: Fixed-point fractional library routines. 42988 (line 1492) 42989 * __satfractsfusa: Fixed-point fractional library routines. 42990 (line 1497) 42991 * __satfractsfusq: Fixed-point fractional library routines. 42992 (line 1494) 42993 * __satfractsfuta: Fixed-point fractional library routines. 42994 (line 1499) 42995 * __satfractsida: Fixed-point fractional library routines. 42996 (line 1440) 42997 * __satfractsidq: Fixed-point fractional library routines. 42998 (line 1437) 42999 * __satfractsiha: Fixed-point fractional library routines. 43000 (line 1438) 43001 * __satfractsihq: Fixed-point fractional library routines. 43002 (line 1435) 43003 * __satfractsiqq: Fixed-point fractional library routines. 43004 (line 1434) 43005 * __satfractsisa: Fixed-point fractional library routines. 43006 (line 1439) 43007 * __satfractsisq: Fixed-point fractional library routines. 43008 (line 1436) 43009 * __satfractsita: Fixed-point fractional library routines. 43010 (line 1441) 43011 * __satfractsiuda: Fixed-point fractional library routines. 43012 (line 1448) 43013 * __satfractsiudq: Fixed-point fractional library routines. 43014 (line 1445) 43015 * __satfractsiuha: Fixed-point fractional library routines. 43016 (line 1446) 43017 * __satfractsiuhq: Fixed-point fractional library routines. 43018 (line 1443) 43019 * __satfractsiuqq: Fixed-point fractional library routines. 43020 (line 1442) 43021 * __satfractsiusa: Fixed-point fractional library routines. 43022 (line 1447) 43023 * __satfractsiusq: Fixed-point fractional library routines. 43024 (line 1444) 43025 * __satfractsiuta: Fixed-point fractional library routines. 43026 (line 1449) 43027 * __satfractsqda: Fixed-point fractional library routines. 43028 (line 1079) 43029 * __satfractsqdq2: Fixed-point fractional library routines. 43030 (line 1076) 43031 * __satfractsqha: Fixed-point fractional library routines. 43032 (line 1077) 43033 * __satfractsqhq2: Fixed-point fractional library routines. 43034 (line 1075) 43035 * __satfractsqqq2: Fixed-point fractional library routines. 43036 (line 1074) 43037 * __satfractsqsa: Fixed-point fractional library routines. 43038 (line 1078) 43039 * __satfractsqta: Fixed-point fractional library routines. 43040 (line 1080) 43041 * __satfractsquda: Fixed-point fractional library routines. 43042 (line 1090) 43043 * __satfractsqudq: Fixed-point fractional library routines. 43044 (line 1086) 43045 * __satfractsquha: Fixed-point fractional library routines. 43046 (line 1088) 43047 * __satfractsquhq: Fixed-point fractional library routines. 43048 (line 1083) 43049 * __satfractsquqq: Fixed-point fractional library routines. 43050 (line 1082) 43051 * __satfractsqusa: Fixed-point fractional library routines. 43052 (line 1089) 43053 * __satfractsqusq: Fixed-point fractional library routines. 43054 (line 1084) 43055 * __satfractsquta: Fixed-point fractional library routines. 43056 (line 1092) 43057 * __satfracttada2: Fixed-point fractional library routines. 43058 (line 1175) 43059 * __satfracttadq: Fixed-point fractional library routines. 43060 (line 1172) 43061 * __satfracttaha2: Fixed-point fractional library routines. 43062 (line 1173) 43063 * __satfracttahq: Fixed-point fractional library routines. 43064 (line 1170) 43065 * __satfracttaqq: Fixed-point fractional library routines. 43066 (line 1169) 43067 * __satfracttasa2: Fixed-point fractional library routines. 43068 (line 1174) 43069 * __satfracttasq: Fixed-point fractional library routines. 43070 (line 1171) 43071 * __satfracttauda: Fixed-point fractional library routines. 43072 (line 1187) 43073 * __satfracttaudq: Fixed-point fractional library routines. 43074 (line 1182) 43075 * __satfracttauha: Fixed-point fractional library routines. 43076 (line 1184) 43077 * __satfracttauhq: Fixed-point fractional library routines. 43078 (line 1178) 43079 * __satfracttauqq: Fixed-point fractional library routines. 43080 (line 1177) 43081 * __satfracttausa: Fixed-point fractional library routines. 43082 (line 1185) 43083 * __satfracttausq: Fixed-point fractional library routines. 43084 (line 1180) 43085 * __satfracttauta: Fixed-point fractional library routines. 43086 (line 1189) 43087 * __satfracttida: Fixed-point fractional library routines. 43088 (line 1472) 43089 * __satfracttidq: Fixed-point fractional library routines. 43090 (line 1469) 43091 * __satfracttiha: Fixed-point fractional library routines. 43092 (line 1470) 43093 * __satfracttihq: Fixed-point fractional library routines. 43094 (line 1467) 43095 * __satfracttiqq: Fixed-point fractional library routines. 43096 (line 1466) 43097 * __satfracttisa: Fixed-point fractional library routines. 43098 (line 1471) 43099 * __satfracttisq: Fixed-point fractional library routines. 43100 (line 1468) 43101 * __satfracttita: Fixed-point fractional library routines. 43102 (line 1473) 43103 * __satfracttiuda: Fixed-point fractional library routines. 43104 (line 1481) 43105 * __satfracttiudq: Fixed-point fractional library routines. 43106 (line 1478) 43107 * __satfracttiuha: Fixed-point fractional library routines. 43108 (line 1479) 43109 * __satfracttiuhq: Fixed-point fractional library routines. 43110 (line 1475) 43111 * __satfracttiuqq: Fixed-point fractional library routines. 43112 (line 1474) 43113 * __satfracttiusa: Fixed-point fractional library routines. 43114 (line 1480) 43115 * __satfracttiusq: Fixed-point fractional library routines. 43116 (line 1476) 43117 * __satfracttiuta: Fixed-point fractional library routines. 43118 (line 1483) 43119 * __satfractudada: Fixed-point fractional library routines. 43120 (line 1351) 43121 * __satfractudadq: Fixed-point fractional library routines. 43122 (line 1347) 43123 * __satfractudaha: Fixed-point fractional library routines. 43124 (line 1349) 43125 * __satfractudahq: Fixed-point fractional library routines. 43126 (line 1344) 43127 * __satfractudaqq: Fixed-point fractional library routines. 43128 (line 1343) 43129 * __satfractudasa: Fixed-point fractional library routines. 43130 (line 1350) 43131 * __satfractudasq: Fixed-point fractional library routines. 43132 (line 1345) 43133 * __satfractudata: Fixed-point fractional library routines. 43134 (line 1353) 43135 * __satfractudaudq: Fixed-point fractional library routines. 43136 (line 1361) 43137 * __satfractudauha2: Fixed-point fractional library routines. 43138 (line 1363) 43139 * __satfractudauhq: Fixed-point fractional library routines. 43140 (line 1357) 43141 * __satfractudauqq: Fixed-point fractional library routines. 43142 (line 1355) 43143 * __satfractudausa2: Fixed-point fractional library routines. 43144 (line 1365) 43145 * __satfractudausq: Fixed-point fractional library routines. 43146 (line 1359) 43147 * __satfractudauta2: Fixed-point fractional library routines. 43148 (line 1367) 43149 * __satfractudqda: Fixed-point fractional library routines. 43150 (line 1276) 43151 * __satfractudqdq: Fixed-point fractional library routines. 43152 (line 1271) 43153 * __satfractudqha: Fixed-point fractional library routines. 43154 (line 1273) 43155 * __satfractudqhq: Fixed-point fractional library routines. 43156 (line 1267) 43157 * __satfractudqqq: Fixed-point fractional library routines. 43158 (line 1266) 43159 * __satfractudqsa: Fixed-point fractional library routines. 43160 (line 1274) 43161 * __satfractudqsq: Fixed-point fractional library routines. 43162 (line 1269) 43163 * __satfractudqta: Fixed-point fractional library routines. 43164 (line 1278) 43165 * __satfractudquda: Fixed-point fractional library routines. 43166 (line 1290) 43167 * __satfractudquha: Fixed-point fractional library routines. 43168 (line 1286) 43169 * __satfractudquhq2: Fixed-point fractional library routines. 43170 (line 1282) 43171 * __satfractudquqq2: Fixed-point fractional library routines. 43172 (line 1280) 43173 * __satfractudqusa: Fixed-point fractional library routines. 43174 (line 1288) 43175 * __satfractudqusq2: Fixed-point fractional library routines. 43176 (line 1284) 43177 * __satfractudquta: Fixed-point fractional library routines. 43178 (line 1292) 43179 * __satfractuhada: Fixed-point fractional library routines. 43180 (line 1304) 43181 * __satfractuhadq: Fixed-point fractional library routines. 43182 (line 1299) 43183 * __satfractuhaha: Fixed-point fractional library routines. 43184 (line 1301) 43185 * __satfractuhahq: Fixed-point fractional library routines. 43186 (line 1295) 43187 * __satfractuhaqq: Fixed-point fractional library routines. 43188 (line 1294) 43189 * __satfractuhasa: Fixed-point fractional library routines. 43190 (line 1302) 43191 * __satfractuhasq: Fixed-point fractional library routines. 43192 (line 1297) 43193 * __satfractuhata: Fixed-point fractional library routines. 43194 (line 1306) 43195 * __satfractuhauda2: Fixed-point fractional library routines. 43196 (line 1318) 43197 * __satfractuhaudq: Fixed-point fractional library routines. 43198 (line 1314) 43199 * __satfractuhauhq: Fixed-point fractional library routines. 43200 (line 1310) 43201 * __satfractuhauqq: Fixed-point fractional library routines. 43202 (line 1308) 43203 * __satfractuhausa2: Fixed-point fractional library routines. 43204 (line 1316) 43205 * __satfractuhausq: Fixed-point fractional library routines. 43206 (line 1312) 43207 * __satfractuhauta2: Fixed-point fractional library routines. 43208 (line 1320) 43209 * __satfractuhqda: Fixed-point fractional library routines. 43210 (line 1224) 43211 * __satfractuhqdq: Fixed-point fractional library routines. 43212 (line 1221) 43213 * __satfractuhqha: Fixed-point fractional library routines. 43214 (line 1222) 43215 * __satfractuhqhq: Fixed-point fractional library routines. 43216 (line 1219) 43217 * __satfractuhqqq: Fixed-point fractional library routines. 43218 (line 1218) 43219 * __satfractuhqsa: Fixed-point fractional library routines. 43220 (line 1223) 43221 * __satfractuhqsq: Fixed-point fractional library routines. 43222 (line 1220) 43223 * __satfractuhqta: Fixed-point fractional library routines. 43224 (line 1225) 43225 * __satfractuhquda: Fixed-point fractional library routines. 43226 (line 1236) 43227 * __satfractuhqudq2: Fixed-point fractional library routines. 43228 (line 1231) 43229 * __satfractuhquha: Fixed-point fractional library routines. 43230 (line 1233) 43231 * __satfractuhquqq2: Fixed-point fractional library routines. 43232 (line 1227) 43233 * __satfractuhqusa: Fixed-point fractional library routines. 43234 (line 1234) 43235 * __satfractuhqusq2: Fixed-point fractional library routines. 43236 (line 1229) 43237 * __satfractuhquta: Fixed-point fractional library routines. 43238 (line 1238) 43239 * __satfractunsdida: Fixed-point fractional library routines. 43240 (line 1834) 43241 * __satfractunsdidq: Fixed-point fractional library routines. 43242 (line 1831) 43243 * __satfractunsdiha: Fixed-point fractional library routines. 43244 (line 1832) 43245 * __satfractunsdihq: Fixed-point fractional library routines. 43246 (line 1828) 43247 * __satfractunsdiqq: Fixed-point fractional library routines. 43248 (line 1827) 43249 * __satfractunsdisa: Fixed-point fractional library routines. 43250 (line 1833) 43251 * __satfractunsdisq: Fixed-point fractional library routines. 43252 (line 1829) 43253 * __satfractunsdita: Fixed-point fractional library routines. 43254 (line 1836) 43255 * __satfractunsdiuda: Fixed-point fractional library routines. 43256 (line 1850) 43257 * __satfractunsdiudq: Fixed-point fractional library routines. 43258 (line 1844) 43259 * __satfractunsdiuha: Fixed-point fractional library routines. 43260 (line 1846) 43261 * __satfractunsdiuhq: Fixed-point fractional library routines. 43262 (line 1840) 43263 * __satfractunsdiuqq: Fixed-point fractional library routines. 43264 (line 1838) 43265 * __satfractunsdiusa: Fixed-point fractional library routines. 43266 (line 1848) 43267 * __satfractunsdiusq: Fixed-point fractional library routines. 43268 (line 1842) 43269 * __satfractunsdiuta: Fixed-point fractional library routines. 43270 (line 1852) 43271 * __satfractunshida: Fixed-point fractional library routines. 43272 (line 1786) 43273 * __satfractunshidq: Fixed-point fractional library routines. 43274 (line 1783) 43275 * __satfractunshiha: Fixed-point fractional library routines. 43276 (line 1784) 43277 * __satfractunshihq: Fixed-point fractional library routines. 43278 (line 1780) 43279 * __satfractunshiqq: Fixed-point fractional library routines. 43280 (line 1779) 43281 * __satfractunshisa: Fixed-point fractional library routines. 43282 (line 1785) 43283 * __satfractunshisq: Fixed-point fractional library routines. 43284 (line 1781) 43285 * __satfractunshita: Fixed-point fractional library routines. 43286 (line 1788) 43287 * __satfractunshiuda: Fixed-point fractional library routines. 43288 (line 1802) 43289 * __satfractunshiudq: Fixed-point fractional library routines. 43290 (line 1796) 43291 * __satfractunshiuha: Fixed-point fractional library routines. 43292 (line 1798) 43293 * __satfractunshiuhq: Fixed-point fractional library routines. 43294 (line 1792) 43295 * __satfractunshiuqq: Fixed-point fractional library routines. 43296 (line 1790) 43297 * __satfractunshiusa: Fixed-point fractional library routines. 43298 (line 1800) 43299 * __satfractunshiusq: Fixed-point fractional library routines. 43300 (line 1794) 43301 * __satfractunshiuta: Fixed-point fractional library routines. 43302 (line 1804) 43303 * __satfractunsqida: Fixed-point fractional library routines. 43304 (line 1760) 43305 * __satfractunsqidq: Fixed-point fractional library routines. 43306 (line 1757) 43307 * __satfractunsqiha: Fixed-point fractional library routines. 43308 (line 1758) 43309 * __satfractunsqihq: Fixed-point fractional library routines. 43310 (line 1754) 43311 * __satfractunsqiqq: Fixed-point fractional library routines. 43312 (line 1753) 43313 * __satfractunsqisa: Fixed-point fractional library routines. 43314 (line 1759) 43315 * __satfractunsqisq: Fixed-point fractional library routines. 43316 (line 1755) 43317 * __satfractunsqita: Fixed-point fractional library routines. 43318 (line 1762) 43319 * __satfractunsqiuda: Fixed-point fractional library routines. 43320 (line 1776) 43321 * __satfractunsqiudq: Fixed-point fractional library routines. 43322 (line 1770) 43323 * __satfractunsqiuha: Fixed-point fractional library routines. 43324 (line 1772) 43325 * __satfractunsqiuhq: Fixed-point fractional library routines. 43326 (line 1766) 43327 * __satfractunsqiuqq: Fixed-point fractional library routines. 43328 (line 1764) 43329 * __satfractunsqiusa: Fixed-point fractional library routines. 43330 (line 1774) 43331 * __satfractunsqiusq: Fixed-point fractional library routines. 43332 (line 1768) 43333 * __satfractunsqiuta: Fixed-point fractional library routines. 43334 (line 1778) 43335 * __satfractunssida: Fixed-point fractional library routines. 43336 (line 1811) 43337 * __satfractunssidq: Fixed-point fractional library routines. 43338 (line 1808) 43339 * __satfractunssiha: Fixed-point fractional library routines. 43340 (line 1809) 43341 * __satfractunssihq: Fixed-point fractional library routines. 43342 (line 1806) 43343 * __satfractunssiqq: Fixed-point fractional library routines. 43344 (line 1805) 43345 * __satfractunssisa: Fixed-point fractional library routines. 43346 (line 1810) 43347 * __satfractunssisq: Fixed-point fractional library routines. 43348 (line 1807) 43349 * __satfractunssita: Fixed-point fractional library routines. 43350 (line 1812) 43351 * __satfractunssiuda: Fixed-point fractional library routines. 43352 (line 1824) 43353 * __satfractunssiudq: Fixed-point fractional library routines. 43354 (line 1819) 43355 * __satfractunssiuha: Fixed-point fractional library routines. 43356 (line 1821) 43357 * __satfractunssiuhq: Fixed-point fractional library routines. 43358 (line 1815) 43359 * __satfractunssiuqq: Fixed-point fractional library routines. 43360 (line 1814) 43361 * __satfractunssiusa: Fixed-point fractional library routines. 43362 (line 1822) 43363 * __satfractunssiusq: Fixed-point fractional library routines. 43364 (line 1817) 43365 * __satfractunssiuta: Fixed-point fractional library routines. 43366 (line 1826) 43367 * __satfractunstida: Fixed-point fractional library routines. 43368 (line 1864) 43369 * __satfractunstidq: Fixed-point fractional library routines. 43370 (line 1859) 43371 * __satfractunstiha: Fixed-point fractional library routines. 43372 (line 1861) 43373 * __satfractunstihq: Fixed-point fractional library routines. 43374 (line 1855) 43375 * __satfractunstiqq: Fixed-point fractional library routines. 43376 (line 1854) 43377 * __satfractunstisa: Fixed-point fractional library routines. 43378 (line 1862) 43379 * __satfractunstisq: Fixed-point fractional library routines. 43380 (line 1857) 43381 * __satfractunstita: Fixed-point fractional library routines. 43382 (line 1866) 43383 * __satfractunstiuda: Fixed-point fractional library routines. 43384 (line 1880) 43385 * __satfractunstiudq: Fixed-point fractional library routines. 43386 (line 1874) 43387 * __satfractunstiuha: Fixed-point fractional library routines. 43388 (line 1876) 43389 * __satfractunstiuhq: Fixed-point fractional library routines. 43390 (line 1870) 43391 * __satfractunstiuqq: Fixed-point fractional library routines. 43392 (line 1868) 43393 * __satfractunstiusa: Fixed-point fractional library routines. 43394 (line 1878) 43395 * __satfractunstiusq: Fixed-point fractional library routines. 43396 (line 1872) 43397 * __satfractunstiuta: Fixed-point fractional library routines. 43398 (line 1882) 43399 * __satfractuqqda: Fixed-point fractional library routines. 43400 (line 1201) 43401 * __satfractuqqdq: Fixed-point fractional library routines. 43402 (line 1196) 43403 * __satfractuqqha: Fixed-point fractional library routines. 43404 (line 1198) 43405 * __satfractuqqhq: Fixed-point fractional library routines. 43406 (line 1192) 43407 * __satfractuqqqq: Fixed-point fractional library routines. 43408 (line 1191) 43409 * __satfractuqqsa: Fixed-point fractional library routines. 43410 (line 1199) 43411 * __satfractuqqsq: Fixed-point fractional library routines. 43412 (line 1194) 43413 * __satfractuqqta: Fixed-point fractional library routines. 43414 (line 1203) 43415 * __satfractuqquda: Fixed-point fractional library routines. 43416 (line 1215) 43417 * __satfractuqqudq2: Fixed-point fractional library routines. 43418 (line 1209) 43419 * __satfractuqquha: Fixed-point fractional library routines. 43420 (line 1211) 43421 * __satfractuqquhq2: Fixed-point fractional library routines. 43422 (line 1205) 43423 * __satfractuqqusa: Fixed-point fractional library routines. 43424 (line 1213) 43425 * __satfractuqqusq2: Fixed-point fractional library routines. 43426 (line 1207) 43427 * __satfractuqquta: Fixed-point fractional library routines. 43428 (line 1217) 43429 * __satfractusada: Fixed-point fractional library routines. 43430 (line 1327) 43431 * __satfractusadq: Fixed-point fractional library routines. 43432 (line 1324) 43433 * __satfractusaha: Fixed-point fractional library routines. 43434 (line 1325) 43435 * __satfractusahq: Fixed-point fractional library routines. 43436 (line 1322) 43437 * __satfractusaqq: Fixed-point fractional library routines. 43438 (line 1321) 43439 * __satfractusasa: Fixed-point fractional library routines. 43440 (line 1326) 43441 * __satfractusasq: Fixed-point fractional library routines. 43442 (line 1323) 43443 * __satfractusata: Fixed-point fractional library routines. 43444 (line 1328) 43445 * __satfractusauda2: Fixed-point fractional library routines. 43446 (line 1339) 43447 * __satfractusaudq: Fixed-point fractional library routines. 43448 (line 1335) 43449 * __satfractusauha2: Fixed-point fractional library routines. 43450 (line 1337) 43451 * __satfractusauhq: Fixed-point fractional library routines. 43452 (line 1331) 43453 * __satfractusauqq: Fixed-point fractional library routines. 43454 (line 1330) 43455 * __satfractusausq: Fixed-point fractional library routines. 43456 (line 1333) 43457 * __satfractusauta2: Fixed-point fractional library routines. 43458 (line 1341) 43459 * __satfractusqda: Fixed-point fractional library routines. 43460 (line 1248) 43461 * __satfractusqdq: Fixed-point fractional library routines. 43462 (line 1244) 43463 * __satfractusqha: Fixed-point fractional library routines. 43464 (line 1246) 43465 * __satfractusqhq: Fixed-point fractional library routines. 43466 (line 1241) 43467 * __satfractusqqq: Fixed-point fractional library routines. 43468 (line 1240) 43469 * __satfractusqsa: Fixed-point fractional library routines. 43470 (line 1247) 43471 * __satfractusqsq: Fixed-point fractional library routines. 43472 (line 1242) 43473 * __satfractusqta: Fixed-point fractional library routines. 43474 (line 1250) 43475 * __satfractusquda: Fixed-point fractional library routines. 43476 (line 1262) 43477 * __satfractusqudq2: Fixed-point fractional library routines. 43478 (line 1256) 43479 * __satfractusquha: Fixed-point fractional library routines. 43480 (line 1258) 43481 * __satfractusquhq2: Fixed-point fractional library routines. 43482 (line 1254) 43483 * __satfractusquqq2: Fixed-point fractional library routines. 43484 (line 1252) 43485 * __satfractusqusa: Fixed-point fractional library routines. 43486 (line 1260) 43487 * __satfractusquta: Fixed-point fractional library routines. 43488 (line 1264) 43489 * __satfractutada: Fixed-point fractional library routines. 43490 (line 1379) 43491 * __satfractutadq: Fixed-point fractional library routines. 43492 (line 1374) 43493 * __satfractutaha: Fixed-point fractional library routines. 43494 (line 1376) 43495 * __satfractutahq: Fixed-point fractional library routines. 43496 (line 1370) 43497 * __satfractutaqq: Fixed-point fractional library routines. 43498 (line 1369) 43499 * __satfractutasa: Fixed-point fractional library routines. 43500 (line 1377) 43501 * __satfractutasq: Fixed-point fractional library routines. 43502 (line 1372) 43503 * __satfractutata: Fixed-point fractional library routines. 43504 (line 1381) 43505 * __satfractutauda2: Fixed-point fractional library routines. 43506 (line 1395) 43507 * __satfractutaudq: Fixed-point fractional library routines. 43508 (line 1389) 43509 * __satfractutauha2: Fixed-point fractional library routines. 43510 (line 1391) 43511 * __satfractutauhq: Fixed-point fractional library routines. 43512 (line 1385) 43513 * __satfractutauqq: Fixed-point fractional library routines. 43514 (line 1383) 43515 * __satfractutausa2: Fixed-point fractional library routines. 43516 (line 1393) 43517 * __satfractutausq: Fixed-point fractional library routines. 43518 (line 1387) 43519 * __splitstack_find: Miscellaneous routines. 43520 (line 18) 43521 * __ssaddda3: Fixed-point fractional library routines. 43522 (line 67) 43523 * __ssadddq3: Fixed-point fractional library routines. 43524 (line 63) 43525 * __ssaddha3: Fixed-point fractional library routines. 43526 (line 65) 43527 * __ssaddhq3: Fixed-point fractional library routines. 43528 (line 60) 43529 * __ssaddqq3: Fixed-point fractional library routines. 43530 (line 59) 43531 * __ssaddsa3: Fixed-point fractional library routines. 43532 (line 66) 43533 * __ssaddsq3: Fixed-point fractional library routines. 43534 (line 61) 43535 * __ssaddta3: Fixed-point fractional library routines. 43536 (line 69) 43537 * __ssashlda3: Fixed-point fractional library routines. 43538 (line 402) 43539 * __ssashldq3: Fixed-point fractional library routines. 43540 (line 399) 43541 * __ssashlha3: Fixed-point fractional library routines. 43542 (line 400) 43543 * __ssashlhq3: Fixed-point fractional library routines. 43544 (line 396) 43545 * __ssashlsa3: Fixed-point fractional library routines. 43546 (line 401) 43547 * __ssashlsq3: Fixed-point fractional library routines. 43548 (line 397) 43549 * __ssashlta3: Fixed-point fractional library routines. 43550 (line 404) 43551 * __ssdivda3: Fixed-point fractional library routines. 43552 (line 261) 43553 * __ssdivdq3: Fixed-point fractional library routines. 43554 (line 257) 43555 * __ssdivha3: Fixed-point fractional library routines. 43556 (line 259) 43557 * __ssdivhq3: Fixed-point fractional library routines. 43558 (line 254) 43559 * __ssdivqq3: Fixed-point fractional library routines. 43560 (line 253) 43561 * __ssdivsa3: Fixed-point fractional library routines. 43562 (line 260) 43563 * __ssdivsq3: Fixed-point fractional library routines. 43564 (line 255) 43565 * __ssdivta3: Fixed-point fractional library routines. 43566 (line 263) 43567 * __ssmulda3: Fixed-point fractional library routines. 43568 (line 193) 43569 * __ssmuldq3: Fixed-point fractional library routines. 43570 (line 189) 43571 * __ssmulha3: Fixed-point fractional library routines. 43572 (line 191) 43573 * __ssmulhq3: Fixed-point fractional library routines. 43574 (line 186) 43575 * __ssmulqq3: Fixed-point fractional library routines. 43576 (line 185) 43577 * __ssmulsa3: Fixed-point fractional library routines. 43578 (line 192) 43579 * __ssmulsq3: Fixed-point fractional library routines. 43580 (line 187) 43581 * __ssmulta3: Fixed-point fractional library routines. 43582 (line 195) 43583 * __ssnegda2: Fixed-point fractional library routines. 43584 (line 316) 43585 * __ssnegdq2: Fixed-point fractional library routines. 43586 (line 313) 43587 * __ssnegha2: Fixed-point fractional library routines. 43588 (line 314) 43589 * __ssneghq2: Fixed-point fractional library routines. 43590 (line 311) 43591 * __ssnegqq2: Fixed-point fractional library routines. 43592 (line 310) 43593 * __ssnegsa2: Fixed-point fractional library routines. 43594 (line 315) 43595 * __ssnegsq2: Fixed-point fractional library routines. 43596 (line 312) 43597 * __ssnegta2: Fixed-point fractional library routines. 43598 (line 317) 43599 * __sssubda3: Fixed-point fractional library routines. 43600 (line 129) 43601 * __sssubdq3: Fixed-point fractional library routines. 43602 (line 125) 43603 * __sssubha3: Fixed-point fractional library routines. 43604 (line 127) 43605 * __sssubhq3: Fixed-point fractional library routines. 43606 (line 122) 43607 * __sssubqq3: Fixed-point fractional library routines. 43608 (line 121) 43609 * __sssubsa3: Fixed-point fractional library routines. 43610 (line 128) 43611 * __sssubsq3: Fixed-point fractional library routines. 43612 (line 123) 43613 * __sssubta3: Fixed-point fractional library routines. 43614 (line 131) 43615 * __subda3: Fixed-point fractional library routines. 43616 (line 107) 43617 * __subdf3: Soft float library routines. 43618 (line 31) 43619 * __subdq3: Fixed-point fractional library routines. 43620 (line 95) 43621 * __subha3: Fixed-point fractional library routines. 43622 (line 105) 43623 * __subhq3: Fixed-point fractional library routines. 43624 (line 92) 43625 * __subqq3: Fixed-point fractional library routines. 43626 (line 91) 43627 * __subsa3: Fixed-point fractional library routines. 43628 (line 106) 43629 * __subsf3: Soft float library routines. 43630 (line 30) 43631 * __subsq3: Fixed-point fractional library routines. 43632 (line 93) 43633 * __subta3: Fixed-point fractional library routines. 43634 (line 109) 43635 * __subtf3: Soft float library routines. 43636 (line 33) 43637 * __subuda3: Fixed-point fractional library routines. 43638 (line 115) 43639 * __subudq3: Fixed-point fractional library routines. 43640 (line 103) 43641 * __subuha3: Fixed-point fractional library routines. 43642 (line 111) 43643 * __subuhq3: Fixed-point fractional library routines. 43644 (line 99) 43645 * __subuqq3: Fixed-point fractional library routines. 43646 (line 97) 43647 * __subusa3: Fixed-point fractional library routines. 43648 (line 113) 43649 * __subusq3: Fixed-point fractional library routines. 43650 (line 101) 43651 * __subuta3: Fixed-point fractional library routines. 43652 (line 117) 43653 * __subvdi3: Integer library routines. 43654 (line 123) 43655 * __subvsi3: Integer library routines. 43656 (line 122) 43657 * __subxf3: Soft float library routines. 43658 (line 35) 43659 * __truncdfsf2: Soft float library routines. 43660 (line 76) 43661 * __trunctfdf2: Soft float library routines. 43662 (line 73) 43663 * __trunctfsf2: Soft float library routines. 43664 (line 75) 43665 * __truncxfdf2: Soft float library routines. 43666 (line 72) 43667 * __truncxfsf2: Soft float library routines. 43668 (line 74) 43669 * __ucmpdi2: Integer library routines. 43670 (line 93) 43671 * __ucmpti2: Integer library routines. 43672 (line 95) 43673 * __udivdi3: Integer library routines. 43674 (line 54) 43675 * __udivmoddi3: Integer library routines. 43676 (line 61) 43677 * __udivsi3: Integer library routines. 43678 (line 52) 43679 * __udivti3: Integer library routines. 43680 (line 63) 43681 * __udivuda3: Fixed-point fractional library routines. 43682 (line 246) 43683 * __udivudq3: Fixed-point fractional library routines. 43684 (line 240) 43685 * __udivuha3: Fixed-point fractional library routines. 43686 (line 242) 43687 * __udivuhq3: Fixed-point fractional library routines. 43688 (line 236) 43689 * __udivuqq3: Fixed-point fractional library routines. 43690 (line 234) 43691 * __udivusa3: Fixed-point fractional library routines. 43692 (line 244) 43693 * __udivusq3: Fixed-point fractional library routines. 43694 (line 238) 43695 * __udivuta3: Fixed-point fractional library routines. 43696 (line 248) 43697 * __umoddi3: Integer library routines. 43698 (line 71) 43699 * __umodsi3: Integer library routines. 43700 (line 69) 43701 * __umodti3: Integer library routines. 43702 (line 73) 43703 * __unorddf2: Soft float library routines. 43704 (line 173) 43705 * __unordsf2: Soft float library routines. 43706 (line 172) 43707 * __unordtf2: Soft float library routines. 43708 (line 174) 43709 * __usadduda3: Fixed-point fractional library routines. 43710 (line 85) 43711 * __usaddudq3: Fixed-point fractional library routines. 43712 (line 79) 43713 * __usadduha3: Fixed-point fractional library routines. 43714 (line 81) 43715 * __usadduhq3: Fixed-point fractional library routines. 43716 (line 75) 43717 * __usadduqq3: Fixed-point fractional library routines. 43718 (line 73) 43719 * __usaddusa3: Fixed-point fractional library routines. 43720 (line 83) 43721 * __usaddusq3: Fixed-point fractional library routines. 43722 (line 77) 43723 * __usadduta3: Fixed-point fractional library routines. 43724 (line 87) 43725 * __usashluda3: Fixed-point fractional library routines. 43726 (line 421) 43727 * __usashludq3: Fixed-point fractional library routines. 43728 (line 415) 43729 * __usashluha3: Fixed-point fractional library routines. 43730 (line 417) 43731 * __usashluhq3: Fixed-point fractional library routines. 43732 (line 411) 43733 * __usashluqq3: Fixed-point fractional library routines. 43734 (line 409) 43735 * __usashlusa3: Fixed-point fractional library routines. 43736 (line 419) 43737 * __usashlusq3: Fixed-point fractional library routines. 43738 (line 413) 43739 * __usashluta3: Fixed-point fractional library routines. 43740 (line 423) 43741 * __usdivuda3: Fixed-point fractional library routines. 43742 (line 280) 43743 * __usdivudq3: Fixed-point fractional library routines. 43744 (line 274) 43745 * __usdivuha3: Fixed-point fractional library routines. 43746 (line 276) 43747 * __usdivuhq3: Fixed-point fractional library routines. 43748 (line 270) 43749 * __usdivuqq3: Fixed-point fractional library routines. 43750 (line 268) 43751 * __usdivusa3: Fixed-point fractional library routines. 43752 (line 278) 43753 * __usdivusq3: Fixed-point fractional library routines. 43754 (line 272) 43755 * __usdivuta3: Fixed-point fractional library routines. 43756 (line 282) 43757 * __usmuluda3: Fixed-point fractional library routines. 43758 (line 212) 43759 * __usmuludq3: Fixed-point fractional library routines. 43760 (line 206) 43761 * __usmuluha3: Fixed-point fractional library routines. 43762 (line 208) 43763 * __usmuluhq3: Fixed-point fractional library routines. 43764 (line 202) 43765 * __usmuluqq3: Fixed-point fractional library routines. 43766 (line 200) 43767 * __usmulusa3: Fixed-point fractional library routines. 43768 (line 210) 43769 * __usmulusq3: Fixed-point fractional library routines. 43770 (line 204) 43771 * __usmuluta3: Fixed-point fractional library routines. 43772 (line 214) 43773 * __usneguda2: Fixed-point fractional library routines. 43774 (line 331) 43775 * __usnegudq2: Fixed-point fractional library routines. 43776 (line 326) 43777 * __usneguha2: Fixed-point fractional library routines. 43778 (line 328) 43779 * __usneguhq2: Fixed-point fractional library routines. 43780 (line 322) 43781 * __usneguqq2: Fixed-point fractional library routines. 43782 (line 321) 43783 * __usnegusa2: Fixed-point fractional library routines. 43784 (line 329) 43785 * __usnegusq2: Fixed-point fractional library routines. 43786 (line 324) 43787 * __usneguta2: Fixed-point fractional library routines. 43788 (line 333) 43789 * __ussubuda3: Fixed-point fractional library routines. 43790 (line 148) 43791 * __ussubudq3: Fixed-point fractional library routines. 43792 (line 142) 43793 * __ussubuha3: Fixed-point fractional library routines. 43794 (line 144) 43795 * __ussubuhq3: Fixed-point fractional library routines. 43796 (line 138) 43797 * __ussubuqq3: Fixed-point fractional library routines. 43798 (line 136) 43799 * __ussubusa3: Fixed-point fractional library routines. 43800 (line 146) 43801 * __ussubusq3: Fixed-point fractional library routines. 43802 (line 140) 43803 * __ussubuta3: Fixed-point fractional library routines. 43804 (line 150) 43805 * abort: Portability. (line 21) 43806 * abs: Arithmetic. (line 200) 43807 * abs and attributes: Expressions. (line 64) 43808 * ABS_EXPR: Unary and Binary Expressions. 43809 (line 6) 43810 * absence_set: Processor pipeline description. 43811 (line 220) 43812 * absM2 instruction pattern: Standard Names. (line 479) 43813 * absolute value: Arithmetic. (line 200) 43814 * access to operands: Accessors. (line 6) 43815 * access to special operands: Special Accessors. (line 6) 43816 * accessors: Accessors. (line 6) 43817 * ACCUM_TYPE_SIZE: Type Layout. (line 88) 43818 * ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 49) 43819 * ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135) 43820 * ADA_LONG_TYPE_SIZE: Type Layout. (line 26) 43821 * Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 43822 (line 6) 43823 * ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15) 43824 * addM3 instruction pattern: Standard Names. (line 216) 43825 * addMODEcc instruction pattern: Standard Names. (line 917) 43826 * addr_diff_vec: Side Effects. (line 302) 43827 * addr_diff_vec, length of: Insn Lengths. (line 26) 43828 * ADDR_EXPR: Storage References. (line 6) 43829 * addr_vec: Side Effects. (line 297) 43830 * addr_vec, length of: Insn Lengths. (line 26) 43831 * address constraints: Simple Constraints. (line 164) 43832 * address_operand <1>: Machine-Independent Predicates. 43833 (line 63) 43834 * address_operand: Simple Constraints. (line 168) 43835 * addressing modes: Addressing Modes. (line 6) 43836 * ADJUST_FIELD_ALIGN: Storage Layout. (line 189) 43837 * ADJUST_INSN_LENGTH: Insn Lengths. (line 35) 43838 * ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 23) 43839 * aggregates as return values: Aggregate Return. (line 6) 43840 * alias: Alias analysis. (line 6) 43841 * ALL_COP_ADDITIONAL_REGISTER_NAMES: MIPS Coprocessors. (line 32) 43842 * ALL_REGS: Register Classes. (line 17) 43843 * allocate_stack instruction pattern: Standard Names. (line 1227) 43844 * alternate entry points: Insns. (line 140) 43845 * anchored addresses: Anchored Addresses. (line 6) 43846 * and: Arithmetic. (line 158) 43847 * and and attributes: Expressions. (line 50) 43848 * and, canonicalization of: Insn Canonicalizations. 43849 (line 52) 43850 * andM3 instruction pattern: Standard Names. (line 222) 43851 * annotations: Annotations. (line 6) 43852 * APPLY_RESULT_SIZE: Scalar Return. (line 112) 43853 * ARG_POINTER_CFA_OFFSET: Frame Layout. (line 194) 43854 * ARG_POINTER_REGNUM: Frame Registers. (line 41) 43855 * ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 43856 * arg_pointer_rtx: Frame Registers. (line 104) 43857 * ARGS_GROW_DOWNWARD: Frame Layout. (line 35) 43858 * argument passing: Interface. (line 36) 43859 * arguments in registers: Register Arguments. (line 6) 43860 * arguments on stack: Stack Arguments. (line 6) 43861 * arithmetic library: Soft float library routines. 43862 (line 6) 43863 * arithmetic shift: Arithmetic. (line 173) 43864 * arithmetic shift with signed saturation: Arithmetic. (line 173) 43865 * arithmetic shift with unsigned saturation: Arithmetic. (line 173) 43866 * arithmetic, in RTL: Arithmetic. (line 6) 43867 * ARITHMETIC_TYPE_P: Types for C++. (line 61) 43868 * array: Types. (line 6) 43869 * ARRAY_RANGE_REF: Storage References. (line 6) 43870 * ARRAY_REF: Storage References. (line 6) 43871 * ARRAY_TYPE: Types. (line 6) 43872 * AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 89) 43873 * ashift: Arithmetic. (line 173) 43874 * ashift and attributes: Expressions. (line 64) 43875 * ashiftrt: Arithmetic. (line 190) 43876 * ashiftrt and attributes: Expressions. (line 64) 43877 * ashlM3 instruction pattern: Standard Names. (line 458) 43878 * ashrM3 instruction pattern: Standard Names. (line 468) 43879 * ASM_APP_OFF: File Framework. (line 78) 43880 * ASM_APP_ON: File Framework. (line 71) 43881 * ASM_COMMENT_START: File Framework. (line 66) 43882 * ASM_DECLARE_CLASS_REFERENCE: Label Output. (line 465) 43883 * ASM_DECLARE_FUNCTION_NAME: Label Output. (line 99) 43884 * ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 114) 43885 * ASM_DECLARE_OBJECT_NAME: Label Output. (line 127) 43886 * ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 156) 43887 * ASM_DECLARE_UNRESOLVED_REFERENCE: Label Output. (line 471) 43888 * ASM_FINAL_SPEC: Driver. (line 82) 43889 * ASM_FINISH_DECLARE_OBJECT: Label Output. (line 164) 43890 * ASM_FORMAT_PRIVATE_NAME: Label Output. (line 383) 43891 * asm_fprintf: Instruction Output. (line 151) 43892 * ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 162) 43893 * ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 367) 43894 * asm_input: Side Effects. (line 284) 43895 * asm_input and /v: Flags. (line 94) 43896 * ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82) 43897 * ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 79) 43898 * asm_noperands: Insns. (line 307) 43899 * asm_operands and /v: Flags. (line 94) 43900 * asm_operands, RTL sharing: Sharing. (line 45) 43901 * asm_operands, usage: Assembler. (line 6) 43902 * ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9) 43903 * ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26) 43904 * ASM_OUTPUT_ALIGN: Alignment Output. (line 86) 43905 * ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 91) 43906 * ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 71) 43907 * ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 30) 43908 * ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 38) 43909 * ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 102) 43910 * ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 94) 43911 * ASM_OUTPUT_ASCII: Data Output. (line 62) 43912 * ASM_OUTPUT_BSS: Uninitialized Data. (line 46) 43913 * ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51) 43914 * ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38) 43915 * ASM_OUTPUT_COMMON: Uninitialized Data. (line 10) 43916 * ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 355) 43917 * ASM_OUTPUT_DEF: Label Output. (line 404) 43918 * ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 412) 43919 * ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 69) 43920 * ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 78) 43921 * ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 84) 43922 * ASM_OUTPUT_DWARF_TABLE_REF: SDB and DWARF. (line 89) 43923 * ASM_OUTPUT_DWARF_VMS_DELTA: SDB and DWARF. (line 73) 43924 * ASM_OUTPUT_EXTERNAL: Label Output. (line 284) 43925 * ASM_OUTPUT_FDESC: Data Output. (line 71) 43926 * ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 17) 43927 * ASM_OUTPUT_IDENT: File Framework. (line 109) 43928 * ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 29) 43929 * ASM_OUTPUT_LABEL: Label Output. (line 9) 43930 * ASM_OUTPUT_LABEL_REF: Label Output. (line 328) 43931 * ASM_OUTPUT_LABELREF: Label Output. (line 306) 43932 * ASM_OUTPUT_LOCAL: Uninitialized Data. (line 81) 43933 * ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 95) 43934 * ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 53) 43935 * ASM_OUTPUT_OPCODE: Instruction Output. (line 36) 43936 * ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 121) 43937 * ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 84) 43938 * ASM_OUTPUT_REG_POP: Instruction Output. (line 206) 43939 * ASM_OUTPUT_REG_PUSH: Instruction Output. (line 201) 43940 * ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 47) 43941 * ASM_OUTPUT_SKIP: Alignment Output. (line 73) 43942 * ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 85) 43943 * ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 96) 43944 * ASM_OUTPUT_SYMBOL_REF: Label Output. (line 321) 43945 * ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 89) 43946 * ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 430) 43947 * ASM_OUTPUT_WEAKREF: Label Output. (line 216) 43948 * ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67) 43949 * ASM_SPEC: Driver. (line 74) 43950 * ASM_STABD_OP: DBX Options. (line 36) 43951 * ASM_STABN_OP: DBX Options. (line 43) 43952 * ASM_STABS_OP: DBX Options. (line 29) 43953 * ASM_WEAKEN_DECL: Label Output. (line 208) 43954 * ASM_WEAKEN_LABEL: Label Output. (line 195) 43955 * assemble_name: Label Output. (line 8) 43956 * assemble_name_raw: Label Output. (line 28) 43957 * assembler format: File Framework. (line 6) 43958 * assembler instructions in RTL: Assembler. (line 6) 43959 * ASSEMBLER_DIALECT: Instruction Output. (line 174) 43960 * assigning attribute values to insns: Tagging Insns. (line 6) 43961 * asterisk in template: Output Statement. (line 29) 43962 * atan2M3 instruction pattern: Standard Names. (line 549) 43963 * attr <1>: Expressions. (line 154) 43964 * attr: Tagging Insns. (line 54) 43965 * attr_flag: Expressions. (line 119) 43966 * attribute expressions: Expressions. (line 6) 43967 * attribute specifications: Attr Example. (line 6) 43968 * attribute specifications example: Attr Example. (line 6) 43969 * ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 171) 43970 * attributes: Attributes. (line 6) 43971 * attributes, defining: Defining Attributes. 43972 (line 6) 43973 * attributes, target-specific: Target Attributes. (line 6) 43974 * autoincrement addressing, availability: Portability. (line 21) 43975 * autoincrement/decrement addressing: Simple Constraints. (line 30) 43976 * automata_option: Processor pipeline description. 43977 (line 301) 43978 * automaton based pipeline description: Processor pipeline description. 43979 (line 6) 43980 * automaton based scheduler: Processor pipeline description. 43981 (line 6) 43982 * AVOID_CCMODE_COPIES: Values in Registers. 43983 (line 153) 43984 * backslash: Output Template. (line 46) 43985 * barrier: Insns. (line 160) 43986 * barrier and /f: Flags. (line 125) 43987 * barrier and /v: Flags. (line 44) 43988 * BASE_REG_CLASS: Register Classes. (line 109) 43989 * basic block: Basic Blocks. (line 6) 43990 * Basic Statements: Basic Statements. (line 6) 43991 * basic-block.h: Control Flow. (line 6) 43992 * BASIC_BLOCK: Basic Blocks. (line 19) 43993 * basic_block: Basic Blocks. (line 6) 43994 * BB_HEAD, BB_END: Maintaining the CFG. 43995 (line 88) 43996 * bb_seq: GIMPLE sequences. (line 73) 43997 * BIGGEST_ALIGNMENT: Storage Layout. (line 161) 43998 * BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 182) 43999 * BImode: Machine Modes. (line 22) 44000 * BIND_EXPR: Unary and Binary Expressions. 44001 (line 6) 44002 * BINFO_TYPE: Classes. (line 6) 44003 * bit-fields: Bit-Fields. (line 6) 44004 * BIT_AND_EXPR: Unary and Binary Expressions. 44005 (line 6) 44006 * BIT_IOR_EXPR: Unary and Binary Expressions. 44007 (line 6) 44008 * BIT_NOT_EXPR: Unary and Binary Expressions. 44009 (line 6) 44010 * BIT_XOR_EXPR: Unary and Binary Expressions. 44011 (line 6) 44012 * BITFIELD_NBYTES_LIMITED: Storage Layout. (line 379) 44013 * BITS_BIG_ENDIAN: Storage Layout. (line 12) 44014 * BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 44015 * BITS_PER_UNIT: Storage Layout. (line 45) 44016 * BITS_PER_WORD: Storage Layout. (line 50) 44017 * bitwise complement: Arithmetic. (line 154) 44018 * bitwise exclusive-or: Arithmetic. (line 168) 44019 * bitwise inclusive-or: Arithmetic. (line 163) 44020 * bitwise logical-and: Arithmetic. (line 158) 44021 * BLKmode: Machine Modes. (line 183) 44022 * BLKmode, and function return values: Calls. (line 23) 44023 * block statement iterators <1>: Maintaining the CFG. 44024 (line 45) 44025 * block statement iterators: Basic Blocks. (line 68) 44026 * BLOCK_FOR_INSN, bb_for_stmt: Maintaining the CFG. 44027 (line 40) 44028 * BLOCK_REG_PADDING: Register Arguments. (line 228) 44029 * blockage instruction pattern: Standard Names. (line 1417) 44030 * Blocks: Blocks. (line 6) 44031 * bool: Misc. (line 854) 44032 * BOOL_TYPE_SIZE: Type Layout. (line 44) 44033 * BOOLEAN_TYPE: Types. (line 6) 44034 * branch prediction: Profile information. 44035 (line 24) 44036 * BRANCH_COST: Costs. (line 105) 44037 * break_out_memory_refs: Addressing Modes. (line 135) 44038 * BREAK_STMT: Statements for C++. (line 6) 44039 * bsi_commit_edge_inserts: Maintaining the CFG. 44040 (line 118) 44041 * bsi_end_p: Maintaining the CFG. 44042 (line 60) 44043 * bsi_insert_after: Maintaining the CFG. 44044 (line 72) 44045 * bsi_insert_before: Maintaining the CFG. 44046 (line 78) 44047 * bsi_insert_on_edge: Maintaining the CFG. 44048 (line 118) 44049 * bsi_last: Maintaining the CFG. 44050 (line 56) 44051 * bsi_next: Maintaining the CFG. 44052 (line 64) 44053 * bsi_prev: Maintaining the CFG. 44054 (line 68) 44055 * bsi_remove: Maintaining the CFG. 44056 (line 84) 44057 * bsi_start: Maintaining the CFG. 44058 (line 52) 44059 * BSS_SECTION_ASM_OP: Sections. (line 68) 44060 * bswap: Arithmetic. (line 241) 44061 * btruncM2 instruction pattern: Standard Names. (line 567) 44062 * build0: Macros and Functions. 44063 (line 16) 44064 * build1: Macros and Functions. 44065 (line 17) 44066 * build2: Macros and Functions. 44067 (line 18) 44068 * build3: Macros and Functions. 44069 (line 19) 44070 * build4: Macros and Functions. 44071 (line 20) 44072 * build5: Macros and Functions. 44073 (line 21) 44074 * build6: Macros and Functions. 44075 (line 22) 44076 * builtin_longjmp instruction pattern: Standard Names. (line 1320) 44077 * builtin_setjmp_receiver instruction pattern: Standard Names. 44078 (line 1310) 44079 * builtin_setjmp_setup instruction pattern: Standard Names. (line 1299) 44080 * byte_mode: Machine Modes. (line 336) 44081 * BYTES_BIG_ENDIAN: Storage Layout. (line 24) 44082 * BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 221) 44083 * C statements for assembler output: Output Statement. (line 6) 44084 * C99 math functions, implicit usage: Library Calls. (line 62) 44085 * C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 142) 44086 * c_register_pragma: Misc. (line 404) 44087 * c_register_pragma_with_expansion: Misc. (line 406) 44088 * call <1>: Side Effects. (line 86) 44089 * call: Flags. (line 239) 44090 * call instruction pattern: Standard Names. (line 974) 44091 * call usage: Calls. (line 10) 44092 * call, in call_insn: Flags. (line 33) 44093 * call, in mem: Flags. (line 99) 44094 * call-clobbered register: Register Basics. (line 35) 44095 * call-saved register: Register Basics. (line 46) 44096 * call-used register: Register Basics. (line 53) 44097 * CALL_EXPR: Unary and Binary Expressions. 44098 (line 6) 44099 * call_insn: Insns. (line 95) 44100 * call_insn and /c: Flags. (line 33) 44101 * call_insn and /f: Flags. (line 125) 44102 * call_insn and /i: Flags. (line 24) 44103 * call_insn and /j: Flags. (line 179) 44104 * call_insn and /s: Flags. (line 49) 44105 * call_insn and /u: Flags. (line 19) 44106 * call_insn and /u or /i: Flags. (line 29) 44107 * call_insn and /v: Flags. (line 44) 44108 * CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 44109 * call_pop instruction pattern: Standard Names. (line 1002) 44110 * CALL_POPS_ARGS: Stack Arguments. (line 133) 44111 * CALL_REALLY_USED_REGISTERS: Register Basics. (line 46) 44112 * CALL_USED_REGISTERS: Register Basics. (line 35) 44113 * call_used_regs: Register Basics. (line 59) 44114 * call_value instruction pattern: Standard Names. (line 994) 44115 * call_value_pop instruction pattern: Standard Names. (line 1002) 44116 * CALLER_SAVE_PROFITABLE: Caller Saves. (line 11) 44117 * calling conventions: Stack and Calling. (line 6) 44118 * calling functions in RTL: Calls. (line 6) 44119 * can_create_pseudo_p: Standard Names. (line 75) 44120 * can_fallthru: Basic Blocks. (line 57) 44121 * canadian: Configure Terms. (line 6) 44122 * CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 522) 44123 * CANNOT_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 44124 (line 280) 44125 * canonicalization of instructions: Insn Canonicalizations. 44126 (line 6) 44127 * CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 44128 (line 55) 44129 * canonicalize_funcptr_for_compare instruction pattern: Standard Names. 44130 (line 1158) 44131 * CASE_USE_BIT_TESTS: Misc. (line 54) 44132 * CASE_VECTOR_MODE: Misc. (line 27) 44133 * CASE_VECTOR_PC_RELATIVE: Misc. (line 40) 44134 * CASE_VECTOR_SHORTEN_MODE: Misc. (line 31) 44135 * casesi instruction pattern: Standard Names. (line 1082) 44136 * cbranchMODE4 instruction pattern: Standard Names. (line 963) 44137 * cc0 <1>: Regs and Memory. (line 307) 44138 * cc0: CC0 Condition Codes. 44139 (line 6) 44140 * cc0, RTL sharing: Sharing. (line 27) 44141 * cc0_rtx: Regs and Memory. (line 333) 44142 * CC1_SPEC: Driver. (line 56) 44143 * CC1PLUS_SPEC: Driver. (line 64) 44144 * cc_status: CC0 Condition Codes. 44145 (line 6) 44146 * CC_STATUS_MDEP: CC0 Condition Codes. 44147 (line 17) 44148 * CC_STATUS_MDEP_INIT: CC0 Condition Codes. 44149 (line 23) 44150 * CCmode <1>: Machine Modes. (line 176) 44151 * CCmode: MODE_CC Condition Codes. 44152 (line 6) 44153 * CDImode: Machine Modes. (line 202) 44154 * CEIL_DIV_EXPR: Unary and Binary Expressions. 44155 (line 6) 44156 * CEIL_MOD_EXPR: Unary and Binary Expressions. 44157 (line 6) 44158 * ceilM2 instruction pattern: Standard Names. (line 583) 44159 * CFA_FRAME_BASE_OFFSET: Frame Layout. (line 226) 44160 * CFG, Control Flow Graph: Control Flow. (line 6) 44161 * cfghooks.h: Maintaining the CFG. 44162 (line 6) 44163 * cgraph_finalize_function: Parsing pass. (line 52) 44164 * chain_circular: GTY Options. (line 191) 44165 * chain_next: GTY Options. (line 191) 44166 * chain_prev: GTY Options. (line 191) 44167 * change_address: Standard Names. (line 47) 44168 * CHAR_TYPE_SIZE: Type Layout. (line 39) 44169 * check_stack instruction pattern: Standard Names. (line 1245) 44170 * CHImode: Machine Modes. (line 202) 44171 * class definitions, register: Register Classes. (line 6) 44172 * class preference constraints: Class Preferences. (line 6) 44173 * class, scope: Classes. (line 6) 44174 * CLASS_MAX_NREGS: Register Classes. (line 510) 44175 * CLASS_TYPE_P: Types for C++. (line 65) 44176 * classes of RTX codes: RTL Classes. (line 6) 44177 * CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 44178 * CLASSTYPE_HAS_MUTABLE: Classes. (line 85) 44179 * CLASSTYPE_NON_POD_P: Classes. (line 90) 44180 * CLEANUP_DECL: Statements for C++. (line 6) 44181 * CLEANUP_EXPR: Statements for C++. (line 6) 44182 * CLEANUP_POINT_EXPR: Unary and Binary Expressions. 44183 (line 6) 44184 * CLEANUP_STMT: Statements for C++. (line 6) 44185 * Cleanups: Cleanups. (line 6) 44186 * CLEAR_BY_PIECES_P: Costs. (line 188) 44187 * clear_cache instruction pattern: Standard Names. (line 1561) 44188 * CLEAR_INSN_CACHE: Trampolines. (line 99) 44189 * CLEAR_RATIO: Costs. (line 176) 44190 * clobber: Side Effects. (line 100) 44191 * clz: Arithmetic. (line 217) 44192 * CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 319) 44193 * clzM2 instruction pattern: Standard Names. (line 648) 44194 * cmpmemM instruction pattern: Standard Names. (line 781) 44195 * cmpstrM instruction pattern: Standard Names. (line 760) 44196 * cmpstrnM instruction pattern: Standard Names. (line 747) 44197 * code generation RTL sequences: Expander Definitions. 44198 (line 6) 44199 * code iterators in .md files: Code Iterators. (line 6) 44200 * code_label: Insns. (line 119) 44201 * code_label and /i: Flags. (line 59) 44202 * code_label and /v: Flags. (line 44) 44203 * CODE_LABEL_NUMBER: Insns. (line 119) 44204 * codes, RTL expression: RTL Objects. (line 47) 44205 * COImode: Machine Modes. (line 202) 44206 * COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 44207 * COLLECT_EXPORT_LIST: Misc. (line 753) 44208 * COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 44209 (line 44) 44210 * COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 44211 (line 33) 44212 * commit_edge_insertions: Maintaining the CFG. 44213 (line 118) 44214 * compare: Arithmetic. (line 43) 44215 * compare, canonicalization of: Insn Canonicalizations. 44216 (line 37) 44217 * comparison_operator: Machine-Independent Predicates. 44218 (line 111) 44219 * compiler passes and files: Passes. (line 6) 44220 * complement, bitwise: Arithmetic. (line 154) 44221 * COMPLEX_CST: Constant expressions. 44222 (line 6) 44223 * COMPLEX_EXPR: Unary and Binary Expressions. 44224 (line 6) 44225 * COMPLEX_TYPE: Types. (line 6) 44226 * COMPONENT_REF: Storage References. (line 6) 44227 * Compound Expressions: Compound Expressions. 44228 (line 6) 44229 * Compound Lvalues: Compound Lvalues. (line 6) 44230 * COMPOUND_EXPR: Unary and Binary Expressions. 44231 (line 6) 44232 * COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 44233 (line 6) 44234 * COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 44235 (line 367) 44236 * COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 44237 (line 367) 44238 * computed jump: Edges. (line 128) 44239 * computing the length of an insn: Insn Lengths. (line 6) 44240 * concat: Regs and Memory. (line 385) 44241 * concatn: Regs and Memory. (line 391) 44242 * cond: Comparisons. (line 90) 44243 * cond and attributes: Expressions. (line 37) 44244 * cond_exec: Side Effects. (line 248) 44245 * COND_EXPR: Unary and Binary Expressions. 44246 (line 6) 44247 * condition code register: Regs and Memory. (line 307) 44248 * condition code status: Condition Code. (line 6) 44249 * condition codes: Comparisons. (line 20) 44250 * conditional execution <1>: Cond Exec Macros. (line 6) 44251 * conditional execution: Conditional Execution. 44252 (line 6) 44253 * Conditional Expressions: Conditional Expressions. 44254 (line 6) 44255 * conditions, in patterns: Patterns. (line 43) 44256 * configuration file <1>: Filesystem. (line 6) 44257 * configuration file: Host Misc. (line 6) 44258 * configure terms: Configure Terms. (line 6) 44259 * CONJ_EXPR: Unary and Binary Expressions. 44260 (line 6) 44261 * const: Constants. (line 99) 44262 * CONST0_RTX: Constants. (line 119) 44263 * const0_rtx: Constants. (line 16) 44264 * CONST1_RTX: Constants. (line 119) 44265 * const1_rtx: Constants. (line 16) 44266 * CONST2_RTX: Constants. (line 119) 44267 * const2_rtx: Constants. (line 16) 44268 * CONST_DECL: Declarations. (line 6) 44269 * const_double: Constants. (line 32) 44270 * const_double, RTL sharing: Sharing. (line 29) 44271 * CONST_DOUBLE_LOW: Constants. (line 39) 44272 * CONST_DOUBLE_OK_FOR_CONSTRAINT_P: Old Constraints. (line 69) 44273 * CONST_DOUBLE_OK_FOR_LETTER_P: Old Constraints. (line 54) 44274 * const_double_operand: Machine-Independent Predicates. 44275 (line 21) 44276 * const_fixed: Constants. (line 52) 44277 * const_int: Constants. (line 8) 44278 * const_int and attribute tests: Expressions. (line 47) 44279 * const_int and attributes: Expressions. (line 10) 44280 * const_int, RTL sharing: Sharing. (line 23) 44281 * const_int_operand: Machine-Independent Predicates. 44282 (line 16) 44283 * CONST_OK_FOR_CONSTRAINT_P: Old Constraints. (line 49) 44284 * CONST_OK_FOR_LETTER_P: Old Constraints. (line 40) 44285 * const_string: Constants. (line 71) 44286 * const_string and attributes: Expressions. (line 20) 44287 * const_true_rtx: Constants. (line 26) 44288 * const_vector: Constants. (line 59) 44289 * const_vector, RTL sharing: Sharing. (line 32) 44290 * constant attributes: Constant Attributes. 44291 (line 6) 44292 * constant definitions: Constant Definitions. 44293 (line 6) 44294 * CONSTANT_ADDRESS_P: Addressing Modes. (line 29) 44295 * CONSTANT_ALIGNMENT: Storage Layout. (line 229) 44296 * CONSTANT_P: Addressing Modes. (line 36) 44297 * CONSTANT_POOL_ADDRESS_P: Flags. (line 10) 44298 * CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 76) 44299 * constants in constraints: Simple Constraints. (line 70) 44300 * constm1_rtx: Constants. (line 16) 44301 * constraint modifier characters: Modifiers. (line 6) 44302 * constraint, matching: Simple Constraints. (line 142) 44303 * CONSTRAINT_LEN: Old Constraints. (line 12) 44304 * constraint_num: C Constraint Interface. 44305 (line 38) 44306 * constraint_satisfied_p: C Constraint Interface. 44307 (line 54) 44308 * constraints: Constraints. (line 6) 44309 * constraints, defining: Define Constraints. (line 6) 44310 * constraints, defining, obsolete method: Old Constraints. (line 6) 44311 * constraints, machine specific: Machine Constraints. 44312 (line 6) 44313 * constraints, testing: C Constraint Interface. 44314 (line 6) 44315 * CONSTRUCTOR: Unary and Binary Expressions. 44316 (line 6) 44317 * constructors, automatic calls: Collect2. (line 15) 44318 * constructors, output of: Initialization. (line 6) 44319 * container: Containers. (line 6) 44320 * CONTINUE_STMT: Statements for C++. (line 6) 44321 * contributors: Contributors. (line 6) 44322 * controlling register usage: Register Basics. (line 73) 44323 * controlling the compilation driver: Driver. (line 6) 44324 * conventions, run-time: Interface. (line 6) 44325 * conversions: Conversions. (line 6) 44326 * CONVERT_EXPR: Unary and Binary Expressions. 44327 (line 6) 44328 * copy_rtx: Addressing Modes. (line 188) 44329 * copy_rtx_if_shared: Sharing. (line 64) 44330 * copysignM3 instruction pattern: Standard Names. (line 629) 44331 * cosM2 instruction pattern: Standard Names. (line 508) 44332 * costs of instructions: Costs. (line 6) 44333 * CP_INTEGRAL_TYPE: Types for C++. (line 57) 44334 * cp_namespace_decls: Namespaces. (line 49) 44335 * CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 44336 * CP_TYPE_CONST_P: Types for C++. (line 24) 44337 * CP_TYPE_QUALS: Types for C++. (line 6) 44338 * CP_TYPE_RESTRICT_P: Types for C++. (line 30) 44339 * CP_TYPE_VOLATILE_P: Types for C++. (line 27) 44340 * CPLUSPLUS_CPP_SPEC: Driver. (line 51) 44341 * CPP_SPEC: Driver. (line 44) 44342 * CQImode: Machine Modes. (line 202) 44343 * cross compilation and floating point: Floating Point. (line 6) 44344 * CRT_CALL_STATIC_FUNCTION: Sections. (line 122) 44345 * CRTSTUFF_T_CFLAGS: Target Fragment. (line 35) 44346 * CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 39) 44347 * CSImode: Machine Modes. (line 202) 44348 * cstoreMODE4 instruction pattern: Standard Names. (line 924) 44349 * CTImode: Machine Modes. (line 202) 44350 * ctrapMM4 instruction pattern: Standard Names. (line 1386) 44351 * ctz: Arithmetic. (line 225) 44352 * CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 320) 44353 * ctzM2 instruction pattern: Standard Names. (line 657) 44354 * CUMULATIVE_ARGS: Register Arguments. (line 127) 44355 * current_function_epilogue_delay_list: Function Entry. (line 181) 44356 * current_function_is_leaf: Leaf Functions. (line 51) 44357 * current_function_outgoing_args_size: Stack Arguments. (line 48) 44358 * current_function_pops_args: Function Entry. (line 106) 44359 * current_function_pretend_args_size: Function Entry. (line 112) 44360 * current_function_uses_only_leaf_regs: Leaf Functions. (line 51) 44361 * current_insn_predicate: Conditional Execution. 44362 (line 26) 44363 * DAmode: Machine Modes. (line 152) 44364 * data bypass: Processor pipeline description. 44365 (line 106) 44366 * data dependence delays: Processor pipeline description. 44367 (line 6) 44368 * Data Dependency Analysis: Dependency analysis. 44369 (line 6) 44370 * data structures: Per-Function Data. (line 6) 44371 * DATA_ALIGNMENT: Storage Layout. (line 216) 44372 * DATA_SECTION_ASM_OP: Sections. (line 53) 44373 * DBR_OUTPUT_SEQEND: Instruction Output. (line 135) 44374 * dbr_sequence_length: Instruction Output. (line 134) 44375 * DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 103) 44376 * DBX_CONTIN_CHAR: DBX Options. (line 66) 44377 * DBX_CONTIN_LENGTH: DBX Options. (line 56) 44378 * DBX_DEBUGGING_INFO: DBX Options. (line 9) 44379 * DBX_FUNCTION_FIRST: DBX Options. (line 97) 44380 * DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 109) 44381 * DBX_NO_XREFS: DBX Options. (line 50) 44382 * DBX_OUTPUT_LBRAC: DBX Hooks. (line 9) 44383 * DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 34) 44384 * DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9) 44385 * DBX_OUTPUT_NFUN: DBX Hooks. (line 18) 44386 * DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 44387 (line 42) 44388 * DBX_OUTPUT_RBRAC: DBX Hooks. (line 15) 44389 * DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 22) 44390 * DBX_REGISTER_NUMBER: All Debuggers. (line 9) 44391 * DBX_REGPARM_STABS_CODE: DBX Options. (line 87) 44392 * DBX_REGPARM_STABS_LETTER: DBX Options. (line 92) 44393 * DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82) 44394 * DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73) 44395 * DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78) 44396 * DBX_USE_BINCL: DBX Options. (line 115) 44397 * DCmode: Machine Modes. (line 197) 44398 * DDmode: Machine Modes. (line 90) 44399 * De Morgan's law: Insn Canonicalizations. 44400 (line 52) 44401 * dead_or_set_p: define_peephole. (line 65) 44402 * debug_expr: Debug Information. (line 22) 44403 * DEBUG_EXPR_DECL: Declarations. (line 6) 44404 * debug_insn: Insns. (line 239) 44405 * DEBUG_SYMS_TEXT: DBX Options. (line 25) 44406 * DEBUGGER_ARG_OFFSET: All Debuggers. (line 37) 44407 * DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28) 44408 * decimal float library: Decimal float library routines. 44409 (line 6) 44410 * DECL_ALIGN: Declarations. (line 6) 44411 * DECL_ANTICIPATED: Functions for C++. (line 42) 44412 * DECL_ARGUMENTS: Function Basics. (line 36) 44413 * DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 44414 * DECL_ARTIFICIAL <1>: Function Basics. (line 6) 44415 * DECL_ARTIFICIAL <2>: Function Properties. 44416 (line 47) 44417 * DECL_ARTIFICIAL: Working with declarations. 44418 (line 24) 44419 * DECL_ASSEMBLER_NAME: Function Basics. (line 19) 44420 * DECL_ATTRIBUTES: Attributes. (line 22) 44421 * DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 44422 * DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 44423 * DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 44424 * DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 44425 * DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 44426 * DECL_CONTEXT: Namespaces. (line 31) 44427 * DECL_CONV_FN_P: Functions for C++. (line 105) 44428 * DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 44429 * DECL_DESTRUCTOR_P: Functions for C++. (line 95) 44430 * DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 44431 * DECL_EXTERNAL <1>: Function Properties. 44432 (line 25) 44433 * DECL_EXTERNAL: Declarations. (line 6) 44434 * DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 44435 * DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Basics. (line 6) 44436 * DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Properties. 44437 (line 61) 44438 * DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Basics. (line 6) 44439 * DECL_FUNCTION_SPECIFIC_TARGET: Function Properties. 44440 (line 55) 44441 * DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 44442 * DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 44443 * DECL_INITIAL <1>: Function Basics. (line 51) 44444 * DECL_INITIAL: Declarations. (line 6) 44445 * DECL_LINKONCE_P: Functions for C++. (line 50) 44446 * DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 44447 * DECL_MAIN_P: Functions for C++. (line 34) 44448 * DECL_NAME <1>: Function Basics. (line 9) 44449 * DECL_NAME <2>: Namespaces. (line 20) 44450 * DECL_NAME: Working with declarations. 44451 (line 7) 44452 * DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 44453 * DECL_NAMESPACE_STD_P: Namespaces. (line 45) 44454 * DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 44455 * DECL_NONCONVERTING_P: Functions for C++. (line 80) 44456 * DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 44457 * DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 44458 * DECL_PURE_P: Function Properties. 44459 (line 40) 44460 * DECL_RESULT: Function Basics. (line 41) 44461 * DECL_SAVED_TREE: Function Basics. (line 44) 44462 * DECL_SIZE: Declarations. (line 6) 44463 * DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 44464 * DECL_STMT: Statements for C++. (line 6) 44465 * DECL_STMT_DECL: Statements for C++. (line 6) 44466 * DECL_THUNK_P: Functions for C++. (line 116) 44467 * DECL_VIRTUAL_P: Function Properties. 44468 (line 44) 44469 * DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 44470 * declaration: Declarations. (line 6) 44471 * declarations, RTL: RTL Declarations. (line 6) 44472 * DECLARE_LIBRARY_RENAMES: Library Calls. (line 9) 44473 * decrement_and_branch_until_zero instruction pattern: Standard Names. 44474 (line 1120) 44475 * default: GTY Options. (line 77) 44476 * default_file_start: File Framework. (line 8) 44477 * DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18) 44478 * DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 35) 44479 * DEFAULT_SIGNED_CHAR: Type Layout. (line 153) 44480 * define_address_constraint: Define Constraints. (line 107) 44481 * define_asm_attributes: Tagging Insns. (line 73) 44482 * define_attr: Defining Attributes. 44483 (line 6) 44484 * define_automaton: Processor pipeline description. 44485 (line 53) 44486 * define_bypass: Processor pipeline description. 44487 (line 197) 44488 * define_c_enum: Constant Definitions. 44489 (line 49) 44490 * define_code_attr: Code Iterators. (line 6) 44491 * define_code_iterator: Code Iterators. (line 6) 44492 * define_cond_exec: Conditional Execution. 44493 (line 13) 44494 * define_constants: Constant Definitions. 44495 (line 6) 44496 * define_constraint: Define Constraints. (line 48) 44497 * define_cpu_unit: Processor pipeline description. 44498 (line 68) 44499 * define_delay: Delay Slots. (line 25) 44500 * define_enum: Constant Definitions. 44501 (line 118) 44502 * define_enum_attr <1>: Defining Attributes. 44503 (line 64) 44504 * define_enum_attr: Constant Definitions. 44505 (line 136) 44506 * define_expand: Expander Definitions. 44507 (line 11) 44508 * define_insn: Patterns. (line 6) 44509 * define_insn example: Example. (line 6) 44510 * define_insn_and_split: Insn Splitting. (line 170) 44511 * define_insn_reservation: Processor pipeline description. 44512 (line 106) 44513 * define_memory_constraint: Define Constraints. (line 88) 44514 * define_mode_attr: Substitutions. (line 6) 44515 * define_mode_iterator: Defining Mode Iterators. 44516 (line 6) 44517 * define_peephole: define_peephole. (line 6) 44518 * define_peephole2: define_peephole2. (line 6) 44519 * define_predicate: Defining Predicates. 44520 (line 6) 44521 * define_query_cpu_unit: Processor pipeline description. 44522 (line 90) 44523 * define_register_constraint: Define Constraints. (line 28) 44524 * define_reservation: Processor pipeline description. 44525 (line 186) 44526 * define_special_predicate: Defining Predicates. 44527 (line 6) 44528 * define_split: Insn Splitting. (line 32) 44529 * defining attributes and their values: Defining Attributes. 44530 (line 6) 44531 * defining constraints: Define Constraints. (line 6) 44532 * defining constraints, obsolete method: Old Constraints. (line 6) 44533 * defining jump instruction patterns: Jump Patterns. (line 6) 44534 * defining looping instruction patterns: Looping Patterns. (line 6) 44535 * defining peephole optimizers: Peephole Definitions. 44536 (line 6) 44537 * defining predicates: Defining Predicates. 44538 (line 6) 44539 * defining RTL sequences for code generation: Expander Definitions. 44540 (line 6) 44541 * delay slots, defining: Delay Slots. (line 6) 44542 * DELAY_SLOTS_FOR_EPILOGUE: Function Entry. (line 163) 44543 * deletable: GTY Options. (line 145) 44544 * DELETE_IF_ORDINARY: Filesystem. (line 79) 44545 * Dependent Patterns: Dependent Patterns. (line 6) 44546 * desc: GTY Options. (line 77) 44547 * destructors, output of: Initialization. (line 6) 44548 * deterministic finite state automaton: Processor pipeline description. 44549 (line 301) 44550 * DF_SIZE: Type Layout. (line 129) 44551 * DFmode: Machine Modes. (line 73) 44552 * digits in constraint: Simple Constraints. (line 130) 44553 * DImode: Machine Modes. (line 45) 44554 * DIR_SEPARATOR: Filesystem. (line 18) 44555 * DIR_SEPARATOR_2: Filesystem. (line 19) 44556 * directory options .md: Including Patterns. (line 44) 44557 * disabling certain registers: Register Basics. (line 73) 44558 * dispatch table: Dispatch Tables. (line 8) 44559 * div: Arithmetic. (line 116) 44560 * div and attributes: Expressions. (line 64) 44561 * division: Arithmetic. (line 136) 44562 * divM3 instruction pattern: Standard Names. (line 222) 44563 * divmodM4 instruction pattern: Standard Names. (line 438) 44564 * DO_BODY: Statements for C++. (line 6) 44565 * DO_COND: Statements for C++. (line 6) 44566 * DO_STMT: Statements for C++. (line 6) 44567 * DOLLARS_IN_IDENTIFIERS: Misc. (line 451) 44568 * doloop_begin instruction pattern: Standard Names. (line 1151) 44569 * doloop_end instruction pattern: Standard Names. (line 1130) 44570 * DONE: Expander Definitions. 44571 (line 74) 44572 * DONT_USE_BUILTIN_SETJMP: Exception Region Output. 44573 (line 79) 44574 * DOUBLE_TYPE_SIZE: Type Layout. (line 53) 44575 * DQmode: Machine Modes. (line 115) 44576 * driver: Driver. (line 6) 44577 * DRIVER_SELF_SPECS: Driver. (line 9) 44578 * DUMPFILE_FORMAT: Filesystem. (line 67) 44579 * DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 50) 44580 * DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13) 44581 * DWARF2_FRAME_INFO: SDB and DWARF. (line 30) 44582 * DWARF2_FRAME_REG_OUT: Frame Registers. (line 150) 44583 * DWARF2_UNWIND_INFO: Exception Region Output. 44584 (line 40) 44585 * DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 152) 44586 * DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 44587 (line 84) 44588 * DWARF_FRAME_REGISTERS: Frame Registers. (line 110) 44589 * DWARF_FRAME_REGNUM: Frame Registers. (line 142) 44590 * DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134) 44591 * DWARF_ZERO_REG: Frame Layout. (line 163) 44592 * DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 92) 44593 * E in constraint: Simple Constraints. (line 89) 44594 * earlyclobber operand: Modifiers. (line 25) 44595 * edge: Edges. (line 6) 44596 * edge in the flow graph: Edges. (line 6) 44597 * edge iterators: Edges. (line 15) 44598 * edge splitting: Maintaining the CFG. 44599 (line 118) 44600 * EDGE_ABNORMAL: Edges. (line 128) 44601 * EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171) 44602 * EDGE_ABNORMAL, EDGE_EH: Edges. (line 96) 44603 * EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 122) 44604 * EDGE_FALLTHRU, force_nonfallthru: Edges. (line 86) 44605 * EDOM, implicit usage: Library Calls. (line 44) 44606 * EH_FRAME_IN_DATA_SECTION: Exception Region Output. 44607 (line 20) 44608 * EH_FRAME_SECTION_NAME: Exception Region Output. 44609 (line 10) 44610 * eh_return instruction pattern: Standard Names. (line 1326) 44611 * EH_RETURN_DATA_REGNO: Exception Handling. (line 7) 44612 * EH_RETURN_HANDLER_RTX: Exception Handling. (line 39) 44613 * EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22) 44614 * EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 44615 (line 29) 44616 * EH_USES: Function Entry. (line 158) 44617 * ei_edge: Edges. (line 43) 44618 * ei_end_p: Edges. (line 27) 44619 * ei_last: Edges. (line 23) 44620 * ei_next: Edges. (line 35) 44621 * ei_one_before_end_p: Edges. (line 31) 44622 * ei_prev: Edges. (line 39) 44623 * ei_safe_safe: Edges. (line 47) 44624 * ei_start: Edges. (line 19) 44625 * ELIGIBLE_FOR_EPILOGUE_DELAY: Function Entry. (line 169) 44626 * ELIMINABLE_REGS: Elimination. (line 47) 44627 * ELSE_CLAUSE: Statements for C++. (line 6) 44628 * Embedded C: Fixed-point fractional library routines. 44629 (line 6) 44630 * EMIT_MODE_SET: Mode Switching. (line 74) 44631 * Empty Statements: Empty Statements. (line 6) 44632 * EMPTY_CLASS_EXPR: Statements for C++. (line 6) 44633 * EMPTY_FIELD_BOUNDARY: Storage Layout. (line 292) 44634 * Emulated TLS: Emulated TLS. (line 6) 44635 * ENABLE_EXECUTE_STACK: Trampolines. (line 109) 44636 * enabled: Disable Insn Alternatives. 44637 (line 6) 44638 * ENDFILE_SPEC: Driver. (line 156) 44639 * endianness: Portability. (line 21) 44640 * ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 28) 44641 * enum machine_mode: Machine Modes. (line 6) 44642 * enum reg_class: Register Classes. (line 67) 44643 * ENUMERAL_TYPE: Types. (line 6) 44644 * enumerations: Constant Definitions. 44645 (line 49) 44646 * epilogue: Function Entry. (line 6) 44647 * epilogue instruction pattern: Standard Names. (line 1358) 44648 * EPILOGUE_USES: Function Entry. (line 152) 44649 * eq: Comparisons. (line 52) 44650 * eq and attributes: Expressions. (line 64) 44651 * eq_attr: Expressions. (line 85) 44652 * EQ_EXPR: Unary and Binary Expressions. 44653 (line 6) 44654 * equal: Comparisons. (line 52) 44655 * errno, implicit usage: Library Calls. (line 56) 44656 * EXACT_DIV_EXPR: Unary and Binary Expressions. 44657 (line 6) 44658 * examining SSA_NAMEs: SSA. (line 218) 44659 * exception handling <1>: Edges. (line 96) 44660 * exception handling: Exception Handling. (line 6) 44661 * exception_receiver instruction pattern: Standard Names. (line 1290) 44662 * exclamation point: Multi-Alternative. (line 47) 44663 * exclusion_set: Processor pipeline description. 44664 (line 220) 44665 * exclusive-or, bitwise: Arithmetic. (line 168) 44666 * EXIT_EXPR: Unary and Binary Expressions. 44667 (line 6) 44668 * EXIT_IGNORE_STACK: Function Entry. (line 140) 44669 * expander definitions: Expander Definitions. 44670 (line 6) 44671 * expM2 instruction pattern: Standard Names. (line 524) 44672 * EXPR_FILENAME: Working with declarations. 44673 (line 14) 44674 * EXPR_LINENO: Working with declarations. 44675 (line 20) 44676 * expr_list: Insns. (line 545) 44677 * EXPR_STMT: Statements for C++. (line 6) 44678 * EXPR_STMT_EXPR: Statements for C++. (line 6) 44679 * expression: Expression trees. (line 6) 44680 * expression codes: RTL Objects. (line 47) 44681 * extendMN2 instruction pattern: Standard Names. (line 839) 44682 * extensible constraints: Simple Constraints. (line 173) 44683 * EXTRA_ADDRESS_CONSTRAINT: Old Constraints. (line 123) 44684 * EXTRA_CONSTRAINT: Old Constraints. (line 74) 44685 * EXTRA_CONSTRAINT_STR: Old Constraints. (line 95) 44686 * EXTRA_MEMORY_CONSTRAINT: Old Constraints. (line 100) 44687 * EXTRA_SPECS: Driver. (line 183) 44688 * extv instruction pattern: Standard Names. (line 875) 44689 * extzv instruction pattern: Standard Names. (line 890) 44690 * F in constraint: Simple Constraints. (line 94) 44691 * FAIL: Expander Definitions. 44692 (line 80) 44693 * fall-thru: Edges. (line 69) 44694 * FATAL_EXIT_CODE: Host Misc. (line 6) 44695 * FDL, GNU Free Documentation License: GNU Free Documentation License. 44696 (line 6) 44697 * features, optional, in system conventions: Run-time Target. 44698 (line 59) 44699 * ffs: Arithmetic. (line 211) 44700 * ffsM2 instruction pattern: Standard Names. (line 638) 44701 * FIELD_DECL: Declarations. (line 6) 44702 * file_end_indicate_exec_stack: File Framework. (line 41) 44703 * files and passes of the compiler: Passes. (line 6) 44704 * files, generated: Files. (line 6) 44705 * final_absence_set: Processor pipeline description. 44706 (line 220) 44707 * FINAL_PRESCAN_INSN: Instruction Output. (line 61) 44708 * final_presence_set: Processor pipeline description. 44709 (line 220) 44710 * final_scan_insn: Function Entry. (line 181) 44711 * final_sequence: Instruction Output. (line 145) 44712 * FIND_BASE_TERM: Addressing Modes. (line 119) 44713 * FINI_ARRAY_SECTION_ASM_OP: Sections. (line 115) 44714 * FINI_SECTION_ASM_OP: Sections. (line 100) 44715 * finite state automaton minimization: Processor pipeline description. 44716 (line 301) 44717 * FIRST_PARM_OFFSET: Frame Layout. (line 67) 44718 * FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 44719 * FIRST_PSEUDO_REGISTER: Register Basics. (line 9) 44720 * FIRST_STACK_REG: Stack Registers. (line 27) 44721 * FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 44722 * fix: Conversions. (line 66) 44723 * FIX_TRUNC_EXPR: Unary and Binary Expressions. 44724 (line 6) 44725 * fix_truncMN2 instruction pattern: Standard Names. (line 826) 44726 * fixed register: Register Basics. (line 15) 44727 * fixed-point fractional library: Fixed-point fractional library routines. 44728 (line 6) 44729 * FIXED_CONVERT_EXPR: Unary and Binary Expressions. 44730 (line 6) 44731 * FIXED_CST: Constant expressions. 44732 (line 6) 44733 * FIXED_POINT_TYPE: Types. (line 6) 44734 * FIXED_REGISTERS: Register Basics. (line 15) 44735 * fixed_regs: Register Basics. (line 59) 44736 * fixMN2 instruction pattern: Standard Names. (line 806) 44737 * FIXUNS_TRUNC_LIKE_FIX_TRUNC: Misc. (line 100) 44738 * fixuns_truncMN2 instruction pattern: Standard Names. (line 830) 44739 * fixunsMN2 instruction pattern: Standard Names. (line 815) 44740 * flags in RTL expression: Flags. (line 6) 44741 * float: Conversions. (line 58) 44742 * FLOAT_EXPR: Unary and Binary Expressions. 44743 (line 6) 44744 * float_extend: Conversions. (line 33) 44745 * FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 25) 44746 * FLOAT_STORE_FLAG_VALUE: Misc. (line 301) 44747 * float_truncate: Conversions. (line 53) 44748 * FLOAT_TYPE_SIZE: Type Layout. (line 49) 44749 * FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 36) 44750 * FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 44751 (line 226) 44752 * floating point and cross compilation: Floating Point. (line 6) 44753 * Floating Point Emulation: Target Fragment. (line 15) 44754 * floatMN2 instruction pattern: Standard Names. (line 798) 44755 * floatunsMN2 instruction pattern: Standard Names. (line 802) 44756 * FLOOR_DIV_EXPR: Unary and Binary Expressions. 44757 (line 6) 44758 * FLOOR_MOD_EXPR: Unary and Binary Expressions. 44759 (line 6) 44760 * floorM2 instruction pattern: Standard Names. (line 559) 44761 * flow-insensitive alias analysis: Alias analysis. (line 6) 44762 * flow-sensitive alias analysis: Alias analysis. (line 6) 44763 * fma: Arithmetic. (line 111) 44764 * fmaM4 instruction pattern: Standard Names. (line 234) 44765 * fmodM3 instruction pattern: Standard Names. (line 490) 44766 * fmsM4 instruction pattern: Standard Names. (line 243) 44767 * fnmaM4 instruction pattern: Standard Names. (line 249) 44768 * fnmsM4 instruction pattern: Standard Names. (line 255) 44769 * FOR_BODY: Statements for C++. (line 6) 44770 * FOR_COND: Statements for C++. (line 6) 44771 * FOR_EXPR: Statements for C++. (line 6) 44772 * FOR_INIT_STMT: Statements for C++. (line 6) 44773 * FOR_STMT: Statements for C++. (line 6) 44774 * FORCE_CODE_SECTION_ALIGN: Sections. (line 146) 44775 * force_reg: Standard Names. (line 36) 44776 * fract_convert: Conversions. (line 82) 44777 * FRACT_TYPE_SIZE: Type Layout. (line 68) 44778 * fractional types: Fixed-point fractional library routines. 44779 (line 6) 44780 * fractMN2 instruction pattern: Standard Names. (line 848) 44781 * fractunsMN2 instruction pattern: Standard Names. (line 863) 44782 * frame layout: Frame Layout. (line 6) 44783 * FRAME_ADDR_RTX: Frame Layout. (line 116) 44784 * FRAME_GROWS_DOWNWARD: Frame Layout. (line 31) 44785 * FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 44786 (line 69) 44787 * FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 212) 44788 * frame_pointer_needed: Function Entry. (line 34) 44789 * FRAME_POINTER_REGNUM: Frame Registers. (line 14) 44790 * FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 44791 (line 74) 44792 * frame_pointer_rtx: Frame Registers. (line 104) 44793 * frame_related: Flags. (line 247) 44794 * frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 44795 (line 125) 44796 * frame_related, in mem: Flags. (line 103) 44797 * frame_related, in reg: Flags. (line 112) 44798 * frame_related, in symbol_ref: Flags. (line 183) 44799 * frequency, count, BB_FREQ_BASE: Profile information. 44800 (line 30) 44801 * ftruncM2 instruction pattern: Standard Names. (line 821) 44802 * function <1>: Functions for C++. (line 6) 44803 * function: Functions. (line 6) 44804 * function call conventions: Interface. (line 6) 44805 * function entry and exit: Function Entry. (line 6) 44806 * function entry point, alternate function entry point: Edges. 44807 (line 180) 44808 * function properties: Function Properties. 44809 (line 6) 44810 * function-call insns: Calls. (line 6) 44811 * FUNCTION_ARG: Register Arguments. (line 11) 44812 * FUNCTION_ARG_ADVANCE: Register Arguments. (line 185) 44813 * FUNCTION_ARG_OFFSET: Register Arguments. (line 196) 44814 * FUNCTION_ARG_PADDING: Register Arguments. (line 203) 44815 * FUNCTION_ARG_REGNO_P: Register Arguments. (line 244) 44816 * FUNCTION_BOUNDARY: Storage Layout. (line 158) 44817 * FUNCTION_DECL <1>: Functions. (line 6) 44818 * FUNCTION_DECL: Functions for C++. (line 6) 44819 * FUNCTION_INCOMING_ARG: Register Arguments. (line 68) 44820 * FUNCTION_MODE: Misc. (line 356) 44821 * FUNCTION_PROFILER: Profiling. (line 9) 44822 * FUNCTION_TYPE: Types. (line 6) 44823 * FUNCTION_VALUE: Scalar Return. (line 52) 44824 * FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78) 44825 * functions, leaf: Leaf Functions. (line 6) 44826 * fundamental type: Types. (line 6) 44827 * G in constraint: Simple Constraints. (line 98) 44828 * g in constraint: Simple Constraints. (line 120) 44829 * garbage collector, invocation: Invoking the garbage collector. 44830 (line 6) 44831 * garbage collector, troubleshooting: Troubleshooting. (line 6) 44832 * GCC and portability: Portability. (line 6) 44833 * GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 44834 * gcov_type: Profile information. 44835 (line 41) 44836 * ge: Comparisons. (line 72) 44837 * ge and attributes: Expressions. (line 64) 44838 * GE_EXPR: Unary and Binary Expressions. 44839 (line 6) 44840 * GEN_ERRNO_RTX: Library Calls. (line 57) 44841 * gencodes: RTL passes. (line 18) 44842 * general_operand: Machine-Independent Predicates. 44843 (line 105) 44844 * GENERAL_REGS: Register Classes. (line 23) 44845 * generated files: Files. (line 6) 44846 * generating assembler output: Output Statement. (line 6) 44847 * generating insns: RTL Template. (line 6) 44848 * GENERIC <1>: GENERIC. (line 6) 44849 * GENERIC: Parsing pass. (line 6) 44850 * generic predicates: Machine-Independent Predicates. 44851 (line 6) 44852 * genflags: RTL passes. (line 18) 44853 * get_attr: Expressions. (line 80) 44854 * get_attr_length: Insn Lengths. (line 46) 44855 * GET_CLASS_NARROWEST_MODE: Machine Modes. (line 333) 44856 * GET_CODE: RTL Objects. (line 47) 44857 * get_frame_size: Elimination. (line 34) 44858 * get_insns: Insns. (line 34) 44859 * get_last_insn: Insns. (line 34) 44860 * GET_MODE: Machine Modes. (line 280) 44861 * GET_MODE_ALIGNMENT: Machine Modes. (line 320) 44862 * GET_MODE_BITSIZE: Machine Modes. (line 304) 44863 * GET_MODE_CLASS: Machine Modes. (line 294) 44864 * GET_MODE_FBIT: Machine Modes. (line 311) 44865 * GET_MODE_IBIT: Machine Modes. (line 307) 44866 * GET_MODE_MASK: Machine Modes. (line 315) 44867 * GET_MODE_NAME: Machine Modes. (line 291) 44868 * GET_MODE_NUNITS: Machine Modes. (line 329) 44869 * GET_MODE_SIZE: Machine Modes. (line 301) 44870 * GET_MODE_UNIT_SIZE: Machine Modes. (line 323) 44871 * GET_MODE_WIDER_MODE: Machine Modes. (line 297) 44872 * GET_RTX_CLASS: RTL Classes. (line 6) 44873 * GET_RTX_FORMAT: RTL Classes. (line 131) 44874 * GET_RTX_LENGTH: RTL Classes. (line 128) 44875 * geu: Comparisons. (line 72) 44876 * geu and attributes: Expressions. (line 64) 44877 * GGC: Type Information. (line 6) 44878 * ggc_collect: Invoking the garbage collector. 44879 (line 6) 44880 * GIMPLE <1>: Gimplification pass. 44881 (line 6) 44882 * GIMPLE <2>: GIMPLE. (line 6) 44883 * GIMPLE: Parsing pass. (line 14) 44884 * GIMPLE Exception Handling: GIMPLE Exception Handling. 44885 (line 6) 44886 * GIMPLE instruction set: GIMPLE instruction set. 44887 (line 6) 44888 * GIMPLE sequences: GIMPLE sequences. (line 6) 44889 * gimple_addresses_taken: Manipulating GIMPLE statements. 44890 (line 90) 44891 * GIMPLE_ASM: GIMPLE_ASM. (line 6) 44892 * gimple_asm_clear_volatile: GIMPLE_ASM. (line 63) 44893 * gimple_asm_clobber_op: GIMPLE_ASM. (line 46) 44894 * gimple_asm_input_op: GIMPLE_ASM. (line 30) 44895 * gimple_asm_nclobbers: GIMPLE_ASM. (line 27) 44896 * gimple_asm_ninputs: GIMPLE_ASM. (line 21) 44897 * gimple_asm_noutputs: GIMPLE_ASM. (line 24) 44898 * gimple_asm_output_op: GIMPLE_ASM. (line 38) 44899 * gimple_asm_set_clobber_op: GIMPLE_ASM. (line 50) 44900 * gimple_asm_set_input_op: GIMPLE_ASM. (line 34) 44901 * gimple_asm_set_output_op: GIMPLE_ASM. (line 42) 44902 * gimple_asm_set_volatile: GIMPLE_ASM. (line 60) 44903 * gimple_asm_string: GIMPLE_ASM. (line 53) 44904 * gimple_asm_volatile_p: GIMPLE_ASM. (line 57) 44905 * GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 44906 * gimple_assign_cast_p <1>: Logical Operators. (line 160) 44907 * gimple_assign_cast_p: GIMPLE_ASSIGN. (line 93) 44908 * gimple_assign_lhs: GIMPLE_ASSIGN. (line 51) 44909 * gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 54) 44910 * gimple_assign_rhs1: GIMPLE_ASSIGN. (line 57) 44911 * gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 60) 44912 * gimple_assign_rhs2: GIMPLE_ASSIGN. (line 64) 44913 * gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 67) 44914 * gimple_assign_rhs3: GIMPLE_ASSIGN. (line 71) 44915 * gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 74) 44916 * gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 46) 44917 * gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 41) 44918 * gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 78) 44919 * gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 81) 44920 * gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 85) 44921 * gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 89) 44922 * gimple_bb: Manipulating GIMPLE statements. 44923 (line 18) 44924 * GIMPLE_BIND: GIMPLE_BIND. (line 6) 44925 * gimple_bind_add_seq: GIMPLE_BIND. (line 36) 44926 * gimple_bind_add_stmt: GIMPLE_BIND. (line 32) 44927 * gimple_bind_append_vars: GIMPLE_BIND. (line 19) 44928 * gimple_bind_block: GIMPLE_BIND. (line 40) 44929 * gimple_bind_body: GIMPLE_BIND. (line 23) 44930 * gimple_bind_set_block: GIMPLE_BIND. (line 45) 44931 * gimple_bind_set_body: GIMPLE_BIND. (line 28) 44932 * gimple_bind_set_vars: GIMPLE_BIND. (line 15) 44933 * gimple_bind_vars: GIMPLE_BIND. (line 12) 44934 * gimple_block: Manipulating GIMPLE statements. 44935 (line 21) 44936 * gimple_build_asm: GIMPLE_ASM. (line 8) 44937 * gimple_build_asm_vec: GIMPLE_ASM. (line 17) 44938 * gimple_build_assign: GIMPLE_ASSIGN. (line 7) 44939 * gimple_build_assign_with_ops: GIMPLE_ASSIGN. (line 30) 44940 * gimple_build_bind: GIMPLE_BIND. (line 8) 44941 * gimple_build_call: GIMPLE_CALL. (line 8) 44942 * gimple_build_call_from_tree: GIMPLE_CALL. (line 16) 44943 * gimple_build_call_vec: GIMPLE_CALL. (line 25) 44944 * gimple_build_catch: GIMPLE_CATCH. (line 8) 44945 * gimple_build_cond: GIMPLE_COND. (line 8) 44946 * gimple_build_cond_from_tree: GIMPLE_COND. (line 16) 44947 * gimple_build_debug_bind: GIMPLE_DEBUG. (line 8) 44948 * gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 8) 44949 * gimple_build_goto: GIMPLE_LABEL. (line 18) 44950 * gimple_build_label: GIMPLE_LABEL. (line 7) 44951 * gimple_build_nop: GIMPLE_NOP. (line 7) 44952 * gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 44953 (line 8) 44954 * gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 44955 (line 7) 44956 * gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 44957 (line 8) 44958 * gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 44959 (line 8) 44960 * gimple_build_omp_for: GIMPLE_OMP_FOR. (line 9) 44961 * gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 7) 44962 * gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 7) 44963 * gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 44964 (line 8) 44965 * gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 7) 44966 * gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 7) 44967 * gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 44968 (line 8) 44969 * gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 44970 (line 14) 44971 * gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 8) 44972 * gimple_build_resx: GIMPLE_RESX. (line 7) 44973 * gimple_build_return: GIMPLE_RETURN. (line 7) 44974 * gimple_build_switch: GIMPLE_SWITCH. (line 8) 44975 * gimple_build_switch_vec: GIMPLE_SWITCH. (line 16) 44976 * gimple_build_try: GIMPLE_TRY. (line 8) 44977 * gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 44978 (line 7) 44979 * GIMPLE_CALL: GIMPLE_CALL. (line 6) 44980 * gimple_call_arg: GIMPLE_CALL. (line 66) 44981 * gimple_call_arg_ptr: GIMPLE_CALL. (line 71) 44982 * gimple_call_cannot_inline_p: GIMPLE_CALL. (line 91) 44983 * gimple_call_chain: GIMPLE_CALL. (line 57) 44984 * gimple_call_copy_skip_args: GIMPLE_CALL. (line 98) 44985 * gimple_call_fn: GIMPLE_CALL. (line 38) 44986 * gimple_call_fndecl: GIMPLE_CALL. (line 46) 44987 * gimple_call_lhs: GIMPLE_CALL. (line 29) 44988 * gimple_call_lhs_ptr: GIMPLE_CALL. (line 32) 44989 * gimple_call_mark_uninlinable: GIMPLE_CALL. (line 88) 44990 * gimple_call_noreturn_p: GIMPLE_CALL. (line 94) 44991 * gimple_call_num_args: GIMPLE_CALL. (line 63) 44992 * gimple_call_return_type: GIMPLE_CALL. (line 54) 44993 * gimple_call_set_arg: GIMPLE_CALL. (line 76) 44994 * gimple_call_set_chain: GIMPLE_CALL. (line 60) 44995 * gimple_call_set_fn: GIMPLE_CALL. (line 42) 44996 * gimple_call_set_fndecl: GIMPLE_CALL. (line 51) 44997 * gimple_call_set_lhs: GIMPLE_CALL. (line 35) 44998 * gimple_call_set_tail: GIMPLE_CALL. (line 80) 44999 * gimple_call_tail_p: GIMPLE_CALL. (line 85) 45000 * GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 45001 * gimple_catch_handler: GIMPLE_CATCH. (line 20) 45002 * gimple_catch_set_handler: GIMPLE_CATCH. (line 28) 45003 * gimple_catch_set_types: GIMPLE_CATCH. (line 24) 45004 * gimple_catch_types: GIMPLE_CATCH. (line 13) 45005 * gimple_catch_types_ptr: GIMPLE_CATCH. (line 16) 45006 * gimple_code: Manipulating GIMPLE statements. 45007 (line 15) 45008 * GIMPLE_COND: GIMPLE_COND. (line 6) 45009 * gimple_cond_code: GIMPLE_COND. (line 21) 45010 * gimple_cond_false_label: GIMPLE_COND. (line 60) 45011 * gimple_cond_lhs: GIMPLE_COND. (line 30) 45012 * gimple_cond_make_false: GIMPLE_COND. (line 64) 45013 * gimple_cond_make_true: GIMPLE_COND. (line 67) 45014 * gimple_cond_rhs: GIMPLE_COND. (line 38) 45015 * gimple_cond_set_code: GIMPLE_COND. (line 26) 45016 * gimple_cond_set_false_label: GIMPLE_COND. (line 56) 45017 * gimple_cond_set_lhs: GIMPLE_COND. (line 34) 45018 * gimple_cond_set_rhs: GIMPLE_COND. (line 42) 45019 * gimple_cond_set_true_label: GIMPLE_COND. (line 51) 45020 * gimple_cond_true_label: GIMPLE_COND. (line 46) 45021 * gimple_copy: Manipulating GIMPLE statements. 45022 (line 147) 45023 * GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 45024 * GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 45025 * gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 48) 45026 * gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 53) 45027 * gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 45) 45028 * gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 70) 45029 * gimple_debug_bind_p: Logical Operators. (line 164) 45030 * gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 66) 45031 * gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 62) 45032 * gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 58) 45033 * gimple_def_ops: Manipulating GIMPLE statements. 45034 (line 94) 45035 * GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 45036 * gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 19) 45037 * gimple_eh_filter_must_not_throw: GIMPLE_EH_FILTER. (line 33) 45038 * gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 29) 45039 * gimple_eh_filter_set_must_not_throw: GIMPLE_EH_FILTER. (line 37) 45040 * gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 24) 45041 * gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 12) 45042 * gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 15) 45043 * gimple_expr_code: Manipulating GIMPLE statements. 45044 (line 31) 45045 * gimple_expr_type: Manipulating GIMPLE statements. 45046 (line 24) 45047 * gimple_goto_dest: GIMPLE_LABEL. (line 21) 45048 * gimple_goto_set_dest: GIMPLE_LABEL. (line 24) 45049 * gimple_has_mem_ops: Manipulating GIMPLE statements. 45050 (line 72) 45051 * gimple_has_ops: Manipulating GIMPLE statements. 45052 (line 69) 45053 * gimple_has_volatile_ops: Manipulating GIMPLE statements. 45054 (line 134) 45055 * GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 45056 * gimple_label_label: GIMPLE_LABEL. (line 11) 45057 * gimple_label_set_label: GIMPLE_LABEL. (line 14) 45058 * gimple_loaded_syms: Manipulating GIMPLE statements. 45059 (line 122) 45060 * gimple_locus: Manipulating GIMPLE statements. 45061 (line 42) 45062 * gimple_locus_empty_p: Manipulating GIMPLE statements. 45063 (line 48) 45064 * gimple_modified_p: Manipulating GIMPLE statements. 45065 (line 130) 45066 * gimple_no_warning_p: Manipulating GIMPLE statements. 45067 (line 51) 45068 * GIMPLE_NOP: GIMPLE_NOP. (line 6) 45069 * gimple_nop_p: GIMPLE_NOP. (line 10) 45070 * gimple_num_ops <1>: Logical Operators. (line 78) 45071 * gimple_num_ops: Manipulating GIMPLE statements. 45072 (line 75) 45073 * GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 45074 (line 6) 45075 * gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 45076 (line 17) 45077 * gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 45078 (line 24) 45079 * gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 45080 (line 14) 45081 * gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 45082 (line 21) 45083 * GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 45084 (line 6) 45085 * gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 45086 (line 12) 45087 * gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 45088 (line 15) 45089 * gimple_omp_body: GIMPLE_OMP_PARALLEL. 45090 (line 24) 45091 * GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 45092 (line 6) 45093 * gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 45094 (line 13) 45095 * gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 45096 (line 17) 45097 * gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 45098 (line 24) 45099 * gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 45100 (line 28) 45101 * gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 45102 (line 20) 45103 * gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 45104 (line 31) 45105 * GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 45106 (line 6) 45107 * gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 45108 (line 13) 45109 * gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 45110 (line 16) 45111 * gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 45112 (line 21) 45113 * GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 45114 * gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 20) 45115 * gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 23) 45116 * gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 83) 45117 * gimple_omp_for_final: GIMPLE_OMP_FOR. (line 51) 45118 * gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 54) 45119 * gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 61) 45120 * gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 64) 45121 * gimple_omp_for_index: GIMPLE_OMP_FOR. (line 31) 45122 * gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 34) 45123 * gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 41) 45124 * gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 44) 45125 * gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 70) 45126 * gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 27) 45127 * gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 80) 45128 * gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 58) 45129 * gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 67) 45130 * gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 38) 45131 * gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 48) 45132 * gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 75) 45133 * GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 45134 * GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 45135 * GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 45136 (line 6) 45137 * gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 45138 (line 42) 45139 * gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 45140 (line 46) 45141 * gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 45142 (line 31) 45143 * gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 45144 (line 34) 45145 * gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 45146 (line 16) 45147 * gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 45148 (line 54) 45149 * gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 45150 (line 58) 45151 * gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 45152 (line 51) 45153 * gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 45154 (line 38) 45155 * gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 45156 (line 20) 45157 * gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 45158 (line 62) 45159 * GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 45160 * gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 14) 45161 * gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 11) 45162 * GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 45163 * gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 12) 45164 * gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 16) 45165 * GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 45166 (line 6) 45167 * gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 45168 (line 30) 45169 * gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 45170 (line 33) 45171 * gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 45172 (line 17) 45173 * gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 45174 (line 21) 45175 * gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 45176 (line 37) 45177 * gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 45178 (line 26) 45179 * gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 45180 (line 28) 45181 * GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 45182 * gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 14) 45183 * gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 17) 45184 * gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 21) 45185 * gimple_op <1>: Manipulating GIMPLE statements. 45186 (line 81) 45187 * gimple_op: Logical Operators. (line 81) 45188 * gimple_op_ptr: Manipulating GIMPLE statements. 45189 (line 84) 45190 * gimple_ops <1>: Logical Operators. (line 84) 45191 * gimple_ops: Manipulating GIMPLE statements. 45192 (line 78) 45193 * GIMPLE_PHI: GIMPLE_PHI. (line 6) 45194 * gimple_phi_arg: GIMPLE_PHI. (line 28) 45195 * gimple_phi_capacity: GIMPLE_PHI. (line 10) 45196 * gimple_phi_num_args: GIMPLE_PHI. (line 14) 45197 * gimple_phi_result: GIMPLE_PHI. (line 19) 45198 * gimple_phi_result_ptr: GIMPLE_PHI. (line 22) 45199 * gimple_phi_set_arg: GIMPLE_PHI. (line 33) 45200 * gimple_phi_set_result: GIMPLE_PHI. (line 25) 45201 * gimple_plf: Manipulating GIMPLE statements. 45202 (line 66) 45203 * GIMPLE_RESX: GIMPLE_RESX. (line 6) 45204 * gimple_resx_region: GIMPLE_RESX. (line 13) 45205 * gimple_resx_set_region: GIMPLE_RESX. (line 16) 45206 * GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 45207 * gimple_return_retval: GIMPLE_RETURN. (line 10) 45208 * gimple_return_set_retval: GIMPLE_RETURN. (line 14) 45209 * gimple_seq_add_seq: GIMPLE sequences. (line 32) 45210 * gimple_seq_add_stmt: GIMPLE sequences. (line 26) 45211 * gimple_seq_alloc: GIMPLE sequences. (line 62) 45212 * gimple_seq_copy: GIMPLE sequences. (line 67) 45213 * gimple_seq_deep_copy: GIMPLE sequences. (line 37) 45214 * gimple_seq_empty_p: GIMPLE sequences. (line 70) 45215 * gimple_seq_first: GIMPLE sequences. (line 44) 45216 * gimple_seq_init: GIMPLE sequences. (line 59) 45217 * gimple_seq_last: GIMPLE sequences. (line 47) 45218 * gimple_seq_reverse: GIMPLE sequences. (line 40) 45219 * gimple_seq_set_first: GIMPLE sequences. (line 55) 45220 * gimple_seq_set_last: GIMPLE sequences. (line 51) 45221 * gimple_seq_singleton_p: GIMPLE sequences. (line 79) 45222 * gimple_set_block: Manipulating GIMPLE statements. 45223 (line 39) 45224 * gimple_set_def_ops: Manipulating GIMPLE statements. 45225 (line 98) 45226 * gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 45227 (line 138) 45228 * gimple_set_locus: Manipulating GIMPLE statements. 45229 (line 45) 45230 * gimple_set_op: Manipulating GIMPLE statements. 45231 (line 87) 45232 * gimple_set_plf: Manipulating GIMPLE statements. 45233 (line 62) 45234 * gimple_set_use_ops: Manipulating GIMPLE statements. 45235 (line 105) 45236 * gimple_set_vdef_ops: Manipulating GIMPLE statements. 45237 (line 119) 45238 * gimple_set_visited: Manipulating GIMPLE statements. 45239 (line 55) 45240 * gimple_set_vuse_ops: Manipulating GIMPLE statements. 45241 (line 112) 45242 * gimple_statement_base: Tuple representation. 45243 (line 14) 45244 * gimple_statement_with_ops: Tuple representation. 45245 (line 96) 45246 * gimple_stored_syms: Manipulating GIMPLE statements. 45247 (line 126) 45248 * GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 45249 * gimple_switch_default_label: GIMPLE_SWITCH. (line 46) 45250 * gimple_switch_index: GIMPLE_SWITCH. (line 31) 45251 * gimple_switch_label: GIMPLE_SWITCH. (line 37) 45252 * gimple_switch_num_labels: GIMPLE_SWITCH. (line 22) 45253 * gimple_switch_set_default_label: GIMPLE_SWITCH. (line 50) 45254 * gimple_switch_set_index: GIMPLE_SWITCH. (line 34) 45255 * gimple_switch_set_label: GIMPLE_SWITCH. (line 42) 45256 * gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 27) 45257 * GIMPLE_TRY: GIMPLE_TRY. (line 6) 45258 * gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 20) 45259 * gimple_try_cleanup: GIMPLE_TRY. (line 27) 45260 * gimple_try_eval: GIMPLE_TRY. (line 23) 45261 * gimple_try_kind: GIMPLE_TRY. (line 16) 45262 * gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 32) 45263 * gimple_try_set_cleanup: GIMPLE_TRY. (line 41) 45264 * gimple_try_set_eval: GIMPLE_TRY. (line 36) 45265 * gimple_use_ops: Manipulating GIMPLE statements. 45266 (line 101) 45267 * gimple_vdef_ops: Manipulating GIMPLE statements. 45268 (line 115) 45269 * gimple_visited_p: Manipulating GIMPLE statements. 45270 (line 58) 45271 * gimple_vuse_ops: Manipulating GIMPLE statements. 45272 (line 108) 45273 * gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 45274 (line 11) 45275 * gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 45276 (line 18) 45277 * gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 45278 (line 15) 45279 * gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 45280 (line 22) 45281 * GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 45282 (line 6) 45283 * gimplification <1>: Parsing pass. (line 14) 45284 * gimplification: Gimplification pass. 45285 (line 6) 45286 * gimplifier: Parsing pass. (line 14) 45287 * gimplify_assign: GIMPLE_ASSIGN. (line 19) 45288 * gimplify_expr: Gimplification pass. 45289 (line 18) 45290 * gimplify_function_tree: Gimplification pass. 45291 (line 18) 45292 * GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 45293 * global_regs: Register Basics. (line 59) 45294 * GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 91) 45295 * GO_IF_MODE_DEPENDENT_ADDRESS: Addressing Modes. (line 212) 45296 * greater than: Comparisons. (line 60) 45297 * gsi_after_labels: Sequence iterators. (line 76) 45298 * gsi_bb: Sequence iterators. (line 83) 45299 * gsi_commit_edge_inserts: Sequence iterators. (line 194) 45300 * gsi_commit_one_edge_insert: Sequence iterators. (line 190) 45301 * gsi_end_p: Sequence iterators. (line 60) 45302 * gsi_for_stmt: Sequence iterators. (line 157) 45303 * gsi_insert_after: Sequence iterators. (line 147) 45304 * gsi_insert_before: Sequence iterators. (line 136) 45305 * gsi_insert_on_edge: Sequence iterators. (line 174) 45306 * gsi_insert_on_edge_immediate: Sequence iterators. (line 185) 45307 * gsi_insert_seq_after: Sequence iterators. (line 154) 45308 * gsi_insert_seq_before: Sequence iterators. (line 143) 45309 * gsi_insert_seq_on_edge: Sequence iterators. (line 179) 45310 * gsi_last: Sequence iterators. (line 50) 45311 * gsi_last_bb: Sequence iterators. (line 56) 45312 * gsi_link_after: Sequence iterators. (line 115) 45313 * gsi_link_before: Sequence iterators. (line 105) 45314 * gsi_link_seq_after: Sequence iterators. (line 110) 45315 * gsi_link_seq_before: Sequence iterators. (line 99) 45316 * gsi_move_after: Sequence iterators. (line 161) 45317 * gsi_move_before: Sequence iterators. (line 166) 45318 * gsi_move_to_bb_end: Sequence iterators. (line 171) 45319 * gsi_next: Sequence iterators. (line 66) 45320 * gsi_one_before_end_p: Sequence iterators. (line 63) 45321 * gsi_prev: Sequence iterators. (line 69) 45322 * gsi_remove: Sequence iterators. (line 90) 45323 * gsi_replace: Sequence iterators. (line 130) 45324 * gsi_seq: Sequence iterators. (line 86) 45325 * gsi_split_seq_after: Sequence iterators. (line 120) 45326 * gsi_split_seq_before: Sequence iterators. (line 125) 45327 * gsi_start: Sequence iterators. (line 40) 45328 * gsi_start_bb: Sequence iterators. (line 46) 45329 * gsi_stmt: Sequence iterators. (line 72) 45330 * gsi_stmt_ptr: Sequence iterators. (line 80) 45331 * gt: Comparisons. (line 60) 45332 * gt and attributes: Expressions. (line 64) 45333 * GT_EXPR: Unary and Binary Expressions. 45334 (line 6) 45335 * gtu: Comparisons. (line 64) 45336 * gtu and attributes: Expressions. (line 64) 45337 * GTY: Type Information. (line 6) 45338 * H in constraint: Simple Constraints. (line 98) 45339 * HAmode: Machine Modes. (line 144) 45340 * HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 438) 45341 * HANDLER: Statements for C++. (line 6) 45342 * HANDLER_BODY: Statements for C++. (line 6) 45343 * HANDLER_PARMS: Statements for C++. (line 6) 45344 * hard registers: Regs and Memory. (line 9) 45345 * HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 58) 45346 * HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 51) 45347 * HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20) 45348 * HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53) 45349 * HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 20) 45350 * HARD_REGNO_MODE_OK: Values in Registers. 45351 (line 58) 45352 * HARD_REGNO_NREGS: Values in Registers. 45353 (line 11) 45354 * HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 45355 (line 25) 45356 * HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 45357 (line 43) 45358 * HARD_REGNO_RENAME_OK: Values in Registers. 45359 (line 119) 45360 * HAS_INIT_SECTION: Macros for Initialization. 45361 (line 19) 45362 * HAS_LONG_COND_BRANCH: Misc. (line 9) 45363 * HAS_LONG_UNCOND_BRANCH: Misc. (line 18) 45364 * HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 45365 * HAVE_POST_DECREMENT: Addressing Modes. (line 12) 45366 * HAVE_POST_INCREMENT: Addressing Modes. (line 11) 45367 * HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18) 45368 * HAVE_POST_MODIFY_REG: Addressing Modes. (line 24) 45369 * HAVE_PRE_DECREMENT: Addressing Modes. (line 10) 45370 * HAVE_PRE_INCREMENT: Addressing Modes. (line 9) 45371 * HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17) 45372 * HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23) 45373 * HCmode: Machine Modes. (line 197) 45374 * HFmode: Machine Modes. (line 58) 45375 * high: Constants. (line 109) 45376 * HImode: Machine Modes. (line 29) 45377 * HImode, in insn: Insns. (line 272) 45378 * HONOR_REG_ALLOC_ORDER: Allocation Order. (line 37) 45379 * host configuration: Host Config. (line 6) 45380 * host functions: Host Common. (line 6) 45381 * host hooks: Host Common. (line 6) 45382 * host makefile fragment: Host Fragment. (line 6) 45383 * HOST_BIT_BUCKET: Filesystem. (line 51) 45384 * HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 45385 * HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 12) 45386 * HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 45) 45387 * HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 17) 45388 * HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 26) 45389 * HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 45390 * HOST_LONG_FORMAT: Host Misc. (line 45) 45391 * HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 45392 * HOST_OBJECT_SUFFIX: Filesystem. (line 40) 45393 * HOST_PTR_PRINTF: Host Misc. (line 49) 45394 * HOT_TEXT_SECTION_NAME: Sections. (line 43) 45395 * HQmode: Machine Modes. (line 107) 45396 * i in constraint: Simple Constraints. (line 70) 45397 * I in constraint: Simple Constraints. (line 81) 45398 * identifier: Identifiers. (line 6) 45399 * IDENTIFIER_LENGTH: Identifiers. (line 22) 45400 * IDENTIFIER_NODE: Identifiers. (line 6) 45401 * IDENTIFIER_OPNAME_P: Identifiers. (line 27) 45402 * IDENTIFIER_POINTER: Identifiers. (line 17) 45403 * IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 45404 * IEEE 754-2008: Decimal float library routines. 45405 (line 6) 45406 * IF_COND: Statements for C++. (line 6) 45407 * if_marked: GTY Options. (line 151) 45408 * IF_STMT: Statements for C++. (line 6) 45409 * if_then_else: Comparisons. (line 80) 45410 * if_then_else and attributes: Expressions. (line 32) 45411 * if_then_else usage: Side Effects. (line 56) 45412 * IFCVT_EXTRA_FIELDS: Misc. (line 582) 45413 * IFCVT_INIT_EXTRA_FIELDS: Misc. (line 577) 45414 * IFCVT_MODIFY_CANCEL: Misc. (line 571) 45415 * IFCVT_MODIFY_FINAL: Misc. (line 565) 45416 * IFCVT_MODIFY_INSN: Misc. (line 559) 45417 * IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 552) 45418 * IFCVT_MODIFY_TESTS: Misc. (line 541) 45419 * IMAGPART_EXPR: Unary and Binary Expressions. 45420 (line 6) 45421 * Immediate Uses: SSA Operands. (line 274) 45422 * immediate_operand: Machine-Independent Predicates. 45423 (line 11) 45424 * IMMEDIATE_PREFIX: Instruction Output. (line 155) 45425 * in_struct: Flags. (line 263) 45426 * in_struct, in code_label and note: Flags. (line 59) 45427 * in_struct, in insn and jump_insn and call_insn: Flags. (line 49) 45428 * in_struct, in insn, jump_insn and call_insn: Flags. (line 166) 45429 * in_struct, in mem: Flags. (line 70) 45430 * in_struct, in subreg: Flags. (line 205) 45431 * include: Including Patterns. (line 6) 45432 * INCLUDE_DEFAULTS: Driver. (line 344) 45433 * inclusive-or, bitwise: Arithmetic. (line 163) 45434 * INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 183) 45435 * INCOMING_REGNO: Register Basics. (line 88) 45436 * INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 139) 45437 * INCOMING_STACK_BOUNDARY: Storage Layout. (line 153) 45438 * INDEX_REG_CLASS: Register Classes. (line 136) 45439 * indirect_jump instruction pattern: Standard Names. (line 1078) 45440 * indirect_operand: Machine-Independent Predicates. 45441 (line 71) 45442 * INDIRECT_REF: Storage References. (line 6) 45443 * INIT_ARRAY_SECTION_ASM_OP: Sections. (line 108) 45444 * INIT_CUMULATIVE_ARGS: Register Arguments. (line 149) 45445 * INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 176) 45446 * INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 170) 45447 * INIT_ENVIRONMENT: Driver. (line 306) 45448 * INIT_EXPANDERS: Per-Function Data. (line 39) 45449 * INIT_EXPR: Unary and Binary Expressions. 45450 (line 6) 45451 * init_machine_status: Per-Function Data. (line 45) 45452 * init_one_libfunc: Library Calls. (line 15) 45453 * INIT_SECTION_ASM_OP <1>: Macros for Initialization. 45454 (line 10) 45455 * INIT_SECTION_ASM_OP: Sections. (line 92) 45456 * INITIAL_ELIMINATION_OFFSET: Elimination. (line 85) 45457 * INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 83) 45458 * INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 35) 45459 * initialization routines: Initialization. (line 6) 45460 * inlining: Target Attributes. (line 95) 45461 * insert_insn_on_edge: Maintaining the CFG. 45462 (line 118) 45463 * insn: Insns. (line 63) 45464 * insn and /f: Flags. (line 125) 45465 * insn and /j: Flags. (line 175) 45466 * insn and /s: Flags. (line 166) 45467 * insn and /u: Flags. (line 39) 45468 * insn and /v: Flags. (line 44) 45469 * insn attributes: Insn Attributes. (line 6) 45470 * insn canonicalization: Insn Canonicalizations. 45471 (line 6) 45472 * insn includes: Including Patterns. (line 6) 45473 * insn lengths, computing: Insn Lengths. (line 6) 45474 * insn splitting: Insn Splitting. (line 6) 45475 * insn-attr.h: Defining Attributes. 45476 (line 24) 45477 * INSN_ANNULLED_BRANCH_P: Flags. (line 39) 45478 * INSN_CODE: Insns. (line 298) 45479 * INSN_DELETED_P: Flags. (line 44) 45480 * INSN_FROM_TARGET_P: Flags. (line 49) 45481 * insn_list: Insns. (line 545) 45482 * INSN_REFERENCES_ARE_DELAYED: Misc. (line 480) 45483 * INSN_SETS_ARE_DELAYED: Misc. (line 469) 45484 * INSN_UID: Insns. (line 23) 45485 * INSN_VAR_LOCATION: Insns. (line 239) 45486 * insns: Insns. (line 6) 45487 * insns, generating: RTL Template. (line 6) 45488 * insns, recognizing: RTL Template. (line 6) 45489 * instruction attributes: Insn Attributes. (line 6) 45490 * instruction latency time: Processor pipeline description. 45491 (line 197) 45492 * instruction patterns: Patterns. (line 6) 45493 * instruction splitting: Insn Splitting. (line 6) 45494 * insv instruction pattern: Standard Names. (line 893) 45495 * INT16_TYPE: Type Layout. (line 236) 45496 * INT32_TYPE: Type Layout. (line 237) 45497 * INT64_TYPE: Type Layout. (line 238) 45498 * INT8_TYPE: Type Layout. (line 235) 45499 * INT_FAST16_TYPE: Type Layout. (line 252) 45500 * INT_FAST32_TYPE: Type Layout. (line 253) 45501 * INT_FAST64_TYPE: Type Layout. (line 254) 45502 * INT_FAST8_TYPE: Type Layout. (line 251) 45503 * INT_LEAST16_TYPE: Type Layout. (line 244) 45504 * INT_LEAST32_TYPE: Type Layout. (line 245) 45505 * INT_LEAST64_TYPE: Type Layout. (line 246) 45506 * INT_LEAST8_TYPE: Type Layout. (line 243) 45507 * INT_TYPE_SIZE: Type Layout. (line 12) 45508 * INTEGER_CST: Constant expressions. 45509 (line 6) 45510 * INTEGER_TYPE: Types. (line 6) 45511 * Interdependence of Patterns: Dependent Patterns. (line 6) 45512 * interfacing to GCC output: Interface. (line 6) 45513 * interlock delays: Processor pipeline description. 45514 (line 6) 45515 * intermediate representation lowering: Parsing pass. (line 14) 45516 * INTMAX_TYPE: Type Layout. (line 212) 45517 * INTPTR_TYPE: Type Layout. (line 259) 45518 * introduction: Top. (line 6) 45519 * INVOKE__main: Macros for Initialization. 45520 (line 51) 45521 * ior: Arithmetic. (line 163) 45522 * ior and attributes: Expressions. (line 50) 45523 * ior, canonicalization of: Insn Canonicalizations. 45524 (line 52) 45525 * iorM3 instruction pattern: Standard Names. (line 222) 45526 * IRA_COVER_CLASSES: Register Classes. (line 564) 45527 * IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 45) 45528 * IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 132) 45529 * is_gimple_addressable: Logical Operators. (line 115) 45530 * is_gimple_asm_val: Logical Operators. (line 119) 45531 * is_gimple_assign: Logical Operators. (line 151) 45532 * is_gimple_call: Logical Operators. (line 154) 45533 * is_gimple_call_addr: Logical Operators. (line 122) 45534 * is_gimple_constant: Logical Operators. (line 130) 45535 * is_gimple_debug: Logical Operators. (line 157) 45536 * is_gimple_ip_invariant: Logical Operators. (line 139) 45537 * is_gimple_ip_invariant_address: Logical Operators. (line 144) 45538 * is_gimple_mem_ref_addr: Logical Operators. (line 126) 45539 * is_gimple_min_invariant: Logical Operators. (line 133) 45540 * is_gimple_omp: GIMPLE_OMP_PARALLEL. 45541 (line 65) 45542 * is_gimple_val: Logical Operators. (line 109) 45543 * iterators in .md files: Iterators. (line 6) 45544 * IV analysis on GIMPLE: Scalar evolutions. (line 6) 45545 * IV analysis on RTL: loop-iv. (line 6) 45546 * jump: Flags. (line 314) 45547 * jump instruction pattern: Standard Names. (line 969) 45548 * jump instruction patterns: Jump Patterns. (line 6) 45549 * jump instructions and set: Side Effects. (line 56) 45550 * jump, in call_insn: Flags. (line 179) 45551 * jump, in insn: Flags. (line 175) 45552 * jump, in mem: Flags. (line 79) 45553 * JUMP_ALIGN: Alignment Output. (line 9) 45554 * jump_insn: Insns. (line 73) 45555 * jump_insn and /f: Flags. (line 125) 45556 * jump_insn and /s: Flags. (line 49) 45557 * jump_insn and /u: Flags. (line 39) 45558 * jump_insn and /v: Flags. (line 44) 45559 * JUMP_LABEL: Insns. (line 80) 45560 * JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 152) 45561 * Jumps: Jumps. (line 6) 45562 * LABEL_ALIGN: Alignment Output. (line 58) 45563 * LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 27) 45564 * LABEL_ALT_ENTRY_P: Insns. (line 140) 45565 * LABEL_ALTERNATE_NAME: Edges. (line 180) 45566 * LABEL_DECL: Declarations. (line 6) 45567 * LABEL_KIND: Insns. (line 140) 45568 * LABEL_NUSES: Insns. (line 136) 45569 * LABEL_PRESERVE_P: Flags. (line 59) 45570 * label_ref: Constants. (line 86) 45571 * label_ref and /v: Flags. (line 65) 45572 * label_ref, RTL sharing: Sharing. (line 35) 45573 * LABEL_REF_NONLOCAL_P: Flags. (line 65) 45574 * lang_hooks.gimplify_expr: Gimplification pass. 45575 (line 18) 45576 * lang_hooks.parse_file: Parsing pass. (line 6) 45577 * language-dependent trees: Language-dependent trees. 45578 (line 6) 45579 * language-independent intermediate representation: Parsing pass. 45580 (line 14) 45581 * large return values: Aggregate Return. (line 6) 45582 * LARGEST_EXPONENT_IS_NORMAL: Storage Layout. (line 470) 45583 * LAST_STACK_REG: Stack Registers. (line 31) 45584 * LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 45585 * lceilMN2: Standard Names. (line 624) 45586 * LCSSA: LCSSA. (line 6) 45587 * LD_FINI_SWITCH: Macros for Initialization. 45588 (line 29) 45589 * LD_INIT_SWITCH: Macros for Initialization. 45590 (line 25) 45591 * LDD_SUFFIX: Macros for Initialization. 45592 (line 122) 45593 * le: Comparisons. (line 76) 45594 * le and attributes: Expressions. (line 64) 45595 * LE_EXPR: Unary and Binary Expressions. 45596 (line 6) 45597 * leaf functions: Leaf Functions. (line 6) 45598 * leaf_function_p: Standard Names. (line 1040) 45599 * LEAF_REG_REMAP: Leaf Functions. (line 39) 45600 * LEAF_REGISTERS: Leaf Functions. (line 25) 45601 * left rotate: Arithmetic. (line 195) 45602 * left shift: Arithmetic. (line 173) 45603 * LEGITIMATE_CONSTANT_P: Addressing Modes. (line 230) 45604 * LEGITIMATE_PIC_OPERAND_P: PIC. (line 32) 45605 * LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 151) 45606 * length: GTY Options. (line 50) 45607 * less than: Comparisons. (line 68) 45608 * less than or equal: Comparisons. (line 76) 45609 * leu: Comparisons. (line 76) 45610 * leu and attributes: Expressions. (line 64) 45611 * lfloorMN2: Standard Names. (line 619) 45612 * LIB2FUNCS_EXTRA: Target Fragment. (line 11) 45613 * LIB_SPEC: Driver. (line 108) 45614 * LIBCALL_VALUE: Scalar Return. (line 56) 45615 * libgcc.a: Library Calls. (line 6) 45616 * LIBGCC2_CFLAGS: Target Fragment. (line 8) 45617 * LIBGCC2_HAS_DF_MODE: Type Layout. (line 109) 45618 * LIBGCC2_HAS_TF_MODE: Type Layout. (line 122) 45619 * LIBGCC2_HAS_XF_MODE: Type Layout. (line 116) 45620 * LIBGCC2_LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 103) 45621 * LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 960) 45622 * LIBGCC_SPEC: Driver. (line 116) 45623 * library subroutine names: Library Calls. (line 6) 45624 * LIBRARY_PATH_ENV: Misc. (line 520) 45625 * LIMIT_RELOAD_CLASS: Register Classes. (line 298) 45626 * Linear loop transformations framework: Lambda. (line 6) 45627 * LINK_COMMAND_SPEC: Driver. (line 237) 45628 * LINK_EH_SPEC: Driver. (line 143) 45629 * LINK_ELIMINATE_DUPLICATE_LDIRECTORIES: Driver. (line 247) 45630 * LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 233) 45631 * LINK_LIBGCC_SPECIAL_1: Driver. (line 228) 45632 * LINK_SPEC: Driver. (line 101) 45633 * list: Containers. (line 6) 45634 * Liveness representation: Liveness information. 45635 (line 6) 45636 * lo_sum: Arithmetic. (line 24) 45637 * load address instruction: Simple Constraints. (line 164) 45638 * LOAD_EXTEND_OP: Misc. (line 69) 45639 * load_multiple instruction pattern: Standard Names. (line 137) 45640 * LOCAL_ALIGNMENT: Storage Layout. (line 242) 45641 * LOCAL_CLASS_P: Classes. (line 73) 45642 * LOCAL_DECL_ALIGNMENT: Storage Layout. (line 272) 45643 * LOCAL_INCLUDE_DIR: Driver. (line 313) 45644 * LOCAL_LABEL_PREFIX: Instruction Output. (line 153) 45645 * LOCAL_REGNO: Register Basics. (line 102) 45646 * LOG_LINKS: Insns. (line 317) 45647 * Logical Operators: Logical Operators. (line 6) 45648 * logical-and, bitwise: Arithmetic. (line 158) 45649 * logM2 instruction pattern: Standard Names. (line 532) 45650 * LONG_ACCUM_TYPE_SIZE: Type Layout. (line 93) 45651 * LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 58) 45652 * LONG_FRACT_TYPE_SIZE: Type Layout. (line 73) 45653 * LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 98) 45654 * LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 78) 45655 * LONG_LONG_TYPE_SIZE: Type Layout. (line 33) 45656 * LONG_TYPE_SIZE: Type Layout. (line 22) 45657 * longjmp and automatic variables: Interface. (line 52) 45658 * Loop analysis: Loop representation. 45659 (line 6) 45660 * Loop manipulation: Loop manipulation. (line 6) 45661 * Loop querying: Loop querying. (line 6) 45662 * Loop representation: Loop representation. 45663 (line 6) 45664 * Loop-closed SSA form: LCSSA. (line 6) 45665 * LOOP_ALIGN: Alignment Output. (line 41) 45666 * LOOP_EXPR: Unary and Binary Expressions. 45667 (line 6) 45668 * looping instruction patterns: Looping Patterns. (line 6) 45669 * lowering, language-dependent intermediate representation: Parsing pass. 45670 (line 14) 45671 * lrintMN2: Standard Names. (line 609) 45672 * lroundMN2: Standard Names. (line 614) 45673 * LSHIFT_EXPR: Unary and Binary Expressions. 45674 (line 6) 45675 * lshiftrt: Arithmetic. (line 190) 45676 * lshiftrt and attributes: Expressions. (line 64) 45677 * lshrM3 instruction pattern: Standard Names. (line 468) 45678 * lt: Comparisons. (line 68) 45679 * lt and attributes: Expressions. (line 64) 45680 * LT_EXPR: Unary and Binary Expressions. 45681 (line 6) 45682 * LTGT_EXPR: Unary and Binary Expressions. 45683 (line 6) 45684 * lto: LTO. (line 6) 45685 * ltrans: LTO. (line 6) 45686 * ltu: Comparisons. (line 68) 45687 * m in constraint: Simple Constraints. (line 17) 45688 * machine attributes: Target Attributes. (line 6) 45689 * machine description macros: Target Macros. (line 6) 45690 * machine descriptions: Machine Desc. (line 6) 45691 * machine mode conversions: Conversions. (line 6) 45692 * machine modes: Machine Modes. (line 6) 45693 * machine specific constraints: Machine Constraints. 45694 (line 6) 45695 * machine-independent predicates: Machine-Independent Predicates. 45696 (line 6) 45697 * macros, target description: Target Macros. (line 6) 45698 * maddMN4 instruction pattern: Standard Names. (line 391) 45699 * MAKE_DECL_ONE_ONLY: Label Output. (line 238) 45700 * make_phi_node: GIMPLE_PHI. (line 7) 45701 * make_safe_from: Expander Definitions. 45702 (line 148) 45703 * makefile fragment: Fragments. (line 6) 45704 * makefile targets: Makefile. (line 6) 45705 * MALLOC_ABI_ALIGNMENT: Storage Layout. (line 167) 45706 * Manipulating GIMPLE statements: Manipulating GIMPLE statements. 45707 (line 6) 45708 * mark_hook: GTY Options. (line 166) 45709 * marking roots: GGC Roots. (line 6) 45710 * MASK_RETURN_ADDR: Exception Region Output. 45711 (line 35) 45712 * match_dup <1>: RTL Template. (line 73) 45713 * match_dup: define_peephole2. (line 28) 45714 * match_dup and attributes: Insn Lengths. (line 16) 45715 * match_op_dup: RTL Template. (line 163) 45716 * match_operand: RTL Template. (line 16) 45717 * match_operand and attributes: Expressions. (line 55) 45718 * match_operator: RTL Template. (line 95) 45719 * match_par_dup: RTL Template. (line 219) 45720 * match_parallel: RTL Template. (line 172) 45721 * match_scratch <1>: define_peephole2. (line 28) 45722 * match_scratch: RTL Template. (line 58) 45723 * matching constraint: Simple Constraints. (line 142) 45724 * matching operands: Output Template. (line 49) 45725 * math library: Soft float library routines. 45726 (line 6) 45727 * math, in RTL: Arithmetic. (line 6) 45728 * MATH_LIBRARY: Misc. (line 513) 45729 * matherr: Library Calls. (line 44) 45730 * MAX_BITS_PER_WORD: Storage Layout. (line 54) 45731 * MAX_CONDITIONAL_EXECUTE: Misc. (line 535) 45732 * MAX_FIXED_MODE_SIZE: Storage Layout. (line 417) 45733 * MAX_MOVE_MAX: Misc. (line 120) 45734 * MAX_OFILE_ALIGNMENT: Storage Layout. (line 204) 45735 * MAX_REGS_PER_ADDRESS: Addressing Modes. (line 43) 45736 * MAX_STACK_ALIGNMENT: Storage Layout. (line 197) 45737 * maxM3 instruction pattern: Standard Names. (line 261) 45738 * may_trap_p, tree_could_trap_p: Edges. (line 115) 45739 * maybe_undef: GTY Options. (line 174) 45740 * mcount: Profiling. (line 12) 45741 * MD_CAN_REDIRECT_BRANCH: Misc. (line 682) 45742 * MD_EXEC_PREFIX: Driver. (line 268) 45743 * MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 98) 45744 * MD_HANDLE_UNWABI: Exception Handling. (line 118) 45745 * MD_STARTFILE_PREFIX: Driver. (line 296) 45746 * MD_STARTFILE_PREFIX_1: Driver. (line 301) 45747 * MD_UNWIND_SUPPORT: Exception Handling. (line 94) 45748 * mem: Regs and Memory. (line 374) 45749 * mem and /c: Flags. (line 99) 45750 * mem and /f: Flags. (line 103) 45751 * mem and /i: Flags. (line 85) 45752 * mem and /j: Flags. (line 79) 45753 * mem and /s: Flags. (line 70) 45754 * mem and /u: Flags. (line 152) 45755 * mem and /v: Flags. (line 94) 45756 * mem, RTL sharing: Sharing. (line 40) 45757 * MEM_ADDR_SPACE: Special Accessors. (line 39) 45758 * MEM_ALIAS_SET: Special Accessors. (line 9) 45759 * MEM_ALIGN: Special Accessors. (line 36) 45760 * MEM_EXPR: Special Accessors. (line 20) 45761 * MEM_IN_STRUCT_P: Flags. (line 70) 45762 * MEM_KEEP_ALIAS_SET_P: Flags. (line 79) 45763 * MEM_NOTRAP_P: Flags. (line 99) 45764 * MEM_OFFSET: Special Accessors. (line 28) 45765 * MEM_POINTER: Flags. (line 103) 45766 * MEM_READONLY_P: Flags. (line 152) 45767 * MEM_REF: Storage References. (line 6) 45768 * MEM_SCALAR_P: Flags. (line 85) 45769 * MEM_SIZE: Special Accessors. (line 31) 45770 * MEM_VOLATILE_P: Flags. (line 94) 45771 * MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 397) 45772 * memory model: Memory model. (line 6) 45773 * memory reference, nonoffsettable: Simple Constraints. (line 256) 45774 * memory references in constraints: Simple Constraints. (line 17) 45775 * memory_barrier instruction pattern: Standard Names. (line 1422) 45776 * MEMORY_MOVE_COST: Costs. (line 54) 45777 * memory_operand: Machine-Independent Predicates. 45778 (line 58) 45779 * METHOD_TYPE: Types. (line 6) 45780 * MIN_UNITS_PER_WORD: Storage Layout. (line 64) 45781 * MINIMUM_ALIGNMENT: Storage Layout. (line 285) 45782 * MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 175) 45783 * minM3 instruction pattern: Standard Names. (line 261) 45784 * minus: Arithmetic. (line 36) 45785 * minus and attributes: Expressions. (line 64) 45786 * minus, canonicalization of: Insn Canonicalizations. 45787 (line 27) 45788 * MINUS_EXPR: Unary and Binary Expressions. 45789 (line 6) 45790 * MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 45791 * mod: Arithmetic. (line 136) 45792 * mod and attributes: Expressions. (line 64) 45793 * mode classes: Machine Modes. (line 219) 45794 * mode iterators in .md files: Mode Iterators. (line 6) 45795 * mode switching: Mode Switching. (line 6) 45796 * MODE_ACCUM: Machine Modes. (line 249) 45797 * MODE_AFTER: Mode Switching. (line 49) 45798 * MODE_BASE_REG_CLASS: Register Classes. (line 114) 45799 * MODE_BASE_REG_REG_CLASS: Register Classes. (line 120) 45800 * MODE_CC <1>: Machine Modes. (line 268) 45801 * MODE_CC: MODE_CC Condition Codes. 45802 (line 6) 45803 * MODE_CODE_BASE_REG_CLASS: Register Classes. (line 127) 45804 * MODE_COMPLEX_FLOAT: Machine Modes. (line 260) 45805 * MODE_COMPLEX_INT: Machine Modes. (line 257) 45806 * MODE_DECIMAL_FLOAT: Machine Modes. (line 237) 45807 * MODE_ENTRY: Mode Switching. (line 54) 45808 * MODE_EXIT: Mode Switching. (line 60) 45809 * MODE_FLOAT: Machine Modes. (line 233) 45810 * MODE_FRACT: Machine Modes. (line 241) 45811 * MODE_FUNCTION: Machine Modes. (line 264) 45812 * MODE_INT: Machine Modes. (line 225) 45813 * MODE_NEEDED: Mode Switching. (line 42) 45814 * MODE_PARTIAL_INT: Machine Modes. (line 229) 45815 * MODE_PRIORITY_TO_MODE: Mode Switching. (line 66) 45816 * MODE_RANDOM: Machine Modes. (line 273) 45817 * MODE_UACCUM: Machine Modes. (line 253) 45818 * MODE_UFRACT: Machine Modes. (line 245) 45819 * MODES_TIEABLE_P: Values in Registers. 45820 (line 129) 45821 * modifiers in constraints: Modifiers. (line 6) 45822 * MODIFY_EXPR: Unary and Binary Expressions. 45823 (line 6) 45824 * MODIFY_JNI_METHOD_CALL: Misc. (line 760) 45825 * modM3 instruction pattern: Standard Names. (line 222) 45826 * modulo scheduling: RTL passes. (line 131) 45827 * MOVE_BY_PIECES_P: Costs. (line 165) 45828 * MOVE_MAX: Misc. (line 115) 45829 * MOVE_MAX_PIECES: Costs. (line 171) 45830 * MOVE_RATIO: Costs. (line 149) 45831 * movM instruction pattern: Standard Names. (line 11) 45832 * movmemM instruction pattern: Standard Names. (line 681) 45833 * movmisalignM instruction pattern: Standard Names. (line 126) 45834 * movMODEcc instruction pattern: Standard Names. (line 904) 45835 * movstr instruction pattern: Standard Names. (line 716) 45836 * movstrictM instruction pattern: Standard Names. (line 120) 45837 * msubMN4 instruction pattern: Standard Names. (line 414) 45838 * mulhisi3 instruction pattern: Standard Names. (line 367) 45839 * mulM3 instruction pattern: Standard Names. (line 222) 45840 * mulqihi3 instruction pattern: Standard Names. (line 371) 45841 * mulsidi3 instruction pattern: Standard Names. (line 371) 45842 * mult: Arithmetic. (line 92) 45843 * mult and attributes: Expressions. (line 64) 45844 * mult, canonicalization of: Insn Canonicalizations. 45845 (line 27) 45846 * MULT_EXPR: Unary and Binary Expressions. 45847 (line 6) 45848 * MULTILIB_DEFAULTS: Driver. (line 253) 45849 * MULTILIB_DIRNAMES: Target Fragment. (line 64) 45850 * MULTILIB_EXCEPTIONS: Target Fragment. (line 84) 45851 * MULTILIB_EXTRA_OPTS: Target Fragment. (line 96) 45852 * MULTILIB_MATCHES: Target Fragment. (line 77) 45853 * MULTILIB_OPTIONS: Target Fragment. (line 44) 45854 * multiple alternative constraints: Multi-Alternative. (line 6) 45855 * MULTIPLE_SYMBOL_SPACES: Misc. (line 493) 45856 * multiplication: Arithmetic. (line 92) 45857 * multiplication with signed saturation: Arithmetic. (line 92) 45858 * multiplication with unsigned saturation: Arithmetic. (line 92) 45859 * n in constraint: Simple Constraints. (line 75) 45860 * N_REG_CLASSES: Register Classes. (line 78) 45861 * name: Identifiers. (line 6) 45862 * named address spaces: Named Address Spaces. 45863 (line 6) 45864 * named patterns and conditions: Patterns. (line 47) 45865 * names, pattern: Standard Names. (line 6) 45866 * namespace, scope: Namespaces. (line 6) 45867 * NAMESPACE_DECL <1>: Declarations. (line 6) 45868 * NAMESPACE_DECL: Namespaces. (line 6) 45869 * NATIVE_SYSTEM_HEADER_DIR: Target Fragment. (line 103) 45870 * ne: Comparisons. (line 56) 45871 * ne and attributes: Expressions. (line 64) 45872 * NE_EXPR: Unary and Binary Expressions. 45873 (line 6) 45874 * nearbyintM2 instruction pattern: Standard Names. (line 591) 45875 * neg: Arithmetic. (line 81) 45876 * neg and attributes: Expressions. (line 64) 45877 * neg, canonicalization of: Insn Canonicalizations. 45878 (line 27) 45879 * NEGATE_EXPR: Unary and Binary Expressions. 45880 (line 6) 45881 * negation: Arithmetic. (line 81) 45882 * negation with signed saturation: Arithmetic. (line 81) 45883 * negation with unsigned saturation: Arithmetic. (line 81) 45884 * negM2 instruction pattern: Standard Names. (line 476) 45885 * nested functions, trampolines for: Trampolines. (line 6) 45886 * nested_ptr: GTY Options. (line 181) 45887 * next_bb, prev_bb, FOR_EACH_BB: Basic Blocks. (line 10) 45888 * NEXT_INSN: Insns. (line 30) 45889 * NEXT_OBJC_RUNTIME: Library Calls. (line 80) 45890 * nil: RTL Objects. (line 73) 45891 * NM_FLAGS: Macros for Initialization. 45892 (line 111) 45893 * NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 39) 45894 * NO_DBX_FUNCTION_END: DBX Hooks. (line 33) 45895 * NO_DBX_GCC_MARKER: File Names and DBX. (line 28) 45896 * NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 23) 45897 * NO_DOLLAR_IN_LABEL: Misc. (line 457) 45898 * NO_DOT_IN_LABEL: Misc. (line 463) 45899 * NO_FUNCTION_CSE: Costs. (line 261) 45900 * NO_IMPLICIT_EXTERN_C: Misc. (line 376) 45901 * NO_PROFILE_COUNTERS: Profiling. (line 28) 45902 * NO_REGS: Register Classes. (line 17) 45903 * NON_LVALUE_EXPR: Unary and Binary Expressions. 45904 (line 6) 45905 * nondeterministic finite state automaton: Processor pipeline description. 45906 (line 301) 45907 * nonimmediate_operand: Machine-Independent Predicates. 45908 (line 101) 45909 * nonlocal goto handler: Edges. (line 171) 45910 * nonlocal_goto instruction pattern: Standard Names. (line 1262) 45911 * nonlocal_goto_receiver instruction pattern: Standard Names. 45912 (line 1279) 45913 * nonmemory_operand: Machine-Independent Predicates. 45914 (line 97) 45915 * nonoffsettable memory reference: Simple Constraints. (line 256) 45916 * nop instruction pattern: Standard Names. (line 1073) 45917 * NOP_EXPR: Unary and Binary Expressions. 45918 (line 6) 45919 * normal predicates: Predicates. (line 31) 45920 * not: Arithmetic. (line 154) 45921 * not and attributes: Expressions. (line 50) 45922 * not equal: Comparisons. (line 56) 45923 * not, canonicalization of: Insn Canonicalizations. 45924 (line 27) 45925 * note: Insns. (line 168) 45926 * note and /i: Flags. (line 59) 45927 * note and /v: Flags. (line 44) 45928 * NOTE_INSN_BASIC_BLOCK, CODE_LABEL, notes: Basic Blocks. (line 41) 45929 * NOTE_INSN_BLOCK_BEG: Insns. (line 193) 45930 * NOTE_INSN_BLOCK_END: Insns. (line 193) 45931 * NOTE_INSN_DELETED: Insns. (line 183) 45932 * NOTE_INSN_DELETED_LABEL: Insns. (line 188) 45933 * NOTE_INSN_EH_REGION_BEG: Insns. (line 199) 45934 * NOTE_INSN_EH_REGION_END: Insns. (line 199) 45935 * NOTE_INSN_FUNCTION_BEG: Insns. (line 223) 45936 * NOTE_INSN_LOOP_BEG: Insns. (line 207) 45937 * NOTE_INSN_LOOP_CONT: Insns. (line 213) 45938 * NOTE_INSN_LOOP_END: Insns. (line 207) 45939 * NOTE_INSN_LOOP_VTOP: Insns. (line 217) 45940 * NOTE_INSN_VAR_LOCATION: Insns. (line 227) 45941 * NOTE_LINE_NUMBER: Insns. (line 168) 45942 * NOTE_SOURCE_FILE: Insns. (line 168) 45943 * NOTE_VAR_LOCATION: Insns. (line 227) 45944 * NOTICE_UPDATE_CC: CC0 Condition Codes. 45945 (line 31) 45946 * NUM_MACHINE_MODES: Machine Modes. (line 286) 45947 * NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 45948 * Number of iterations analysis: Number of iterations. 45949 (line 6) 45950 * o in constraint: Simple Constraints. (line 23) 45951 * OBJC_GEN_METHOD_LABEL: Label Output. (line 440) 45952 * OBJC_JBLEN: Misc. (line 955) 45953 * OBJECT_FORMAT_COFF: Macros for Initialization. 45954 (line 97) 45955 * OFFSET_TYPE: Types. (line 6) 45956 * offsettable address: Simple Constraints. (line 23) 45957 * OImode: Machine Modes. (line 51) 45958 * Omega a solver for linear programming problems: Omega. (line 6) 45959 * OMP_ATOMIC: OpenMP. (line 6) 45960 * OMP_CLAUSE: OpenMP. (line 6) 45961 * OMP_CONTINUE: OpenMP. (line 6) 45962 * OMP_CRITICAL: OpenMP. (line 6) 45963 * OMP_FOR: OpenMP. (line 6) 45964 * OMP_MASTER: OpenMP. (line 6) 45965 * OMP_ORDERED: OpenMP. (line 6) 45966 * OMP_PARALLEL: OpenMP. (line 6) 45967 * OMP_RETURN: OpenMP. (line 6) 45968 * OMP_SECTION: OpenMP. (line 6) 45969 * OMP_SECTIONS: OpenMP. (line 6) 45970 * OMP_SINGLE: OpenMP. (line 6) 45971 * one_cmplM2 instruction pattern: Standard Names. (line 678) 45972 * operand access: Accessors. (line 6) 45973 * Operand Access Routines: SSA Operands. (line 119) 45974 * operand constraints: Constraints. (line 6) 45975 * Operand Iterators: SSA Operands. (line 119) 45976 * operand predicates: Predicates. (line 6) 45977 * operand substitution: Output Template. (line 6) 45978 * Operands: Operands. (line 6) 45979 * operands <1>: SSA Operands. (line 6) 45980 * operands: Patterns. (line 53) 45981 * operator predicates: Predicates. (line 6) 45982 * optc-gen.awk: Options. (line 6) 45983 * Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 45984 * OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9) 45985 * option specification files: Options. (line 6) 45986 * OPTION_DEFAULT_SPECS: Driver. (line 26) 45987 * optional hardware or system features: Run-time Target. (line 59) 45988 * options, directory search: Including Patterns. (line 44) 45989 * order of register allocation: Allocation Order. (line 6) 45990 * ordered_comparison_operator: Machine-Independent Predicates. 45991 (line 116) 45992 * ORDERED_EXPR: Unary and Binary Expressions. 45993 (line 6) 45994 * Ordering of Patterns: Pattern Ordering. (line 6) 45995 * ORIGINAL_REGNO: Special Accessors. (line 44) 45996 * other register constraints: Simple Constraints. (line 173) 45997 * OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 74) 45998 * OUTGOING_REGNO: Register Basics. (line 95) 45999 * output of assembler code: File Framework. (line 6) 46000 * output statements: Output Statement. (line 6) 46001 * output templates: Output Template. (line 6) 46002 * OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 51) 46003 * output_asm_insn: Output Statement. (line 53) 46004 * OUTPUT_QUOTED_STRING: File Framework. (line 102) 46005 * OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 21) 46006 * OVERLOAD: Functions for C++. (line 6) 46007 * OVERRIDE_ABI_FORMAT: Register Arguments. (line 140) 46008 * OVL_CURRENT: Functions for C++. (line 6) 46009 * OVL_NEXT: Functions for C++. (line 6) 46010 * p in constraint: Simple Constraints. (line 164) 46011 * PAD_VARARGS_DOWN: Register Arguments. (line 220) 46012 * parallel: Side Effects. (line 204) 46013 * param_is: GTY Options. (line 109) 46014 * parameters, c++ abi: C++ ABI. (line 6) 46015 * parameters, miscellaneous: Misc. (line 6) 46016 * parameters, precompiled headers: PCH Target. (line 6) 46017 * paramN_is: GTY Options. (line 127) 46018 * parity: Arithmetic. (line 237) 46019 * parityM2 instruction pattern: Standard Names. (line 672) 46020 * PARM_BOUNDARY: Storage Layout. (line 132) 46021 * PARM_DECL: Declarations. (line 6) 46022 * PARSE_LDD_OUTPUT: Macros for Initialization. 46023 (line 127) 46024 * passes and files of the compiler: Passes. (line 6) 46025 * passing arguments: Interface. (line 36) 46026 * PATH_SEPARATOR: Filesystem. (line 31) 46027 * PATTERN: Insns. (line 288) 46028 * pattern conditions: Patterns. (line 43) 46029 * pattern names: Standard Names. (line 6) 46030 * Pattern Ordering: Pattern Ordering. (line 6) 46031 * patterns: Patterns. (line 6) 46032 * pc: Regs and Memory. (line 361) 46033 * pc and attributes: Insn Lengths. (line 20) 46034 * pc, RTL sharing: Sharing. (line 25) 46035 * PC_REGNUM: Register Basics. (line 109) 46036 * pc_rtx: Regs and Memory. (line 366) 46037 * PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 311) 46038 * PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 65) 46039 * PDImode: Machine Modes. (line 40) 46040 * peephole optimization, RTL representation: Side Effects. (line 238) 46041 * peephole optimizer definitions: Peephole Definitions. 46042 (line 6) 46043 * per-function data: Per-Function Data. (line 6) 46044 * percent sign: Output Template. (line 6) 46045 * PHI nodes: SSA. (line 31) 46046 * PHI_ARG_DEF: SSA. (line 71) 46047 * PHI_ARG_EDGE: SSA. (line 68) 46048 * PHI_ARG_ELT: SSA. (line 63) 46049 * PHI_NUM_ARGS: SSA. (line 59) 46050 * PHI_RESULT: SSA. (line 56) 46051 * PIC: PIC. (line 6) 46052 * PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26) 46053 * PIC_OFFSET_TABLE_REGNUM: PIC. (line 16) 46054 * pipeline hazard recognizer: Processor pipeline description. 46055 (line 6) 46056 * Plugins: Plugins. (line 6) 46057 * plus: Arithmetic. (line 14) 46058 * plus and attributes: Expressions. (line 64) 46059 * plus, canonicalization of: Insn Canonicalizations. 46060 (line 27) 46061 * PLUS_EXPR: Unary and Binary Expressions. 46062 (line 6) 46063 * Pmode: Misc. (line 344) 46064 * pmode_register_operand: Machine-Independent Predicates. 46065 (line 35) 46066 * pointer: Types. (line 6) 46067 * POINTER_PLUS_EXPR: Unary and Binary Expressions. 46068 (line 6) 46069 * POINTER_SIZE: Storage Layout. (line 70) 46070 * POINTER_TYPE: Types. (line 6) 46071 * POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 76) 46072 * pop_operand: Machine-Independent Predicates. 46073 (line 88) 46074 * popcount: Arithmetic. (line 233) 46075 * popcountM2 instruction pattern: Standard Names. (line 666) 46076 * portability: Portability. (line 6) 46077 * position independent code: PIC. (line 6) 46078 * post_dec: Incdec. (line 25) 46079 * post_inc: Incdec. (line 30) 46080 * post_modify: Incdec. (line 33) 46081 * POSTDECREMENT_EXPR: Unary and Binary Expressions. 46082 (line 6) 46083 * POSTINCREMENT_EXPR: Unary and Binary Expressions. 46084 (line 6) 46085 * POWI_MAX_MULTS: Misc. (line 823) 46086 * powM3 instruction pattern: Standard Names. (line 540) 46087 * pragma: Misc. (line 381) 46088 * pre_dec: Incdec. (line 8) 46089 * PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 127) 46090 * pre_inc: Incdec. (line 22) 46091 * pre_modify: Incdec. (line 51) 46092 * PREDECREMENT_EXPR: Unary and Binary Expressions. 46093 (line 6) 46094 * predefined macros: Run-time Target. (line 6) 46095 * predicates: Predicates. (line 6) 46096 * predicates and machine modes: Predicates. (line 31) 46097 * predication <1>: Cond Exec Macros. (line 6) 46098 * predication: Conditional Execution. 46099 (line 6) 46100 * predict.def: Profile information. 46101 (line 24) 46102 * PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 42) 46103 * PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 278) 46104 * PREFERRED_RELOAD_CLASS: Register Classes. (line 243) 46105 * PREFERRED_STACK_BOUNDARY: Storage Layout. (line 146) 46106 * prefetch: Side Effects. (line 312) 46107 * prefetch and /v: Flags. (line 232) 46108 * prefetch instruction pattern: Standard Names. (line 1401) 46109 * PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 232) 46110 * PREINCREMENT_EXPR: Unary and Binary Expressions. 46111 (line 6) 46112 * presence_set: Processor pipeline description. 46113 (line 220) 46114 * preserving SSA form: SSA. (line 76) 46115 * preserving virtual SSA form: SSA. (line 186) 46116 * prev_active_insn: define_peephole. (line 60) 46117 * PREV_INSN: Insns. (line 26) 46118 * PRINT_OPERAND: Instruction Output. (line 96) 46119 * PRINT_OPERAND_ADDRESS: Instruction Output. (line 124) 46120 * PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 117) 46121 * probe_stack instruction pattern: Standard Names. (line 1254) 46122 * processor functional units: Processor pipeline description. 46123 (line 6) 46124 * processor pipeline description: Processor pipeline description. 46125 (line 6) 46126 * product: Arithmetic. (line 92) 46127 * profile feedback: Profile information. 46128 (line 14) 46129 * profile representation: Profile information. 46130 (line 6) 46131 * PROFILE_BEFORE_PROLOGUE: Profiling. (line 35) 46132 * PROFILE_HOOK: Profiling. (line 23) 46133 * profiling, code generation: Profiling. (line 6) 46134 * program counter: Regs and Memory. (line 362) 46135 * prologue: Function Entry. (line 6) 46136 * prologue instruction pattern: Standard Names. (line 1345) 46137 * PROMOTE_MODE: Storage Layout. (line 87) 46138 * pseudo registers: Regs and Memory. (line 9) 46139 * PSImode: Machine Modes. (line 32) 46140 * PTRDIFF_TYPE: Type Layout. (line 183) 46141 * purge_dead_edges <1>: Edges. (line 104) 46142 * purge_dead_edges: Maintaining the CFG. 46143 (line 93) 46144 * push address instruction: Simple Constraints. (line 164) 46145 * PUSH_ARGS: Stack Arguments. (line 18) 46146 * PUSH_ARGS_REVERSED: Stack Arguments. (line 26) 46147 * push_operand: Machine-Independent Predicates. 46148 (line 81) 46149 * push_reload: Addressing Modes. (line 175) 46150 * PUSH_ROUNDING: Stack Arguments. (line 32) 46151 * pushM1 instruction pattern: Standard Names. (line 209) 46152 * PUT_CODE: RTL Objects. (line 47) 46153 * PUT_MODE: Machine Modes. (line 283) 46154 * PUT_REG_NOTE_KIND: Insns. (line 350) 46155 * PUT_SDB_: SDB and DWARF. (line 101) 46156 * QCmode: Machine Modes. (line 197) 46157 * QFmode: Machine Modes. (line 54) 46158 * QImode: Machine Modes. (line 25) 46159 * QImode, in insn: Insns. (line 272) 46160 * QQmode: Machine Modes. (line 103) 46161 * qualified type <1>: Types for C++. (line 6) 46162 * qualified type: Types. (line 6) 46163 * querying function unit reservations: Processor pipeline description. 46164 (line 90) 46165 * question mark: Multi-Alternative. (line 41) 46166 * quotient: Arithmetic. (line 116) 46167 * r in constraint: Simple Constraints. (line 66) 46168 * RANGE_TEST_NON_SHORT_CIRCUIT: Costs. (line 265) 46169 * RDIV_EXPR: Unary and Binary Expressions. 46170 (line 6) 46171 * READONLY_DATA_SECTION_ASM_OP: Sections. (line 63) 46172 * real operands: SSA Operands. (line 6) 46173 * REAL_ARITHMETIC: Floating Point. (line 66) 46174 * REAL_CST: Constant expressions. 46175 (line 6) 46176 * REAL_LIBGCC_SPEC: Driver. (line 125) 46177 * REAL_NM_FILE_NAME: Macros for Initialization. 46178 (line 106) 46179 * REAL_TYPE: Types. (line 6) 46180 * REAL_VALUE_ABS: Floating Point. (line 82) 46181 * REAL_VALUE_ATOF: Floating Point. (line 50) 46182 * REAL_VALUE_FIX: Floating Point. (line 41) 46183 * REAL_VALUE_FROM_INT: Floating Point. (line 99) 46184 * REAL_VALUE_ISINF: Floating Point. (line 59) 46185 * REAL_VALUE_ISNAN: Floating Point. (line 62) 46186 * REAL_VALUE_NEGATE: Floating Point. (line 79) 46187 * REAL_VALUE_NEGATIVE: Floating Point. (line 56) 46188 * REAL_VALUE_TO_INT: Floating Point. (line 93) 46189 * REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 156) 46190 * REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 154) 46191 * REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 155) 46192 * REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 152) 46193 * REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 153) 46194 * REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 151) 46195 * REAL_VALUE_TRUNCATE: Floating Point. (line 86) 46196 * REAL_VALUE_TYPE: Floating Point. (line 26) 46197 * REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 45) 46198 * REAL_VALUES_EQUAL: Floating Point. (line 32) 46199 * REAL_VALUES_LESS: Floating Point. (line 38) 46200 * REALPART_EXPR: Unary and Binary Expressions. 46201 (line 6) 46202 * recog_data.operand: Instruction Output. (line 54) 46203 * recognizing insns: RTL Template. (line 6) 46204 * RECORD_TYPE <1>: Types. (line 6) 46205 * RECORD_TYPE: Classes. (line 6) 46206 * redirect_edge_and_branch: Profile information. 46207 (line 71) 46208 * redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 46209 (line 103) 46210 * reduc_smax_M instruction pattern: Standard Names. (line 267) 46211 * reduc_smin_M instruction pattern: Standard Names. (line 267) 46212 * reduc_splus_M instruction pattern: Standard Names. (line 279) 46213 * reduc_umax_M instruction pattern: Standard Names. (line 273) 46214 * reduc_umin_M instruction pattern: Standard Names. (line 273) 46215 * reduc_uplus_M instruction pattern: Standard Names. (line 285) 46216 * reference: Types. (line 6) 46217 * REFERENCE_TYPE: Types. (line 6) 46218 * reg: Regs and Memory. (line 9) 46219 * reg and /f: Flags. (line 112) 46220 * reg and /i: Flags. (line 107) 46221 * reg and /v: Flags. (line 116) 46222 * reg, RTL sharing: Sharing. (line 17) 46223 * REG_ALLOC_ORDER: Allocation Order. (line 9) 46224 * REG_BR_PRED: Insns. (line 531) 46225 * REG_BR_PROB: Insns. (line 525) 46226 * REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 46227 (line 82) 46228 * REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 46229 (line 52) 46230 * REG_CC_SETTER: Insns. (line 496) 46231 * REG_CC_USER: Insns. (line 496) 46232 * reg_class_contents: Register Basics. (line 59) 46233 * REG_CLASS_CONTENTS: Register Classes. (line 88) 46234 * REG_CLASS_FROM_CONSTRAINT: Old Constraints. (line 35) 46235 * REG_CLASS_FROM_LETTER: Old Constraints. (line 27) 46236 * REG_CLASS_NAMES: Register Classes. (line 83) 46237 * REG_CROSSING_JUMP: Insns. (line 409) 46238 * REG_DEAD: Insns. (line 361) 46239 * REG_DEAD, REG_UNUSED: Liveness information. 46240 (line 32) 46241 * REG_DEP_ANTI: Insns. (line 518) 46242 * REG_DEP_OUTPUT: Insns. (line 514) 46243 * REG_DEP_TRUE: Insns. (line 511) 46244 * REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 110) 46245 * REG_EQUAL: Insns. (line 424) 46246 * REG_EQUIV: Insns. (line 424) 46247 * REG_EXPR: Special Accessors. (line 50) 46248 * REG_FRAME_RELATED_EXPR: Insns. (line 537) 46249 * REG_FUNCTION_VALUE_P: Flags. (line 107) 46250 * REG_INC: Insns. (line 377) 46251 * reg_label and /v: Flags. (line 65) 46252 * REG_LABEL_OPERAND: Insns. (line 391) 46253 * REG_LABEL_TARGET: Insns. (line 400) 46254 * reg_names <1>: Instruction Output. (line 108) 46255 * reg_names: Register Basics. (line 59) 46256 * REG_NONNEG: Insns. (line 383) 46257 * REG_NOTE_KIND: Insns. (line 350) 46258 * REG_NOTES: Insns. (line 324) 46259 * REG_OFFSET: Special Accessors. (line 54) 46260 * REG_OK_STRICT: Addressing Modes. (line 100) 46261 * REG_PARM_STACK_SPACE: Stack Arguments. (line 59) 46262 * REG_PARM_STACK_SPACE, and FUNCTION_ARG: Register Arguments. 46263 (line 52) 46264 * REG_POINTER: Flags. (line 112) 46265 * REG_SETJMP: Insns. (line 418) 46266 * REG_UNUSED: Insns. (line 370) 46267 * REG_USERVAR_P: Flags. (line 116) 46268 * regclass_for_constraint: C Constraint Interface. 46269 (line 60) 46270 * register allocation order: Allocation Order. (line 6) 46271 * register class definitions: Register Classes. (line 6) 46272 * register class preference constraints: Class Preferences. (line 6) 46273 * register pairs: Values in Registers. 46274 (line 69) 46275 * Register Transfer Language (RTL): RTL. (line 6) 46276 * register usage: Registers. (line 6) 46277 * REGISTER_MOVE_COST: Costs. (line 10) 46278 * REGISTER_NAMES: Instruction Output. (line 9) 46279 * register_operand: Machine-Independent Predicates. 46280 (line 30) 46281 * REGISTER_PREFIX: Instruction Output. (line 152) 46282 * REGISTER_TARGET_PRAGMAS: Misc. (line 382) 46283 * registers arguments: Register Arguments. (line 6) 46284 * registers in constraints: Simple Constraints. (line 66) 46285 * REGMODE_NATURAL_SIZE: Values in Registers. 46286 (line 50) 46287 * REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 169) 46288 * REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 146) 46289 * REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 156) 46290 * REGNO_OK_FOR_BASE_P: Register Classes. (line 142) 46291 * REGNO_OK_FOR_INDEX_P: Register Classes. (line 180) 46292 * REGNO_REG_CLASS: Register Classes. (line 103) 46293 * regs_ever_live: Function Entry. (line 21) 46294 * regular expressions: Processor pipeline description. 46295 (line 106) 46296 * relative costs: Costs. (line 6) 46297 * RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 263) 46298 * reload_completed: Standard Names. (line 1040) 46299 * reload_in instruction pattern: Standard Names. (line 99) 46300 * reload_in_progress: Standard Names. (line 57) 46301 * reload_out instruction pattern: Standard Names. (line 99) 46302 * reloading: RTL passes. (line 182) 46303 * remainder: Arithmetic. (line 136) 46304 * remainderM3 instruction pattern: Standard Names. (line 499) 46305 * reorder: GTY Options. (line 205) 46306 * representation of RTL: RTL. (line 6) 46307 * reservation delays: Processor pipeline description. 46308 (line 6) 46309 * rest_of_decl_compilation: Parsing pass. (line 52) 46310 * rest_of_type_compilation: Parsing pass. (line 52) 46311 * restore_stack_block instruction pattern: Standard Names. (line 1174) 46312 * restore_stack_function instruction pattern: Standard Names. 46313 (line 1174) 46314 * restore_stack_nonlocal instruction pattern: Standard Names. 46315 (line 1174) 46316 * RESULT_DECL: Declarations. (line 6) 46317 * return: Side Effects. (line 72) 46318 * return instruction pattern: Standard Names. (line 1027) 46319 * return values in registers: Scalar Return. (line 6) 46320 * RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 135) 46321 * RETURN_ADDR_OFFSET: Exception Handling. (line 60) 46322 * RETURN_ADDR_RTX: Frame Layout. (line 124) 46323 * RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 65) 46324 * RETURN_EXPR: Statements for C++. (line 6) 46325 * RETURN_STMT: Statements for C++. (line 6) 46326 * return_val: Flags. (line 299) 46327 * return_val, in call_insn: Flags. (line 24) 46328 * return_val, in mem: Flags. (line 85) 46329 * return_val, in reg: Flags. (line 107) 46330 * return_val, in symbol_ref: Flags. (line 220) 46331 * returning aggregate values: Aggregate Return. (line 6) 46332 * returning structures and unions: Interface. (line 10) 46333 * reverse probability: Profile information. 46334 (line 66) 46335 * REVERSE_CONDEXEC_PREDICATES_P: Cond Exec Macros. (line 11) 46336 * REVERSE_CONDITION: MODE_CC Condition Codes. 46337 (line 87) 46338 * REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 46339 (line 73) 46340 * right rotate: Arithmetic. (line 195) 46341 * right shift: Arithmetic. (line 190) 46342 * rintM2 instruction pattern: Standard Names. (line 599) 46343 * RISC: Processor pipeline description. 46344 (line 220) 46345 * roots, marking: GGC Roots. (line 6) 46346 * rotate: Arithmetic. (line 195) 46347 * rotatert: Arithmetic. (line 195) 46348 * rotlM3 instruction pattern: Standard Names. (line 468) 46349 * rotrM3 instruction pattern: Standard Names. (line 468) 46350 * ROUND_DIV_EXPR: Unary and Binary Expressions. 46351 (line 6) 46352 * ROUND_MOD_EXPR: Unary and Binary Expressions. 46353 (line 6) 46354 * ROUND_TOWARDS_ZERO: Storage Layout. (line 461) 46355 * ROUND_TYPE_ALIGN: Storage Layout. (line 408) 46356 * roundM2 instruction pattern: Standard Names. (line 575) 46357 * RSHIFT_EXPR: Unary and Binary Expressions. 46358 (line 6) 46359 * RTL addition: Arithmetic. (line 14) 46360 * RTL addition with signed saturation: Arithmetic. (line 14) 46361 * RTL addition with unsigned saturation: Arithmetic. (line 14) 46362 * RTL classes: RTL Classes. (line 6) 46363 * RTL comparison: Arithmetic. (line 43) 46364 * RTL comparison operations: Comparisons. (line 6) 46365 * RTL constant expression types: Constants. (line 6) 46366 * RTL constants: Constants. (line 6) 46367 * RTL declarations: RTL Declarations. (line 6) 46368 * RTL difference: Arithmetic. (line 36) 46369 * RTL expression: RTL Objects. (line 6) 46370 * RTL expressions for arithmetic: Arithmetic. (line 6) 46371 * RTL format: RTL Classes. (line 72) 46372 * RTL format characters: RTL Classes. (line 77) 46373 * RTL function-call insns: Calls. (line 6) 46374 * RTL insn template: RTL Template. (line 6) 46375 * RTL integers: RTL Objects. (line 6) 46376 * RTL memory expressions: Regs and Memory. (line 6) 46377 * RTL object types: RTL Objects. (line 6) 46378 * RTL postdecrement: Incdec. (line 6) 46379 * RTL postincrement: Incdec. (line 6) 46380 * RTL predecrement: Incdec. (line 6) 46381 * RTL preincrement: Incdec. (line 6) 46382 * RTL register expressions: Regs and Memory. (line 6) 46383 * RTL representation: RTL. (line 6) 46384 * RTL side effect expressions: Side Effects. (line 6) 46385 * RTL strings: RTL Objects. (line 6) 46386 * RTL structure sharing assumptions: Sharing. (line 6) 46387 * RTL subtraction: Arithmetic. (line 36) 46388 * RTL subtraction with signed saturation: Arithmetic. (line 36) 46389 * RTL subtraction with unsigned saturation: Arithmetic. (line 36) 46390 * RTL sum: Arithmetic. (line 14) 46391 * RTL vectors: RTL Objects. (line 6) 46392 * RTL_CONST_CALL_P: Flags. (line 19) 46393 * RTL_CONST_OR_PURE_CALL_P: Flags. (line 29) 46394 * RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 33) 46395 * RTL_PURE_CALL_P: Flags. (line 24) 46396 * RTX (See RTL): RTL Objects. (line 6) 46397 * RTX codes, classes of: RTL Classes. (line 6) 46398 * RTX_FRAME_RELATED_P: Flags. (line 125) 46399 * run-time conventions: Interface. (line 6) 46400 * run-time target specification: Run-time Target. (line 6) 46401 * s in constraint: Simple Constraints. (line 102) 46402 * same_type_p: Types. (line 88) 46403 * SAmode: Machine Modes. (line 148) 46404 * sat_fract: Conversions. (line 90) 46405 * satfractMN2 instruction pattern: Standard Names. (line 856) 46406 * satfractunsMN2 instruction pattern: Standard Names. (line 869) 46407 * satisfies_constraint_: C Constraint Interface. 46408 (line 47) 46409 * SAVE_EXPR: Unary and Binary Expressions. 46410 (line 6) 46411 * save_stack_block instruction pattern: Standard Names. (line 1174) 46412 * save_stack_function instruction pattern: Standard Names. (line 1174) 46413 * save_stack_nonlocal instruction pattern: Standard Names. (line 1174) 46414 * SBSS_SECTION_ASM_OP: Sections. (line 77) 46415 * Scalar evolutions: Scalar evolutions. (line 6) 46416 * scalars, returned as values: Scalar Return. (line 6) 46417 * SCHED_GROUP_P: Flags. (line 166) 46418 * SCmode: Machine Modes. (line 197) 46419 * scratch: Regs and Memory. (line 298) 46420 * scratch operands: Regs and Memory. (line 298) 46421 * scratch, RTL sharing: Sharing. (line 35) 46422 * scratch_operand: Machine-Independent Predicates. 46423 (line 50) 46424 * SDATA_SECTION_ASM_OP: Sections. (line 58) 46425 * SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 119) 46426 * SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 114) 46427 * SDB_DEBUGGING_INFO: SDB and DWARF. (line 9) 46428 * SDB_DELIM: SDB and DWARF. (line 107) 46429 * SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 124) 46430 * SDmode: Machine Modes. (line 85) 46431 * sdot_prodM instruction pattern: Standard Names. (line 291) 46432 * search options: Including Patterns. (line 44) 46433 * SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 394) 46434 * SECONDARY_MEMORY_NEEDED: Register Classes. (line 450) 46435 * SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 469) 46436 * SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 460) 46437 * SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 395) 46438 * SECONDARY_RELOAD_CLASS: Register Classes. (line 393) 46439 * SELECT_CC_MODE: MODE_CC Condition Codes. 46440 (line 7) 46441 * sequence: Side Effects. (line 254) 46442 * Sequence iterators: Sequence iterators. (line 6) 46443 * set: Side Effects. (line 15) 46444 * set and /f: Flags. (line 125) 46445 * SET_ASM_OP: Label Output. (line 418) 46446 * set_attr: Tagging Insns. (line 31) 46447 * set_attr_alternative: Tagging Insns. (line 49) 46448 * set_bb_seq: GIMPLE sequences. (line 76) 46449 * SET_BY_PIECES_P: Costs. (line 206) 46450 * SET_DEST: Side Effects. (line 69) 46451 * SET_IS_RETURN_P: Flags. (line 175) 46452 * SET_LABEL_KIND: Insns. (line 140) 46453 * set_optab_libfunc: Library Calls. (line 15) 46454 * SET_RATIO: Costs. (line 194) 46455 * SET_SRC: Side Effects. (line 69) 46456 * SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 83) 46457 * setmemM instruction pattern: Standard Names. (line 724) 46458 * SETUP_FRAME_ADDRESSES: Frame Layout. (line 102) 46459 * SF_SIZE: Type Layout. (line 128) 46460 * SFmode: Machine Modes. (line 66) 46461 * sharing of RTL components: Sharing. (line 6) 46462 * shift: Arithmetic. (line 173) 46463 * SHIFT_COUNT_TRUNCATED: Misc. (line 127) 46464 * SHLIB_SUFFIX: Macros for Initialization. 46465 (line 135) 46466 * SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 83) 46467 * SHORT_FRACT_TYPE_SIZE: Type Layout. (line 63) 46468 * SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 96) 46469 * SHORT_TYPE_SIZE: Type Layout. (line 16) 46470 * sibcall_epilogue instruction pattern: Standard Names. (line 1371) 46471 * sibling call: Edges. (line 122) 46472 * SIBLING_CALL_P: Flags. (line 179) 46473 * SIG_ATOMIC_TYPE: Type Layout. (line 234) 46474 * sign_extend: Conversions. (line 23) 46475 * sign_extract: Bit-Fields. (line 8) 46476 * sign_extract, canonicalization of: Insn Canonicalizations. 46477 (line 88) 46478 * signed division: Arithmetic. (line 116) 46479 * signed division with signed saturation: Arithmetic. (line 116) 46480 * signed maximum: Arithmetic. (line 141) 46481 * signed minimum: Arithmetic. (line 141) 46482 * SImode: Machine Modes. (line 37) 46483 * simple constraints: Simple Constraints. (line 6) 46484 * sincos math function, implicit usage: Library Calls. (line 70) 46485 * sinM2 instruction pattern: Standard Names. (line 516) 46486 * SIZE_ASM_OP: Label Output. (line 35) 46487 * SIZE_TYPE: Type Layout. (line 167) 46488 * skip: GTY Options. (line 72) 46489 * SLOW_BYTE_ACCESS: Costs. (line 118) 46490 * SLOW_UNALIGNED_ACCESS: Costs. (line 133) 46491 * smax: Arithmetic. (line 141) 46492 * smin: Arithmetic. (line 141) 46493 * sms, swing, software pipelining: RTL passes. (line 131) 46494 * smulM3_highpart instruction pattern: Standard Names. (line 383) 46495 * soft float library: Soft float library routines. 46496 (line 6) 46497 * special: GTY Options. (line 249) 46498 * special predicates: Predicates. (line 31) 46499 * SPECS: Target Fragment. (line 108) 46500 * speed of instructions: Costs. (line 6) 46501 * split_block: Maintaining the CFG. 46502 (line 110) 46503 * splitting instructions: Insn Splitting. (line 6) 46504 * SQmode: Machine Modes. (line 111) 46505 * sqrt: Arithmetic. (line 207) 46506 * sqrtM2 instruction pattern: Standard Names. (line 482) 46507 * square root: Arithmetic. (line 207) 46508 * ss_abs: Arithmetic. (line 200) 46509 * ss_ashift: Arithmetic. (line 173) 46510 * ss_div: Arithmetic. (line 116) 46511 * ss_minus: Arithmetic. (line 36) 46512 * ss_mult: Arithmetic. (line 92) 46513 * ss_neg: Arithmetic. (line 81) 46514 * ss_plus: Arithmetic. (line 14) 46515 * ss_truncate: Conversions. (line 43) 46516 * SSA: SSA. (line 6) 46517 * SSA_NAME_DEF_STMT: SSA. (line 221) 46518 * SSA_NAME_VERSION: SSA. (line 226) 46519 * ssaddM3 instruction pattern: Standard Names. (line 222) 46520 * ssashlM3 instruction pattern: Standard Names. (line 458) 46521 * ssdivM3 instruction pattern: Standard Names. (line 222) 46522 * ssmaddMN4 instruction pattern: Standard Names. (line 406) 46523 * ssmsubMN4 instruction pattern: Standard Names. (line 430) 46524 * ssmulM3 instruction pattern: Standard Names. (line 222) 46525 * ssnegM2 instruction pattern: Standard Names. (line 476) 46526 * sssubM3 instruction pattern: Standard Names. (line 222) 46527 * ssum_widenM3 instruction pattern: Standard Names. (line 301) 46528 * stack arguments: Stack Arguments. (line 6) 46529 * stack frame layout: Frame Layout. (line 6) 46530 * stack smashing protection: Stack Smashing Protection. 46531 (line 6) 46532 * STACK_ALIGNMENT_NEEDED: Frame Layout. (line 48) 46533 * STACK_BOUNDARY: Storage Layout. (line 138) 46534 * STACK_CHECK_BUILTIN: Stack Checking. (line 32) 46535 * STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83) 46536 * STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74) 46537 * STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90) 46538 * STACK_CHECK_MOVING_SP: Stack Checking. (line 54) 46539 * STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 46) 46540 * STACK_CHECK_PROTECT: Stack Checking. (line 63) 46541 * STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 39) 46542 * STACK_DYNAMIC_OFFSET: Frame Layout. (line 75) 46543 * STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 46544 (line 83) 46545 * STACK_GROWS_DOWNWARD: Frame Layout. (line 9) 46546 * STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 84) 46547 * STACK_POINTER_OFFSET: Frame Layout. (line 58) 46548 * STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 46549 (line 93) 46550 * STACK_POINTER_REGNUM: Frame Registers. (line 9) 46551 * STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 46552 (line 83) 46553 * stack_pointer_rtx: Frame Registers. (line 104) 46554 * stack_protect_set instruction pattern: Standard Names. (line 1542) 46555 * stack_protect_test instruction pattern: Standard Names. (line 1552) 46556 * STACK_PUSH_CODE: Frame Layout. (line 17) 46557 * STACK_REG_COVER_CLASS: Stack Registers. (line 23) 46558 * STACK_REGS: Stack Registers. (line 20) 46559 * STACK_SAVEAREA_MODE: Storage Layout. (line 424) 46560 * STACK_SIZE_MODE: Storage Layout. (line 436) 46561 * STACK_SLOT_ALIGNMENT: Storage Layout. (line 256) 46562 * standard pattern names: Standard Names. (line 6) 46563 * STANDARD_INCLUDE_COMPONENT: Driver. (line 339) 46564 * STANDARD_INCLUDE_DIR: Driver. (line 331) 46565 * STANDARD_STARTFILE_PREFIX: Driver. (line 275) 46566 * STANDARD_STARTFILE_PREFIX_1: Driver. (line 282) 46567 * STANDARD_STARTFILE_PREFIX_2: Driver. (line 289) 46568 * STARTFILE_SPEC: Driver. (line 148) 46569 * STARTING_FRAME_OFFSET: Frame Layout. (line 39) 46570 * STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 46571 (line 74) 46572 * Statement and operand traversals: Statement and operand traversals. 46573 (line 6) 46574 * Statement Sequences: Statement Sequences. 46575 (line 6) 46576 * statements <1>: Statements for C++. (line 6) 46577 * statements: Function Properties. 46578 (line 6) 46579 * Statements: Statements. (line 6) 46580 * Static profile estimation: Profile information. 46581 (line 24) 46582 * static single assignment: SSA. (line 6) 46583 * STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 78) 46584 * STATIC_CHAIN_REGNUM: Frame Registers. (line 77) 46585 * stdarg.h and register arguments: Register Arguments. (line 47) 46586 * STDC_0_IN_SYSTEM_HEADERS: Misc. (line 365) 46587 * STMT_EXPR: Unary and Binary Expressions. 46588 (line 6) 46589 * STMT_IS_FULL_EXPR_P: Statements for C++. (line 22) 46590 * storage layout: Storage Layout. (line 6) 46591 * STORE_BY_PIECES_P: Costs. (line 213) 46592 * STORE_FLAG_VALUE: Misc. (line 216) 46593 * store_multiple instruction pattern: Standard Names. (line 160) 46594 * strcpy: Storage Layout. (line 223) 46595 * STRICT_ALIGNMENT: Storage Layout. (line 306) 46596 * strict_low_part: RTL Declarations. (line 9) 46597 * strict_memory_address_p: Addressing Modes. (line 185) 46598 * STRING_CST: Constant expressions. 46599 (line 6) 46600 * STRING_POOL_ADDRESS_P: Flags. (line 183) 46601 * strlenM instruction pattern: Standard Names. (line 791) 46602 * structure value address: Aggregate Return. (line 6) 46603 * STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 298) 46604 * structures, returning: Interface. (line 10) 46605 * subM3 instruction pattern: Standard Names. (line 222) 46606 * SUBOBJECT: Statements for C++. (line 6) 46607 * SUBOBJECT_CLEANUP: Statements for C++. (line 6) 46608 * subreg: Regs and Memory. (line 97) 46609 * subreg and /s: Flags. (line 205) 46610 * subreg and /u: Flags. (line 198) 46611 * subreg and /u and /v: Flags. (line 188) 46612 * subreg, in strict_low_part: RTL Declarations. (line 9) 46613 * SUBREG_BYTE: Regs and Memory. (line 289) 46614 * SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 188) 46615 * SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 198) 46616 * SUBREG_PROMOTED_VAR_P: Flags. (line 205) 46617 * SUBREG_REG: Regs and Memory. (line 289) 46618 * SUCCESS_EXIT_CODE: Host Misc. (line 12) 46619 * SUPPORTS_INIT_PRIORITY: Macros for Initialization. 46620 (line 58) 46621 * SUPPORTS_ONE_ONLY: Label Output. (line 247) 46622 * SUPPORTS_WEAK: Label Output. (line 221) 46623 * SWITCH_BODY: Statements for C++. (line 6) 46624 * SWITCH_COND: Statements for C++. (line 6) 46625 * SWITCH_STMT: Statements for C++. (line 6) 46626 * SWITCHABLE_TARGET: Run-time Target. (line 176) 46627 * SYMBOL_FLAG_ANCHOR: Special Accessors. (line 110) 46628 * SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 92) 46629 * SYMBOL_FLAG_FUNCTION: Special Accessors. (line 85) 46630 * SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 106) 46631 * SYMBOL_FLAG_LOCAL: Special Accessors. (line 88) 46632 * SYMBOL_FLAG_SMALL: Special Accessors. (line 97) 46633 * SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 101) 46634 * symbol_ref: Constants. (line 76) 46635 * symbol_ref and /f: Flags. (line 183) 46636 * symbol_ref and /i: Flags. (line 220) 46637 * symbol_ref and /u: Flags. (line 10) 46638 * symbol_ref and /v: Flags. (line 224) 46639 * symbol_ref, RTL sharing: Sharing. (line 20) 46640 * SYMBOL_REF_ANCHOR_P: Special Accessors. (line 110) 46641 * SYMBOL_REF_BLOCK: Special Accessors. (line 123) 46642 * SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 128) 46643 * SYMBOL_REF_CONSTANT: Special Accessors. (line 71) 46644 * SYMBOL_REF_DATA: Special Accessors. (line 75) 46645 * SYMBOL_REF_DECL: Special Accessors. (line 59) 46646 * SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 92) 46647 * SYMBOL_REF_FLAG: Flags. (line 224) 46648 * SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 269) 46649 * SYMBOL_REF_FLAGS: Special Accessors. (line 79) 46650 * SYMBOL_REF_FUNCTION_P: Special Accessors. (line 85) 46651 * SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 106) 46652 * SYMBOL_REF_LOCAL_P: Special Accessors. (line 88) 46653 * SYMBOL_REF_SMALL_P: Special Accessors. (line 97) 46654 * SYMBOL_REF_TLS_MODEL: Special Accessors. (line 101) 46655 * SYMBOL_REF_USED: Flags. (line 215) 46656 * SYMBOL_REF_WEAK: Flags. (line 220) 46657 * symbolic label: Sharing. (line 20) 46658 * sync_addMODE instruction pattern: Standard Names. (line 1458) 46659 * sync_andMODE instruction pattern: Standard Names. (line 1458) 46660 * sync_compare_and_swapMODE instruction pattern: Standard Names. 46661 (line 1428) 46662 * sync_iorMODE instruction pattern: Standard Names. (line 1458) 46663 * sync_lock_releaseMODE instruction pattern: Standard Names. (line 1523) 46664 * sync_lock_test_and_setMODE instruction pattern: Standard Names. 46665 (line 1497) 46666 * sync_nandMODE instruction pattern: Standard Names. (line 1458) 46667 * sync_new_addMODE instruction pattern: Standard Names. (line 1490) 46668 * sync_new_andMODE instruction pattern: Standard Names. (line 1490) 46669 * sync_new_iorMODE instruction pattern: Standard Names. (line 1490) 46670 * sync_new_nandMODE instruction pattern: Standard Names. (line 1490) 46671 * sync_new_subMODE instruction pattern: Standard Names. (line 1490) 46672 * sync_new_xorMODE instruction pattern: Standard Names. (line 1490) 46673 * sync_old_addMODE instruction pattern: Standard Names. (line 1473) 46674 * sync_old_andMODE instruction pattern: Standard Names. (line 1473) 46675 * sync_old_iorMODE instruction pattern: Standard Names. (line 1473) 46676 * sync_old_nandMODE instruction pattern: Standard Names. (line 1473) 46677 * sync_old_subMODE instruction pattern: Standard Names. (line 1473) 46678 * sync_old_xorMODE instruction pattern: Standard Names. (line 1473) 46679 * sync_subMODE instruction pattern: Standard Names. (line 1458) 46680 * sync_xorMODE instruction pattern: Standard Names. (line 1458) 46681 * SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 177) 46682 * SYSROOT_SUFFIX_SPEC: Driver. (line 172) 46683 * SYSTEM_INCLUDE_DIR: Driver. (line 322) 46684 * t-TARGET: Target Fragment. (line 6) 46685 * table jump: Basic Blocks. (line 57) 46686 * tablejump instruction pattern: Standard Names. (line 1102) 46687 * tag: GTY Options. (line 77) 46688 * tagging insns: Tagging Insns. (line 6) 46689 * tail calls: Tail Calls. (line 6) 46690 * TAmode: Machine Modes. (line 156) 46691 * target attributes: Target Attributes. (line 6) 46692 * target description macros: Target Macros. (line 6) 46693 * target functions: Target Structure. (line 6) 46694 * target hooks: Target Structure. (line 6) 46695 * target makefile fragment: Target Fragment. (line 6) 46696 * target specifications: Run-time Target. (line 6) 46697 * TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 46698 (line 45) 46699 * TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 46700 (line 88) 46701 * TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 46702 (line 63) 46703 * TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 46704 (line 72) 46705 * TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 46706 (line 38) 46707 * TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 46708 (line 79) 46709 * TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 46710 (line 52) 46711 * TARGET_ADDRESS_COST: Costs. (line 297) 46712 * TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 383) 46713 * TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 697) 46714 * TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 977) 46715 * TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 83) 46716 * TARGET_ARM_EABI_UNWINDER: Exception Region Output. 46717 (line 122) 46718 * TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10) 46719 * TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8) 46720 * TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9) 46721 * TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11) 46722 * TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 259) 46723 * TARGET_ASM_BYTE_OP: Data Output. (line 7) 46724 * TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 237) 46725 * TARGET_ASM_CLOSE_PAREN: Data Output. (line 142) 46726 * TARGET_ASM_CODE_END: File Framework. (line 59) 46727 * TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 46728 (line 69) 46729 * TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 142) 46730 * TARGET_ASM_DESTRUCTOR: Macros for Initialization. 46731 (line 83) 46732 * TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 82) 46733 * TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 74) 46734 * TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 63) 46735 * TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 294) 46736 * TARGET_ASM_FILE_END: File Framework. (line 37) 46737 * TARGET_ASM_FILE_START: File Framework. (line 9) 46738 * TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17) 46739 * TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31) 46740 * TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 84) 46741 * TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61) 46742 * TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55) 46743 * TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68) 46744 * TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11) 46745 * TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 216) 46746 * TARGET_ASM_FUNCTION_SECTION: File Framework. (line 123) 46747 * TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework. 46748 (line 133) 46749 * TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 187) 46750 * TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 178) 46751 * TARGET_ASM_INIT_SECTIONS: Sections. (line 161) 46752 * TARGET_ASM_INTEGER: Data Output. (line 27) 46753 * TARGET_ASM_INTERNAL_LABEL: Label Output. (line 338) 46754 * TARGET_ASM_JUMP_ALIGN_MAX_SKIP: Alignment Output. (line 22) 46755 * TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. 46756 (line 36) 46757 * TARGET_ASM_LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 69) 46758 * TARGET_ASM_LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 54) 46759 * TARGET_ASM_LTO_END: File Framework. (line 54) 46760 * TARGET_ASM_LTO_START: File Framework. (line 49) 46761 * TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 301) 46762 * TARGET_ASM_NAMED_SECTION: File Framework. (line 115) 46763 * TARGET_ASM_OPEN_PAREN: Data Output. (line 141) 46764 * TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 40) 46765 * TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 44) 46766 * TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 96) 46767 * TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 195) 46768 * TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 94) 46769 * TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 164) 46770 * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 208) 46771 * TARGET_ASM_RELOC_RW_MASK: Sections. (line 170) 46772 * TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 224) 46773 * TARGET_ASM_SELECT_SECTION: Sections. (line 182) 46774 * TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 29) 46775 * TARGET_ASM_TTYPE: Exception Region Output. 46776 (line 116) 46777 * TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14) 46778 * TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12) 46779 * TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13) 46780 * TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15) 46781 * TARGET_ASM_UNIQUE_SECTION: Sections. (line 203) 46782 * TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 88) 46783 * TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 93) 46784 * TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11) 46785 * TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 19) 46786 * TARGET_BINDS_LOCAL_P: Sections. (line 301) 46787 * TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 794) 46788 * TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 786) 46789 * TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 264) 46790 * TARGET_BUILTIN_DECL: Misc. (line 620) 46791 * TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 265) 46792 * TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 109) 46793 * TARGET_C99_FUNCTIONS: Library Calls. (line 63) 46794 * TARGET_CALLEE_COPIES: Register Arguments. (line 115) 46795 * TARGET_CAN_ELIMINATE: Elimination. (line 75) 46796 * TARGET_CAN_INLINE_P: Target Attributes. (line 150) 46797 * TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 246) 46798 * TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 773) 46799 * TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 285) 46800 * TARGET_CASE_VALUES_THRESHOLD: Misc. (line 47) 46801 * TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 46802 (line 116) 46803 * TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 28) 46804 * TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 113) 46805 * TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 492) 46806 * TARGET_COMMUTATIVE_P: Misc. (line 690) 46807 * TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 27) 46808 * TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60) 46809 * TARGET_CONST_ANCHOR: Misc. (line 988) 46810 * TARGET_CONVERT_TO_TYPE: Misc. (line 941) 46811 * TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9) 46812 * TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 87) 46813 * TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 38) 46814 * TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 62) 46815 * TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 25) 46816 * TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 54) 46817 * TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 18) 46818 * TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 12) 46819 * TARGET_CXX_GUARD_TYPE: C++ ABI. (line 7) 46820 * TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 30) 46821 * TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 43) 46822 * TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 69) 46823 * TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 74) 46824 * TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 80) 46825 * TARGET_DEBUG_UNWIND_INFO: SDB and DWARF. (line 37) 46826 * TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 508) 46827 * TARGET_DECLSPEC: Target Attributes. (line 73) 46828 * TARGET_DEFAULT_PACK_STRUCT: Misc. (line 445) 46829 * TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 159) 46830 * TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 56) 46831 * TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 422) 46832 * TARGET_DELAY_SCHED2: SDB and DWARF. (line 61) 46833 * TARGET_DELAY_VARTRACK: SDB and DWARF. (line 65) 46834 * TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 237) 46835 * TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55) 46836 * TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 18) 46837 * TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 172) 46838 * TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 46839 (line 99) 46840 * TARGET_EDOM: Library Calls. (line 45) 46841 * TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 68) 46842 * TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 19) 46843 * TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 24) 46844 * TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 45) 46845 * TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 36) 46846 * TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 63) 46847 * TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 49) 46848 * TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 57) 46849 * TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 41) 46850 * TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 31) 46851 * TARGET_ENCODE_SECTION_INFO: Sections. (line 245) 46852 * TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 46853 (line 83) 46854 * TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 128) 46855 * TARGET_ENUM_VA_LIST_P: Register Arguments. (line 269) 46856 * TARGET_EXCEPT_UNWIND_INFO: Exception Region Output. 46857 (line 48) 46858 * TARGET_EXECUTABLE_SUFFIX: Misc. (line 747) 46859 * TARGET_EXPAND_BUILTIN: Misc. (line 630) 46860 * TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 67) 46861 * TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 514) 46862 * TARGET_EXPR: Unary and Binary Expressions. 46863 (line 6) 46864 * TARGET_EXTRA_INCLUDES: Misc. (line 834) 46865 * TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 21) 46866 * TARGET_EXTRA_PRE_INCLUDES: Misc. (line 841) 46867 * TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 46868 (line 101) 46869 * TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 511) 46870 * target_flags: Run-time Target. (line 52) 46871 * TARGET_FLAGS_REGNUM: Register Arguments. (line 361) 46872 * TARGET_FLT_EVAL_METHOD: Type Layout. (line 140) 46873 * TARGET_FN_ABI_VA_LIST: Register Arguments. (line 280) 46874 * TARGET_FOLD_BUILTIN: Misc. (line 651) 46875 * TARGET_FORMAT_TYPES: Misc. (line 861) 46876 * TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 9) 46877 * TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 239) 46878 * TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 95) 46879 * TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8) 46880 * TARGET_FUNCTION_VALUE: Scalar Return. (line 11) 46881 * TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 97) 46882 * TARGET_GET_DRAP_RTX: Misc. (line 971) 46883 * TARGET_GET_PCH_VALIDITY: PCH Target. (line 7) 46884 * TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 83) 46885 * TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 78) 46886 * TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 291) 46887 * TARGET_HANDLE_C_OPTION: Run-time Target. (line 78) 46888 * TARGET_HANDLE_OPTION: Run-time Target. (line 61) 46889 * TARGET_HANDLE_PRAGMA_EXTERN_PREFIX: Misc. (line 442) 46890 * TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 46891 (line 144) 46892 * TARGET_HAS_SINCOS: Library Calls. (line 71) 46893 * TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 808) 46894 * TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 46895 (line 64) 46896 * TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 140) 46897 * TARGET_HAVE_SRODATA_SECTION: Sections. (line 290) 46898 * TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 145) 46899 * TARGET_HAVE_TLS: Sections. (line 310) 46900 * TARGET_HELP: Run-time Target. (line 170) 46901 * TARGET_IN_SMALL_DATA_P: Sections. (line 286) 46902 * TARGET_INIT_BUILTINS: Misc. (line 602) 46903 * TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 46904 (line 108) 46905 * TARGET_INIT_LIBFUNCS: Library Calls. (line 16) 46906 * TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 82) 46907 * TARGET_INSTANTIATE_DECLS: Storage Layout. (line 522) 46908 * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 895) 46909 * TARGET_INVALID_BINARY_OP: Misc. (line 914) 46910 * TARGET_INVALID_CONVERSION: Misc. (line 901) 46911 * TARGET_INVALID_PARAMETER_TYPE: Misc. (line 920) 46912 * TARGET_INVALID_RETURN_TYPE: Misc. (line 927) 46913 * TARGET_INVALID_UNARY_OP: Misc. (line 907) 46914 * TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 670) 46915 * TARGET_IRA_COVER_CLASSES: Register Classes. (line 537) 46916 * TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 50) 46917 * TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 132) 46918 * TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 35) 46919 * TARGET_LIBCALL_VALUE: Scalar Return. (line 66) 46920 * TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 445) 46921 * TARGET_LIBGCC_SDATA_SECTION: Sections. (line 133) 46922 * TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 451) 46923 * TARGET_LOOP_UNROLL_ADJUST: Misc. (line 815) 46924 * TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 587) 46925 * TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 313) 46926 * TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 235) 46927 * TARGET_MANGLE_TYPE: Storage Layout. (line 526) 46928 * TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 39) 46929 * TARGET_MD_ASM_CLOBBERS: Misc. (line 503) 46930 * TARGET_MEM_CONSTRAINT: Addressing Modes. (line 109) 46931 * TARGET_MEM_REF: Storage References. (line 6) 46932 * TARGET_MEMORY_MOVE_COST: Costs. (line 81) 46933 * TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 47) 46934 * TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 39) 46935 * TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 33) 46936 * TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 106) 46937 * TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 196) 46938 * TARGET_MODE_REP_EXTENDED: Misc. (line 191) 46939 * TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 481) 46940 * TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 62) 46941 * TARGET_MUST_PASS_IN_STACK, and FUNCTION_ARG: Register Arguments. 46942 (line 52) 46943 * TARGET_MVERSION_FUNCTION: Misc. (line 660) 46944 * TARGET_N_FORMAT_TYPES: Misc. (line 866) 46945 * TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 389) 46946 * TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 92) 46947 * TARGET_OBJECT_SUFFIX: Misc. (line 742) 46948 * TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46) 46949 * TARGET_OPTF: Misc. (line 848) 46950 * TARGET_OPTION_DEFAULT_PARAMS: Run-time Target. (line 166) 46951 * TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 163) 46952 * TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 149) 46953 * TARGET_OPTION_OVERRIDE: Target Attributes. (line 137) 46954 * TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 131) 46955 * TARGET_OPTION_PRINT: Target Attributes. (line 125) 46956 * TARGET_OPTION_RESTORE: Target Attributes. (line 119) 46957 * TARGET_OPTION_SAVE: Target Attributes. (line 113) 46958 * TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 102) 46959 * TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42) 46960 * TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 132) 46961 * TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 870) 46962 * TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 876) 46963 * TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 880) 46964 * TARGET_PASS_BY_REFERENCE: Register Arguments. (line 103) 46965 * TARGET_PCH_VALID_P: PCH Target. (line 13) 46966 * TARGET_POSIX_IO: Misc. (line 527) 46967 * TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 287) 46968 * TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 208) 46969 * TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 196) 46970 * TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 128) 46971 * TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 294) 46972 * TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 112) 46973 * TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11) 46974 * TARGET_PROMOTED_TYPE: Misc. (line 933) 46975 * TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 277) 46976 * TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 302) 46977 * TARGET_REGISTER_MOVE_COST: Costs. (line 33) 46978 * TARGET_RELAXED_ORDERING: Misc. (line 885) 46979 * TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 640) 46980 * TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 17) 46981 * TARGET_RETURN_IN_MSB: Scalar Return. (line 117) 46982 * TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 94) 46983 * TARGET_RTX_COSTS: Costs. (line 271) 46984 * TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 310) 46985 * TARGET_SCHED_ADJUST_COST: Scheduling. (line 37) 46986 * TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 52) 46987 * TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 274) 46988 * TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 289) 46989 * TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 89) 46990 * TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 235) 46991 * TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 160) 46992 * TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 144) 46993 * TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 153) 46994 * TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 132) 46995 * TARGET_SCHED_DISPATCH: Scheduling. (line 355) 46996 * TARGET_SCHED_DISPATCH_DO: Scheduling. (line 360) 46997 * TARGET_SCHED_FINISH: Scheduling. (line 109) 46998 * TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 126) 46999 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 215) 47000 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 204) 47001 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 47002 (line 168) 47003 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 47004 (line 196) 47005 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC: Scheduling. 47006 (line 328) 47007 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 220) 47008 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 230) 47009 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 225) 47010 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 210) 47011 * TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 293) 47012 * TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 315) 47013 * TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 269) 47014 * TARGET_SCHED_INIT: Scheduling. (line 99) 47015 * TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 149) 47016 * TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 141) 47017 * TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 118) 47018 * TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 279) 47019 * TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 246) 47020 * TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12) 47021 * TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 308) 47022 * TARGET_SCHED_REORDER: Scheduling. (line 60) 47023 * TARGET_SCHED_REORDER2: Scheduling. (line 77) 47024 * TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 285) 47025 * TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 340) 47026 * TARGET_SCHED_SMS_RES_MII: Scheduling. (line 346) 47027 * TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 297) 47028 * TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 24) 47029 * TARGET_SECONDARY_RELOAD: Register Classes. (line 316) 47030 * TARGET_SECTION_TYPE_FLAGS: File Framework. (line 151) 47031 * TARGET_SET_CURRENT_FUNCTION: Misc. (line 724) 47032 * TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 34) 47033 * TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 76) 47034 * TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 154) 47035 * TARGET_SLOW_UNALIGNED_VECTOR_MEMOP: Misc. (line 665) 47036 * TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments. 47037 (line 328) 47038 * TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 252) 47039 * TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 47040 (line 17) 47041 * TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 47042 (line 7) 47043 * TARGET_STATIC_CHAIN: Frame Registers. (line 92) 47044 * TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 112) 47045 * TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 108) 47046 * TARGET_STRIP_NAME_ENCODING: Sections. (line 282) 47047 * TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 45) 47048 * TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection. 47049 (line 27) 47050 * TARGET_SUPPORTS_WEAK: Label Output. (line 229) 47051 * TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 47052 (line 93) 47053 * TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 75) 47054 * TARGET_TRAMPOLINE_INIT: Trampolines. (line 56) 47055 * TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 716) 47056 * TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 47057 (line 74) 47058 * TARGET_UNWIND_WORD_MODE: Storage Layout. (line 457) 47059 * TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 967) 47060 * TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 55) 47061 * TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 258) 47062 * TARGET_USE_JCR_SECTION: Misc. (line 949) 47063 * TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 129) 47064 * TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 68) 47065 * TARGET_VALID_POINTER_MODE: Register Arguments. (line 297) 47066 * TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 322) 47067 * TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES: Addressing Modes. 47068 (line 382) 47069 * TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 344) 47070 * TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 274) 47071 * TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN: Addressing Modes. (line 300) 47072 * TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD: Addressing Modes. (line 312) 47073 * TARGET_VECTORIZE_BUILTIN_VEC_PERM: Addressing Modes. (line 336) 47074 * TARGET_VECTORIZE_BUILTIN_VEC_PERM_OK: Addressing Modes. (line 340) 47075 * TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 47076 (line 325) 47077 * TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 47078 (line 356) 47079 * TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 375) 47080 * TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. 47081 (line 366) 47082 * TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 47083 (line 331) 47084 * TARGET_VERSION: Run-time Target. (line 119) 47085 * TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 330) 47086 * TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 324) 47087 * TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 313) 47088 * TARGET_WANT_DEBUG_PUB_SECTIONS: SDB and DWARF. (line 56) 47089 * TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 265) 47090 * targetm: Target Structure. (line 7) 47091 * targets, makefile: Makefile. (line 6) 47092 * TCmode: Machine Modes. (line 197) 47093 * TDmode: Machine Modes. (line 94) 47094 * TEMPLATE_DECL: Declarations. (line 6) 47095 * Temporaries: Temporaries. (line 6) 47096 * termination routines: Initialization. (line 6) 47097 * testing constraints: C Constraint Interface. 47098 (line 6) 47099 * TEXT_SECTION_ASM_OP: Sections. (line 38) 47100 * TF_SIZE: Type Layout. (line 131) 47101 * TFmode: Machine Modes. (line 98) 47102 * THEN_CLAUSE: Statements for C++. (line 6) 47103 * THREAD_MODEL_SPEC: Driver. (line 163) 47104 * THROW_EXPR: Unary and Binary Expressions. 47105 (line 6) 47106 * THUNK_DECL: Declarations. (line 6) 47107 * THUNK_DELTA: Declarations. (line 6) 47108 * TImode: Machine Modes. (line 48) 47109 * TImode, in insn: Insns. (line 272) 47110 * TLS_COMMON_ASM_OP: Sections. (line 82) 47111 * TLS_SECTION_ASM_FLAG: Sections. (line 87) 47112 * tm.h macros: Target Macros. (line 6) 47113 * TQFmode: Machine Modes. (line 62) 47114 * TQmode: Machine Modes. (line 119) 47115 * TRAMPOLINE_ALIGNMENT: Trampolines. (line 49) 47116 * TRAMPOLINE_SECTION: Trampolines. (line 40) 47117 * TRAMPOLINE_SIZE: Trampolines. (line 45) 47118 * trampolines for nested functions: Trampolines. (line 6) 47119 * TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 123) 47120 * trap instruction pattern: Standard Names. (line 1381) 47121 * tree <1>: Macros and Functions. 47122 (line 6) 47123 * tree: Tree overview. (line 6) 47124 * Tree SSA: Tree SSA. (line 6) 47125 * TREE_CHAIN: Macros and Functions. 47126 (line 6) 47127 * TREE_CODE: Tree overview. (line 6) 47128 * tree_int_cst_equal: Constant expressions. 47129 (line 6) 47130 * TREE_INT_CST_HIGH: Constant expressions. 47131 (line 6) 47132 * TREE_INT_CST_LOW: Constant expressions. 47133 (line 6) 47134 * tree_int_cst_lt: Constant expressions. 47135 (line 6) 47136 * TREE_LIST: Containers. (line 6) 47137 * TREE_OPERAND: Expression trees. (line 6) 47138 * TREE_PUBLIC <1>: Function Basics. (line 6) 47139 * TREE_PUBLIC: Function Properties. 47140 (line 28) 47141 * TREE_PURPOSE: Containers. (line 6) 47142 * TREE_READONLY: Function Properties. 47143 (line 37) 47144 * tree_size: Macros and Functions. 47145 (line 13) 47146 * TREE_STATIC: Function Properties. 47147 (line 31) 47148 * TREE_STRING_LENGTH: Constant expressions. 47149 (line 6) 47150 * TREE_STRING_POINTER: Constant expressions. 47151 (line 6) 47152 * TREE_THIS_VOLATILE: Function Properties. 47153 (line 34) 47154 * TREE_TYPE <1>: Expression trees. (line 17) 47155 * TREE_TYPE <2>: Macros and Functions. 47156 (line 6) 47157 * TREE_TYPE <3>: Types. (line 6) 47158 * TREE_TYPE <4>: Function Basics. (line 47) 47159 * TREE_TYPE <5>: Working with declarations. 47160 (line 11) 47161 * TREE_TYPE <6>: Types for C++. (line 6) 47162 * TREE_TYPE: Expression trees. (line 6) 47163 * TREE_VALUE: Containers. (line 6) 47164 * TREE_VEC: Containers. (line 6) 47165 * TREE_VEC_ELT: Containers. (line 6) 47166 * TREE_VEC_LENGTH: Containers. (line 6) 47167 * TRULY_NOOP_TRUNCATION: Misc. (line 177) 47168 * TRUNC_DIV_EXPR: Unary and Binary Expressions. 47169 (line 6) 47170 * TRUNC_MOD_EXPR: Unary and Binary Expressions. 47171 (line 6) 47172 * truncate: Conversions. (line 38) 47173 * truncMN2 instruction pattern: Standard Names. (line 834) 47174 * TRUTH_AND_EXPR: Unary and Binary Expressions. 47175 (line 6) 47176 * TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 47177 (line 6) 47178 * TRUTH_NOT_EXPR: Unary and Binary Expressions. 47179 (line 6) 47180 * TRUTH_OR_EXPR: Unary and Binary Expressions. 47181 (line 6) 47182 * TRUTH_ORIF_EXPR: Unary and Binary Expressions. 47183 (line 6) 47184 * TRUTH_XOR_EXPR: Unary and Binary Expressions. 47185 (line 6) 47186 * TRY_BLOCK: Statements for C++. (line 6) 47187 * TRY_HANDLERS: Statements for C++. (line 6) 47188 * TRY_STMTS: Statements for C++. (line 6) 47189 * Tuple specific accessors: Tuple specific accessors. 47190 (line 6) 47191 * tuples: Tuple representation. 47192 (line 6) 47193 * type: Types. (line 6) 47194 * type declaration: Declarations. (line 6) 47195 * TYPE_ALIGN <1>: Types. (line 30) 47196 * TYPE_ALIGN <2>: Types for C++. (line 6) 47197 * TYPE_ALIGN: Types. (line 6) 47198 * TYPE_ARG_TYPES <1>: Types for C++. (line 6) 47199 * TYPE_ARG_TYPES: Types. (line 6) 47200 * TYPE_ASM_OP: Label Output. (line 67) 47201 * TYPE_ATTRIBUTES: Attributes. (line 25) 47202 * TYPE_BINFO: Classes. (line 6) 47203 * TYPE_BUILT_IN: Types for C++. (line 68) 47204 * TYPE_CANONICAL: Types. (line 6) 47205 * TYPE_CONTEXT <1>: Types for C++. (line 6) 47206 * TYPE_CONTEXT: Types. (line 6) 47207 * TYPE_DECL: Declarations. (line 6) 47208 * TYPE_FIELDS <1>: Types for C++. (line 6) 47209 * TYPE_FIELDS <2>: Classes. (line 6) 47210 * TYPE_FIELDS: Types. (line 6) 47211 * TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 96) 47212 * TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 81) 47213 * TYPE_HAS_MUTABLE_P: Classes. (line 86) 47214 * TYPE_HAS_NEW_OPERATOR: Classes. (line 93) 47215 * TYPE_MAIN_VARIANT <1>: Types. (line 19) 47216 * TYPE_MAIN_VARIANT: Types for C++. (line 6) 47217 * TYPE_MAX_VALUE: Types. (line 6) 47218 * TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 47219 * TYPE_METHOD_BASETYPE: Types. (line 6) 47220 * TYPE_METHODS: Classes. (line 6) 47221 * TYPE_MIN_VALUE: Types. (line 6) 47222 * TYPE_NAME <1>: Types. (line 6) 47223 * TYPE_NAME: Types for C++. (line 6) 47224 * TYPE_NOTHROW_P: Functions for C++. (line 154) 47225 * TYPE_OFFSET_BASETYPE <1>: Types. (line 6) 47226 * TYPE_OFFSET_BASETYPE: Types for C++. (line 6) 47227 * TYPE_OPERAND_FMT: Label Output. (line 78) 47228 * TYPE_OVERLOADS_ARRAY_REF: Classes. (line 104) 47229 * TYPE_OVERLOADS_ARROW: Classes. (line 107) 47230 * TYPE_OVERLOADS_CALL_EXPR: Classes. (line 100) 47231 * TYPE_POLYMORPHIC_P: Classes. (line 77) 47232 * TYPE_PRECISION <1>: Types. (line 6) 47233 * TYPE_PRECISION: Types for C++. (line 6) 47234 * TYPE_PTR_P: Types for C++. (line 74) 47235 * TYPE_PTRFN_P: Types for C++. (line 78) 47236 * TYPE_PTRMEM_P: Types for C++. (line 6) 47237 * TYPE_PTROB_P: Types for C++. (line 81) 47238 * TYPE_PTROBV_P: Types for C++. (line 6) 47239 * TYPE_QUAL_CONST <1>: Types for C++. (line 6) 47240 * TYPE_QUAL_CONST: Types. (line 6) 47241 * TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 47242 * TYPE_QUAL_RESTRICT: Types. (line 6) 47243 * TYPE_QUAL_VOLATILE <1>: Types. (line 6) 47244 * TYPE_QUAL_VOLATILE: Types for C++. (line 6) 47245 * TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 47246 * TYPE_SIZE <1>: Types for C++. (line 40) 47247 * TYPE_SIZE: Types. (line 25) 47248 * TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 47249 * TYPE_UNQUALIFIED <1>: Types. (line 6) 47250 * TYPE_UNQUALIFIED: Types for C++. (line 6) 47251 * TYPE_VFIELD: Classes. (line 6) 47252 * TYPENAME_TYPE: Types for C++. (line 6) 47253 * TYPENAME_TYPE_FULLNAME <1>: Types. (line 6) 47254 * TYPENAME_TYPE_FULLNAME: Types for C++. (line 6) 47255 * TYPEOF_TYPE: Types for C++. (line 6) 47256 * UDAmode: Machine Modes. (line 168) 47257 * udiv: Arithmetic. (line 130) 47258 * udivM3 instruction pattern: Standard Names. (line 222) 47259 * udivmodM4 instruction pattern: Standard Names. (line 455) 47260 * udot_prodM instruction pattern: Standard Names. (line 292) 47261 * UDQmode: Machine Modes. (line 136) 47262 * UHAmode: Machine Modes. (line 160) 47263 * UHQmode: Machine Modes. (line 128) 47264 * UINT16_TYPE: Type Layout. (line 240) 47265 * UINT32_TYPE: Type Layout. (line 241) 47266 * UINT64_TYPE: Type Layout. (line 242) 47267 * UINT8_TYPE: Type Layout. (line 239) 47268 * UINT_FAST16_TYPE: Type Layout. (line 256) 47269 * UINT_FAST32_TYPE: Type Layout. (line 257) 47270 * UINT_FAST64_TYPE: Type Layout. (line 258) 47271 * UINT_FAST8_TYPE: Type Layout. (line 255) 47272 * UINT_LEAST16_TYPE: Type Layout. (line 248) 47273 * UINT_LEAST32_TYPE: Type Layout. (line 249) 47274 * UINT_LEAST64_TYPE: Type Layout. (line 250) 47275 * UINT_LEAST8_TYPE: Type Layout. (line 247) 47276 * UINTMAX_TYPE: Type Layout. (line 223) 47277 * UINTPTR_TYPE: Type Layout. (line 260) 47278 * umaddMN4 instruction pattern: Standard Names. (line 402) 47279 * umax: Arithmetic. (line 149) 47280 * umaxM3 instruction pattern: Standard Names. (line 222) 47281 * umin: Arithmetic. (line 149) 47282 * uminM3 instruction pattern: Standard Names. (line 222) 47283 * umod: Arithmetic. (line 136) 47284 * umodM3 instruction pattern: Standard Names. (line 222) 47285 * umsubMN4 instruction pattern: Standard Names. (line 426) 47286 * umulhisi3 instruction pattern: Standard Names. (line 374) 47287 * umulM3_highpart instruction pattern: Standard Names. (line 388) 47288 * umulqihi3 instruction pattern: Standard Names. (line 374) 47289 * umulsidi3 instruction pattern: Standard Names. (line 374) 47290 * unchanging: Flags. (line 324) 47291 * unchanging, in call_insn: Flags. (line 19) 47292 * unchanging, in jump_insn, call_insn and insn: Flags. (line 39) 47293 * unchanging, in mem: Flags. (line 152) 47294 * unchanging, in subreg: Flags. (line 188) 47295 * unchanging, in symbol_ref: Flags. (line 10) 47296 * UNEQ_EXPR: Unary and Binary Expressions. 47297 (line 6) 47298 * UNGE_EXPR: Unary and Binary Expressions. 47299 (line 6) 47300 * UNGT_EXPR: Unary and Binary Expressions. 47301 (line 6) 47302 * UNION_TYPE <1>: Types. (line 6) 47303 * UNION_TYPE: Classes. (line 6) 47304 * unions, returning: Interface. (line 10) 47305 * UNITS_PER_WORD: Storage Layout. (line 60) 47306 * UNKNOWN_TYPE <1>: Types for C++. (line 6) 47307 * UNKNOWN_TYPE: Types. (line 6) 47308 * UNLE_EXPR: Unary and Binary Expressions. 47309 (line 6) 47310 * UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 49) 47311 * UNLT_EXPR: Unary and Binary Expressions. 47312 (line 6) 47313 * UNORDERED_EXPR: Unary and Binary Expressions. 47314 (line 6) 47315 * unshare_all_rtl: Sharing. (line 58) 47316 * unsigned division: Arithmetic. (line 130) 47317 * unsigned division with unsigned saturation: Arithmetic. (line 130) 47318 * unsigned greater than: Comparisons. (line 72) 47319 * unsigned less than: Comparisons. (line 76) 47320 * unsigned minimum and maximum: Arithmetic. (line 149) 47321 * unsigned_fix: Conversions. (line 77) 47322 * unsigned_float: Conversions. (line 62) 47323 * unsigned_fract_convert: Conversions. (line 97) 47324 * unsigned_sat_fract: Conversions. (line 103) 47325 * unspec <1>: Constant Definitions. 47326 (line 111) 47327 * unspec: Side Effects. (line 287) 47328 * unspec_volatile <1>: Constant Definitions. 47329 (line 99) 47330 * unspec_volatile: Side Effects. (line 287) 47331 * untyped_call instruction pattern: Standard Names. (line 1012) 47332 * untyped_return instruction pattern: Standard Names. (line 1062) 47333 * UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 47334 * update_ssa: SSA. (line 76) 47335 * update_stmt <1>: Manipulating GIMPLE statements. 47336 (line 141) 47337 * update_stmt: SSA Operands. (line 6) 47338 * update_stmt_if_modified: Manipulating GIMPLE statements. 47339 (line 144) 47340 * UQQmode: Machine Modes. (line 123) 47341 * us_ashift: Arithmetic. (line 173) 47342 * us_minus: Arithmetic. (line 36) 47343 * us_mult: Arithmetic. (line 92) 47344 * us_neg: Arithmetic. (line 81) 47345 * us_plus: Arithmetic. (line 14) 47346 * us_truncate: Conversions. (line 48) 47347 * usaddM3 instruction pattern: Standard Names. (line 222) 47348 * USAmode: Machine Modes. (line 164) 47349 * usashlM3 instruction pattern: Standard Names. (line 458) 47350 * usdivM3 instruction pattern: Standard Names. (line 222) 47351 * use: Side Effects. (line 162) 47352 * USE_C_ALLOCA: Host Misc. (line 19) 47353 * USE_LD_AS_NEEDED: Driver. (line 136) 47354 * USE_LOAD_POST_DECREMENT: Costs. (line 226) 47355 * USE_LOAD_POST_INCREMENT: Costs. (line 221) 47356 * USE_LOAD_PRE_DECREMENT: Costs. (line 236) 47357 * USE_LOAD_PRE_INCREMENT: Costs. (line 231) 47358 * use_param: GTY Options. (line 109) 47359 * use_paramN: GTY Options. (line 127) 47360 * use_params: GTY Options. (line 135) 47361 * USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 195) 47362 * USE_STORE_POST_DECREMENT: Costs. (line 246) 47363 * USE_STORE_POST_INCREMENT: Costs. (line 241) 47364 * USE_STORE_PRE_DECREMENT: Costs. (line 256) 47365 * USE_STORE_PRE_INCREMENT: Costs. (line 251) 47366 * used: Flags. (line 342) 47367 * used, in symbol_ref: Flags. (line 215) 47368 * USER_LABEL_PREFIX: Instruction Output. (line 154) 47369 * USING_STMT: Statements for C++. (line 6) 47370 * usmaddMN4 instruction pattern: Standard Names. (line 410) 47371 * usmsubMN4 instruction pattern: Standard Names. (line 434) 47372 * usmulhisi3 instruction pattern: Standard Names. (line 378) 47373 * usmulM3 instruction pattern: Standard Names. (line 222) 47374 * usmulqihi3 instruction pattern: Standard Names. (line 378) 47375 * usmulsidi3 instruction pattern: Standard Names. (line 378) 47376 * usnegM2 instruction pattern: Standard Names. (line 476) 47377 * USQmode: Machine Modes. (line 132) 47378 * ussubM3 instruction pattern: Standard Names. (line 222) 47379 * usum_widenM3 instruction pattern: Standard Names. (line 302) 47380 * UTAmode: Machine Modes. (line 172) 47381 * UTQmode: Machine Modes. (line 140) 47382 * V in constraint: Simple Constraints. (line 43) 47383 * VA_ARG_EXPR: Unary and Binary Expressions. 47384 (line 6) 47385 * values, returned by functions: Scalar Return. (line 6) 47386 * VAR_DECL: Declarations. (line 6) 47387 * var_location: Debug Information. (line 14) 47388 * varargs implementation: Varargs. (line 6) 47389 * variable: Declarations. (line 6) 47390 * Variable Location Debug Information in RTL: Debug Information. 47391 (line 6) 47392 * variable_size: GTY Options. (line 225) 47393 * vashlM3 instruction pattern: Standard Names. (line 472) 47394 * vashrM3 instruction pattern: Standard Names. (line 472) 47395 * vec_concat: Vector Operations. (line 28) 47396 * vec_duplicate: Vector Operations. (line 33) 47397 * VEC_EXTRACT_EVEN_EXPR: Vectors. (line 6) 47398 * vec_extract_evenM instruction pattern: Standard Names. (line 176) 47399 * VEC_EXTRACT_ODD_EXPR: Vectors. (line 6) 47400 * vec_extract_oddM instruction pattern: Standard Names. (line 183) 47401 * vec_extractM instruction pattern: Standard Names. (line 171) 47402 * vec_initM instruction pattern: Standard Names. (line 204) 47403 * VEC_INTERLEAVE_HIGH_EXPR: Vectors. (line 6) 47404 * vec_interleave_highM instruction pattern: Standard Names. (line 190) 47405 * VEC_INTERLEAVE_LOW_EXPR: Vectors. (line 6) 47406 * vec_interleave_lowM instruction pattern: Standard Names. (line 197) 47407 * VEC_LSHIFT_EXPR: Vectors. (line 6) 47408 * vec_merge: Vector Operations. (line 11) 47409 * VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 47410 * VEC_PACK_SAT_EXPR: Vectors. (line 6) 47411 * vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 329) 47412 * vec_pack_ssat_M instruction pattern: Standard Names. (line 322) 47413 * VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 47414 * vec_pack_trunc_M instruction pattern: Standard Names. (line 315) 47415 * vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 329) 47416 * vec_pack_usat_M instruction pattern: Standard Names. (line 322) 47417 * VEC_RSHIFT_EXPR: Vectors. (line 6) 47418 * vec_select: Vector Operations. (line 19) 47419 * vec_setM instruction pattern: Standard Names. (line 166) 47420 * vec_shl_M instruction pattern: Standard Names. (line 309) 47421 * vec_shr_M instruction pattern: Standard Names. (line 309) 47422 * VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 47423 * VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 47424 * VEC_UNPACK_HI_EXPR: Vectors. (line 6) 47425 * VEC_UNPACK_LO_EXPR: Vectors. (line 6) 47426 * vec_unpacks_float_hi_M instruction pattern: Standard Names. 47427 (line 351) 47428 * vec_unpacks_float_lo_M instruction pattern: Standard Names. 47429 (line 351) 47430 * vec_unpacks_hi_M instruction pattern: Standard Names. (line 336) 47431 * vec_unpacks_lo_M instruction pattern: Standard Names. (line 336) 47432 * vec_unpacku_float_hi_M instruction pattern: Standard Names. 47433 (line 351) 47434 * vec_unpacku_float_lo_M instruction pattern: Standard Names. 47435 (line 351) 47436 * vec_unpacku_hi_M instruction pattern: Standard Names. (line 344) 47437 * vec_unpacku_lo_M instruction pattern: Standard Names. (line 344) 47438 * VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 47439 * VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 47440 * vec_widen_smult_hi_M instruction pattern: Standard Names. (line 360) 47441 * vec_widen_smult_lo_M instruction pattern: Standard Names. (line 360) 47442 * vec_widen_umult_hi_M instruction pattern: Standard Names. (line 360) 47443 * vec_widen_umult_lo__M instruction pattern: Standard Names. (line 360) 47444 * vector: Containers. (line 6) 47445 * vector operations: Vector Operations. (line 6) 47446 * VECTOR_CST: Constant expressions. 47447 (line 6) 47448 * VECTOR_STORE_FLAG_VALUE: Misc. (line 308) 47449 * virtual operands: SSA Operands. (line 6) 47450 * VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 47451 * VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 47452 * VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 47453 * VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 47454 * VLIW: Processor pipeline description. 47455 (line 6) 47456 * vlshrM3 instruction pattern: Standard Names. (line 472) 47457 * VMS: Filesystem. (line 37) 47458 * VMS_DEBUGGING_INFO: VMS Debug. (line 9) 47459 * VOID_TYPE: Types. (line 6) 47460 * VOIDmode: Machine Modes. (line 190) 47461 * volatil: Flags. (line 356) 47462 * volatil, in insn, call_insn, jump_insn, code_label, barrier, and note: Flags. 47463 (line 44) 47464 * volatil, in label_ref and reg_label: Flags. (line 65) 47465 * volatil, in mem, asm_operands, and asm_input: Flags. (line 94) 47466 * volatil, in reg: Flags. (line 116) 47467 * volatil, in subreg: Flags. (line 188) 47468 * volatil, in symbol_ref: Flags. (line 224) 47469 * volatile memory references: Flags. (line 357) 47470 * volatile, in prefetch: Flags. (line 232) 47471 * voting between constraint alternatives: Class Preferences. (line 6) 47472 * vrotlM3 instruction pattern: Standard Names. (line 472) 47473 * vrotrM3 instruction pattern: Standard Names. (line 472) 47474 * walk_dominator_tree: SSA. (line 256) 47475 * walk_gimple_op: Statement and operand traversals. 47476 (line 32) 47477 * walk_gimple_seq: Statement and operand traversals. 47478 (line 50) 47479 * walk_gimple_stmt: Statement and operand traversals. 47480 (line 13) 47481 * walk_use_def_chains: SSA. (line 232) 47482 * WCHAR_TYPE: Type Layout. (line 191) 47483 * WCHAR_TYPE_SIZE: Type Layout. (line 199) 47484 * which_alternative: Output Statement. (line 59) 47485 * WHILE_BODY: Statements for C++. (line 6) 47486 * WHILE_COND: Statements for C++. (line 6) 47487 * WHILE_STMT: Statements for C++. (line 6) 47488 * whopr: LTO. (line 6) 47489 * WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 146) 47490 * WINT_TYPE: Type Layout. (line 204) 47491 * word_mode: Machine Modes. (line 336) 47492 * WORD_REGISTER_OPERATIONS: Misc. (line 63) 47493 * WORDS_BIG_ENDIAN: Storage Layout. (line 29) 47494 * WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 217) 47495 * wpa: LTO. (line 6) 47496 * X in constraint: Simple Constraints. (line 124) 47497 * x-HOST: Host Fragment. (line 6) 47498 * XCmode: Machine Modes. (line 197) 47499 * XCOFF_DEBUGGING_INFO: DBX Options. (line 13) 47500 * XEXP: Accessors. (line 6) 47501 * XF_SIZE: Type Layout. (line 130) 47502 * XFmode: Machine Modes. (line 79) 47503 * XINT: Accessors. (line 6) 47504 * xm-MACHINE.h <1>: Host Misc. (line 6) 47505 * xm-MACHINE.h: Filesystem. (line 6) 47506 * xor: Arithmetic. (line 168) 47507 * xor, canonicalization of: Insn Canonicalizations. 47508 (line 79) 47509 * xorM3 instruction pattern: Standard Names. (line 222) 47510 * XSTR: Accessors. (line 6) 47511 * XVEC: Accessors. (line 41) 47512 * XVECEXP: Accessors. (line 48) 47513 * XVECLEN: Accessors. (line 44) 47514 * XWINT: Accessors. (line 6) 47515 * zero_extend: Conversions. (line 28) 47516 * zero_extendMN2 instruction pattern: Standard Names. (line 844) 47517 * zero_extract: Bit-Fields. (line 30) 47518 * zero_extract, canonicalization of: Insn Canonicalizations. 47519 (line 88) 47520 47521 47522 47523 Tag Table: 47524 Node: Top2086 47525 Node: Contributing5181 47526 Node: Portability5922 47527 Node: Interface7710 47528 Node: Libgcc10750 47529 Node: Integer library routines12591 47530 Node: Soft float library routines19430 47531 Node: Decimal float library routines31367 47532 Node: Fixed-point fractional library routines47124 47533 Node: Exception handling routines147522 47534 Node: Miscellaneous routines148629 47535 Node: Languages150749 47536 Node: Source Tree152298 47537 Node: Configure Terms152880 47538 Node: Top Level155838 47539 Node: gcc Directory159150 47540 Node: Subdirectories160100 47541 Node: Configuration161972 47542 Node: Config Fragments162692 47543 Node: System Config163921 47544 Node: Configuration Files164857 47545 Node: Build167214 47546 Node: Makefile167626 47547 Ref: Makefile-Footnote-1174429 47548 Ref: Makefile-Footnote-2174574 47549 Node: Library Files174646 47550 Node: Headers175208 47551 Node: Documentation177291 47552 Node: Texinfo Manuals178150 47553 Node: Man Page Generation180494 47554 Node: Miscellaneous Docs182409 47555 Node: Front End183798 47556 Node: Front End Directory187491 47557 Node: Front End Config188811 47558 Node: Front End Makefile191753 47559 Node: Back End195535 47560 Node: Testsuites199214 47561 Node: Test Idioms200145 47562 Node: Test Directives203542 47563 Node: Directives204069 47564 Node: Selectors214137 47565 Node: Effective-Target Keywords215279 47566 Ref: arm_neon_ok222512 47567 Ref: arm_neon_fp16_ok222673 47568 Node: Add Options231869 47569 Node: Require Support233066 47570 Node: Final Actions235573 47571 Node: Ada Tests239636 47572 Node: C Tests240978 47573 Node: libgcj Tests245401 47574 Node: LTO Testing246528 47575 Node: gcov Testing248175 47576 Node: profopt Testing251162 47577 Node: compat Testing252877 47578 Node: Torture Tests257117 47579 Node: Options258734 47580 Node: Option file format259174 47581 Node: Option properties266145 47582 Node: Passes277699 47583 Node: Parsing pass278443 47584 Node: Gimplification pass281973 47585 Node: Pass manager283806 47586 Node: Tree SSA passes285600 47587 Node: RTL passes308072 47588 Node: RTL320415 47589 Node: RTL Objects322603 47590 Node: RTL Classes326477 47591 Node: Accessors331475 47592 Node: Special Accessors333869 47593 Node: Flags339235 47594 Node: Machine Modes355410 47595 Node: Constants367722 47596 Node: Regs and Memory373751 47597 Node: Arithmetic391652 47598 Node: Comparisons401479 47599 Node: Bit-Fields405771 47600 Node: Vector Operations407323 47601 Node: Conversions409158 47602 Node: RTL Declarations413656 47603 Node: Side Effects414477 47604 Node: Incdec430799 47605 Node: Assembler434134 47606 Node: Debug Information435679 47607 Node: Insns436877 47608 Node: Calls463077 47609 Node: Sharing465670 47610 Node: Reading RTL468780 47611 Node: GENERIC469772 47612 Node: Deficiencies471645 47613 Node: Tree overview471886 47614 Node: Macros and Functions476013 47615 Node: Identifiers476838 47616 Node: Containers478449 47617 Node: Types479606 47618 Node: Declarations491702 47619 Node: Working with declarations492197 47620 Node: Internal structure497803 47621 Node: Current structure hierarchy498187 47622 Node: Adding new DECL node types500281 47623 Node: Attributes504354 47624 Node: Expression trees505599 47625 Node: Constant expressions507352 47626 Node: Storage References511571 47627 Node: Unary and Binary Expressions515090 47628 Node: Vectors534508 47629 Node: Statements539437 47630 Node: Basic Statements539957 47631 Node: Blocks544464 47632 Node: Statement Sequences545868 47633 Node: Empty Statements546201 47634 Node: Jumps546775 47635 Node: Cleanups547428 47636 Node: OpenMP549196 47637 Node: Functions554943 47638 Node: Function Basics555414 47639 Node: Function Properties559099 47640 Node: Language-dependent trees561881 47641 Node: C and C++ Trees562767 47642 Node: Types for C++565671 47643 Node: Namespaces570637 47644 Node: Classes573744 47645 Node: Functions for C++578822 47646 Node: Statements for C++585075 47647 Node: C++ Expressions593123 47648 Node: Java Trees594624 47649 Node: GIMPLE594737 47650 Node: Tuple representation598358 47651 Node: GIMPLE instruction set606634 47652 Node: GIMPLE Exception Handling608302 47653 Node: Temporaries610216 47654 Ref: Temporaries-Footnote-1611531 47655 Node: Operands611594 47656 Node: Compound Expressions612356 47657 Node: Compound Lvalues612590 47658 Node: Conditional Expressions613352 47659 Node: Logical Operators614010 47660 Node: Manipulating GIMPLE statements620767 47661 Node: Tuple specific accessors626701 47662 Node: `GIMPLE_ASM'627520 47663 Node: `GIMPLE_ASSIGN'630153 47664 Node: `GIMPLE_BIND'634259 47665 Node: `GIMPLE_CALL'636066 47666 Node: `GIMPLE_CATCH'640336 47667 Node: `GIMPLE_COND'641480 47668 Node: `GIMPLE_DEBUG'644268 47669 Node: `GIMPLE_EH_FILTER'647651 47670 Node: `GIMPLE_LABEL'649139 47671 Node: `GIMPLE_NOP'650114 47672 Node: `GIMPLE_OMP_ATOMIC_LOAD'650483 47673 Node: `GIMPLE_OMP_ATOMIC_STORE'651393 47674 Node: `GIMPLE_OMP_CONTINUE'652032 47675 Node: `GIMPLE_OMP_CRITICAL'653382 47676 Node: `GIMPLE_OMP_FOR'654319 47677 Node: `GIMPLE_OMP_MASTER'657834 47678 Node: `GIMPLE_OMP_ORDERED'658217 47679 Node: `GIMPLE_OMP_PARALLEL'658617 47680 Node: `GIMPLE_OMP_RETURN'661389 47681 Node: `GIMPLE_OMP_SECTION'662039 47682 Node: `GIMPLE_OMP_SECTIONS'662705 47683 Node: `GIMPLE_OMP_SINGLE'664311 47684 Node: `GIMPLE_PHI'665248 47685 Node: `GIMPLE_RESX'666663 47686 Node: `GIMPLE_RETURN'667382 47687 Node: `GIMPLE_SWITCH'667950 47688 Node: `GIMPLE_TRY'670088 47689 Node: `GIMPLE_WITH_CLEANUP_EXPR'671878 47690 Node: GIMPLE sequences672761 47691 Node: Sequence iterators675967 47692 Node: Adding a new GIMPLE statement code684423 47693 Node: Statement and operand traversals685699 47694 Node: Tree SSA688299 47695 Node: Annotations690085 47696 Node: SSA Operands690611 47697 Node: SSA705142 47698 Node: Alias analysis717433 47699 Node: Memory model721213 47700 Node: Loop Analysis and Representation722576 47701 Node: Loop representation723757 47702 Node: Loop querying730677 47703 Node: Loop manipulation733510 47704 Node: LCSSA735878 47705 Node: Scalar evolutions737950 47706 Node: loop-iv741194 47707 Node: Number of iterations743120 47708 Node: Dependency analysis745929 47709 Node: Lambda752297 47710 Node: Omega753968 47711 Node: Control Flow755533 47712 Node: Basic Blocks756528 47713 Node: Edges761096 47714 Node: Profile information769658 47715 Node: Maintaining the CFG774344 47716 Node: Liveness information781221 47717 Node: Machine Desc783347 47718 Node: Overview785815 47719 Node: Patterns787856 47720 Node: Example791294 47721 Node: RTL Template792729 47722 Node: Output Template803384 47723 Node: Output Statement807349 47724 Node: Predicates811311 47725 Node: Machine-Independent Predicates814229 47726 Node: Defining Predicates819174 47727 Node: Constraints825139 47728 Node: Simple Constraints826621 47729 Node: Multi-Alternative839477 47730 Node: Class Preferences842318 47731 Node: Modifiers843210 47732 Node: Machine Constraints847342 47733 Node: Disable Insn Alternatives886496 47734 Node: Define Constraints889389 47735 Node: C Constraint Interface896170 47736 Node: Standard Names899811 47737 Ref: shift patterns919752 47738 Ref: prologue instruction pattern960386 47739 Ref: epilogue instruction pattern960879 47740 Node: Pattern Ordering970601 47741 Node: Dependent Patterns971837 47742 Node: Jump Patterns973457 47743 Ref: Jump Patterns-Footnote-1975601 47744 Node: Looping Patterns975647 47745 Node: Insn Canonicalizations980375 47746 Node: Expander Definitions984326 47747 Node: Insn Splitting992444 47748 Node: Including Patterns1002046 47749 Node: Peephole Definitions1003826 47750 Node: define_peephole1005079 47751 Node: define_peephole21011410 47752 Node: Insn Attributes1014477 47753 Node: Defining Attributes1015583 47754 Ref: define_enum_attr1018102 47755 Node: Expressions1019137 47756 Node: Tagging Insns1025739 47757 Node: Attr Example1030092 47758 Node: Insn Lengths1032466 47759 Node: Constant Attributes1035525 47760 Node: Delay Slots1036694 47761 Node: Processor pipeline description1039918 47762 Ref: Processor pipeline description-Footnote-11057536 47763 Node: Conditional Execution1057858 47764 Node: Constant Definitions1060711 47765 Ref: define_enum1064502 47766 Node: Iterators1064990 47767 Node: Mode Iterators1065437 47768 Node: Defining Mode Iterators1066415 47769 Node: Substitutions1067909 47770 Node: Examples1070150 47771 Node: Code Iterators1071598 47772 Node: Target Macros1073855 47773 Node: Target Structure1076943 47774 Node: Driver1078212 47775 Node: Run-time Target1097598 47776 Node: Per-Function Data1107235 47777 Node: Storage Layout1110000 47778 Node: Type Layout1135234 47779 Node: Registers1149705 47780 Node: Register Basics1150679 47781 Node: Allocation Order1156184 47782 Node: Values in Registers1158630 47783 Node: Leaf Functions1166119 47784 Node: Stack Registers1168977 47785 Node: Register Classes1170249 47786 Node: Old Constraints1199396 47787 Node: Stack and Calling1206548 47788 Node: Frame Layout1207082 47789 Node: Exception Handling1217962 47790 Node: Stack Checking1224340 47791 Node: Frame Registers1229153 47792 Node: Elimination1236819 47793 Node: Stack Arguments1241048 47794 Node: Register Arguments1247945 47795 Node: Scalar Return1266725 47796 Node: Aggregate Return1272804 47797 Node: Caller Saves1277014 47798 Node: Function Entry1278192 47799 Node: Profiling1290820 47800 Node: Tail Calls1292519 47801 Node: Stack Smashing Protection1293885 47802 Node: Varargs1295510 47803 Node: Trampolines1302196 47804 Node: Library Calls1308843 47805 Node: Addressing Modes1313044 47806 Node: Anchored Addresses1332060 47807 Node: Condition Code1334709 47808 Node: CC0 Condition Codes1336838 47809 Node: MODE_CC Condition Codes1340084 47810 Node: Cond Exec Macros1346311 47811 Node: Costs1347288 47812 Node: Scheduling1363499 47813 Node: Sections1382420 47814 Node: PIC1397721 47815 Node: Assembler Format1399781 47816 Node: File Framework1400919 47817 Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1407808 47818 Node: Data Output1411073 47819 Node: Uninitialized Data1419422 47820 Node: Label Output1424986 47821 Node: Initialization1448058 47822 Node: Macros for Initialization1454020 47823 Node: Instruction Output1460743 47824 Node: Dispatch Tables1471245 47825 Node: Exception Region Output1475623 47826 Node: Alignment Output1481967 47827 Node: Debugging Info1486512 47828 Node: All Debuggers1487182 47829 Node: DBX Options1490037 47830 Node: DBX Hooks1495486 47831 Node: File Names and DBX1497412 47832 Node: SDB and DWARF1499524 47833 Node: VMS Debug1505371 47834 Node: Floating Point1505958 47835 Node: Mode Switching1510781 47836 Node: Target Attributes1514707 47837 Node: Emulated TLS1522619 47838 Node: MIPS Coprocessors1526009 47839 Node: PCH Target1527578 47840 Node: C++ ABI1529120 47841 Node: Named Address Spaces1533769 47842 Node: Misc1538708 47843 Ref: TARGET_SHIFT_TRUNCATION_MASK1546136 47844 Node: Host Config1589538 47845 Node: Host Common1590606 47846 Node: Filesystem1592985 47847 Node: Host Misc1597100 47848 Node: Fragments1599549 47849 Node: Target Fragment1600744 47850 Node: Host Fragment1606634 47851 Node: Collect21606874 47852 Node: Header Dirs1609510 47853 Node: Type Information1610933 47854 Node: GTY Options1613290 47855 Node: GGC Roots1624980 47856 Node: Files1625700 47857 Node: Invoking the garbage collector1628446 47858 Node: Troubleshooting1629949 47859 Node: Plugins1631025 47860 Node: LTO1647396 47861 Node: Funding1672442 47862 Node: GNU Project1674925 47863 Node: Copying1675574 47864 Node: GNU Free Documentation License1713105 47865 Node: Contributors1738245 47866 Node: Option Index1775117 47867 Node: Concept Index1775921 47868 47869 End Tag Table 47870
