1 This is doc/gccint.info, produced by makeinfo version 4.13 from 2 /tmp/build-mingw64-toolchain-digit/src/gcc-4.8.3/gcc/doc/gccint.texi. 3 4 Copyright (C) 1988-2013 Free Software Foundation, Inc. 5 6 Permission is granted to copy, distribute and/or modify this document 7 under the terms of the GNU Free Documentation License, Version 1.3 or 8 any later version published by the Free Software Foundation; with the 9 Invariant Sections being "Funding Free Software", the Front-Cover Texts 10 being (a) (see below), and with the Back-Cover Texts being (b) (see 11 below). A copy of the license is included in the section entitled "GNU 12 Free Documentation License". 13 14 (a) The FSF's Front-Cover Text is: 15 16 A GNU Manual 17 18 (b) The FSF's Back-Cover Text is: 19 20 You have freedom to copy and modify this GNU Manual, like GNU 21 software. Copies published by the Free Software Foundation raise 22 funds for GNU development. 23 24 INFO-DIR-SECTION Software development 25 START-INFO-DIR-ENTRY 26 * gccint: (gccint). Internals of the GNU Compiler Collection. 27 END-INFO-DIR-ENTRY 28 This file documents the internals of the GNU compilers. 29 30 Copyright (C) 1988-2013 Free Software Foundation, Inc. 31 32 Permission is granted to copy, distribute and/or modify this document 33 under the terms of the GNU Free Documentation License, Version 1.3 or 34 any later version published by the Free Software Foundation; with the 35 Invariant Sections being "Funding Free Software", the Front-Cover Texts 36 being (a) (see below), and with the Back-Cover Texts being (b) (see 37 below). A copy of the license is included in the section entitled "GNU 38 Free Documentation License". 39 40 (a) The FSF's Front-Cover Text is: 41 42 A GNU Manual 43 44 (b) The FSF's Back-Cover Text is: 45 46 You have freedom to copy and modify this GNU Manual, like GNU 47 software. Copies published by the Free Software Foundation raise 48 funds for GNU development. 49 50 51 52 File: gccint.info, Node: Top, Next: Contributing, Up: (DIR) 53 54 Introduction 55 ************ 56 57 This manual documents the internals of the GNU compilers, including how 58 to port them to new targets and some information about how to write 59 front ends for new languages. It corresponds to the compilers 60 (GCC) version 4.8.3. The use of the GNU compilers is documented in a 61 separate manual. *Note Introduction: (gcc)Top. 62 63 This manual is mainly a reference manual rather than a tutorial. It 64 discusses how to contribute to GCC (*note Contributing::), the 65 characteristics of the machines supported by GCC as hosts and targets 66 (*note Portability::), how GCC relates to the ABIs on such systems 67 (*note Interface::), and the characteristics of the languages for which 68 GCC front ends are written (*note Languages::). It then describes the 69 GCC source tree structure and build system, some of the interfaces to 70 GCC front ends, and how support for a target system is implemented in 71 GCC. 72 73 Additional tutorial information is linked to from 74 `http://gcc.gnu.org/readings.html'. 75 76 * Menu: 77 78 * Contributing:: How to contribute to testing and developing GCC. 79 * Portability:: Goals of GCC's portability features. 80 * Interface:: Function-call interface of GCC output. 81 * Libgcc:: Low-level runtime library used by GCC. 82 * Languages:: Languages for which GCC front ends are written. 83 * Source Tree:: GCC source tree structure and build system. 84 * Testsuites:: GCC testsuites. 85 * Options:: Option specification files. 86 * Passes:: Order of passes, what they do, and what each file is for. 87 * GENERIC:: Language-independent representation generated by Front Ends 88 * GIMPLE:: Tuple representation used by Tree SSA optimizers 89 * Tree SSA:: Analysis and optimization of GIMPLE 90 * RTL:: Machine-dependent low-level intermediate representation. 91 * Control Flow:: Maintaining and manipulating the control flow graph. 92 * Loop Analysis and Representation:: Analysis and representation of loops 93 * Machine Desc:: How to write machine description instruction patterns. 94 * Target Macros:: How to write the machine description C macros and functions. 95 * Host Config:: Writing the `xm-MACHINE.h' file. 96 * Fragments:: Writing the `t-TARGET' and `x-HOST' files. 97 * Collect2:: How `collect2' works; how it finds `ld'. 98 * Header Dirs:: Understanding the standard header file directories. 99 * Type Information:: GCC's memory management; generating type information. 100 * Plugins:: Extending the compiler with plugins. 101 * LTO:: Using Link-Time Optimization. 102 103 * Funding:: How to help assure funding for free software. 104 * GNU Project:: The GNU Project and GNU/Linux. 105 106 * Copying:: GNU General Public License says 107 how you can copy and share GCC. 108 * GNU Free Documentation License:: How you can copy and share this manual. 109 * Contributors:: People who have contributed to GCC. 110 111 * Option Index:: Index to command line options. 112 * Concept Index:: Index of concepts and symbol names. 113 114 115 File: gccint.info, Node: Contributing, Next: Portability, Prev: Top, Up: Top 116 117 1 Contributing to GCC Development 118 ********************************* 119 120 If you would like to help pretest GCC releases to assure they work well, 121 current development sources are available by SVN (see 122 `http://gcc.gnu.org/svn.html'). Source and binary snapshots are also 123 available for FTP; see `http://gcc.gnu.org/snapshots.html'. 124 125 If you would like to work on improvements to GCC, please read the 126 advice at these URLs: 127 128 `http://gcc.gnu.org/contribute.html' 129 `http://gcc.gnu.org/contributewhy.html' 130 131 for information on how to make useful contributions and avoid 132 duplication of effort. Suggested projects are listed at 133 `http://gcc.gnu.org/projects/'. 134 135 136 File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top 137 138 2 GCC and Portability 139 ********************* 140 141 GCC itself aims to be portable to any machine where `int' is at least a 142 32-bit type. It aims to target machines with a flat (non-segmented) 143 byte addressed data address space (the code address space can be 144 separate). Target ABIs may have 8, 16, 32 or 64-bit `int' type. `char' 145 can be wider than 8 bits. 146 147 GCC gets most of the information about the target machine from a 148 machine description which gives an algebraic formula for each of the 149 machine's instructions. This is a very clean way to describe the 150 target. But when the compiler needs information that is difficult to 151 express in this fashion, ad-hoc parameters have been defined for 152 machine descriptions. The purpose of portability is to reduce the 153 total work needed on the compiler; it was not of interest for its own 154 sake. 155 156 GCC does not contain machine dependent code, but it does contain code 157 that depends on machine parameters such as endianness (whether the most 158 significant byte has the highest or lowest address of the bytes in a 159 word) and the availability of autoincrement addressing. In the 160 RTL-generation pass, it is often necessary to have multiple strategies 161 for generating code for a particular kind of syntax tree, strategies 162 that are usable for different combinations of parameters. Often, not 163 all possible cases have been addressed, but only the common ones or 164 only the ones that have been encountered. As a result, a new target 165 may require additional strategies. You will know if this happens 166 because the compiler will call `abort'. Fortunately, the new 167 strategies can be added in a machine-independent fashion, and will 168 affect only the target machines that need them. 169 170 171 File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top 172 173 3 Interfacing to GCC Output 174 *************************** 175 176 GCC is normally configured to use the same function calling convention 177 normally in use on the target system. This is done with the 178 machine-description macros described (*note Target Macros::). 179 180 However, returning of structure and union values is done differently on 181 some target machines. As a result, functions compiled with PCC 182 returning such types cannot be called from code compiled with GCC, and 183 vice versa. This does not cause trouble often because few Unix library 184 routines return structures or unions. 185 186 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes 187 long in the same registers used for `int' or `double' return values. 188 (GCC typically allocates variables of such types in registers also.) 189 Structures and unions of other sizes are returned by storing them into 190 an address passed by the caller (usually in a register). The target 191 hook `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. 192 193 By contrast, PCC on most target machines returns structures and unions 194 of any size by copying the data into an area of static storage, and then 195 returning the address of that storage as if it were a pointer value. 196 The caller must copy the data from that memory area to the place where 197 the value is wanted. This is slower than the method used by GCC, and 198 fails to be reentrant. 199 200 On some target machines, such as RISC machines and the 80386, the 201 standard system convention is to pass to the subroutine the address of 202 where to return the value. On these machines, GCC has been configured 203 to be compatible with the standard compiler, when this method is used. 204 It may not be compatible for structures of 1, 2, 4 or 8 bytes. 205 206 GCC uses the system's standard convention for passing arguments. On 207 some machines, the first few arguments are passed in registers; in 208 others, all are passed on the stack. It would be possible to use 209 registers for argument passing on any machine, and this would probably 210 result in a significant speedup. But the result would be complete 211 incompatibility with code that follows the standard convention. So this 212 change is practical only if you are switching to GCC as the sole C 213 compiler for the system. We may implement register argument passing on 214 certain machines once we have a complete GNU system so that we can 215 compile the libraries with GCC. 216 217 On some machines (particularly the SPARC), certain types of arguments 218 are passed "by invisible reference". This means that the value is 219 stored in memory, and the address of the memory location is passed to 220 the subroutine. 221 222 If you use `longjmp', beware of automatic variables. ISO C says that 223 automatic variables that are not declared `volatile' have undefined 224 values after a `longjmp'. And this is all GCC promises to do, because 225 it is very difficult to restore register variables correctly, and one 226 of GCC's features is that it can put variables in registers without 227 your asking it to. 228 229 230 File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top 231 232 4 The GCC low-level runtime library 233 *********************************** 234 235 GCC provides a low-level runtime library, `libgcc.a' or `libgcc_s.so.1' 236 on some platforms. GCC generates calls to routines in this library 237 automatically, whenever it needs to perform some operation that is too 238 complicated to emit inline code for. 239 240 Most of the routines in `libgcc' handle arithmetic operations that the 241 target processor cannot perform directly. This includes integer 242 multiply and divide on some machines, and all floating-point and 243 fixed-point operations on other machines. `libgcc' also includes 244 routines for exception handling, and a handful of miscellaneous 245 operations. 246 247 Some of these routines can be defined in mostly machine-independent C. 248 Others must be hand-written in assembly language for each processor 249 that needs them. 250 251 GCC will also generate calls to C library routines, such as `memcpy' 252 and `memset', in some cases. The set of routines that GCC may possibly 253 use is documented in *note Other Builtins: (gcc)Other Builtins. 254 255 These routines take arguments and return values of a specific machine 256 mode, not a specific C type. *Note Machine Modes::, for an explanation 257 of this concept. For illustrative purposes, in this chapter the 258 floating point type `float' is assumed to correspond to `SFmode'; 259 `double' to `DFmode'; and `long double' to both `TFmode' and `XFmode'. 260 Similarly, the integer types `int' and `unsigned int' correspond to 261 `SImode'; `long' and `unsigned long' to `DImode'; and `long long' and 262 `unsigned long long' to `TImode'. 263 264 * Menu: 265 266 * Integer library routines:: 267 * Soft float library routines:: 268 * Decimal float library routines:: 269 * Fixed-point fractional library routines:: 270 * Exception handling routines:: 271 * Miscellaneous routines:: 272 273 274 File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc 275 276 4.1 Routines for integer arithmetic 277 =================================== 278 279 The integer arithmetic routines are used on platforms that don't provide 280 hardware support for arithmetic operations on some modes. 281 282 4.1.1 Arithmetic functions 283 -------------------------- 284 285 -- Runtime Function: int __ashlsi3 (int A, int B) 286 -- Runtime Function: long __ashldi3 (long A, int B) 287 -- Runtime Function: long long __ashlti3 (long long A, int B) 288 These functions return the result of shifting A left by B bits. 289 290 -- Runtime Function: int __ashrsi3 (int A, int B) 291 -- Runtime Function: long __ashrdi3 (long A, int B) 292 -- Runtime Function: long long __ashrti3 (long long A, int B) 293 These functions return the result of arithmetically shifting A 294 right by B bits. 295 296 -- Runtime Function: int __divsi3 (int A, int B) 297 -- Runtime Function: long __divdi3 (long A, long B) 298 -- Runtime Function: long long __divti3 (long long A, long long B) 299 These functions return the quotient of the signed division of A and 300 B. 301 302 -- Runtime Function: int __lshrsi3 (int A, int B) 303 -- Runtime Function: long __lshrdi3 (long A, int B) 304 -- Runtime Function: long long __lshrti3 (long long A, int B) 305 These functions return the result of logically shifting A right by 306 B bits. 307 308 -- Runtime Function: int __modsi3 (int A, int B) 309 -- Runtime Function: long __moddi3 (long A, long B) 310 -- Runtime Function: long long __modti3 (long long A, long long B) 311 These functions return the remainder of the signed division of A 312 and B. 313 314 -- Runtime Function: int __mulsi3 (int A, int B) 315 -- Runtime Function: long __muldi3 (long A, long B) 316 -- Runtime Function: long long __multi3 (long long A, long long B) 317 These functions return the product of A and B. 318 319 -- Runtime Function: long __negdi2 (long A) 320 -- Runtime Function: long long __negti2 (long long A) 321 These functions return the negation of A. 322 323 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned 324 int B) 325 -- Runtime Function: unsigned long __udivdi3 (unsigned long A, 326 unsigned long B) 327 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 328 A, unsigned long long B) 329 These functions return the quotient of the unsigned division of A 330 and B. 331 332 -- Runtime Function: unsigned long __udivmoddi4 (unsigned long A, 333 unsigned long B, unsigned long *C) 334 -- Runtime Function: unsigned long long __udivmodti4 (unsigned long 335 long A, unsigned long long B, unsigned long long *C) 336 These functions calculate both the quotient and remainder of the 337 unsigned division of A and B. The return value is the quotient, 338 and the remainder is placed in variable pointed to by C. 339 340 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned 341 int B) 342 -- Runtime Function: unsigned long __umoddi3 (unsigned long A, 343 unsigned long B) 344 -- Runtime Function: unsigned long long __umodti3 (unsigned long long 345 A, unsigned long long B) 346 These functions return the remainder of the unsigned division of A 347 and B. 348 349 4.1.2 Comparison functions 350 -------------------------- 351 352 The following functions implement integral comparisons. These functions 353 implement a low-level compare, upon which the higher level comparison 354 operators (such as less than and greater than or equal to) can be 355 constructed. The returned values lie in the range zero to two, to allow 356 the high-level operators to be implemented by testing the returned 357 result using either signed or unsigned comparison. 358 359 -- Runtime Function: int __cmpdi2 (long A, long B) 360 -- Runtime Function: int __cmpti2 (long long A, long long B) 361 These functions perform a signed comparison of A and B. If A is 362 less than B, they return 0; if A is greater than B, they return 2; 363 and if A and B are equal they return 1. 364 365 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B) 366 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned 367 long long B) 368 These functions perform an unsigned comparison of A and B. If A 369 is less than B, they return 0; if A is greater than B, they return 370 2; and if A and B are equal they return 1. 371 372 4.1.3 Trapping arithmetic functions 373 ----------------------------------- 374 375 The following functions implement trapping arithmetic. These functions 376 call the libc function `abort' upon signed arithmetic overflow. 377 378 -- Runtime Function: int __absvsi2 (int A) 379 -- Runtime Function: long __absvdi2 (long A) 380 These functions return the absolute value of A. 381 382 -- Runtime Function: int __addvsi3 (int A, int B) 383 -- Runtime Function: long __addvdi3 (long A, long B) 384 These functions return the sum of A and B; that is `A + B'. 385 386 -- Runtime Function: int __mulvsi3 (int A, int B) 387 -- Runtime Function: long __mulvdi3 (long A, long B) 388 The functions return the product of A and B; that is `A * B'. 389 390 -- Runtime Function: int __negvsi2 (int A) 391 -- Runtime Function: long __negvdi2 (long A) 392 These functions return the negation of A; that is `-A'. 393 394 -- Runtime Function: int __subvsi3 (int A, int B) 395 -- Runtime Function: long __subvdi3 (long A, long B) 396 These functions return the difference between B and A; that is `A 397 - B'. 398 399 4.1.4 Bit operations 400 -------------------- 401 402 -- Runtime Function: int __clzsi2 (int A) 403 -- Runtime Function: int __clzdi2 (long A) 404 -- Runtime Function: int __clzti2 (long long A) 405 These functions return the number of leading 0-bits in A, starting 406 at the most significant bit position. If A is zero, the result is 407 undefined. 408 409 -- Runtime Function: int __ctzsi2 (int A) 410 -- Runtime Function: int __ctzdi2 (long A) 411 -- Runtime Function: int __ctzti2 (long long A) 412 These functions return the number of trailing 0-bits in A, starting 413 at the least significant bit position. If A is zero, the result is 414 undefined. 415 416 -- Runtime Function: int __ffsdi2 (long A) 417 -- Runtime Function: int __ffsti2 (long long A) 418 These functions return the index of the least significant 1-bit in 419 A, or the value zero if A is zero. The least significant bit is 420 index one. 421 422 -- Runtime Function: int __paritysi2 (int A) 423 -- Runtime Function: int __paritydi2 (long A) 424 -- Runtime Function: int __parityti2 (long long A) 425 These functions return the value zero if the number of bits set in 426 A is even, and the value one otherwise. 427 428 -- Runtime Function: int __popcountsi2 (int A) 429 -- Runtime Function: int __popcountdi2 (long A) 430 -- Runtime Function: int __popcountti2 (long long A) 431 These functions return the number of bits set in A. 432 433 -- Runtime Function: int32_t __bswapsi2 (int32_t A) 434 -- Runtime Function: int64_t __bswapdi2 (int64_t A) 435 These functions return the A byteswapped. 436 437 438 File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc 439 440 4.2 Routines for floating point emulation 441 ========================================= 442 443 The software floating point library is used on machines which do not 444 have hardware support for floating point. It is also used whenever 445 `-msoft-float' is used to disable generation of floating point 446 instructions. (Not all targets support this switch.) 447 448 For compatibility with other compilers, the floating point emulation 449 routines can be renamed with the `DECLARE_LIBRARY_RENAMES' macro (*note 450 Library Calls::). In this section, the default names are used. 451 452 Presently the library does not support `XFmode', which is used for 453 `long double' on some architectures. 454 455 4.2.1 Arithmetic functions 456 -------------------------- 457 458 -- Runtime Function: float __addsf3 (float A, float B) 459 -- Runtime Function: double __adddf3 (double A, double B) 460 -- Runtime Function: long double __addtf3 (long double A, long double 461 B) 462 -- Runtime Function: long double __addxf3 (long double A, long double 463 B) 464 These functions return the sum of A and B. 465 466 -- Runtime Function: float __subsf3 (float A, float B) 467 -- Runtime Function: double __subdf3 (double A, double B) 468 -- Runtime Function: long double __subtf3 (long double A, long double 469 B) 470 -- Runtime Function: long double __subxf3 (long double A, long double 471 B) 472 These functions return the difference between B and A; that is, 473 A - B. 474 475 -- Runtime Function: float __mulsf3 (float A, float B) 476 -- Runtime Function: double __muldf3 (double A, double B) 477 -- Runtime Function: long double __multf3 (long double A, long double 478 B) 479 -- Runtime Function: long double __mulxf3 (long double A, long double 480 B) 481 These functions return the product of A and B. 482 483 -- Runtime Function: float __divsf3 (float A, float B) 484 -- Runtime Function: double __divdf3 (double A, double B) 485 -- Runtime Function: long double __divtf3 (long double A, long double 486 B) 487 -- Runtime Function: long double __divxf3 (long double A, long double 488 B) 489 These functions return the quotient of A and B; that is, A / B. 490 491 -- Runtime Function: float __negsf2 (float A) 492 -- Runtime Function: double __negdf2 (double A) 493 -- Runtime Function: long double __negtf2 (long double A) 494 -- Runtime Function: long double __negxf2 (long double A) 495 These functions return the negation of A. They simply flip the 496 sign bit, so they can produce negative zero and negative NaN. 497 498 4.2.2 Conversion functions 499 -------------------------- 500 501 -- Runtime Function: double __extendsfdf2 (float A) 502 -- Runtime Function: long double __extendsftf2 (float A) 503 -- Runtime Function: long double __extendsfxf2 (float A) 504 -- Runtime Function: long double __extenddftf2 (double A) 505 -- Runtime Function: long double __extenddfxf2 (double A) 506 These functions extend A to the wider mode of their return type. 507 508 -- Runtime Function: double __truncxfdf2 (long double A) 509 -- Runtime Function: double __trunctfdf2 (long double A) 510 -- Runtime Function: float __truncxfsf2 (long double A) 511 -- Runtime Function: float __trunctfsf2 (long double A) 512 -- Runtime Function: float __truncdfsf2 (double A) 513 These functions truncate A to the narrower mode of their return 514 type, rounding toward zero. 515 516 -- Runtime Function: int __fixsfsi (float A) 517 -- Runtime Function: int __fixdfsi (double A) 518 -- Runtime Function: int __fixtfsi (long double A) 519 -- Runtime Function: int __fixxfsi (long double A) 520 These functions convert A to a signed integer, rounding toward 521 zero. 522 523 -- Runtime Function: long __fixsfdi (float A) 524 -- Runtime Function: long __fixdfdi (double A) 525 -- Runtime Function: long __fixtfdi (long double A) 526 -- Runtime Function: long __fixxfdi (long double A) 527 These functions convert A to a signed long, rounding toward zero. 528 529 -- Runtime Function: long long __fixsfti (float A) 530 -- Runtime Function: long long __fixdfti (double A) 531 -- Runtime Function: long long __fixtfti (long double A) 532 -- Runtime Function: long long __fixxfti (long double A) 533 These functions convert A to a signed long long, rounding toward 534 zero. 535 536 -- Runtime Function: unsigned int __fixunssfsi (float A) 537 -- Runtime Function: unsigned int __fixunsdfsi (double A) 538 -- Runtime Function: unsigned int __fixunstfsi (long double A) 539 -- Runtime Function: unsigned int __fixunsxfsi (long double A) 540 These functions convert A to an unsigned integer, rounding toward 541 zero. Negative values all become zero. 542 543 -- Runtime Function: unsigned long __fixunssfdi (float A) 544 -- Runtime Function: unsigned long __fixunsdfdi (double A) 545 -- Runtime Function: unsigned long __fixunstfdi (long double A) 546 -- Runtime Function: unsigned long __fixunsxfdi (long double A) 547 These functions convert A to an unsigned long, rounding toward 548 zero. Negative values all become zero. 549 550 -- Runtime Function: unsigned long long __fixunssfti (float A) 551 -- Runtime Function: unsigned long long __fixunsdfti (double A) 552 -- Runtime Function: unsigned long long __fixunstfti (long double A) 553 -- Runtime Function: unsigned long long __fixunsxfti (long double A) 554 These functions convert A to an unsigned long long, rounding 555 toward zero. Negative values all become zero. 556 557 -- Runtime Function: float __floatsisf (int I) 558 -- Runtime Function: double __floatsidf (int I) 559 -- Runtime Function: long double __floatsitf (int I) 560 -- Runtime Function: long double __floatsixf (int I) 561 These functions convert I, a signed integer, to floating point. 562 563 -- Runtime Function: float __floatdisf (long I) 564 -- Runtime Function: double __floatdidf (long I) 565 -- Runtime Function: long double __floatditf (long I) 566 -- Runtime Function: long double __floatdixf (long I) 567 These functions convert I, a signed long, to floating point. 568 569 -- Runtime Function: float __floattisf (long long I) 570 -- Runtime Function: double __floattidf (long long I) 571 -- Runtime Function: long double __floattitf (long long I) 572 -- Runtime Function: long double __floattixf (long long I) 573 These functions convert I, a signed long long, to floating point. 574 575 -- Runtime Function: float __floatunsisf (unsigned int I) 576 -- Runtime Function: double __floatunsidf (unsigned int I) 577 -- Runtime Function: long double __floatunsitf (unsigned int I) 578 -- Runtime Function: long double __floatunsixf (unsigned int I) 579 These functions convert I, an unsigned integer, to floating point. 580 581 -- Runtime Function: float __floatundisf (unsigned long I) 582 -- Runtime Function: double __floatundidf (unsigned long I) 583 -- Runtime Function: long double __floatunditf (unsigned long I) 584 -- Runtime Function: long double __floatundixf (unsigned long I) 585 These functions convert I, an unsigned long, to floating point. 586 587 -- Runtime Function: float __floatuntisf (unsigned long long I) 588 -- Runtime Function: double __floatuntidf (unsigned long long I) 589 -- Runtime Function: long double __floatuntitf (unsigned long long I) 590 -- Runtime Function: long double __floatuntixf (unsigned long long I) 591 These functions convert I, an unsigned long long, to floating 592 point. 593 594 4.2.3 Comparison functions 595 -------------------------- 596 597 There are two sets of basic comparison functions. 598 599 -- Runtime Function: int __cmpsf2 (float A, float B) 600 -- Runtime Function: int __cmpdf2 (double A, double B) 601 -- Runtime Function: int __cmptf2 (long double A, long double B) 602 These functions calculate a <=> b. That is, if A is less than B, 603 they return -1; if A is greater than B, they return 1; and if A 604 and B are equal they return 0. If either argument is NaN they 605 return 1, but you should not rely on this; if NaN is a 606 possibility, use one of the higher-level comparison functions. 607 608 -- Runtime Function: int __unordsf2 (float A, float B) 609 -- Runtime Function: int __unorddf2 (double A, double B) 610 -- Runtime Function: int __unordtf2 (long double A, long double B) 611 These functions return a nonzero value if either argument is NaN, 612 otherwise 0. 613 614 There is also a complete group of higher level functions which 615 correspond directly to comparison operators. They implement the ISO C 616 semantics for floating-point comparisons, taking NaN into account. Pay 617 careful attention to the return values defined for each set. Under the 618 hood, all of these routines are implemented as 619 620 if (__unordXf2 (a, b)) 621 return E; 622 return __cmpXf2 (a, b); 623 624 where E is a constant chosen to give the proper behavior for NaN. 625 Thus, the meaning of the return value is different for each set. Do 626 not rely on this implementation; only the semantics documented below 627 are guaranteed. 628 629 -- Runtime Function: int __eqsf2 (float A, float B) 630 -- Runtime Function: int __eqdf2 (double A, double B) 631 -- Runtime Function: int __eqtf2 (long double A, long double B) 632 These functions return zero if neither argument is NaN, and A and 633 B are equal. 634 635 -- Runtime Function: int __nesf2 (float A, float B) 636 -- Runtime Function: int __nedf2 (double A, double B) 637 -- Runtime Function: int __netf2 (long double A, long double B) 638 These functions return a nonzero value if either argument is NaN, 639 or if A and B are unequal. 640 641 -- Runtime Function: int __gesf2 (float A, float B) 642 -- Runtime Function: int __gedf2 (double A, double B) 643 -- Runtime Function: int __getf2 (long double A, long double B) 644 These functions return a value greater than or equal to zero if 645 neither argument is NaN, and A is greater than or equal to B. 646 647 -- Runtime Function: int __ltsf2 (float A, float B) 648 -- Runtime Function: int __ltdf2 (double A, double B) 649 -- Runtime Function: int __lttf2 (long double A, long double B) 650 These functions return a value less than zero if neither argument 651 is NaN, and A is strictly less than B. 652 653 -- Runtime Function: int __lesf2 (float A, float B) 654 -- Runtime Function: int __ledf2 (double A, double B) 655 -- Runtime Function: int __letf2 (long double A, long double B) 656 These functions return a value less than or equal to zero if 657 neither argument is NaN, and A is less than or equal to B. 658 659 -- Runtime Function: int __gtsf2 (float A, float B) 660 -- Runtime Function: int __gtdf2 (double A, double B) 661 -- Runtime Function: int __gttf2 (long double A, long double B) 662 These functions return a value greater than zero if neither 663 argument is NaN, and A is strictly greater than B. 664 665 4.2.4 Other floating-point functions 666 ------------------------------------ 667 668 -- Runtime Function: float __powisf2 (float A, int B) 669 -- Runtime Function: double __powidf2 (double A, int B) 670 -- Runtime Function: long double __powitf2 (long double A, int B) 671 -- Runtime Function: long double __powixf2 (long double A, int B) 672 These functions convert raise A to the power B. 673 674 -- Runtime Function: complex float __mulsc3 (float A, float B, float 675 C, float D) 676 -- Runtime Function: complex double __muldc3 (double A, double B, 677 double C, double D) 678 -- Runtime Function: complex long double __multc3 (long double A, long 679 double B, long double C, long double D) 680 -- Runtime Function: complex long double __mulxc3 (long double A, long 681 double B, long double C, long double D) 682 These functions return the product of A + iB and C + iD, following 683 the rules of C99 Annex G. 684 685 -- Runtime Function: complex float __divsc3 (float A, float B, float 686 C, float D) 687 -- Runtime Function: complex double __divdc3 (double A, double B, 688 double C, double D) 689 -- Runtime Function: complex long double __divtc3 (long double A, long 690 double B, long double C, long double D) 691 -- Runtime Function: complex long double __divxc3 (long double A, long 692 double B, long double C, long double D) 693 These functions return the quotient of A + iB and C + iD (i.e., (A 694 + iB) / (C + iD)), following the rules of C99 Annex G. 695 696 697 File: gccint.info, Node: Decimal float library routines, Next: Fixed-point fractional library routines, Prev: Soft float library routines, Up: Libgcc 698 699 4.3 Routines for decimal floating point emulation 700 ================================================= 701 702 The software decimal floating point library implements IEEE 754-2008 703 decimal floating point arithmetic and is only activated on selected 704 targets. 705 706 The software decimal floating point library supports either DPD 707 (Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as 708 selected at configure time. 709 710 4.3.1 Arithmetic functions 711 -------------------------- 712 713 -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32 714 B) 715 -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32 716 B) 717 -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64 718 B) 719 -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64 720 B) 721 -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A, 722 _Decimal128 B) 723 -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A, 724 _Decimal128 B) 725 These functions return the sum of A and B. 726 727 -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32 728 B) 729 -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32 730 B) 731 -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64 732 B) 733 -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64 734 B) 735 -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A, 736 _Decimal128 B) 737 -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A, 738 _Decimal128 B) 739 These functions return the difference between B and A; that is, 740 A - B. 741 742 -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32 743 B) 744 -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32 745 B) 746 -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64 747 B) 748 -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64 749 B) 750 -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A, 751 _Decimal128 B) 752 -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A, 753 _Decimal128 B) 754 These functions return the product of A and B. 755 756 -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32 757 B) 758 -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32 759 B) 760 -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64 761 B) 762 -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64 763 B) 764 -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A, 765 _Decimal128 B) 766 -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A, 767 _Decimal128 B) 768 These functions return the quotient of A and B; that is, A / B. 769 770 -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A) 771 -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A) 772 -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A) 773 -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A) 774 -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A) 775 -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A) 776 These functions return the negation of A. They simply flip the 777 sign bit, so they can produce negative zero and negative NaN. 778 779 4.3.2 Conversion functions 780 -------------------------- 781 782 -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A) 783 -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A) 784 -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A) 785 -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A) 786 -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A) 787 -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A) 788 -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A) 789 -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A) 790 -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A) 791 -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A) 792 -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A) 793 -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A) 794 These functions convert the value A from one decimal floating type 795 to another. 796 797 -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A) 798 -- Runtime Function: _Decimal64 __bid_extendsfdd (float A) 799 -- Runtime Function: _Decimal128 __dpd_extendsftd (float A) 800 -- Runtime Function: _Decimal128 __bid_extendsftd (float A) 801 -- Runtime Function: _Decimal128 __dpd_extenddftd (double A) 802 -- Runtime Function: _Decimal128 __bid_extenddftd (double A) 803 -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A) 804 -- Runtime Function: _Decimal128 __bid_extendxftd (long double A) 805 -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A) 806 -- Runtime Function: _Decimal32 __bid_truncdfsd (double A) 807 -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A) 808 -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A) 809 -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A) 810 -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A) 811 -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A) 812 -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A) 813 -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A) 814 -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A) 815 These functions convert the value of A from a binary floating type 816 to a decimal floating type of a different size. 817 818 -- Runtime Function: float __dpd_truncddsf (_Decimal64 A) 819 -- Runtime Function: float __bid_truncddsf (_Decimal64 A) 820 -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A) 821 -- Runtime Function: float __bid_trunctdsf (_Decimal128 A) 822 -- Runtime Function: double __dpd_extendsddf (_Decimal32 A) 823 -- Runtime Function: double __bid_extendsddf (_Decimal32 A) 824 -- Runtime Function: double __dpd_trunctddf (_Decimal128 A) 825 -- Runtime Function: double __bid_trunctddf (_Decimal128 A) 826 -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A) 827 -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A) 828 -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A) 829 -- Runtime Function: long double __bid_extendddxf (_Decimal64 A) 830 -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A) 831 -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A) 832 -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A) 833 -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A) 834 -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A) 835 -- Runtime Function: long double __bid_extendddtf (_Decimal64 A) 836 These functions convert the value of A from a decimal floating type 837 to a binary floating type of a different size. 838 839 -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A) 840 -- Runtime Function: _Decimal32 __bid_extendsfsd (float A) 841 -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A) 842 -- Runtime Function: _Decimal64 __bid_extenddfdd (double A) 843 -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A) 844 -- Runtime Function: _Decimal128 __bid_extendtftd (long double A) 845 -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A) 846 -- Runtime Function: float __bid_truncsdsf (_Decimal32 A) 847 -- Runtime Function: double __dpd_truncdddf (_Decimal64 A) 848 -- Runtime Function: double __bid_truncdddf (_Decimal64 A) 849 -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A) 850 -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A) 851 These functions convert the value of A between decimal and binary 852 floating types of the same size. 853 854 -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A) 855 -- Runtime Function: int __bid_fixsdsi (_Decimal32 A) 856 -- Runtime Function: int __dpd_fixddsi (_Decimal64 A) 857 -- Runtime Function: int __bid_fixddsi (_Decimal64 A) 858 -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A) 859 -- Runtime Function: int __bid_fixtdsi (_Decimal128 A) 860 These functions convert A to a signed integer. 861 862 -- Runtime Function: long __dpd_fixsddi (_Decimal32 A) 863 -- Runtime Function: long __bid_fixsddi (_Decimal32 A) 864 -- Runtime Function: long __dpd_fixdddi (_Decimal64 A) 865 -- Runtime Function: long __bid_fixdddi (_Decimal64 A) 866 -- Runtime Function: long __dpd_fixtddi (_Decimal128 A) 867 -- Runtime Function: long __bid_fixtddi (_Decimal128 A) 868 These functions convert A to a signed long. 869 870 -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A) 871 -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A) 872 -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A) 873 -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A) 874 -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A) 875 -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A) 876 These functions convert A to an unsigned integer. Negative values 877 all become zero. 878 879 -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A) 880 -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A) 881 -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A) 882 -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A) 883 -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A) 884 -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A) 885 These functions convert A to an unsigned long. Negative values 886 all become zero. 887 888 -- Runtime Function: _Decimal32 __dpd_floatsisd (int I) 889 -- Runtime Function: _Decimal32 __bid_floatsisd (int I) 890 -- Runtime Function: _Decimal64 __dpd_floatsidd (int I) 891 -- Runtime Function: _Decimal64 __bid_floatsidd (int I) 892 -- Runtime Function: _Decimal128 __dpd_floatsitd (int I) 893 -- Runtime Function: _Decimal128 __bid_floatsitd (int I) 894 These functions convert I, a signed integer, to decimal floating 895 point. 896 897 -- Runtime Function: _Decimal32 __dpd_floatdisd (long I) 898 -- Runtime Function: _Decimal32 __bid_floatdisd (long I) 899 -- Runtime Function: _Decimal64 __dpd_floatdidd (long I) 900 -- Runtime Function: _Decimal64 __bid_floatdidd (long I) 901 -- Runtime Function: _Decimal128 __dpd_floatditd (long I) 902 -- Runtime Function: _Decimal128 __bid_floatditd (long I) 903 These functions convert I, a signed long, to decimal floating 904 point. 905 906 -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I) 907 -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I) 908 -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I) 909 -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I) 910 -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I) 911 -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I) 912 These functions convert I, an unsigned integer, to decimal 913 floating point. 914 915 -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I) 916 -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I) 917 -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I) 918 -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I) 919 -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I) 920 -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I) 921 These functions convert I, an unsigned long, to decimal floating 922 point. 923 924 4.3.3 Comparison functions 925 -------------------------- 926 927 -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B) 928 -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B) 929 -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B) 930 -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B) 931 -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B) 932 -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B) 933 These functions return a nonzero value if either argument is NaN, 934 otherwise 0. 935 936 There is also a complete group of higher level functions which 937 correspond directly to comparison operators. They implement the ISO C 938 semantics for floating-point comparisons, taking NaN into account. Pay 939 careful attention to the return values defined for each set. Under the 940 hood, all of these routines are implemented as 941 942 if (__bid_unordXd2 (a, b)) 943 return E; 944 return __bid_cmpXd2 (a, b); 945 946 where E is a constant chosen to give the proper behavior for NaN. 947 Thus, the meaning of the return value is different for each set. Do 948 not rely on this implementation; only the semantics documented below 949 are guaranteed. 950 951 -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B) 952 -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B) 953 -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B) 954 -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B) 955 -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B) 956 -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B) 957 These functions return zero if neither argument is NaN, and A and 958 B are equal. 959 960 -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B) 961 -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B) 962 -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B) 963 -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B) 964 -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B) 965 -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B) 966 These functions return a nonzero value if either argument is NaN, 967 or if A and B are unequal. 968 969 -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B) 970 -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B) 971 -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B) 972 -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B) 973 -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B) 974 -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B) 975 These functions return a value greater than or equal to zero if 976 neither argument is NaN, and A is greater than or equal to B. 977 978 -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B) 979 -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B) 980 -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B) 981 -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B) 982 -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B) 983 -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B) 984 These functions return a value less than zero if neither argument 985 is NaN, and A is strictly less than B. 986 987 -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B) 988 -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B) 989 -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B) 990 -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B) 991 -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B) 992 -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B) 993 These functions return a value less than or equal to zero if 994 neither argument is NaN, and A is less than or equal to B. 995 996 -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B) 997 -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B) 998 -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B) 999 -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B) 1000 -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B) 1001 -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B) 1002 These functions return a value greater than zero if neither 1003 argument is NaN, and A is strictly greater than B. 1004 1005 1006 File: gccint.info, Node: Fixed-point fractional library routines, Next: Exception handling routines, Prev: Decimal float library routines, Up: Libgcc 1007 1008 4.4 Routines for fixed-point fractional emulation 1009 ================================================= 1010 1011 The software fixed-point library implements fixed-point fractional 1012 arithmetic, and is only activated on selected targets. 1013 1014 For ease of comprehension `fract' is an alias for the `_Fract' type, 1015 `accum' an alias for `_Accum', and `sat' an alias for `_Sat'. 1016 1017 For illustrative purposes, in this section the fixed-point fractional 1018 type `short fract' is assumed to correspond to machine mode `QQmode'; 1019 `unsigned short fract' to `UQQmode'; `fract' to `HQmode'; 1020 `unsigned fract' to `UHQmode'; `long fract' to `SQmode'; 1021 `unsigned long fract' to `USQmode'; `long long fract' to `DQmode'; and 1022 `unsigned long long fract' to `UDQmode'. Similarly the fixed-point 1023 accumulator type `short accum' corresponds to `HAmode'; 1024 `unsigned short accum' to `UHAmode'; `accum' to `SAmode'; 1025 `unsigned accum' to `USAmode'; `long accum' to `DAmode'; 1026 `unsigned long accum' to `UDAmode'; `long long accum' to `TAmode'; and 1027 `unsigned long long accum' to `UTAmode'. 1028 1029 4.4.1 Arithmetic functions 1030 -------------------------- 1031 1032 -- Runtime Function: short fract __addqq3 (short fract A, short fract 1033 B) 1034 -- Runtime Function: fract __addhq3 (fract A, fract B) 1035 -- Runtime Function: long fract __addsq3 (long fract A, long fract B) 1036 -- Runtime Function: long long fract __adddq3 (long long fract A, long 1037 long fract B) 1038 -- Runtime Function: unsigned short fract __adduqq3 (unsigned short 1039 fract A, unsigned short fract B) 1040 -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A, 1041 unsigned fract B) 1042 -- Runtime Function: unsigned long fract __addusq3 (unsigned long 1043 fract A, unsigned long fract B) 1044 -- Runtime Function: unsigned long long fract __addudq3 (unsigned long 1045 long fract A, unsigned long long fract B) 1046 -- Runtime Function: short accum __addha3 (short accum A, short accum 1047 B) 1048 -- Runtime Function: accum __addsa3 (accum A, accum B) 1049 -- Runtime Function: long accum __addda3 (long accum A, long accum B) 1050 -- Runtime Function: long long accum __addta3 (long long accum A, long 1051 long accum B) 1052 -- Runtime Function: unsigned short accum __adduha3 (unsigned short 1053 accum A, unsigned short accum B) 1054 -- Runtime Function: unsigned accum __addusa3 (unsigned accum A, 1055 unsigned accum B) 1056 -- Runtime Function: unsigned long accum __adduda3 (unsigned long 1057 accum A, unsigned long accum B) 1058 -- Runtime Function: unsigned long long accum __adduta3 (unsigned long 1059 long accum A, unsigned long long accum B) 1060 These functions return the sum of A and B. 1061 1062 -- Runtime Function: short fract __ssaddqq3 (short fract A, short 1063 fract B) 1064 -- Runtime Function: fract __ssaddhq3 (fract A, fract B) 1065 -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B) 1066 -- Runtime Function: long long fract __ssadddq3 (long long fract A, 1067 long long fract B) 1068 -- Runtime Function: short accum __ssaddha3 (short accum A, short 1069 accum B) 1070 -- Runtime Function: accum __ssaddsa3 (accum A, accum B) 1071 -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B) 1072 -- Runtime Function: long long accum __ssaddta3 (long long accum A, 1073 long long accum B) 1074 These functions return the sum of A and B with signed saturation. 1075 1076 -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short 1077 fract A, unsigned short fract B) 1078 -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A, 1079 unsigned fract B) 1080 -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long 1081 fract A, unsigned long fract B) 1082 -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned 1083 long long fract A, unsigned long long fract B) 1084 -- Runtime Function: unsigned short accum __usadduha3 (unsigned short 1085 accum A, unsigned short accum B) 1086 -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A, 1087 unsigned accum B) 1088 -- Runtime Function: unsigned long accum __usadduda3 (unsigned long 1089 accum A, unsigned long accum B) 1090 -- Runtime Function: unsigned long long accum __usadduta3 (unsigned 1091 long long accum A, unsigned long long accum B) 1092 These functions return the sum of A and B with unsigned saturation. 1093 1094 -- Runtime Function: short fract __subqq3 (short fract A, short fract 1095 B) 1096 -- Runtime Function: fract __subhq3 (fract A, fract B) 1097 -- Runtime Function: long fract __subsq3 (long fract A, long fract B) 1098 -- Runtime Function: long long fract __subdq3 (long long fract A, long 1099 long fract B) 1100 -- Runtime Function: unsigned short fract __subuqq3 (unsigned short 1101 fract A, unsigned short fract B) 1102 -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A, 1103 unsigned fract B) 1104 -- Runtime Function: unsigned long fract __subusq3 (unsigned long 1105 fract A, unsigned long fract B) 1106 -- Runtime Function: unsigned long long fract __subudq3 (unsigned long 1107 long fract A, unsigned long long fract B) 1108 -- Runtime Function: short accum __subha3 (short accum A, short accum 1109 B) 1110 -- Runtime Function: accum __subsa3 (accum A, accum B) 1111 -- Runtime Function: long accum __subda3 (long accum A, long accum B) 1112 -- Runtime Function: long long accum __subta3 (long long accum A, long 1113 long accum B) 1114 -- Runtime Function: unsigned short accum __subuha3 (unsigned short 1115 accum A, unsigned short accum B) 1116 -- Runtime Function: unsigned accum __subusa3 (unsigned accum A, 1117 unsigned accum B) 1118 -- Runtime Function: unsigned long accum __subuda3 (unsigned long 1119 accum A, unsigned long accum B) 1120 -- Runtime Function: unsigned long long accum __subuta3 (unsigned long 1121 long accum A, unsigned long long accum B) 1122 These functions return the difference of A and B; that is, `A - B'. 1123 1124 -- Runtime Function: short fract __sssubqq3 (short fract A, short 1125 fract B) 1126 -- Runtime Function: fract __sssubhq3 (fract A, fract B) 1127 -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B) 1128 -- Runtime Function: long long fract __sssubdq3 (long long fract A, 1129 long long fract B) 1130 -- Runtime Function: short accum __sssubha3 (short accum A, short 1131 accum B) 1132 -- Runtime Function: accum __sssubsa3 (accum A, accum B) 1133 -- Runtime Function: long accum __sssubda3 (long accum A, long accum B) 1134 -- Runtime Function: long long accum __sssubta3 (long long accum A, 1135 long long accum B) 1136 These functions return the difference of A and B with signed 1137 saturation; that is, `A - B'. 1138 1139 -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short 1140 fract A, unsigned short fract B) 1141 -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A, 1142 unsigned fract B) 1143 -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long 1144 fract A, unsigned long fract B) 1145 -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned 1146 long long fract A, unsigned long long fract B) 1147 -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short 1148 accum A, unsigned short accum B) 1149 -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A, 1150 unsigned accum B) 1151 -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long 1152 accum A, unsigned long accum B) 1153 -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned 1154 long long accum A, unsigned long long accum B) 1155 These functions return the difference of A and B with unsigned 1156 saturation; that is, `A - B'. 1157 1158 -- Runtime Function: short fract __mulqq3 (short fract A, short fract 1159 B) 1160 -- Runtime Function: fract __mulhq3 (fract A, fract B) 1161 -- Runtime Function: long fract __mulsq3 (long fract A, long fract B) 1162 -- Runtime Function: long long fract __muldq3 (long long fract A, long 1163 long fract B) 1164 -- Runtime Function: unsigned short fract __muluqq3 (unsigned short 1165 fract A, unsigned short fract B) 1166 -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A, 1167 unsigned fract B) 1168 -- Runtime Function: unsigned long fract __mulusq3 (unsigned long 1169 fract A, unsigned long fract B) 1170 -- Runtime Function: unsigned long long fract __muludq3 (unsigned long 1171 long fract A, unsigned long long fract B) 1172 -- Runtime Function: short accum __mulha3 (short accum A, short accum 1173 B) 1174 -- Runtime Function: accum __mulsa3 (accum A, accum B) 1175 -- Runtime Function: long accum __mulda3 (long accum A, long accum B) 1176 -- Runtime Function: long long accum __multa3 (long long accum A, long 1177 long accum B) 1178 -- Runtime Function: unsigned short accum __muluha3 (unsigned short 1179 accum A, unsigned short accum B) 1180 -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A, 1181 unsigned accum B) 1182 -- Runtime Function: unsigned long accum __muluda3 (unsigned long 1183 accum A, unsigned long accum B) 1184 -- Runtime Function: unsigned long long accum __muluta3 (unsigned long 1185 long accum A, unsigned long long accum B) 1186 These functions return the product of A and B. 1187 1188 -- Runtime Function: short fract __ssmulqq3 (short fract A, short 1189 fract B) 1190 -- Runtime Function: fract __ssmulhq3 (fract A, fract B) 1191 -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B) 1192 -- Runtime Function: long long fract __ssmuldq3 (long long fract A, 1193 long long fract B) 1194 -- Runtime Function: short accum __ssmulha3 (short accum A, short 1195 accum B) 1196 -- Runtime Function: accum __ssmulsa3 (accum A, accum B) 1197 -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B) 1198 -- Runtime Function: long long accum __ssmulta3 (long long accum A, 1199 long long accum B) 1200 These functions return the product of A and B with signed 1201 saturation. 1202 1203 -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short 1204 fract A, unsigned short fract B) 1205 -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A, 1206 unsigned fract B) 1207 -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long 1208 fract A, unsigned long fract B) 1209 -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned 1210 long long fract A, unsigned long long fract B) 1211 -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short 1212 accum A, unsigned short accum B) 1213 -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A, 1214 unsigned accum B) 1215 -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long 1216 accum A, unsigned long accum B) 1217 -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned 1218 long long accum A, unsigned long long accum B) 1219 These functions return the product of A and B with unsigned 1220 saturation. 1221 1222 -- Runtime Function: short fract __divqq3 (short fract A, short fract 1223 B) 1224 -- Runtime Function: fract __divhq3 (fract A, fract B) 1225 -- Runtime Function: long fract __divsq3 (long fract A, long fract B) 1226 -- Runtime Function: long long fract __divdq3 (long long fract A, long 1227 long fract B) 1228 -- Runtime Function: short accum __divha3 (short accum A, short accum 1229 B) 1230 -- Runtime Function: accum __divsa3 (accum A, accum B) 1231 -- Runtime Function: long accum __divda3 (long accum A, long accum B) 1232 -- Runtime Function: long long accum __divta3 (long long accum A, long 1233 long accum B) 1234 These functions return the quotient of the signed division of A 1235 and B. 1236 1237 -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short 1238 fract A, unsigned short fract B) 1239 -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A, 1240 unsigned fract B) 1241 -- Runtime Function: unsigned long fract __udivusq3 (unsigned long 1242 fract A, unsigned long fract B) 1243 -- Runtime Function: unsigned long long fract __udivudq3 (unsigned 1244 long long fract A, unsigned long long fract B) 1245 -- Runtime Function: unsigned short accum __udivuha3 (unsigned short 1246 accum A, unsigned short accum B) 1247 -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A, 1248 unsigned accum B) 1249 -- Runtime Function: unsigned long accum __udivuda3 (unsigned long 1250 accum A, unsigned long accum B) 1251 -- Runtime Function: unsigned long long accum __udivuta3 (unsigned 1252 long long accum A, unsigned long long accum B) 1253 These functions return the quotient of the unsigned division of A 1254 and B. 1255 1256 -- Runtime Function: short fract __ssdivqq3 (short fract A, short 1257 fract B) 1258 -- Runtime Function: fract __ssdivhq3 (fract A, fract B) 1259 -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B) 1260 -- Runtime Function: long long fract __ssdivdq3 (long long fract A, 1261 long long fract B) 1262 -- Runtime Function: short accum __ssdivha3 (short accum A, short 1263 accum B) 1264 -- Runtime Function: accum __ssdivsa3 (accum A, accum B) 1265 -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B) 1266 -- Runtime Function: long long accum __ssdivta3 (long long accum A, 1267 long long accum B) 1268 These functions return the quotient of the signed division of A 1269 and B with signed saturation. 1270 1271 -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short 1272 fract A, unsigned short fract B) 1273 -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A, 1274 unsigned fract B) 1275 -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long 1276 fract A, unsigned long fract B) 1277 -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned 1278 long long fract A, unsigned long long fract B) 1279 -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short 1280 accum A, unsigned short accum B) 1281 -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A, 1282 unsigned accum B) 1283 -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long 1284 accum A, unsigned long accum B) 1285 -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned 1286 long long accum A, unsigned long long accum B) 1287 These functions return the quotient of the unsigned division of A 1288 and B with unsigned saturation. 1289 1290 -- Runtime Function: short fract __negqq2 (short fract A) 1291 -- Runtime Function: fract __neghq2 (fract A) 1292 -- Runtime Function: long fract __negsq2 (long fract A) 1293 -- Runtime Function: long long fract __negdq2 (long long fract A) 1294 -- Runtime Function: unsigned short fract __neguqq2 (unsigned short 1295 fract A) 1296 -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A) 1297 -- Runtime Function: unsigned long fract __negusq2 (unsigned long 1298 fract A) 1299 -- Runtime Function: unsigned long long fract __negudq2 (unsigned long 1300 long fract A) 1301 -- Runtime Function: short accum __negha2 (short accum A) 1302 -- Runtime Function: accum __negsa2 (accum A) 1303 -- Runtime Function: long accum __negda2 (long accum A) 1304 -- Runtime Function: long long accum __negta2 (long long accum A) 1305 -- Runtime Function: unsigned short accum __neguha2 (unsigned short 1306 accum A) 1307 -- Runtime Function: unsigned accum __negusa2 (unsigned accum A) 1308 -- Runtime Function: unsigned long accum __neguda2 (unsigned long 1309 accum A) 1310 -- Runtime Function: unsigned long long accum __neguta2 (unsigned long 1311 long accum A) 1312 These functions return the negation of A. 1313 1314 -- Runtime Function: short fract __ssnegqq2 (short fract A) 1315 -- Runtime Function: fract __ssneghq2 (fract A) 1316 -- Runtime Function: long fract __ssnegsq2 (long fract A) 1317 -- Runtime Function: long long fract __ssnegdq2 (long long fract A) 1318 -- Runtime Function: short accum __ssnegha2 (short accum A) 1319 -- Runtime Function: accum __ssnegsa2 (accum A) 1320 -- Runtime Function: long accum __ssnegda2 (long accum A) 1321 -- Runtime Function: long long accum __ssnegta2 (long long accum A) 1322 These functions return the negation of A with signed saturation. 1323 1324 -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short 1325 fract A) 1326 -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A) 1327 -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long 1328 fract A) 1329 -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned 1330 long long fract A) 1331 -- Runtime Function: unsigned short accum __usneguha2 (unsigned short 1332 accum A) 1333 -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A) 1334 -- Runtime Function: unsigned long accum __usneguda2 (unsigned long 1335 accum A) 1336 -- Runtime Function: unsigned long long accum __usneguta2 (unsigned 1337 long long accum A) 1338 These functions return the negation of A with unsigned saturation. 1339 1340 -- Runtime Function: short fract __ashlqq3 (short fract A, int B) 1341 -- Runtime Function: fract __ashlhq3 (fract A, int B) 1342 -- Runtime Function: long fract __ashlsq3 (long fract A, int B) 1343 -- Runtime Function: long long fract __ashldq3 (long long fract A, int 1344 B) 1345 -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short 1346 fract A, int B) 1347 -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int 1348 B) 1349 -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long 1350 fract A, int B) 1351 -- Runtime Function: unsigned long long fract __ashludq3 (unsigned 1352 long long fract A, int B) 1353 -- Runtime Function: short accum __ashlha3 (short accum A, int B) 1354 -- Runtime Function: accum __ashlsa3 (accum A, int B) 1355 -- Runtime Function: long accum __ashlda3 (long accum A, int B) 1356 -- Runtime Function: long long accum __ashlta3 (long long accum A, int 1357 B) 1358 -- Runtime Function: unsigned short accum __ashluha3 (unsigned short 1359 accum A, int B) 1360 -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int 1361 B) 1362 -- Runtime Function: unsigned long accum __ashluda3 (unsigned long 1363 accum A, int B) 1364 -- Runtime Function: unsigned long long accum __ashluta3 (unsigned 1365 long long accum A, int B) 1366 These functions return the result of shifting A left by B bits. 1367 1368 -- Runtime Function: short fract __ashrqq3 (short fract A, int B) 1369 -- Runtime Function: fract __ashrhq3 (fract A, int B) 1370 -- Runtime Function: long fract __ashrsq3 (long fract A, int B) 1371 -- Runtime Function: long long fract __ashrdq3 (long long fract A, int 1372 B) 1373 -- Runtime Function: short accum __ashrha3 (short accum A, int B) 1374 -- Runtime Function: accum __ashrsa3 (accum A, int B) 1375 -- Runtime Function: long accum __ashrda3 (long accum A, int B) 1376 -- Runtime Function: long long accum __ashrta3 (long long accum A, int 1377 B) 1378 These functions return the result of arithmetically shifting A 1379 right by B bits. 1380 1381 -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short 1382 fract A, int B) 1383 -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int 1384 B) 1385 -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long 1386 fract A, int B) 1387 -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned 1388 long long fract A, int B) 1389 -- Runtime Function: unsigned short accum __lshruha3 (unsigned short 1390 accum A, int B) 1391 -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int 1392 B) 1393 -- Runtime Function: unsigned long accum __lshruda3 (unsigned long 1394 accum A, int B) 1395 -- Runtime Function: unsigned long long accum __lshruta3 (unsigned 1396 long long accum A, int B) 1397 These functions return the result of logically shifting A right by 1398 B bits. 1399 1400 -- Runtime Function: fract __ssashlhq3 (fract A, int B) 1401 -- Runtime Function: long fract __ssashlsq3 (long fract A, int B) 1402 -- Runtime Function: long long fract __ssashldq3 (long long fract A, 1403 int B) 1404 -- Runtime Function: short accum __ssashlha3 (short accum A, int B) 1405 -- Runtime Function: accum __ssashlsa3 (accum A, int B) 1406 -- Runtime Function: long accum __ssashlda3 (long accum A, int B) 1407 -- Runtime Function: long long accum __ssashlta3 (long long accum A, 1408 int B) 1409 These functions return the result of shifting A left by B bits 1410 with signed saturation. 1411 1412 -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short 1413 fract A, int B) 1414 -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A, 1415 int B) 1416 -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long 1417 fract A, int B) 1418 -- Runtime Function: unsigned long long fract __usashludq3 (unsigned 1419 long long fract A, int B) 1420 -- Runtime Function: unsigned short accum __usashluha3 (unsigned short 1421 accum A, int B) 1422 -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A, 1423 int B) 1424 -- Runtime Function: unsigned long accum __usashluda3 (unsigned long 1425 accum A, int B) 1426 -- Runtime Function: unsigned long long accum __usashluta3 (unsigned 1427 long long accum A, int B) 1428 These functions return the result of shifting A left by B bits 1429 with unsigned saturation. 1430 1431 4.4.2 Comparison functions 1432 -------------------------- 1433 1434 The following functions implement fixed-point comparisons. These 1435 functions implement a low-level compare, upon which the higher level 1436 comparison operators (such as less than and greater than or equal to) 1437 can be constructed. The returned values lie in the range zero to two, 1438 to allow the high-level operators to be implemented by testing the 1439 returned result using either signed or unsigned comparison. 1440 1441 -- Runtime Function: int __cmpqq2 (short fract A, short fract B) 1442 -- Runtime Function: int __cmphq2 (fract A, fract B) 1443 -- Runtime Function: int __cmpsq2 (long fract A, long fract B) 1444 -- Runtime Function: int __cmpdq2 (long long fract A, long long fract 1445 B) 1446 -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned 1447 short fract B) 1448 -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B) 1449 -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned 1450 long fract B) 1451 -- Runtime Function: int __cmpudq2 (unsigned long long fract A, 1452 unsigned long long fract B) 1453 -- Runtime Function: int __cmpha2 (short accum A, short accum B) 1454 -- Runtime Function: int __cmpsa2 (accum A, accum B) 1455 -- Runtime Function: int __cmpda2 (long accum A, long accum B) 1456 -- Runtime Function: int __cmpta2 (long long accum A, long long accum 1457 B) 1458 -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned 1459 short accum B) 1460 -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B) 1461 -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned 1462 long accum B) 1463 -- Runtime Function: int __cmputa2 (unsigned long long accum A, 1464 unsigned long long accum B) 1465 These functions perform a signed or unsigned comparison of A and B 1466 (depending on the selected machine mode). If A is less than B, 1467 they return 0; if A is greater than B, they return 2; and if A and 1468 B are equal they return 1. 1469 1470 4.4.3 Conversion functions 1471 -------------------------- 1472 1473 -- Runtime Function: fract __fractqqhq2 (short fract A) 1474 -- Runtime Function: long fract __fractqqsq2 (short fract A) 1475 -- Runtime Function: long long fract __fractqqdq2 (short fract A) 1476 -- Runtime Function: short accum __fractqqha (short fract A) 1477 -- Runtime Function: accum __fractqqsa (short fract A) 1478 -- Runtime Function: long accum __fractqqda (short fract A) 1479 -- Runtime Function: long long accum __fractqqta (short fract A) 1480 -- Runtime Function: unsigned short fract __fractqquqq (short fract A) 1481 -- Runtime Function: unsigned fract __fractqquhq (short fract A) 1482 -- Runtime Function: unsigned long fract __fractqqusq (short fract A) 1483 -- Runtime Function: unsigned long long fract __fractqqudq (short 1484 fract A) 1485 -- Runtime Function: unsigned short accum __fractqquha (short fract A) 1486 -- Runtime Function: unsigned accum __fractqqusa (short fract A) 1487 -- Runtime Function: unsigned long accum __fractqquda (short fract A) 1488 -- Runtime Function: unsigned long long accum __fractqquta (short 1489 fract A) 1490 -- Runtime Function: signed char __fractqqqi (short fract A) 1491 -- Runtime Function: short __fractqqhi (short fract A) 1492 -- Runtime Function: int __fractqqsi (short fract A) 1493 -- Runtime Function: long __fractqqdi (short fract A) 1494 -- Runtime Function: long long __fractqqti (short fract A) 1495 -- Runtime Function: float __fractqqsf (short fract A) 1496 -- Runtime Function: double __fractqqdf (short fract A) 1497 -- Runtime Function: short fract __fracthqqq2 (fract A) 1498 -- Runtime Function: long fract __fracthqsq2 (fract A) 1499 -- Runtime Function: long long fract __fracthqdq2 (fract A) 1500 -- Runtime Function: short accum __fracthqha (fract A) 1501 -- Runtime Function: accum __fracthqsa (fract A) 1502 -- Runtime Function: long accum __fracthqda (fract A) 1503 -- Runtime Function: long long accum __fracthqta (fract A) 1504 -- Runtime Function: unsigned short fract __fracthquqq (fract A) 1505 -- Runtime Function: unsigned fract __fracthquhq (fract A) 1506 -- Runtime Function: unsigned long fract __fracthqusq (fract A) 1507 -- Runtime Function: unsigned long long fract __fracthqudq (fract A) 1508 -- Runtime Function: unsigned short accum __fracthquha (fract A) 1509 -- Runtime Function: unsigned accum __fracthqusa (fract A) 1510 -- Runtime Function: unsigned long accum __fracthquda (fract A) 1511 -- Runtime Function: unsigned long long accum __fracthquta (fract A) 1512 -- Runtime Function: signed char __fracthqqi (fract A) 1513 -- Runtime Function: short __fracthqhi (fract A) 1514 -- Runtime Function: int __fracthqsi (fract A) 1515 -- Runtime Function: long __fracthqdi (fract A) 1516 -- Runtime Function: long long __fracthqti (fract A) 1517 -- Runtime Function: float __fracthqsf (fract A) 1518 -- Runtime Function: double __fracthqdf (fract A) 1519 -- Runtime Function: short fract __fractsqqq2 (long fract A) 1520 -- Runtime Function: fract __fractsqhq2 (long fract A) 1521 -- Runtime Function: long long fract __fractsqdq2 (long fract A) 1522 -- Runtime Function: short accum __fractsqha (long fract A) 1523 -- Runtime Function: accum __fractsqsa (long fract A) 1524 -- Runtime Function: long accum __fractsqda (long fract A) 1525 -- Runtime Function: long long accum __fractsqta (long fract A) 1526 -- Runtime Function: unsigned short fract __fractsquqq (long fract A) 1527 -- Runtime Function: unsigned fract __fractsquhq (long fract A) 1528 -- Runtime Function: unsigned long fract __fractsqusq (long fract A) 1529 -- Runtime Function: unsigned long long fract __fractsqudq (long fract 1530 A) 1531 -- Runtime Function: unsigned short accum __fractsquha (long fract A) 1532 -- Runtime Function: unsigned accum __fractsqusa (long fract A) 1533 -- Runtime Function: unsigned long accum __fractsquda (long fract A) 1534 -- Runtime Function: unsigned long long accum __fractsquta (long fract 1535 A) 1536 -- Runtime Function: signed char __fractsqqi (long fract A) 1537 -- Runtime Function: short __fractsqhi (long fract A) 1538 -- Runtime Function: int __fractsqsi (long fract A) 1539 -- Runtime Function: long __fractsqdi (long fract A) 1540 -- Runtime Function: long long __fractsqti (long fract A) 1541 -- Runtime Function: float __fractsqsf (long fract A) 1542 -- Runtime Function: double __fractsqdf (long fract A) 1543 -- Runtime Function: short fract __fractdqqq2 (long long fract A) 1544 -- Runtime Function: fract __fractdqhq2 (long long fract A) 1545 -- Runtime Function: long fract __fractdqsq2 (long long fract A) 1546 -- Runtime Function: short accum __fractdqha (long long fract A) 1547 -- Runtime Function: accum __fractdqsa (long long fract A) 1548 -- Runtime Function: long accum __fractdqda (long long fract A) 1549 -- Runtime Function: long long accum __fractdqta (long long fract A) 1550 -- Runtime Function: unsigned short fract __fractdquqq (long long 1551 fract A) 1552 -- Runtime Function: unsigned fract __fractdquhq (long long fract A) 1553 -- Runtime Function: unsigned long fract __fractdqusq (long long fract 1554 A) 1555 -- Runtime Function: unsigned long long fract __fractdqudq (long long 1556 fract A) 1557 -- Runtime Function: unsigned short accum __fractdquha (long long 1558 fract A) 1559 -- Runtime Function: unsigned accum __fractdqusa (long long fract A) 1560 -- Runtime Function: unsigned long accum __fractdquda (long long fract 1561 A) 1562 -- Runtime Function: unsigned long long accum __fractdquta (long long 1563 fract A) 1564 -- Runtime Function: signed char __fractdqqi (long long fract A) 1565 -- Runtime Function: short __fractdqhi (long long fract A) 1566 -- Runtime Function: int __fractdqsi (long long fract A) 1567 -- Runtime Function: long __fractdqdi (long long fract A) 1568 -- Runtime Function: long long __fractdqti (long long fract A) 1569 -- Runtime Function: float __fractdqsf (long long fract A) 1570 -- Runtime Function: double __fractdqdf (long long fract A) 1571 -- Runtime Function: short fract __fracthaqq (short accum A) 1572 -- Runtime Function: fract __fracthahq (short accum A) 1573 -- Runtime Function: long fract __fracthasq (short accum A) 1574 -- Runtime Function: long long fract __fracthadq (short accum A) 1575 -- Runtime Function: accum __fracthasa2 (short accum A) 1576 -- Runtime Function: long accum __fracthada2 (short accum A) 1577 -- Runtime Function: long long accum __fracthata2 (short accum A) 1578 -- Runtime Function: unsigned short fract __fracthauqq (short accum A) 1579 -- Runtime Function: unsigned fract __fracthauhq (short accum A) 1580 -- Runtime Function: unsigned long fract __fracthausq (short accum A) 1581 -- Runtime Function: unsigned long long fract __fracthaudq (short 1582 accum A) 1583 -- Runtime Function: unsigned short accum __fracthauha (short accum A) 1584 -- Runtime Function: unsigned accum __fracthausa (short accum A) 1585 -- Runtime Function: unsigned long accum __fracthauda (short accum A) 1586 -- Runtime Function: unsigned long long accum __fracthauta (short 1587 accum A) 1588 -- Runtime Function: signed char __fracthaqi (short accum A) 1589 -- Runtime Function: short __fracthahi (short accum A) 1590 -- Runtime Function: int __fracthasi (short accum A) 1591 -- Runtime Function: long __fracthadi (short accum A) 1592 -- Runtime Function: long long __fracthati (short accum A) 1593 -- Runtime Function: float __fracthasf (short accum A) 1594 -- Runtime Function: double __fracthadf (short accum A) 1595 -- Runtime Function: short fract __fractsaqq (accum A) 1596 -- Runtime Function: fract __fractsahq (accum A) 1597 -- Runtime Function: long fract __fractsasq (accum A) 1598 -- Runtime Function: long long fract __fractsadq (accum A) 1599 -- Runtime Function: short accum __fractsaha2 (accum A) 1600 -- Runtime Function: long accum __fractsada2 (accum A) 1601 -- Runtime Function: long long accum __fractsata2 (accum A) 1602 -- Runtime Function: unsigned short fract __fractsauqq (accum A) 1603 -- Runtime Function: unsigned fract __fractsauhq (accum A) 1604 -- Runtime Function: unsigned long fract __fractsausq (accum A) 1605 -- Runtime Function: unsigned long long fract __fractsaudq (accum A) 1606 -- Runtime Function: unsigned short accum __fractsauha (accum A) 1607 -- Runtime Function: unsigned accum __fractsausa (accum A) 1608 -- Runtime Function: unsigned long accum __fractsauda (accum A) 1609 -- Runtime Function: unsigned long long accum __fractsauta (accum A) 1610 -- Runtime Function: signed char __fractsaqi (accum A) 1611 -- Runtime Function: short __fractsahi (accum A) 1612 -- Runtime Function: int __fractsasi (accum A) 1613 -- Runtime Function: long __fractsadi (accum A) 1614 -- Runtime Function: long long __fractsati (accum A) 1615 -- Runtime Function: float __fractsasf (accum A) 1616 -- Runtime Function: double __fractsadf (accum A) 1617 -- Runtime Function: short fract __fractdaqq (long accum A) 1618 -- Runtime Function: fract __fractdahq (long accum A) 1619 -- Runtime Function: long fract __fractdasq (long accum A) 1620 -- Runtime Function: long long fract __fractdadq (long accum A) 1621 -- Runtime Function: short accum __fractdaha2 (long accum A) 1622 -- Runtime Function: accum __fractdasa2 (long accum A) 1623 -- Runtime Function: long long accum __fractdata2 (long accum A) 1624 -- Runtime Function: unsigned short fract __fractdauqq (long accum A) 1625 -- Runtime Function: unsigned fract __fractdauhq (long accum A) 1626 -- Runtime Function: unsigned long fract __fractdausq (long accum A) 1627 -- Runtime Function: unsigned long long fract __fractdaudq (long accum 1628 A) 1629 -- Runtime Function: unsigned short accum __fractdauha (long accum A) 1630 -- Runtime Function: unsigned accum __fractdausa (long accum A) 1631 -- Runtime Function: unsigned long accum __fractdauda (long accum A) 1632 -- Runtime Function: unsigned long long accum __fractdauta (long accum 1633 A) 1634 -- Runtime Function: signed char __fractdaqi (long accum A) 1635 -- Runtime Function: short __fractdahi (long accum A) 1636 -- Runtime Function: int __fractdasi (long accum A) 1637 -- Runtime Function: long __fractdadi (long accum A) 1638 -- Runtime Function: long long __fractdati (long accum A) 1639 -- Runtime Function: float __fractdasf (long accum A) 1640 -- Runtime Function: double __fractdadf (long accum A) 1641 -- Runtime Function: short fract __fracttaqq (long long accum A) 1642 -- Runtime Function: fract __fracttahq (long long accum A) 1643 -- Runtime Function: long fract __fracttasq (long long accum A) 1644 -- Runtime Function: long long fract __fracttadq (long long accum A) 1645 -- Runtime Function: short accum __fracttaha2 (long long accum A) 1646 -- Runtime Function: accum __fracttasa2 (long long accum A) 1647 -- Runtime Function: long accum __fracttada2 (long long accum A) 1648 -- Runtime Function: unsigned short fract __fracttauqq (long long 1649 accum A) 1650 -- Runtime Function: unsigned fract __fracttauhq (long long accum A) 1651 -- Runtime Function: unsigned long fract __fracttausq (long long accum 1652 A) 1653 -- Runtime Function: unsigned long long fract __fracttaudq (long long 1654 accum A) 1655 -- Runtime Function: unsigned short accum __fracttauha (long long 1656 accum A) 1657 -- Runtime Function: unsigned accum __fracttausa (long long accum A) 1658 -- Runtime Function: unsigned long accum __fracttauda (long long accum 1659 A) 1660 -- Runtime Function: unsigned long long accum __fracttauta (long long 1661 accum A) 1662 -- Runtime Function: signed char __fracttaqi (long long accum A) 1663 -- Runtime Function: short __fracttahi (long long accum A) 1664 -- Runtime Function: int __fracttasi (long long accum A) 1665 -- Runtime Function: long __fracttadi (long long accum A) 1666 -- Runtime Function: long long __fracttati (long long accum A) 1667 -- Runtime Function: float __fracttasf (long long accum A) 1668 -- Runtime Function: double __fracttadf (long long accum A) 1669 -- Runtime Function: short fract __fractuqqqq (unsigned short fract A) 1670 -- Runtime Function: fract __fractuqqhq (unsigned short fract A) 1671 -- Runtime Function: long fract __fractuqqsq (unsigned short fract A) 1672 -- Runtime Function: long long fract __fractuqqdq (unsigned short 1673 fract A) 1674 -- Runtime Function: short accum __fractuqqha (unsigned short fract A) 1675 -- Runtime Function: accum __fractuqqsa (unsigned short fract A) 1676 -- Runtime Function: long accum __fractuqqda (unsigned short fract A) 1677 -- Runtime Function: long long accum __fractuqqta (unsigned short 1678 fract A) 1679 -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short 1680 fract A) 1681 -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned 1682 short fract A) 1683 -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned 1684 short fract A) 1685 -- Runtime Function: unsigned short accum __fractuqquha (unsigned 1686 short fract A) 1687 -- Runtime Function: unsigned accum __fractuqqusa (unsigned short 1688 fract A) 1689 -- Runtime Function: unsigned long accum __fractuqquda (unsigned short 1690 fract A) 1691 -- Runtime Function: unsigned long long accum __fractuqquta (unsigned 1692 short fract A) 1693 -- Runtime Function: signed char __fractuqqqi (unsigned short fract A) 1694 -- Runtime Function: short __fractuqqhi (unsigned short fract A) 1695 -- Runtime Function: int __fractuqqsi (unsigned short fract A) 1696 -- Runtime Function: long __fractuqqdi (unsigned short fract A) 1697 -- Runtime Function: long long __fractuqqti (unsigned short fract A) 1698 -- Runtime Function: float __fractuqqsf (unsigned short fract A) 1699 -- Runtime Function: double __fractuqqdf (unsigned short fract A) 1700 -- Runtime Function: short fract __fractuhqqq (unsigned fract A) 1701 -- Runtime Function: fract __fractuhqhq (unsigned fract A) 1702 -- Runtime Function: long fract __fractuhqsq (unsigned fract A) 1703 -- Runtime Function: long long fract __fractuhqdq (unsigned fract A) 1704 -- Runtime Function: short accum __fractuhqha (unsigned fract A) 1705 -- Runtime Function: accum __fractuhqsa (unsigned fract A) 1706 -- Runtime Function: long accum __fractuhqda (unsigned fract A) 1707 -- Runtime Function: long long accum __fractuhqta (unsigned fract A) 1708 -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned 1709 fract A) 1710 -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned 1711 fract A) 1712 -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned 1713 fract A) 1714 -- Runtime Function: unsigned short accum __fractuhquha (unsigned 1715 fract A) 1716 -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A) 1717 -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract 1718 A) 1719 -- Runtime Function: unsigned long long accum __fractuhquta (unsigned 1720 fract A) 1721 -- Runtime Function: signed char __fractuhqqi (unsigned fract A) 1722 -- Runtime Function: short __fractuhqhi (unsigned fract A) 1723 -- Runtime Function: int __fractuhqsi (unsigned fract A) 1724 -- Runtime Function: long __fractuhqdi (unsigned fract A) 1725 -- Runtime Function: long long __fractuhqti (unsigned fract A) 1726 -- Runtime Function: float __fractuhqsf (unsigned fract A) 1727 -- Runtime Function: double __fractuhqdf (unsigned fract A) 1728 -- Runtime Function: short fract __fractusqqq (unsigned long fract A) 1729 -- Runtime Function: fract __fractusqhq (unsigned long fract A) 1730 -- Runtime Function: long fract __fractusqsq (unsigned long fract A) 1731 -- Runtime Function: long long fract __fractusqdq (unsigned long fract 1732 A) 1733 -- Runtime Function: short accum __fractusqha (unsigned long fract A) 1734 -- Runtime Function: accum __fractusqsa (unsigned long fract A) 1735 -- Runtime Function: long accum __fractusqda (unsigned long fract A) 1736 -- Runtime Function: long long accum __fractusqta (unsigned long fract 1737 A) 1738 -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned 1739 long fract A) 1740 -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long 1741 fract A) 1742 -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned 1743 long fract A) 1744 -- Runtime Function: unsigned short accum __fractusquha (unsigned long 1745 fract A) 1746 -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract 1747 A) 1748 -- Runtime Function: unsigned long accum __fractusquda (unsigned long 1749 fract A) 1750 -- Runtime Function: unsigned long long accum __fractusquta (unsigned 1751 long fract A) 1752 -- Runtime Function: signed char __fractusqqi (unsigned long fract A) 1753 -- Runtime Function: short __fractusqhi (unsigned long fract A) 1754 -- Runtime Function: int __fractusqsi (unsigned long fract A) 1755 -- Runtime Function: long __fractusqdi (unsigned long fract A) 1756 -- Runtime Function: long long __fractusqti (unsigned long fract A) 1757 -- Runtime Function: float __fractusqsf (unsigned long fract A) 1758 -- Runtime Function: double __fractusqdf (unsigned long fract A) 1759 -- Runtime Function: short fract __fractudqqq (unsigned long long 1760 fract A) 1761 -- Runtime Function: fract __fractudqhq (unsigned long long fract A) 1762 -- Runtime Function: long fract __fractudqsq (unsigned long long fract 1763 A) 1764 -- Runtime Function: long long fract __fractudqdq (unsigned long long 1765 fract A) 1766 -- Runtime Function: short accum __fractudqha (unsigned long long 1767 fract A) 1768 -- Runtime Function: accum __fractudqsa (unsigned long long fract A) 1769 -- Runtime Function: long accum __fractudqda (unsigned long long fract 1770 A) 1771 -- Runtime Function: long long accum __fractudqta (unsigned long long 1772 fract A) 1773 -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned 1774 long long fract A) 1775 -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long 1776 fract A) 1777 -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long 1778 long fract A) 1779 -- Runtime Function: unsigned short accum __fractudquha (unsigned long 1780 long fract A) 1781 -- Runtime Function: unsigned accum __fractudqusa (unsigned long long 1782 fract A) 1783 -- Runtime Function: unsigned long accum __fractudquda (unsigned long 1784 long fract A) 1785 -- Runtime Function: unsigned long long accum __fractudquta (unsigned 1786 long long fract A) 1787 -- Runtime Function: signed char __fractudqqi (unsigned long long 1788 fract A) 1789 -- Runtime Function: short __fractudqhi (unsigned long long fract A) 1790 -- Runtime Function: int __fractudqsi (unsigned long long fract A) 1791 -- Runtime Function: long __fractudqdi (unsigned long long fract A) 1792 -- Runtime Function: long long __fractudqti (unsigned long long fract 1793 A) 1794 -- Runtime Function: float __fractudqsf (unsigned long long fract A) 1795 -- Runtime Function: double __fractudqdf (unsigned long long fract A) 1796 -- Runtime Function: short fract __fractuhaqq (unsigned short accum A) 1797 -- Runtime Function: fract __fractuhahq (unsigned short accum A) 1798 -- Runtime Function: long fract __fractuhasq (unsigned short accum A) 1799 -- Runtime Function: long long fract __fractuhadq (unsigned short 1800 accum A) 1801 -- Runtime Function: short accum __fractuhaha (unsigned short accum A) 1802 -- Runtime Function: accum __fractuhasa (unsigned short accum A) 1803 -- Runtime Function: long accum __fractuhada (unsigned short accum A) 1804 -- Runtime Function: long long accum __fractuhata (unsigned short 1805 accum A) 1806 -- Runtime Function: unsigned short fract __fractuhauqq (unsigned 1807 short accum A) 1808 -- Runtime Function: unsigned fract __fractuhauhq (unsigned short 1809 accum A) 1810 -- Runtime Function: unsigned long fract __fractuhausq (unsigned short 1811 accum A) 1812 -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned 1813 short accum A) 1814 -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short 1815 accum A) 1816 -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned 1817 short accum A) 1818 -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned 1819 short accum A) 1820 -- Runtime Function: signed char __fractuhaqi (unsigned short accum A) 1821 -- Runtime Function: short __fractuhahi (unsigned short accum A) 1822 -- Runtime Function: int __fractuhasi (unsigned short accum A) 1823 -- Runtime Function: long __fractuhadi (unsigned short accum A) 1824 -- Runtime Function: long long __fractuhati (unsigned short accum A) 1825 -- Runtime Function: float __fractuhasf (unsigned short accum A) 1826 -- Runtime Function: double __fractuhadf (unsigned short accum A) 1827 -- Runtime Function: short fract __fractusaqq (unsigned accum A) 1828 -- Runtime Function: fract __fractusahq (unsigned accum A) 1829 -- Runtime Function: long fract __fractusasq (unsigned accum A) 1830 -- Runtime Function: long long fract __fractusadq (unsigned accum A) 1831 -- Runtime Function: short accum __fractusaha (unsigned accum A) 1832 -- Runtime Function: accum __fractusasa (unsigned accum A) 1833 -- Runtime Function: long accum __fractusada (unsigned accum A) 1834 -- Runtime Function: long long accum __fractusata (unsigned accum A) 1835 -- Runtime Function: unsigned short fract __fractusauqq (unsigned 1836 accum A) 1837 -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A) 1838 -- Runtime Function: unsigned long fract __fractusausq (unsigned accum 1839 A) 1840 -- Runtime Function: unsigned long long fract __fractusaudq (unsigned 1841 accum A) 1842 -- Runtime Function: unsigned short accum __fractusauha2 (unsigned 1843 accum A) 1844 -- Runtime Function: unsigned long accum __fractusauda2 (unsigned 1845 accum A) 1846 -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned 1847 accum A) 1848 -- Runtime Function: signed char __fractusaqi (unsigned accum A) 1849 -- Runtime Function: short __fractusahi (unsigned accum A) 1850 -- Runtime Function: int __fractusasi (unsigned accum A) 1851 -- Runtime Function: long __fractusadi (unsigned accum A) 1852 -- Runtime Function: long long __fractusati (unsigned accum A) 1853 -- Runtime Function: float __fractusasf (unsigned accum A) 1854 -- Runtime Function: double __fractusadf (unsigned accum A) 1855 -- Runtime Function: short fract __fractudaqq (unsigned long accum A) 1856 -- Runtime Function: fract __fractudahq (unsigned long accum A) 1857 -- Runtime Function: long fract __fractudasq (unsigned long accum A) 1858 -- Runtime Function: long long fract __fractudadq (unsigned long accum 1859 A) 1860 -- Runtime Function: short accum __fractudaha (unsigned long accum A) 1861 -- Runtime Function: accum __fractudasa (unsigned long accum A) 1862 -- Runtime Function: long accum __fractudada (unsigned long accum A) 1863 -- Runtime Function: long long accum __fractudata (unsigned long accum 1864 A) 1865 -- Runtime Function: unsigned short fract __fractudauqq (unsigned long 1866 accum A) 1867 -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum 1868 A) 1869 -- Runtime Function: unsigned long fract __fractudausq (unsigned long 1870 accum A) 1871 -- Runtime Function: unsigned long long fract __fractudaudq (unsigned 1872 long accum A) 1873 -- Runtime Function: unsigned short accum __fractudauha2 (unsigned 1874 long accum A) 1875 -- Runtime Function: unsigned accum __fractudausa2 (unsigned long 1876 accum A) 1877 -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned 1878 long accum A) 1879 -- Runtime Function: signed char __fractudaqi (unsigned long accum A) 1880 -- Runtime Function: short __fractudahi (unsigned long accum A) 1881 -- Runtime Function: int __fractudasi (unsigned long accum A) 1882 -- Runtime Function: long __fractudadi (unsigned long accum A) 1883 -- Runtime Function: long long __fractudati (unsigned long accum A) 1884 -- Runtime Function: float __fractudasf (unsigned long accum A) 1885 -- Runtime Function: double __fractudadf (unsigned long accum A) 1886 -- Runtime Function: short fract __fractutaqq (unsigned long long 1887 accum A) 1888 -- Runtime Function: fract __fractutahq (unsigned long long accum A) 1889 -- Runtime Function: long fract __fractutasq (unsigned long long accum 1890 A) 1891 -- Runtime Function: long long fract __fractutadq (unsigned long long 1892 accum A) 1893 -- Runtime Function: short accum __fractutaha (unsigned long long 1894 accum A) 1895 -- Runtime Function: accum __fractutasa (unsigned long long accum A) 1896 -- Runtime Function: long accum __fractutada (unsigned long long accum 1897 A) 1898 -- Runtime Function: long long accum __fractutata (unsigned long long 1899 accum A) 1900 -- Runtime Function: unsigned short fract __fractutauqq (unsigned long 1901 long accum A) 1902 -- Runtime Function: unsigned fract __fractutauhq (unsigned long long 1903 accum A) 1904 -- Runtime Function: unsigned long fract __fractutausq (unsigned long 1905 long accum A) 1906 -- Runtime Function: unsigned long long fract __fractutaudq (unsigned 1907 long long accum A) 1908 -- Runtime Function: unsigned short accum __fractutauha2 (unsigned 1909 long long accum A) 1910 -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long 1911 accum A) 1912 -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long 1913 long accum A) 1914 -- Runtime Function: signed char __fractutaqi (unsigned long long 1915 accum A) 1916 -- Runtime Function: short __fractutahi (unsigned long long accum A) 1917 -- Runtime Function: int __fractutasi (unsigned long long accum A) 1918 -- Runtime Function: long __fractutadi (unsigned long long accum A) 1919 -- Runtime Function: long long __fractutati (unsigned long long accum 1920 A) 1921 -- Runtime Function: float __fractutasf (unsigned long long accum A) 1922 -- Runtime Function: double __fractutadf (unsigned long long accum A) 1923 -- Runtime Function: short fract __fractqiqq (signed char A) 1924 -- Runtime Function: fract __fractqihq (signed char A) 1925 -- Runtime Function: long fract __fractqisq (signed char A) 1926 -- Runtime Function: long long fract __fractqidq (signed char A) 1927 -- Runtime Function: short accum __fractqiha (signed char A) 1928 -- Runtime Function: accum __fractqisa (signed char A) 1929 -- Runtime Function: long accum __fractqida (signed char A) 1930 -- Runtime Function: long long accum __fractqita (signed char A) 1931 -- Runtime Function: unsigned short fract __fractqiuqq (signed char A) 1932 -- Runtime Function: unsigned fract __fractqiuhq (signed char A) 1933 -- Runtime Function: unsigned long fract __fractqiusq (signed char A) 1934 -- Runtime Function: unsigned long long fract __fractqiudq (signed 1935 char A) 1936 -- Runtime Function: unsigned short accum __fractqiuha (signed char A) 1937 -- Runtime Function: unsigned accum __fractqiusa (signed char A) 1938 -- Runtime Function: unsigned long accum __fractqiuda (signed char A) 1939 -- Runtime Function: unsigned long long accum __fractqiuta (signed 1940 char A) 1941 -- Runtime Function: short fract __fracthiqq (short A) 1942 -- Runtime Function: fract __fracthihq (short A) 1943 -- Runtime Function: long fract __fracthisq (short A) 1944 -- Runtime Function: long long fract __fracthidq (short A) 1945 -- Runtime Function: short accum __fracthiha (short A) 1946 -- Runtime Function: accum __fracthisa (short A) 1947 -- Runtime Function: long accum __fracthida (short A) 1948 -- Runtime Function: long long accum __fracthita (short A) 1949 -- Runtime Function: unsigned short fract __fracthiuqq (short A) 1950 -- Runtime Function: unsigned fract __fracthiuhq (short A) 1951 -- Runtime Function: unsigned long fract __fracthiusq (short A) 1952 -- Runtime Function: unsigned long long fract __fracthiudq (short A) 1953 -- Runtime Function: unsigned short accum __fracthiuha (short A) 1954 -- Runtime Function: unsigned accum __fracthiusa (short A) 1955 -- Runtime Function: unsigned long accum __fracthiuda (short A) 1956 -- Runtime Function: unsigned long long accum __fracthiuta (short A) 1957 -- Runtime Function: short fract __fractsiqq (int A) 1958 -- Runtime Function: fract __fractsihq (int A) 1959 -- Runtime Function: long fract __fractsisq (int A) 1960 -- Runtime Function: long long fract __fractsidq (int A) 1961 -- Runtime Function: short accum __fractsiha (int A) 1962 -- Runtime Function: accum __fractsisa (int A) 1963 -- Runtime Function: long accum __fractsida (int A) 1964 -- Runtime Function: long long accum __fractsita (int A) 1965 -- Runtime Function: unsigned short fract __fractsiuqq (int A) 1966 -- Runtime Function: unsigned fract __fractsiuhq (int A) 1967 -- Runtime Function: unsigned long fract __fractsiusq (int A) 1968 -- Runtime Function: unsigned long long fract __fractsiudq (int A) 1969 -- Runtime Function: unsigned short accum __fractsiuha (int A) 1970 -- Runtime Function: unsigned accum __fractsiusa (int A) 1971 -- Runtime Function: unsigned long accum __fractsiuda (int A) 1972 -- Runtime Function: unsigned long long accum __fractsiuta (int A) 1973 -- Runtime Function: short fract __fractdiqq (long A) 1974 -- Runtime Function: fract __fractdihq (long A) 1975 -- Runtime Function: long fract __fractdisq (long A) 1976 -- Runtime Function: long long fract __fractdidq (long A) 1977 -- Runtime Function: short accum __fractdiha (long A) 1978 -- Runtime Function: accum __fractdisa (long A) 1979 -- Runtime Function: long accum __fractdida (long A) 1980 -- Runtime Function: long long accum __fractdita (long A) 1981 -- Runtime Function: unsigned short fract __fractdiuqq (long A) 1982 -- Runtime Function: unsigned fract __fractdiuhq (long A) 1983 -- Runtime Function: unsigned long fract __fractdiusq (long A) 1984 -- Runtime Function: unsigned long long fract __fractdiudq (long A) 1985 -- Runtime Function: unsigned short accum __fractdiuha (long A) 1986 -- Runtime Function: unsigned accum __fractdiusa (long A) 1987 -- Runtime Function: unsigned long accum __fractdiuda (long A) 1988 -- Runtime Function: unsigned long long accum __fractdiuta (long A) 1989 -- Runtime Function: short fract __fracttiqq (long long A) 1990 -- Runtime Function: fract __fracttihq (long long A) 1991 -- Runtime Function: long fract __fracttisq (long long A) 1992 -- Runtime Function: long long fract __fracttidq (long long A) 1993 -- Runtime Function: short accum __fracttiha (long long A) 1994 -- Runtime Function: accum __fracttisa (long long A) 1995 -- Runtime Function: long accum __fracttida (long long A) 1996 -- Runtime Function: long long accum __fracttita (long long A) 1997 -- Runtime Function: unsigned short fract __fracttiuqq (long long A) 1998 -- Runtime Function: unsigned fract __fracttiuhq (long long A) 1999 -- Runtime Function: unsigned long fract __fracttiusq (long long A) 2000 -- Runtime Function: unsigned long long fract __fracttiudq (long long 2001 A) 2002 -- Runtime Function: unsigned short accum __fracttiuha (long long A) 2003 -- Runtime Function: unsigned accum __fracttiusa (long long A) 2004 -- Runtime Function: unsigned long accum __fracttiuda (long long A) 2005 -- Runtime Function: unsigned long long accum __fracttiuta (long long 2006 A) 2007 -- Runtime Function: short fract __fractsfqq (float A) 2008 -- Runtime Function: fract __fractsfhq (float A) 2009 -- Runtime Function: long fract __fractsfsq (float A) 2010 -- Runtime Function: long long fract __fractsfdq (float A) 2011 -- Runtime Function: short accum __fractsfha (float A) 2012 -- Runtime Function: accum __fractsfsa (float A) 2013 -- Runtime Function: long accum __fractsfda (float A) 2014 -- Runtime Function: long long accum __fractsfta (float A) 2015 -- Runtime Function: unsigned short fract __fractsfuqq (float A) 2016 -- Runtime Function: unsigned fract __fractsfuhq (float A) 2017 -- Runtime Function: unsigned long fract __fractsfusq (float A) 2018 -- Runtime Function: unsigned long long fract __fractsfudq (float A) 2019 -- Runtime Function: unsigned short accum __fractsfuha (float A) 2020 -- Runtime Function: unsigned accum __fractsfusa (float A) 2021 -- Runtime Function: unsigned long accum __fractsfuda (float A) 2022 -- Runtime Function: unsigned long long accum __fractsfuta (float A) 2023 -- Runtime Function: short fract __fractdfqq (double A) 2024 -- Runtime Function: fract __fractdfhq (double A) 2025 -- Runtime Function: long fract __fractdfsq (double A) 2026 -- Runtime Function: long long fract __fractdfdq (double A) 2027 -- Runtime Function: short accum __fractdfha (double A) 2028 -- Runtime Function: accum __fractdfsa (double A) 2029 -- Runtime Function: long accum __fractdfda (double A) 2030 -- Runtime Function: long long accum __fractdfta (double A) 2031 -- Runtime Function: unsigned short fract __fractdfuqq (double A) 2032 -- Runtime Function: unsigned fract __fractdfuhq (double A) 2033 -- Runtime Function: unsigned long fract __fractdfusq (double A) 2034 -- Runtime Function: unsigned long long fract __fractdfudq (double A) 2035 -- Runtime Function: unsigned short accum __fractdfuha (double A) 2036 -- Runtime Function: unsigned accum __fractdfusa (double A) 2037 -- Runtime Function: unsigned long accum __fractdfuda (double A) 2038 -- Runtime Function: unsigned long long accum __fractdfuta (double A) 2039 These functions convert from fractional and signed non-fractionals 2040 to fractionals and signed non-fractionals, without saturation. 2041 2042 -- Runtime Function: fract __satfractqqhq2 (short fract A) 2043 -- Runtime Function: long fract __satfractqqsq2 (short fract A) 2044 -- Runtime Function: long long fract __satfractqqdq2 (short fract A) 2045 -- Runtime Function: short accum __satfractqqha (short fract A) 2046 -- Runtime Function: accum __satfractqqsa (short fract A) 2047 -- Runtime Function: long accum __satfractqqda (short fract A) 2048 -- Runtime Function: long long accum __satfractqqta (short fract A) 2049 -- Runtime Function: unsigned short fract __satfractqquqq (short fract 2050 A) 2051 -- Runtime Function: unsigned fract __satfractqquhq (short fract A) 2052 -- Runtime Function: unsigned long fract __satfractqqusq (short fract 2053 A) 2054 -- Runtime Function: unsigned long long fract __satfractqqudq (short 2055 fract A) 2056 -- Runtime Function: unsigned short accum __satfractqquha (short fract 2057 A) 2058 -- Runtime Function: unsigned accum __satfractqqusa (short fract A) 2059 -- Runtime Function: unsigned long accum __satfractqquda (short fract 2060 A) 2061 -- Runtime Function: unsigned long long accum __satfractqquta (short 2062 fract A) 2063 -- Runtime Function: short fract __satfracthqqq2 (fract A) 2064 -- Runtime Function: long fract __satfracthqsq2 (fract A) 2065 -- Runtime Function: long long fract __satfracthqdq2 (fract A) 2066 -- Runtime Function: short accum __satfracthqha (fract A) 2067 -- Runtime Function: accum __satfracthqsa (fract A) 2068 -- Runtime Function: long accum __satfracthqda (fract A) 2069 -- Runtime Function: long long accum __satfracthqta (fract A) 2070 -- Runtime Function: unsigned short fract __satfracthquqq (fract A) 2071 -- Runtime Function: unsigned fract __satfracthquhq (fract A) 2072 -- Runtime Function: unsigned long fract __satfracthqusq (fract A) 2073 -- Runtime Function: unsigned long long fract __satfracthqudq (fract A) 2074 -- Runtime Function: unsigned short accum __satfracthquha (fract A) 2075 -- Runtime Function: unsigned accum __satfracthqusa (fract A) 2076 -- Runtime Function: unsigned long accum __satfracthquda (fract A) 2077 -- Runtime Function: unsigned long long accum __satfracthquta (fract A) 2078 -- Runtime Function: short fract __satfractsqqq2 (long fract A) 2079 -- Runtime Function: fract __satfractsqhq2 (long fract A) 2080 -- Runtime Function: long long fract __satfractsqdq2 (long fract A) 2081 -- Runtime Function: short accum __satfractsqha (long fract A) 2082 -- Runtime Function: accum __satfractsqsa (long fract A) 2083 -- Runtime Function: long accum __satfractsqda (long fract A) 2084 -- Runtime Function: long long accum __satfractsqta (long fract A) 2085 -- Runtime Function: unsigned short fract __satfractsquqq (long fract 2086 A) 2087 -- Runtime Function: unsigned fract __satfractsquhq (long fract A) 2088 -- Runtime Function: unsigned long fract __satfractsqusq (long fract A) 2089 -- Runtime Function: unsigned long long fract __satfractsqudq (long 2090 fract A) 2091 -- Runtime Function: unsigned short accum __satfractsquha (long fract 2092 A) 2093 -- Runtime Function: unsigned accum __satfractsqusa (long fract A) 2094 -- Runtime Function: unsigned long accum __satfractsquda (long fract A) 2095 -- Runtime Function: unsigned long long accum __satfractsquta (long 2096 fract A) 2097 -- Runtime Function: short fract __satfractdqqq2 (long long fract A) 2098 -- Runtime Function: fract __satfractdqhq2 (long long fract A) 2099 -- Runtime Function: long fract __satfractdqsq2 (long long fract A) 2100 -- Runtime Function: short accum __satfractdqha (long long fract A) 2101 -- Runtime Function: accum __satfractdqsa (long long fract A) 2102 -- Runtime Function: long accum __satfractdqda (long long fract A) 2103 -- Runtime Function: long long accum __satfractdqta (long long fract A) 2104 -- Runtime Function: unsigned short fract __satfractdquqq (long long 2105 fract A) 2106 -- Runtime Function: unsigned fract __satfractdquhq (long long fract A) 2107 -- Runtime Function: unsigned long fract __satfractdqusq (long long 2108 fract A) 2109 -- Runtime Function: unsigned long long fract __satfractdqudq (long 2110 long fract A) 2111 -- Runtime Function: unsigned short accum __satfractdquha (long long 2112 fract A) 2113 -- Runtime Function: unsigned accum __satfractdqusa (long long fract A) 2114 -- Runtime Function: unsigned long accum __satfractdquda (long long 2115 fract A) 2116 -- Runtime Function: unsigned long long accum __satfractdquta (long 2117 long fract A) 2118 -- Runtime Function: short fract __satfracthaqq (short accum A) 2119 -- Runtime Function: fract __satfracthahq (short accum A) 2120 -- Runtime Function: long fract __satfracthasq (short accum A) 2121 -- Runtime Function: long long fract __satfracthadq (short accum A) 2122 -- Runtime Function: accum __satfracthasa2 (short accum A) 2123 -- Runtime Function: long accum __satfracthada2 (short accum A) 2124 -- Runtime Function: long long accum __satfracthata2 (short accum A) 2125 -- Runtime Function: unsigned short fract __satfracthauqq (short accum 2126 A) 2127 -- Runtime Function: unsigned fract __satfracthauhq (short accum A) 2128 -- Runtime Function: unsigned long fract __satfracthausq (short accum 2129 A) 2130 -- Runtime Function: unsigned long long fract __satfracthaudq (short 2131 accum A) 2132 -- Runtime Function: unsigned short accum __satfracthauha (short accum 2133 A) 2134 -- Runtime Function: unsigned accum __satfracthausa (short accum A) 2135 -- Runtime Function: unsigned long accum __satfracthauda (short accum 2136 A) 2137 -- Runtime Function: unsigned long long accum __satfracthauta (short 2138 accum A) 2139 -- Runtime Function: short fract __satfractsaqq (accum A) 2140 -- Runtime Function: fract __satfractsahq (accum A) 2141 -- Runtime Function: long fract __satfractsasq (accum A) 2142 -- Runtime Function: long long fract __satfractsadq (accum A) 2143 -- Runtime Function: short accum __satfractsaha2 (accum A) 2144 -- Runtime Function: long accum __satfractsada2 (accum A) 2145 -- Runtime Function: long long accum __satfractsata2 (accum A) 2146 -- Runtime Function: unsigned short fract __satfractsauqq (accum A) 2147 -- Runtime Function: unsigned fract __satfractsauhq (accum A) 2148 -- Runtime Function: unsigned long fract __satfractsausq (accum A) 2149 -- Runtime Function: unsigned long long fract __satfractsaudq (accum A) 2150 -- Runtime Function: unsigned short accum __satfractsauha (accum A) 2151 -- Runtime Function: unsigned accum __satfractsausa (accum A) 2152 -- Runtime Function: unsigned long accum __satfractsauda (accum A) 2153 -- Runtime Function: unsigned long long accum __satfractsauta (accum A) 2154 -- Runtime Function: short fract __satfractdaqq (long accum A) 2155 -- Runtime Function: fract __satfractdahq (long accum A) 2156 -- Runtime Function: long fract __satfractdasq (long accum A) 2157 -- Runtime Function: long long fract __satfractdadq (long accum A) 2158 -- Runtime Function: short accum __satfractdaha2 (long accum A) 2159 -- Runtime Function: accum __satfractdasa2 (long accum A) 2160 -- Runtime Function: long long accum __satfractdata2 (long accum A) 2161 -- Runtime Function: unsigned short fract __satfractdauqq (long accum 2162 A) 2163 -- Runtime Function: unsigned fract __satfractdauhq (long accum A) 2164 -- Runtime Function: unsigned long fract __satfractdausq (long accum A) 2165 -- Runtime Function: unsigned long long fract __satfractdaudq (long 2166 accum A) 2167 -- Runtime Function: unsigned short accum __satfractdauha (long accum 2168 A) 2169 -- Runtime Function: unsigned accum __satfractdausa (long accum A) 2170 -- Runtime Function: unsigned long accum __satfractdauda (long accum A) 2171 -- Runtime Function: unsigned long long accum __satfractdauta (long 2172 accum A) 2173 -- Runtime Function: short fract __satfracttaqq (long long accum A) 2174 -- Runtime Function: fract __satfracttahq (long long accum A) 2175 -- Runtime Function: long fract __satfracttasq (long long accum A) 2176 -- Runtime Function: long long fract __satfracttadq (long long accum A) 2177 -- Runtime Function: short accum __satfracttaha2 (long long accum A) 2178 -- Runtime Function: accum __satfracttasa2 (long long accum A) 2179 -- Runtime Function: long accum __satfracttada2 (long long accum A) 2180 -- Runtime Function: unsigned short fract __satfracttauqq (long long 2181 accum A) 2182 -- Runtime Function: unsigned fract __satfracttauhq (long long accum A) 2183 -- Runtime Function: unsigned long fract __satfracttausq (long long 2184 accum A) 2185 -- Runtime Function: unsigned long long fract __satfracttaudq (long 2186 long accum A) 2187 -- Runtime Function: unsigned short accum __satfracttauha (long long 2188 accum A) 2189 -- Runtime Function: unsigned accum __satfracttausa (long long accum A) 2190 -- Runtime Function: unsigned long accum __satfracttauda (long long 2191 accum A) 2192 -- Runtime Function: unsigned long long accum __satfracttauta (long 2193 long accum A) 2194 -- Runtime Function: short fract __satfractuqqqq (unsigned short fract 2195 A) 2196 -- Runtime Function: fract __satfractuqqhq (unsigned short fract A) 2197 -- Runtime Function: long fract __satfractuqqsq (unsigned short fract 2198 A) 2199 -- Runtime Function: long long fract __satfractuqqdq (unsigned short 2200 fract A) 2201 -- Runtime Function: short accum __satfractuqqha (unsigned short fract 2202 A) 2203 -- Runtime Function: accum __satfractuqqsa (unsigned short fract A) 2204 -- Runtime Function: long accum __satfractuqqda (unsigned short fract 2205 A) 2206 -- Runtime Function: long long accum __satfractuqqta (unsigned short 2207 fract A) 2208 -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short 2209 fract A) 2210 -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned 2211 short fract A) 2212 -- Runtime Function: unsigned long long fract __satfractuqqudq2 2213 (unsigned short fract A) 2214 -- Runtime Function: unsigned short accum __satfractuqquha (unsigned 2215 short fract A) 2216 -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short 2217 fract A) 2218 -- Runtime Function: unsigned long accum __satfractuqquda (unsigned 2219 short fract A) 2220 -- Runtime Function: unsigned long long accum __satfractuqquta 2221 (unsigned short fract A) 2222 -- Runtime Function: short fract __satfractuhqqq (unsigned fract A) 2223 -- Runtime Function: fract __satfractuhqhq (unsigned fract A) 2224 -- Runtime Function: long fract __satfractuhqsq (unsigned fract A) 2225 -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A) 2226 -- Runtime Function: short accum __satfractuhqha (unsigned fract A) 2227 -- Runtime Function: accum __satfractuhqsa (unsigned fract A) 2228 -- Runtime Function: long accum __satfractuhqda (unsigned fract A) 2229 -- Runtime Function: long long accum __satfractuhqta (unsigned fract A) 2230 -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned 2231 fract A) 2232 -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned 2233 fract A) 2234 -- Runtime Function: unsigned long long fract __satfractuhqudq2 2235 (unsigned fract A) 2236 -- Runtime Function: unsigned short accum __satfractuhquha (unsigned 2237 fract A) 2238 -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A) 2239 -- Runtime Function: unsigned long accum __satfractuhquda (unsigned 2240 fract A) 2241 -- Runtime Function: unsigned long long accum __satfractuhquta 2242 (unsigned fract A) 2243 -- Runtime Function: short fract __satfractusqqq (unsigned long fract 2244 A) 2245 -- Runtime Function: fract __satfractusqhq (unsigned long fract A) 2246 -- Runtime Function: long fract __satfractusqsq (unsigned long fract A) 2247 -- Runtime Function: long long fract __satfractusqdq (unsigned long 2248 fract A) 2249 -- Runtime Function: short accum __satfractusqha (unsigned long fract 2250 A) 2251 -- Runtime Function: accum __satfractusqsa (unsigned long fract A) 2252 -- Runtime Function: long accum __satfractusqda (unsigned long fract A) 2253 -- Runtime Function: long long accum __satfractusqta (unsigned long 2254 fract A) 2255 -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned 2256 long fract A) 2257 -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long 2258 fract A) 2259 -- Runtime Function: unsigned long long fract __satfractusqudq2 2260 (unsigned long fract A) 2261 -- Runtime Function: unsigned short accum __satfractusquha (unsigned 2262 long fract A) 2263 -- Runtime Function: unsigned accum __satfractusqusa (unsigned long 2264 fract A) 2265 -- Runtime Function: unsigned long accum __satfractusquda (unsigned 2266 long fract A) 2267 -- Runtime Function: unsigned long long accum __satfractusquta 2268 (unsigned long fract A) 2269 -- Runtime Function: short fract __satfractudqqq (unsigned long long 2270 fract A) 2271 -- Runtime Function: fract __satfractudqhq (unsigned long long fract A) 2272 -- Runtime Function: long fract __satfractudqsq (unsigned long long 2273 fract A) 2274 -- Runtime Function: long long fract __satfractudqdq (unsigned long 2275 long fract A) 2276 -- Runtime Function: short accum __satfractudqha (unsigned long long 2277 fract A) 2278 -- Runtime Function: accum __satfractudqsa (unsigned long long fract A) 2279 -- Runtime Function: long accum __satfractudqda (unsigned long long 2280 fract A) 2281 -- Runtime Function: long long accum __satfractudqta (unsigned long 2282 long fract A) 2283 -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned 2284 long long fract A) 2285 -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long 2286 long fract A) 2287 -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned 2288 long long fract A) 2289 -- Runtime Function: unsigned short accum __satfractudquha (unsigned 2290 long long fract A) 2291 -- Runtime Function: unsigned accum __satfractudqusa (unsigned long 2292 long fract A) 2293 -- Runtime Function: unsigned long accum __satfractudquda (unsigned 2294 long long fract A) 2295 -- Runtime Function: unsigned long long accum __satfractudquta 2296 (unsigned long long fract A) 2297 -- Runtime Function: short fract __satfractuhaqq (unsigned short accum 2298 A) 2299 -- Runtime Function: fract __satfractuhahq (unsigned short accum A) 2300 -- Runtime Function: long fract __satfractuhasq (unsigned short accum 2301 A) 2302 -- Runtime Function: long long fract __satfractuhadq (unsigned short 2303 accum A) 2304 -- Runtime Function: short accum __satfractuhaha (unsigned short accum 2305 A) 2306 -- Runtime Function: accum __satfractuhasa (unsigned short accum A) 2307 -- Runtime Function: long accum __satfractuhada (unsigned short accum 2308 A) 2309 -- Runtime Function: long long accum __satfractuhata (unsigned short 2310 accum A) 2311 -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned 2312 short accum A) 2313 -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short 2314 accum A) 2315 -- Runtime Function: unsigned long fract __satfractuhausq (unsigned 2316 short accum A) 2317 -- Runtime Function: unsigned long long fract __satfractuhaudq 2318 (unsigned short accum A) 2319 -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short 2320 accum A) 2321 -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned 2322 short accum A) 2323 -- Runtime Function: unsigned long long accum __satfractuhauta2 2324 (unsigned short accum A) 2325 -- Runtime Function: short fract __satfractusaqq (unsigned accum A) 2326 -- Runtime Function: fract __satfractusahq (unsigned accum A) 2327 -- Runtime Function: long fract __satfractusasq (unsigned accum A) 2328 -- Runtime Function: long long fract __satfractusadq (unsigned accum A) 2329 -- Runtime Function: short accum __satfractusaha (unsigned accum A) 2330 -- Runtime Function: accum __satfractusasa (unsigned accum A) 2331 -- Runtime Function: long accum __satfractusada (unsigned accum A) 2332 -- Runtime Function: long long accum __satfractusata (unsigned accum A) 2333 -- Runtime Function: unsigned short fract __satfractusauqq (unsigned 2334 accum A) 2335 -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A) 2336 -- Runtime Function: unsigned long fract __satfractusausq (unsigned 2337 accum A) 2338 -- Runtime Function: unsigned long long fract __satfractusaudq 2339 (unsigned accum A) 2340 -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned 2341 accum A) 2342 -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned 2343 accum A) 2344 -- Runtime Function: unsigned long long accum __satfractusauta2 2345 (unsigned accum A) 2346 -- Runtime Function: short fract __satfractudaqq (unsigned long accum 2347 A) 2348 -- Runtime Function: fract __satfractudahq (unsigned long accum A) 2349 -- Runtime Function: long fract __satfractudasq (unsigned long accum A) 2350 -- Runtime Function: long long fract __satfractudadq (unsigned long 2351 accum A) 2352 -- Runtime Function: short accum __satfractudaha (unsigned long accum 2353 A) 2354 -- Runtime Function: accum __satfractudasa (unsigned long accum A) 2355 -- Runtime Function: long accum __satfractudada (unsigned long accum A) 2356 -- Runtime Function: long long accum __satfractudata (unsigned long 2357 accum A) 2358 -- Runtime Function: unsigned short fract __satfractudauqq (unsigned 2359 long accum A) 2360 -- Runtime Function: unsigned fract __satfractudauhq (unsigned long 2361 accum A) 2362 -- Runtime Function: unsigned long fract __satfractudausq (unsigned 2363 long accum A) 2364 -- Runtime Function: unsigned long long fract __satfractudaudq 2365 (unsigned long accum A) 2366 -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned 2367 long accum A) 2368 -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long 2369 accum A) 2370 -- Runtime Function: unsigned long long accum __satfractudauta2 2371 (unsigned long accum A) 2372 -- Runtime Function: short fract __satfractutaqq (unsigned long long 2373 accum A) 2374 -- Runtime Function: fract __satfractutahq (unsigned long long accum A) 2375 -- Runtime Function: long fract __satfractutasq (unsigned long long 2376 accum A) 2377 -- Runtime Function: long long fract __satfractutadq (unsigned long 2378 long accum A) 2379 -- Runtime Function: short accum __satfractutaha (unsigned long long 2380 accum A) 2381 -- Runtime Function: accum __satfractutasa (unsigned long long accum A) 2382 -- Runtime Function: long accum __satfractutada (unsigned long long 2383 accum A) 2384 -- Runtime Function: long long accum __satfractutata (unsigned long 2385 long accum A) 2386 -- Runtime Function: unsigned short fract __satfractutauqq (unsigned 2387 long long accum A) 2388 -- Runtime Function: unsigned fract __satfractutauhq (unsigned long 2389 long accum A) 2390 -- Runtime Function: unsigned long fract __satfractutausq (unsigned 2391 long long accum A) 2392 -- Runtime Function: unsigned long long fract __satfractutaudq 2393 (unsigned long long accum A) 2394 -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned 2395 long long accum A) 2396 -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long 2397 long accum A) 2398 -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned 2399 long long accum A) 2400 -- Runtime Function: short fract __satfractqiqq (signed char A) 2401 -- Runtime Function: fract __satfractqihq (signed char A) 2402 -- Runtime Function: long fract __satfractqisq (signed char A) 2403 -- Runtime Function: long long fract __satfractqidq (signed char A) 2404 -- Runtime Function: short accum __satfractqiha (signed char A) 2405 -- Runtime Function: accum __satfractqisa (signed char A) 2406 -- Runtime Function: long accum __satfractqida (signed char A) 2407 -- Runtime Function: long long accum __satfractqita (signed char A) 2408 -- Runtime Function: unsigned short fract __satfractqiuqq (signed char 2409 A) 2410 -- Runtime Function: unsigned fract __satfractqiuhq (signed char A) 2411 -- Runtime Function: unsigned long fract __satfractqiusq (signed char 2412 A) 2413 -- Runtime Function: unsigned long long fract __satfractqiudq (signed 2414 char A) 2415 -- Runtime Function: unsigned short accum __satfractqiuha (signed char 2416 A) 2417 -- Runtime Function: unsigned accum __satfractqiusa (signed char A) 2418 -- Runtime Function: unsigned long accum __satfractqiuda (signed char 2419 A) 2420 -- Runtime Function: unsigned long long accum __satfractqiuta (signed 2421 char A) 2422 -- Runtime Function: short fract __satfracthiqq (short A) 2423 -- Runtime Function: fract __satfracthihq (short A) 2424 -- Runtime Function: long fract __satfracthisq (short A) 2425 -- Runtime Function: long long fract __satfracthidq (short A) 2426 -- Runtime Function: short accum __satfracthiha (short A) 2427 -- Runtime Function: accum __satfracthisa (short A) 2428 -- Runtime Function: long accum __satfracthida (short A) 2429 -- Runtime Function: long long accum __satfracthita (short A) 2430 -- Runtime Function: unsigned short fract __satfracthiuqq (short A) 2431 -- Runtime Function: unsigned fract __satfracthiuhq (short A) 2432 -- Runtime Function: unsigned long fract __satfracthiusq (short A) 2433 -- Runtime Function: unsigned long long fract __satfracthiudq (short A) 2434 -- Runtime Function: unsigned short accum __satfracthiuha (short A) 2435 -- Runtime Function: unsigned accum __satfracthiusa (short A) 2436 -- Runtime Function: unsigned long accum __satfracthiuda (short A) 2437 -- Runtime Function: unsigned long long accum __satfracthiuta (short A) 2438 -- Runtime Function: short fract __satfractsiqq (int A) 2439 -- Runtime Function: fract __satfractsihq (int A) 2440 -- Runtime Function: long fract __satfractsisq (int A) 2441 -- Runtime Function: long long fract __satfractsidq (int A) 2442 -- Runtime Function: short accum __satfractsiha (int A) 2443 -- Runtime Function: accum __satfractsisa (int A) 2444 -- Runtime Function: long accum __satfractsida (int A) 2445 -- Runtime Function: long long accum __satfractsita (int A) 2446 -- Runtime Function: unsigned short fract __satfractsiuqq (int A) 2447 -- Runtime Function: unsigned fract __satfractsiuhq (int A) 2448 -- Runtime Function: unsigned long fract __satfractsiusq (int A) 2449 -- Runtime Function: unsigned long long fract __satfractsiudq (int A) 2450 -- Runtime Function: unsigned short accum __satfractsiuha (int A) 2451 -- Runtime Function: unsigned accum __satfractsiusa (int A) 2452 -- Runtime Function: unsigned long accum __satfractsiuda (int A) 2453 -- Runtime Function: unsigned long long accum __satfractsiuta (int A) 2454 -- Runtime Function: short fract __satfractdiqq (long A) 2455 -- Runtime Function: fract __satfractdihq (long A) 2456 -- Runtime Function: long fract __satfractdisq (long A) 2457 -- Runtime Function: long long fract __satfractdidq (long A) 2458 -- Runtime Function: short accum __satfractdiha (long A) 2459 -- Runtime Function: accum __satfractdisa (long A) 2460 -- Runtime Function: long accum __satfractdida (long A) 2461 -- Runtime Function: long long accum __satfractdita (long A) 2462 -- Runtime Function: unsigned short fract __satfractdiuqq (long A) 2463 -- Runtime Function: unsigned fract __satfractdiuhq (long A) 2464 -- Runtime Function: unsigned long fract __satfractdiusq (long A) 2465 -- Runtime Function: unsigned long long fract __satfractdiudq (long A) 2466 -- Runtime Function: unsigned short accum __satfractdiuha (long A) 2467 -- Runtime Function: unsigned accum __satfractdiusa (long A) 2468 -- Runtime Function: unsigned long accum __satfractdiuda (long A) 2469 -- Runtime Function: unsigned long long accum __satfractdiuta (long A) 2470 -- Runtime Function: short fract __satfracttiqq (long long A) 2471 -- Runtime Function: fract __satfracttihq (long long A) 2472 -- Runtime Function: long fract __satfracttisq (long long A) 2473 -- Runtime Function: long long fract __satfracttidq (long long A) 2474 -- Runtime Function: short accum __satfracttiha (long long A) 2475 -- Runtime Function: accum __satfracttisa (long long A) 2476 -- Runtime Function: long accum __satfracttida (long long A) 2477 -- Runtime Function: long long accum __satfracttita (long long A) 2478 -- Runtime Function: unsigned short fract __satfracttiuqq (long long A) 2479 -- Runtime Function: unsigned fract __satfracttiuhq (long long A) 2480 -- Runtime Function: unsigned long fract __satfracttiusq (long long A) 2481 -- Runtime Function: unsigned long long fract __satfracttiudq (long 2482 long A) 2483 -- Runtime Function: unsigned short accum __satfracttiuha (long long A) 2484 -- Runtime Function: unsigned accum __satfracttiusa (long long A) 2485 -- Runtime Function: unsigned long accum __satfracttiuda (long long A) 2486 -- Runtime Function: unsigned long long accum __satfracttiuta (long 2487 long A) 2488 -- Runtime Function: short fract __satfractsfqq (float A) 2489 -- Runtime Function: fract __satfractsfhq (float A) 2490 -- Runtime Function: long fract __satfractsfsq (float A) 2491 -- Runtime Function: long long fract __satfractsfdq (float A) 2492 -- Runtime Function: short accum __satfractsfha (float A) 2493 -- Runtime Function: accum __satfractsfsa (float A) 2494 -- Runtime Function: long accum __satfractsfda (float A) 2495 -- Runtime Function: long long accum __satfractsfta (float A) 2496 -- Runtime Function: unsigned short fract __satfractsfuqq (float A) 2497 -- Runtime Function: unsigned fract __satfractsfuhq (float A) 2498 -- Runtime Function: unsigned long fract __satfractsfusq (float A) 2499 -- Runtime Function: unsigned long long fract __satfractsfudq (float A) 2500 -- Runtime Function: unsigned short accum __satfractsfuha (float A) 2501 -- Runtime Function: unsigned accum __satfractsfusa (float A) 2502 -- Runtime Function: unsigned long accum __satfractsfuda (float A) 2503 -- Runtime Function: unsigned long long accum __satfractsfuta (float A) 2504 -- Runtime Function: short fract __satfractdfqq (double A) 2505 -- Runtime Function: fract __satfractdfhq (double A) 2506 -- Runtime Function: long fract __satfractdfsq (double A) 2507 -- Runtime Function: long long fract __satfractdfdq (double A) 2508 -- Runtime Function: short accum __satfractdfha (double A) 2509 -- Runtime Function: accum __satfractdfsa (double A) 2510 -- Runtime Function: long accum __satfractdfda (double A) 2511 -- Runtime Function: long long accum __satfractdfta (double A) 2512 -- Runtime Function: unsigned short fract __satfractdfuqq (double A) 2513 -- Runtime Function: unsigned fract __satfractdfuhq (double A) 2514 -- Runtime Function: unsigned long fract __satfractdfusq (double A) 2515 -- Runtime Function: unsigned long long fract __satfractdfudq (double 2516 A) 2517 -- Runtime Function: unsigned short accum __satfractdfuha (double A) 2518 -- Runtime Function: unsigned accum __satfractdfusa (double A) 2519 -- Runtime Function: unsigned long accum __satfractdfuda (double A) 2520 -- Runtime Function: unsigned long long accum __satfractdfuta (double 2521 A) 2522 The functions convert from fractional and signed non-fractionals to 2523 fractionals, with saturation. 2524 2525 -- Runtime Function: unsigned char __fractunsqqqi (short fract A) 2526 -- Runtime Function: unsigned short __fractunsqqhi (short fract A) 2527 -- Runtime Function: unsigned int __fractunsqqsi (short fract A) 2528 -- Runtime Function: unsigned long __fractunsqqdi (short fract A) 2529 -- Runtime Function: unsigned long long __fractunsqqti (short fract A) 2530 -- Runtime Function: unsigned char __fractunshqqi (fract A) 2531 -- Runtime Function: unsigned short __fractunshqhi (fract A) 2532 -- Runtime Function: unsigned int __fractunshqsi (fract A) 2533 -- Runtime Function: unsigned long __fractunshqdi (fract A) 2534 -- Runtime Function: unsigned long long __fractunshqti (fract A) 2535 -- Runtime Function: unsigned char __fractunssqqi (long fract A) 2536 -- Runtime Function: unsigned short __fractunssqhi (long fract A) 2537 -- Runtime Function: unsigned int __fractunssqsi (long fract A) 2538 -- Runtime Function: unsigned long __fractunssqdi (long fract A) 2539 -- Runtime Function: unsigned long long __fractunssqti (long fract A) 2540 -- Runtime Function: unsigned char __fractunsdqqi (long long fract A) 2541 -- Runtime Function: unsigned short __fractunsdqhi (long long fract A) 2542 -- Runtime Function: unsigned int __fractunsdqsi (long long fract A) 2543 -- Runtime Function: unsigned long __fractunsdqdi (long long fract A) 2544 -- Runtime Function: unsigned long long __fractunsdqti (long long 2545 fract A) 2546 -- Runtime Function: unsigned char __fractunshaqi (short accum A) 2547 -- Runtime Function: unsigned short __fractunshahi (short accum A) 2548 -- Runtime Function: unsigned int __fractunshasi (short accum A) 2549 -- Runtime Function: unsigned long __fractunshadi (short accum A) 2550 -- Runtime Function: unsigned long long __fractunshati (short accum A) 2551 -- Runtime Function: unsigned char __fractunssaqi (accum A) 2552 -- Runtime Function: unsigned short __fractunssahi (accum A) 2553 -- Runtime Function: unsigned int __fractunssasi (accum A) 2554 -- Runtime Function: unsigned long __fractunssadi (accum A) 2555 -- Runtime Function: unsigned long long __fractunssati (accum A) 2556 -- Runtime Function: unsigned char __fractunsdaqi (long accum A) 2557 -- Runtime Function: unsigned short __fractunsdahi (long accum A) 2558 -- Runtime Function: unsigned int __fractunsdasi (long accum A) 2559 -- Runtime Function: unsigned long __fractunsdadi (long accum A) 2560 -- Runtime Function: unsigned long long __fractunsdati (long accum A) 2561 -- Runtime Function: unsigned char __fractunstaqi (long long accum A) 2562 -- Runtime Function: unsigned short __fractunstahi (long long accum A) 2563 -- Runtime Function: unsigned int __fractunstasi (long long accum A) 2564 -- Runtime Function: unsigned long __fractunstadi (long long accum A) 2565 -- Runtime Function: unsigned long long __fractunstati (long long 2566 accum A) 2567 -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short 2568 fract A) 2569 -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short 2570 fract A) 2571 -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short 2572 fract A) 2573 -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short 2574 fract A) 2575 -- Runtime Function: unsigned long long __fractunsuqqti (unsigned 2576 short fract A) 2577 -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A) 2578 -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A) 2579 -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A) 2580 -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A) 2581 -- Runtime Function: unsigned long long __fractunsuhqti (unsigned 2582 fract A) 2583 -- Runtime Function: unsigned char __fractunsusqqi (unsigned long 2584 fract A) 2585 -- Runtime Function: unsigned short __fractunsusqhi (unsigned long 2586 fract A) 2587 -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract 2588 A) 2589 -- Runtime Function: unsigned long __fractunsusqdi (unsigned long 2590 fract A) 2591 -- Runtime Function: unsigned long long __fractunsusqti (unsigned long 2592 fract A) 2593 -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long 2594 fract A) 2595 -- Runtime Function: unsigned short __fractunsudqhi (unsigned long 2596 long fract A) 2597 -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long 2598 fract A) 2599 -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long 2600 fract A) 2601 -- Runtime Function: unsigned long long __fractunsudqti (unsigned long 2602 long fract A) 2603 -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short 2604 accum A) 2605 -- Runtime Function: unsigned short __fractunsuhahi (unsigned short 2606 accum A) 2607 -- Runtime Function: unsigned int __fractunsuhasi (unsigned short 2608 accum A) 2609 -- Runtime Function: unsigned long __fractunsuhadi (unsigned short 2610 accum A) 2611 -- Runtime Function: unsigned long long __fractunsuhati (unsigned 2612 short accum A) 2613 -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A) 2614 -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A) 2615 -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A) 2616 -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A) 2617 -- Runtime Function: unsigned long long __fractunsusati (unsigned 2618 accum A) 2619 -- Runtime Function: unsigned char __fractunsudaqi (unsigned long 2620 accum A) 2621 -- Runtime Function: unsigned short __fractunsudahi (unsigned long 2622 accum A) 2623 -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum 2624 A) 2625 -- Runtime Function: unsigned long __fractunsudadi (unsigned long 2626 accum A) 2627 -- Runtime Function: unsigned long long __fractunsudati (unsigned long 2628 accum A) 2629 -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long 2630 accum A) 2631 -- Runtime Function: unsigned short __fractunsutahi (unsigned long 2632 long accum A) 2633 -- Runtime Function: unsigned int __fractunsutasi (unsigned long long 2634 accum A) 2635 -- Runtime Function: unsigned long __fractunsutadi (unsigned long long 2636 accum A) 2637 -- Runtime Function: unsigned long long __fractunsutati (unsigned long 2638 long accum A) 2639 -- Runtime Function: short fract __fractunsqiqq (unsigned char A) 2640 -- Runtime Function: fract __fractunsqihq (unsigned char A) 2641 -- Runtime Function: long fract __fractunsqisq (unsigned char A) 2642 -- Runtime Function: long long fract __fractunsqidq (unsigned char A) 2643 -- Runtime Function: short accum __fractunsqiha (unsigned char A) 2644 -- Runtime Function: accum __fractunsqisa (unsigned char A) 2645 -- Runtime Function: long accum __fractunsqida (unsigned char A) 2646 -- Runtime Function: long long accum __fractunsqita (unsigned char A) 2647 -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned 2648 char A) 2649 -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A) 2650 -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned 2651 char A) 2652 -- Runtime Function: unsigned long long fract __fractunsqiudq 2653 (unsigned char A) 2654 -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned 2655 char A) 2656 -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A) 2657 -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned 2658 char A) 2659 -- Runtime Function: unsigned long long accum __fractunsqiuta 2660 (unsigned char A) 2661 -- Runtime Function: short fract __fractunshiqq (unsigned short A) 2662 -- Runtime Function: fract __fractunshihq (unsigned short A) 2663 -- Runtime Function: long fract __fractunshisq (unsigned short A) 2664 -- Runtime Function: long long fract __fractunshidq (unsigned short A) 2665 -- Runtime Function: short accum __fractunshiha (unsigned short A) 2666 -- Runtime Function: accum __fractunshisa (unsigned short A) 2667 -- Runtime Function: long accum __fractunshida (unsigned short A) 2668 -- Runtime Function: long long accum __fractunshita (unsigned short A) 2669 -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned 2670 short A) 2671 -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A) 2672 -- Runtime Function: unsigned long fract __fractunshiusq (unsigned 2673 short A) 2674 -- Runtime Function: unsigned long long fract __fractunshiudq 2675 (unsigned short A) 2676 -- Runtime Function: unsigned short accum __fractunshiuha (unsigned 2677 short A) 2678 -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A) 2679 -- Runtime Function: unsigned long accum __fractunshiuda (unsigned 2680 short A) 2681 -- Runtime Function: unsigned long long accum __fractunshiuta 2682 (unsigned short A) 2683 -- Runtime Function: short fract __fractunssiqq (unsigned int A) 2684 -- Runtime Function: fract __fractunssihq (unsigned int A) 2685 -- Runtime Function: long fract __fractunssisq (unsigned int A) 2686 -- Runtime Function: long long fract __fractunssidq (unsigned int A) 2687 -- Runtime Function: short accum __fractunssiha (unsigned int A) 2688 -- Runtime Function: accum __fractunssisa (unsigned int A) 2689 -- Runtime Function: long accum __fractunssida (unsigned int A) 2690 -- Runtime Function: long long accum __fractunssita (unsigned int A) 2691 -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned 2692 int A) 2693 -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A) 2694 -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int 2695 A) 2696 -- Runtime Function: unsigned long long fract __fractunssiudq 2697 (unsigned int A) 2698 -- Runtime Function: unsigned short accum __fractunssiuha (unsigned 2699 int A) 2700 -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A) 2701 -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int 2702 A) 2703 -- Runtime Function: unsigned long long accum __fractunssiuta 2704 (unsigned int A) 2705 -- Runtime Function: short fract __fractunsdiqq (unsigned long A) 2706 -- Runtime Function: fract __fractunsdihq (unsigned long A) 2707 -- Runtime Function: long fract __fractunsdisq (unsigned long A) 2708 -- Runtime Function: long long fract __fractunsdidq (unsigned long A) 2709 -- Runtime Function: short accum __fractunsdiha (unsigned long A) 2710 -- Runtime Function: accum __fractunsdisa (unsigned long A) 2711 -- Runtime Function: long accum __fractunsdida (unsigned long A) 2712 -- Runtime Function: long long accum __fractunsdita (unsigned long A) 2713 -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned 2714 long A) 2715 -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A) 2716 -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned 2717 long A) 2718 -- Runtime Function: unsigned long long fract __fractunsdiudq 2719 (unsigned long A) 2720 -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned 2721 long A) 2722 -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A) 2723 -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned 2724 long A) 2725 -- Runtime Function: unsigned long long accum __fractunsdiuta 2726 (unsigned long A) 2727 -- Runtime Function: short fract __fractunstiqq (unsigned long long A) 2728 -- Runtime Function: fract __fractunstihq (unsigned long long A) 2729 -- Runtime Function: long fract __fractunstisq (unsigned long long A) 2730 -- Runtime Function: long long fract __fractunstidq (unsigned long 2731 long A) 2732 -- Runtime Function: short accum __fractunstiha (unsigned long long A) 2733 -- Runtime Function: accum __fractunstisa (unsigned long long A) 2734 -- Runtime Function: long accum __fractunstida (unsigned long long A) 2735 -- Runtime Function: long long accum __fractunstita (unsigned long 2736 long A) 2737 -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned 2738 long long A) 2739 -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long 2740 long A) 2741 -- Runtime Function: unsigned long fract __fractunstiusq (unsigned 2742 long long A) 2743 -- Runtime Function: unsigned long long fract __fractunstiudq 2744 (unsigned long long A) 2745 -- Runtime Function: unsigned short accum __fractunstiuha (unsigned 2746 long long A) 2747 -- Runtime Function: unsigned accum __fractunstiusa (unsigned long 2748 long A) 2749 -- Runtime Function: unsigned long accum __fractunstiuda (unsigned 2750 long long A) 2751 -- Runtime Function: unsigned long long accum __fractunstiuta 2752 (unsigned long long A) 2753 These functions convert from fractionals to unsigned 2754 non-fractionals; and from unsigned non-fractionals to fractionals, 2755 without saturation. 2756 2757 -- Runtime Function: short fract __satfractunsqiqq (unsigned char A) 2758 -- Runtime Function: fract __satfractunsqihq (unsigned char A) 2759 -- Runtime Function: long fract __satfractunsqisq (unsigned char A) 2760 -- Runtime Function: long long fract __satfractunsqidq (unsigned char 2761 A) 2762 -- Runtime Function: short accum __satfractunsqiha (unsigned char A) 2763 -- Runtime Function: accum __satfractunsqisa (unsigned char A) 2764 -- Runtime Function: long accum __satfractunsqida (unsigned char A) 2765 -- Runtime Function: long long accum __satfractunsqita (unsigned char 2766 A) 2767 -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned 2768 char A) 2769 -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char 2770 A) 2771 -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned 2772 char A) 2773 -- Runtime Function: unsigned long long fract __satfractunsqiudq 2774 (unsigned char A) 2775 -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned 2776 char A) 2777 -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char 2778 A) 2779 -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned 2780 char A) 2781 -- Runtime Function: unsigned long long accum __satfractunsqiuta 2782 (unsigned char A) 2783 -- Runtime Function: short fract __satfractunshiqq (unsigned short A) 2784 -- Runtime Function: fract __satfractunshihq (unsigned short A) 2785 -- Runtime Function: long fract __satfractunshisq (unsigned short A) 2786 -- Runtime Function: long long fract __satfractunshidq (unsigned short 2787 A) 2788 -- Runtime Function: short accum __satfractunshiha (unsigned short A) 2789 -- Runtime Function: accum __satfractunshisa (unsigned short A) 2790 -- Runtime Function: long accum __satfractunshida (unsigned short A) 2791 -- Runtime Function: long long accum __satfractunshita (unsigned short 2792 A) 2793 -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned 2794 short A) 2795 -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short 2796 A) 2797 -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned 2798 short A) 2799 -- Runtime Function: unsigned long long fract __satfractunshiudq 2800 (unsigned short A) 2801 -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned 2802 short A) 2803 -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short 2804 A) 2805 -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned 2806 short A) 2807 -- Runtime Function: unsigned long long accum __satfractunshiuta 2808 (unsigned short A) 2809 -- Runtime Function: short fract __satfractunssiqq (unsigned int A) 2810 -- Runtime Function: fract __satfractunssihq (unsigned int A) 2811 -- Runtime Function: long fract __satfractunssisq (unsigned int A) 2812 -- Runtime Function: long long fract __satfractunssidq (unsigned int A) 2813 -- Runtime Function: short accum __satfractunssiha (unsigned int A) 2814 -- Runtime Function: accum __satfractunssisa (unsigned int A) 2815 -- Runtime Function: long accum __satfractunssida (unsigned int A) 2816 -- Runtime Function: long long accum __satfractunssita (unsigned int A) 2817 -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned 2818 int A) 2819 -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A) 2820 -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned 2821 int A) 2822 -- Runtime Function: unsigned long long fract __satfractunssiudq 2823 (unsigned int A) 2824 -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned 2825 int A) 2826 -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A) 2827 -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned 2828 int A) 2829 -- Runtime Function: unsigned long long accum __satfractunssiuta 2830 (unsigned int A) 2831 -- Runtime Function: short fract __satfractunsdiqq (unsigned long A) 2832 -- Runtime Function: fract __satfractunsdihq (unsigned long A) 2833 -- Runtime Function: long fract __satfractunsdisq (unsigned long A) 2834 -- Runtime Function: long long fract __satfractunsdidq (unsigned long 2835 A) 2836 -- Runtime Function: short accum __satfractunsdiha (unsigned long A) 2837 -- Runtime Function: accum __satfractunsdisa (unsigned long A) 2838 -- Runtime Function: long accum __satfractunsdida (unsigned long A) 2839 -- Runtime Function: long long accum __satfractunsdita (unsigned long 2840 A) 2841 -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned 2842 long A) 2843 -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long 2844 A) 2845 -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned 2846 long A) 2847 -- Runtime Function: unsigned long long fract __satfractunsdiudq 2848 (unsigned long A) 2849 -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned 2850 long A) 2851 -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long 2852 A) 2853 -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned 2854 long A) 2855 -- Runtime Function: unsigned long long accum __satfractunsdiuta 2856 (unsigned long A) 2857 -- Runtime Function: short fract __satfractunstiqq (unsigned long long 2858 A) 2859 -- Runtime Function: fract __satfractunstihq (unsigned long long A) 2860 -- Runtime Function: long fract __satfractunstisq (unsigned long long 2861 A) 2862 -- Runtime Function: long long fract __satfractunstidq (unsigned long 2863 long A) 2864 -- Runtime Function: short accum __satfractunstiha (unsigned long long 2865 A) 2866 -- Runtime Function: accum __satfractunstisa (unsigned long long A) 2867 -- Runtime Function: long accum __satfractunstida (unsigned long long 2868 A) 2869 -- Runtime Function: long long accum __satfractunstita (unsigned long 2870 long A) 2871 -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned 2872 long long A) 2873 -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long 2874 long A) 2875 -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned 2876 long long A) 2877 -- Runtime Function: unsigned long long fract __satfractunstiudq 2878 (unsigned long long A) 2879 -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned 2880 long long A) 2881 -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long 2882 long A) 2883 -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned 2884 long long A) 2885 -- Runtime Function: unsigned long long accum __satfractunstiuta 2886 (unsigned long long A) 2887 These functions convert from unsigned non-fractionals to 2888 fractionals, with saturation. 2889 2890 2891 File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Fixed-point fractional library routines, Up: Libgcc 2892 2893 4.5 Language-independent routines for exception handling 2894 ======================================================== 2895 2896 document me! 2897 2898 _Unwind_DeleteException 2899 _Unwind_Find_FDE 2900 _Unwind_ForcedUnwind 2901 _Unwind_GetGR 2902 _Unwind_GetIP 2903 _Unwind_GetLanguageSpecificData 2904 _Unwind_GetRegionStart 2905 _Unwind_GetTextRelBase 2906 _Unwind_GetDataRelBase 2907 _Unwind_RaiseException 2908 _Unwind_Resume 2909 _Unwind_SetGR 2910 _Unwind_SetIP 2911 _Unwind_FindEnclosingFunction 2912 _Unwind_SjLj_Register 2913 _Unwind_SjLj_Unregister 2914 _Unwind_SjLj_RaiseException 2915 _Unwind_SjLj_ForcedUnwind 2916 _Unwind_SjLj_Resume 2917 __deregister_frame 2918 __deregister_frame_info 2919 __deregister_frame_info_bases 2920 __register_frame 2921 __register_frame_info 2922 __register_frame_info_bases 2923 __register_frame_info_table 2924 __register_frame_info_table_bases 2925 __register_frame_table 2926 2927 2928 File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc 2929 2930 4.6 Miscellaneous runtime library routines 2931 ========================================== 2932 2933 4.6.1 Cache control functions 2934 ----------------------------- 2935 2936 -- Runtime Function: void __clear_cache (char *BEG, char *END) 2937 This function clears the instruction cache between BEG and END. 2938 2939 4.6.2 Split stack functions and variables 2940 ----------------------------------------- 2941 2942 -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void 2943 *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void 2944 **INITIAL_SP) 2945 When using `-fsplit-stack', this call may be used to iterate over 2946 the stack segments. It may be called like this: 2947 void *next_segment = NULL; 2948 void *next_sp = NULL; 2949 void *initial_sp = NULL; 2950 void *stack; 2951 size_t stack_size; 2952 while ((stack = __splitstack_find (next_segment, next_sp, 2953 &stack_size, &next_segment, 2954 &next_sp, &initial_sp)) 2955 != NULL) 2956 { 2957 /* Stack segment starts at stack and is 2958 stack_size bytes long. */ 2959 } 2960 2961 There is no way to iterate over the stack segments of a different 2962 thread. However, what is permitted is for one thread to call this 2963 with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT, 2964 NEXT_SP, and INITIAL_SP to a different thread, and then to suspend 2965 one way or another. A different thread may run the subsequent 2966 `__splitstack_find' iterations. Of course, this will only work if 2967 the first thread is suspended while the second thread is calling 2968 `__splitstack_find'. If not, the second thread could be looking 2969 at the stack while it is changing, and anything could happen. 2970 2971 -- Variable: __morestack_segments 2972 -- Variable: __morestack_current_segment 2973 -- Variable: __morestack_initial_sp 2974 Internal variables used by the `-fsplit-stack' implementation. 2975 2976 2977 File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top 2978 2979 5 Language Front Ends in GCC 2980 **************************** 2981 2982 The interface to front ends for languages in GCC, and in particular the 2983 `tree' structure (*note GENERIC::), was initially designed for C, and 2984 many aspects of it are still somewhat biased towards C and C-like 2985 languages. It is, however, reasonably well suited to other procedural 2986 languages, and front ends for many such languages have been written for 2987 GCC. 2988 2989 Writing a compiler as a front end for GCC, rather than compiling 2990 directly to assembler or generating C code which is then compiled by 2991 GCC, has several advantages: 2992 2993 * GCC front ends benefit from the support for many different target 2994 machines already present in GCC. 2995 2996 * GCC front ends benefit from all the optimizations in GCC. Some of 2997 these, such as alias analysis, may work better when GCC is 2998 compiling directly from source code then when it is compiling from 2999 generated C code. 3000 3001 * Better debugging information is generated when compiling directly 3002 from source code than when going via intermediate generated C code. 3003 3004 Because of the advantages of writing a compiler as a GCC front end, 3005 GCC front ends have also been created for languages very different from 3006 those for which GCC was designed, such as the declarative 3007 logic/functional language Mercury. For these reasons, it may also be 3008 useful to implement compilers created for specialized purposes (for 3009 example, as part of a research project) as GCC front ends. 3010 3011 3012 File: gccint.info, Node: Source Tree, Next: Testsuites, Prev: Languages, Up: Top 3013 3014 6 Source Tree Structure and Build System 3015 **************************************** 3016 3017 This chapter describes the structure of the GCC source tree, and how 3018 GCC is built. The user documentation for building and installing GCC 3019 is in a separate manual (`http://gcc.gnu.org/install/'), with which it 3020 is presumed that you are familiar. 3021 3022 * Menu: 3023 3024 * Configure Terms:: Configuration terminology and history. 3025 * Top Level:: The top level source directory. 3026 * gcc Directory:: The `gcc' subdirectory. 3027 3028 3029 File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree 3030 3031 6.1 Configure Terms and History 3032 =============================== 3033 3034 The configure and build process has a long and colorful history, and can 3035 be confusing to anyone who doesn't know why things are the way they are. 3036 While there are other documents which describe the configuration process 3037 in detail, here are a few things that everyone working on GCC should 3038 know. 3039 3040 There are three system names that the build knows about: the machine 3041 you are building on ("build"), the machine that you are building for 3042 ("host"), and the machine that GCC will produce code for ("target"). 3043 When you configure GCC, you specify these with `--build=', `--host=', 3044 and `--target='. 3045 3046 Specifying the host without specifying the build should be avoided, as 3047 `configure' may (and once did) assume that the host you specify is also 3048 the build, which may not be true. 3049 3050 If build, host, and target are all the same, this is called a 3051 "native". If build and host are the same but target is different, this 3052 is called a "cross". If build, host, and target are all different this 3053 is called a "canadian" (for obscure reasons dealing with Canada's 3054 political party and the background of the person working on the build 3055 at that time). If host and target are the same, but build is 3056 different, you are using a cross-compiler to build a native for a 3057 different system. Some people call this a "host-x-host", "crossed 3058 native", or "cross-built native". If build and target are the same, 3059 but host is different, you are using a cross compiler to build a cross 3060 compiler that produces code for the machine you're building on. This 3061 is rare, so there is no common way of describing it. There is a 3062 proposal to call this a "crossback". 3063 3064 If build and host are the same, the GCC you are building will also be 3065 used to build the target libraries (like `libstdc++'). If build and 3066 host are different, you must have already built and installed a cross 3067 compiler that will be used to build the target libraries (if you 3068 configured with `--target=foo-bar', this compiler will be called 3069 `foo-bar-gcc'). 3070 3071 In the case of target libraries, the machine you're building for is the 3072 machine you specified with `--target'. So, build is the machine you're 3073 building on (no change there), host is the machine you're building for 3074 (the target libraries are built for the target, so host is the target 3075 you specified), and target doesn't apply (because you're not building a 3076 compiler, you're building libraries). The configure/make process will 3077 adjust these variables as needed. It also sets `$with_cross_host' to 3078 the original `--host' value in case you need it. 3079 3080 The `libiberty' support library is built up to three times: once for 3081 the host, once for the target (even if they are the same), and once for 3082 the build if build and host are different. This allows it to be used 3083 by all programs which are generated in the course of the build process. 3084 3085 3086 File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree 3087 3088 6.2 Top Level Source Directory 3089 ============================== 3090 3091 The top level source directory in a GCC distribution contains several 3092 files and directories that are shared with other software distributions 3093 such as that of GNU Binutils. It also contains several subdirectories 3094 that contain parts of GCC and its runtime libraries: 3095 3096 `boehm-gc' 3097 The Boehm conservative garbage collector, used as part of the Java 3098 runtime library. 3099 3100 `config' 3101 Autoconf macros and Makefile fragments used throughout the tree. 3102 3103 `contrib' 3104 Contributed scripts that may be found useful in conjunction with 3105 GCC. One of these, `contrib/texi2pod.pl', is used to generate man 3106 pages from Texinfo manuals as part of the GCC build process. 3107 3108 `fixincludes' 3109 The support for fixing system headers to work with GCC. See 3110 `fixincludes/README' for more information. The headers fixed by 3111 this mechanism are installed in `LIBSUBDIR/include-fixed'. Along 3112 with those headers, `README-fixinc' is also installed, as 3113 `LIBSUBDIR/include-fixed/README'. 3114 3115 `gcc' 3116 The main sources of GCC itself (except for runtime libraries), 3117 including optimizers, support for different target architectures, 3118 language front ends, and testsuites. *Note The `gcc' 3119 Subdirectory: gcc Directory, for details. 3120 3121 `gnattools' 3122 Support tools for GNAT. 3123 3124 `include' 3125 Headers for the `libiberty' library. 3126 3127 `intl' 3128 GNU `libintl', from GNU `gettext', for systems which do not 3129 include it in `libc'. 3130 3131 `libada' 3132 The Ada runtime library. 3133 3134 `libatomic' 3135 The runtime support library for atomic operations (e.g. for 3136 `__sync' and `__atomic'). 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 `libitm' 3167 The runtime support library for transactional memory. 3168 3169 `libjava' 3170 The Java runtime library. 3171 3172 `libmudflap' 3173 The `libmudflap' library, used for instrumenting pointer and array 3174 dereferencing operations. 3175 3176 `libobjc' 3177 The Objective-C and Objective-C++ runtime library. 3178 3179 `libquadmath' 3180 The runtime support library for quad-precision math operations. 3181 3182 `libssp' 3183 The Stack protector runtime library. 3184 3185 `libstdc++-v3' 3186 The C++ runtime library. 3187 3188 `lto-plugin' 3189 Plugin used by `gold' if link-time optimizations are enabled. 3190 3191 `maintainer-scripts' 3192 Scripts used by the `gccadmin' account on `gcc.gnu.org'. 3193 3194 `zlib' 3195 The `zlib' compression library, used by the Java front end, as 3196 part of the Java runtime library, and for compressing and 3197 uncompressing GCC's intermediate language in LTO object files. 3198 3199 The build system in the top level directory, including how recursion 3200 into subdirectories works and how building runtime libraries for 3201 multilibs is handled, is documented in a separate manual, included with 3202 GNU Binutils. *Note GNU configure and build system: (configure)Top, 3203 for details. 3204 3205 3206 File: gccint.info, Node: gcc Directory, Prev: Top Level, Up: Source Tree 3207 3208 6.3 The `gcc' Subdirectory 3209 ========================== 3210 3211 The `gcc' directory contains many files that are part of the C sources 3212 of GCC, other files used as part of the configuration and build 3213 process, and subdirectories including documentation and a testsuite. 3214 The files that are sources of GCC are documented in a separate chapter. 3215 *Note Passes and Files of the Compiler: Passes. 3216 3217 * Menu: 3218 3219 * Subdirectories:: Subdirectories of `gcc'. 3220 * Configuration:: The configuration process, and the files it uses. 3221 * Build:: The build system in the `gcc' directory. 3222 * Makefile:: Targets in `gcc/Makefile'. 3223 * Library Files:: Library source files and headers under `gcc/'. 3224 * Headers:: Headers installed by GCC. 3225 * Documentation:: Building documentation in GCC. 3226 * Front End:: Anatomy of a language front end. 3227 * Back End:: Anatomy of a target back end. 3228 3229 3230 File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory 3231 3232 6.3.1 Subdirectories of `gcc' 3233 ----------------------------- 3234 3235 The `gcc' directory contains the following subdirectories: 3236 3237 `LANGUAGE' 3238 Subdirectories for various languages. Directories containing a 3239 file `config-lang.in' are language subdirectories. The contents of 3240 the subdirectories `c' (for C), `cp' (for C++), `objc' (for 3241 Objective-C), `objcp' (for Objective-C++), and `lto' (for LTO) are 3242 documented in this manual (*note Passes and Files of the Compiler: 3243 Passes.); those for other languages are not. *Note Anatomy of a 3244 Language Front End: Front End, for details of the files in these 3245 directories. 3246 3247 `common' 3248 Source files shared between the compiler drivers (such as `gcc') 3249 and the compilers proper (such as `cc1'). If an architecture 3250 defines target hooks shared between those places, it also has a 3251 subdirectory in `common/config'. *Note Target Structure::. 3252 3253 `config' 3254 Configuration files for supported architectures and operating 3255 systems. *Note Anatomy of a Target Back End: Back End, for 3256 details of the files in this directory. 3257 3258 `doc' 3259 Texinfo documentation for GCC, together with automatically 3260 generated man pages and support for converting the installation 3261 manual to HTML. *Note Documentation::. 3262 3263 `ginclude' 3264 System headers installed by GCC, mainly those required by the C 3265 standard of freestanding implementations. *Note Headers Installed 3266 by GCC: Headers, for details of when these and other headers are 3267 installed. 3268 3269 `po' 3270 Message catalogs with translations of messages produced by GCC into 3271 various languages, `LANGUAGE.po'. This directory also contains 3272 `gcc.pot', the template for these message catalogues, `exgettext', 3273 a wrapper around `gettext' to extract the messages from the GCC 3274 sources and create `gcc.pot', which is run by `make gcc.pot', and 3275 `EXCLUDES', a list of files from which messages should not be 3276 extracted. 3277 3278 `testsuite' 3279 The GCC testsuites (except for those for runtime libraries). 3280 *Note Testsuites::. 3281 3282 3283 File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory 3284 3285 6.3.2 Configuration in the `gcc' Directory 3286 ------------------------------------------ 3287 3288 The `gcc' directory is configured with an Autoconf-generated script 3289 `configure'. The `configure' script is generated from `configure.ac' 3290 and `aclocal.m4'. From the files `configure.ac' and `acconfig.h', 3291 Autoheader generates the file `config.in'. The file `cstamp-h.in' is 3292 used as a timestamp. 3293 3294 * Menu: 3295 3296 * Config Fragments:: Scripts used by `configure'. 3297 * System Config:: The `config.build', `config.host', and 3298 `config.gcc' files. 3299 * Configuration Files:: Files created by running `configure'. 3300 3301 3302 File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration 3303 3304 6.3.2.1 Scripts Used by `configure' 3305 ................................... 3306 3307 `configure' uses some other scripts to help in its work: 3308 3309 * The standard GNU `config.sub' and `config.guess' files, kept in 3310 the top level directory, are used. 3311 3312 * The file `config.gcc' is used to handle configuration specific to 3313 the particular target machine. The file `config.build' is used to 3314 handle configuration specific to the particular build machine. 3315 The file `config.host' is used to handle configuration specific to 3316 the particular host machine. (In general, these should only be 3317 used for features that cannot reasonably be tested in Autoconf 3318 feature tests.) *Note The `config.build'; `config.host'; and 3319 `config.gcc' Files: System Config, for details of the contents of 3320 these files. 3321 3322 * Each language subdirectory has a file `LANGUAGE/config-lang.in' 3323 that is used for front-end-specific configuration. *Note The 3324 Front End `config-lang.in' File: Front End Config, for details of 3325 this file. 3326 3327 * A helper script `configure.frag' is used as part of creating the 3328 output of `configure'. 3329 3330 3331 File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration 3332 3333 6.3.2.2 The `config.build'; `config.host'; and `config.gcc' Files 3334 ................................................................. 3335 3336 The `config.build' file contains specific rules for particular systems 3337 which GCC is built on. This should be used as rarely as possible, as 3338 the behavior of the build system can always be detected by autoconf. 3339 3340 The `config.host' file contains specific rules for particular systems 3341 which GCC will run on. This is rarely needed. 3342 3343 The `config.gcc' file contains specific rules for particular systems 3344 which GCC will generate code for. This is usually needed. 3345 3346 Each file has a list of the shell variables it sets, with 3347 descriptions, at the top of the file. 3348 3349 FIXME: document the contents of these files, and what variables should 3350 be set to control build, host and target configuration. 3351 3352 3353 File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration 3354 3355 6.3.2.3 Files Created by `configure' 3356 .................................... 3357 3358 Here we spell out what files will be set up by `configure' in the `gcc' 3359 directory. Some other files are created as temporary files in the 3360 configuration process, and are not used in the subsequent build; these 3361 are not documented. 3362 3363 * `Makefile' is constructed from `Makefile.in', together with the 3364 host and target fragments (*note Makefile Fragments: Fragments.) 3365 `t-TARGET' and `x-HOST' from `config', if any, and language 3366 Makefile fragments `LANGUAGE/Make-lang.in'. 3367 3368 * `auto-host.h' contains information about the host machine 3369 determined by `configure'. If the host machine is different from 3370 the build machine, then `auto-build.h' is also created, containing 3371 such information about the build machine. 3372 3373 * `config.status' is a script that may be run to recreate the 3374 current configuration. 3375 3376 * `configargs.h' is a header containing details of the arguments 3377 passed to `configure' to configure GCC, and of the thread model 3378 used. 3379 3380 * `cstamp-h' is used as a timestamp. 3381 3382 * If a language `config-lang.in' file (*note The Front End 3383 `config-lang.in' File: Front End Config.) sets `outputs', then the 3384 files listed in `outputs' there are also generated. 3385 3386 The following configuration headers are created from the Makefile, 3387 using `mkconfig.sh', rather than directly by `configure'. `config.h', 3388 `bconfig.h' and `tconfig.h' all contain the `xm-MACHINE.h' header, if 3389 any, appropriate to the host, build and target machines respectively, 3390 the configuration headers for the target, and some definitions; for the 3391 host and build machines, these include the autoconfigured headers 3392 generated by `configure'. The other configuration headers are 3393 determined by `config.gcc'. They also contain the typedefs for `rtx', 3394 `rtvec' and `tree'. 3395 3396 * `config.h', for use in programs that run on the host machine. 3397 3398 * `bconfig.h', for use in programs that run on the build machine. 3399 3400 * `tconfig.h', for use in programs and libraries for the target 3401 machine. 3402 3403 * `tm_p.h', which includes the header `MACHINE-protos.h' that 3404 contains prototypes for functions in the target `MACHINE.c' file. 3405 The header `MACHINE-protos.h' can include prototypes of functions 3406 that use rtl and tree data structures inside appropriate `#ifdef 3407 RTX_CODE' and `#ifdef TREE_CODE' conditional code segements. The 3408 `MACHINE-protos.h' is included after the `rtl.h' and/or `tree.h' 3409 would have been included. The `tm_p.h' also includes the header 3410 `tm-preds.h' which is generated by `genpreds' program during the 3411 build to define the declarations and inline functions for the 3412 predicate functions. 3413 3414 3415 File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory 3416 3417 6.3.3 Build System in the `gcc' Directory 3418 ----------------------------------------- 3419 3420 FIXME: describe the build system, including what is built in what 3421 stages. Also list the various source files that are used in the build 3422 process but aren't source files of GCC itself and so aren't documented 3423 below (*note Passes::). 3424 3425 3426 File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory 3427 3428 6.3.4 Makefile Targets 3429 ---------------------- 3430 3431 These targets are available from the `gcc' directory: 3432 3433 `all' 3434 This is the default target. Depending on what your 3435 build/host/target configuration is, it coordinates all the things 3436 that need to be built. 3437 3438 `doc' 3439 Produce info-formatted documentation and man pages. Essentially it 3440 calls `make man' and `make info'. 3441 3442 `dvi' 3443 Produce DVI-formatted documentation. 3444 3445 `pdf' 3446 Produce PDF-formatted documentation. 3447 3448 `html' 3449 Produce HTML-formatted documentation. 3450 3451 `man' 3452 Generate man pages. 3453 3454 `info' 3455 Generate info-formatted pages. 3456 3457 `mostlyclean' 3458 Delete the files made while building the compiler. 3459 3460 `clean' 3461 That, and all the other files built by `make all'. 3462 3463 `distclean' 3464 That, and all the files created by `configure'. 3465 3466 `maintainer-clean' 3467 Distclean plus any file that can be generated from other files. 3468 Note that additional tools may be required beyond what is normally 3469 needed to build GCC. 3470 3471 `srcextra' 3472 Generates files in the source directory that are not 3473 version-controlled but should go into a release tarball. 3474 3475 `srcinfo' 3476 `srcman' 3477 Copies the info-formatted and manpage documentation into the source 3478 directory usually for the purpose of generating a release tarball. 3479 3480 `install' 3481 Installs GCC. 3482 3483 `uninstall' 3484 Deletes installed files, though this is not supported. 3485 3486 `check' 3487 Run the testsuite. This creates a `testsuite' subdirectory that 3488 has various `.sum' and `.log' files containing the results of the 3489 testing. You can run subsets with, for example, `make check-gcc'. 3490 You can specify specific tests by setting `RUNTESTFLAGS' to be the 3491 name of the `.exp' file, optionally followed by (for some tests) 3492 an equals and a file wildcard, like: 3493 3494 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*" 3495 3496 Note that running the testsuite may require additional tools be 3497 installed, such as Tcl or DejaGnu. 3498 3499 The toplevel tree from which you start GCC compilation is not the GCC 3500 directory, but rather a complex Makefile that coordinates the various 3501 steps of the build, including bootstrapping the compiler and using the 3502 new compiler to build target libraries. 3503 3504 When GCC is configured for a native configuration, the default action 3505 for `make' is to do a full three-stage bootstrap. This means that GCC 3506 is built three times--once with the native compiler, once with the 3507 native-built compiler it just built, and once with the compiler it 3508 built the second time. In theory, the last two should produce the same 3509 results, which `make compare' can check. Each stage is configured 3510 separately and compiled into a separate directory, to minimize problems 3511 due to ABI incompatibilities between the native compiler and GCC. 3512 3513 If you do a change, rebuilding will also start from the first stage 3514 and "bubble" up the change through the three stages. Each stage is 3515 taken from its build directory (if it had been built previously), 3516 rebuilt, and copied to its subdirectory. This will allow you to, for 3517 example, continue a bootstrap after fixing a bug which causes the 3518 stage2 build to crash. It does not provide as good coverage of the 3519 compiler as bootstrapping from scratch, but it ensures that the new 3520 code is syntactically correct (e.g., that you did not use GCC extensions 3521 by mistake), and avoids spurious bootstrap comparison failures(1). 3522 3523 Other targets available from the top level include: 3524 3525 `bootstrap-lean' 3526 Like `bootstrap', except that the various stages are removed once 3527 they're no longer needed. This saves disk space. 3528 3529 `bootstrap2' 3530 `bootstrap2-lean' 3531 Performs only the first two stages of bootstrap. Unlike a 3532 three-stage bootstrap, this does not perform a comparison to test 3533 that the compiler is running properly. Note that the disk space 3534 required by a "lean" bootstrap is approximately independent of the 3535 number of stages. 3536 3537 `stageN-bubble (N = 1...4, profile, feedback)' 3538 Rebuild all the stages up to N, with the appropriate flags, 3539 "bubbling" the changes as described above. 3540 3541 `all-stageN (N = 1...4, profile, feedback)' 3542 Assuming that stage N has already been built, rebuild it with the 3543 appropriate flags. This is rarely needed. 3544 3545 `cleanstrap' 3546 Remove everything (`make clean') and rebuilds (`make bootstrap'). 3547 3548 `compare' 3549 Compares the results of stages 2 and 3. This ensures that the 3550 compiler is running properly, since it should produce the same 3551 object files regardless of how it itself was compiled. 3552 3553 `profiledbootstrap' 3554 Builds a compiler with profiling feedback information. In this 3555 case, the second and third stages are named `profile' and 3556 `feedback', respectively. For more information, see *note 3557 Building with profile feedback: (gccinstall)Building. 3558 3559 `restrap' 3560 Restart a bootstrap, so that everything that was not built with 3561 the system compiler is rebuilt. 3562 3563 `stageN-start (N = 1...4, profile, feedback)' 3564 For each package that is bootstrapped, rename directories so that, 3565 for example, `gcc' points to the stageN GCC, compiled with the 3566 stageN-1 GCC(2). 3567 3568 You will invoke this target if you need to test or debug the 3569 stageN GCC. If you only need to execute GCC (but you need not run 3570 `make' either to rebuild it or to run test suites), you should be 3571 able to work directly in the `stageN-gcc' directory. This makes 3572 it easier to debug multiple stages in parallel. 3573 3574 `stage' 3575 For each package that is bootstrapped, relocate its build directory 3576 to indicate its stage. For example, if the `gcc' directory points 3577 to the stage2 GCC, after invoking this target it will be renamed 3578 to `stage2-gcc'. 3579 3580 3581 If you wish to use non-default GCC flags when compiling the stage2 and 3582 stage3 compilers, set `BOOT_CFLAGS' on the command line when doing 3583 `make'. 3584 3585 Usually, the first stage only builds the languages that the compiler 3586 is written in: typically, C and maybe Ada. If you are debugging a 3587 miscompilation of a different stage2 front-end (for example, of the 3588 Fortran front-end), you may want to have front-ends for other languages 3589 in the first stage as well. To do so, set `STAGE1_LANGUAGES' on the 3590 command line when doing `make'. 3591 3592 For example, in the aforementioned scenario of debugging a Fortran 3593 front-end miscompilation caused by the stage1 compiler, you may need a 3594 command like 3595 3596 make stage2-bubble STAGE1_LANGUAGES=c,fortran 3597 3598 Alternatively, you can use per-language targets to build and test 3599 languages that are not enabled by default in stage1. For example, 3600 `make f951' will build a Fortran compiler even in the stage1 build 3601 directory. 3602 3603 ---------- Footnotes ---------- 3604 3605 (1) Except if the compiler was buggy and miscompiled some of the files 3606 that were not modified. In this case, it's best to use `make restrap'. 3607 3608 (2) Customarily, the system compiler is also termed the `stage0' GCC. 3609 3610 3611 File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory 3612 3613 6.3.5 Library Source Files and Headers under the `gcc' Directory 3614 ---------------------------------------------------------------- 3615 3616 FIXME: list here, with explanation, all the C source files and headers 3617 under the `gcc' directory that aren't built into the GCC executable but 3618 rather are part of runtime libraries and object files, such as 3619 `crtstuff.c' and `unwind-dw2.c'. *Note Headers Installed by GCC: 3620 Headers, for more information about the `ginclude' directory. 3621 3622 3623 File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory 3624 3625 6.3.6 Headers Installed by GCC 3626 ------------------------------ 3627 3628 In general, GCC expects the system C library to provide most of the 3629 headers to be used with it. However, GCC will fix those headers if 3630 necessary to make them work with GCC, and will install some headers 3631 required of freestanding implementations. These headers are installed 3632 in `LIBSUBDIR/include'. Headers for non-C runtime libraries are also 3633 installed by GCC; these are not documented here. (FIXME: document them 3634 somewhere.) 3635 3636 Several of the headers GCC installs are in the `ginclude' directory. 3637 These headers, `iso646.h', `stdarg.h', `stdbool.h', and `stddef.h', are 3638 installed in `LIBSUBDIR/include', unless the target Makefile fragment 3639 (*note Target Fragment::) overrides this by setting `USER_H'. 3640 3641 In addition to these headers and those generated by fixing system 3642 headers to work with GCC, some other headers may also be installed in 3643 `LIBSUBDIR/include'. `config.gcc' may set `extra_headers'; this 3644 specifies additional headers under `config' to be installed on some 3645 systems. 3646 3647 GCC installs its own version of `<float.h>', from `ginclude/float.h'. 3648 This is done to cope with command-line options that change the 3649 representation of floating point numbers. 3650 3651 GCC also installs its own version of `<limits.h>'; this is generated 3652 from `glimits.h', together with `limitx.h' and `limity.h' if the system 3653 also has its own version of `<limits.h>'. (GCC provides its own header 3654 because it is required of ISO C freestanding implementations, but needs 3655 to include the system header from its own header as well because other 3656 standards such as POSIX specify additional values to be defined in 3657 `<limits.h>'.) The system's `<limits.h>' header is used via 3658 `LIBSUBDIR/include/syslimits.h', which is copied from `gsyslimits.h' if 3659 it does not need fixing to work with GCC; if it needs fixing, 3660 `syslimits.h' is the fixed copy. 3661 3662 GCC can also install `<tgmath.h>'. It will do this when `config.gcc' 3663 sets `use_gcc_tgmath' to `yes'. 3664 3665 3666 File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory 3667 3668 6.3.7 Building Documentation 3669 ---------------------------- 3670 3671 The main GCC documentation is in the form of manuals in Texinfo format. 3672 These are installed in Info format; DVI versions may be generated by 3673 `make dvi', PDF versions by `make pdf', and HTML versions by `make 3674 html'. In addition, some man pages are generated from the Texinfo 3675 manuals, there are some other text files with miscellaneous 3676 documentation, and runtime libraries have their own documentation 3677 outside the `gcc' directory. FIXME: document the documentation for 3678 runtime libraries somewhere. 3679 3680 * Menu: 3681 3682 * Texinfo Manuals:: GCC manuals in Texinfo format. 3683 * Man Page Generation:: Generating man pages from Texinfo manuals. 3684 * Miscellaneous Docs:: Miscellaneous text files with documentation. 3685 3686 3687 File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation 3688 3689 6.3.7.1 Texinfo Manuals 3690 ....................... 3691 3692 The manuals for GCC as a whole, and the C and C++ front ends, are in 3693 files `doc/*.texi'. Other front ends have their own manuals in files 3694 `LANGUAGE/*.texi'. Common files `doc/include/*.texi' are provided 3695 which may be included in multiple manuals; the following files are in 3696 `doc/include': 3697 3698 `fdl.texi' 3699 The GNU Free Documentation License. 3700 3701 `funding.texi' 3702 The section "Funding Free Software". 3703 3704 `gcc-common.texi' 3705 Common definitions for manuals. 3706 3707 `gpl_v3.texi' 3708 The GNU General Public License. 3709 3710 `texinfo.tex' 3711 A copy of `texinfo.tex' known to work with the GCC manuals. 3712 3713 DVI-formatted manuals are generated by `make dvi', which uses 3714 `texi2dvi' (via the Makefile macro `$(TEXI2DVI)'). PDF-formatted 3715 manuals are generated by `make pdf', which uses `texi2pdf' (via the 3716 Makefile macro `$(TEXI2PDF)'). HTML formatted manuals are generated by 3717 `make html'. Info manuals are generated by `make info' (which is run 3718 as part of a bootstrap); this generates the manuals in the source 3719 directory, using `makeinfo' via the Makefile macro `$(MAKEINFO)', and 3720 they are included in release distributions. 3721 3722 Manuals are also provided on the GCC web site, in both HTML and 3723 PostScript forms. This is done via the script 3724 `maintainer-scripts/update_web_docs_svn'. Each manual to be provided 3725 online must be listed in the definition of `MANUALS' in that file; a 3726 file `NAME.texi' must only appear once in the source tree, and the 3727 output manual must have the same name as the source file. (However, 3728 other Texinfo files, included in manuals but not themselves the root 3729 files of manuals, may have names that appear more than once in the 3730 source tree.) The manual file `NAME.texi' should only include other 3731 files in its own directory or in `doc/include'. HTML manuals will be 3732 generated by `makeinfo --html', PostScript manuals by `texi2dvi' and 3733 `dvips', and PDF manuals by `texi2pdf'. All Texinfo files that are 3734 parts of manuals must be version-controlled, even if they are generated 3735 files, for the generation of online manuals to work. 3736 3737 The installation manual, `doc/install.texi', is also provided on the 3738 GCC web site. The HTML version is generated by the script 3739 `doc/install.texi2html'. 3740 3741 3742 File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation 3743 3744 6.3.7.2 Man Page Generation 3745 ........................... 3746 3747 Because of user demand, in addition to full Texinfo manuals, man pages 3748 are provided which contain extracts from those manuals. These man 3749 pages are generated from the Texinfo manuals using 3750 `contrib/texi2pod.pl' and `pod2man'. (The man page for `g++', 3751 `cp/g++.1', just contains a `.so' reference to `gcc.1', but all the 3752 other man pages are generated from Texinfo manuals.) 3753 3754 Because many systems may not have the necessary tools installed to 3755 generate the man pages, they are only generated if the `configure' 3756 script detects that recent enough tools are installed, and the 3757 Makefiles allow generating man pages to fail without aborting the 3758 build. Man pages are also included in release distributions. They are 3759 generated in the source directory. 3760 3761 Magic comments in Texinfo files starting `@c man' control what parts 3762 of a Texinfo file go into a man page. Only a subset of Texinfo is 3763 supported by `texi2pod.pl', and it may be necessary to add support for 3764 more Texinfo features to this script when generating new man pages. To 3765 improve the man page output, some special Texinfo macros are provided 3766 in `doc/include/gcc-common.texi' which `texi2pod.pl' understands: 3767 3768 `@gcctabopt' 3769 Use in the form `@table @gcctabopt' for tables of options, where 3770 for printed output the effect of `@code' is better than that of 3771 `@option' but for man page output a different effect is wanted. 3772 3773 `@gccoptlist' 3774 Use for summary lists of options in manuals. 3775 3776 `@gol' 3777 Use at the end of each line inside `@gccoptlist'. This is 3778 necessary to avoid problems with differences in how the 3779 `@gccoptlist' macro is handled by different Texinfo formatters. 3780 3781 FIXME: describe the `texi2pod.pl' input language and magic comments in 3782 more detail. 3783 3784 3785 File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation 3786 3787 6.3.7.3 Miscellaneous Documentation 3788 ................................... 3789 3790 In addition to the formal documentation that is installed by GCC, there 3791 are several other text files in the `gcc' subdirectory with 3792 miscellaneous documentation: 3793 3794 `ABOUT-GCC-NLS' 3795 Notes on GCC's Native Language Support. FIXME: this should be 3796 part of this manual rather than a separate file. 3797 3798 `ABOUT-NLS' 3799 Notes on the Free Translation Project. 3800 3801 `COPYING' 3802 `COPYING3' 3803 The GNU General Public License, Versions 2 and 3. 3804 3805 `COPYING.LIB' 3806 `COPYING3.LIB' 3807 The GNU Lesser General Public License, Versions 2.1 and 3. 3808 3809 `*ChangeLog*' 3810 `*/ChangeLog*' 3811 Change log files for various parts of GCC. 3812 3813 `LANGUAGES' 3814 Details of a few changes to the GCC front-end interface. FIXME: 3815 the information in this file should be part of general 3816 documentation of the front-end interface in this manual. 3817 3818 `ONEWS' 3819 Information about new features in old versions of GCC. (For recent 3820 versions, the information is on the GCC web site.) 3821 3822 `README.Portability' 3823 Information about portability issues when writing code in GCC. 3824 FIXME: why isn't this part of this manual or of the GCC Coding 3825 Conventions? 3826 3827 FIXME: document such files in subdirectories, at least `config', `c', 3828 `cp', `objc', `testsuite'. 3829 3830 3831 File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory 3832 3833 6.3.8 Anatomy of a Language Front End 3834 ------------------------------------- 3835 3836 A front end for a language in GCC has the following parts: 3837 3838 * A directory `LANGUAGE' under `gcc' containing source files for 3839 that front end. *Note The Front End `LANGUAGE' Directory: Front 3840 End Directory, for details. 3841 3842 * A mention of the language in the list of supported languages in 3843 `gcc/doc/install.texi'. 3844 3845 * A mention of the name under which the language's runtime library is 3846 recognized by `--enable-shared=PACKAGE' in the documentation of 3847 that option in `gcc/doc/install.texi'. 3848 3849 * A mention of any special prerequisites for building the front end 3850 in the documentation of prerequisites in `gcc/doc/install.texi'. 3851 3852 * Details of contributors to that front end in 3853 `gcc/doc/contrib.texi'. If the details are in that front end's 3854 own manual then there should be a link to that manual's list in 3855 `contrib.texi'. 3856 3857 * Information about support for that language in 3858 `gcc/doc/frontends.texi'. 3859 3860 * Information about standards for that language, and the front end's 3861 support for them, in `gcc/doc/standards.texi'. This may be a link 3862 to such information in the front end's own manual. 3863 3864 * Details of source file suffixes for that language and `-x LANG' 3865 options supported, in `gcc/doc/invoke.texi'. 3866 3867 * Entries in `default_compilers' in `gcc.c' for source file suffixes 3868 for that language. 3869 3870 * Preferably testsuites, which may be under `gcc/testsuite' or 3871 runtime library directories. FIXME: document somewhere how to 3872 write testsuite harnesses. 3873 3874 * Probably a runtime library for the language, outside the `gcc' 3875 directory. FIXME: document this further. 3876 3877 * Details of the directories of any runtime libraries in 3878 `gcc/doc/sourcebuild.texi'. 3879 3880 * Check targets in `Makefile.def' for the top-level `Makefile' to 3881 check just the compiler or the compiler and runtime library for the 3882 language. 3883 3884 If the front end is added to the official GCC source repository, the 3885 following are also necessary: 3886 3887 * At least one Bugzilla component for bugs in that front end and 3888 runtime libraries. This category needs to be added to the 3889 Bugzilla database. 3890 3891 * Normally, one or more maintainers of that front end listed in 3892 `MAINTAINERS'. 3893 3894 * Mentions on the GCC web site in `index.html' and `frontends.html', 3895 with any relevant links on `readings.html'. (Front ends that are 3896 not an official part of GCC may also be listed on 3897 `frontends.html', with relevant links.) 3898 3899 * A news item on `index.html', and possibly an announcement on the 3900 <gcc-announce (a] gcc.gnu.org> mailing list. 3901 3902 * The front end's manuals should be mentioned in 3903 `maintainer-scripts/update_web_docs_svn' (*note Texinfo Manuals::) 3904 and the online manuals should be linked to from 3905 `onlinedocs/index.html'. 3906 3907 * Any old releases or CVS repositories of the front end, before its 3908 inclusion in GCC, should be made available on the GCC FTP site 3909 `ftp://gcc.gnu.org/pub/gcc/old-releases/'. 3910 3911 * The release and snapshot script `maintainer-scripts/gcc_release' 3912 should be updated to generate appropriate tarballs for this front 3913 end. 3914 3915 * If this front end includes its own version files that include the 3916 current date, `maintainer-scripts/update_version' should be 3917 updated accordingly. 3918 3919 * Menu: 3920 3921 * Front End Directory:: The front end `LANGUAGE' directory. 3922 * Front End Config:: The front end `config-lang.in' file. 3923 * Front End Makefile:: The front end `Make-lang.in' file. 3924 3925 3926 File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End 3927 3928 6.3.8.1 The Front End `LANGUAGE' Directory 3929 .......................................... 3930 3931 A front end `LANGUAGE' directory contains the source files of that 3932 front end (but not of any runtime libraries, which should be outside 3933 the `gcc' directory). This includes documentation, and possibly some 3934 subsidiary programs built alongside the front end. Certain files are 3935 special and other parts of the compiler depend on their names: 3936 3937 `config-lang.in' 3938 This file is required in all language subdirectories. *Note The 3939 Front End `config-lang.in' File: Front End Config, for details of 3940 its contents 3941 3942 `Make-lang.in' 3943 This file is required in all language subdirectories. *Note The 3944 Front End `Make-lang.in' File: Front End Makefile, for details of 3945 its contents. 3946 3947 `lang.opt' 3948 This file registers the set of switches that the front end accepts 3949 on the command line, and their `--help' text. *Note Options::. 3950 3951 `lang-specs.h' 3952 This file provides entries for `default_compilers' in `gcc.c' 3953 which override the default of giving an error that a compiler for 3954 that language is not installed. 3955 3956 `LANGUAGE-tree.def' 3957 This file, which need not exist, defines any language-specific tree 3958 codes. 3959 3960 3961 File: gccint.info, Node: Front End Config, Next: Front End Makefile, Prev: Front End Directory, Up: Front End 3962 3963 6.3.8.2 The Front End `config-lang.in' File 3964 ........................................... 3965 3966 Each language subdirectory contains a `config-lang.in' file. This file 3967 is a shell script that may define some variables describing the 3968 language: 3969 3970 `language' 3971 This definition must be present, and gives the name of the language 3972 for some purposes such as arguments to `--enable-languages'. 3973 3974 `lang_requires' 3975 If defined, this variable lists (space-separated) language front 3976 ends other than C that this front end requires to be enabled (with 3977 the names given being their `language' settings). For example, the 3978 Java front end depends on the C++ front end, so sets 3979 `lang_requires=c++'. 3980 3981 `subdir_requires' 3982 If defined, this variable lists (space-separated) front end 3983 directories other than C that this front end requires to be 3984 present. For example, the Objective-C++ front end uses source 3985 files from the C++ and Objective-C front ends, so sets 3986 `subdir_requires="cp objc"'. 3987 3988 `target_libs' 3989 If defined, this variable lists (space-separated) targets in the 3990 top level `Makefile' to build the runtime libraries for this 3991 language, such as `target-libobjc'. 3992 3993 `lang_dirs' 3994 If defined, this variable lists (space-separated) top level 3995 directories (parallel to `gcc'), apart from the runtime libraries, 3996 that should not be configured if this front end is not built. 3997 3998 `build_by_default' 3999 If defined to `no', this language front end is not built unless 4000 enabled in a `--enable-languages' argument. Otherwise, front ends 4001 are built by default, subject to any special logic in 4002 `configure.ac' (as is present to disable the Ada front end if the 4003 Ada compiler is not already installed). 4004 4005 `boot_language' 4006 If defined to `yes', this front end is built in stage1 of the 4007 bootstrap. This is only relevant to front ends written in their 4008 own languages. 4009 4010 `compilers' 4011 If defined, a space-separated list of compiler executables that 4012 will be run by the driver. The names here will each end with 4013 `\$(exeext)'. 4014 4015 `outputs' 4016 If defined, a space-separated list of files that should be 4017 generated by `configure' substituting values in them. This 4018 mechanism can be used to create a file `LANGUAGE/Makefile' from 4019 `LANGUAGE/Makefile.in', but this is deprecated, building 4020 everything from the single `gcc/Makefile' is preferred. 4021 4022 `gtfiles' 4023 If defined, a space-separated list of files that should be scanned 4024 by `gengtype.c' to generate the garbage collection tables and 4025 routines for this language. This excludes the files that are 4026 common to all front ends. *Note Type Information::. 4027 4028 4029 4030 File: gccint.info, Node: Front End Makefile, Prev: Front End Config, Up: Front End 4031 4032 6.3.8.3 The Front End `Make-lang.in' File 4033 ......................................... 4034 4035 Each language subdirectory contains a `Make-lang.in' file. It contains 4036 targets `LANG.HOOK' (where `LANG' is the setting of `language' in 4037 `config-lang.in') for the following values of `HOOK', and any other 4038 Makefile rules required to build those targets (which may if necessary 4039 use other Makefiles specified in `outputs' in `config-lang.in', 4040 although this is deprecated). It also adds any testsuite targets that 4041 can use the standard rule in `gcc/Makefile.in' to the variable 4042 `lang_checks'. 4043 4044 `all.cross' 4045 `start.encap' 4046 `rest.encap' 4047 FIXME: exactly what goes in each of these targets? 4048 4049 `tags' 4050 Build an `etags' `TAGS' file in the language subdirectory in the 4051 source tree. 4052 4053 `info' 4054 Build info documentation for the front end, in the build directory. 4055 This target is only called by `make bootstrap' if a suitable 4056 version of `makeinfo' is available, so does not need to check for 4057 this, and should fail if an error occurs. 4058 4059 `dvi' 4060 Build DVI documentation for the front end, in the build directory. 4061 This should be done using `$(TEXI2DVI)', with appropriate `-I' 4062 arguments pointing to directories of included files. 4063 4064 `pdf' 4065 Build PDF documentation for the front end, in the build directory. 4066 This should be done using `$(TEXI2PDF)', with appropriate `-I' 4067 arguments pointing to directories of included files. 4068 4069 `html' 4070 Build HTML documentation for the front end, in the build directory. 4071 4072 `man' 4073 Build generated man pages for the front end from Texinfo manuals 4074 (*note Man Page Generation::), in the build directory. This target 4075 is only called if the necessary tools are available, but should 4076 ignore errors so as not to stop the build if errors occur; man 4077 pages are optional and the tools involved may be installed in a 4078 broken way. 4079 4080 `install-common' 4081 Install everything that is part of the front end, apart from the 4082 compiler executables listed in `compilers' in `config-lang.in'. 4083 4084 `install-info' 4085 Install info documentation for the front end, if it is present in 4086 the source directory. This target should have dependencies on 4087 info files that should be installed. 4088 4089 `install-man' 4090 Install man pages for the front end. This target should ignore 4091 errors. 4092 4093 `install-plugin' 4094 Install headers needed for plugins. 4095 4096 `srcextra' 4097 Copies its dependencies into the source directory. This generally 4098 should be used for generated files such as Bison output files 4099 which are not version-controlled, but should be included in any 4100 release tarballs. This target will be executed during a bootstrap 4101 if `--enable-generated-files-in-srcdir' was specified as a 4102 `configure' option. 4103 4104 `srcinfo' 4105 `srcman' 4106 Copies its dependencies into the source directory. These targets 4107 will be executed during a bootstrap if 4108 `--enable-generated-files-in-srcdir' was specified as a 4109 `configure' option. 4110 4111 `uninstall' 4112 Uninstall files installed by installing the compiler. This is 4113 currently documented not to be supported, so the hook need not do 4114 anything. 4115 4116 `mostlyclean' 4117 `clean' 4118 `distclean' 4119 `maintainer-clean' 4120 The language parts of the standard GNU `*clean' targets. *Note 4121 Standard Targets for Users: (standards)Standard Targets, for 4122 details of the standard targets. For GCC, `maintainer-clean' 4123 should delete all generated files in the source directory that are 4124 not version-controlled, but should not delete anything that is. 4125 4126 `Make-lang.in' must also define a variable `LANG_OBJS' to a list of 4127 host object files that are used by that language. 4128 4129 4130 File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory 4131 4132 6.3.9 Anatomy of a Target Back End 4133 ---------------------------------- 4134 4135 A back end for a target architecture in GCC has the following parts: 4136 4137 * A directory `MACHINE' under `gcc/config', containing a machine 4138 description `MACHINE.md' file (*note Machine Descriptions: Machine 4139 Desc.), header files `MACHINE.h' and `MACHINE-protos.h' and a 4140 source file `MACHINE.c' (*note Target Description Macros and 4141 Functions: Target Macros.), possibly a target Makefile fragment 4142 `t-MACHINE' (*note The Target Makefile Fragment: Target 4143 Fragment.), and maybe some other files. The names of these files 4144 may be changed from the defaults given by explicit specifications 4145 in `config.gcc'. 4146 4147 * If necessary, a file `MACHINE-modes.def' in the `MACHINE' 4148 directory, containing additional machine modes to represent 4149 condition codes. *Note Condition Code::, for further details. 4150 4151 * An optional `MACHINE.opt' file in the `MACHINE' directory, 4152 containing a list of target-specific options. You can also add 4153 other option files using the `extra_options' variable in 4154 `config.gcc'. *Note Options::. 4155 4156 * Entries in `config.gcc' (*note The `config.gcc' File: System 4157 Config.) for the systems with this target architecture. 4158 4159 * Documentation in `gcc/doc/invoke.texi' for any command-line 4160 options supported by this target (*note Run-time Target 4161 Specification: Run-time Target.). This means both entries in the 4162 summary table of options and details of the individual options. 4163 4164 * Documentation in `gcc/doc/extend.texi' for any target-specific 4165 attributes supported (*note Defining target-specific uses of 4166 `__attribute__': Target Attributes.), including where the same 4167 attribute is already supported on some targets, which are 4168 enumerated in the manual. 4169 4170 * Documentation in `gcc/doc/extend.texi' for any target-specific 4171 pragmas supported. 4172 4173 * Documentation in `gcc/doc/extend.texi' of any target-specific 4174 built-in functions supported. 4175 4176 * Documentation in `gcc/doc/extend.texi' of any target-specific 4177 format checking styles supported. 4178 4179 * Documentation in `gcc/doc/md.texi' of any target-specific 4180 constraint letters (*note Constraints for Particular Machines: 4181 Machine Constraints.). 4182 4183 * A note in `gcc/doc/contrib.texi' under the person or people who 4184 contributed the target support. 4185 4186 * Entries in `gcc/doc/install.texi' for all target triplets 4187 supported with this target architecture, giving details of any 4188 special notes about installation for this target, or saying that 4189 there are no special notes if there are none. 4190 4191 * Possibly other support outside the `gcc' directory for runtime 4192 libraries. FIXME: reference docs for this. The `libstdc++' 4193 porting manual needs to be installed as info for this to work, or 4194 to be a chapter of this manual. 4195 4196 If the back end is added to the official GCC source repository, the 4197 following are also necessary: 4198 4199 * An entry for the target architecture in `readings.html' on the GCC 4200 web site, with any relevant links. 4201 4202 * Details of the properties of the back end and target architecture 4203 in `backends.html' on the GCC web site. 4204 4205 * A news item about the contribution of support for that target 4206 architecture, in `index.html' on the GCC web site. 4207 4208 * Normally, one or more maintainers of that target listed in 4209 `MAINTAINERS'. Some existing architectures may be unmaintained, 4210 but it would be unusual to add support for a target that does not 4211 have a maintainer when support is added. 4212 4213 * Target triplets covering all `config.gcc' stanzas for the target, 4214 in the list in `contrib/config-list.mk'. 4215 4216 4217 File: gccint.info, Node: Testsuites, Next: Options, Prev: Source Tree, Up: Top 4218 4219 7 Testsuites 4220 ************ 4221 4222 GCC contains several testsuites to help maintain compiler quality. 4223 Most of the runtime libraries and language front ends in GCC have 4224 testsuites. Currently only the C language testsuites are documented 4225 here; FIXME: document the others. 4226 4227 * Menu: 4228 4229 * Test Idioms:: Idioms used in testsuite code. 4230 * Test Directives:: Directives used within DejaGnu tests. 4231 * Ada Tests:: The Ada language testsuites. 4232 * C Tests:: The C language testsuites. 4233 * libgcj Tests:: The Java library testsuites. 4234 * LTO Testing:: Support for testing link-time optimizations. 4235 * gcov Testing:: Support for testing gcov. 4236 * profopt Testing:: Support for testing profile-directed optimizations. 4237 * compat Testing:: Support for testing binary compatibility. 4238 * Torture Tests:: Support for torture testing using multiple options. 4239 4240 4241 File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites 4242 4243 7.1 Idioms Used in Testsuite Code 4244 ================================= 4245 4246 In general, C testcases have a trailing `-N.c', starting with `-1.c', 4247 in case other testcases with similar names are added later. If the 4248 test is a test of some well-defined feature, it should have a name 4249 referring to that feature such as `FEATURE-1.c'. If it does not test a 4250 well-defined feature but just happens to exercise a bug somewhere in 4251 the compiler, and a bug report has been filed for this bug in the GCC 4252 bug database, `prBUG-NUMBER-1.c' is the appropriate form of name. 4253 Otherwise (for miscellaneous bugs not filed in the GCC bug database), 4254 and previously more generally, test cases are named after the date on 4255 which they were added. This allows people to tell at a glance whether 4256 a test failure is because of a recently found bug that has not yet been 4257 fixed, or whether it may be a regression, but does not give any other 4258 information about the bug or where discussion of it may be found. Some 4259 other language testsuites follow similar conventions. 4260 4261 In the `gcc.dg' testsuite, it is often necessary to test that an error 4262 is indeed a hard error and not just a warning--for example, where it is 4263 a constraint violation in the C standard, which must become an error 4264 with `-pedantic-errors'. The following idiom, where the first line 4265 shown is line LINE of the file and the line that generates the error, 4266 is used for this: 4267 4268 /* { dg-bogus "warning" "warning in place of error" } */ 4269 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */ 4270 4271 It may be necessary to check that an expression is an integer constant 4272 expression and has a certain value. To check that `E' has value `V', 4273 an idiom similar to the following is used: 4274 4275 char x[((E) == (V) ? 1 : -1)]; 4276 4277 In `gcc.dg' tests, `__typeof__' is sometimes used to make assertions 4278 about the types of expressions. See, for example, 4279 `gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact 4280 rules for the types of conditional expressions in the C standard; see, 4281 for example, `gcc.dg/c99-intconst-1.c'. 4282 4283 It is useful to be able to test that optimizations are being made 4284 properly. This cannot be done in all cases, but it can be done where 4285 the optimization will lead to code being optimized away (for example, 4286 where flow analysis or alias analysis should show that certain code 4287 cannot be called) or to functions not being called because they have 4288 been expanded as built-in functions. Such tests go in 4289 `gcc.c-torture/execute'. Where code should be optimized away, a call 4290 to a nonexistent function such as `link_failure ()' may be inserted; a 4291 definition 4292 4293 #ifndef __OPTIMIZE__ 4294 void 4295 link_failure (void) 4296 { 4297 abort (); 4298 } 4299 #endif 4300 4301 will also be needed so that linking still succeeds when the test is run 4302 without optimization. When all calls to a built-in function should 4303 have been optimized and no calls to the non-built-in version of the 4304 function should remain, that function may be defined as `static' to 4305 call `abort ()' (although redeclaring a function as static may not work 4306 on all targets). 4307 4308 All testcases must be portable. Target-specific testcases must have 4309 appropriate code to avoid causing failures on unsupported systems; 4310 unfortunately, the mechanisms for this differ by directory. 4311 4312 FIXME: discuss non-C testsuites here. 4313 4314 4315 File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites 4316 4317 7.2 Directives used within DejaGnu tests 4318 ======================================== 4319 4320 * Menu: 4321 4322 * Directives:: Syntax and descriptions of test directives. 4323 * Selectors:: Selecting targets to which a test applies. 4324 * Effective-Target Keywords:: Keywords describing target attributes. 4325 * Add Options:: Features for `dg-add-options' 4326 * Require Support:: Variants of `dg-require-SUPPORT' 4327 * Final Actions:: Commands for use in `dg-final' 4328 4329 4330 File: gccint.info, Node: Directives, Next: Selectors, Up: Test Directives 4331 4332 7.2.1 Syntax and Descriptions of test directives 4333 ------------------------------------------------ 4334 4335 Test directives appear within comments in a test source file and begin 4336 with `dg-'. Some of these are defined within DejaGnu and others are 4337 local to the GCC testsuite. 4338 4339 The order in which test directives appear in a test can be important: 4340 directives local to GCC sometimes override information used by the 4341 DejaGnu directives, which know nothing about the GCC directives, so the 4342 DejaGnu directives must precede GCC directives. 4343 4344 Several test directives include selectors (*note Selectors::) which 4345 are usually preceded by the keyword `target' or `xfail'. 4346 4347 7.2.1.1 Specify how to build the test 4348 ..................................... 4349 4350 `{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }' 4351 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 4352 is executed. It is one of: 4353 4354 `preprocess' 4355 Compile with `-E' to run only the preprocessor. 4356 4357 `compile' 4358 Compile with `-S' to produce an assembly code file. 4359 4360 `assemble' 4361 Compile with `-c' to produce a relocatable object file. 4362 4363 `link' 4364 Compile, assemble, and link to produce an executable file. 4365 4366 `run' 4367 Produce and run an executable file, which is expected to 4368 return an exit code of 0. 4369 4370 The default is `compile'. That can be overridden for a set of 4371 tests by redefining `dg-do-what-default' within the `.exp' file 4372 for those tests. 4373 4374 If the directive includes the optional `{ target SELECTOR }' then 4375 the test is skipped unless the target system matches the SELECTOR. 4376 4377 If DO-WHAT-KEYWORD is `run' and the directive includes the 4378 optional `{ xfail SELECTOR }' and the selector is met then the 4379 test is expected to fail. The `xfail' clause is ignored for other 4380 values of DO-WHAT-KEYWORD; those tests can use directive 4381 `dg-xfail-if'. 4382 4383 7.2.1.2 Specify additional compiler options 4384 ........................................... 4385 4386 `{ dg-options OPTIONS [{ target SELECTOR }] }' 4387 This DejaGnu directive provides a list of compiler options, to be 4388 used if the target system matches SELECTOR, that replace the 4389 default options used for this set of tests. 4390 4391 `{ dg-add-options FEATURE ... }' 4392 Add any compiler options that are needed to access certain 4393 features. This directive does nothing on targets that enable the 4394 features by default, or that don't provide them at all. It must 4395 come after all `dg-options' directives. For supported values of 4396 FEATURE see *note Add Options::. 4397 4398 `{ dg-additional-options OPTIONS [{ target SELECTOR }] }' 4399 This directive provides a list of compiler options, to be used if 4400 the target system matches SELECTOR, that are added to the default 4401 options used for this set of tests. 4402 4403 7.2.1.3 Modify the test timeout value 4404 ..................................... 4405 4406 The normal timeout limit, in seconds, is found by searching the 4407 following in order: 4408 4409 * the value defined by an earlier `dg-timeout' directive in the test 4410 4411 * variable TOOL_TIMEOUT defined by the set of tests 4412 4413 * GCC,TIMEOUT set in the target board 4414 4415 * 300 4416 4417 `{ dg-timeout N [{target SELECTOR }] }' 4418 Set the time limit for the compilation and for the execution of 4419 the test to the specified number of seconds. 4420 4421 `{ dg-timeout-factor X [{ target SELECTOR }] }' 4422 Multiply the normal time limit for compilation and execution of 4423 the test by the specified floating-point factor. 4424 4425 7.2.1.4 Skip a test for some targets 4426 .................................... 4427 4428 `{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4429 Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each 4430 element is a string of zero or more GCC options. Skip the test if 4431 all of the following conditions are met: 4432 * the test system is included in SELECTOR 4433 4434 * for at least one of the option strings in INCLUDE-OPTS, every 4435 option from that string is in the set of options with which 4436 the test would be compiled; use `"*"' for an INCLUDE-OPTS list 4437 that matches any options; that is the default if INCLUDE-OPTS 4438 is not specified 4439 4440 * for each of the option strings in EXCLUDE-OPTS, at least one 4441 option from that string is not in the set of options with 4442 which the test would be compiled; use `""' for an empty 4443 EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not 4444 specified 4445 4446 For example, to skip a test if option `-Os' is present: 4447 4448 /* { dg-skip-if "" { *-*-* } { "-Os" } { "" } } */ 4449 4450 To skip a test if both options `-O2' and `-g' are present: 4451 4452 /* { dg-skip-if "" { *-*-* } { "-O2 -g" } { "" } } */ 4453 4454 To skip a test if either `-O2' or `-O3' is present: 4455 4456 /* { dg-skip-if "" { *-*-* } { "-O2" "-O3" } { "" } } */ 4457 4458 To skip a test unless option `-Os' is present: 4459 4460 /* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */ 4461 4462 To skip a test if either `-O2' or `-O3' is used with `-g' but not 4463 if `-fpic' is also present: 4464 4465 /* { dg-skip-if "" { *-*-* } { "-O2 -g" "-O3 -g" } { "-fpic" } } */ 4466 4467 `{ dg-require-effective-target KEYWORD [{ SELECTOR }] }' 4468 Skip the test if the test target, including current multilib flags, 4469 is not covered by the effective-target keyword. If the directive 4470 includes the optional `{ SELECTOR }' then the effective-target 4471 test is only performed if the target system matches the SELECTOR. 4472 This directive must appear after any `dg-do' directive in the test 4473 and before any `dg-additional-sources' directive. *Note 4474 Effective-Target Keywords::. 4475 4476 `{ dg-require-SUPPORT args }' 4477 Skip the test if the target does not provide the required support. 4478 These directives must appear after any `dg-do' directive in the 4479 test and before any `dg-additional-sources' directive. They 4480 require at least one argument, which can be an empty string if the 4481 specific procedure does not examine the argument. *Note Require 4482 Support::, for a complete list of these directives. 4483 4484 7.2.1.5 Expect a test to fail for some targets 4485 .............................................. 4486 4487 `{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4488 Expect the test to fail if the conditions (which are the same as 4489 for `dg-skip-if') are met. This does not affect the execute step. 4490 4491 `{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4492 Expect the execute step of a test to fail if the conditions (which 4493 are the same as for `dg-skip-if') are met. 4494 4495 7.2.1.6 Expect the test executable to fail 4496 .......................................... 4497 4498 `{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }' 4499 Expect the test executable to return a nonzero exit status if the 4500 conditions (which are the same as for `dg-skip-if') are met. 4501 4502 7.2.1.7 Verify compiler messages 4503 ................................ 4504 4505 `{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4506 This DejaGnu directive appears on a source line that is expected 4507 to get an error message, or else specifies the source line 4508 associated with the message. If there is no message for that line 4509 or if the text of that message is not matched by REGEXP then the 4510 check fails and COMMENT is included in the `FAIL' message. The 4511 check does not look for the string `error' unless it is part of 4512 REGEXP. 4513 4514 `{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4515 This DejaGnu directive appears on a source line that is expected 4516 to get a warning message, or else specifies the source line 4517 associated with the message. If there is no message for that line 4518 or if the text of that message is not matched by REGEXP then the 4519 check fails and COMMENT is included in the `FAIL' message. The 4520 check does not look for the string `warning' unless it is part of 4521 REGEXP. 4522 4523 `{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4524 The line is expected to get a message other than an error or 4525 warning. If there is no message for that line or if the text of 4526 that message is not matched by REGEXP then the check fails and 4527 COMMENT is included in the `FAIL' message. 4528 4529 `{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4530 This DejaGnu directive appears on a source line that should not 4531 get a message matching REGEXP, or else specifies the source line 4532 associated with the bogus message. It is usually used with `xfail' 4533 to indicate that the message is a known problem for a particular 4534 set of targets. 4535 4536 `{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }' 4537 This DejaGnu directive indicates that the test is expected to fail 4538 due to compiler messages that are not handled by `dg-error', 4539 `dg-warning' or `dg-bogus'. For this directive `xfail' has the 4540 same effect as `target'. 4541 4542 `{ dg-prune-output REGEXP }' 4543 Prune messages matching REGEXP from the test output. 4544 4545 7.2.1.8 Verify output of the test executable 4546 ............................................ 4547 4548 `{ dg-output REGEXP [{ target/xfail SELECTOR }] }' 4549 This DejaGnu directive compares REGEXP to the combined output that 4550 the test executable writes to `stdout' and `stderr'. 4551 4552 7.2.1.9 Specify additional files for a test 4553 ........................................... 4554 4555 `{ dg-additional-files "FILELIST" }' 4556 Specify additional files, other than source files, that must be 4557 copied to the system where the compiler runs. 4558 4559 `{ dg-additional-sources "FILELIST" }' 4560 Specify additional source files to appear in the compile line 4561 following the main test file. 4562 4563 7.2.1.10 Add checks at the end of a test 4564 ........................................ 4565 4566 `{ dg-final { LOCAL-DIRECTIVE } }' 4567 This DejaGnu directive is placed within a comment anywhere in the 4568 source file and is processed after the test has been compiled and 4569 run. Multiple `dg-final' commands are processed in the order in 4570 which they appear in the source file. *Note Final Actions::, for 4571 a list of directives that can be used within `dg-final'. 4572 4573 4574 File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives 4575 4576 7.2.2 Selecting targets to which a test applies 4577 ----------------------------------------------- 4578 4579 Several test directives include SELECTORs to limit the targets for 4580 which a test is run or to declare that a test is expected to fail on 4581 particular targets. 4582 4583 A selector is: 4584 * one or more target triplets, possibly including wildcard 4585 characters; use `*-*-*' to match any target 4586 4587 * a single effective-target keyword (*note Effective-Target 4588 Keywords::) 4589 4590 * a logical expression 4591 4592 Depending on the context, the selector specifies whether a test is 4593 skipped and reported as unsupported or is expected to fail. A context 4594 that allows either `target' or `xfail' also allows `{ target SELECTOR1 4595 xfail SELECTOR2 }' to skip the test for targets that don't match 4596 SELECTOR1 and the test to fail for targets that match SELECTOR2. 4597 4598 A selector expression appears within curly braces and uses a single 4599 logical operator: one of `!', `&&', or `||'. An operand is another 4600 selector expression, an effective-target keyword, a single target 4601 triplet, or a list of target triplets within quotes or curly braces. 4602 For example: 4603 4604 { target { ! "hppa*-*-* ia64*-*-*" } } 4605 { target { powerpc*-*-* && lp64 } } 4606 { xfail { lp64 || vect_no_align } } 4607 4608 4609 File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives 4610 4611 7.2.3 Keywords describing target attributes 4612 ------------------------------------------- 4613 4614 Effective-target keywords identify sets of targets that support 4615 particular functionality. They are used to limit tests to be run only 4616 for particular targets, or to specify that particular sets of targets 4617 are expected to fail some tests. 4618 4619 Effective-target keywords are defined in `lib/target-supports.exp' in 4620 the GCC testsuite, with the exception of those that are documented as 4621 being local to a particular test directory. 4622 4623 The `effective target' takes into account all of the compiler options 4624 with which the test will be compiled, including the multilib options. 4625 By convention, keywords ending in `_nocache' can also include options 4626 specified for the particular test in an earlier `dg-options' or 4627 `dg-add-options' directive. 4628 4629 7.2.3.1 Data type sizes 4630 ....................... 4631 4632 `ilp32' 4633 Target has 32-bit `int', `long', and pointers. 4634 4635 `lp64' 4636 Target has 32-bit `int', 64-bit `long' and pointers. 4637 4638 `llp64' 4639 Target has 32-bit `int' and `long', 64-bit `long long' and 4640 pointers. 4641 4642 `double64' 4643 Target has 64-bit `double'. 4644 4645 `double64plus' 4646 Target has `double' that is 64 bits or longer. 4647 4648 `int32plus' 4649 Target has `int' that is at 32 bits or longer. 4650 4651 `int16' 4652 Target has `int' that is 16 bits or shorter. 4653 4654 `long_neq_int' 4655 Target has `int' and `long' with different sizes. 4656 4657 `large_double' 4658 Target supports `double' that is longer than `float'. 4659 4660 `large_long_double' 4661 Target supports `long double' that is longer than `double'. 4662 4663 `ptr32plus' 4664 Target has pointers that are 32 bits or longer. 4665 4666 `size32plus' 4667 Target supports array and structure sizes that are 32 bits or 4668 longer. 4669 4670 `4byte_wchar_t' 4671 Target has `wchar_t' that is at least 4 bytes. 4672 4673 7.2.3.2 Fortran-specific attributes 4674 ................................... 4675 4676 `fortran_integer_16' 4677 Target supports Fortran `integer' that is 16 bytes or longer. 4678 4679 `fortran_large_int' 4680 Target supports Fortran `integer' kinds larger than `integer(8)'. 4681 4682 `fortran_large_real' 4683 Target supports Fortran `real' kinds larger than `real(8)'. 4684 4685 7.2.3.3 Vector-specific attributes 4686 .................................. 4687 4688 `vect_condition' 4689 Target supports vector conditional operations. 4690 4691 `vect_double' 4692 Target supports hardware vectors of `double'. 4693 4694 `vect_float' 4695 Target supports hardware vectors of `float'. 4696 4697 `vect_int' 4698 Target supports hardware vectors of `int'. 4699 4700 `vect_long' 4701 Target supports hardware vectors of `long'. 4702 4703 `vect_long_long' 4704 Target supports hardware vectors of `long long'. 4705 4706 `vect_aligned_arrays' 4707 Target aligns arrays to vector alignment boundary. 4708 4709 `vect_hw_misalign' 4710 Target supports a vector misalign access. 4711 4712 `vect_no_align' 4713 Target does not support a vector alignment mechanism. 4714 4715 `vect_no_int_max' 4716 Target does not support a vector max instruction on `int'. 4717 4718 `vect_no_int_add' 4719 Target does not support a vector add instruction on `int'. 4720 4721 `vect_no_bitwise' 4722 Target does not support vector bitwise instructions. 4723 4724 `vect_char_mult' 4725 Target supports `vector char' multiplication. 4726 4727 `vect_short_mult' 4728 Target supports `vector short' multiplication. 4729 4730 `vect_int_mult' 4731 Target supports `vector int' multiplication. 4732 4733 `vect_extract_even_odd' 4734 Target supports vector even/odd element extraction. 4735 4736 `vect_extract_even_odd_wide' 4737 Target supports vector even/odd element extraction of vectors with 4738 elements `SImode' or larger. 4739 4740 `vect_interleave' 4741 Target supports vector interleaving. 4742 4743 `vect_strided' 4744 Target supports vector interleaving and extract even/odd. 4745 4746 `vect_strided_wide' 4747 Target supports vector interleaving and extract even/odd for wide 4748 element types. 4749 4750 `vect_perm' 4751 Target supports vector permutation. 4752 4753 `vect_shift' 4754 Target supports a hardware vector shift operation. 4755 4756 `vect_widen_sum_hi_to_si' 4757 Target supports a vector widening summation of `short' operands 4758 into `int' results, or can promote (unpack) from `short' to `int'. 4759 4760 `vect_widen_sum_qi_to_hi' 4761 Target supports a vector widening summation of `char' operands 4762 into `short' results, or can promote (unpack) from `char' to 4763 `short'. 4764 4765 `vect_widen_sum_qi_to_si' 4766 Target supports a vector widening summation of `char' operands 4767 into `int' results. 4768 4769 `vect_widen_mult_qi_to_hi' 4770 Target supports a vector widening multiplication of `char' operands 4771 into `short' results, or can promote (unpack) from `char' to 4772 `short' and perform non-widening multiplication of `short'. 4773 4774 `vect_widen_mult_hi_to_si' 4775 Target supports a vector widening multiplication of `short' 4776 operands into `int' results, or can promote (unpack) from `short' 4777 to `int' and perform non-widening multiplication of `int'. 4778 4779 `vect_sdot_qi' 4780 Target supports a vector dot-product of `signed char'. 4781 4782 `vect_udot_qi' 4783 Target supports a vector dot-product of `unsigned char'. 4784 4785 `vect_sdot_hi' 4786 Target supports a vector dot-product of `signed short'. 4787 4788 `vect_udot_hi' 4789 Target supports a vector dot-product of `unsigned short'. 4790 4791 `vect_pack_trunc' 4792 Target supports a vector demotion (packing) of `short' to `char' 4793 and from `int' to `short' using modulo arithmetic. 4794 4795 `vect_unpack' 4796 Target supports a vector promotion (unpacking) of `char' to `short' 4797 and from `char' to `int'. 4798 4799 `vect_intfloat_cvt' 4800 Target supports conversion from `signed int' to `float'. 4801 4802 `vect_uintfloat_cvt' 4803 Target supports conversion from `unsigned int' to `float'. 4804 4805 `vect_floatint_cvt' 4806 Target supports conversion from `float' to `signed int'. 4807 4808 `vect_floatuint_cvt' 4809 Target supports conversion from `float' to `unsigned int'. 4810 4811 7.2.3.4 Thread Local Storage attributes 4812 ....................................... 4813 4814 `tls' 4815 Target supports thread-local storage. 4816 4817 `tls_native' 4818 Target supports native (rather than emulated) thread-local storage. 4819 4820 `tls_runtime' 4821 Test system supports executing TLS executables. 4822 4823 7.2.3.5 Decimal floating point attributes 4824 ......................................... 4825 4826 `dfp' 4827 Targets supports compiling decimal floating point extension to C. 4828 4829 `dfp_nocache' 4830 Including the options used to compile this particular test, the 4831 target supports compiling decimal floating point extension to C. 4832 4833 `dfprt' 4834 Test system can execute decimal floating point tests. 4835 4836 `dfprt_nocache' 4837 Including the options used to compile this particular test, the 4838 test system can execute decimal floating point tests. 4839 4840 `hard_dfp' 4841 Target generates decimal floating point instructions with current 4842 options. 4843 4844 7.2.3.6 ARM-specific attributes 4845 ............................... 4846 4847 `arm32' 4848 ARM target generates 32-bit code. 4849 4850 `arm_eabi' 4851 ARM target adheres to the ABI for the ARM Architecture. 4852 4853 `arm_hf_eabi' 4854 ARM target adheres to the VFP and Advanced SIMD Register Arguments 4855 variant of the ABI for the ARM Architecture (as selected with 4856 `-mfloat-abi=hard'). 4857 4858 `arm_hard_vfp_ok' 4859 ARM target supports `-mfpu=vfp -mfloat-abi=hard'. Some multilibs 4860 may be incompatible with these options. 4861 4862 `arm_iwmmxt_ok' 4863 ARM target supports `-mcpu=iwmmxt'. Some multilibs may be 4864 incompatible with this option. 4865 4866 `arm_neon' 4867 ARM target supports generating NEON instructions. 4868 4869 `arm_neon_hw' 4870 Test system supports executing NEON instructions. 4871 4872 `arm_neonv2_hw' 4873 Test system supports executing NEON v2 instructions. 4874 4875 `arm_neon_ok' 4876 ARM Target supports `-mfpu=neon -mfloat-abi=softfp' or compatible 4877 options. Some multilibs may be incompatible with these options. 4878 4879 `arm_neonv2_ok' 4880 ARM Target supports `-mfpu=neon-vfpv4 -mfloat-abi=softfp' or 4881 compatible options. Some multilibs may be incompatible with these 4882 options. 4883 4884 `arm_neon_fp16_ok' 4885 ARM Target supports `-mfpu=neon-fp16 -mfloat-abi=softfp' or 4886 compatible options. Some multilibs may be incompatible with these 4887 options. 4888 4889 `arm_thumb1_ok' 4890 ARM target generates Thumb-1 code for `-mthumb'. 4891 4892 `arm_thumb2_ok' 4893 ARM target generates Thumb-2 code for `-mthumb'. 4894 4895 `arm_vfp_ok' 4896 ARM target supports `-mfpu=vfp -mfloat-abi=softfp'. Some 4897 multilibs may be incompatible with these options. 4898 4899 `arm_v8_vfp_ok' 4900 ARM target supports `-mfpu=fp-armv8 -mfloat-abi=softfp'. Some 4901 multilibs may be incompatible with these options. 4902 4903 `arm_v8_neon_ok' 4904 ARM target supports `-mfpu=neon-fp-armv8 -mfloat-abi=softfp'. 4905 Some multilibs may be incompatible with these options. 4906 4907 `arm_prefer_ldrd_strd' 4908 ARM target prefers `LDRD' and `STRD' instructions over `LDM' and 4909 `STM' instructions. 4910 4911 4912 7.2.3.7 MIPS-specific attributes 4913 ................................ 4914 4915 `mips64' 4916 MIPS target supports 64-bit instructions. 4917 4918 `nomips16' 4919 MIPS target does not produce MIPS16 code. 4920 4921 `mips16_attribute' 4922 MIPS target can generate MIPS16 code. 4923 4924 `mips_loongson' 4925 MIPS target is a Loongson-2E or -2F target using an ABI that 4926 supports the Loongson vector modes. 4927 4928 `mips_newabi_large_long_double' 4929 MIPS target supports `long double' larger than `double' when using 4930 the new ABI. 4931 4932 `mpaired_single' 4933 MIPS target supports `-mpaired-single'. 4934 4935 7.2.3.8 PowerPC-specific attributes 4936 ................................... 4937 4938 `dfp_hw' 4939 PowerPC target supports executing hardware DFP instructions. 4940 4941 `p8vector_hw' 4942 PowerPC target supports executing VSX instructions (ISA 2.07). 4943 4944 `powerpc64' 4945 Test system supports executing 64-bit instructions. 4946 4947 `powerpc_altivec' 4948 PowerPC target supports AltiVec. 4949 4950 `powerpc_altivec_ok' 4951 PowerPC target supports `-maltivec'. 4952 4953 `powerpc_eabi_ok' 4954 PowerPC target supports `-meabi'. 4955 4956 `powerpc_elfv2' 4957 PowerPC target supports `-mabi=elfv2'. 4958 4959 `powerpc_fprs' 4960 PowerPC target supports floating-point registers. 4961 4962 `powerpc_hard_double' 4963 PowerPC target supports hardware double-precision floating-point. 4964 4965 `powerpc_htm_ok' 4966 PowerPC target supports `-mhtm' 4967 4968 `powerpc_p8vector_ok' 4969 PowerPC target supports `-mpower8-vector' 4970 4971 `powerpc_ppu_ok' 4972 PowerPC target supports `-mcpu=cell'. 4973 4974 `powerpc_spe' 4975 PowerPC target supports PowerPC SPE. 4976 4977 `powerpc_spe_nocache' 4978 Including the options used to compile this particular test, the 4979 PowerPC target supports PowerPC SPE. 4980 4981 `powerpc_spu' 4982 PowerPC target supports PowerPC SPU. 4983 4984 `powerpc_vsx_ok' 4985 PowerPC target supports `-mvsx'. 4986 4987 `powerpc_405_nocache' 4988 Including the options used to compile this particular test, the 4989 PowerPC target supports PowerPC 405. 4990 4991 `ppc_recip_hw' 4992 PowerPC target supports executing reciprocal estimate instructions. 4993 4994 `spu_auto_overlay' 4995 SPU target has toolchain that supports automatic overlay 4996 generation. 4997 4998 `vmx_hw' 4999 PowerPC target supports executing AltiVec instructions. 5000 5001 `vsx_hw' 5002 PowerPC target supports executing VSX instructions (ISA 2.06). 5003 5004 7.2.3.9 Other hardware attributes 5005 ................................. 5006 5007 `avx' 5008 Target supports compiling `avx' instructions. 5009 5010 `avx_runtime' 5011 Target supports the execution of `avx' instructions. 5012 5013 `cell_hw' 5014 Test system can execute AltiVec and Cell PPU instructions. 5015 5016 `coldfire_fpu' 5017 Target uses a ColdFire FPU. 5018 5019 `hard_float' 5020 Target supports FPU instructions. 5021 5022 `sse' 5023 Target supports compiling `sse' instructions. 5024 5025 `sse_runtime' 5026 Target supports the execution of `sse' instructions. 5027 5028 `sse2' 5029 Target supports compiling `sse2' instructions. 5030 5031 `sse2_runtime' 5032 Target supports the execution of `sse2' instructions. 5033 5034 `sync_char_short' 5035 Target supports atomic operations on `char' and `short'. 5036 5037 `sync_int_long' 5038 Target supports atomic operations on `int' and `long'. 5039 5040 `ultrasparc_hw' 5041 Test environment appears to run executables on a simulator that 5042 accepts only `EM_SPARC' executables and chokes on `EM_SPARC32PLUS' 5043 or `EM_SPARCV9' executables. 5044 5045 `vect_cmdline_needed' 5046 Target requires a command line argument to enable a SIMD 5047 instruction set. 5048 5049 7.2.3.10 Environment attributes 5050 ............................... 5051 5052 `c' 5053 The language for the compiler under test is C. 5054 5055 `c++' 5056 The language for the compiler under test is C++. 5057 5058 `c99_runtime' 5059 Target provides a full C99 runtime. 5060 5061 `correct_iso_cpp_string_wchar_protos' 5062 Target `string.h' and `wchar.h' headers provide C++ required 5063 overloads for `strchr' etc. functions. 5064 5065 `dummy_wcsftime' 5066 Target uses a dummy `wcsftime' function that always returns zero. 5067 5068 `fd_truncate' 5069 Target can truncate a file from a file descriptor, as used by 5070 `libgfortran/io/unix.c:fd_truncate'; i.e. `ftruncate' or `chsize'. 5071 5072 `freestanding' 5073 Target is `freestanding' as defined in section 4 of the C99 5074 standard. Effectively, it is a target which supports no extra 5075 headers or libraries other than what is considered essential. 5076 5077 `init_priority' 5078 Target supports constructors with initialization priority 5079 arguments. 5080 5081 `inttypes_types' 5082 Target has the basic signed and unsigned types in `inttypes.h'. 5083 This is for tests that GCC's notions of these types agree with 5084 those in the header, as some systems have only `inttypes.h'. 5085 5086 `lax_strtofp' 5087 Target might have errors of a few ULP in string to floating-point 5088 conversion functions and overflow is not always detected correctly 5089 by those functions. 5090 5091 `mmap' 5092 Target supports `mmap'. 5093 5094 `newlib' 5095 Target supports Newlib. 5096 5097 `pow10' 5098 Target provides `pow10' function. 5099 5100 `pthread' 5101 Target can compile using `pthread.h' with no errors or warnings. 5102 5103 `pthread_h' 5104 Target has `pthread.h'. 5105 5106 `run_expensive_tests' 5107 Expensive testcases (usually those that consume excessive amounts 5108 of CPU time) should be run on this target. This can be enabled by 5109 setting the `GCC_TEST_RUN_EXPENSIVE' environment variable to a 5110 non-empty string. 5111 5112 `simulator' 5113 Test system runs executables on a simulator (i.e. slowly) rather 5114 than hardware (i.e. fast). 5115 5116 `stdint_types' 5117 Target has the basic signed and unsigned C types in `stdint.h'. 5118 This will be obsolete when GCC ensures a working `stdint.h' for 5119 all targets. 5120 5121 `trampolines' 5122 Target supports trampolines. 5123 5124 `uclibc' 5125 Target supports uClibc. 5126 5127 `unwrapped' 5128 Target does not use a status wrapper. 5129 5130 `vxworks_kernel' 5131 Target is a VxWorks kernel. 5132 5133 `vxworks_rtp' 5134 Target is a VxWorks RTP. 5135 5136 `wchar' 5137 Target supports wide characters. 5138 5139 7.2.3.11 Other attributes 5140 ......................... 5141 5142 `automatic_stack_alignment' 5143 Target supports automatic stack alignment. 5144 5145 `cxa_atexit' 5146 Target uses `__cxa_atexit'. 5147 5148 `default_packed' 5149 Target has packed layout of structure members by default. 5150 5151 `fgraphite' 5152 Target supports Graphite optimizations. 5153 5154 `fixed_point' 5155 Target supports fixed-point extension to C. 5156 5157 `fopenmp' 5158 Target supports OpenMP via `-fopenmp'. 5159 5160 `fpic' 5161 Target supports `-fpic' and `-fPIC'. 5162 5163 `freorder' 5164 Target supports `-freorder-blocks-and-partition'. 5165 5166 `fstack_protector' 5167 Target supports `-fstack-protector'. 5168 5169 `gas' 5170 Target uses GNU `as'. 5171 5172 `gc_sections' 5173 Target supports `--gc-sections'. 5174 5175 `gld' 5176 Target uses GNU `ld'. 5177 5178 `keeps_null_pointer_checks' 5179 Target keeps null pointer checks, either due to the use of 5180 `-fno-delete-null-pointer-checks' or hardwired into the target. 5181 5182 `lto' 5183 Compiler has been configured to support link-time optimization 5184 (LTO). 5185 5186 `naked_functions' 5187 Target supports the `naked' function attribute. 5188 5189 `named_sections' 5190 Target supports named sections. 5191 5192 `natural_alignment_32' 5193 Target uses natural alignment (aligned to type size) for types of 5194 32 bits or less. 5195 5196 `target_natural_alignment_64' 5197 Target uses natural alignment (aligned to type size) for types of 5198 64 bits or less. 5199 5200 `nonpic' 5201 Target does not generate PIC by default. 5202 5203 `pcc_bitfield_type_matters' 5204 Target defines `PCC_BITFIELD_TYPE_MATTERS'. 5205 5206 `pe_aligned_commons' 5207 Target supports `-mpe-aligned-commons'. 5208 5209 `pie' 5210 Target supports `-pie', `-fpie' and `-fPIE'. 5211 5212 `section_anchors' 5213 Target supports section anchors. 5214 5215 `short_enums' 5216 Target defaults to short enums. 5217 5218 `static' 5219 Target supports `-static'. 5220 5221 `static_libgfortran' 5222 Target supports statically linking `libgfortran'. 5223 5224 `string_merging' 5225 Target supports merging string constants at link time. 5226 5227 `ucn' 5228 Target supports compiling and assembling UCN. 5229 5230 `ucn_nocache' 5231 Including the options used to compile this particular test, the 5232 target supports compiling and assembling UCN. 5233 5234 `unaligned_stack' 5235 Target does not guarantee that its `STACK_BOUNDARY' is greater than 5236 or equal to the required vector alignment. 5237 5238 `vector_alignment_reachable' 5239 Vector alignment is reachable for types of 32 bits or less. 5240 5241 `vector_alignment_reachable_for_64bit' 5242 Vector alignment is reachable for types of 64 bits or less. 5243 5244 `wchar_t_char16_t_compatible' 5245 Target supports `wchar_t' that is compatible with `char16_t'. 5246 5247 `wchar_t_char32_t_compatible' 5248 Target supports `wchar_t' that is compatible with `char32_t'. 5249 5250 7.2.3.12 Local to tests in `gcc.target/i386' 5251 ............................................ 5252 5253 `3dnow' 5254 Target supports compiling `3dnow' instructions. 5255 5256 `aes' 5257 Target supports compiling `aes' instructions. 5258 5259 `fma4' 5260 Target supports compiling `fma4' instructions. 5261 5262 `ms_hook_prologue' 5263 Target supports attribute `ms_hook_prologue'. 5264 5265 `pclmul' 5266 Target supports compiling `pclmul' instructions. 5267 5268 `sse3' 5269 Target supports compiling `sse3' instructions. 5270 5271 `sse4' 5272 Target supports compiling `sse4' instructions. 5273 5274 `sse4a' 5275 Target supports compiling `sse4a' instructions. 5276 5277 `ssse3' 5278 Target supports compiling `ssse3' instructions. 5279 5280 `vaes' 5281 Target supports compiling `vaes' instructions. 5282 5283 `vpclmul' 5284 Target supports compiling `vpclmul' instructions. 5285 5286 `xop' 5287 Target supports compiling `xop' instructions. 5288 5289 7.2.3.13 Local to tests in `gcc.target/spu/ea' 5290 .............................................. 5291 5292 `ealib' 5293 Target `__ea' library functions are available. 5294 5295 7.2.3.14 Local to tests in `gcc.test-framework' 5296 ............................................... 5297 5298 `no' 5299 Always returns 0. 5300 5301 `yes' 5302 Always returns 1. 5303 5304 5305 File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5306 5307 7.2.4 Features for `dg-add-options' 5308 ----------------------------------- 5309 5310 The supported values of FEATURE for directive `dg-add-options' are: 5311 5312 `arm_neon' 5313 NEON support. Only ARM targets support this feature, and only then 5314 in certain modes; see the *note arm_neon_ok effective target 5315 keyword: arm_neon_ok. 5316 5317 `arm_neon_fp16' 5318 NEON and half-precision floating point support. Only ARM targets 5319 support this feature, and only then in certain modes; see the 5320 *note arm_neon_fp16_ok effective target keyword: arm_neon_ok. 5321 5322 `bind_pic_locally' 5323 Add the target-specific flags needed to enable functions to bind 5324 locally when using pic/PIC passes in the testsuite. 5325 5326 `c99_runtime' 5327 Add the target-specific flags needed to access the C99 runtime. 5328 5329 `ieee' 5330 Add the target-specific flags needed to enable full IEEE 5331 compliance mode. 5332 5333 `mips16_attribute' 5334 `mips16' function attributes. Only MIPS targets support this 5335 feature, and only then in certain modes. 5336 5337 `tls' 5338 Add the target-specific flags needed to use thread-local storage. 5339 5340 5341 File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 5342 5343 7.2.5 Variants of `dg-require-SUPPORT' 5344 -------------------------------------- 5345 5346 A few of the `dg-require' directives take arguments. 5347 5348 `dg-require-iconv CODESET' 5349 Skip the test if the target does not support iconv. CODESET is 5350 the codeset to convert to. 5351 5352 `dg-require-profiling PROFOPT' 5353 Skip the test if the target does not support profiling with option 5354 PROFOPT. 5355 5356 `dg-require-visibility VIS' 5357 Skip the test if the target does not support the `visibility' 5358 attribute. If VIS is `""', support for `visibility("hidden")' is 5359 checked, for `visibility("VIS")' otherwise. 5360 5361 The original `dg-require' directives were defined before there was 5362 support for effective-target keywords. The directives that do not take 5363 arguments could be replaced with effective-target keywords. 5364 5365 `dg-require-alias ""' 5366 Skip the test if the target does not support the `alias' attribute. 5367 5368 `dg-require-ascii-locale ""' 5369 Skip the test if the host does not support an ASCII locale. 5370 5371 `dg-require-compat-dfp ""' 5372 Skip this test unless both compilers in a `compat' testsuite 5373 support decimal floating point. 5374 5375 `dg-require-cxa-atexit ""' 5376 Skip the test if the target does not support `__cxa_atexit'. This 5377 is equivalent to `dg-require-effective-target cxa_atexit'. 5378 5379 `dg-require-dll ""' 5380 Skip the test if the target does not support DLL attributes. 5381 5382 `dg-require-fork ""' 5383 Skip the test if the target does not support `fork'. 5384 5385 `dg-require-gc-sections ""' 5386 Skip the test if the target's linker does not support the 5387 `--gc-sections' flags. This is equivalent to 5388 `dg-require-effective-target gc-sections'. 5389 5390 `dg-require-host-local ""' 5391 Skip the test if the host is remote, rather than the same as the 5392 build system. Some tests are incompatible with DejaGnu's handling 5393 of remote hosts, which involves copying the source file to the 5394 host and compiling it with a relative path and "`-o a.out'". 5395 5396 `dg-require-mkfifo ""' 5397 Skip the test if the target does not support `mkfifo'. 5398 5399 `dg-require-named-sections ""' 5400 Skip the test is the target does not support named sections. This 5401 is equivalent to `dg-require-effective-target named_sections'. 5402 5403 `dg-require-weak ""' 5404 Skip the test if the target does not support weak symbols. 5405 5406 `dg-require-weak-override ""' 5407 Skip the test if the target does not support overriding weak 5408 symbols. 5409 5410 5411 File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 5412 5413 7.2.6 Commands for use in `dg-final' 5414 ------------------------------------ 5415 5416 The GCC testsuite defines the following directives to be used within 5417 `dg-final'. 5418 5419 7.2.6.1 Scan a particular file 5420 .............................. 5421 5422 `scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 5423 Passes if REGEXP matches text in FILENAME. 5424 5425 `scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 5426 Passes if REGEXP does not match text in FILENAME. 5427 5428 `scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 5429 Passes if REGEXP matches in Fortran module MODULE. 5430 5431 7.2.6.2 Scan the assembly output 5432 ................................ 5433 5434 `scan-assembler REGEX [{ target/xfail SELECTOR }]' 5435 Passes if REGEX matches text in the test's assembler output. 5436 5437 `scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 5438 Passes if REGEX does not match text in the test's assembler output. 5439 5440 `scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 5441 Passes if REGEX is matched exactly NUM times in the test's 5442 assembler output. 5443 5444 `scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 5445 Passes if REGEX matches text in the test's demangled assembler 5446 output. 5447 5448 `scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 5449 Passes if REGEX does not match text in the test's demangled 5450 assembler output. 5451 5452 `scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 5453 Passes if SYMBOL is defined as a hidden symbol in the test's 5454 assembly output. 5455 5456 `scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 5457 Passes if SYMBOL is not defined as a hidden symbol in the test's 5458 assembly output. 5459 5460 7.2.6.3 Scan optimization dump files 5461 .................................... 5462 5463 These commands are available for KIND of `tree', `rtl', and `ipa'. 5464 5465 `scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 5466 Passes if REGEX matches text in the dump file with suffix SUFFIX. 5467 5468 `scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5469 Passes if REGEX does not match text in the dump file with suffix 5470 SUFFIX. 5471 5472 `scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 5473 Passes if REGEX is found exactly NUM times in the dump file with 5474 suffix SUFFIX. 5475 5476 `scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 5477 Passes if REGEX matches demangled text in the dump file with 5478 suffix SUFFIX. 5479 5480 `scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5481 Passes if REGEX does not match demangled text in the dump file with 5482 suffix SUFFIX. 5483 5484 7.2.6.4 Verify that an output files exists or not 5485 ................................................. 5486 5487 `output-exists [{ target/xfail SELECTOR }]' 5488 Passes if compiler output file exists. 5489 5490 `output-exists-not [{ target/xfail SELECTOR }]' 5491 Passes if compiler output file does not exist. 5492 5493 7.2.6.5 Check for LTO tests 5494 ........................... 5495 5496 `scan-symbol REGEXP [{ target/xfail SELECTOR }]' 5497 Passes if the pattern is present in the final executable. 5498 5499 7.2.6.6 Checks for `gcov' tests 5500 ............................... 5501 5502 `run-gcov SOURCEFILE' 5503 Check line counts in `gcov' tests. 5504 5505 `run-gcov [branches] [calls] { OPTS SOURCEFILE }' 5506 Check branch and/or call counts, in addition to line counts, in 5507 `gcov' tests. 5508 5509 7.2.6.7 Clean up generated test files 5510 ..................................... 5511 5512 `cleanup-coverage-files' 5513 Removes coverage data files generated for this test. 5514 5515 `cleanup-ipa-dump SUFFIX' 5516 Removes IPA dump files generated for this test. 5517 5518 `cleanup-modules "LIST-OF-EXTRA-MODULES"' 5519 Removes Fortran module files generated for this test, excluding the 5520 module names listed in keep-modules. Cleaning up module files is 5521 usually done automatically by the testsuite by looking at the 5522 source files and removing the modules after the test has been 5523 executed. 5524 module MoD1 5525 end module MoD1 5526 module Mod2 5527 end module Mod2 5528 module moD3 5529 end module moD3 5530 module mod4 5531 end module mod4 5532 ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant 5533 ! { dg-final { keep-modules "mod3 mod4" } } 5534 5535 `keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"' 5536 Whitespace separated list of module names that should not be 5537 deleted by cleanup-modules. If the list of modules is empty, all 5538 modules defined in this file are kept. 5539 module maybe_unneeded 5540 end module maybe_unneeded 5541 module keep1 5542 end module keep1 5543 module keep2 5544 end module keep2 5545 ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two 5546 ! { dg-final { keep-modules "" } } ! keep all 5547 5548 `cleanup-profile-file' 5549 Removes profiling files generated for this test. 5550 5551 `cleanup-repo-files' 5552 Removes files generated for this test for `-frepo'. 5553 5554 `cleanup-rtl-dump SUFFIX' 5555 Removes RTL dump files generated for this test. 5556 5557 `cleanup-saved-temps' 5558 Removes files for the current test which were kept for 5559 `-save-temps'. 5560 5561 `cleanup-tree-dump SUFFIX' 5562 Removes tree dump files matching SUFFIX which were generated for 5563 this test. 5564 5565 5566 File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 5567 5568 7.3 Ada Language Testsuites 5569 =========================== 5570 5571 The Ada testsuite includes executable tests from the ACATS testsuite, 5572 publicly available at `http://www.ada-auth.org/acats.html'. 5573 5574 These tests are integrated in the GCC testsuite in the `ada/acats' 5575 directory, and enabled automatically when running `make check', assuming 5576 the Ada language has been enabled when configuring GCC. 5577 5578 You can also run the Ada testsuite independently, using `make 5579 check-ada', or run a subset of the tests by specifying which chapter to 5580 run, e.g.: 5581 5582 $ make check-ada CHAPTERS="c3 c9" 5583 5584 The tests are organized by directory, each directory corresponding to 5585 a chapter of the Ada Reference Manual. So for example, `c9' corresponds 5586 to chapter 9, which deals with tasking features of the language. 5587 5588 There is also an extra chapter called `gcc' containing a template for 5589 creating new executable tests, although this is deprecated in favor of 5590 the `gnat.dg' testsuite. 5591 5592 The tests are run using two `sh' scripts: `run_acats' and 5593 `run_all.sh'. To run the tests using a simulator or a cross target, 5594 see the small customization section at the top of `run_all.sh'. 5595 5596 These tests are run using the build tree: they can be run without doing 5597 a `make install'. 5598 5599 5600 File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites 5601 5602 7.4 C Language Testsuites 5603 ========================= 5604 5605 GCC contains the following C language testsuites, in the 5606 `gcc/testsuite' directory: 5607 5608 `gcc.dg' 5609 This contains tests of particular features of the C compiler, 5610 using the more modern `dg' harness. Correctness tests for various 5611 compiler features should go here if possible. 5612 5613 Magic comments determine whether the file is preprocessed, 5614 compiled, linked or run. In these tests, error and warning 5615 message texts are compared against expected texts or regular 5616 expressions given in comments. These tests are run with the 5617 options `-ansi -pedantic' unless other options are given in the 5618 test. Except as noted below they are not run with multiple 5619 optimization options. 5620 5621 `gcc.dg/compat' 5622 This subdirectory contains tests for binary compatibility using 5623 `lib/compat.exp', which in turn uses the language-independent 5624 support (*note Support for testing binary compatibility: compat 5625 Testing.). 5626 5627 `gcc.dg/cpp' 5628 This subdirectory contains tests of the preprocessor. 5629 5630 `gcc.dg/debug' 5631 This subdirectory contains tests for debug formats. Tests in this 5632 subdirectory are run for each debug format that the compiler 5633 supports. 5634 5635 `gcc.dg/format' 5636 This subdirectory contains tests of the `-Wformat' format 5637 checking. Tests in this directory are run with and without 5638 `-DWIDE'. 5639 5640 `gcc.dg/noncompile' 5641 This subdirectory contains tests of code that should not compile 5642 and does not need any special compilation options. They are run 5643 with multiple optimization options, since sometimes invalid code 5644 crashes the compiler with optimization. 5645 5646 `gcc.dg/special' 5647 FIXME: describe this. 5648 5649 `gcc.c-torture' 5650 This contains particular code fragments which have historically 5651 broken easily. These tests are run with multiple optimization 5652 options, so tests for features which only break at some 5653 optimization levels belong here. This also contains tests to 5654 check that certain optimizations occur. It might be worthwhile to 5655 separate the correctness tests cleanly from the code quality 5656 tests, but it hasn't been done yet. 5657 5658 `gcc.c-torture/compat' 5659 FIXME: describe this. 5660 5661 This directory should probably not be used for new tests. 5662 5663 `gcc.c-torture/compile' 5664 This testsuite contains test cases that should compile, but do not 5665 need to link or run. These test cases are compiled with several 5666 different combinations of optimization options. All warnings are 5667 disabled for these test cases, so this directory is not suitable if 5668 you wish to test for the presence or absence of compiler warnings. 5669 While special options can be set, and tests disabled on specific 5670 platforms, by the use of `.x' files, mostly these test cases 5671 should not contain platform dependencies. FIXME: discuss how 5672 defines such as `NO_LABEL_VALUES' and `STACK_SIZE' are used. 5673 5674 `gcc.c-torture/execute' 5675 This testsuite contains test cases that should compile, link and 5676 run; otherwise the same comments as for `gcc.c-torture/compile' 5677 apply. 5678 5679 `gcc.c-torture/execute/ieee' 5680 This contains tests which are specific to IEEE floating point. 5681 5682 `gcc.c-torture/unsorted' 5683 FIXME: describe this. 5684 5685 This directory should probably not be used for new tests. 5686 5687 `gcc.misc-tests' 5688 This directory contains C tests that require special handling. 5689 Some of these tests have individual expect files, and others share 5690 special-purpose expect files: 5691 5692 ``bprob*.c'' 5693 Test `-fbranch-probabilities' using 5694 `gcc.misc-tests/bprob.exp', which in turn uses the generic, 5695 language-independent framework (*note Support for testing 5696 profile-directed optimizations: profopt Testing.). 5697 5698 ``gcov*.c'' 5699 Test `gcov' output using `gcov.exp', which in turn uses the 5700 language-independent support (*note Support for testing gcov: 5701 gcov Testing.). 5702 5703 ``i386-pf-*.c'' 5704 Test i386-specific support for data prefetch using 5705 `i386-prefetch.exp'. 5706 5707 `gcc.test-framework' 5708 5709 ``dg-*.c'' 5710 Test the testsuite itself using 5711 `gcc.test-framework/test-framework.exp'. 5712 5713 5714 FIXME: merge in `testsuite/README.gcc' and discuss the format of test 5715 cases and magic comments more. 5716 5717 5718 File: gccint.info, Node: libgcj Tests, Next: LTO Testing, Prev: C Tests, Up: Testsuites 5719 5720 7.5 The Java library testsuites. 5721 ================================ 5722 5723 Runtime tests are executed via `make check' in the 5724 `TARGET/libjava/testsuite' directory in the build tree. Additional 5725 runtime tests can be checked into this testsuite. 5726 5727 Regression testing of the core packages in libgcj is also covered by 5728 the Mauve testsuite. The Mauve Project develops tests for the Java 5729 Class Libraries. These tests are run as part of libgcj testing by 5730 placing the Mauve tree within the libjava testsuite sources at 5731 `libjava/testsuite/libjava.mauve/mauve', or by specifying the location 5732 of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'. 5733 5734 To detect regressions, a mechanism in `mauve.exp' compares the 5735 failures for a test run against the list of expected failures in 5736 `libjava/testsuite/libjava.mauve/xfails' from the source hierarchy. 5737 Update this file when adding new failing tests to Mauve, or when fixing 5738 bugs in libgcj that had caused Mauve test failures. 5739 5740 We encourage developers to contribute test cases to Mauve. 5741 5742 5743 File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: libgcj Tests, Up: Testsuites 5744 5745 7.6 Support for testing link-time optimizations 5746 =============================================== 5747 5748 Tests for link-time optimizations usually require multiple source files 5749 that are compiled separately, perhaps with different sets of options. 5750 There are several special-purpose test directives used for these tests. 5751 5752 `{ dg-lto-do DO-WHAT-KEYWORD }' 5753 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 5754 is executed. It is one of: 5755 5756 `assemble' 5757 Compile with `-c' to produce a relocatable object file. 5758 5759 `link' 5760 Compile, assemble, and link to produce an executable file. 5761 5762 `run' 5763 Produce and run an executable file, which is expected to 5764 return an exit code of 0. 5765 5766 The default is `assemble'. That can be overridden for a set of 5767 tests by redefining `dg-do-what-default' within the `.exp' file 5768 for those tests. 5769 5770 Unlike `dg-do', `dg-lto-do' does not support an optional `target' 5771 or `xfail' list. Use `dg-skip-if', `dg-xfail-if', or 5772 `dg-xfail-run-if'. 5773 5774 `{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 5775 This directive provides a list of one or more sets of compiler 5776 options to override LTO_OPTIONS. Each test will be compiled and 5777 run with each of these sets of options. 5778 5779 `{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}' 5780 This directive adds OPTIONS to the linker options used. 5781 5782 `{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}' 5783 This directive removes OPTIONS from the set of linker options used. 5784 5785 5786 File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 5787 5788 7.7 Support for testing `gcov' 5789 ============================== 5790 5791 Language-independent support for testing `gcov', and for checking that 5792 branch profiling produces expected values, is provided by the expect 5793 file `lib/gcov.exp'. `gcov' tests also rely on procedures in 5794 `lib/gcc-dg.exp' to compile and run the test program. A typical `gcov' 5795 test contains the following DejaGnu commands within comments: 5796 5797 { dg-options "-fprofile-arcs -ftest-coverage" } 5798 { dg-do run { target native } } 5799 { dg-final { run-gcov sourcefile } } 5800 5801 Checks of `gcov' output can include line counts, branch percentages, 5802 and call return percentages. All of these checks are requested via 5803 commands that appear in comments in the test's source file. Commands 5804 to check line counts are processed by default. Commands to check 5805 branch percentages and call return percentages are processed if the 5806 `run-gcov' command has arguments `branches' or `calls', respectively. 5807 For example, the following specifies checking both, as well as passing 5808 `-b' to `gcov': 5809 5810 { dg-final { run-gcov branches calls { -b sourcefile } } } 5811 5812 A line count command appears within a comment on the source line that 5813 is expected to get the specified count and has the form `count(CNT)'. 5814 A test should only check line counts for lines that will get the same 5815 count for any architecture. 5816 5817 Commands to check branch percentages (`branch') and call return 5818 percentages (`returns') are very similar to each other. A beginning 5819 command appears on or before the first of a range of lines that will 5820 report the percentage, and the ending command follows that range of 5821 lines. The beginning command can include a list of percentages, all of 5822 which are expected to be found within the range. A range is terminated 5823 by the next command of the same kind. A command `branch(end)' or 5824 `returns(end)' marks the end of a range without starting a new one. 5825 For example: 5826 5827 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 5828 /* branch(end) */ 5829 foo (i, j); 5830 5831 For a call return percentage, the value specified is the percentage of 5832 calls reported to return. For a branch percentage, the value is either 5833 the expected percentage or 100 minus that value, since the direction of 5834 a branch can differ depending on the target or the optimization level. 5835 5836 Not all branches and calls need to be checked. A test should not 5837 check for branches that might be optimized away or replaced with 5838 predicated instructions. Don't check for calls inserted by the 5839 compiler or ones that might be inlined or optimized away. 5840 5841 A single test can check for combinations of line counts, branch 5842 percentages, and call return percentages. The command to check a line 5843 count must appear on the line that will report that count, but commands 5844 to check branch percentages and call return percentages can bracket the 5845 lines that report them. 5846 5847 5848 File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 5849 5850 7.8 Support for testing profile-directed optimizations 5851 ====================================================== 5852 5853 The file `profopt.exp' provides language-independent support for 5854 checking correct execution of a test built with profile-directed 5855 optimization. This testing requires that a test program be built and 5856 executed twice. The first time it is compiled to generate profile 5857 data, and the second time it is compiled to use the data that was 5858 generated during the first execution. The second execution is to 5859 verify that the test produces the expected results. 5860 5861 To check that the optimization actually generated better code, a test 5862 can be built and run a third time with normal optimizations to verify 5863 that the performance is better with the profile-directed optimizations. 5864 `profopt.exp' has the beginnings of this kind of support. 5865 5866 `profopt.exp' provides generic support for profile-directed 5867 optimizations. Each set of tests that uses it provides information 5868 about a specific optimization: 5869 5870 `tool' 5871 tool being tested, e.g., `gcc' 5872 5873 `profile_option' 5874 options used to generate profile data 5875 5876 `feedback_option' 5877 options used to optimize using that profile data 5878 5879 `prof_ext' 5880 suffix of profile data files 5881 5882 `PROFOPT_OPTIONS' 5883 list of options with which to run each test, similar to the lists 5884 for torture tests 5885 5886 `{ dg-final-generate { LOCAL-DIRECTIVE } }' 5887 This directive is similar to `dg-final', but the LOCAL-DIRECTIVE 5888 is run after the generation of profile data. 5889 5890 `{ dg-final-use { LOCAL-DIRECTIVE } }' 5891 The LOCAL-DIRECTIVE is run after the profile data have been used. 5892 5893 5894 File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 5895 5896 7.9 Support for testing binary compatibility 5897 ============================================ 5898 5899 The file `compat.exp' provides language-independent support for binary 5900 compatibility testing. It supports testing interoperability of two 5901 compilers that follow the same ABI, or of multiple sets of compiler 5902 options that should not affect binary compatibility. It is intended to 5903 be used for testsuites that complement ABI testsuites. 5904 5905 A test supported by this framework has three parts, each in a separate 5906 source file: a main program and two pieces that interact with each 5907 other to split up the functionality being tested. 5908 5909 `TESTNAME_main.SUFFIX' 5910 Contains the main program, which calls a function in file 5911 `TESTNAME_x.SUFFIX'. 5912 5913 `TESTNAME_x.SUFFIX' 5914 Contains at least one call to a function in `TESTNAME_y.SUFFIX'. 5915 5916 `TESTNAME_y.SUFFIX' 5917 Shares data with, or gets arguments from, `TESTNAME_x.SUFFIX'. 5918 5919 Within each test, the main program and one functional piece are 5920 compiled by the GCC under test. The other piece can be compiled by an 5921 alternate compiler. If no alternate compiler is specified, then all 5922 three source files are all compiled by the GCC under test. You can 5923 specify pairs of sets of compiler options. The first element of such a 5924 pair specifies options used with the GCC under test, and the second 5925 element of the pair specifies options used with the alternate compiler. 5926 Each test is compiled with each pair of options. 5927 5928 `compat.exp' defines default pairs of compiler options. These can be 5929 overridden by defining the environment variable `COMPAT_OPTIONS' as: 5930 5931 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 5932 ...[list {TSTN} {ALTN}]]" 5933 5934 where TSTI and ALTI are lists of options, with TSTI used by the 5935 compiler under test and ALTI used by the alternate compiler. For 5936 example, with `[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 5937 the test is first built with `-g -O0' by the compiler under test and 5938 with `-O3' by the alternate compiler. The test is built a second time 5939 using `-fpic' by the compiler under test and `-fPIC -O2' by the 5940 alternate compiler. 5941 5942 An alternate compiler is specified by defining an environment variable 5943 to be the full pathname of an installed compiler; for C define 5944 `ALT_CC_UNDER_TEST', and for C++ define `ALT_CXX_UNDER_TEST'. These 5945 will be written to the `site.exp' file used by DejaGnu. The default is 5946 to build each test with the compiler under test using the first of each 5947 pair of compiler options from `COMPAT_OPTIONS'. When 5948 `ALT_CC_UNDER_TEST' or `ALT_CXX_UNDER_TEST' is `same', each test is 5949 built using the compiler under test but with combinations of the 5950 options from `COMPAT_OPTIONS'. 5951 5952 To run only the C++ compatibility suite using the compiler under test 5953 and another version of GCC using specific compiler options, do the 5954 following from `OBJDIR/gcc': 5955 5956 rm site.exp 5957 make -k \ 5958 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 5959 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 5960 check-c++ \ 5961 RUNTESTFLAGS="compat.exp" 5962 5963 A test that fails when the source files are compiled with different 5964 compilers, but passes when the files are compiled with the same 5965 compiler, demonstrates incompatibility of the generated code or runtime 5966 support. A test that fails for the alternate compiler but passes for 5967 the compiler under test probably tests for a bug that was fixed in the 5968 compiler under test but is present in the alternate compiler. 5969 5970 The binary compatibility tests support a small number of test framework 5971 commands that appear within comments in a test file. 5972 5973 `dg-require-*' 5974 These commands can be used in `TESTNAME_main.SUFFIX' to skip the 5975 test if specific support is not available on the target. 5976 5977 `dg-options' 5978 The specified options are used for compiling this particular source 5979 file, appended to the options from `COMPAT_OPTIONS'. When this 5980 command appears in `TESTNAME_main.SUFFIX' the options are also 5981 used to link the test program. 5982 5983 `dg-xfail-if' 5984 This command can be used in a secondary source file to specify that 5985 compilation is expected to fail for particular options on 5986 particular targets. 5987 5988 5989 File: gccint.info, Node: Torture Tests, Prev: compat Testing, Up: Testsuites 5990 5991 7.10 Support for torture testing using multiple options 5992 ======================================================= 5993 5994 Throughout the compiler testsuite there are several directories whose 5995 tests are run multiple times, each with a different set of options. 5996 These are known as torture tests. `lib/torture-options.exp' defines 5997 procedures to set up these lists: 5998 5999 `torture-init' 6000 Initialize use of torture lists. 6001 6002 `set-torture-options' 6003 Set lists of torture options to use for tests with and without 6004 loops. Optionally combine a set of torture options with a set of 6005 other options, as is done with Objective-C runtime options. 6006 6007 `torture-finish' 6008 Finalize use of torture lists. 6009 6010 The `.exp' file for a set of tests that use torture options must 6011 include calls to these three procedures if: 6012 6013 * It calls `gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 6014 6015 * It calls ${TOOL}`-torture' or ${TOOL}`-torture-execute', where 6016 TOOL is `c', `fortran', or `objc'. 6017 6018 * It calls `dg-pch'. 6019 6020 It is not necessary for a `.exp' file that calls `gcc-dg-runtest' to 6021 call the torture procedures if the tests should use the list in 6022 DG_TORTURE_OPTIONS defined in `gcc-dg.exp'. 6023 6024 Most uses of torture options can override the default lists by defining 6025 TORTURE_OPTIONS or add to the default list by defining 6026 ADDITIONAL_TORTURE_OPTIONS. Define these in a `.dejagnurc' file or add 6027 them to the `site.exp' file; for example 6028 6029 set ADDITIONAL_TORTURE_OPTIONS [list \ 6030 { -O2 -ftree-loop-linear } \ 6031 { -O2 -fpeel-loops } ] 6032 6033 6034 File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 6035 6036 8 Option specification files 6037 **************************** 6038 6039 Most GCC command-line options are described by special option 6040 definition files, the names of which conventionally end in `.opt'. 6041 This chapter describes the format of these files. 6042 6043 * Menu: 6044 6045 * Option file format:: The general layout of the files 6046 * Option properties:: Supported option properties 6047 6048 6049 File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 6050 6051 8.1 Option file format 6052 ====================== 6053 6054 Option files are a simple list of records in which each field occupies 6055 its own line and in which the records themselves are separated by blank 6056 lines. Comments may appear on their own line anywhere within the file 6057 and are preceded by semicolons. Whitespace is allowed before the 6058 semicolon. 6059 6060 The files can contain the following types of record: 6061 6062 * A language definition record. These records have two fields: the 6063 string `Language' and the name of the language. Once a language 6064 has been declared in this way, it can be used as an option 6065 property. *Note Option properties::. 6066 6067 * A target specific save record to save additional information. These 6068 records have two fields: the string `TargetSave', and a 6069 declaration type to go in the `cl_target_option' structure. 6070 6071 * A variable record to define a variable used to store option 6072 information. These records have two fields: the string 6073 `Variable', and a declaration of the type and name of the 6074 variable, optionally with an initializer (but without any trailing 6075 `;'). These records may be used for variables used for many 6076 options where declaring the initializer in a single option 6077 definition record, or duplicating it in many records, would be 6078 inappropriate, or for variables set in option handlers rather than 6079 referenced by `Var' properties. 6080 6081 * A variable record to define a variable used to store option 6082 information. These records have two fields: the string 6083 `TargetVariable', and a declaration of the type and name of the 6084 variable, optionally with an initializer (but without any trailing 6085 `;'). `TargetVariable' is a combination of `Variable' and 6086 `TargetSave' records in that the variable is defined in the 6087 `gcc_options' structure, but these variables are also stored in 6088 the `cl_target_option' structure. The variables are saved in the 6089 target save code and restored in the target restore code. 6090 6091 * A variable record to record any additional files that the 6092 `options.h' file should include. This is useful to provide 6093 enumeration or structure definitions needed for target variables. 6094 These records have two fields: the string `HeaderInclude' and the 6095 name of the include file. 6096 6097 * A variable record to record any additional files that the 6098 `options.c' or `options-save.c' file should include. This is 6099 useful to provide inline functions needed for target variables 6100 and/or `#ifdef' sequences to properly set up the initialization. 6101 These records have two fields: the string `SourceInclude' and the 6102 name of the include file. 6103 6104 * An enumeration record to define a set of strings that may be used 6105 as arguments to an option or options. These records have three 6106 fields: the string `Enum', a space-separated list of properties 6107 and help text used to describe the set of strings in `--help' 6108 output. Properties use the same format as option properties; the 6109 following are valid: 6110 `Name(NAME)' 6111 This property is required; NAME must be a name (suitable for 6112 use in C identifiers) used to identify the set of strings in 6113 `Enum' option properties. 6114 6115 `Type(TYPE)' 6116 This property is required; TYPE is the C type for variables 6117 set by options using this enumeration together with `Var'. 6118 6119 `UnknownError(MESSAGE)' 6120 The message MESSAGE will be used as an error message if the 6121 argument is invalid; for enumerations without `UnknownError', 6122 a generic error message is used. MESSAGE should contain a 6123 single `%qs' format, which will be used to format the invalid 6124 argument. 6125 6126 * An enumeration value record to define one of the strings in a set 6127 given in an `Enum' record. These records have two fields: the 6128 string `EnumValue' and a space-separated list of properties. 6129 Properties use the same format as option properties; the following 6130 are valid: 6131 `Enum(NAME)' 6132 This property is required; NAME says which `Enum' record this 6133 `EnumValue' record corresponds to. 6134 6135 `String(STRING)' 6136 This property is required; STRING is the string option 6137 argument being described by this record. 6138 6139 `Value(VALUE)' 6140 This property is required; it says what value (representable 6141 as `int') should be used for the given string. 6142 6143 `Canonical' 6144 This property is optional. If present, it says the present 6145 string is the canonical one among all those with the given 6146 value. Other strings yielding that value will be mapped to 6147 this one so specs do not need to handle them. 6148 6149 `DriverOnly' 6150 This property is optional. If present, the present string 6151 will only be accepted by the driver. This is used for cases 6152 such as `-march=native' that are processed by the driver so 6153 that `gcc -v' shows how the options chosen depended on the 6154 system on which the compiler was run. 6155 6156 * An option definition record. These records have the following 6157 fields: 6158 1. the name of the option, with the leading "-" removed 6159 6160 2. a space-separated list of option properties (*note Option 6161 properties::) 6162 6163 3. the help text to use for `--help' (omitted if the second field 6164 contains the `Undocumented' property). 6165 6166 By default, all options beginning with "f", "W" or "m" are 6167 implicitly assumed to take a "no-" form. This form should not be 6168 listed separately. If an option beginning with one of these 6169 letters does not have a "no-" form, you can use the 6170 `RejectNegative' property to reject it. 6171 6172 The help text is automatically line-wrapped before being displayed. 6173 Normally the name of the option is printed on the left-hand side of 6174 the output and the help text is printed on the right. However, if 6175 the help text contains a tab character, the text to the left of 6176 the tab is used instead of the option's name and the text to the 6177 right of the tab forms the help text. This allows you to 6178 elaborate on what type of argument the option takes. 6179 6180 * A target mask record. These records have one field of the form 6181 `Mask(X)'. The options-processing script will automatically 6182 allocate a bit in `target_flags' (*note Run-time Target::) for 6183 each mask name X and set the macro `MASK_X' to the appropriate 6184 bitmask. It will also declare a `TARGET_X' macro that has the 6185 value 1 when bit `MASK_X' is set and 0 otherwise. 6186 6187 They are primarily intended to declare target masks that are not 6188 associated with user options, either because these masks represent 6189 internal switches or because the options are not available on all 6190 configurations and yet the masks always need to be defined. 6191 6192 6193 File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 6194 6195 8.2 Option properties 6196 ===================== 6197 6198 The second field of an option record can specify any of the following 6199 properties. When an option takes an argument, it is enclosed in 6200 parentheses following the option property name. The parser that 6201 handles option files is quite simplistic, and will be tricked by any 6202 nested parentheses within the argument text itself; in this case, the 6203 entire option argument can be wrapped in curly braces within the 6204 parentheses to demarcate it, e.g.: 6205 6206 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 6207 6208 `Common' 6209 The option is available for all languages and targets. 6210 6211 `Target' 6212 The option is available for all languages but is target-specific. 6213 6214 `Driver' 6215 The option is handled by the compiler driver using code not shared 6216 with the compilers proper (`cc1' etc.). 6217 6218 `LANGUAGE' 6219 The option is available when compiling for the given language. 6220 6221 It is possible to specify several different languages for the same 6222 option. Each LANGUAGE must have been declared by an earlier 6223 `Language' record. *Note Option file format::. 6224 6225 `RejectDriver' 6226 The option is only handled by the compilers proper (`cc1' etc.) 6227 and should not be accepted by the driver. 6228 6229 `RejectNegative' 6230 The option does not have a "no-" form. All options beginning with 6231 "f", "W" or "m" are assumed to have a "no-" form unless this 6232 property is used. 6233 6234 `Negative(OTHERNAME)' 6235 The option will turn off another option OTHERNAME, which is the 6236 option name with the leading "-" removed. This chain action will 6237 propagate through the `Negative' property of the option to be 6238 turned off. 6239 6240 As a consequence, if you have a group of mutually-exclusive 6241 options, their `Negative' properties should form a circular chain. 6242 For example, if options `-A', `-B' and `-C' are mutually 6243 exclusive, their respective `Negative' properties should be 6244 `Negative(B)', `Negative(C)' and `Negative(A)'. 6245 6246 `Joined' 6247 `Separate' 6248 The option takes a mandatory argument. `Joined' indicates that 6249 the option and argument can be included in the same `argv' entry 6250 (as with `-mflush-func=NAME', for example). `Separate' indicates 6251 that the option and argument can be separate `argv' entries (as 6252 with `-o'). An option is allowed to have both of these properties. 6253 6254 `JoinedOrMissing' 6255 The option takes an optional argument. If the argument is given, 6256 it will be part of the same `argv' entry as the option itself. 6257 6258 This property cannot be used alongside `Joined' or `Separate'. 6259 6260 `MissingArgError(MESSAGE)' 6261 For an option marked `Joined' or `Separate', the message MESSAGE 6262 will be used as an error message if the mandatory argument is 6263 missing; for options without `MissingArgError', a generic error 6264 message is used. MESSAGE should contain a single `%qs' format, 6265 which will be used to format the name of the option passed. 6266 6267 `Args(N)' 6268 For an option marked `Separate', indicate that it takes N 6269 arguments. The default is 1. 6270 6271 `UInteger' 6272 The option's argument is a non-negative integer. The option parser 6273 will check and convert the argument before passing it to the 6274 relevant option handler. `UInteger' should also be used on 6275 options like `-falign-loops' where both `-falign-loops' and 6276 `-falign-loops'=N are supported to make sure the saved options are 6277 given a full integer. 6278 6279 `ToLower' 6280 The option's argument should be converted to lowercase as part of 6281 putting it in canonical form, and before comparing with the strings 6282 indicated by any `Enum' property. 6283 6284 `NoDriverArg' 6285 For an option marked `Separate', the option only takes an argument 6286 in the compiler proper, not in the driver. This is for 6287 compatibility with existing options that are used both directly and 6288 via `-Wp,'; new options should not have this property. 6289 6290 `Var(VAR)' 6291 The state of this option should be stored in variable VAR 6292 (actually a macro for `global_options.x_VAR'). The way that the 6293 state is stored depends on the type of option: 6294 6295 * If the option uses the `Mask' or `InverseMask' properties, 6296 VAR is the integer variable that contains the mask. 6297 6298 * If the option is a normal on/off switch, VAR is an integer 6299 variable that is nonzero when the option is enabled. The 6300 options parser will set the variable to 1 when the positive 6301 form of the option is used and 0 when the "no-" form is used. 6302 6303 * If the option takes an argument and has the `UInteger' 6304 property, VAR is an integer variable that stores the value of 6305 the argument. 6306 6307 * If the option takes an argument and has the `Enum' property, 6308 VAR is a variable (type given in the `Type' property of the 6309 `Enum' record whose `Name' property has the same argument as 6310 the `Enum' property of this option) that stores the value of 6311 the argument. 6312 6313 * If the option has the `Defer' property, VAR is a pointer to a 6314 `VEC(cl_deferred_option,heap)' that stores the option for 6315 later processing. (VAR is declared with type `void *' and 6316 needs to be cast to `VEC(cl_deferred_option,heap)' before 6317 use.) 6318 6319 * Otherwise, if the option takes an argument, VAR is a pointer 6320 to the argument string. The pointer will be null if the 6321 argument is optional and wasn't given. 6322 6323 The option-processing script will usually zero-initialize VAR. 6324 You can modify this behavior using `Init'. 6325 6326 `Var(VAR, SET)' 6327 The option controls an integer variable VAR and is active when VAR 6328 equals SET. The option parser will set VAR to SET when the 6329 positive form of the option is used and `!SET' when the "no-" form 6330 is used. 6331 6332 VAR is declared in the same way as for the single-argument form 6333 described above. 6334 6335 `Init(VALUE)' 6336 The variable specified by the `Var' property should be statically 6337 initialized to VALUE. If more than one option using the same 6338 variable specifies `Init', all must specify the same initializer. 6339 6340 `Mask(NAME)' 6341 The option is associated with a bit in the `target_flags' variable 6342 (*note Run-time Target::) and is active when that bit is set. You 6343 may also specify `Var' to select a variable other than 6344 `target_flags'. 6345 6346 The options-processing script will automatically allocate a unique 6347 bit for the option. If the option is attached to `target_flags', 6348 the script will set the macro `MASK_NAME' to the appropriate 6349 bitmask. It will also declare a `TARGET_NAME' macro that has the 6350 value 1 when the option is active and 0 otherwise. If you use 6351 `Var' to attach the option to a different variable, the bitmask 6352 macro with be called `OPTION_MASK_NAME'. 6353 6354 `InverseMask(OTHERNAME)' 6355 `InverseMask(OTHERNAME, THISNAME)' 6356 The option is the inverse of another option that has the 6357 `Mask(OTHERNAME)' property. If THISNAME is given, the 6358 options-processing script will declare a `TARGET_THISNAME' macro 6359 that is 1 when the option is active and 0 otherwise. 6360 6361 `Enum(NAME)' 6362 The option's argument is a string from the set of strings 6363 associated with the corresponding `Enum' record. The string is 6364 checked and converted to the integer specified in the corresponding 6365 `EnumValue' record before being passed to option handlers. 6366 6367 `Defer' 6368 The option should be stored in a vector, specified with `Var', for 6369 later processing. 6370 6371 `Alias(OPT)' 6372 `Alias(OPT, ARG)' 6373 `Alias(OPT, POSARG, NEGARG)' 6374 The option is an alias for `-OPT' (or the negative form of that 6375 option, depending on `NegativeAlias'). In the first form, any 6376 argument passed to the alias is considered to be passed to `-OPT', 6377 and `-OPT' is considered to be negated if the alias is used in 6378 negated form. In the second form, the alias may not be negated or 6379 have an argument, and POSARG is considered to be passed as an 6380 argument to `-OPT'. In the third form, the alias may not have an 6381 argument, if the alias is used in the positive form then POSARG is 6382 considered to be passed to `-OPT', and if the alias is used in the 6383 negative form then NEGARG is considered to be passed to `-OPT'. 6384 6385 Aliases should not specify `Var' or `Mask' or `UInteger'. Aliases 6386 should normally specify the same languages as the target of the 6387 alias; the flags on the target will be used to determine any 6388 diagnostic for use of an option for the wrong language, while 6389 those on the alias will be used to identify what command-line text 6390 is the option and what text is any argument to that option. 6391 6392 When an `Alias' definition is used for an option, driver specs do 6393 not need to handle it and no `OPT_' enumeration value is defined 6394 for it; only the canonical form of the option will be seen in those 6395 places. 6396 6397 `NegativeAlias' 6398 For an option marked with `Alias(OPT)', the option is considered 6399 to be an alias for the positive form of `-OPT' if negated and for 6400 the negative form of `-OPT' if not negated. `NegativeAlias' may 6401 not be used with the forms of `Alias' taking more than one 6402 argument. 6403 6404 `Ignore' 6405 This option is ignored apart from printing any warning specified 6406 using `Warn'. The option will not be seen by specs and no `OPT_' 6407 enumeration value is defined for it. 6408 6409 `SeparateAlias' 6410 For an option marked with `Joined', `Separate' and `Alias', the 6411 option only acts as an alias when passed a separate argument; with 6412 a joined argument it acts as a normal option, with an `OPT_' 6413 enumeration value. This is for compatibility with the Java `-d' 6414 option and should not be used for new options. 6415 6416 `Warn(MESSAGE)' 6417 If this option is used, output the warning MESSAGE. MESSAGE is a 6418 format string, either taking a single operand with a `%qs' format 6419 which is the option name, or not taking any operands, which is 6420 passed to the `warning' function. If an alias is marked `Warn', 6421 the target of the alias must not also be marked `Warn'. 6422 6423 `Report' 6424 The state of the option should be printed by `-fverbose-asm'. 6425 6426 `Warning' 6427 This is a warning option and should be shown as such in `--help' 6428 output. This flag does not currently affect anything other than 6429 `--help'. 6430 6431 `Optimization' 6432 This is an optimization option. It should be shown as such in 6433 `--help' output, and any associated variable named using `Var' 6434 should be saved and restored when the optimization level is 6435 changed with `optimize' attributes. 6436 6437 `Undocumented' 6438 The option is deliberately missing documentation and should not be 6439 included in the `--help' output. 6440 6441 `Condition(COND)' 6442 The option should only be accepted if preprocessor condition COND 6443 is true. Note that any C declarations associated with the option 6444 will be present even if COND is false; COND simply controls 6445 whether the option is accepted and whether it is printed in the 6446 `--help' output. 6447 6448 `Save' 6449 Build the `cl_target_option' structure to hold a copy of the 6450 option, add the functions `cl_target_option_save' and 6451 `cl_target_option_restore' to save and restore the options. 6452 6453 `SetByCombined' 6454 The option may also be set by a combined option such as 6455 `-ffast-math'. This causes the `gcc_options' struct to have a 6456 field `frontend_set_NAME', where `NAME' is the name of the field 6457 holding the value of this option (without the leading `x_'). This 6458 gives the front end a way to indicate that the value has been set 6459 explicitly and should not be changed by the combined option. For 6460 example, some front ends use this to prevent `-ffast-math' and 6461 `-fno-fast-math' from changing the value of `-fmath-errno' for 6462 languages that do not use `errno'. 6463 6464 `EnabledBy(OPT)' 6465 `EnabledBy(OPT && OPT2)' 6466 If not explicitly set, the option is set to the value of `-OPT'. 6467 The second form specifies that the option is only set if both OPT 6468 and OPT2 are set. 6469 6470 `LangEnabledBy(LANGUAGE, OPT)' 6471 `LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)' 6472 When compiling for the given language, the option is set to the 6473 value of `-OPT', if not explicitly set. In the second form, if OPT 6474 is used in the positive form then POSARG is considered to be 6475 passed to the option, and if OPT is used in the negative form then 6476 NEGARG is considered to be passed to the option. It is possible 6477 to specify several different languages. Each LANGUAGE must have 6478 been declared by an earlier `Language' record. *Note Option file 6479 format::. 6480 6481 `NoDWARFRecord' 6482 The option is omitted from the producer string written by 6483 `-grecord-gcc-switches'. 6484 6485 6486 File: gccint.info, Node: Passes, Next: GENERIC, Prev: Options, Up: Top 6487 6488 9 Passes and Files of the Compiler 6489 ********************************** 6490 6491 This chapter is dedicated to giving an overview of the optimization and 6492 code generation passes of the compiler. In the process, it describes 6493 some of the language front end interface, though this description is no 6494 where near complete. 6495 6496 * Menu: 6497 6498 * Parsing pass:: The language front end turns text into bits. 6499 * Gimplification pass:: The bits are turned into something we can optimize. 6500 * Pass manager:: Sequencing the optimization passes. 6501 * Tree SSA passes:: Optimizations on a high-level representation. 6502 * RTL passes:: Optimizations on a low-level representation. 6503 6504 6505 File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes 6506 6507 9.1 Parsing pass 6508 ================ 6509 6510 The language front end is invoked only once, via 6511 `lang_hooks.parse_file', to parse the entire input. The language front 6512 end may use any intermediate language representation deemed 6513 appropriate. The C front end uses GENERIC trees (*note GENERIC::), plus 6514 a double handful of language specific tree codes defined in 6515 `c-common.def'. The Fortran front end uses a completely different 6516 private representation. 6517 6518 At some point the front end must translate the representation used in 6519 the front end to a representation understood by the language-independent 6520 portions of the compiler. Current practice takes one of two forms. 6521 The C front end manually invokes the gimplifier (*note GIMPLE::) on 6522 each function, and uses the gimplifier callbacks to convert the 6523 language-specific tree nodes directly to GIMPLE before passing the 6524 function off to be compiled. The Fortran front end converts from a 6525 private representation to GENERIC, which is later lowered to GIMPLE 6526 when the function is compiled. Which route to choose probably depends 6527 on how well GENERIC (plus extensions) can be made to match up with the 6528 source language and necessary parsing data structures. 6529 6530 BUG: Gimplification must occur before nested function lowering, and 6531 nested function lowering must be done by the front end before passing 6532 the data off to cgraph. 6533 6534 TODO: Cgraph should control nested function lowering. It would only 6535 be invoked when it is certain that the outer-most function is used. 6536 6537 TODO: Cgraph needs a gimplify_function callback. It should be invoked 6538 when (1) it is certain that the function is used, (2) warning flags 6539 specified by the user require some amount of compilation in order to 6540 honor, (3) the language indicates that semantic analysis is not 6541 complete until gimplification occurs. Hum... this sounds overly 6542 complicated. Perhaps we should just have the front end gimplify 6543 always; in most cases it's only one function call. 6544 6545 The front end needs to pass all function definitions and top level 6546 declarations off to the middle-end so that they can be compiled and 6547 emitted to the object file. For a simple procedural language, it is 6548 usually most convenient to do this as each top level declaration or 6549 definition is seen. There is also a distinction to be made between 6550 generating functional code and generating complete debug information. 6551 The only thing that is absolutely required for functional code is that 6552 function and data _definitions_ be passed to the middle-end. For 6553 complete debug information, function, data and type declarations should 6554 all be passed as well. 6555 6556 In any case, the front end needs each complete top-level function or 6557 data declaration, and each data definition should be passed to 6558 `rest_of_decl_compilation'. Each complete type definition should be 6559 passed to `rest_of_type_compilation'. Each function definition should 6560 be passed to `cgraph_finalize_function'. 6561 6562 TODO: I know rest_of_compilation currently has all sorts of RTL 6563 generation semantics. I plan to move all code generation bits (both 6564 Tree and RTL) to compile_function. Should we hide cgraph from the 6565 front ends and move back to rest_of_compilation as the official 6566 interface? Possibly we should rename all three interfaces such that 6567 the names match in some meaningful way and that is more descriptive 6568 than "rest_of". 6569 6570 The middle-end will, at its option, emit the function and data 6571 definitions immediately or queue them for later processing. 6572 6573 6574 File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes 6575 6576 9.2 Gimplification pass 6577 ======================= 6578 6579 "Gimplification" is a whimsical term for the process of converting the 6580 intermediate representation of a function into the GIMPLE language 6581 (*note GIMPLE::). The term stuck, and so words like "gimplification", 6582 "gimplify", "gimplifier" and the like are sprinkled throughout this 6583 section of code. 6584 6585 While a front end may certainly choose to generate GIMPLE directly if 6586 it chooses, this can be a moderately complex process unless the 6587 intermediate language used by the front end is already fairly simple. 6588 Usually it is easier to generate GENERIC trees plus extensions and let 6589 the language-independent gimplifier do most of the work. 6590 6591 The main entry point to this pass is `gimplify_function_tree' located 6592 in `gimplify.c'. From here we process the entire function gimplifying 6593 each statement in turn. The main workhorse for this pass is 6594 `gimplify_expr'. Approximately everything passes through here at least 6595 once, and it is from here that we invoke the `lang_hooks.gimplify_expr' 6596 callback. 6597 6598 The callback should examine the expression in question and return 6599 `GS_UNHANDLED' if the expression is not a language specific construct 6600 that requires attention. Otherwise it should alter the expression in 6601 some way to such that forward progress is made toward producing valid 6602 GIMPLE. If the callback is certain that the transformation is complete 6603 and the expression is valid GIMPLE, it should return `GS_ALL_DONE'. 6604 Otherwise it should return `GS_OK', which will cause the expression to 6605 be processed again. If the callback encounters an error during the 6606 transformation (because the front end is relying on the gimplification 6607 process to finish semantic checks), it should return `GS_ERROR'. 6608 6609 6610 File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes 6611 6612 9.3 Pass manager 6613 ================ 6614 6615 The pass manager is located in `passes.c', `tree-optimize.c' and 6616 `tree-pass.h'. Its job is to run all of the individual passes in the 6617 correct order, and take care of standard bookkeeping that applies to 6618 every pass. 6619 6620 The theory of operation is that each pass defines a structure that 6621 represents everything we need to know about that pass--when it should 6622 be run, how it should be run, what intermediate language form or 6623 on-the-side data structures it needs. We register the pass to be run 6624 in some particular order, and the pass manager arranges for everything 6625 to happen in the correct order. 6626 6627 The actuality doesn't completely live up to the theory at present. 6628 Command-line switches and `timevar_id_t' enumerations must still be 6629 defined elsewhere. The pass manager validates constraints but does not 6630 attempt to (re-)generate data structures or lower intermediate language 6631 form based on the requirements of the next pass. Nevertheless, what is 6632 present is useful, and a far sight better than nothing at all. 6633 6634 Each pass should have a unique name. Each pass may have its own dump 6635 file (for GCC debugging purposes). Passes with a name starting with a 6636 star do not dump anything. Sometimes passes are supposed to share a 6637 dump file / option name. To still give these unique names, you can use 6638 a prefix that is delimited by a space from the part that is used for 6639 the dump file / option name. E.g. When the pass name is "ud dce", the 6640 name used for dump file/options is "dce". 6641 6642 TODO: describe the global variables set up by the pass manager, and a 6643 brief description of how a new pass should use it. I need to look at 6644 what info RTL passes use first... 6645 6646 6647 File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes 6648 6649 9.4 Tree SSA passes 6650 =================== 6651 6652 The following briefly describes the Tree optimization passes that are 6653 run after gimplification and what source files they are located in. 6654 6655 * Remove useless statements 6656 6657 This pass is an extremely simple sweep across the gimple code in 6658 which we identify obviously dead code and remove it. Here we do 6659 things like simplify `if' statements with constant conditions, 6660 remove exception handling constructs surrounding code that 6661 obviously cannot throw, remove lexical bindings that contain no 6662 variables, and other assorted simplistic cleanups. The idea is to 6663 get rid of the obvious stuff quickly rather than wait until later 6664 when it's more work to get rid of it. This pass is located in 6665 `tree-cfg.c' and described by `pass_remove_useless_stmts'. 6666 6667 * Mudflap declaration registration 6668 6669 If mudflap (*note -fmudflap -fmudflapth -fmudflapir: (gcc)Optimize 6670 Options.) is enabled, we generate code to register some variable 6671 declarations with the mudflap runtime. Specifically, the runtime 6672 tracks the lifetimes of those variable declarations that have 6673 their addresses taken, or whose bounds are unknown at compile time 6674 (`extern'). This pass generates new exception handling constructs 6675 (`try'/`finally'), and so must run before those are lowered. In 6676 addition, the pass enqueues declarations of static variables whose 6677 lifetimes extend to the entire program. The pass is located in 6678 `tree-mudflap.c' and is described by `pass_mudflap_1'. 6679 6680 * OpenMP lowering 6681 6682 If OpenMP generation (`-fopenmp') is enabled, this pass lowers 6683 OpenMP constructs into GIMPLE. 6684 6685 Lowering of OpenMP constructs involves creating replacement 6686 expressions for local variables that have been mapped using data 6687 sharing clauses, exposing the control flow of most synchronization 6688 directives and adding region markers to facilitate the creation of 6689 the control flow graph. The pass is located in `omp-low.c' and is 6690 described by `pass_lower_omp'. 6691 6692 * OpenMP expansion 6693 6694 If OpenMP generation (`-fopenmp') is enabled, this pass expands 6695 parallel regions into their own functions to be invoked by the 6696 thread library. The pass is located in `omp-low.c' and is 6697 described by `pass_expand_omp'. 6698 6699 * Lower control flow 6700 6701 This pass flattens `if' statements (`COND_EXPR') and moves lexical 6702 bindings (`BIND_EXPR') out of line. After this pass, all `if' 6703 statements will have exactly two `goto' statements in its `then' 6704 and `else' arms. Lexical binding information for each statement 6705 will be found in `TREE_BLOCK' rather than being inferred from its 6706 position under a `BIND_EXPR'. This pass is found in 6707 `gimple-low.c' and is described by `pass_lower_cf'. 6708 6709 * Lower exception handling control flow 6710 6711 This pass decomposes high-level exception handling constructs 6712 (`TRY_FINALLY_EXPR' and `TRY_CATCH_EXPR') into a form that 6713 explicitly represents the control flow involved. After this pass, 6714 `lookup_stmt_eh_region' will return a non-negative number for any 6715 statement that may have EH control flow semantics; examine 6716 `tree_can_throw_internal' or `tree_can_throw_external' for exact 6717 semantics. Exact control flow may be extracted from 6718 `foreach_reachable_handler'. The EH region nesting tree is defined 6719 in `except.h' and built in `except.c'. The lowering pass itself 6720 is in `tree-eh.c' and is described by `pass_lower_eh'. 6721 6722 * Build the control flow graph 6723 6724 This pass decomposes a function into basic blocks and creates all 6725 of the edges that connect them. It is located in `tree-cfg.c' and 6726 is described by `pass_build_cfg'. 6727 6728 * Find all referenced variables 6729 6730 This pass walks the entire function and collects an array of all 6731 variables referenced in the function, `referenced_vars'. The 6732 index at which a variable is found in the array is used as a UID 6733 for the variable within this function. This data is needed by the 6734 SSA rewriting routines. The pass is located in `tree-dfa.c' and 6735 is described by `pass_referenced_vars'. 6736 6737 * Enter static single assignment form 6738 6739 This pass rewrites the function such that it is in SSA form. After 6740 this pass, all `is_gimple_reg' variables will be referenced by 6741 `SSA_NAME', and all occurrences of other variables will be 6742 annotated with `VDEFS' and `VUSES'; PHI nodes will have been 6743 inserted as necessary for each basic block. This pass is located 6744 in `tree-ssa.c' and is described by `pass_build_ssa'. 6745 6746 * Warn for uninitialized variables 6747 6748 This pass scans the function for uses of `SSA_NAME's that are fed 6749 by default definition. For non-parameter variables, such uses are 6750 uninitialized. The pass is run twice, before and after 6751 optimization (if turned on). In the first pass we only warn for 6752 uses that are positively uninitialized; in the second pass we warn 6753 for uses that are possibly uninitialized. The pass is located in 6754 `tree-ssa.c' and is defined by `pass_early_warn_uninitialized' and 6755 `pass_late_warn_uninitialized'. 6756 6757 * Dead code elimination 6758 6759 This pass scans the function for statements without side effects 6760 whose result is unused. It does not do memory life analysis, so 6761 any value that is stored in memory is considered used. The pass 6762 is run multiple times throughout the optimization process. It is 6763 located in `tree-ssa-dce.c' and is described by `pass_dce'. 6764 6765 * Dominator optimizations 6766 6767 This pass performs trivial dominator-based copy and constant 6768 propagation, expression simplification, and jump threading. It is 6769 run multiple times throughout the optimization process. It is 6770 located in `tree-ssa-dom.c' and is described by `pass_dominator'. 6771 6772 * Forward propagation of single-use variables 6773 6774 This pass attempts to remove redundant computation by substituting 6775 variables that are used once into the expression that uses them and 6776 seeing if the result can be simplified. It is located in 6777 `tree-ssa-forwprop.c' and is described by `pass_forwprop'. 6778 6779 * Copy Renaming 6780 6781 This pass attempts to change the name of compiler temporaries 6782 involved in copy operations such that SSA->normal can coalesce the 6783 copy away. When compiler temporaries are copies of user 6784 variables, it also renames the compiler temporary to the user 6785 variable resulting in better use of user symbols. It is located 6786 in `tree-ssa-copyrename.c' and is described by `pass_copyrename'. 6787 6788 * PHI node optimizations 6789 6790 This pass recognizes forms of PHI inputs that can be represented as 6791 conditional expressions and rewrites them into straight line code. 6792 It is located in `tree-ssa-phiopt.c' and is described by 6793 `pass_phiopt'. 6794 6795 * May-alias optimization 6796 6797 This pass performs a flow sensitive SSA-based points-to analysis. 6798 The resulting may-alias, must-alias, and escape analysis 6799 information is used to promote variables from in-memory 6800 addressable objects to non-aliased variables that can be renamed 6801 into SSA form. We also update the `VDEF'/`VUSE' memory tags for 6802 non-renameable aggregates so that we get fewer false kills. The 6803 pass is located in `tree-ssa-alias.c' and is described by 6804 `pass_may_alias'. 6805 6806 Interprocedural points-to information is located in 6807 `tree-ssa-structalias.c' and described by `pass_ipa_pta'. 6808 6809 * Profiling 6810 6811 This pass rewrites the function in order to collect runtime block 6812 and value profiling data. Such data may be fed back into the 6813 compiler on a subsequent run so as to allow optimization based on 6814 expected execution frequencies. The pass is located in 6815 `predict.c' and is described by `pass_profile'. 6816 6817 * Lower complex arithmetic 6818 6819 This pass rewrites complex arithmetic operations into their 6820 component scalar arithmetic operations. The pass is located in 6821 `tree-complex.c' and is described by `pass_lower_complex'. 6822 6823 * Scalar replacement of aggregates 6824 6825 This pass rewrites suitable non-aliased local aggregate variables 6826 into a set of scalar variables. The resulting scalar variables are 6827 rewritten into SSA form, which allows subsequent optimization 6828 passes to do a significantly better job with them. The pass is 6829 located in `tree-sra.c' and is described by `pass_sra'. 6830 6831 * Dead store elimination 6832 6833 This pass eliminates stores to memory that are subsequently 6834 overwritten by another store, without any intervening loads. The 6835 pass is located in `tree-ssa-dse.c' and is described by `pass_dse'. 6836 6837 * Tail recursion elimination 6838 6839 This pass transforms tail recursion into a loop. It is located in 6840 `tree-tailcall.c' and is described by `pass_tail_recursion'. 6841 6842 * Forward store motion 6843 6844 This pass sinks stores and assignments down the flowgraph closer 6845 to their use point. The pass is located in `tree-ssa-sink.c' and 6846 is described by `pass_sink_code'. 6847 6848 * Partial redundancy elimination 6849 6850 This pass eliminates partially redundant computations, as well as 6851 performing load motion. The pass is located in `tree-ssa-pre.c' 6852 and is described by `pass_pre'. 6853 6854 Just before partial redundancy elimination, if 6855 `-funsafe-math-optimizations' is on, GCC tries to convert 6856 divisions to multiplications by the reciprocal. The pass is 6857 located in `tree-ssa-math-opts.c' and is described by 6858 `pass_cse_reciprocal'. 6859 6860 * Full redundancy elimination 6861 6862 This is a simpler form of PRE that only eliminates redundancies 6863 that occur on all paths. It is located in `tree-ssa-pre.c' and 6864 described by `pass_fre'. 6865 6866 * Loop optimization 6867 6868 The main driver of the pass is placed in `tree-ssa-loop.c' and 6869 described by `pass_loop'. 6870 6871 The optimizations performed by this pass are: 6872 6873 Loop invariant motion. This pass moves only invariants that would 6874 be hard to handle on RTL level (function calls, operations that 6875 expand to nontrivial sequences of insns). With `-funswitch-loops' 6876 it also moves operands of conditions that are invariant out of the 6877 loop, so that we can use just trivial invariantness analysis in 6878 loop unswitching. The pass also includes store motion. The pass 6879 is implemented in `tree-ssa-loop-im.c'. 6880 6881 Canonical induction variable creation. This pass creates a simple 6882 counter for number of iterations of the loop and replaces the exit 6883 condition of the loop using it, in case when a complicated 6884 analysis is necessary to determine the number of iterations. 6885 Later optimizations then may determine the number easily. The 6886 pass is implemented in `tree-ssa-loop-ivcanon.c'. 6887 6888 Induction variable optimizations. This pass performs standard 6889 induction variable optimizations, including strength reduction, 6890 induction variable merging and induction variable elimination. 6891 The pass is implemented in `tree-ssa-loop-ivopts.c'. 6892 6893 Loop unswitching. This pass moves the conditional jumps that are 6894 invariant out of the loops. To achieve this, a duplicate of the 6895 loop is created for each possible outcome of conditional jump(s). 6896 The pass is implemented in `tree-ssa-loop-unswitch.c'. This pass 6897 should eventually replace the RTL level loop unswitching in 6898 `loop-unswitch.c', but currently the RTL level pass is not 6899 completely redundant yet due to deficiencies in tree level alias 6900 analysis. 6901 6902 The optimizations also use various utility functions contained in 6903 `tree-ssa-loop-manip.c', `cfgloop.c', `cfgloopanal.c' and 6904 `cfgloopmanip.c'. 6905 6906 Vectorization. This pass transforms loops to operate on vector 6907 types instead of scalar types. Data parallelism across loop 6908 iterations is exploited to group data elements from consecutive 6909 iterations into a vector and operate on them in parallel. 6910 Depending on available target support the loop is conceptually 6911 unrolled by a factor `VF' (vectorization factor), which is the 6912 number of elements operated upon in parallel in each iteration, 6913 and the `VF' copies of each scalar operation are fused to form a 6914 vector operation. Additional loop transformations such as peeling 6915 and versioning may take place to align the number of iterations, 6916 and to align the memory accesses in the loop. The pass is 6917 implemented in `tree-vectorizer.c' (the main driver), 6918 `tree-vect-loop.c' and `tree-vect-loop-manip.c' (loop specific 6919 parts and general loop utilities), `tree-vect-slp' (loop-aware SLP 6920 functionality), `tree-vect-stmts.c' and `tree-vect-data-refs.c'. 6921 Analysis of data references is in `tree-data-ref.c'. 6922 6923 SLP Vectorization. This pass performs vectorization of 6924 straight-line code. The pass is implemented in `tree-vectorizer.c' 6925 (the main driver), `tree-vect-slp.c', `tree-vect-stmts.c' and 6926 `tree-vect-data-refs.c'. 6927 6928 Autoparallelization. This pass splits the loop iteration space to 6929 run into several threads. The pass is implemented in 6930 `tree-parloops.c'. 6931 6932 Graphite is a loop transformation framework based on the polyhedral 6933 model. Graphite stands for Gimple Represented as Polyhedra. The 6934 internals of this infrastructure are documented in 6935 `http://gcc.gnu.org/wiki/Graphite'. The passes working on this 6936 representation are implemented in the various `graphite-*' files. 6937 6938 * Tree level if-conversion for vectorizer 6939 6940 This pass applies if-conversion to simple loops to help vectorizer. 6941 We identify if convertible loops, if-convert statements and merge 6942 basic blocks in one big block. The idea is to present loop in such 6943 form so that vectorizer can have one to one mapping between 6944 statements and available vector operations. This pass is located 6945 in `tree-if-conv.c' and is described by `pass_if_conversion'. 6946 6947 * Conditional constant propagation 6948 6949 This pass relaxes a lattice of values in order to identify those 6950 that must be constant even in the presence of conditional branches. 6951 The pass is located in `tree-ssa-ccp.c' and is described by 6952 `pass_ccp'. 6953 6954 A related pass that works on memory loads and stores, and not just 6955 register values, is located in `tree-ssa-ccp.c' and described by 6956 `pass_store_ccp'. 6957 6958 * Conditional copy propagation 6959 6960 This is similar to constant propagation but the lattice of values 6961 is the "copy-of" relation. It eliminates redundant copies from the 6962 code. The pass is located in `tree-ssa-copy.c' and described by 6963 `pass_copy_prop'. 6964 6965 A related pass that works on memory copies, and not just register 6966 copies, is located in `tree-ssa-copy.c' and described by 6967 `pass_store_copy_prop'. 6968 6969 * Value range propagation 6970 6971 This transformation is similar to constant propagation but instead 6972 of propagating single constant values, it propagates known value 6973 ranges. The implementation is based on Patterson's range 6974 propagation algorithm (Accurate Static Branch Prediction by Value 6975 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 6976 Patterson's algorithm, this implementation does not propagate 6977 branch probabilities nor it uses more than a single range per SSA 6978 name. This means that the current implementation cannot be used 6979 for branch prediction (though adapting it would not be difficult). 6980 The pass is located in `tree-vrp.c' and is described by `pass_vrp'. 6981 6982 * Folding built-in functions 6983 6984 This pass simplifies built-in functions, as applicable, with 6985 constant arguments or with inferable string lengths. It is 6986 located in `tree-ssa-ccp.c' and is described by 6987 `pass_fold_builtins'. 6988 6989 * Split critical edges 6990 6991 This pass identifies critical edges and inserts empty basic blocks 6992 such that the edge is no longer critical. The pass is located in 6993 `tree-cfg.c' and is described by `pass_split_crit_edges'. 6994 6995 * Control dependence dead code elimination 6996 6997 This pass is a stronger form of dead code elimination that can 6998 eliminate unnecessary control flow statements. It is located in 6999 `tree-ssa-dce.c' and is described by `pass_cd_dce'. 7000 7001 * Tail call elimination 7002 7003 This pass identifies function calls that may be rewritten into 7004 jumps. No code transformation is actually applied here, but the 7005 data and control flow problem is solved. The code transformation 7006 requires target support, and so is delayed until RTL. In the 7007 meantime `CALL_EXPR_TAILCALL' is set indicating the possibility. 7008 The pass is located in `tree-tailcall.c' and is described by 7009 `pass_tail_calls'. The RTL transformation is handled by 7010 `fixup_tail_calls' in `calls.c'. 7011 7012 * Warn for function return without value 7013 7014 For non-void functions, this pass locates return statements that do 7015 not specify a value and issues a warning. Such a statement may 7016 have been injected by falling off the end of the function. This 7017 pass is run last so that we have as much time as possible to prove 7018 that the statement is not reachable. It is located in 7019 `tree-cfg.c' and is described by `pass_warn_function_return'. 7020 7021 * Mudflap statement annotation 7022 7023 If mudflap is enabled, we rewrite some memory accesses with code to 7024 validate that the memory access is correct. In particular, 7025 expressions involving pointer dereferences (`INDIRECT_REF', 7026 `ARRAY_REF', etc.) are replaced by code that checks the selected 7027 address range against the mudflap runtime's database of valid 7028 regions. This check includes an inline lookup into a 7029 direct-mapped cache, based on shift/mask operations of the pointer 7030 value, with a fallback function call into the runtime. The pass 7031 is located in `tree-mudflap.c' and is described by 7032 `pass_mudflap_2'. 7033 7034 * Leave static single assignment form 7035 7036 This pass rewrites the function such that it is in normal form. At 7037 the same time, we eliminate as many single-use temporaries as 7038 possible, so the intermediate language is no longer GIMPLE, but 7039 GENERIC. The pass is located in `tree-outof-ssa.c' and is 7040 described by `pass_del_ssa'. 7041 7042 * Merge PHI nodes that feed into one another 7043 7044 This is part of the CFG cleanup passes. It attempts to join PHI 7045 nodes from a forwarder CFG block into another block with PHI 7046 nodes. The pass is located in `tree-cfgcleanup.c' and is 7047 described by `pass_merge_phi'. 7048 7049 * Return value optimization 7050 7051 If a function always returns the same local variable, and that 7052 local variable is an aggregate type, then the variable is replaced 7053 with the return value for the function (i.e., the function's 7054 DECL_RESULT). This is equivalent to the C++ named return value 7055 optimization applied to GIMPLE. The pass is located in 7056 `tree-nrv.c' and is described by `pass_nrv'. 7057 7058 * Return slot optimization 7059 7060 If a function returns a memory object and is called as `var = 7061 foo()', this pass tries to change the call so that the address of 7062 `var' is sent to the caller to avoid an extra memory copy. This 7063 pass is located in `tree-nrv.c' and is described by 7064 `pass_return_slot'. 7065 7066 * Optimize calls to `__builtin_object_size' 7067 7068 This is a propagation pass similar to CCP that tries to remove 7069 calls to `__builtin_object_size' when the size of the object can be 7070 computed at compile-time. This pass is located in 7071 `tree-object-size.c' and is described by `pass_object_sizes'. 7072 7073 * Loop invariant motion 7074 7075 This pass removes expensive loop-invariant computations out of 7076 loops. The pass is located in `tree-ssa-loop.c' and described by 7077 `pass_lim'. 7078 7079 * Loop nest optimizations 7080 7081 This is a family of loop transformations that works on loop nests. 7082 It includes loop interchange, scaling, skewing and reversal and 7083 they are all geared to the optimization of data locality in array 7084 traversals and the removal of dependencies that hamper 7085 optimizations such as loop parallelization and vectorization. The 7086 pass is located in `tree-loop-linear.c' and described by 7087 `pass_linear_transform'. 7088 7089 * Removal of empty loops 7090 7091 This pass removes loops with no code in them. The pass is located 7092 in `tree-ssa-loop-ivcanon.c' and described by `pass_empty_loop'. 7093 7094 * Unrolling of small loops 7095 7096 This pass completely unrolls loops with few iterations. The pass 7097 is located in `tree-ssa-loop-ivcanon.c' and described by 7098 `pass_complete_unroll'. 7099 7100 * Predictive commoning 7101 7102 This pass makes the code reuse the computations from the previous 7103 iterations of the loops, especially loads and stores to memory. 7104 It does so by storing the values of these computations to a bank 7105 of temporary variables that are rotated at the end of loop. To 7106 avoid the need for this rotation, the loop is then unrolled and 7107 the copies of the loop body are rewritten to use the appropriate 7108 version of the temporary variable. This pass is located in 7109 `tree-predcom.c' and described by `pass_predcom'. 7110 7111 * Array prefetching 7112 7113 This pass issues prefetch instructions for array references inside 7114 loops. The pass is located in `tree-ssa-loop-prefetch.c' and 7115 described by `pass_loop_prefetch'. 7116 7117 * Reassociation 7118 7119 This pass rewrites arithmetic expressions to enable optimizations 7120 that operate on them, like redundancy elimination and 7121 vectorization. The pass is located in `tree-ssa-reassoc.c' and 7122 described by `pass_reassoc'. 7123 7124 * Optimization of `stdarg' functions 7125 7126 This pass tries to avoid the saving of register arguments into the 7127 stack on entry to `stdarg' functions. If the function doesn't use 7128 any `va_start' macros, no registers need to be saved. If 7129 `va_start' macros are used, the `va_list' variables don't escape 7130 the function, it is only necessary to save registers that will be 7131 used in `va_arg' macros. For instance, if `va_arg' is only used 7132 with integral types in the function, floating point registers 7133 don't need to be saved. This pass is located in `tree-stdarg.c' 7134 and described by `pass_stdarg'. 7135 7136 7137 7138 File: gccint.info, Node: RTL passes, Prev: Tree SSA passes, Up: Passes 7139 7140 9.5 RTL passes 7141 ============== 7142 7143 The following briefly describes the RTL generation and optimization 7144 passes that are run after the Tree optimization passes. 7145 7146 * RTL generation 7147 7148 The source files for RTL generation include `stmt.c', `calls.c', 7149 `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and 7150 `emit-rtl.c'. Also, the file `insn-emit.c', generated from the 7151 machine description by the program `genemit', is used in this 7152 pass. The header file `expr.h' is used for communication within 7153 this pass. 7154 7155 The header files `insn-flags.h' and `insn-codes.h', generated from 7156 the machine description by the programs `genflags' and `gencodes', 7157 tell this pass which standard names are available for use and 7158 which patterns correspond to them. 7159 7160 * Generation of exception landing pads 7161 7162 This pass generates the glue that handles communication between the 7163 exception handling library routines and the exception handlers 7164 within the function. Entry points in the function that are 7165 invoked by the exception handling library are called "landing 7166 pads". The code for this pass is located in `except.c'. 7167 7168 * Control flow graph cleanup 7169 7170 This pass removes unreachable code, simplifies jumps to next, 7171 jumps to jump, jumps across jumps, etc. The pass is run multiple 7172 times. For historical reasons, it is occasionally referred to as 7173 the "jump optimization pass". The bulk of the code for this pass 7174 is in `cfgcleanup.c', and there are support routines in `cfgrtl.c' 7175 and `jump.c'. 7176 7177 * Forward propagation of single-def values 7178 7179 This pass attempts to remove redundant computation by substituting 7180 variables that come from a single definition, and seeing if the 7181 result can be simplified. It performs copy propagation and 7182 addressing mode selection. The pass is run twice, with values 7183 being propagated into loops only on the second run. The code is 7184 located in `fwprop.c'. 7185 7186 * Common subexpression elimination 7187 7188 This pass removes redundant computation within basic blocks, and 7189 optimizes addressing modes based on cost. The pass is run twice. 7190 The code for this pass is located in `cse.c'. 7191 7192 * Global common subexpression elimination 7193 7194 This pass performs two different types of GCSE depending on 7195 whether you are optimizing for size or not (LCM based GCSE tends 7196 to increase code size for a gain in speed, while Morel-Renvoise 7197 based GCSE does not). When optimizing for size, GCSE is done 7198 using Morel-Renvoise Partial Redundancy Elimination, with the 7199 exception that it does not try to move invariants out of 7200 loops--that is left to the loop optimization pass. If MR PRE 7201 GCSE is done, code hoisting (aka unification) is also done, as 7202 well as load motion. If you are optimizing for speed, LCM (lazy 7203 code motion) based GCSE is done. LCM is based on the work of 7204 Knoop, Ruthing, and Steffen. LCM based GCSE also does loop 7205 invariant code motion. We also perform load and store motion when 7206 optimizing for speed. Regardless of which type of GCSE is used, 7207 the GCSE pass also performs global constant and copy propagation. 7208 The source file for this pass is `gcse.c', and the LCM routines 7209 are in `lcm.c'. 7210 7211 * Loop optimization 7212 7213 This pass performs several loop related optimizations. The source 7214 files `cfgloopanal.c' and `cfgloopmanip.c' contain generic loop 7215 analysis and manipulation code. Initialization and finalization 7216 of loop structures is handled by `loop-init.c'. A loop invariant 7217 motion pass is implemented in `loop-invariant.c'. Basic block 7218 level optimizations--unrolling, peeling and unswitching loops-- 7219 are implemented in `loop-unswitch.c' and `loop-unroll.c'. 7220 Replacing of the exit condition of loops by special 7221 machine-dependent instructions is handled by `loop-doloop.c'. 7222 7223 * Jump bypassing 7224 7225 This pass is an aggressive form of GCSE that transforms the control 7226 flow graph of a function by propagating constants into conditional 7227 branch instructions. The source file for this pass is `gcse.c'. 7228 7229 * If conversion 7230 7231 This pass attempts to replace conditional branches and surrounding 7232 assignments with arithmetic, boolean value producing comparison 7233 instructions, and conditional move instructions. In the very last 7234 invocation after reload/LRA, it will generate predicated 7235 instructions when supported by the target. The code is located in 7236 `ifcvt.c'. 7237 7238 * Web construction 7239 7240 This pass splits independent uses of each pseudo-register. This 7241 can improve effect of the other transformation, such as CSE or 7242 register allocation. The code for this pass is located in `web.c'. 7243 7244 * Instruction combination 7245 7246 This pass attempts to combine groups of two or three instructions 7247 that are related by data flow into single instructions. It 7248 combines the RTL expressions for the instructions by substitution, 7249 simplifies the result using algebra, and then attempts to match 7250 the result against the machine description. The code is located 7251 in `combine.c'. 7252 7253 * Register movement 7254 7255 This pass looks for cases where matching constraints would force an 7256 instruction to need a reload, and this reload would be a 7257 register-to-register move. It then attempts to change the 7258 registers used by the instruction to avoid the move instruction. 7259 The code is located in `regmove.c'. 7260 7261 * Mode switching optimization 7262 7263 This pass looks for instructions that require the processor to be 7264 in a specific "mode" and minimizes the number of mode changes 7265 required to satisfy all users. What these modes are, and what 7266 they apply to are completely target-specific. The code for this 7267 pass is located in `mode-switching.c'. 7268 7269 * Modulo scheduling 7270 7271 This pass looks at innermost loops and reorders their instructions 7272 by overlapping different iterations. Modulo scheduling is 7273 performed immediately before instruction scheduling. The code for 7274 this pass is located in `modulo-sched.c'. 7275 7276 * Instruction scheduling 7277 7278 This pass looks for instructions whose output will not be 7279 available by the time that it is used in subsequent instructions. 7280 Memory loads and floating point instructions often have this 7281 behavior on RISC machines. It re-orders instructions within a 7282 basic block to try to separate the definition and use of items 7283 that otherwise would cause pipeline stalls. This pass is 7284 performed twice, before and after register allocation. The code 7285 for this pass is located in `haifa-sched.c', `sched-deps.c', 7286 `sched-ebb.c', `sched-rgn.c' and `sched-vis.c'. 7287 7288 * Register allocation 7289 7290 These passes make sure that all occurrences of pseudo registers are 7291 eliminated, either by allocating them to a hard register, replacing 7292 them by an equivalent expression (e.g. a constant) or by placing 7293 them on the stack. This is done in several subpasses: 7294 7295 * Register move optimizations. This pass makes some simple RTL 7296 code transformations which improve the subsequent register 7297 allocation. The source file is `regmove.c'. 7298 7299 * The integrated register allocator (IRA). It is called 7300 integrated because coalescing, register live range splitting, 7301 and hard register preferencing are done on-the-fly during 7302 coloring. It also has better integration with the reload/LRA 7303 pass. Pseudo-registers spilled by the allocator or the 7304 reload/LRA have still a chance to get hard-registers if the 7305 reload/LRA evicts some pseudo-registers from hard-registers. 7306 The allocator helps to choose better pseudos for spilling 7307 based on their live ranges and to coalesce stack slots 7308 allocated for the spilled pseudo-registers. IRA is a regional 7309 register allocator which is transformed into Chaitin-Briggs 7310 allocator if there is one region. By default, IRA chooses 7311 regions using register pressure but the user can force it to 7312 use one region or regions corresponding to all loops. 7313 7314 Source files of the allocator are `ira.c', `ira-build.c', 7315 `ira-costs.c', `ira-conflicts.c', `ira-color.c', 7316 `ira-emit.c', `ira-lives', plus header files `ira.h' and 7317 `ira-int.h' used for the communication between the allocator 7318 and the rest of the compiler and between the IRA files. 7319 7320 * Reloading. This pass renumbers pseudo registers with the 7321 hardware registers numbers they were allocated. Pseudo 7322 registers that did not get hard registers are replaced with 7323 stack slots. Then it finds instructions that are invalid 7324 because a value has failed to end up in a register, or has 7325 ended up in a register of the wrong kind. It fixes up these 7326 instructions by reloading the problematical values 7327 temporarily into registers. Additional instructions are 7328 generated to do the copying. 7329 7330 The reload pass also optionally eliminates the frame pointer 7331 and inserts instructions to save and restore call-clobbered 7332 registers around calls. 7333 7334 Source files are `reload.c' and `reload1.c', plus the header 7335 `reload.h' used for communication between them. 7336 7337 * This pass is a modern replacement of the reload pass. Source 7338 files are `lra.c', `lra-assign.c', `lra-coalesce.c', 7339 `lra-constraints.c', `lra-eliminations.c', `lra-equivs.c', 7340 `lra-lives.c', `lra-saves.c', `lra-spills.c', the header 7341 `lra-int.h' used for communication between them, and the 7342 header `lra.h' used for communication between LRA and the 7343 rest of compiler. 7344 7345 Unlike the reload pass, intermediate LRA decisions are 7346 reflected in RTL as much as possible. This reduces the 7347 number of target-dependent macros and hooks, leaving 7348 instruction constraints as the primary source of control. 7349 7350 LRA is run on targets for which TARGET_LRA_P returns true. 7351 7352 * Basic block reordering 7353 7354 This pass implements profile guided code positioning. If profile 7355 information is not available, various types of static analysis are 7356 performed to make the predictions normally coming from the profile 7357 feedback (IE execution frequency, branch probability, etc). It is 7358 implemented in the file `bb-reorder.c', and the various prediction 7359 routines are in `predict.c'. 7360 7361 * Variable tracking 7362 7363 This pass computes where the variables are stored at each position 7364 in code and generates notes describing the variable locations to 7365 RTL code. The location lists are then generated according to these 7366 notes to debug information if the debugging information format 7367 supports location lists. The code is located in `var-tracking.c'. 7368 7369 * Delayed branch scheduling 7370 7371 This optional pass attempts to find instructions that can go into 7372 the delay slots of other instructions, usually jumps and calls. 7373 The code for this pass is located in `reorg.c'. 7374 7375 * Branch shortening 7376 7377 On many RISC machines, branch instructions have a limited range. 7378 Thus, longer sequences of instructions must be used for long 7379 branches. In this pass, the compiler figures out what how far 7380 each instruction will be from each other instruction, and 7381 therefore whether the usual instructions, or the longer sequences, 7382 must be used for each branch. The code for this pass is located 7383 in `final.c'. 7384 7385 * Register-to-stack conversion 7386 7387 Conversion from usage of some hard registers to usage of a register 7388 stack may be done at this point. Currently, this is supported only 7389 for the floating-point registers of the Intel 80387 coprocessor. 7390 The code for this pass is located in `reg-stack.c'. 7391 7392 * Final 7393 7394 This pass outputs the assembler code for the function. The source 7395 files are `final.c' plus `insn-output.c'; the latter is generated 7396 automatically from the machine description by the tool `genoutput'. 7397 The header file `conditions.h' is used for communication between 7398 these files. If mudflap is enabled, the queue of deferred 7399 declarations and any addressed constants (e.g., string literals) 7400 is processed by `mudflap_finish_file' into a synthetic constructor 7401 function containing calls into the mudflap runtime. 7402 7403 * Debugging information output 7404 7405 This is run after final because it must output the stack slot 7406 offsets for pseudo registers that did not get hard registers. 7407 Source files are `dbxout.c' for DBX symbol table format, 7408 `sdbout.c' for SDB symbol table format, `dwarfout.c' for DWARF 7409 symbol table format, files `dwarf2out.c' and `dwarf2asm.c' for 7410 DWARF2 symbol table format, and `vmsdbgout.c' for VMS debug symbol 7411 table format. 7412 7413 7414 7415 File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 7416 7417 10 RTL Representation 7418 ********************* 7419 7420 The last part of the compiler work is done on a low-level intermediate 7421 representation called Register Transfer Language. In this language, the 7422 instructions to be output are described, pretty much one by one, in an 7423 algebraic form that describes what the instruction does. 7424 7425 RTL is inspired by Lisp lists. It has both an internal form, made up 7426 of structures that point at other structures, and a textual form that 7427 is used in the machine description and in printed debugging dumps. The 7428 textual form uses nested parentheses to indicate the pointers in the 7429 internal form. 7430 7431 * Menu: 7432 7433 * RTL Objects:: Expressions vs vectors vs strings vs integers. 7434 * RTL Classes:: Categories of RTL expression objects, and their structure. 7435 * Accessors:: Macros to access expression operands or vector elts. 7436 * Special Accessors:: Macros to access specific annotations on RTL. 7437 * Flags:: Other flags in an RTL expression. 7438 * Machine Modes:: Describing the size and format of a datum. 7439 * Constants:: Expressions with constant values. 7440 * Regs and Memory:: Expressions representing register contents or memory. 7441 * Arithmetic:: Expressions representing arithmetic on other expressions. 7442 * Comparisons:: Expressions representing comparison of expressions. 7443 * Bit-Fields:: Expressions representing bit-fields in memory or reg. 7444 * Vector Operations:: Expressions involving vector datatypes. 7445 * Conversions:: Extending, truncating, floating or fixing. 7446 * RTL Declarations:: Declaring volatility, constancy, etc. 7447 * Side Effects:: Expressions for storing in registers, etc. 7448 * Incdec:: Embedded side-effects for autoincrement addressing. 7449 * Assembler:: Representing `asm' with operands. 7450 * Debug Information:: Expressions representing debugging information. 7451 * Insns:: Expression types for entire insns. 7452 * Calls:: RTL representation of function call insns. 7453 * Sharing:: Some expressions are unique; others *must* be copied. 7454 * Reading RTL:: Reading textual RTL from a file. 7455 7456 7457 File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 7458 7459 10.1 RTL Object Types 7460 ===================== 7461 7462 RTL uses five kinds of objects: expressions, integers, wide integers, 7463 strings and vectors. Expressions are the most important ones. An RTL 7464 expression ("RTX", for short) is a C structure, but it is usually 7465 referred to with a pointer; a type that is given the typedef name `rtx'. 7466 7467 An integer is simply an `int'; their written form uses decimal digits. 7468 A wide integer is an integral object whose type is `HOST_WIDE_INT'; 7469 their written form uses decimal digits. 7470 7471 A string is a sequence of characters. In core it is represented as a 7472 `char *' in usual C fashion, and it is written in C syntax as well. 7473 However, strings in RTL may never be null. If you write an empty 7474 string in a machine description, it is represented in core as a null 7475 pointer rather than as a pointer to a null character. In certain 7476 contexts, these null pointers instead of strings are valid. Within RTL 7477 code, strings are most commonly found inside `symbol_ref' expressions, 7478 but they appear in other contexts in the RTL expressions that make up 7479 machine descriptions. 7480 7481 In a machine description, strings are normally written with double 7482 quotes, as you would in C. However, strings in machine descriptions may 7483 extend over many lines, which is invalid C, and adjacent string 7484 constants are not concatenated as they are in C. Any string constant 7485 may be surrounded with a single set of parentheses. Sometimes this 7486 makes the machine description easier to read. 7487 7488 There is also a special syntax for strings, which can be useful when C 7489 code is embedded in a machine description. Wherever a string can 7490 appear, it is also valid to write a C-style brace block. The entire 7491 brace block, including the outermost pair of braces, is considered to be 7492 the string constant. Double quote characters inside the braces are not 7493 special. Therefore, if you write string constants in the C code, you 7494 need not escape each quote character with a backslash. 7495 7496 A vector contains an arbitrary number of pointers to expressions. The 7497 number of elements in the vector is explicitly present in the vector. 7498 The written form of a vector consists of square brackets (`[...]') 7499 surrounding the elements, in sequence and with whitespace separating 7500 them. Vectors of length zero are not created; null pointers are used 7501 instead. 7502 7503 Expressions are classified by "expression codes" (also called RTX 7504 codes). The expression code is a name defined in `rtl.def', which is 7505 also (in uppercase) a C enumeration constant. The possible expression 7506 codes and their meanings are machine-independent. The code of an RTX 7507 can be extracted with the macro `GET_CODE (X)' and altered with 7508 `PUT_CODE (X, NEWCODE)'. 7509 7510 The expression code determines how many operands the expression 7511 contains, and what kinds of objects they are. In RTL, unlike Lisp, you 7512 cannot tell by looking at an operand what kind of object it is. 7513 Instead, you must know from its context--from the expression code of 7514 the containing expression. For example, in an expression of code 7515 `subreg', the first operand is to be regarded as an expression and the 7516 second operand as an integer. In an expression of code `plus', there 7517 are two operands, both of which are to be regarded as expressions. In 7518 a `symbol_ref' expression, there is one operand, which is to be 7519 regarded as a string. 7520 7521 Expressions are written as parentheses containing the name of the 7522 expression type, its flags and machine mode if any, and then the 7523 operands of the expression (separated by spaces). 7524 7525 Expression code names in the `md' file are written in lowercase, but 7526 when they appear in C code they are written in uppercase. In this 7527 manual, they are shown as follows: `const_int'. 7528 7529 In a few contexts a null pointer is valid where an expression is 7530 normally wanted. The written form of this is `(nil)'. 7531 7532 7533 File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 7534 7535 10.2 RTL Classes and Formats 7536 ============================ 7537 7538 The various expression codes are divided into several "classes", which 7539 are represented by single characters. You can determine the class of 7540 an RTX code with the macro `GET_RTX_CLASS (CODE)'. Currently, 7541 `rtl.def' defines these classes: 7542 7543 `RTX_OBJ' 7544 An RTX code that represents an actual object, such as a register 7545 (`REG') or a memory location (`MEM', `SYMBOL_REF'). `LO_SUM') is 7546 also included; instead, `SUBREG' and `STRICT_LOW_PART' are not in 7547 this class, but in class `x'. 7548 7549 `RTX_CONST_OBJ' 7550 An RTX code that represents a constant object. `HIGH' is also 7551 included in this class. 7552 7553 `RTX_COMPARE' 7554 An RTX code for a non-symmetric comparison, such as `GEU' or `LT'. 7555 7556 `RTX_COMM_COMPARE' 7557 An RTX code for a symmetric (commutative) comparison, such as `EQ' 7558 or `ORDERED'. 7559 7560 `RTX_UNARY' 7561 An RTX code for a unary arithmetic operation, such as `NEG', 7562 `NOT', or `ABS'. This category also includes value extension 7563 (sign or zero) and conversions between integer and floating point. 7564 7565 `RTX_COMM_ARITH' 7566 An RTX code for a commutative binary operation, such as `PLUS' or 7567 `AND'. `NE' and `EQ' are comparisons, so they have class `<'. 7568 7569 `RTX_BIN_ARITH' 7570 An RTX code for a non-commutative binary operation, such as 7571 `MINUS', `DIV', or `ASHIFTRT'. 7572 7573 `RTX_BITFIELD_OPS' 7574 An RTX code for a bit-field operation. Currently only 7575 `ZERO_EXTRACT' and `SIGN_EXTRACT'. These have three inputs and 7576 are lvalues (so they can be used for insertion as well). *Note 7577 Bit-Fields::. 7578 7579 `RTX_TERNARY' 7580 An RTX code for other three input operations. Currently only 7581 `IF_THEN_ELSE', `VEC_MERGE', `SIGN_EXTRACT', `ZERO_EXTRACT', and 7582 `FMA'. 7583 7584 `RTX_INSN' 7585 An RTX code for an entire instruction: `INSN', `JUMP_INSN', and 7586 `CALL_INSN'. *Note Insns::. 7587 7588 `RTX_MATCH' 7589 An RTX code for something that matches in insns, such as 7590 `MATCH_DUP'. These only occur in machine descriptions. 7591 7592 `RTX_AUTOINC' 7593 An RTX code for an auto-increment addressing mode, such as 7594 `POST_INC'. 7595 7596 `RTX_EXTRA' 7597 All other RTX codes. This category includes the remaining codes 7598 used only in machine descriptions (`DEFINE_*', etc.). It also 7599 includes all the codes describing side effects (`SET', `USE', 7600 `CLOBBER', etc.) and the non-insns that may appear on an insn 7601 chain, such as `NOTE', `BARRIER', and `CODE_LABEL'. `SUBREG' is 7602 also part of this class. 7603 7604 For each expression code, `rtl.def' specifies the number of contained 7605 objects and their kinds using a sequence of characters called the 7606 "format" of the expression code. For example, the format of `subreg' 7607 is `ei'. 7608 7609 These are the most commonly used format characters: 7610 7611 `e' 7612 An expression (actually a pointer to an expression). 7613 7614 `i' 7615 An integer. 7616 7617 `w' 7618 A wide integer. 7619 7620 `s' 7621 A string. 7622 7623 `E' 7624 A vector of expressions. 7625 7626 A few other format characters are used occasionally: 7627 7628 `u' 7629 `u' is equivalent to `e' except that it is printed differently in 7630 debugging dumps. It is used for pointers to insns. 7631 7632 `n' 7633 `n' is equivalent to `i' except that it is printed differently in 7634 debugging dumps. It is used for the line number or code number of 7635 a `note' insn. 7636 7637 `S' 7638 `S' indicates a string which is optional. In the RTL objects in 7639 core, `S' is equivalent to `s', but when the object is read, from 7640 an `md' file, the string value of this operand may be omitted. An 7641 omitted string is taken to be the null string. 7642 7643 `V' 7644 `V' indicates a vector which is optional. In the RTL objects in 7645 core, `V' is equivalent to `E', but when the object is read from 7646 an `md' file, the vector value of this operand may be omitted. An 7647 omitted vector is effectively the same as a vector of no elements. 7648 7649 `B' 7650 `B' indicates a pointer to basic block structure. 7651 7652 `0' 7653 `0' means a slot whose contents do not fit any normal category. 7654 `0' slots are not printed at all in dumps, and are often used in 7655 special ways by small parts of the compiler. 7656 7657 There are macros to get the number of operands and the format of an 7658 expression code: 7659 7660 `GET_RTX_LENGTH (CODE)' 7661 Number of operands of an RTX of code CODE. 7662 7663 `GET_RTX_FORMAT (CODE)' 7664 The format of an RTX of code CODE, as a C string. 7665 7666 Some classes of RTX codes always have the same format. For example, it 7667 is safe to assume that all comparison operations have format `ee'. 7668 7669 `1' 7670 All codes of this class have format `e'. 7671 7672 `<' 7673 `c' 7674 `2' 7675 All codes of these classes have format `ee'. 7676 7677 `b' 7678 `3' 7679 All codes of these classes have format `eee'. 7680 7681 `i' 7682 All codes of this class have formats that begin with `iuueiee'. 7683 *Note Insns::. Note that not all RTL objects linked onto an insn 7684 chain are of class `i'. 7685 7686 `o' 7687 `m' 7688 `x' 7689 You can make no assumptions about the format of these codes. 7690 7691 7692 File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 7693 7694 10.3 Access to Operands 7695 ======================= 7696 7697 Operands of expressions are accessed using the macros `XEXP', `XINT', 7698 `XWINT' and `XSTR'. Each of these macros takes two arguments: an 7699 expression-pointer (RTX) and an operand number (counting from zero). 7700 Thus, 7701 7702 XEXP (X, 2) 7703 7704 accesses operand 2 of expression X, as an expression. 7705 7706 XINT (X, 2) 7707 7708 accesses the same operand as an integer. `XSTR', used in the same 7709 fashion, would access it as a string. 7710 7711 Any operand can be accessed as an integer, as an expression or as a 7712 string. You must choose the correct method of access for the kind of 7713 value actually stored in the operand. You would do this based on the 7714 expression code of the containing expression. That is also how you 7715 would know how many operands there are. 7716 7717 For example, if X is a `subreg' expression, you know that it has two 7718 operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, 7719 1)'. If you did `XINT (X, 0)', you would get the address of the 7720 expression operand but cast as an integer; that might occasionally be 7721 useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP 7722 (X, 1)' would also compile without error, and would return the second, 7723 integer operand cast as an expression pointer, which would probably 7724 result in a crash when accessed. Nothing stops you from writing `XEXP 7725 (X, 28)' either, but this will access memory past the end of the 7726 expression with unpredictable results. 7727 7728 Access to operands which are vectors is more complicated. You can use 7729 the macro `XVEC' to get the vector-pointer itself, or the macros 7730 `XVECEXP' and `XVECLEN' to access the elements and length of a vector. 7731 7732 `XVEC (EXP, IDX)' 7733 Access the vector-pointer which is operand number IDX in EXP. 7734 7735 `XVECLEN (EXP, IDX)' 7736 Access the length (number of elements) in the vector which is in 7737 operand number IDX in EXP. This value is an `int'. 7738 7739 `XVECEXP (EXP, IDX, ELTNUM)' 7740 Access element number ELTNUM in the vector which is in operand 7741 number IDX in EXP. This value is an RTX. 7742 7743 It is up to you to make sure that ELTNUM is not negative and is 7744 less than `XVECLEN (EXP, IDX)'. 7745 7746 All the macros defined in this section expand into lvalues and 7747 therefore can be used to assign the operands, lengths and vector 7748 elements as well as to access them. 7749 7750 7751 File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 7752 7753 10.4 Access to Special Operands 7754 =============================== 7755 7756 Some RTL nodes have special annotations associated with them. 7757 7758 `MEM' 7759 7760 `MEM_ALIAS_SET (X)' 7761 If 0, X is not in any alias set, and may alias anything. 7762 Otherwise, X can only alias `MEM's in a conflicting alias 7763 set. This value is set in a language-dependent manner in the 7764 front-end, and should not be altered in the back-end. In 7765 some front-ends, these numbers may correspond in some way to 7766 types, or other language-level entities, but they need not, 7767 and the back-end makes no such assumptions. These set 7768 numbers are tested with `alias_sets_conflict_p'. 7769 7770 `MEM_EXPR (X)' 7771 If this register is known to hold the value of some user-level 7772 declaration, this is that tree node. It may also be a 7773 `COMPONENT_REF', in which case this is some field reference, 7774 and `TREE_OPERAND (X, 0)' contains the declaration, or 7775 another `COMPONENT_REF', or null if there is no compile-time 7776 object associated with the reference. 7777 7778 `MEM_OFFSET_KNOWN_P (X)' 7779 True if the offset of the memory reference from `MEM_EXPR' is 7780 known. `MEM_OFFSET (X)' provides the offset if so. 7781 7782 `MEM_OFFSET (X)' 7783 The offset from the start of `MEM_EXPR'. The value is only 7784 valid if `MEM_OFFSET_KNOWN_P (X)' is true. 7785 7786 `MEM_SIZE_KNOWN_P (X)' 7787 True if the size of the memory reference is known. `MEM_SIZE 7788 (X)' provides its size if so. 7789 7790 `MEM_SIZE (X)' 7791 The size in bytes of the memory reference. This is mostly 7792 relevant for `BLKmode' references as otherwise the size is 7793 implied by the mode. The value is only valid if 7794 `MEM_SIZE_KNOWN_P (X)' is true. 7795 7796 `MEM_ALIGN (X)' 7797 The known alignment in bits of the memory reference. 7798 7799 `MEM_ADDR_SPACE (X)' 7800 The address space of the memory reference. This will 7801 commonly be zero for the generic address space. 7802 7803 `REG' 7804 7805 `ORIGINAL_REGNO (X)' 7806 This field holds the number the register "originally" had; 7807 for a pseudo register turned into a hard reg this will hold 7808 the old pseudo register number. 7809 7810 `REG_EXPR (X)' 7811 If this register is known to hold the value of some user-level 7812 declaration, this is that tree node. 7813 7814 `REG_OFFSET (X)' 7815 If this register is known to hold the value of some user-level 7816 declaration, this is the offset into that logical storage. 7817 7818 `SYMBOL_REF' 7819 7820 `SYMBOL_REF_DECL (X)' 7821 If the `symbol_ref' X was created for a `VAR_DECL' or a 7822 `FUNCTION_DECL', that tree is recorded here. If this value is 7823 null, then X was created by back end code generation routines, 7824 and there is no associated front end symbol table entry. 7825 7826 `SYMBOL_REF_DECL' may also point to a tree of class `'c'', 7827 that is, some sort of constant. In this case, the 7828 `symbol_ref' is an entry in the per-file constant pool; 7829 again, there is no associated front end symbol table entry. 7830 7831 `SYMBOL_REF_CONSTANT (X)' 7832 If `CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 7833 pool entry for X. It is null otherwise. 7834 7835 `SYMBOL_REF_DATA (X)' 7836 A field of opaque type used to store `SYMBOL_REF_DECL' or 7837 `SYMBOL_REF_CONSTANT'. 7838 7839 `SYMBOL_REF_FLAGS (X)' 7840 In a `symbol_ref', this is used to communicate various 7841 predicates about the symbol. Some of these are common enough 7842 to be computed by common code, some are specific to the 7843 target. The common bits are: 7844 7845 `SYMBOL_FLAG_FUNCTION' 7846 Set if the symbol refers to a function. 7847 7848 `SYMBOL_FLAG_LOCAL' 7849 Set if the symbol is local to this "module". See 7850 `TARGET_BINDS_LOCAL_P'. 7851 7852 `SYMBOL_FLAG_EXTERNAL' 7853 Set if this symbol is not defined in this translation 7854 unit. Note that this is not the inverse of 7855 `SYMBOL_FLAG_LOCAL'. 7856 7857 `SYMBOL_FLAG_SMALL' 7858 Set if the symbol is located in the small data section. 7859 See `TARGET_IN_SMALL_DATA_P'. 7860 7861 `SYMBOL_REF_TLS_MODEL (X)' 7862 This is a multi-bit field accessor that returns the 7863 `tls_model' to be used for a thread-local storage 7864 symbol. It returns zero for non-thread-local symbols. 7865 7866 `SYMBOL_FLAG_HAS_BLOCK_INFO' 7867 Set if the symbol has `SYMBOL_REF_BLOCK' and 7868 `SYMBOL_REF_BLOCK_OFFSET' fields. 7869 7870 `SYMBOL_FLAG_ANCHOR' 7871 Set if the symbol is used as a section anchor. "Section 7872 anchors" are symbols that have a known position within 7873 an `object_block' and that can be used to access nearby 7874 members of that block. They are used to implement 7875 `-fsection-anchors'. 7876 7877 If this flag is set, then `SYMBOL_FLAG_HAS_BLOCK_INFO' 7878 will be too. 7879 7880 Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for 7881 the target's use. 7882 7883 `SYMBOL_REF_BLOCK (X)' 7884 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the `object_block' 7885 structure to which the symbol belongs, or `NULL' if it has not 7886 been assigned a block. 7887 7888 `SYMBOL_REF_BLOCK_OFFSET (X)' 7889 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 7890 the first object in `SYMBOL_REF_BLOCK (X)'. The value is negative 7891 if X has not yet been assigned to a block, or it has not been 7892 given an offset within that block. 7893 7894 7895 File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 7896 7897 10.5 Flags in an RTL Expression 7898 =============================== 7899 7900 RTL expressions contain several flags (one-bit bit-fields) that are 7901 used in certain types of expression. Most often they are accessed with 7902 the following macros, which expand into lvalues. 7903 7904 `CONSTANT_POOL_ADDRESS_P (X)' 7905 Nonzero in a `symbol_ref' if it refers to part of the current 7906 function's constant pool. For most targets these addresses are in 7907 a `.rodata' section entirely separate from the function, but for 7908 some targets the addresses are close to the beginning of the 7909 function. In either case GCC assumes these addresses can be 7910 addressed directly, perhaps with the help of base registers. 7911 Stored in the `unchanging' field and printed as `/u'. 7912 7913 `RTL_CONST_CALL_P (X)' 7914 In a `call_insn' indicates that the insn represents a call to a 7915 const function. Stored in the `unchanging' field and printed as 7916 `/u'. 7917 7918 `RTL_PURE_CALL_P (X)' 7919 In a `call_insn' indicates that the insn represents a call to a 7920 pure function. Stored in the `return_val' field and printed as 7921 `/i'. 7922 7923 `RTL_CONST_OR_PURE_CALL_P (X)' 7924 In a `call_insn', true if `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' 7925 is true. 7926 7927 `RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 7928 In a `call_insn' indicates that the insn represents a possibly 7929 infinite looping call to a const or pure function. Stored in the 7930 `call' field and printed as `/c'. Only true if one of 7931 `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' is true. 7932 7933 `INSN_ANNULLED_BRANCH_P (X)' 7934 In a `jump_insn', `call_insn', or `insn' indicates that the branch 7935 is an annulling one. See the discussion under `sequence' below. 7936 Stored in the `unchanging' field and printed as `/u'. 7937 7938 `INSN_DELETED_P (X)' 7939 In an `insn', `call_insn', `jump_insn', `code_label', `barrier', 7940 or `note', nonzero if the insn has been deleted. Stored in the 7941 `volatil' field and printed as `/v'. 7942 7943 `INSN_FROM_TARGET_P (X)' 7944 In an `insn' or `jump_insn' or `call_insn' in a delay slot of a 7945 branch, indicates that the insn is from the target of the branch. 7946 If the branch insn has `INSN_ANNULLED_BRANCH_P' set, this insn 7947 will only be executed if the branch is taken. For annulled 7948 branches with `INSN_FROM_TARGET_P' clear, the insn will be 7949 executed only if the branch is not taken. When 7950 `INSN_ANNULLED_BRANCH_P' is not set, this insn will always be 7951 executed. Stored in the `in_struct' field and printed as `/s'. 7952 7953 `LABEL_PRESERVE_P (X)' 7954 In a `code_label' or `note', indicates that the label is 7955 referenced by code or data not visible to the RTL of a given 7956 function. Labels referenced by a non-local goto will have this 7957 bit set. Stored in the `in_struct' field and printed as `/s'. 7958 7959 `LABEL_REF_NONLOCAL_P (X)' 7960 In `label_ref' and `reg_label' expressions, nonzero if this is a 7961 reference to a non-local label. Stored in the `volatil' field and 7962 printed as `/v'. 7963 7964 `MEM_KEEP_ALIAS_SET_P (X)' 7965 In `mem' expressions, 1 if we should keep the alias set for this 7966 mem unchanged when we access a component. Set to 1, for example, 7967 when we are already in a non-addressable component of an aggregate. 7968 Stored in the `jump' field and printed as `/j'. 7969 7970 `MEM_VOLATILE_P (X)' 7971 In `mem', `asm_operands', and `asm_input' expressions, nonzero for 7972 volatile memory references. Stored in the `volatil' field and 7973 printed as `/v'. 7974 7975 `MEM_NOTRAP_P (X)' 7976 In `mem', nonzero for memory references that will not trap. 7977 Stored in the `call' field and printed as `/c'. 7978 7979 `MEM_POINTER (X)' 7980 Nonzero in a `mem' if the memory reference holds a pointer. 7981 Stored in the `frame_related' field and printed as `/f'. 7982 7983 `REG_FUNCTION_VALUE_P (X)' 7984 Nonzero in a `reg' if it is the place in which this function's 7985 value is going to be returned. (This happens only in a hard 7986 register.) Stored in the `return_val' field and printed as `/i'. 7987 7988 `REG_POINTER (X)' 7989 Nonzero in a `reg' if the register holds a pointer. Stored in the 7990 `frame_related' field and printed as `/f'. 7991 7992 `REG_USERVAR_P (X)' 7993 In a `reg', nonzero if it corresponds to a variable present in the 7994 user's source code. Zero for temporaries generated internally by 7995 the compiler. Stored in the `volatil' field and printed as `/v'. 7996 7997 The same hard register may be used also for collecting the values 7998 of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero 7999 in this kind of use. 8000 8001 `RTX_FRAME_RELATED_P (X)' 8002 Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or 8003 `set' which is part of a function prologue and sets the stack 8004 pointer, sets the frame pointer, or saves a register. This flag 8005 should also be set on an instruction that sets up a temporary 8006 register to use in place of the frame pointer. Stored in the 8007 `frame_related' field and printed as `/f'. 8008 8009 In particular, on RISC targets where there are limits on the sizes 8010 of immediate constants, it is sometimes impossible to reach the 8011 register save area directly from the stack pointer. In that case, 8012 a temporary register is used that is near enough to the register 8013 save area, and the Canonical Frame Address, i.e., DWARF2's logical 8014 frame pointer, register must (temporarily) be changed to be this 8015 temporary register. So, the instruction that sets this temporary 8016 register must be marked as `RTX_FRAME_RELATED_P'. 8017 8018 If the marked instruction is overly complex (defined in terms of 8019 what `dwarf2out_frame_debug_expr' can handle), you will also have 8020 to create a `REG_FRAME_RELATED_EXPR' note and attach it to the 8021 instruction. This note should contain a simple expression of the 8022 computation performed by this instruction, i.e., one that 8023 `dwarf2out_frame_debug_expr' can handle. 8024 8025 This flag is required for exception handling support on targets 8026 with RTL prologues. 8027 8028 `MEM_READONLY_P (X)' 8029 Nonzero in a `mem', if the memory is statically allocated and 8030 read-only. 8031 8032 Read-only in this context means never modified during the lifetime 8033 of the program, not necessarily in ROM or in write-disabled pages. 8034 A common example of the later is a shared library's global offset 8035 table. This table is initialized by the runtime loader, so the 8036 memory is technically writable, but after control is transferred 8037 from the runtime loader to the application, this memory will never 8038 be subsequently modified. 8039 8040 Stored in the `unchanging' field and printed as `/u'. 8041 8042 `SCHED_GROUP_P (X)' 8043 During instruction scheduling, in an `insn', `call_insn' or 8044 `jump_insn', indicates that the previous insn must be scheduled 8045 together with this insn. This is used to ensure that certain 8046 groups of instructions will not be split up by the instruction 8047 scheduling pass, for example, `use' insns before a `call_insn' may 8048 not be separated from the `call_insn'. Stored in the `in_struct' 8049 field and printed as `/s'. 8050 8051 `SET_IS_RETURN_P (X)' 8052 For a `set', nonzero if it is for a return. Stored in the `jump' 8053 field and printed as `/j'. 8054 8055 `SIBLING_CALL_P (X)' 8056 For a `call_insn', nonzero if the insn is a sibling call. Stored 8057 in the `jump' field and printed as `/j'. 8058 8059 `STRING_POOL_ADDRESS_P (X)' 8060 For a `symbol_ref' expression, nonzero if it addresses this 8061 function's string constant pool. Stored in the `frame_related' 8062 field and printed as `/f'. 8063 8064 `SUBREG_PROMOTED_UNSIGNED_P (X)' 8065 Returns a value greater then zero for a `subreg' that has 8066 `SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 8067 kept zero-extended, zero if it is kept sign-extended, and less 8068 then zero if it is extended some other way via the `ptr_extend' 8069 instruction. Stored in the `unchanging' field and `volatil' 8070 field, printed as `/u' and `/v'. This macro may only be used to 8071 get the value it may not be used to change the value. Use 8072 `SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 8073 8074 `SUBREG_PROMOTED_UNSIGNED_SET (X)' 8075 Set the `unchanging' and `volatil' fields in a `subreg' to reflect 8076 zero, sign, or other extension. If `volatil' is zero, then 8077 `unchanging' as nonzero means zero extension and as zero means 8078 sign extension. If `volatil' is nonzero then some other type of 8079 extension was done via the `ptr_extend' instruction. 8080 8081 `SUBREG_PROMOTED_VAR_P (X)' 8082 Nonzero in a `subreg' if it was made when accessing an object that 8083 was promoted to a wider mode in accord with the `PROMOTED_MODE' 8084 machine description macro (*note Storage Layout::). In this case, 8085 the mode of the `subreg' is the declared mode of the object and 8086 the mode of `SUBREG_REG' is the mode of the register that holds 8087 the object. Promoted variables are always either sign- or 8088 zero-extended to the wider mode on every assignment. Stored in 8089 the `in_struct' field and printed as `/s'. 8090 8091 `SYMBOL_REF_USED (X)' 8092 In a `symbol_ref', indicates that X has been used. This is 8093 normally only used to ensure that X is only declared external 8094 once. Stored in the `used' field. 8095 8096 `SYMBOL_REF_WEAK (X)' 8097 In a `symbol_ref', indicates that X has been declared weak. 8098 Stored in the `return_val' field and printed as `/i'. 8099 8100 `SYMBOL_REF_FLAG (X)' 8101 In a `symbol_ref', this is used as a flag for machine-specific 8102 purposes. Stored in the `volatil' field and printed as `/v'. 8103 8104 Most uses of `SYMBOL_REF_FLAG' are historic and may be subsumed by 8105 `SYMBOL_REF_FLAGS'. Certainly use of `SYMBOL_REF_FLAGS' is 8106 mandatory if the target requires more than one bit of storage. 8107 8108 `PREFETCH_SCHEDULE_BARRIER_P (X)' 8109 In a `prefetch', indicates that the prefetch is a scheduling 8110 barrier. No other INSNs will be moved over it. Stored in the 8111 `volatil' field and printed as `/v'. 8112 8113 These are the fields to which the above macros refer: 8114 8115 `call' 8116 In a `mem', 1 means that the memory reference will not trap. 8117 8118 In a `call', 1 means that this pure or const call may possibly 8119 infinite loop. 8120 8121 In an RTL dump, this flag is represented as `/c'. 8122 8123 `frame_related' 8124 In an `insn' or `set' expression, 1 means that it is part of a 8125 function prologue and sets the stack pointer, sets the frame 8126 pointer, saves a register, or sets up a temporary register to use 8127 in place of the frame pointer. 8128 8129 In `reg' expressions, 1 means that the register holds a pointer. 8130 8131 In `mem' expressions, 1 means that the memory reference holds a 8132 pointer. 8133 8134 In `symbol_ref' expressions, 1 means that the reference addresses 8135 this function's string constant pool. 8136 8137 In an RTL dump, this flag is represented as `/f'. 8138 8139 `in_struct' 8140 In `reg' expressions, it is 1 if the register has its entire life 8141 contained within the test expression of some loop. 8142 8143 In `subreg' expressions, 1 means that the `subreg' is accessing an 8144 object that has had its mode promoted from a wider mode. 8145 8146 In `label_ref' expressions, 1 means that the referenced label is 8147 outside the innermost loop containing the insn in which the 8148 `label_ref' was found. 8149 8150 In `code_label' expressions, it is 1 if the label may never be 8151 deleted. This is used for labels which are the target of 8152 non-local gotos. Such a label that would have been deleted is 8153 replaced with a `note' of type `NOTE_INSN_DELETED_LABEL'. 8154 8155 In an `insn' during dead-code elimination, 1 means that the insn is 8156 dead code. 8157 8158 In an `insn' or `jump_insn' during reorg for an insn in the delay 8159 slot of a branch, 1 means that this insn is from the target of the 8160 branch. 8161 8162 In an `insn' during instruction scheduling, 1 means that this insn 8163 must be scheduled as part of a group together with the previous 8164 insn. 8165 8166 In an RTL dump, this flag is represented as `/s'. 8167 8168 `return_val' 8169 In `reg' expressions, 1 means the register contains the value to 8170 be returned by the current function. On machines that pass 8171 parameters in registers, the same register number may be used for 8172 parameters as well, but this flag is not set on such uses. 8173 8174 In `symbol_ref' expressions, 1 means the referenced symbol is weak. 8175 8176 In `call' expressions, 1 means the call is pure. 8177 8178 In an RTL dump, this flag is represented as `/i'. 8179 8180 `jump' 8181 In a `mem' expression, 1 means we should keep the alias set for 8182 this mem unchanged when we access a component. 8183 8184 In a `set', 1 means it is for a return. 8185 8186 In a `call_insn', 1 means it is a sibling call. 8187 8188 In an RTL dump, this flag is represented as `/j'. 8189 8190 `unchanging' 8191 In `reg' and `mem' expressions, 1 means that the value of the 8192 expression never changes. 8193 8194 In `subreg' expressions, it is 1 if the `subreg' references an 8195 unsigned object whose mode has been promoted to a wider mode. 8196 8197 In an `insn' or `jump_insn' in the delay slot of a branch 8198 instruction, 1 means an annulling branch should be used. 8199 8200 In a `symbol_ref' expression, 1 means that this symbol addresses 8201 something in the per-function constant pool. 8202 8203 In a `call_insn' 1 means that this instruction is a call to a const 8204 function. 8205 8206 In an RTL dump, this flag is represented as `/u'. 8207 8208 `used' 8209 This flag is used directly (without an access macro) at the end of 8210 RTL generation for a function, to count the number of times an 8211 expression appears in insns. Expressions that appear more than 8212 once are copied, according to the rules for shared structure 8213 (*note Sharing::). 8214 8215 For a `reg', it is used directly (without an access macro) by the 8216 leaf register renumbering code to ensure that each register is only 8217 renumbered once. 8218 8219 In a `symbol_ref', it indicates that an external declaration for 8220 the symbol has already been written. 8221 8222 `volatil' 8223 In a `mem', `asm_operands', or `asm_input' expression, it is 1 if 8224 the memory reference is volatile. Volatile memory references may 8225 not be deleted, reordered or combined. 8226 8227 In a `symbol_ref' expression, it is used for machine-specific 8228 purposes. 8229 8230 In a `reg' expression, it is 1 if the value is a user-level 8231 variable. 0 indicates an internal compiler temporary. 8232 8233 In an `insn', 1 means the insn has been deleted. 8234 8235 In `label_ref' and `reg_label' expressions, 1 means a reference to 8236 a non-local label. 8237 8238 In `prefetch' expressions, 1 means that the containing insn is a 8239 scheduling barrier. 8240 8241 In an RTL dump, this flag is represented as `/v'. 8242 8243 8244 File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 8245 8246 10.6 Machine Modes 8247 ================== 8248 8249 A machine mode describes a size of data object and the representation 8250 used for it. In the C code, machine modes are represented by an 8251 enumeration type, `enum machine_mode', defined in `machmode.def'. Each 8252 RTL expression has room for a machine mode and so do certain kinds of 8253 tree expressions (declarations and types, to be precise). 8254 8255 In debugging dumps and machine descriptions, the machine mode of an RTL 8256 expression is written after the expression code with a colon to separate 8257 them. The letters `mode' which appear at the end of each machine mode 8258 name are omitted. For example, `(reg:SI 38)' is a `reg' expression 8259 with machine mode `SImode'. If the mode is `VOIDmode', it is not 8260 written at all. 8261 8262 Here is a table of machine modes. The term "byte" below refers to an 8263 object of `BITS_PER_UNIT' bits (*note Storage Layout::). 8264 8265 `BImode' 8266 "Bit" mode represents a single bit, for predicate registers. 8267 8268 `QImode' 8269 "Quarter-Integer" mode represents a single byte treated as an 8270 integer. 8271 8272 `HImode' 8273 "Half-Integer" mode represents a two-byte integer. 8274 8275 `PSImode' 8276 "Partial Single Integer" mode represents an integer which occupies 8277 four bytes but which doesn't really use all four. On some 8278 machines, this is the right mode to use for pointers. 8279 8280 `SImode' 8281 "Single Integer" mode represents a four-byte integer. 8282 8283 `PDImode' 8284 "Partial Double Integer" mode represents an integer which occupies 8285 eight bytes but which doesn't really use all eight. On some 8286 machines, this is the right mode to use for certain pointers. 8287 8288 `DImode' 8289 "Double Integer" mode represents an eight-byte integer. 8290 8291 `TImode' 8292 "Tetra Integer" (?) mode represents a sixteen-byte integer. 8293 8294 `OImode' 8295 "Octa Integer" (?) mode represents a thirty-two-byte integer. 8296 8297 `QFmode' 8298 "Quarter-Floating" mode represents a quarter-precision (single 8299 byte) floating point number. 8300 8301 `HFmode' 8302 "Half-Floating" mode represents a half-precision (two byte) 8303 floating point number. 8304 8305 `TQFmode' 8306 "Three-Quarter-Floating" (?) mode represents a 8307 three-quarter-precision (three byte) floating point number. 8308 8309 `SFmode' 8310 "Single Floating" mode represents a four byte floating point 8311 number. In the common case, of a processor with IEEE arithmetic 8312 and 8-bit bytes, this is a single-precision IEEE floating point 8313 number; it can also be used for double-precision (on processors 8314 with 16-bit bytes) and single-precision VAX and IBM types. 8315 8316 `DFmode' 8317 "Double Floating" mode represents an eight byte floating point 8318 number. In the common case, of a processor with IEEE arithmetic 8319 and 8-bit bytes, this is a double-precision IEEE floating point 8320 number. 8321 8322 `XFmode' 8323 "Extended Floating" mode represents an IEEE extended floating point 8324 number. This mode only has 80 meaningful bits (ten bytes). Some 8325 processors require such numbers to be padded to twelve bytes, 8326 others to sixteen; this mode is used for either. 8327 8328 `SDmode' 8329 "Single Decimal Floating" mode represents a four byte decimal 8330 floating point number (as distinct from conventional binary 8331 floating point). 8332 8333 `DDmode' 8334 "Double Decimal Floating" mode represents an eight byte decimal 8335 floating point number. 8336 8337 `TDmode' 8338 "Tetra Decimal Floating" mode represents a sixteen byte decimal 8339 floating point number all 128 of whose bits are meaningful. 8340 8341 `TFmode' 8342 "Tetra Floating" mode represents a sixteen byte floating point 8343 number all 128 of whose bits are meaningful. One common use is the 8344 IEEE quad-precision format. 8345 8346 `QQmode' 8347 "Quarter-Fractional" mode represents a single byte treated as a 8348 signed fractional number. The default format is "s.7". 8349 8350 `HQmode' 8351 "Half-Fractional" mode represents a two-byte signed fractional 8352 number. The default format is "s.15". 8353 8354 `SQmode' 8355 "Single Fractional" mode represents a four-byte signed fractional 8356 number. The default format is "s.31". 8357 8358 `DQmode' 8359 "Double Fractional" mode represents an eight-byte signed 8360 fractional number. The default format is "s.63". 8361 8362 `TQmode' 8363 "Tetra Fractional" mode represents a sixteen-byte signed 8364 fractional number. The default format is "s.127". 8365 8366 `UQQmode' 8367 "Unsigned Quarter-Fractional" mode represents a single byte 8368 treated as an unsigned fractional number. The default format is 8369 ".8". 8370 8371 `UHQmode' 8372 "Unsigned Half-Fractional" mode represents a two-byte unsigned 8373 fractional number. The default format is ".16". 8374 8375 `USQmode' 8376 "Unsigned Single Fractional" mode represents a four-byte unsigned 8377 fractional number. The default format is ".32". 8378 8379 `UDQmode' 8380 "Unsigned Double Fractional" mode represents an eight-byte unsigned 8381 fractional number. The default format is ".64". 8382 8383 `UTQmode' 8384 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 8385 fractional number. The default format is ".128". 8386 8387 `HAmode' 8388 "Half-Accumulator" mode represents a two-byte signed accumulator. 8389 The default format is "s8.7". 8390 8391 `SAmode' 8392 "Single Accumulator" mode represents a four-byte signed 8393 accumulator. The default format is "s16.15". 8394 8395 `DAmode' 8396 "Double Accumulator" mode represents an eight-byte signed 8397 accumulator. The default format is "s32.31". 8398 8399 `TAmode' 8400 "Tetra Accumulator" mode represents a sixteen-byte signed 8401 accumulator. The default format is "s64.63". 8402 8403 `UHAmode' 8404 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 8405 accumulator. The default format is "8.8". 8406 8407 `USAmode' 8408 "Unsigned Single Accumulator" mode represents a four-byte unsigned 8409 accumulator. The default format is "16.16". 8410 8411 `UDAmode' 8412 "Unsigned Double Accumulator" mode represents an eight-byte 8413 unsigned accumulator. The default format is "32.32". 8414 8415 `UTAmode' 8416 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 8417 unsigned accumulator. The default format is "64.64". 8418 8419 `CCmode' 8420 "Condition Code" mode represents the value of a condition code, 8421 which is a machine-specific set of bits used to represent the 8422 result of a comparison operation. Other machine-specific modes 8423 may also be used for the condition code. These modes are not used 8424 on machines that use `cc0' (*note Condition Code::). 8425 8426 `BLKmode' 8427 "Block" mode represents values that are aggregates to which none of 8428 the other modes apply. In RTL, only memory references can have 8429 this mode, and only if they appear in string-move or vector 8430 instructions. On machines which have no such instructions, 8431 `BLKmode' will not appear in RTL. 8432 8433 `VOIDmode' 8434 Void mode means the absence of a mode or an unspecified mode. For 8435 example, RTL expressions of code `const_int' have mode `VOIDmode' 8436 because they can be taken to have whatever mode the context 8437 requires. In debugging dumps of RTL, `VOIDmode' is expressed by 8438 the absence of any mode. 8439 8440 `QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 8441 These modes stand for a complex number represented as a pair of 8442 floating point values. The floating point values are in `QFmode', 8443 `HFmode', `SFmode', `DFmode', `XFmode', and `TFmode', respectively. 8444 8445 `CQImode, CHImode, CSImode, CDImode, CTImode, COImode' 8446 These modes stand for a complex number represented as a pair of 8447 integer values. The integer values are in `QImode', `HImode', 8448 `SImode', `DImode', `TImode', and `OImode', respectively. 8449 8450 The machine description defines `Pmode' as a C macro which expands 8451 into the machine mode used for addresses. Normally this is the mode 8452 whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. 8453 8454 The only modes which a machine description must support are `QImode', 8455 and the modes corresponding to `BITS_PER_WORD', `FLOAT_TYPE_SIZE' and 8456 `DOUBLE_TYPE_SIZE'. The compiler will attempt to use `DImode' for 8457 8-byte structures and unions, but this can be prevented by overriding 8458 the definition of `MAX_FIXED_MODE_SIZE'. Alternatively, you can have 8459 the compiler use `TImode' for 16-byte structures and unions. Likewise, 8460 you can arrange for the C type `short int' to avoid using `HImode'. 8461 8462 Very few explicit references to machine modes remain in the compiler 8463 and these few references will soon be removed. Instead, the machine 8464 modes are divided into mode classes. These are represented by the 8465 enumeration type `enum mode_class' defined in `machmode.h'. The 8466 possible mode classes are: 8467 8468 `MODE_INT' 8469 Integer modes. By default these are `BImode', `QImode', `HImode', 8470 `SImode', `DImode', `TImode', and `OImode'. 8471 8472 `MODE_PARTIAL_INT' 8473 The "partial integer" modes, `PQImode', `PHImode', `PSImode' and 8474 `PDImode'. 8475 8476 `MODE_FLOAT' 8477 Floating point modes. By default these are `QFmode', `HFmode', 8478 `TQFmode', `SFmode', `DFmode', `XFmode' and `TFmode'. 8479 8480 `MODE_DECIMAL_FLOAT' 8481 Decimal floating point modes. By default these are `SDmode', 8482 `DDmode' and `TDmode'. 8483 8484 `MODE_FRACT' 8485 Signed fractional modes. By default these are `QQmode', `HQmode', 8486 `SQmode', `DQmode' and `TQmode'. 8487 8488 `MODE_UFRACT' 8489 Unsigned fractional modes. By default these are `UQQmode', 8490 `UHQmode', `USQmode', `UDQmode' and `UTQmode'. 8491 8492 `MODE_ACCUM' 8493 Signed accumulator modes. By default these are `HAmode', 8494 `SAmode', `DAmode' and `TAmode'. 8495 8496 `MODE_UACCUM' 8497 Unsigned accumulator modes. By default these are `UHAmode', 8498 `USAmode', `UDAmode' and `UTAmode'. 8499 8500 `MODE_COMPLEX_INT' 8501 Complex integer modes. (These are not currently implemented). 8502 8503 `MODE_COMPLEX_FLOAT' 8504 Complex floating point modes. By default these are `QCmode', 8505 `HCmode', `SCmode', `DCmode', `XCmode', and `TCmode'. 8506 8507 `MODE_FUNCTION' 8508 Algol or Pascal function variables including a static chain. 8509 (These are not currently implemented). 8510 8511 `MODE_CC' 8512 Modes representing condition code values. These are `CCmode' plus 8513 any `CC_MODE' modes listed in the `MACHINE-modes.def'. *Note Jump 8514 Patterns::, also see *note Condition Code::. 8515 8516 `MODE_RANDOM' 8517 This is a catchall mode class for modes which don't fit into the 8518 above classes. Currently `VOIDmode' and `BLKmode' are in 8519 `MODE_RANDOM'. 8520 8521 Here are some C macros that relate to machine modes: 8522 8523 `GET_MODE (X)' 8524 Returns the machine mode of the RTX X. 8525 8526 `PUT_MODE (X, NEWMODE)' 8527 Alters the machine mode of the RTX X to be NEWMODE. 8528 8529 `NUM_MACHINE_MODES' 8530 Stands for the number of machine modes available on the target 8531 machine. This is one greater than the largest numeric value of any 8532 machine mode. 8533 8534 `GET_MODE_NAME (M)' 8535 Returns the name of mode M as a string. 8536 8537 `GET_MODE_CLASS (M)' 8538 Returns the mode class of mode M. 8539 8540 `GET_MODE_WIDER_MODE (M)' 8541 Returns the next wider natural mode. For example, the expression 8542 `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. 8543 8544 `GET_MODE_SIZE (M)' 8545 Returns the size in bytes of a datum of mode M. 8546 8547 `GET_MODE_BITSIZE (M)' 8548 Returns the size in bits of a datum of mode M. 8549 8550 `GET_MODE_IBIT (M)' 8551 Returns the number of integral bits of a datum of fixed-point mode 8552 M. 8553 8554 `GET_MODE_FBIT (M)' 8555 Returns the number of fractional bits of a datum of fixed-point 8556 mode M. 8557 8558 `GET_MODE_MASK (M)' 8559 Returns a bitmask containing 1 for all bits in a word that fit 8560 within mode M. This macro can only be used for modes whose 8561 bitsize is less than or equal to `HOST_BITS_PER_INT'. 8562 8563 `GET_MODE_ALIGNMENT (M)' 8564 Return the required alignment, in bits, for an object of mode M. 8565 8566 `GET_MODE_UNIT_SIZE (M)' 8567 Returns the size in bytes of the subunits of a datum of mode M. 8568 This is the same as `GET_MODE_SIZE' except in the case of complex 8569 modes. For them, the unit size is the size of the real or 8570 imaginary part. 8571 8572 `GET_MODE_NUNITS (M)' 8573 Returns the number of units contained in a mode, i.e., 8574 `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. 8575 8576 `GET_CLASS_NARROWEST_MODE (C)' 8577 Returns the narrowest mode in mode class C. 8578 8579 The global variables `byte_mode' and `word_mode' contain modes whose 8580 classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or 8581 `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' 8582 and `SImode', respectively. 8583 8584 8585 File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 8586 8587 10.7 Constant Expression Types 8588 ============================== 8589 8590 The simplest RTL expressions are those that represent constant values. 8591 8592 `(const_int I)' 8593 This type of expression represents the integer value I. I is 8594 customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', 8595 which is equivalent to `XWINT (EXP, 0)'. 8596 8597 Constants generated for modes with fewer bits than in 8598 `HOST_WIDE_INT' must be sign extended to full width (e.g., with 8599 `gen_int_mode'). For constants for modes with more bits than in 8600 `HOST_WIDE_INT' the implied high order bits of that constant are 8601 copies of the top bit. Note however that values are neither 8602 inherently signed nor inherently unsigned; where necessary, 8603 signedness is determined by the rtl operation instead. 8604 8605 There is only one expression object for the integer value zero; it 8606 is the value of the variable `const0_rtx'. Likewise, the only 8607 expression for integer value one is found in `const1_rtx', the only 8608 expression for integer value two is found in `const2_rtx', and the 8609 only expression for integer value negative one is found in 8610 `constm1_rtx'. Any attempt to create an expression of code 8611 `const_int' and value zero, one, two or negative one will return 8612 `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as 8613 appropriate. 8614 8615 Similarly, there is only one object for the integer whose value is 8616 `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If 8617 `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will 8618 point to the same object. If `STORE_FLAG_VALUE' is -1, 8619 `const_true_rtx' and `constm1_rtx' will point to the same object. 8620 8621 `(const_double:M I0 I1 ...)' 8622 Represents either a floating-point constant of mode M or an 8623 integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' 8624 bits but small enough to fit within twice that number of bits (GCC 8625 does not provide a mechanism to represent even larger constants). 8626 In the latter case, M will be `VOIDmode'. For integral values 8627 constants for modes with more bits than twice the number in 8628 `HOST_WIDE_INT' the implied high order bits of that constant are 8629 copies of the top bit of `CONST_DOUBLE_HIGH'. Note however that 8630 integral values are neither inherently signed nor inherently 8631 unsigned; where necessary, signedness is determined by the rtl 8632 operation instead. 8633 8634 If M is `VOIDmode', the bits of the value are stored in I0 and I1. 8635 I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and 8636 I1 with `CONST_DOUBLE_HIGH'. 8637 8638 If the constant is floating point (regardless of its precision), 8639 then the number of integers used to store the value depends on the 8640 size of `REAL_VALUE_TYPE' (*note Floating Point::). The integers 8641 represent a floating point number, but not precisely in the target 8642 machine's or host machine's floating point format. To convert 8643 them to the precise bit pattern used by the target machine, use 8644 the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 8645 Output::). 8646 8647 `(const_fixed:M ...)' 8648 Represents a fixed-point constant of mode M. The operand is a 8649 data structure of type `struct fixed_value' and is accessed with 8650 the macro `CONST_FIXED_VALUE'. The high part of data is accessed 8651 with `CONST_FIXED_VALUE_HIGH'; the low part is accessed with 8652 `CONST_FIXED_VALUE_LOW'. 8653 8654 `(const_vector:M [X0 X1 ...])' 8655 Represents a vector constant. The square brackets stand for the 8656 vector containing the constant elements. X0, X1 and so on are the 8657 `const_int', `const_double' or `const_fixed' elements. 8658 8659 The number of units in a `const_vector' is obtained with the macro 8660 `CONST_VECTOR_NUNITS' as in `CONST_VECTOR_NUNITS (V)'. 8661 8662 Individual elements in a vector constant are accessed with the 8663 macro `CONST_VECTOR_ELT' as in `CONST_VECTOR_ELT (V, N)' where V 8664 is the vector constant and N is the element desired. 8665 8666 `(const_string STR)' 8667 Represents a constant string with value STR. Currently this is 8668 used only for insn attributes (*note Insn Attributes::) since 8669 constant strings in C are placed in memory. 8670 8671 `(symbol_ref:MODE SYMBOL)' 8672 Represents the value of an assembler label for data. SYMBOL is a 8673 string that describes the name of the assembler label. If it 8674 starts with a `*', the label is the rest of SYMBOL not including 8675 the `*'. Otherwise, the label is SYMBOL, usually prefixed with 8676 `_'. 8677 8678 The `symbol_ref' contains a mode, which is usually `Pmode'. 8679 Usually that is the only mode for which a symbol is directly valid. 8680 8681 `(label_ref:MODE LABEL)' 8682 Represents the value of an assembler label for code. It contains 8683 one operand, an expression, which must be a `code_label' or a 8684 `note' of type `NOTE_INSN_DELETED_LABEL' that appears in the 8685 instruction sequence to identify the place where the label should 8686 go. 8687 8688 The reason for using a distinct expression type for code label 8689 references is so that jump optimization can distinguish them. 8690 8691 The `label_ref' contains a mode, which is usually `Pmode'. 8692 Usually that is the only mode for which a label is directly valid. 8693 8694 `(const:M EXP)' 8695 Represents a constant that is the result of an assembly-time 8696 arithmetic computation. The operand, EXP, is an expression that 8697 contains only constants (`const_int', `symbol_ref' and `label_ref' 8698 expressions) combined with `plus' and `minus'. However, not all 8699 combinations are valid, since the assembler cannot do arbitrary 8700 arithmetic on relocatable symbols. 8701 8702 M should be `Pmode'. 8703 8704 `(high:M EXP)' 8705 Represents the high-order bits of EXP, usually a `symbol_ref'. 8706 The number of bits is machine-dependent and is normally the number 8707 of bits specified in an instruction that initializes the high 8708 order bits of a register. It is used with `lo_sum' to represent 8709 the typical two-instruction sequence used in RISC machines to 8710 reference a global memory location. 8711 8712 M should be `Pmode'. 8713 8714 The macro `CONST0_RTX (MODE)' refers to an expression with value 0 in 8715 mode MODE. If mode MODE is of mode class `MODE_INT', it returns 8716 `const0_rtx'. If mode MODE is of mode class `MODE_FLOAT', it returns a 8717 `CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 8718 `CONST_VECTOR' expression in mode MODE. Similarly, the macro 8719 `CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 8720 and similarly for `CONST2_RTX'. The `CONST1_RTX' and `CONST2_RTX' 8721 macros are undefined for vector modes. 8722 8723 8724 File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 8725 8726 10.8 Registers and Memory 8727 ========================= 8728 8729 Here are the RTL expression types for describing access to machine 8730 registers and to main memory. 8731 8732 `(reg:M N)' 8733 For small values of the integer N (those that are less than 8734 `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 8735 register number N: a "hard register". For larger values of N, it 8736 stands for a temporary value or "pseudo register". The compiler's 8737 strategy is to generate code assuming an unlimited number of such 8738 pseudo registers, and later convert them into hard registers or 8739 into memory references. 8740 8741 M is the machine mode of the reference. It is necessary because 8742 machines can generally refer to each register in more than one 8743 mode. For example, a register may contain a full word but there 8744 may be instructions to refer to it as a half word or as a single 8745 byte, as well as instructions to refer to it as a floating point 8746 number of various precisions. 8747 8748 Even for a register that the machine can access in only one mode, 8749 the mode must always be specified. 8750 8751 The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine 8752 description, since the number of hard registers on the machine is 8753 an invariant characteristic of the machine. Note, however, that 8754 not all of the machine registers must be general registers. All 8755 the machine registers that can be used for storage of data are 8756 given hard register numbers, even those that can be used only in 8757 certain instructions or can hold only certain types of data. 8758 8759 A hard register may be accessed in various modes throughout one 8760 function, but each pseudo register is given a natural mode and is 8761 accessed only in that mode. When it is necessary to describe an 8762 access to a pseudo register using a nonnatural mode, a `subreg' 8763 expression is used. 8764 8765 A `reg' expression with a machine mode that specifies more than 8766 one word of data may actually stand for several consecutive 8767 registers. If in addition the register number specifies a 8768 hardware register, then it actually represents several consecutive 8769 hardware registers starting with the specified one. 8770 8771 Each pseudo register number used in a function's RTL code is 8772 represented by a unique `reg' expression. 8773 8774 Some pseudo register numbers, those within the range of 8775 `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear 8776 during the RTL generation phase and are eliminated before the 8777 optimization phases. These represent locations in the stack frame 8778 that cannot be determined until RTL generation for the function 8779 has been completed. The following virtual register numbers are 8780 defined: 8781 8782 `VIRTUAL_INCOMING_ARGS_REGNUM' 8783 This points to the first word of the incoming arguments 8784 passed on the stack. Normally these arguments are placed 8785 there by the caller, but the callee may have pushed some 8786 arguments that were previously passed in registers. 8787 8788 When RTL generation is complete, this virtual register is 8789 replaced by the sum of the register given by 8790 `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'. 8791 8792 `VIRTUAL_STACK_VARS_REGNUM' 8793 If `FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 8794 points to immediately above the first variable on the stack. 8795 Otherwise, it points to the first variable on the stack. 8796 8797 `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 8798 register given by `FRAME_POINTER_REGNUM' and the value 8799 `STARTING_FRAME_OFFSET'. 8800 8801 `VIRTUAL_STACK_DYNAMIC_REGNUM' 8802 This points to the location of dynamically allocated memory 8803 on the stack immediately after the stack pointer has been 8804 adjusted by the amount of memory desired. 8805 8806 This virtual register is replaced by the sum of the register 8807 given by `STACK_POINTER_REGNUM' and the value 8808 `STACK_DYNAMIC_OFFSET'. 8809 8810 `VIRTUAL_OUTGOING_ARGS_REGNUM' 8811 This points to the location in the stack at which outgoing 8812 arguments should be written when the stack is pre-pushed 8813 (arguments pushed using push insns should always use 8814 `STACK_POINTER_REGNUM'). 8815 8816 This virtual register is replaced by the sum of the register 8817 given by `STACK_POINTER_REGNUM' and the value 8818 `STACK_POINTER_OFFSET'. 8819 8820 `(subreg:M1 REG:M2 BYTENUM)' 8821 `subreg' expressions are used to refer to a register in a machine 8822 mode other than its natural one, or to refer to one register of a 8823 multi-part `reg' that actually refers to several registers. 8824 8825 Each pseudo register has a natural mode. If it is necessary to 8826 operate on it in a different mode, the register must be enclosed 8827 in a `subreg'. 8828 8829 There are currently three supported types for the first operand of 8830 a `subreg': 8831 * pseudo registers This is the most common case. Most 8832 `subreg's have pseudo `reg's as their first operand. 8833 8834 * mem `subreg's of `mem' were common in earlier versions of GCC 8835 and are still supported. During the reload pass these are 8836 replaced by plain `mem's. On machines that do not do 8837 instruction scheduling, use of `subreg's of `mem' are still 8838 used, but this is no longer recommended. Such `subreg's are 8839 considered to be `register_operand's rather than 8840 `memory_operand's before and during reload. Because of this, 8841 the scheduling passes cannot properly schedule instructions 8842 with `subreg's of `mem', so for machines that do scheduling, 8843 `subreg's of `mem' should never be used. To support this, 8844 the combine and recog passes have explicit code to inhibit 8845 the creation of `subreg's of `mem' when `INSN_SCHEDULING' is 8846 defined. 8847 8848 The use of `subreg's of `mem' after the reload pass is an area 8849 that is not well understood and should be avoided. There is 8850 still some code in the compiler to support this, but this 8851 code has possibly rotted. This use of `subreg's is 8852 discouraged and will most likely not be supported in the 8853 future. 8854 8855 * hard registers It is seldom necessary to wrap hard registers 8856 in `subreg's; such registers would normally reduce to a 8857 single `reg' rtx. This use of `subreg's is discouraged and 8858 may not be supported in the future. 8859 8860 8861 `subreg's of `subreg's are not supported. Using 8862 `simplify_gen_subreg' is the recommended way to avoid this problem. 8863 8864 `subreg's come in two distinct flavors, each having its own usage 8865 and rules: 8866 8867 Paradoxical subregs 8868 When M1 is strictly wider than M2, the `subreg' expression is 8869 called "paradoxical". The canonical test for this class of 8870 `subreg' is: 8871 8872 GET_MODE_SIZE (M1) > GET_MODE_SIZE (M2) 8873 8874 Paradoxical `subreg's can be used as both lvalues and rvalues. 8875 When used as an lvalue, the low-order bits of the source value 8876 are stored in REG and the high-order bits are discarded. 8877 When used as an rvalue, the low-order bits of the `subreg' are 8878 taken from REG while the high-order bits may or may not be 8879 defined. 8880 8881 The high-order bits of rvalues are in the following 8882 circumstances: 8883 8884 * `subreg's of `mem' When M2 is smaller than a word, the 8885 macro `LOAD_EXTEND_OP', can control how the high-order 8886 bits are defined. 8887 8888 * `subreg' of `reg's The upper bits are defined when 8889 `SUBREG_PROMOTED_VAR_P' is true. 8890 `SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 8891 bits hold. Such subregs usually represent local 8892 variables, register variables and parameter pseudo 8893 variables that have been promoted to a wider mode. 8894 8895 8896 BYTENUM is always zero for a paradoxical `subreg', even on 8897 big-endian targets. 8898 8899 For example, the paradoxical `subreg': 8900 8901 (set (subreg:SI (reg:HI X) 0) Y) 8902 8903 stores the lower 2 bytes of Y in X and discards the upper 2 8904 bytes. A subsequent: 8905 8906 (set Z (subreg:SI (reg:HI X) 0)) 8907 8908 would set the lower two bytes of Z to Y and set the upper two 8909 bytes to an unknown value assuming `SUBREG_PROMOTED_VAR_P' is 8910 false. 8911 8912 Normal subregs 8913 When M1 is at least as narrow as M2 the `subreg' expression 8914 is called "normal". 8915 8916 Normal `subreg's restrict consideration to certain bits of 8917 REG. There are two cases. If M1 is smaller than a word, the 8918 `subreg' refers to the least-significant part (or "lowpart") 8919 of one word of REG. If M1 is word-sized or greater, the 8920 `subreg' refers to one or more complete words. 8921 8922 When used as an lvalue, `subreg' is a word-based accessor. 8923 Storing to a `subreg' modifies all the words of REG that 8924 overlap the `subreg', but it leaves the other words of REG 8925 alone. 8926 8927 When storing to a normal `subreg' that is smaller than a word, 8928 the other bits of the referenced word are usually left in an 8929 undefined state. This laxity makes it easier to generate 8930 efficient code for such instructions. To represent an 8931 instruction that preserves all the bits outside of those in 8932 the `subreg', use `strict_low_part' or `zero_extract' around 8933 the `subreg'. 8934 8935 BYTENUM must identify the offset of the first byte of the 8936 `subreg' from the start of REG, assuming that REG is laid out 8937 in memory order. The memory order of bytes is defined by two 8938 target macros, `WORDS_BIG_ENDIAN' and `BYTES_BIG_ENDIAN': 8939 8940 * `WORDS_BIG_ENDIAN', if set to 1, says that byte number 8941 zero is part of the most significant word; otherwise, it 8942 is part of the least significant word. 8943 8944 * `BYTES_BIG_ENDIAN', if set to 1, says that byte number 8945 zero is the most significant byte within a word; 8946 otherwise, it is the least significant byte within a 8947 word. 8948 8949 On a few targets, `FLOAT_WORDS_BIG_ENDIAN' disagrees with 8950 `WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 8951 floating point values as if they had the same endianness as 8952 integer values. This works because they handle them solely 8953 as a collection of integer values, with no particular 8954 numerical value. Only real.c and the runtime libraries care 8955 about `FLOAT_WORDS_BIG_ENDIAN'. 8956 8957 Thus, 8958 8959 (subreg:HI (reg:SI X) 2) 8960 8961 on a `BYTES_BIG_ENDIAN', `UNITS_PER_WORD == 4' target is the 8962 same as 8963 8964 (subreg:HI (reg:SI X) 0) 8965 8966 on a little-endian, `UNITS_PER_WORD == 4' target. Both 8967 `subreg's access the lower two bytes of register X. 8968 8969 8970 A `MODE_PARTIAL_INT' mode behaves as if it were as wide as the 8971 corresponding `MODE_INT' mode, except that it has an unknown 8972 number of undefined bits. For example: 8973 8974 (subreg:PSI (reg:SI 0) 0) 8975 8976 accesses the whole of `(reg:SI 0)', but the exact relationship 8977 between the `PSImode' value and the `SImode' value is not defined. 8978 If we assume `UNITS_PER_WORD <= 4', then the following two 8979 `subreg's: 8980 8981 (subreg:PSI (reg:DI 0) 0) 8982 (subreg:PSI (reg:DI 0) 4) 8983 8984 represent independent 4-byte accesses to the two halves of 8985 `(reg:DI 0)'. Both `subreg's have an unknown number of undefined 8986 bits. 8987 8988 If `UNITS_PER_WORD <= 2' then these two `subreg's: 8989 8990 (subreg:HI (reg:PSI 0) 0) 8991 (subreg:HI (reg:PSI 0) 2) 8992 8993 represent independent 2-byte accesses that together span the whole 8994 of `(reg:PSI 0)'. Storing to the first `subreg' does not affect 8995 the value of the second, and vice versa. `(reg:PSI 0)' has an 8996 unknown number of undefined bits, so the assignment: 8997 8998 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 8999 9000 does not guarantee that `(subreg:HI (reg:PSI 0) 0)' has the value 9001 `(reg:HI 4)'. 9002 9003 The rules above apply to both pseudo REGs and hard REGs. If the 9004 semantics are not correct for particular combinations of M1, M2 9005 and hard REG, the target-specific code must ensure that those 9006 combinations are never used. For example: 9007 9008 CANNOT_CHANGE_MODE_CLASS (M2, M1, CLASS) 9009 9010 must be true for every class CLASS that includes REG. 9011 9012 The first operand of a `subreg' expression is customarily accessed 9013 with the `SUBREG_REG' macro and the second operand is customarily 9014 accessed with the `SUBREG_BYTE' macro. 9015 9016 It has been several years since a platform in which 9017 `BYTES_BIG_ENDIAN' not equal to `WORDS_BIG_ENDIAN' has been 9018 tested. Anyone wishing to support such a platform in the future 9019 may be confronted with code rot. 9020 9021 `(scratch:M)' 9022 This represents a scratch register that will be required for the 9023 execution of a single instruction and not used subsequently. It is 9024 converted into a `reg' by either the local register allocator or 9025 the reload pass. 9026 9027 `scratch' is usually present inside a `clobber' operation (*note 9028 Side Effects::). 9029 9030 `(cc0)' 9031 This refers to the machine's condition code register. It has no 9032 operands and may not have a machine mode. There are two ways to 9033 use it: 9034 9035 * To stand for a complete set of condition code flags. This is 9036 best on most machines, where each comparison sets the entire 9037 series of flags. 9038 9039 With this technique, `(cc0)' may be validly used in only two 9040 contexts: as the destination of an assignment (in test and 9041 compare instructions) and in comparison operators comparing 9042 against zero (`const_int' with value zero; that is to say, 9043 `const0_rtx'). 9044 9045 * To stand for a single flag that is the result of a single 9046 condition. This is useful on machines that have only a 9047 single flag bit, and in which comparison instructions must 9048 specify the condition to test. 9049 9050 With this technique, `(cc0)' may be validly used in only two 9051 contexts: as the destination of an assignment (in test and 9052 compare instructions) where the source is a comparison 9053 operator, and as the first operand of `if_then_else' (in a 9054 conditional branch). 9055 9056 There is only one expression object of code `cc0'; it is the value 9057 of the variable `cc0_rtx'. Any attempt to create an expression of 9058 code `cc0' will return `cc0_rtx'. 9059 9060 Instructions can set the condition code implicitly. On many 9061 machines, nearly all instructions set the condition code based on 9062 the value that they compute or store. It is not necessary to 9063 record these actions explicitly in the RTL because the machine 9064 description includes a prescription for recognizing the 9065 instructions that do so (by means of the macro 9066 `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions 9067 whose sole purpose is to set the condition code, and instructions 9068 that use the condition code, need mention `(cc0)'. 9069 9070 On some machines, the condition code register is given a register 9071 number and a `reg' is used instead of `(cc0)'. This is usually the 9072 preferable approach if only a small subset of instructions modify 9073 the condition code. Other machines store condition codes in 9074 general registers; in such cases a pseudo register should be used. 9075 9076 Some machines, such as the SPARC and RS/6000, have two sets of 9077 arithmetic instructions, one that sets and one that does not set 9078 the condition code. This is best handled by normally generating 9079 the instruction that does not set the condition code, and making a 9080 pattern that both performs the arithmetic and sets the condition 9081 code register (which would not be `(cc0)' in this case). For 9082 examples, search for `addcc' and `andcc' in `sparc.md'. 9083 9084 `(pc)' 9085 This represents the machine's program counter. It has no operands 9086 and may not have a machine mode. `(pc)' may be validly used only 9087 in certain specific contexts in jump instructions. 9088 9089 There is only one expression object of code `pc'; it is the value 9090 of the variable `pc_rtx'. Any attempt to create an expression of 9091 code `pc' will return `pc_rtx'. 9092 9093 All instructions that do not jump alter the program counter 9094 implicitly by incrementing it, but there is no need to mention 9095 this in the RTL. 9096 9097 `(mem:M ADDR ALIAS)' 9098 This RTX represents a reference to main memory at an address 9099 represented by the expression ADDR. M specifies how large a unit 9100 of memory is accessed. ALIAS specifies an alias set for the 9101 reference. In general two items are in different alias sets if 9102 they cannot reference the same memory address. 9103 9104 The construct `(mem:BLK (scratch))' is considered to alias all 9105 other memories. Thus it may be used as a memory barrier in 9106 epilogue stack deallocation patterns. 9107 9108 `(concatM RTX RTX)' 9109 This RTX represents the concatenation of two other RTXs. This is 9110 used for complex values. It should only appear in the RTL 9111 attached to declarations and during RTL generation. It should not 9112 appear in the ordinary insn chain. 9113 9114 `(concatnM [RTX ...])' 9115 This RTX represents the concatenation of all the RTX to make a 9116 single value. Like `concat', this should only appear in 9117 declarations, and not in the insn chain. 9118 9119 9120 File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 9121 9122 10.9 RTL Expressions for Arithmetic 9123 =================================== 9124 9125 Unless otherwise specified, all the operands of arithmetic expressions 9126 must be valid for mode M. An operand is valid for mode M if it has 9127 mode M, or if it is a `const_int' or `const_double' and M is a mode of 9128 class `MODE_INT'. 9129 9130 For commutative binary operations, constants should be placed in the 9131 second operand. 9132 9133 `(plus:M X Y)' 9134 `(ss_plus:M X Y)' 9135 `(us_plus:M X Y)' 9136 These three expressions all represent the sum of the values 9137 represented by X and Y carried out in machine mode M. They differ 9138 in their behavior on overflow of integer modes. `plus' wraps 9139 round modulo the width of M; `ss_plus' saturates at the maximum 9140 signed value representable in M; `us_plus' saturates at the 9141 maximum unsigned value. 9142 9143 `(lo_sum:M X Y)' 9144 This expression represents the sum of X and the low-order bits of 9145 Y. It is used with `high' (*note Constants::) to represent the 9146 typical two-instruction sequence used in RISC machines to 9147 reference a global memory location. 9148 9149 The number of low order bits is machine-dependent but is normally 9150 the number of bits in a `Pmode' item minus the number of bits set 9151 by `high'. 9152 9153 M should be `Pmode'. 9154 9155 `(minus:M X Y)' 9156 `(ss_minus:M X Y)' 9157 `(us_minus:M X Y)' 9158 These three expressions represent the result of subtracting Y from 9159 X, carried out in mode M. Behavior on overflow is the same as for 9160 the three variants of `plus' (see above). 9161 9162 `(compare:M X Y)' 9163 Represents the result of subtracting Y from X for purposes of 9164 comparison. The result is computed without overflow, as if with 9165 infinite precision. 9166 9167 Of course, machines can't really subtract with infinite precision. 9168 However, they can pretend to do so when only the sign of the 9169 result will be used, which is the case when the result is stored 9170 in the condition code. And that is the _only_ way this kind of 9171 expression may validly be used: as a value to be stored in the 9172 condition codes, either `(cc0)' or a register. *Note 9173 Comparisons::. 9174 9175 The mode M is not related to the modes of X and Y, but instead is 9176 the mode of the condition code value. If `(cc0)' is used, it is 9177 `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often 9178 `CCmode'. *Note Condition Code::. If M is `VOIDmode' or 9179 `CCmode', the operation returns sufficient information (in an 9180 unspecified format) so that any comparison operator can be applied 9181 to the result of the `COMPARE' operation. For other modes in 9182 class `MODE_CC', the operation only returns a subset of this 9183 information. 9184 9185 Normally, X and Y must have the same mode. Otherwise, `compare' 9186 is valid only if the mode of X is in class `MODE_INT' and Y is a 9187 `const_int' or `const_double' with mode `VOIDmode'. The mode of X 9188 determines what mode the comparison is to be done in; thus it must 9189 not be `VOIDmode'. 9190 9191 If one of the operands is a constant, it should be placed in the 9192 second operand and the comparison code adjusted as appropriate. 9193 9194 A `compare' specifying two `VOIDmode' constants is not valid since 9195 there is no way to know in what mode the comparison is to be 9196 performed; the comparison must either be folded during the 9197 compilation or the first operand must be loaded into a register 9198 while its mode is still known. 9199 9200 `(neg:M X)' 9201 `(ss_neg:M X)' 9202 `(us_neg:M X)' 9203 These two expressions represent the negation (subtraction from 9204 zero) of the value represented by X, carried out in mode M. They 9205 differ in the behavior on overflow of integer modes. In the case 9206 of `neg', the negation of the operand may be a number not 9207 representable in mode M, in which case it is truncated to M. 9208 `ss_neg' and `us_neg' ensure that an out-of-bounds result 9209 saturates to the maximum or minimum signed or unsigned value. 9210 9211 `(mult:M X Y)' 9212 `(ss_mult:M X Y)' 9213 `(us_mult:M X Y)' 9214 Represents the signed product of the values represented by X and Y 9215 carried out in machine mode M. `ss_mult' and `us_mult' ensure 9216 that an out-of-bounds result saturates to the maximum or minimum 9217 signed or unsigned value. 9218 9219 Some machines support a multiplication that generates a product 9220 wider than the operands. Write the pattern for this as 9221 9222 (mult:M (sign_extend:M X) (sign_extend:M Y)) 9223 9224 where M is wider than the modes of X and Y, which need not be the 9225 same. 9226 9227 For unsigned widening multiplication, use the same idiom, but with 9228 `zero_extend' instead of `sign_extend'. 9229 9230 `(fma:M X Y Z)' 9231 Represents the `fma', `fmaf', and `fmal' builtin functions that do 9232 a combined multiply of X and Y and then adding toZ without doing 9233 an intermediate rounding step. 9234 9235 `(div:M X Y)' 9236 `(ss_div:M X Y)' 9237 Represents the quotient in signed division of X by Y, carried out 9238 in machine mode M. If M is a floating point mode, it represents 9239 the exact quotient; otherwise, the integerized quotient. `ss_div' 9240 ensures that an out-of-bounds result saturates to the maximum or 9241 minimum signed value. 9242 9243 Some machines have division instructions in which the operands and 9244 quotient widths are not all the same; you should represent such 9245 instructions using `truncate' and `sign_extend' as in, 9246 9247 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 9248 9249 `(udiv:M X Y)' 9250 `(us_div:M X Y)' 9251 Like `div' but represents unsigned division. `us_div' ensures 9252 that an out-of-bounds result saturates to the maximum or minimum 9253 unsigned value. 9254 9255 `(mod:M X Y)' 9256 `(umod:M X Y)' 9257 Like `div' and `udiv' but represent the remainder instead of the 9258 quotient. 9259 9260 `(smin:M X Y)' 9261 `(smax:M X Y)' 9262 Represents the smaller (for `smin') or larger (for `smax') of X 9263 and Y, interpreted as signed values in mode M. When used with 9264 floating point, if both operands are zeros, or if either operand 9265 is `NaN', then it is unspecified which of the two operands is 9266 returned as the result. 9267 9268 `(umin:M X Y)' 9269 `(umax:M X Y)' 9270 Like `smin' and `smax', but the values are interpreted as unsigned 9271 integers. 9272 9273 `(not:M X)' 9274 Represents the bitwise complement of the value represented by X, 9275 carried out in mode M, which must be a fixed-point machine mode. 9276 9277 `(and:M X Y)' 9278 Represents the bitwise logical-and of the values represented by X 9279 and Y, carried out in machine mode M, which must be a fixed-point 9280 machine mode. 9281 9282 `(ior:M X Y)' 9283 Represents the bitwise inclusive-or of the values represented by X 9284 and Y, carried out in machine mode M, which must be a fixed-point 9285 mode. 9286 9287 `(xor:M X Y)' 9288 Represents the bitwise exclusive-or of the values represented by X 9289 and Y, carried out in machine mode M, which must be a fixed-point 9290 mode. 9291 9292 `(ashift:M X C)' 9293 `(ss_ashift:M X C)' 9294 `(us_ashift:M X C)' 9295 These three expressions represent the result of arithmetically 9296 shifting X left by C places. They differ in their behavior on 9297 overflow of integer modes. An `ashift' operation is a plain shift 9298 with no special behavior in case of a change in the sign bit; 9299 `ss_ashift' and `us_ashift' saturates to the minimum or maximum 9300 representable value if any of the bits shifted out differs from 9301 the final sign bit. 9302 9303 X have mode M, a fixed-point machine mode. C be a fixed-point 9304 mode or be a constant with mode `VOIDmode'; which mode is 9305 determined by the mode called for in the machine description entry 9306 for the left-shift instruction. For example, on the VAX, the mode 9307 of C is `QImode' regardless of M. 9308 9309 `(lshiftrt:M X C)' 9310 `(ashiftrt:M X C)' 9311 Like `ashift' but for right shift. Unlike the case for left shift, 9312 these two operations are distinct. 9313 9314 `(rotate:M X C)' 9315 `(rotatert:M X C)' 9316 Similar but represent left and right rotate. If C is a constant, 9317 use `rotate'. 9318 9319 `(abs:M X)' 9320 9321 `(ss_abs:M X)' 9322 Represents the absolute value of X, computed in mode M. `ss_abs' 9323 ensures that an out-of-bounds result saturates to the maximum 9324 signed value. 9325 9326 `(sqrt:M X)' 9327 Represents the square root of X, computed in mode M. Most often M 9328 will be a floating point mode. 9329 9330 `(ffs:M X)' 9331 Represents one plus the index of the least significant 1-bit in X, 9332 represented as an integer of mode M. (The value is zero if X is 9333 zero.) The mode of X must be M or `VOIDmode'. 9334 9335 `(clrsb:M X)' 9336 Represents the number of redundant leading sign bits in X, 9337 represented as an integer of mode M, starting at the most 9338 significant bit position. This is one less than the number of 9339 leading sign bits (either 0 or 1), with no special cases. The 9340 mode of X must be M or `VOIDmode'. 9341 9342 `(clz:M X)' 9343 Represents the number of leading 0-bits in X, represented as an 9344 integer of mode M, starting at the most significant bit position. 9345 If X is zero, the value is determined by 9346 `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 9347 of the few expressions that is not invariant under widening. The 9348 mode of X must be M or `VOIDmode'. 9349 9350 `(ctz:M X)' 9351 Represents the number of trailing 0-bits in X, represented as an 9352 integer of mode M, starting at the least significant bit position. 9353 If X is zero, the value is determined by 9354 `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 9355 `ctz(x)' is equivalent to `ffs(X) - 1'. The mode of X must be M 9356 or `VOIDmode'. 9357 9358 `(popcount:M X)' 9359 Represents the number of 1-bits in X, represented as an integer of 9360 mode M. The mode of X must be M or `VOIDmode'. 9361 9362 `(parity:M X)' 9363 Represents the number of 1-bits modulo 2 in X, represented as an 9364 integer of mode M. The mode of X must be M or `VOIDmode'. 9365 9366 `(bswap:M X)' 9367 Represents the value X with the order of bytes reversed, carried 9368 out in mode M, which must be a fixed-point machine mode. The mode 9369 of X must be M or `VOIDmode'. 9370 9371 9372 File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 9373 9374 10.10 Comparison Operations 9375 =========================== 9376 9377 Comparison operators test a relation on two operands and are considered 9378 to represent a machine-dependent nonzero value described by, but not 9379 necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::) if the relation 9380 holds, or zero if it does not, for comparison operators whose results 9381 have a `MODE_INT' mode, `FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 9382 relation holds, or zero if it does not, for comparison operators that 9383 return floating-point values, and a vector of either 9384 `VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 9385 zeros if it does not, for comparison operators that return vector 9386 results. The mode of the comparison operation is independent of the 9387 mode of the data being compared. If the comparison operation is being 9388 tested (e.g., the first operand of an `if_then_else'), the mode must be 9389 `VOIDmode'. 9390 9391 There are two ways that comparison operations may be used. The 9392 comparison operators may be used to compare the condition codes `(cc0)' 9393 against zero, as in `(eq (cc0) (const_int 0))'. Such a construct 9394 actually refers to the result of the preceding instruction in which the 9395 condition codes were set. The instruction setting the condition code 9396 must be adjacent to the instruction using the condition code; only 9397 `note' insns may separate them. 9398 9399 Alternatively, a comparison operation may directly compare two data 9400 objects. The mode of the comparison is determined by the operands; they 9401 must both be valid for a common machine mode. A comparison with both 9402 operands constant would be invalid as the machine mode could not be 9403 deduced from it, but such a comparison should never exist in RTL due to 9404 constant folding. 9405 9406 In the example above, if `(cc0)' were last set to `(compare X Y)', the 9407 comparison operation is identical to `(eq X Y)'. Usually only one style 9408 of comparisons is supported on a particular machine, but the combine 9409 pass will try to merge the operations to produce the `eq' shown in case 9410 it exists in the context of the particular insn involved. 9411 9412 Inequality comparisons come in two flavors, signed and unsigned. Thus, 9413 there are distinct expression codes `gt' and `gtu' for signed and 9414 unsigned greater-than. These can produce different results for the same 9415 pair of integer values: for example, 1 is signed greater-than -1 but not 9416 unsigned greater-than, because -1 when regarded as unsigned is actually 9417 `0xffffffff' which is greater than 1. 9418 9419 The signed comparisons are also used for floating point values. 9420 Floating point comparisons are distinguished by the machine modes of 9421 the operands. 9422 9423 `(eq:M X Y)' 9424 `STORE_FLAG_VALUE' if the values represented by X and Y are equal, 9425 otherwise 0. 9426 9427 `(ne:M X Y)' 9428 `STORE_FLAG_VALUE' if the values represented by X and Y are not 9429 equal, otherwise 0. 9430 9431 `(gt:M X Y)' 9432 `STORE_FLAG_VALUE' if the X is greater than Y. If they are 9433 fixed-point, the comparison is done in a signed sense. 9434 9435 `(gtu:M X Y)' 9436 Like `gt' but does unsigned comparison, on fixed-point numbers 9437 only. 9438 9439 `(lt:M X Y)' 9440 `(ltu:M X Y)' 9441 Like `gt' and `gtu' but test for "less than". 9442 9443 `(ge:M X Y)' 9444 `(geu:M X Y)' 9445 Like `gt' and `gtu' but test for "greater than or equal". 9446 9447 `(le:M X Y)' 9448 `(leu:M X Y)' 9449 Like `gt' and `gtu' but test for "less than or equal". 9450 9451 `(if_then_else COND THEN ELSE)' 9452 This is not a comparison operation but is listed here because it is 9453 always used in conjunction with a comparison operation. To be 9454 precise, COND is a comparison expression. This expression 9455 represents a choice, according to COND, between the value 9456 represented by THEN and the one represented by ELSE. 9457 9458 On most machines, `if_then_else' expressions are valid only to 9459 express conditional jumps. 9460 9461 `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 9462 Similar to `if_then_else', but more general. Each of TEST1, 9463 TEST2, ... is performed in turn. The result of this expression is 9464 the VALUE corresponding to the first nonzero test, or DEFAULT if 9465 none of the tests are nonzero expressions. 9466 9467 This is currently not valid for instruction patterns and is 9468 supported only for insn attributes. *Note Insn Attributes::. 9469 9470 9471 File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 9472 9473 10.11 Bit-Fields 9474 ================ 9475 9476 Special expression codes exist to represent bit-field instructions. 9477 9478 `(sign_extract:M LOC SIZE POS)' 9479 This represents a reference to a sign-extended bit-field contained 9480 or starting in LOC (a memory or register reference). The bit-field 9481 is SIZE bits wide and starts at bit POS. The compilation option 9482 `BITS_BIG_ENDIAN' says which end of the memory unit POS counts 9483 from. 9484 9485 If LOC is in memory, its mode must be a single-byte integer mode. 9486 If LOC is in a register, the mode to use is specified by the 9487 operand of the `insv' or `extv' pattern (*note Standard Names::) 9488 and is usually a full-word integer mode, which is the default if 9489 none is specified. 9490 9491 The mode of POS is machine-specific and is also specified in the 9492 `insv' or `extv' pattern. 9493 9494 The mode M is the same as the mode that would be used for LOC if 9495 it were a register. 9496 9497 A `sign_extract' can not appear as an lvalue, or part thereof, in 9498 RTL. 9499 9500 `(zero_extract:M LOC SIZE POS)' 9501 Like `sign_extract' but refers to an unsigned or zero-extended 9502 bit-field. The same sequence of bits are extracted, but they are 9503 filled to an entire word with zeros instead of by sign-extension. 9504 9505 Unlike `sign_extract', this type of expressions can be lvalues in 9506 RTL; they may appear on the left side of an assignment, indicating 9507 insertion of a value into the specified bit-field. 9508 9509 9510 File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 9511 9512 10.12 Vector Operations 9513 ======================= 9514 9515 All normal RTL expressions can be used with vector modes; they are 9516 interpreted as operating on each part of the vector independently. 9517 Additionally, there are a few new expressions to describe specific 9518 vector operations. 9519 9520 `(vec_merge:M VEC1 VEC2 ITEMS)' 9521 This describes a merge operation between two vectors. The result 9522 is a vector of mode M; its elements are selected from either VEC1 9523 or VEC2. Which elements are selected is described by ITEMS, which 9524 is a bit mask represented by a `const_int'; a zero bit indicates 9525 the corresponding element in the result vector is taken from VEC2 9526 while a set bit indicates it is taken from VEC1. 9527 9528 `(vec_select:M VEC1 SELECTION)' 9529 This describes an operation that selects parts of a vector. VEC1 9530 is the source vector, and SELECTION is a `parallel' that contains a 9531 `const_int' for each of the subparts of the result vector, giving 9532 the number of the source subpart that should be stored into it. 9533 The result mode M is either the submode for a single element of 9534 VEC1 (if only one subpart is selected), or another vector mode 9535 with that element submode (if multiple subparts are selected). 9536 9537 `(vec_concat:M X1 X2)' 9538 Describes a vector concat operation. The result is a 9539 concatenation of the vectors or scalars X1 and X2; its length is 9540 the sum of the lengths of the two inputs. 9541 9542 `(vec_duplicate:M X)' 9543 This operation converts a scalar into a vector or a small vector 9544 into a larger one by duplicating the input values. The output 9545 vector mode must have the same submodes as the input vector mode 9546 or the scalar modes, and the number of output parts must be an 9547 integer multiple of the number of input parts. 9548 9549 9550 9551 File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 9552 9553 10.13 Conversions 9554 ================= 9555 9556 All conversions between machine modes must be represented by explicit 9557 conversion operations. For example, an expression which is the sum of 9558 a byte and a full word cannot be written as `(plus:SI (reg:QI 34) 9559 (reg:SI 80))' because the `plus' operation requires two operands of the 9560 same machine mode. Therefore, the byte-sized operand is enclosed in a 9561 conversion operation, as in 9562 9563 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 9564 9565 The conversion operation is not a mere placeholder, because there may 9566 be more than one way of converting from a given starting mode to the 9567 desired final mode. The conversion operation code says how to do it. 9568 9569 For all conversion operations, X must not be `VOIDmode' because the 9570 mode in which to do the conversion would not be known. The conversion 9571 must either be done at compile-time or X must be placed into a register. 9572 9573 `(sign_extend:M X)' 9574 Represents the result of sign-extending the value X to machine 9575 mode M. M must be a fixed-point mode and X a fixed-point value of 9576 a mode narrower than M. 9577 9578 `(zero_extend:M X)' 9579 Represents the result of zero-extending the value X to machine 9580 mode M. M must be a fixed-point mode and X a fixed-point value of 9581 a mode narrower than M. 9582 9583 `(float_extend:M X)' 9584 Represents the result of extending the value X to machine mode M. 9585 M must be a floating point mode and X a floating point value of a 9586 mode narrower than M. 9587 9588 `(truncate:M X)' 9589 Represents the result of truncating the value X to machine mode M. 9590 M must be a fixed-point mode and X a fixed-point value of a mode 9591 wider than M. 9592 9593 `(ss_truncate:M X)' 9594 Represents the result of truncating the value X to machine mode M, 9595 using signed saturation in the case of overflow. Both M and the 9596 mode of X must be fixed-point modes. 9597 9598 `(us_truncate:M X)' 9599 Represents the result of truncating the value X to machine mode M, 9600 using unsigned saturation in the case of overflow. Both M and the 9601 mode of X must be fixed-point modes. 9602 9603 `(float_truncate:M X)' 9604 Represents the result of truncating the value X to machine mode M. 9605 M must be a floating point mode and X a floating point value of a 9606 mode wider than M. 9607 9608 `(float:M X)' 9609 Represents the result of converting fixed point value X, regarded 9610 as signed, to floating point mode M. 9611 9612 `(unsigned_float:M X)' 9613 Represents the result of converting fixed point value X, regarded 9614 as unsigned, to floating point mode M. 9615 9616 `(fix:M X)' 9617 When M is a floating-point mode, represents the result of 9618 converting floating point value X (valid for mode M) to an 9619 integer, still represented in floating point mode M, by rounding 9620 towards zero. 9621 9622 When M is a fixed-point mode, represents the result of converting 9623 floating point value X to mode M, regarded as signed. How 9624 rounding is done is not specified, so this operation may be used 9625 validly in compiling C code only for integer-valued operands. 9626 9627 `(unsigned_fix:M X)' 9628 Represents the result of converting floating point value X to 9629 fixed point mode M, regarded as unsigned. How rounding is done is 9630 not specified. 9631 9632 `(fract_convert:M X)' 9633 Represents the result of converting fixed-point value X to 9634 fixed-point mode M, signed integer value X to fixed-point mode M, 9635 floating-point value X to fixed-point mode M, fixed-point value X 9636 to integer mode M regarded as signed, or fixed-point value X to 9637 floating-point mode M. When overflows or underflows happen, the 9638 results are undefined. 9639 9640 `(sat_fract:M X)' 9641 Represents the result of converting fixed-point value X to 9642 fixed-point mode M, signed integer value X to fixed-point mode M, 9643 or floating-point value X to fixed-point mode M. When overflows 9644 or underflows happen, the results are saturated to the maximum or 9645 the minimum. 9646 9647 `(unsigned_fract_convert:M X)' 9648 Represents the result of converting fixed-point value X to integer 9649 mode M regarded as unsigned, or unsigned integer value X to 9650 fixed-point mode M. When overflows or underflows happen, the 9651 results are undefined. 9652 9653 `(unsigned_sat_fract:M X)' 9654 Represents the result of converting unsigned integer value X to 9655 fixed-point mode M. When overflows or underflows happen, the 9656 results are saturated to the maximum or the minimum. 9657 9658 9659 File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 9660 9661 10.14 Declarations 9662 ================== 9663 9664 Declaration expression codes do not represent arithmetic operations but 9665 rather state assertions about their operands. 9666 9667 `(strict_low_part (subreg:M (reg:N R) 0))' 9668 This expression code is used in only one context: as the 9669 destination operand of a `set' expression. In addition, the 9670 operand of this expression must be a non-paradoxical `subreg' 9671 expression. 9672 9673 The presence of `strict_low_part' says that the part of the 9674 register which is meaningful in mode N, but is not part of mode M, 9675 is not to be altered. Normally, an assignment to such a subreg is 9676 allowed to have undefined effects on the rest of the register when 9677 M is less than a word. 9678 9679 9680 File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 9681 9682 10.15 Side Effect Expressions 9683 ============================= 9684 9685 The expression codes described so far represent values, not actions. 9686 But machine instructions never produce values; they are meaningful only 9687 for their side effects on the state of the machine. Special expression 9688 codes are used to represent side effects. 9689 9690 The body of an instruction is always one of these side effect codes; 9691 the codes described above, which represent values, appear only as the 9692 operands of these. 9693 9694 `(set LVAL X)' 9695 Represents the action of storing the value of X into the place 9696 represented by LVAL. LVAL must be an expression representing a 9697 place that can be stored in: `reg' (or `subreg', `strict_low_part' 9698 or `zero_extract'), `mem', `pc', `parallel', or `cc0'. 9699 9700 If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then 9701 X must be valid for that mode. 9702 9703 If LVAL is a `reg' whose machine mode is less than the full width 9704 of the register, then it means that the part of the register 9705 specified by the machine mode is given the specified value and the 9706 rest of the register receives an undefined value. Likewise, if 9707 LVAL is a `subreg' whose machine mode is narrower than the mode of 9708 the register, the rest of the register can be changed in an 9709 undefined way. 9710 9711 If LVAL is a `strict_low_part' of a subreg, then the part of the 9712 register specified by the machine mode of the `subreg' is given 9713 the value X and the rest of the register is not changed. 9714 9715 If LVAL is a `zero_extract', then the referenced part of the 9716 bit-field (a memory or register reference) specified by the 9717 `zero_extract' is given the value X and the rest of the bit-field 9718 is not changed. Note that `sign_extract' can not appear in LVAL. 9719 9720 If LVAL is `(cc0)', it has no machine mode, and X may be either a 9721 `compare' expression or a value that may have any mode. The 9722 latter case represents a "test" instruction. The expression `(set 9723 (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N) 9724 (const_int 0)))'. Use the former expression to save space during 9725 the compilation. 9726 9727 If LVAL is a `parallel', it is used to represent the case of a 9728 function returning a structure in multiple registers. Each element 9729 of the `parallel' is an `expr_list' whose first operand is a `reg' 9730 and whose second operand is a `const_int' representing the offset 9731 (in bytes) into the structure at which the data in that register 9732 corresponds. The first element may be null to indicate that the 9733 structure is also passed partly in memory. 9734 9735 If LVAL is `(pc)', we have a jump instruction, and the 9736 possibilities for X are very limited. It may be a `label_ref' 9737 expression (unconditional jump). It may be an `if_then_else' 9738 (conditional jump), in which case either the second or the third 9739 operand must be `(pc)' (for the case which does not jump) and the 9740 other of the two must be a `label_ref' (for the case which does 9741 jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may 9742 be a `reg' or a `mem'; these unusual patterns are used to 9743 represent jumps through branch tables. 9744 9745 If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not 9746 be `VOIDmode' and the mode of X must be valid for the mode of LVAL. 9747 9748 LVAL is customarily accessed with the `SET_DEST' macro and X with 9749 the `SET_SRC' macro. 9750 9751 `(return)' 9752 As the sole expression in a pattern, represents a return from the 9753 current function, on machines where this can be done with one 9754 instruction, such as VAXen. On machines where a multi-instruction 9755 "epilogue" must be executed in order to return from the function, 9756 returning is done by jumping to a label which precedes the 9757 epilogue, and the `return' expression code is never used. 9758 9759 Inside an `if_then_else' expression, represents the value to be 9760 placed in `pc' to return to the caller. 9761 9762 Note that an insn pattern of `(return)' is logically equivalent to 9763 `(set (pc) (return))', but the latter form is never used. 9764 9765 `(simple_return)' 9766 Like `(return)', but truly represents only a function return, while 9767 `(return)' may represent an insn that also performs other functions 9768 of the function epilogue. Like `(return)', this may also occur in 9769 conditional jumps. 9770 9771 `(call FUNCTION NARGS)' 9772 Represents a function call. FUNCTION is a `mem' expression whose 9773 address is the address of the function to be called. NARGS is an 9774 expression which can be used for two purposes: on some machines it 9775 represents the number of bytes of stack argument; on others, it 9776 represents the number of argument registers. 9777 9778 Each machine has a standard machine mode which FUNCTION must have. 9779 The machine description defines macro `FUNCTION_MODE' to expand 9780 into the requisite mode name. The purpose of this mode is to 9781 specify what kind of addressing is allowed, on machines where the 9782 allowed kinds of addressing depend on the machine mode being 9783 addressed. 9784 9785 `(clobber X)' 9786 Represents the storing or possible storing of an unpredictable, 9787 undescribed value into X, which must be a `reg', `scratch', 9788 `parallel' or `mem' expression. 9789 9790 One place this is used is in string instructions that store 9791 standard values into particular hard registers. It may not be 9792 worth the trouble to describe the values that are stored, but it 9793 is essential to inform the compiler that the registers will be 9794 altered, lest it attempt to keep data in them across the string 9795 instruction. 9796 9797 If X is `(mem:BLK (const_int 0))' or `(mem:BLK (scratch))', it 9798 means that all memory locations must be presumed clobbered. If X 9799 is a `parallel', it has the same meaning as a `parallel' in a 9800 `set' expression. 9801 9802 Note that the machine description classifies certain hard 9803 registers as "call-clobbered". All function call instructions are 9804 assumed by default to clobber these registers, so there is no need 9805 to use `clobber' expressions to indicate this fact. Also, each 9806 function call is assumed to have the potential to alter any memory 9807 location, unless the function is declared `const'. 9808 9809 If the last group of expressions in a `parallel' are each a 9810 `clobber' expression whose arguments are `reg' or `match_scratch' 9811 (*note RTL Template::) expressions, the combiner phase can add the 9812 appropriate `clobber' expressions to an insn it has constructed 9813 when doing so will cause a pattern to be matched. 9814 9815 This feature can be used, for example, on a machine that whose 9816 multiply and add instructions don't use an MQ register but which 9817 has an add-accumulate instruction that does clobber the MQ 9818 register. Similarly, a combined instruction might require a 9819 temporary register while the constituent instructions might not. 9820 9821 When a `clobber' expression for a register appears inside a 9822 `parallel' with other side effects, the register allocator 9823 guarantees that the register is unoccupied both before and after 9824 that insn if it is a hard register clobber. For pseudo-register 9825 clobber, the register allocator and the reload pass do not assign 9826 the same hard register to the clobber and the input operands if 9827 there is an insn alternative containing the `&' constraint (*note 9828 Modifiers::) for the clobber and the hard register is in register 9829 classes of the clobber in the alternative. You can clobber either 9830 a specific hard register, a pseudo register, or a `scratch' 9831 expression; in the latter two cases, GCC will allocate a hard 9832 register that is available there for use as a temporary. 9833 9834 For instructions that require a temporary register, you should use 9835 `scratch' instead of a pseudo-register because this will allow the 9836 combiner phase to add the `clobber' when required. You do this by 9837 coding (`clobber' (`match_scratch' ...)). If you do clobber a 9838 pseudo register, use one which appears nowhere else--generate a 9839 new one each time. Otherwise, you may confuse CSE. 9840 9841 There is one other known use for clobbering a pseudo register in a 9842 `parallel': when one of the input operands of the insn is also 9843 clobbered by the insn. In this case, using the same pseudo 9844 register in the clobber and elsewhere in the insn produces the 9845 expected results. 9846 9847 `(use X)' 9848 Represents the use of the value of X. It indicates that the value 9849 in X at this point in the program is needed, even though it may 9850 not be apparent why this is so. Therefore, the compiler will not 9851 attempt to delete previous instructions whose only effect is to 9852 store a value in X. X must be a `reg' expression. 9853 9854 In some situations, it may be tempting to add a `use' of a 9855 register in a `parallel' to describe a situation where the value 9856 of a special register will modify the behavior of the instruction. 9857 A hypothetical example might be a pattern for an addition that can 9858 either wrap around or use saturating addition depending on the 9859 value of a special control register: 9860 9861 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 9862 (reg:SI 4)] 0)) 9863 (use (reg:SI 1))]) 9864 9865 This will not work, several of the optimizers only look at 9866 expressions locally; it is very likely that if you have multiple 9867 insns with identical inputs to the `unspec', they will be 9868 optimized away even if register 1 changes in between. 9869 9870 This means that `use' can _only_ be used to describe that the 9871 register is live. You should think twice before adding `use' 9872 statements, more often you will want to use `unspec' instead. The 9873 `use' RTX is most commonly useful to describe that a fixed 9874 register is implicitly used in an insn. It is also safe to use in 9875 patterns where the compiler knows for other reasons that the result 9876 of the whole pattern is variable, such as `movmemM' or `call' 9877 patterns. 9878 9879 During the reload phase, an insn that has a `use' as pattern can 9880 carry a reg_equal note. These `use' insns will be deleted before 9881 the reload phase exits. 9882 9883 During the delayed branch scheduling phase, X may be an insn. 9884 This indicates that X previously was located at this place in the 9885 code and its data dependencies need to be taken into account. 9886 These `use' insns will be deleted before the delayed branch 9887 scheduling phase exits. 9888 9889 `(parallel [X0 X1 ...])' 9890 Represents several side effects performed in parallel. The square 9891 brackets stand for a vector; the operand of `parallel' is a vector 9892 of expressions. X0, X1 and so on are individual side effect 9893 expressions--expressions of code `set', `call', `return', 9894 `simple_return', `clobber' or `use'. 9895 9896 "In parallel" means that first all the values used in the 9897 individual side-effects are computed, and second all the actual 9898 side-effects are performed. For example, 9899 9900 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 9901 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 9902 9903 says unambiguously that the values of hard register 1 and the 9904 memory location addressed by it are interchanged. In both places 9905 where `(reg:SI 1)' appears as a memory address it refers to the 9906 value in register 1 _before_ the execution of the insn. 9907 9908 It follows that it is _incorrect_ to use `parallel' and expect the 9909 result of one `set' to be available for the next one. For 9910 example, people sometimes attempt to represent a jump-if-zero 9911 instruction this way: 9912 9913 (parallel [(set (cc0) (reg:SI 34)) 9914 (set (pc) (if_then_else 9915 (eq (cc0) (const_int 0)) 9916 (label_ref ...) 9917 (pc)))]) 9918 9919 But this is incorrect, because it says that the jump condition 9920 depends on the condition code value _before_ this instruction, not 9921 on the new value that is set by this instruction. 9922 9923 Peephole optimization, which takes place together with final 9924 assembly code output, can produce insns whose patterns consist of 9925 a `parallel' whose elements are the operands needed to output the 9926 resulting assembler code--often `reg', `mem' or constant 9927 expressions. This would not be well-formed RTL at any other stage 9928 in compilation, but it is ok then because no further optimization 9929 remains to be done. However, the definition of the macro 9930 `NOTICE_UPDATE_CC', if any, must deal with such insns if you 9931 define any peephole optimizations. 9932 9933 `(cond_exec [COND EXPR])' 9934 Represents a conditionally executed expression. The EXPR is 9935 executed only if the COND is nonzero. The COND expression must 9936 not have side-effects, but the EXPR may very well have 9937 side-effects. 9938 9939 `(sequence [INSNS ...])' 9940 Represents a sequence of insns. Each of the INSNS that appears in 9941 the vector is suitable for appearing in the chain of insns, so it 9942 must be an `insn', `jump_insn', `call_insn', `code_label', 9943 `barrier' or `note'. 9944 9945 A `sequence' RTX is never placed in an actual insn during RTL 9946 generation. It represents the sequence of insns that result from a 9947 `define_expand' _before_ those insns are passed to `emit_insn' to 9948 insert them in the chain of insns. When actually inserted, the 9949 individual sub-insns are separated out and the `sequence' is 9950 forgotten. 9951 9952 After delay-slot scheduling is completed, an insn and all the 9953 insns that reside in its delay slots are grouped together into a 9954 `sequence'. The insn requiring the delay slot is the first insn 9955 in the vector; subsequent insns are to be placed in the delay slot. 9956 9957 `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 9958 indicate that a branch insn should be used that will conditionally 9959 annul the effect of the insns in the delay slots. In such a case, 9960 `INSN_FROM_TARGET_P' indicates that the insn is from the target of 9961 the branch and should be executed only if the branch is taken; 9962 otherwise the insn should be executed only if the branch is not 9963 taken. *Note Delay Slots::. 9964 9965 These expression codes appear in place of a side effect, as the body of 9966 an insn, though strictly speaking they do not always describe side 9967 effects as such: 9968 9969 `(asm_input S)' 9970 Represents literal assembler code as described by the string S. 9971 9972 `(unspec [OPERANDS ...] INDEX)' 9973 `(unspec_volatile [OPERANDS ...] INDEX)' 9974 Represents a machine-specific operation on OPERANDS. INDEX 9975 selects between multiple machine-specific operations. 9976 `unspec_volatile' is used for volatile operations and operations 9977 that may trap; `unspec' is used for other operations. 9978 9979 These codes may appear inside a `pattern' of an insn, inside a 9980 `parallel', or inside an expression. 9981 9982 `(addr_vec:M [LR0 LR1 ...])' 9983 Represents a table of jump addresses. The vector elements LR0, 9984 etc., are `label_ref' expressions. The mode M specifies how much 9985 space is given to each address; normally M would be `Pmode'. 9986 9987 `(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 9988 Represents a table of jump addresses expressed as offsets from 9989 BASE. The vector elements LR0, etc., are `label_ref' expressions 9990 and so is BASE. The mode M specifies how much space is given to 9991 each address-difference. MIN and MAX are set up by branch 9992 shortening and hold a label with a minimum and a maximum address, 9993 respectively. FLAGS indicates the relative position of BASE, MIN 9994 and MAX to the containing insn and of MIN and MAX to BASE. See 9995 rtl.def for details. 9996 9997 `(prefetch:M ADDR RW LOCALITY)' 9998 Represents prefetch of memory at address ADDR. Operand RW is 1 if 9999 the prefetch is for data to be written, 0 otherwise; targets that 10000 do not support write prefetches should treat this as a normal 10001 prefetch. Operand LOCALITY specifies the amount of temporal 10002 locality; 0 if there is none or 1, 2, or 3 for increasing levels 10003 of temporal locality; targets that do not support locality hints 10004 should ignore this. 10005 10006 This insn is used to minimize cache-miss latency by moving data 10007 into a cache before it is accessed. It should use only 10008 non-faulting data prefetch instructions. 10009 10010 10011 File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 10012 10013 10.16 Embedded Side-Effects on Addresses 10014 ======================================== 10015 10016 Six special side-effect expression codes appear as memory addresses. 10017 10018 `(pre_dec:M X)' 10019 Represents the side effect of decrementing X by a standard amount 10020 and represents also the value that X has after being decremented. 10021 X must be a `reg' or `mem', but most machines allow only a `reg'. 10022 M must be the machine mode for pointers on the machine in use. 10023 The amount X is decremented by is the length in bytes of the 10024 machine mode of the containing memory reference of which this 10025 expression serves as the address. Here is an example of its use: 10026 10027 (mem:DF (pre_dec:SI (reg:SI 39))) 10028 10029 This says to decrement pseudo register 39 by the length of a 10030 `DFmode' value and use the result to address a `DFmode' value. 10031 10032 `(pre_inc:M X)' 10033 Similar, but specifies incrementing X instead of decrementing it. 10034 10035 `(post_dec:M X)' 10036 Represents the same side effect as `pre_dec' but a different 10037 value. The value represented here is the value X has before being 10038 decremented. 10039 10040 `(post_inc:M X)' 10041 Similar, but specifies incrementing X instead of decrementing it. 10042 10043 `(post_modify:M X Y)' 10044 Represents the side effect of setting X to Y and represents X 10045 before X is modified. X must be a `reg' or `mem', but most 10046 machines allow only a `reg'. M must be the machine mode for 10047 pointers on the machine in use. 10048 10049 The expression Y must be one of three forms: `(plus:M X Z)', 10050 `(minus:M X Z)', or `(plus:M X I)', where Z is an index register 10051 and I is a constant. 10052 10053 Here is an example of its use: 10054 10055 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 10056 (reg:SI 48)))) 10057 10058 This says to modify pseudo register 42 by adding the contents of 10059 pseudo register 48 to it, after the use of what ever 42 points to. 10060 10061 `(pre_modify:M X EXPR)' 10062 Similar except side effects happen before the use. 10063 10064 These embedded side effect expressions must be used with care. 10065 Instruction patterns may not use them. Until the `flow' pass of the 10066 compiler, they may occur only to represent pushes onto the stack. The 10067 `flow' pass finds cases where registers are incremented or decremented 10068 in one instruction and used as an address shortly before or after; 10069 these cases are then transformed to use pre- or post-increment or 10070 -decrement. 10071 10072 If a register used as the operand of these expressions is used in 10073 another address in an insn, the original value of the register is used. 10074 Uses of the register outside of an address are not permitted within the 10075 same insn as a use in an embedded side effect expression because such 10076 insns behave differently on different machines and hence must be treated 10077 as ambiguous and disallowed. 10078 10079 An instruction that can be represented with an embedded side effect 10080 could also be represented using `parallel' containing an additional 10081 `set' to describe how the address register is altered. This is not 10082 done because machines that allow these operations at all typically 10083 allow them wherever a memory address is called for. Describing them as 10084 additional parallel stores would require doubling the number of entries 10085 in the machine description. 10086 10087 10088 File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 10089 10090 10.17 Assembler Instructions as Expressions 10091 =========================================== 10092 10093 The RTX code `asm_operands' represents a value produced by a 10094 user-specified assembler instruction. It is used to represent an `asm' 10095 statement with arguments. An `asm' statement with a single output 10096 operand, like this: 10097 10098 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 10099 10100 is represented using a single `asm_operands' RTX which represents the 10101 value that is stored in `outputvar': 10102 10103 (set RTX-FOR-OUTPUTVAR 10104 (asm_operands "foo %1,%2,%0" "a" 0 10105 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 10106 [(asm_input:M1 "g") 10107 (asm_input:M2 "di")])) 10108 10109 Here the operands of the `asm_operands' RTX are the assembler template 10110 string, the output-operand's constraint, the index-number of the output 10111 operand among the output operands specified, a vector of input operand 10112 RTX's, and a vector of input-operand modes and constraints. The mode 10113 M1 is the mode of the sum `x+y'; M2 is that of `*z'. 10114 10115 When an `asm' statement has multiple output values, its insn has 10116 several such `set' RTX's inside of a `parallel'. Each `set' contains 10117 an `asm_operands'; all of these share the same assembler template and 10118 vectors, but each contains the constraint for the respective output 10119 operand. They are also distinguished by the output-operand index 10120 number, which is 0, 1, ... for successive output operands. 10121 10122 10123 File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 10124 10125 10.18 Variable Location Debug Information in RTL 10126 ================================================ 10127 10128 Variable tracking relies on `MEM_EXPR' and `REG_EXPR' annotations to 10129 determine what user variables memory and register references refer to. 10130 10131 Variable tracking at assignments uses these notes only when they refer 10132 to variables that live at fixed locations (e.g., addressable variables, 10133 global non-automatic variables). For variables whose location may 10134 vary, it relies on the following types of notes. 10135 10136 `(var_location:MODE VAR EXP STAT)' 10137 Binds variable `var', a tree, to value EXP, an RTL expression. It 10138 appears only in `NOTE_INSN_VAR_LOCATION' and `DEBUG_INSN's, with 10139 slightly different meanings. MODE, if present, represents the 10140 mode of EXP, which is useful if it is a modeless expression. STAT 10141 is only meaningful in notes, indicating whether the variable is 10142 known to be initialized or uninitialized. 10143 10144 `(debug_expr:MODE DECL)' 10145 Stands for the value bound to the `DEBUG_EXPR_DECL' DECL, that 10146 points back to it, within value expressions in `VAR_LOCATION' 10147 nodes. 10148 10149 10150 10151 File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 10152 10153 10.19 Insns 10154 =========== 10155 10156 The RTL representation of the code for a function is a doubly-linked 10157 chain of objects called "insns". Insns are expressions with special 10158 codes that are used for no other purpose. Some insns are actual 10159 instructions; others represent dispatch tables for `switch' statements; 10160 others represent labels to jump to or various sorts of declarative 10161 information. 10162 10163 In addition to its own specific data, each insn must have a unique 10164 id-number that distinguishes it from all other insns in the current 10165 function (after delayed branch scheduling, copies of an insn with the 10166 same id-number may be present in multiple places in a function, but 10167 these copies will always be identical and will only appear inside a 10168 `sequence'), and chain pointers to the preceding and following insns. 10169 These three fields occupy the same position in every insn, independent 10170 of the expression code of the insn. They could be accessed with `XEXP' 10171 and `XINT', but instead three special macros are always used: 10172 10173 `INSN_UID (I)' 10174 Accesses the unique id of insn I. 10175 10176 `PREV_INSN (I)' 10177 Accesses the chain pointer to the insn preceding I. If I is the 10178 first insn, this is a null pointer. 10179 10180 `NEXT_INSN (I)' 10181 Accesses the chain pointer to the insn following I. If I is the 10182 last insn, this is a null pointer. 10183 10184 The first insn in the chain is obtained by calling `get_insns'; the 10185 last insn is the result of calling `get_last_insn'. Within the chain 10186 delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must 10187 always correspond: if INSN is not the first insn, 10188 10189 NEXT_INSN (PREV_INSN (INSN)) == INSN 10190 10191 is always true and if INSN is not the last insn, 10192 10193 PREV_INSN (NEXT_INSN (INSN)) == INSN 10194 10195 is always true. 10196 10197 After delay slot scheduling, some of the insns in the chain might be 10198 `sequence' expressions, which contain a vector of insns. The value of 10199 `NEXT_INSN' in all but the last of these insns is the next insn in the 10200 vector; the value of `NEXT_INSN' of the last insn in the vector is the 10201 same as the value of `NEXT_INSN' for the `sequence' in which it is 10202 contained. Similar rules apply for `PREV_INSN'. 10203 10204 This means that the above invariants are not necessarily true for insns 10205 inside `sequence' expressions. Specifically, if INSN is the first insn 10206 in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn containing 10207 the `sequence' expression, as is the value of `PREV_INSN (NEXT_INSN 10208 (INSN))' if INSN is the last insn in the `sequence' expression. You 10209 can use these expressions to find the containing `sequence' expression. 10210 10211 Every insn has one of the following expression codes: 10212 10213 `insn' 10214 The expression code `insn' is used for instructions that do not 10215 jump and do not do function calls. `sequence' expressions are 10216 always contained in insns with code `insn' even if one of those 10217 insns should jump or do function calls. 10218 10219 Insns with code `insn' have four additional fields beyond the three 10220 mandatory ones listed above. These four are described in a table 10221 below. 10222 10223 `jump_insn' 10224 The expression code `jump_insn' is used for instructions that may 10225 jump (or, more generally, may contain `label_ref' expressions to 10226 which `pc' can be set in that instruction). If there is an 10227 instruction to return from the current function, it is recorded as 10228 a `jump_insn'. 10229 10230 `jump_insn' insns have the same extra fields as `insn' insns, 10231 accessed in the same way and in addition contain a field 10232 `JUMP_LABEL' which is defined once jump optimization has completed. 10233 10234 For simple conditional and unconditional jumps, this field contains 10235 the `code_label' to which this insn will (possibly conditionally) 10236 branch. In a more complex jump, `JUMP_LABEL' records one of the 10237 labels that the insn refers to; other jump target labels are 10238 recorded as `REG_LABEL_TARGET' notes. The exception is `addr_vec' 10239 and `addr_diff_vec', where `JUMP_LABEL' is `NULL_RTX' and the only 10240 way to find the labels is to scan the entire body of the insn. 10241 10242 Return insns count as jumps, but since they do not refer to any 10243 labels, their `JUMP_LABEL' is `NULL_RTX'. 10244 10245 `call_insn' 10246 The expression code `call_insn' is used for instructions that may 10247 do function calls. It is important to distinguish these 10248 instructions because they imply that certain registers and memory 10249 locations may be altered unpredictably. 10250 10251 `call_insn' insns have the same extra fields as `insn' insns, 10252 accessed in the same way and in addition contain a field 10253 `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 10254 `expr_list' expressions) containing `use', `clobber' and sometimes 10255 `set' expressions that denote hard registers and `mem's used or 10256 clobbered by the called function. 10257 10258 A `mem' generally points to a stack slot in which arguments passed 10259 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 10260 Register Arguments.) are stored. If the argument is caller-copied 10261 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 10262 will be mentioned in `clobber' and `use' entries; if it's 10263 callee-copied, only a `use' will appear, and the `mem' may point 10264 to addresses that are not stack slots. 10265 10266 Registers occurring inside a `clobber' in this list augment 10267 registers specified in `CALL_USED_REGISTERS' (*note Register 10268 Basics::). 10269 10270 If the list contains a `set' involving two registers, it indicates 10271 that the function returns one of its arguments. Such a `set' may 10272 look like a no-op if the same register holds the argument and the 10273 return value. 10274 10275 `code_label' 10276 A `code_label' insn represents a label that a jump insn can jump 10277 to. It contains two special fields of data in addition to the 10278 three standard ones. `CODE_LABEL_NUMBER' is used to hold the 10279 "label number", a number that identifies this label uniquely among 10280 all the labels in the compilation (not just in the current 10281 function). Ultimately, the label is represented in the assembler 10282 output as an assembler label, usually of the form `LN' where N is 10283 the label number. 10284 10285 When a `code_label' appears in an RTL expression, it normally 10286 appears within a `label_ref' which represents the address of the 10287 label, as a number. 10288 10289 Besides as a `code_label', a label can also be represented as a 10290 `note' of type `NOTE_INSN_DELETED_LABEL'. 10291 10292 The field `LABEL_NUSES' is only defined once the jump optimization 10293 phase is completed. It contains the number of times this label is 10294 referenced in the current function. 10295 10296 The field `LABEL_KIND' differentiates four different types of 10297 labels: `LABEL_NORMAL', `LABEL_STATIC_ENTRY', 10298 `LABEL_GLOBAL_ENTRY', and `LABEL_WEAK_ENTRY'. The only labels 10299 that do not have type `LABEL_NORMAL' are "alternate entry points" 10300 to the current function. These may be static (visible only in the 10301 containing translation unit), global (exposed to all translation 10302 units), or weak (global, but can be overridden by another symbol 10303 with the same name). 10304 10305 Much of the compiler treats all four kinds of label identically. 10306 Some of it needs to know whether or not a label is an alternate 10307 entry point; for this purpose, the macro `LABEL_ALT_ENTRY_P' is 10308 provided. It is equivalent to testing whether `LABEL_KIND (label) 10309 == LABEL_NORMAL'. The only place that cares about the distinction 10310 between static, global, and weak alternate entry points, besides 10311 the front-end code that creates them, is the function 10312 `output_alternate_entry_point', in `final.c'. 10313 10314 To set the kind of a label, use the `SET_LABEL_KIND' macro. 10315 10316 `barrier' 10317 Barriers are placed in the instruction stream when control cannot 10318 flow past them. They are placed after unconditional jump 10319 instructions to indicate that the jumps are unconditional and 10320 after calls to `volatile' functions, which do not return (e.g., 10321 `exit'). They contain no information beyond the three standard 10322 fields. 10323 10324 `note' 10325 `note' insns are used to represent additional debugging and 10326 declarative information. They contain two nonstandard fields, an 10327 integer which is accessed with the macro `NOTE_LINE_NUMBER' and a 10328 string accessed with `NOTE_SOURCE_FILE'. 10329 10330 If `NOTE_LINE_NUMBER' is positive, the note represents the 10331 position of a source line and `NOTE_SOURCE_FILE' is the source 10332 file name that the line came from. These notes control generation 10333 of line number data in the assembler output. 10334 10335 Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a 10336 code with one of the following values (and `NOTE_SOURCE_FILE' must 10337 contain a null pointer): 10338 10339 `NOTE_INSN_DELETED' 10340 Such a note is completely ignorable. Some passes of the 10341 compiler delete insns by altering them into notes of this 10342 kind. 10343 10344 `NOTE_INSN_DELETED_LABEL' 10345 This marks what used to be a `code_label', but was not used 10346 for other purposes than taking its address and was 10347 transformed to mark that no code jumps to it. 10348 10349 `NOTE_INSN_BLOCK_BEG' 10350 `NOTE_INSN_BLOCK_END' 10351 These types of notes indicate the position of the beginning 10352 and end of a level of scoping of variable names. They 10353 control the output of debugging information. 10354 10355 `NOTE_INSN_EH_REGION_BEG' 10356 `NOTE_INSN_EH_REGION_END' 10357 These types of notes indicate the position of the beginning 10358 and end of a level of scoping for exception handling. 10359 `NOTE_BLOCK_NUMBER' identifies which `CODE_LABEL' or `note' 10360 of type `NOTE_INSN_DELETED_LABEL' is associated with the 10361 given region. 10362 10363 `NOTE_INSN_LOOP_BEG' 10364 `NOTE_INSN_LOOP_END' 10365 These types of notes indicate the position of the beginning 10366 and end of a `while' or `for' loop. They enable the loop 10367 optimizer to find loops quickly. 10368 10369 `NOTE_INSN_LOOP_CONT' 10370 Appears at the place in a loop that `continue' statements 10371 jump to. 10372 10373 `NOTE_INSN_LOOP_VTOP' 10374 This note indicates the place in a loop where the exit test 10375 begins for those loops in which the exit test has been 10376 duplicated. This position becomes another virtual start of 10377 the loop when considering loop invariants. 10378 10379 `NOTE_INSN_FUNCTION_BEG' 10380 Appears at the start of the function body, after the function 10381 prologue. 10382 10383 `NOTE_INSN_VAR_LOCATION' 10384 This note is used to generate variable location debugging 10385 information. It indicates that the user variable in its 10386 `VAR_LOCATION' operand is at the location given in the RTL 10387 expression, or holds a value that can be computed by 10388 evaluating the RTL expression from that static point in the 10389 program up to the next such note for the same user variable. 10390 10391 10392 These codes are printed symbolically when they appear in debugging 10393 dumps. 10394 10395 `debug_insn' 10396 The expression code `debug_insn' is used for pseudo-instructions 10397 that hold debugging information for variable tracking at 10398 assignments (see `-fvar-tracking-assignments' option). They are 10399 the RTL representation of `GIMPLE_DEBUG' statements (*note 10400 `GIMPLE_DEBUG'::), with a `VAR_LOCATION' operand that binds a user 10401 variable tree to an RTL representation of the `value' in the 10402 corresponding statement. A `DEBUG_EXPR' in it stands for the 10403 value bound to the corresponding `DEBUG_EXPR_DECL'. 10404 10405 Throughout optimization passes, binding information is kept in 10406 pseudo-instruction form, so that, unlike notes, it gets the same 10407 treatment and adjustments that regular instructions would. It is 10408 the variable tracking pass that turns these pseudo-instructions 10409 into var location notes, analyzing control flow, value 10410 equivalences and changes to registers and memory referenced in 10411 value expressions, propagating the values of debug temporaries and 10412 determining expressions that can be used to compute the value of 10413 each user variable at as many points (ranges, actually) in the 10414 program as possible. 10415 10416 Unlike `NOTE_INSN_VAR_LOCATION', the value expression in an 10417 `INSN_VAR_LOCATION' denotes a value at that specific point in the 10418 program, rather than an expression that can be evaluated at any 10419 later point before an overriding `VAR_LOCATION' is encountered. 10420 E.g., if a user variable is bound to a `REG' and then a subsequent 10421 insn modifies the `REG', the note location would keep mapping the 10422 user variable to the register across the insn, whereas the insn 10423 location would keep the variable bound to the value, so that the 10424 variable tracking pass would emit another location note for the 10425 variable at the point in which the register is modified. 10426 10427 10428 The machine mode of an insn is normally `VOIDmode', but some phases 10429 use the mode for various purposes. 10430 10431 The common subexpression elimination pass sets the mode of an insn to 10432 `QImode' when it is the first insn in a block that has already been 10433 processed. 10434 10435 The second Haifa scheduling pass, for targets that can multiple issue, 10436 sets the mode of an insn to `TImode' when it is believed that the 10437 instruction begins an issue group. That is, when the instruction 10438 cannot issue simultaneously with the previous. This may be relied on 10439 by later passes, in particular machine-dependent reorg. 10440 10441 Here is a table of the extra fields of `insn', `jump_insn' and 10442 `call_insn' insns: 10443 10444 `PATTERN (I)' 10445 An expression for the side effect performed by this insn. This 10446 must be one of the following codes: `set', `call', `use', 10447 `clobber', `return', `simple_return', `asm_input', `asm_output', 10448 `addr_vec', `addr_diff_vec', `trap_if', `unspec', 10449 `unspec_volatile', `parallel', `cond_exec', or `sequence'. If it 10450 is a `parallel', each element of the `parallel' must be one these 10451 codes, except that `parallel' expressions cannot be nested and 10452 `addr_vec' and `addr_diff_vec' are not permitted inside a 10453 `parallel' expression. 10454 10455 `INSN_CODE (I)' 10456 An integer that says which pattern in the machine description 10457 matches this insn, or -1 if the matching has not yet been 10458 attempted. 10459 10460 Such matching is never attempted and this field remains -1 on an 10461 insn whose pattern consists of a single `use', `clobber', 10462 `asm_input', `addr_vec' or `addr_diff_vec' expression. 10463 10464 Matching is also never attempted on insns that result from an `asm' 10465 statement. These contain at least one `asm_operands' expression. 10466 The function `asm_noperands' returns a non-negative value for such 10467 insns. 10468 10469 In the debugging output, this field is printed as a number 10470 followed by a symbolic representation that locates the pattern in 10471 the `md' file as some small positive or negative offset from a 10472 named pattern. 10473 10474 `LOG_LINKS (I)' 10475 A list (chain of `insn_list' expressions) giving information about 10476 dependencies between instructions within a basic block. Neither a 10477 jump nor a label may come between the related insns. These are 10478 only used by the schedulers and by combine. This is a deprecated 10479 data structure. Def-use and use-def chains are now preferred. 10480 10481 `REG_NOTES (I)' 10482 A list (chain of `expr_list' and `insn_list' expressions) giving 10483 miscellaneous information about the insn. It is often information 10484 pertaining to the registers used in this insn. 10485 10486 The `LOG_LINKS' field of an insn is a chain of `insn_list' 10487 expressions. Each of these has two operands: the first is an insn, and 10488 the second is another `insn_list' expression (the next one in the 10489 chain). The last `insn_list' in the chain has a null pointer as second 10490 operand. The significant thing about the chain is which insns appear 10491 in it (as first operands of `insn_list' expressions). Their order is 10492 not significant. 10493 10494 This list is originally set up by the flow analysis pass; it is a null 10495 pointer until then. Flow only adds links for those data dependencies 10496 which can be used for instruction combination. For each insn, the flow 10497 analysis pass adds a link to insns which store into registers values 10498 that are used for the first time in this insn. 10499 10500 The `REG_NOTES' field of an insn is a chain similar to the `LOG_LINKS' 10501 field but it includes `expr_list' expressions in addition to 10502 `insn_list' expressions. There are several kinds of register notes, 10503 which are distinguished by the machine mode, which in a register note 10504 is really understood as being an `enum reg_note'. The first operand OP 10505 of the note is data whose meaning depends on the kind of note. 10506 10507 The macro `REG_NOTE_KIND (X)' returns the kind of register note. Its 10508 counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 10509 register note type of X to be NEWKIND. 10510 10511 Register notes are of three classes: They may say something about an 10512 input to an insn, they may say something about an output of an insn, or 10513 they may create a linkage between two insns. There are also a set of 10514 values that are only used in `LOG_LINKS'. 10515 10516 These register notes annotate inputs to an insn: 10517 10518 `REG_DEAD' 10519 The value in OP dies in this insn; that is to say, altering the 10520 value immediately after this insn would not affect the future 10521 behavior of the program. 10522 10523 It does not follow that the register OP has no useful value after 10524 this insn since OP is not necessarily modified by this insn. 10525 Rather, no subsequent instruction uses the contents of OP. 10526 10527 `REG_UNUSED' 10528 The register OP being set by this insn will not be used in a 10529 subsequent insn. This differs from a `REG_DEAD' note, which 10530 indicates that the value in an input will not be used subsequently. 10531 These two notes are independent; both may be present for the same 10532 register. 10533 10534 `REG_INC' 10535 The register OP is incremented (or decremented; at this level 10536 there is no distinction) by an embedded side effect inside this 10537 insn. This means it appears in a `post_inc', `pre_inc', 10538 `post_dec' or `pre_dec' expression. 10539 10540 `REG_NONNEG' 10541 The register OP is known to have a nonnegative value when this 10542 insn is reached. This is used so that decrement and branch until 10543 zero instructions, such as the m68k dbra, can be matched. 10544 10545 The `REG_NONNEG' note is added to insns only if the machine 10546 description has a `decrement_and_branch_until_zero' pattern. 10547 10548 `REG_LABEL_OPERAND' 10549 This insn uses OP, a `code_label' or a `note' of type 10550 `NOTE_INSN_DELETED_LABEL', but is not a `jump_insn', or it is a 10551 `jump_insn' that refers to the operand as an ordinary operand. 10552 The label may still eventually be a jump target, but if so in an 10553 indirect jump in a subsequent insn. The presence of this note 10554 allows jump optimization to be aware that OP is, in fact, being 10555 used, and flow optimization to build an accurate flow graph. 10556 10557 `REG_LABEL_TARGET' 10558 This insn is a `jump_insn' but not an `addr_vec' or 10559 `addr_diff_vec'. It uses OP, a `code_label' as a direct or 10560 indirect jump target. Its purpose is similar to that of 10561 `REG_LABEL_OPERAND'. This note is only present if the insn has 10562 multiple targets; the last label in the insn (in the highest 10563 numbered insn-field) goes into the `JUMP_LABEL' field and does not 10564 have a `REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 10565 10566 `REG_CROSSING_JUMP' 10567 This insn is a branching instruction (either an unconditional jump 10568 or an indirect jump) which crosses between hot and cold sections, 10569 which could potentially be very far apart in the executable. The 10570 presence of this note indicates to other optimizations that this 10571 branching instruction should not be "collapsed" into a simpler 10572 branching construct. It is used when the optimization to 10573 partition basic blocks into hot and cold sections is turned on. 10574 10575 `REG_SETJMP' 10576 Appears attached to each `CALL_INSN' to `setjmp' or a related 10577 function. 10578 10579 The following notes describe attributes of outputs of an insn: 10580 10581 `REG_EQUIV' 10582 `REG_EQUAL' 10583 This note is only valid on an insn that sets only one register and 10584 indicates that that register will be equal to OP at run time; the 10585 scope of this equivalence differs between the two types of notes. 10586 The value which the insn explicitly copies into the register may 10587 look different from OP, but they will be equal at run time. If the 10588 output of the single `set' is a `strict_low_part' expression, the 10589 note refers to the register that is contained in `SUBREG_REG' of 10590 the `subreg' expression. 10591 10592 For `REG_EQUIV', the register is equivalent to OP throughout the 10593 entire function, and could validly be replaced in all its 10594 occurrences by OP. ("Validly" here refers to the data flow of the 10595 program; simple replacement may make some insns invalid.) For 10596 example, when a constant is loaded into a register that is never 10597 assigned any other value, this kind of note is used. 10598 10599 When a parameter is copied into a pseudo-register at entry to a 10600 function, a note of this kind records that the register is 10601 equivalent to the stack slot where the parameter was passed. 10602 Although in this case the register may be set by other insns, it 10603 is still valid to replace the register by the stack slot 10604 throughout the function. 10605 10606 A `REG_EQUIV' note is also used on an instruction which copies a 10607 register parameter into a pseudo-register at entry to a function, 10608 if there is a stack slot where that parameter could be stored. 10609 Although other insns may set the pseudo-register, it is valid for 10610 the compiler to replace the pseudo-register by stack slot 10611 throughout the function, provided the compiler ensures that the 10612 stack slot is properly initialized by making the replacement in 10613 the initial copy instruction as well. This is used on machines 10614 for which the calling convention allocates stack space for 10615 register parameters. See `REG_PARM_STACK_SPACE' in *note Stack 10616 Arguments::. 10617 10618 In the case of `REG_EQUAL', the register that is set by this insn 10619 will be equal to OP at run time at the end of this insn but not 10620 necessarily elsewhere in the function. In this case, OP is 10621 typically an arithmetic expression. For example, when a sequence 10622 of insns such as a library call is used to perform an arithmetic 10623 operation, this kind of note is attached to the insn that produces 10624 or copies the final value. 10625 10626 These two notes are used in different ways by the compiler passes. 10627 `REG_EQUAL' is used by passes prior to register allocation (such as 10628 common subexpression elimination and loop optimization) to tell 10629 them how to think of that value. `REG_EQUIV' notes are used by 10630 register allocation to indicate that there is an available 10631 substitute expression (either a constant or a `mem' expression for 10632 the location of a parameter on the stack) that may be used in 10633 place of a register if insufficient registers are available. 10634 10635 Except for stack homes for parameters, which are indicated by a 10636 `REG_EQUIV' note and are not useful to the early optimization 10637 passes and pseudo registers that are equivalent to a memory 10638 location throughout their entire life, which is not detected until 10639 later in the compilation, all equivalences are initially indicated 10640 by an attached `REG_EQUAL' note. In the early stages of register 10641 allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note 10642 if OP is a constant and the insn represents the only set of its 10643 destination register. 10644 10645 Thus, compiler passes prior to register allocation need only check 10646 for `REG_EQUAL' notes and passes subsequent to register allocation 10647 need only check for `REG_EQUIV' notes. 10648 10649 These notes describe linkages between insns. They occur in pairs: one 10650 insn has one of a pair of notes that points to a second insn, which has 10651 the inverse note pointing back to the first insn. 10652 10653 `REG_CC_SETTER' 10654 `REG_CC_USER' 10655 On machines that use `cc0', the insns which set and use `cc0' set 10656 and use `cc0' are adjacent. However, when branch delay slot 10657 filling is done, this may no longer be true. In this case a 10658 `REG_CC_USER' note will be placed on the insn setting `cc0' to 10659 point to the insn using `cc0' and a `REG_CC_SETTER' note will be 10660 placed on the insn using `cc0' to point to the insn setting `cc0'. 10661 10662 These values are only used in the `LOG_LINKS' field, and indicate the 10663 type of dependency that each link represents. Links which indicate a 10664 data dependence (a read after write dependence) do not use any code, 10665 they simply have mode `VOIDmode', and are printed without any 10666 descriptive text. 10667 10668 `REG_DEP_TRUE' 10669 This indicates a true dependence (a read after write dependence). 10670 10671 `REG_DEP_OUTPUT' 10672 This indicates an output dependence (a write after write 10673 dependence). 10674 10675 `REG_DEP_ANTI' 10676 This indicates an anti dependence (a write after read dependence). 10677 10678 10679 These notes describe information gathered from gcov profile data. They 10680 are stored in the `REG_NOTES' field of an insn as an `expr_list'. 10681 10682 `REG_BR_PROB' 10683 This is used to specify the ratio of branches to non-branches of a 10684 branch insn according to the profile data. The value is stored as 10685 a value between 0 and REG_BR_PROB_BASE; larger values indicate a 10686 higher probability that the branch will be taken. 10687 10688 `REG_BR_PRED' 10689 These notes are found in JUMP insns after delayed branch scheduling 10690 has taken place. They indicate both the direction and the 10691 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 10692 values. 10693 10694 `REG_FRAME_RELATED_EXPR' 10695 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 10696 expression is used in place of the actual insn pattern. This is 10697 done in cases where the pattern is either complex or misleading. 10698 10699 For convenience, the machine mode in an `insn_list' or `expr_list' is 10700 printed using these symbolic codes in debugging dumps. 10701 10702 The only difference between the expression codes `insn_list' and 10703 `expr_list' is that the first operand of an `insn_list' is assumed to 10704 be an insn and is printed in debugging dumps as the insn's unique id; 10705 the first operand of an `expr_list' is printed in the ordinary way as 10706 an expression. 10707 10708 10709 File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 10710 10711 10.20 RTL Representation of Function-Call Insns 10712 =============================================== 10713 10714 Insns that call subroutines have the RTL expression code `call_insn'. 10715 These insns must satisfy special rules, and their bodies must use a 10716 special RTL expression code, `call'. 10717 10718 A `call' expression has two operands, as follows: 10719 10720 (call (mem:FM ADDR) NBYTES) 10721 10722 Here NBYTES is an operand that represents the number of bytes of 10723 argument data being passed to the subroutine, FM is a machine mode 10724 (which must equal as the definition of the `FUNCTION_MODE' macro in the 10725 machine description) and ADDR represents the address of the subroutine. 10726 10727 For a subroutine that returns no value, the `call' expression as shown 10728 above is the entire body of the insn, except that the insn might also 10729 contain `use' or `clobber' expressions. 10730 10731 For a subroutine that returns a value whose mode is not `BLKmode', the 10732 value is returned in a hard register. If this register's number is R, 10733 then the body of the call insn looks like this: 10734 10735 (set (reg:M R) 10736 (call (mem:FM ADDR) NBYTES)) 10737 10738 This RTL expression makes it clear (to the optimizer passes) that the 10739 appropriate register receives a useful value in this insn. 10740 10741 When a subroutine returns a `BLKmode' value, it is handled by passing 10742 to the subroutine the address of a place to store the value. So the 10743 call insn itself does not "return" any value, and it has the same RTL 10744 form as a call that returns nothing. 10745 10746 On some machines, the call instruction itself clobbers some register, 10747 for example to contain the return address. `call_insn' insns on these 10748 machines should have a body which is a `parallel' that contains both 10749 the `call' expression and `clobber' expressions that indicate which 10750 registers are destroyed. Similarly, if the call instruction requires 10751 some register other than the stack pointer that is not explicitly 10752 mentioned in its RTL, a `use' subexpression should mention that 10753 register. 10754 10755 Functions that are called are assumed to modify all registers listed in 10756 the configuration macro `CALL_USED_REGISTERS' (*note Register Basics::) 10757 and, with the exception of `const' functions and library calls, to 10758 modify all of memory. 10759 10760 Insns containing just `use' expressions directly precede the 10761 `call_insn' insn to indicate which registers contain inputs to the 10762 function. Similarly, if registers other than those in 10763 `CALL_USED_REGISTERS' are clobbered by the called function, insns 10764 containing a single `clobber' follow immediately after the call to 10765 indicate which registers. 10766 10767 10768 File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 10769 10770 10.21 Structure Sharing Assumptions 10771 =================================== 10772 10773 The compiler assumes that certain kinds of RTL expressions are unique; 10774 there do not exist two distinct objects representing the same value. 10775 In other cases, it makes an opposite assumption: that no RTL expression 10776 object of a certain kind appears in more than one place in the 10777 containing structure. 10778 10779 These assumptions refer to a single function; except for the RTL 10780 objects that describe global variables and external functions, and a 10781 few standard objects such as small integer constants, no RTL objects 10782 are common to two functions. 10783 10784 * Each pseudo-register has only a single `reg' object to represent 10785 it, and therefore only a single machine mode. 10786 10787 * For any symbolic label, there is only one `symbol_ref' object 10788 referring to it. 10789 10790 * All `const_int' expressions with equal values are shared. 10791 10792 * There is only one `pc' expression. 10793 10794 * There is only one `cc0' expression. 10795 10796 * There is only one `const_double' expression with value 0 for each 10797 floating point mode. Likewise for values 1 and 2. 10798 10799 * There is only one `const_vector' expression with value 0 for each 10800 vector mode, be it an integer or a double constant vector. 10801 10802 * No `label_ref' or `scratch' appears in more than one place in the 10803 RTL structure; in other words, it is safe to do a tree-walk of all 10804 the insns in the function and assume that each time a `label_ref' 10805 or `scratch' is seen it is distinct from all others that are seen. 10806 10807 * Only one `mem' object is normally created for each static variable 10808 or stack slot, so these objects are frequently shared in all the 10809 places they appear. However, separate but equal objects for these 10810 variables are occasionally made. 10811 10812 * When a single `asm' statement has multiple output operands, a 10813 distinct `asm_operands' expression is made for each output operand. 10814 However, these all share the vector which contains the sequence of 10815 input operands. This sharing is used later on to test whether two 10816 `asm_operands' expressions come from the same statement, so all 10817 optimizations must carefully preserve the sharing if they copy the 10818 vector at all. 10819 10820 * No RTL object appears in more than one place in the RTL structure 10821 except as described above. Many passes of the compiler rely on 10822 this by assuming that they can modify RTL objects in place without 10823 unwanted side-effects on other insns. 10824 10825 * During initial RTL generation, shared structure is freely 10826 introduced. After all the RTL for a function has been generated, 10827 all shared structure is copied by `unshare_all_rtl' in 10828 `emit-rtl.c', after which the above rules are guaranteed to be 10829 followed. 10830 10831 * During the combiner pass, shared structure within an insn can exist 10832 temporarily. However, the shared structure is copied before the 10833 combiner is finished with the insn. This is done by calling 10834 `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'. 10835 10836 10837 File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 10838 10839 10.22 Reading RTL 10840 ================= 10841 10842 To read an RTL object from a file, call `read_rtx'. It takes one 10843 argument, a stdio stream, and returns a single RTL object. This routine 10844 is defined in `read-rtl.c'. It is not available in the compiler 10845 itself, only the various programs that generate the compiler back end 10846 from the machine description. 10847 10848 People frequently have the idea of using RTL stored as text in a file 10849 as an interface between a language front end and the bulk of GCC. This 10850 idea is not feasible. 10851 10852 GCC was designed to use RTL internally only. Correct RTL for a given 10853 program is very dependent on the particular target machine. And the RTL 10854 does not contain all the information about the program. 10855 10856 The proper way to interface GCC to a new language front end is with 10857 the "tree" data structure, described in the files `tree.h' and 10858 `tree.def'. The documentation for this structure (*note GENERIC::) is 10859 incomplete. 10860 10861 10862 File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: Passes, Up: Top 10863 10864 11 GENERIC 10865 ********** 10866 10867 The purpose of GENERIC is simply to provide a language-independent way 10868 of representing an entire function in trees. To this end, it was 10869 necessary to add a few new tree codes to the back end, but most 10870 everything was already there. If you can express it with the codes in 10871 `gcc/tree.def', it's GENERIC. 10872 10873 Early on, there was a great deal of debate about how to think about 10874 statements in a tree IL. In GENERIC, a statement is defined as any 10875 expression whose value, if any, is ignored. A statement will always 10876 have `TREE_SIDE_EFFECTS' set (or it will be discarded), but a 10877 non-statement expression may also have side effects. A `CALL_EXPR', 10878 for instance. 10879 10880 It would be possible for some local optimizations to work on the 10881 GENERIC form of a function; indeed, the adapted tree inliner works fine 10882 on GENERIC, but the current compiler performs inlining after lowering 10883 to GIMPLE (a restricted form described in the next section). Indeed, 10884 currently the frontends perform this lowering before handing off to 10885 `tree_rest_of_compilation', but this seems inelegant. 10886 10887 * Menu: 10888 10889 * Deficiencies:: Topics net yet covered in this document. 10890 * Tree overview:: All about `tree's. 10891 * Types:: Fundamental and aggregate types. 10892 * Declarations:: Type declarations and variables. 10893 * Attributes:: Declaration and type attributes. 10894 * Expressions: Expression trees. Operating on data. 10895 * Statements:: Control flow and related trees. 10896 * Functions:: Function bodies, linkage, and other aspects. 10897 * Language-dependent trees:: Topics and trees specific to language front ends. 10898 * C and C++ Trees:: Trees specific to C and C++. 10899 * Java Trees:: Trees specific to Java. 10900 10901 10902 File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 10903 10904 11.1 Deficiencies 10905 ================= 10906 10907 There are many places in which this document is incomplet and incorrekt. 10908 It is, as of yet, only _preliminary_ documentation. 10909 10910 10911 File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 10912 10913 11.2 Overview 10914 ============= 10915 10916 The central data structure used by the internal representation is the 10917 `tree'. These nodes, while all of the C type `tree', are of many 10918 varieties. A `tree' is a pointer type, but the object to which it 10919 points may be of a variety of types. From this point forward, we will 10920 refer to trees in ordinary type, rather than in `this font', except 10921 when talking about the actual C type `tree'. 10922 10923 You can tell what kind of node a particular tree is by using the 10924 `TREE_CODE' macro. Many, many macros take trees as input and return 10925 trees as output. However, most macros require a certain kind of tree 10926 node as input. In other words, there is a type-system for trees, but 10927 it is not reflected in the C type-system. 10928 10929 For safety, it is useful to configure GCC with `--enable-checking'. 10930 Although this results in a significant performance penalty (since all 10931 tree types are checked at run-time), and is therefore inappropriate in a 10932 release version, it is extremely helpful during the development process. 10933 10934 Many macros behave as predicates. Many, although not all, of these 10935 predicates end in `_P'. Do not rely on the result type of these macros 10936 being of any particular type. You may, however, rely on the fact that 10937 the type can be compared to `0', so that statements like 10938 if (TEST_P (t) && !TEST_P (y)) 10939 x = 1; 10940 and 10941 int i = (TEST_P (t) != 0); 10942 are legal. Macros that return `int' values now may be changed to 10943 return `tree' values, or other pointers in the future. Even those that 10944 continue to return `int' may return multiple nonzero codes where 10945 previously they returned only zero and one. Therefore, you should not 10946 write code like 10947 if (TEST_P (t) == 1) 10948 as this code is not guaranteed to work correctly in the future. 10949 10950 You should not take the address of values returned by the macros or 10951 functions described here. In particular, no guarantee is given that the 10952 values are lvalues. 10953 10954 In general, the names of macros are all in uppercase, while the names 10955 of functions are entirely in lowercase. There are rare exceptions to 10956 this rule. You should assume that any macro or function whose name is 10957 made up entirely of uppercase letters may evaluate its arguments more 10958 than once. You may assume that a macro or function whose name is made 10959 up entirely of lowercase letters will evaluate its arguments only once. 10960 10961 The `error_mark_node' is a special tree. Its tree code is 10962 `ERROR_MARK', but since there is only ever one node with that code, the 10963 usual practice is to compare the tree against `error_mark_node'. (This 10964 test is just a test for pointer equality.) If an error has occurred 10965 during front-end processing the flag `errorcount' will be set. If the 10966 front end has encountered code it cannot handle, it will issue a 10967 message to the user and set `sorrycount'. When these flags are set, 10968 any macro or function which normally returns a tree of a particular 10969 kind may instead return the `error_mark_node'. Thus, if you intend to 10970 do any processing of erroneous code, you must be prepared to deal with 10971 the `error_mark_node'. 10972 10973 Occasionally, a particular tree slot (like an operand to an expression, 10974 or a particular field in a declaration) will be referred to as 10975 "reserved for the back end". These slots are used to store RTL when 10976 the tree is converted to RTL for use by the GCC back end. However, if 10977 that process is not taking place (e.g., if the front end is being hooked 10978 up to an intelligent editor), then those slots may be used by the back 10979 end presently in use. 10980 10981 If you encounter situations that do not match this documentation, such 10982 as tree nodes of types not mentioned here, or macros documented to 10983 return entities of a particular kind that instead return entities of 10984 some different kind, you have found a bug, either in the front end or in 10985 the documentation. Please report these bugs as you would any other bug. 10986 10987 * Menu: 10988 10989 * Macros and Functions::Macros and functions that can be used with all trees. 10990 * Identifiers:: The names of things. 10991 * Containers:: Lists and vectors. 10992 10993 10994 File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 10995 10996 11.2.1 Trees 10997 ------------ 10998 10999 All GENERIC trees have two fields in common. First, `TREE_CHAIN' is a 11000 pointer that can be used as a singly-linked list to other trees. The 11001 other is `TREE_TYPE'. Many trees store the type of an expression or 11002 declaration in this field. 11003 11004 These are some other functions for handling trees: 11005 11006 `tree_size' 11007 Return the number of bytes a tree takes. 11008 11009 `build0' 11010 `build1' 11011 `build2' 11012 `build3' 11013 `build4' 11014 `build5' 11015 `build6' 11016 These functions build a tree and supply values to put in each 11017 parameter. The basic signature is `code, type, [operands]'. 11018 `code' is the `TREE_CODE', and `type' is a tree representing the 11019 `TREE_TYPE'. These are followed by the operands, each of which is 11020 also a tree. 11021 11022 11023 11024 File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 11025 11026 11.2.2 Identifiers 11027 ------------------ 11028 11029 An `IDENTIFIER_NODE' represents a slightly more general concept that 11030 the standard C or C++ concept of identifier. In particular, an 11031 `IDENTIFIER_NODE' may contain a `$', or other extraordinary characters. 11032 11033 There are never two distinct `IDENTIFIER_NODE's representing the same 11034 identifier. Therefore, you may use pointer equality to compare 11035 `IDENTIFIER_NODE's, rather than using a routine like `strcmp'. Use 11036 `get_identifier' to obtain the unique `IDENTIFIER_NODE' for a supplied 11037 string. 11038 11039 You can use the following macros to access identifiers: 11040 `IDENTIFIER_POINTER' 11041 The string represented by the identifier, represented as a 11042 `char*'. This string is always `NUL'-terminated, and contains no 11043 embedded `NUL' characters. 11044 11045 `IDENTIFIER_LENGTH' 11046 The length of the string returned by `IDENTIFIER_POINTER', not 11047 including the trailing `NUL'. This value of `IDENTIFIER_LENGTH 11048 (x)' is always the same as `strlen (IDENTIFIER_POINTER (x))'. 11049 11050 `IDENTIFIER_OPNAME_P' 11051 This predicate holds if the identifier represents the name of an 11052 overloaded operator. In this case, you should not depend on the 11053 contents of either the `IDENTIFIER_POINTER' or the 11054 `IDENTIFIER_LENGTH'. 11055 11056 `IDENTIFIER_TYPENAME_P' 11057 This predicate holds if the identifier represents the name of a 11058 user-defined conversion operator. In this case, the `TREE_TYPE' of 11059 the `IDENTIFIER_NODE' holds the type to which the conversion 11060 operator converts. 11061 11062 11063 11064 File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 11065 11066 11.2.3 Containers 11067 ----------------- 11068 11069 Two common container data structures can be represented directly with 11070 tree nodes. A `TREE_LIST' is a singly linked list containing two trees 11071 per node. These are the `TREE_PURPOSE' and `TREE_VALUE' of each node. 11072 (Often, the `TREE_PURPOSE' contains some kind of tag, or additional 11073 information, while the `TREE_VALUE' contains the majority of the 11074 payload. In other cases, the `TREE_PURPOSE' is simply `NULL_TREE', 11075 while in still others both the `TREE_PURPOSE' and `TREE_VALUE' are of 11076 equal stature.) Given one `TREE_LIST' node, the next node is found by 11077 following the `TREE_CHAIN'. If the `TREE_CHAIN' is `NULL_TREE', then 11078 you have reached the end of the list. 11079 11080 A `TREE_VEC' is a simple vector. The `TREE_VEC_LENGTH' is an integer 11081 (not a tree) giving the number of nodes in the vector. The nodes 11082 themselves are accessed using the `TREE_VEC_ELT' macro, which takes two 11083 arguments. The first is the `TREE_VEC' in question; the second is an 11084 integer indicating which element in the vector is desired. The 11085 elements are indexed from zero. 11086 11087 11088 File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 11089 11090 11.3 Types 11091 ========== 11092 11093 All types have corresponding tree nodes. However, you should not assume 11094 that there is exactly one tree node corresponding to each type. There 11095 are often multiple nodes corresponding to the same type. 11096 11097 For the most part, different kinds of types have different tree codes. 11098 (For example, pointer types use a `POINTER_TYPE' code while arrays use 11099 an `ARRAY_TYPE' code.) However, pointers to member functions use the 11100 `RECORD_TYPE' code. Therefore, when writing a `switch' statement that 11101 depends on the code associated with a particular type, you should take 11102 care to handle pointers to member functions under the `RECORD_TYPE' 11103 case label. 11104 11105 The following functions and macros deal with cv-qualification of types: 11106 `TYPE_MAIN_VARIANT' 11107 This macro returns the unqualified version of a type. It may be 11108 applied to an unqualified type, but it is not always the identity 11109 function in that case. 11110 11111 A few other macros and functions are usable with all types: 11112 `TYPE_SIZE' 11113 The number of bits required to represent the type, represented as 11114 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 11115 `NULL_TREE'. 11116 11117 `TYPE_ALIGN' 11118 The alignment of the type, in bits, represented as an `int'. 11119 11120 `TYPE_NAME' 11121 This macro returns a declaration (in the form of a `TYPE_DECL') for 11122 the type. (Note this macro does _not_ return an 11123 `IDENTIFIER_NODE', as you might expect, given its name!) You can 11124 look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual 11125 name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type 11126 that is not a built-in type, the result of a typedef, or a named 11127 class type. 11128 11129 `TYPE_CANONICAL' 11130 This macro returns the "canonical" type for the given type node. 11131 Canonical types are used to improve performance in the C++ and 11132 Objective-C++ front ends by allowing efficient comparison between 11133 two type nodes in `same_type_p': if the `TYPE_CANONICAL' values of 11134 the types are equal, the types are equivalent; otherwise, the types 11135 are not equivalent. The notion of equivalence for canonical types 11136 is the same as the notion of type equivalence in the language 11137 itself. For instance, 11138 11139 When `TYPE_CANONICAL' is `NULL_TREE', there is no canonical type 11140 for the given type node. In this case, comparison between this 11141 type and any other type requires the compiler to perform a deep, 11142 "structural" comparison to see if the two type nodes have the same 11143 form and properties. 11144 11145 The canonical type for a node is always the most fundamental type 11146 in the equivalence class of types. For instance, `int' is its own 11147 canonical type. A typedef `I' of `int' will have `int' as its 11148 canonical type. Similarly, `I*' and a typedef `IP' (defined to 11149 `I*') will has `int*' as their canonical type. When building a new 11150 type node, be sure to set `TYPE_CANONICAL' to the appropriate 11151 canonical type. If the new type is a compound type (built from 11152 other types), and any of those other types require structural 11153 equality, use `SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the 11154 new type also requires structural equality. Finally, if for some 11155 reason you cannot guarantee that `TYPE_CANONICAL' will point to 11156 the canonical type, use `SET_TYPE_STRUCTURAL_EQUALITY' to make 11157 sure that the new type-and any type constructed based on 11158 it-requires structural equality. If you suspect that the canonical 11159 type system is miscomparing types, pass `--param 11160 verify-canonical-types=1' to the compiler or configure with 11161 `--enable-checking' to force the compiler to verify its 11162 canonical-type comparisons against the structural comparisons; the 11163 compiler will then print any warnings if the canonical types 11164 miscompare. 11165 11166 `TYPE_STRUCTURAL_EQUALITY_P' 11167 This predicate holds when the node requires structural equality 11168 checks, e.g., when `TYPE_CANONICAL' is `NULL_TREE'. 11169 11170 `SET_TYPE_STRUCTURAL_EQUALITY' 11171 This macro states that the type node it is given requires 11172 structural equality checks, e.g., it sets `TYPE_CANONICAL' to 11173 `NULL_TREE'. 11174 11175 `same_type_p' 11176 This predicate takes two types as input, and holds if they are the 11177 same type. For example, if one type is a `typedef' for the other, 11178 or both are `typedef's for the same type. This predicate also 11179 holds if the two trees given as input are simply copies of one 11180 another; i.e., there is no difference between them at the source 11181 level, but, for whatever reason, a duplicate has been made in the 11182 representation. You should never use `==' (pointer equality) to 11183 compare types; always use `same_type_p' instead. 11184 11185 Detailed below are the various kinds of types, and the macros that can 11186 be used to access them. Although other kinds of types are used 11187 elsewhere in G++, the types described here are the only ones that you 11188 will encounter while examining the intermediate representation. 11189 11190 `VOID_TYPE' 11191 Used to represent the `void' type. 11192 11193 `INTEGER_TYPE' 11194 Used to represent the various integral types, including `char', 11195 `short', `int', `long', and `long long'. This code is not used 11196 for enumeration types, nor for the `bool' type. The 11197 `TYPE_PRECISION' is the number of bits used in the representation, 11198 represented as an `unsigned int'. (Note that in the general case 11199 this is not the same value as `TYPE_SIZE'; suppose that there were 11200 a 24-bit integer type, but that alignment requirements for the ABI 11201 required 32-bit alignment. Then, `TYPE_SIZE' would be an 11202 `INTEGER_CST' for 32, while `TYPE_PRECISION' would be 24.) The 11203 integer type is unsigned if `TYPE_UNSIGNED' holds; otherwise, it 11204 is signed. 11205 11206 The `TYPE_MIN_VALUE' is an `INTEGER_CST' for the smallest integer 11207 that may be represented by this type. Similarly, the 11208 `TYPE_MAX_VALUE' is an `INTEGER_CST' for the largest integer that 11209 may be represented by this type. 11210 11211 `REAL_TYPE' 11212 Used to represent the `float', `double', and `long double' types. 11213 The number of bits in the floating-point representation is given 11214 by `TYPE_PRECISION', as in the `INTEGER_TYPE' case. 11215 11216 `FIXED_POINT_TYPE' 11217 Used to represent the `short _Fract', `_Fract', `long _Fract', 11218 `long long _Fract', `short _Accum', `_Accum', `long _Accum', and 11219 `long long _Accum' types. The number of bits in the fixed-point 11220 representation is given by `TYPE_PRECISION', as in the 11221 `INTEGER_TYPE' case. There may be padding bits, fractional bits 11222 and integral bits. The number of fractional bits is given by 11223 `TYPE_FBIT', and the number of integral bits is given by 11224 `TYPE_IBIT'. The fixed-point type is unsigned if `TYPE_UNSIGNED' 11225 holds; otherwise, it is signed. The fixed-point type is 11226 saturating if `TYPE_SATURATING' holds; otherwise, it is not 11227 saturating. 11228 11229 `COMPLEX_TYPE' 11230 Used to represent GCC built-in `__complex__' data types. The 11231 `TREE_TYPE' is the type of the real and imaginary parts. 11232 11233 `ENUMERAL_TYPE' 11234 Used to represent an enumeration type. The `TYPE_PRECISION' gives 11235 (as an `int'), the number of bits used to represent the type. If 11236 there are no negative enumeration constants, `TYPE_UNSIGNED' will 11237 hold. The minimum and maximum enumeration constants may be 11238 obtained with `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE', respectively; 11239 each of these macros returns an `INTEGER_CST'. 11240 11241 The actual enumeration constants themselves may be obtained by 11242 looking at the `TYPE_VALUES'. This macro will return a 11243 `TREE_LIST', containing the constants. The `TREE_PURPOSE' of each 11244 node will be an `IDENTIFIER_NODE' giving the name of the constant; 11245 the `TREE_VALUE' will be an `INTEGER_CST' giving the value 11246 assigned to that constant. These constants will appear in the 11247 order in which they were declared. The `TREE_TYPE' of each of 11248 these constants will be the type of enumeration type itself. 11249 11250 `BOOLEAN_TYPE' 11251 Used to represent the `bool' type. 11252 11253 `POINTER_TYPE' 11254 Used to represent pointer types, and pointer to data member types. 11255 The `TREE_TYPE' gives the type to which this type points. 11256 11257 `REFERENCE_TYPE' 11258 Used to represent reference types. The `TREE_TYPE' gives the type 11259 to which this type refers. 11260 11261 `FUNCTION_TYPE' 11262 Used to represent the type of non-member functions and of static 11263 member functions. The `TREE_TYPE' gives the return type of the 11264 function. The `TYPE_ARG_TYPES' are a `TREE_LIST' of the argument 11265 types. The `TREE_VALUE' of each node in this list is the type of 11266 the corresponding argument; the `TREE_PURPOSE' is an expression 11267 for the default argument value, if any. If the last node in the 11268 list is `void_list_node' (a `TREE_LIST' node whose `TREE_VALUE' is 11269 the `void_type_node'), then functions of this type do not take 11270 variable arguments. Otherwise, they do take a variable number of 11271 arguments. 11272 11273 Note that in C (but not in C++) a function declared like `void f()' 11274 is an unprototyped function taking a variable number of arguments; 11275 the `TYPE_ARG_TYPES' of such a function will be `NULL'. 11276 11277 `METHOD_TYPE' 11278 Used to represent the type of a non-static member function. Like a 11279 `FUNCTION_TYPE', the return type is given by the `TREE_TYPE'. The 11280 type of `*this', i.e., the class of which functions of this type 11281 are a member, is given by the `TYPE_METHOD_BASETYPE'. The 11282 `TYPE_ARG_TYPES' is the parameter list, as for a `FUNCTION_TYPE', 11283 and includes the `this' argument. 11284 11285 `ARRAY_TYPE' 11286 Used to represent array types. The `TREE_TYPE' gives the type of 11287 the elements in the array. If the array-bound is present in the 11288 type, the `TYPE_DOMAIN' is an `INTEGER_TYPE' whose 11289 `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE' will be the lower and upper 11290 bounds of the array, respectively. The `TYPE_MIN_VALUE' will 11291 always be an `INTEGER_CST' for zero, while the `TYPE_MAX_VALUE' 11292 will be one less than the number of elements in the array, i.e., 11293 the highest value which may be used to index an element in the 11294 array. 11295 11296 `RECORD_TYPE' 11297 Used to represent `struct' and `class' types, as well as pointers 11298 to member functions and similar constructs in other languages. 11299 `TYPE_FIELDS' contains the items contained in this type, each of 11300 which can be a `FIELD_DECL', `VAR_DECL', `CONST_DECL', or 11301 `TYPE_DECL'. You may not make any assumptions about the ordering 11302 of the fields in the type or whether one or more of them overlap. 11303 11304 `UNION_TYPE' 11305 Used to represent `union' types. Similar to `RECORD_TYPE' except 11306 that all `FIELD_DECL' nodes in `TYPE_FIELD' start at bit position 11307 zero. 11308 11309 `QUAL_UNION_TYPE' 11310 Used to represent part of a variant record in Ada. Similar to 11311 `UNION_TYPE' except that each `FIELD_DECL' has a `DECL_QUALIFIER' 11312 field, which contains a boolean expression that indicates whether 11313 the field is present in the object. The type will only have one 11314 field, so each field's `DECL_QUALIFIER' is only evaluated if none 11315 of the expressions in the previous fields in `TYPE_FIELDS' are 11316 nonzero. Normally these expressions will reference a field in the 11317 outer object using a `PLACEHOLDER_EXPR'. 11318 11319 `LANG_TYPE' 11320 This node is used to represent a language-specific type. The front 11321 end must handle it. 11322 11323 `OFFSET_TYPE' 11324 This node is used to represent a pointer-to-data member. For a 11325 data member `X::m' the `TYPE_OFFSET_BASETYPE' is `X' and the 11326 `TREE_TYPE' is the type of `m'. 11327 11328 11329 There are variables whose values represent some of the basic types. 11330 These include: 11331 `void_type_node' 11332 A node for `void'. 11333 11334 `integer_type_node' 11335 A node for `int'. 11336 11337 `unsigned_type_node.' 11338 A node for `unsigned int'. 11339 11340 `char_type_node.' 11341 A node for `char'. 11342 It may sometimes be useful to compare one of these variables with a 11343 type in hand, using `same_type_p'. 11344 11345 11346 File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 11347 11348 11.4 Declarations 11349 ================= 11350 11351 This section covers the various kinds of declarations that appear in the 11352 internal representation, except for declarations of functions 11353 (represented by `FUNCTION_DECL' nodes), which are described in *note 11354 Functions::. 11355 11356 * Menu: 11357 11358 * Working with declarations:: Macros and functions that work on 11359 declarations. 11360 * Internal structure:: How declaration nodes are represented. 11361 11362 11363 File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 11364 11365 11.4.1 Working with declarations 11366 -------------------------------- 11367 11368 Some macros can be used with any kind of declaration. These include: 11369 `DECL_NAME' 11370 This macro returns an `IDENTIFIER_NODE' giving the name of the 11371 entity. 11372 11373 `TREE_TYPE' 11374 This macro returns the type of the entity declared. 11375 11376 `EXPR_FILENAME' 11377 This macro returns the name of the file in which the entity was 11378 declared, as a `char*'. For an entity declared implicitly by the 11379 compiler (like `__builtin_memcpy'), this will be the string 11380 `"<internal>"'. 11381 11382 `EXPR_LINENO' 11383 This macro returns the line number at which the entity was 11384 declared, as an `int'. 11385 11386 `DECL_ARTIFICIAL' 11387 This predicate holds if the declaration was implicitly generated 11388 by the compiler. For example, this predicate will hold of an 11389 implicitly declared member function, or of the `TYPE_DECL' 11390 implicitly generated for a class type. Recall that in C++ code 11391 like: 11392 struct S {}; 11393 is roughly equivalent to C code like: 11394 struct S {}; 11395 typedef struct S S; 11396 The implicitly generated `typedef' declaration is represented by a 11397 `TYPE_DECL' for which `DECL_ARTIFICIAL' holds. 11398 11399 11400 The various kinds of declarations include: 11401 `LABEL_DECL' 11402 These nodes are used to represent labels in function bodies. For 11403 more information, see *note Functions::. These nodes only appear 11404 in block scopes. 11405 11406 `CONST_DECL' 11407 These nodes are used to represent enumeration constants. The 11408 value of the constant is given by `DECL_INITIAL' which will be an 11409 `INTEGER_CST' with the same type as the `TREE_TYPE' of the 11410 `CONST_DECL', i.e., an `ENUMERAL_TYPE'. 11411 11412 `RESULT_DECL' 11413 These nodes represent the value returned by a function. When a 11414 value is assigned to a `RESULT_DECL', that indicates that the 11415 value should be returned, via bitwise copy, by the function. You 11416 can use `DECL_SIZE' and `DECL_ALIGN' on a `RESULT_DECL', just as 11417 with a `VAR_DECL'. 11418 11419 `TYPE_DECL' 11420 These nodes represent `typedef' declarations. The `TREE_TYPE' is 11421 the type declared to have the name given by `DECL_NAME'. In some 11422 cases, there is no associated name. 11423 11424 `VAR_DECL' 11425 These nodes represent variables with namespace or block scope, as 11426 well as static data members. The `DECL_SIZE' and `DECL_ALIGN' are 11427 analogous to `TYPE_SIZE' and `TYPE_ALIGN'. For a declaration, you 11428 should always use the `DECL_SIZE' and `DECL_ALIGN' rather than the 11429 `TYPE_SIZE' and `TYPE_ALIGN' given by the `TREE_TYPE', since 11430 special attributes may have been applied to the variable to give 11431 it a particular size and alignment. You may use the predicates 11432 `DECL_THIS_STATIC' or `DECL_THIS_EXTERN' to test whether the 11433 storage class specifiers `static' or `extern' were used to declare 11434 a variable. 11435 11436 If this variable is initialized (but does not require a 11437 constructor), the `DECL_INITIAL' will be an expression for the 11438 initializer. The initializer should be evaluated, and a bitwise 11439 copy into the variable performed. If the `DECL_INITIAL' is the 11440 `error_mark_node', there is an initializer, but it is given by an 11441 explicit statement later in the code; no bitwise copy is required. 11442 11443 GCC provides an extension that allows either automatic variables, 11444 or global variables, to be placed in particular registers. This 11445 extension is being used for a particular `VAR_DECL' if 11446 `DECL_REGISTER' holds for the `VAR_DECL', and if 11447 `DECL_ASSEMBLER_NAME' is not equal to `DECL_NAME'. In that case, 11448 `DECL_ASSEMBLER_NAME' is the name of the register into which the 11449 variable will be placed. 11450 11451 `PARM_DECL' 11452 Used to represent a parameter to a function. Treat these nodes 11453 similarly to `VAR_DECL' nodes. These nodes only appear in the 11454 `DECL_ARGUMENTS' for a `FUNCTION_DECL'. 11455 11456 The `DECL_ARG_TYPE' for a `PARM_DECL' is the type that will 11457 actually be used when a value is passed to this function. It may 11458 be a wider type than the `TREE_TYPE' of the parameter; for 11459 example, the ordinary type might be `short' while the 11460 `DECL_ARG_TYPE' is `int'. 11461 11462 `DEBUG_EXPR_DECL' 11463 Used to represent an anonymous debug-information temporary created 11464 to hold an expression as it is optimized away, so that its value 11465 can be referenced in debug bind statements. 11466 11467 `FIELD_DECL' 11468 These nodes represent non-static data members. The `DECL_SIZE' and 11469 `DECL_ALIGN' behave as for `VAR_DECL' nodes. The position of the 11470 field within the parent record is specified by a combination of 11471 three attributes. `DECL_FIELD_OFFSET' is the position, counting 11472 in bytes, of the `DECL_OFFSET_ALIGN'-bit sized word containing the 11473 bit of the field closest to the beginning of the structure. 11474 `DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 11475 field within this word; this may be nonzero even for fields that 11476 are not bit-fields, since `DECL_OFFSET_ALIGN' may be greater than 11477 the natural alignment of the field's type. 11478 11479 If `DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 11480 bit-field, `DECL_BIT_FIELD_TYPE' also contains the type that was 11481 originally specified for it, while DECL_TYPE may be a modified 11482 type with lesser precision, according to the size of the bit field. 11483 11484 `NAMESPACE_DECL' 11485 Namespaces provide a name hierarchy for other declarations. They 11486 appear in the `DECL_CONTEXT' of other `_DECL' nodes. 11487 11488 11489 11490 File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 11491 11492 11.4.2 Internal structure 11493 ------------------------- 11494 11495 `DECL' nodes are represented internally as a hierarchy of structures. 11496 11497 * Menu: 11498 11499 * Current structure hierarchy:: The current DECL node structure 11500 hierarchy. 11501 * Adding new DECL node types:: How to add a new DECL node to a 11502 frontend. 11503 11504 11505 File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 11506 11507 11.4.2.1 Current structure hierarchy 11508 .................................... 11509 11510 `struct tree_decl_minimal' 11511 This is the minimal structure to inherit from in order for common 11512 `DECL' macros to work. The fields it contains are a unique ID, 11513 source location, context, and name. 11514 11515 `struct tree_decl_common' 11516 This structure inherits from `struct tree_decl_minimal'. It 11517 contains fields that most `DECL' nodes need, such as a field to 11518 store alignment, machine mode, size, and attributes. 11519 11520 `struct tree_field_decl' 11521 This structure inherits from `struct tree_decl_common'. It is 11522 used to represent `FIELD_DECL'. 11523 11524 `struct tree_label_decl' 11525 This structure inherits from `struct tree_decl_common'. It is 11526 used to represent `LABEL_DECL'. 11527 11528 `struct tree_translation_unit_decl' 11529 This structure inherits from `struct tree_decl_common'. It is 11530 used to represent `TRANSLATION_UNIT_DECL'. 11531 11532 `struct tree_decl_with_rtl' 11533 This structure inherits from `struct tree_decl_common'. It 11534 contains a field to store the low-level RTL associated with a 11535 `DECL' node. 11536 11537 `struct tree_result_decl' 11538 This structure inherits from `struct tree_decl_with_rtl'. It is 11539 used to represent `RESULT_DECL'. 11540 11541 `struct tree_const_decl' 11542 This structure inherits from `struct tree_decl_with_rtl'. It is 11543 used to represent `CONST_DECL'. 11544 11545 `struct tree_parm_decl' 11546 This structure inherits from `struct tree_decl_with_rtl'. It is 11547 used to represent `PARM_DECL'. 11548 11549 `struct tree_decl_with_vis' 11550 This structure inherits from `struct tree_decl_with_rtl'. It 11551 contains fields necessary to store visibility information, as well 11552 as a section name and assembler name. 11553 11554 `struct tree_var_decl' 11555 This structure inherits from `struct tree_decl_with_vis'. It is 11556 used to represent `VAR_DECL'. 11557 11558 `struct tree_function_decl' 11559 This structure inherits from `struct tree_decl_with_vis'. It is 11560 used to represent `FUNCTION_DECL'. 11561 11562 11563 11564 File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 11565 11566 11.4.2.2 Adding new DECL node types 11567 ................................... 11568 11569 Adding a new `DECL' tree consists of the following steps 11570 11571 Add a new tree code for the `DECL' node 11572 For language specific `DECL' nodes, there is a `.def' file in each 11573 frontend directory where the tree code should be added. For 11574 `DECL' nodes that are part of the middle-end, the code should be 11575 added to `tree.def'. 11576 11577 Create a new structure type for the `DECL' node 11578 These structures should inherit from one of the existing 11579 structures in the language hierarchy by using that structure as 11580 the first member. 11581 11582 struct tree_foo_decl 11583 { 11584 struct tree_decl_with_vis common; 11585 } 11586 11587 Would create a structure name `tree_foo_decl' that inherits from 11588 `struct tree_decl_with_vis'. 11589 11590 For language specific `DECL' nodes, this new structure type should 11591 go in the appropriate `.h' file. For `DECL' nodes that are part 11592 of the middle-end, the structure type should go in `tree.h'. 11593 11594 Add a member to the tree structure enumerator for the node 11595 For garbage collection and dynamic checking purposes, each `DECL' 11596 node structure type is required to have a unique enumerator value 11597 specified with it. For language specific `DECL' nodes, this new 11598 enumerator value should go in the appropriate `.def' file. For 11599 `DECL' nodes that are part of the middle-end, the enumerator 11600 values are specified in `treestruct.def'. 11601 11602 Update `union tree_node' 11603 In order to make your new structure type usable, it must be added 11604 to `union tree_node'. For language specific `DECL' nodes, a new 11605 entry should be added to the appropriate `.h' file of the form 11606 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 11607 For `DECL' nodes that are part of the middle-end, the additional 11608 member goes directly into `union tree_node' in `tree.h'. 11609 11610 Update dynamic checking info 11611 In order to be able to check whether accessing a named portion of 11612 `union tree_node' is legal, and whether a certain `DECL' node 11613 contains one of the enumerated `DECL' node structures in the 11614 hierarchy, a simple lookup table is used. This lookup table needs 11615 to be kept up to date with the tree structure hierarchy, or else 11616 checking and containment macros will fail inappropriately. 11617 11618 For language specific `DECL' nodes, their is an `init_ts' function 11619 in an appropriate `.c' file, which initializes the lookup table. 11620 Code setting up the table for new `DECL' nodes should be added 11621 there. For each `DECL' tree code and enumerator value 11622 representing a member of the inheritance hierarchy, the table 11623 should contain 1 if that tree code inherits (directly or 11624 indirectly) from that member. Thus, a `FOO_DECL' node derived 11625 from `struct decl_with_rtl', and enumerator value `TS_FOO_DECL', 11626 would be set up as follows 11627 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 11628 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 11629 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 11630 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 11631 11632 For `DECL' nodes that are part of the middle-end, the setup code 11633 goes into `tree.c'. 11634 11635 Add macros to access any new fields and flags 11636 Each added field or flag should have a macro that is used to access 11637 it, that performs appropriate checking to ensure only the right 11638 type of `DECL' nodes access the field. 11639 11640 These macros generally take the following form 11641 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 11642 However, if the structure is simply a base class for further 11643 structures, something like the following should be used 11644 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 11645 #define BASE_STRUCT_FIELDNAME(NODE) \ 11646 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 11647 11648 11649 11650 File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 11651 11652 11.5 Attributes in trees 11653 ======================== 11654 11655 Attributes, as specified using the `__attribute__' keyword, are 11656 represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the 11657 name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a 11658 `TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE' 11659 if there are no arguments; the arguments are stored as the `TREE_VALUE' 11660 of successive entries in the list, and may be identifiers or 11661 expressions. The `TREE_CHAIN' of the attribute is the next attribute 11662 in a list of attributes applying to the same declaration or type, or 11663 `NULL_TREE' if there are no further attributes in the list. 11664 11665 Attributes may be attached to declarations and to types; these 11666 attributes may be accessed with the following macros. All attributes 11667 are stored in this way, and many also cause other changes to the 11668 declaration or type or to other internal compiler data structures. 11669 11670 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 11671 This macro returns the attributes on the declaration DECL. 11672 11673 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 11674 This macro returns the attributes on the type TYPE. 11675 11676 11677 File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 11678 11679 11.6 Expressions 11680 ================ 11681 11682 The internal representation for expressions is for the most part quite 11683 straightforward. However, there are a few facts that one must bear in 11684 mind. In particular, the expression "tree" is actually a directed 11685 acyclic graph. (For example there may be many references to the integer 11686 constant zero throughout the source program; many of these will be 11687 represented by the same expression node.) You should not rely on 11688 certain kinds of node being shared, nor should you rely on certain 11689 kinds of nodes being unshared. 11690 11691 The following macros can be used with all expression nodes: 11692 11693 `TREE_TYPE' 11694 Returns the type of the expression. This value may not be 11695 precisely the same type that would be given the expression in the 11696 original program. 11697 11698 In what follows, some nodes that one might expect to always have type 11699 `bool' are documented to have either integral or boolean type. At some 11700 point in the future, the C front end may also make use of this same 11701 intermediate representation, and at this point these nodes will 11702 certainly have integral type. The previous sentence is not meant to 11703 imply that the C++ front end does not or will not give these nodes 11704 integral type. 11705 11706 Below, we list the various kinds of expression nodes. Except where 11707 noted otherwise, the operands to an expression are accessed using the 11708 `TREE_OPERAND' macro. For example, to access the first operand to a 11709 binary plus expression `expr', use: 11710 11711 TREE_OPERAND (expr, 0) 11712 As this example indicates, the operands are zero-indexed. 11713 11714 * Menu: 11715 11716 * Constants: Constant expressions. 11717 * Storage References:: 11718 * Unary and Binary Expressions:: 11719 * Vectors:: 11720 11721 11722 File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 11723 11724 11.6.1 Constant expressions 11725 --------------------------- 11726 11727 The table below begins with constants, moves on to unary expressions, 11728 then proceeds to binary expressions, and concludes with various other 11729 kinds of expressions: 11730 11731 `INTEGER_CST' 11732 These nodes represent integer constants. Note that the type of 11733 these constants is obtained with `TREE_TYPE'; they are not always 11734 of type `int'. In particular, `char' constants are represented 11735 with `INTEGER_CST' nodes. The value of the integer constant `e' is 11736 given by 11737 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT) 11738 + TREE_INST_CST_LOW (e)) 11739 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms. 11740 Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a 11741 `HOST_WIDE_INT'. The value of an `INTEGER_CST' is interpreted as 11742 a signed or unsigned quantity depending on the type of the 11743 constant. In general, the expression given above will overflow, 11744 so it should not be used to calculate the value of the constant. 11745 11746 The variable `integer_zero_node' is an integer constant with value 11747 zero. Similarly, `integer_one_node' is an integer constant with 11748 value one. The `size_zero_node' and `size_one_node' variables are 11749 analogous, but have type `size_t' rather than `int'. 11750 11751 The function `tree_int_cst_lt' is a predicate which holds if its 11752 first argument is less than its second. Both constants are 11753 assumed to have the same signedness (i.e., either both should be 11754 signed or both should be unsigned.) The full width of the 11755 constant is used when doing the comparison; the usual rules about 11756 promotions and conversions are ignored. Similarly, 11757 `tree_int_cst_equal' holds if the two constants are equal. The 11758 `tree_int_cst_sgn' function returns the sign of a constant. The 11759 value is `1', `0', or `-1' according on whether the constant is 11760 greater than, equal to, or less than zero. Again, the signedness 11761 of the constant's type is taken into account; an unsigned constant 11762 is never less than zero, no matter what its bit-pattern. 11763 11764 `REAL_CST' 11765 FIXME: Talk about how to obtain representations of this constant, 11766 do comparisons, and so forth. 11767 11768 `FIXED_CST' 11769 These nodes represent fixed-point constants. The type of these 11770 constants is obtained with `TREE_TYPE'. `TREE_FIXED_CST_PTR' 11771 points to a `struct fixed_value'; `TREE_FIXED_CST' returns the 11772 structure itself. `struct fixed_value' contains `data' with the 11773 size of two `HOST_BITS_PER_WIDE_INT' and `mode' as the associated 11774 fixed-point machine mode for `data'. 11775 11776 `COMPLEX_CST' 11777 These nodes are used to represent complex number constants, that 11778 is a `__complex__' whose parts are constant nodes. The 11779 `TREE_REALPART' and `TREE_IMAGPART' return the real and the 11780 imaginary parts respectively. 11781 11782 `VECTOR_CST' 11783 These nodes are used to represent vector constants, whose parts are 11784 constant nodes. Each individual constant node is either an 11785 integer or a double constant node. The first operand is a 11786 `TREE_LIST' of the constant nodes and is accessed through 11787 `TREE_VECTOR_CST_ELTS'. 11788 11789 `STRING_CST' 11790 These nodes represent string-constants. The `TREE_STRING_LENGTH' 11791 returns the length of the string, as an `int'. The 11792 `TREE_STRING_POINTER' is a `char*' containing the string itself. 11793 The string may not be `NUL'-terminated, and it may contain 11794 embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH' 11795 includes the trailing `NUL' if it is present. 11796 11797 For wide string constants, the `TREE_STRING_LENGTH' is the number 11798 of bytes in the string, and the `TREE_STRING_POINTER' points to an 11799 array of the bytes of the string, as represented on the target 11800 system (that is, as integers in the target endianness). Wide and 11801 non-wide string constants are distinguished only by the `TREE_TYPE' 11802 of the `STRING_CST'. 11803 11804 FIXME: The formats of string constants are not well-defined when 11805 the target system bytes are not the same width as host system 11806 bytes. 11807 11808 11809 11810 File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 11811 11812 11.6.2 References to storage 11813 ---------------------------- 11814 11815 `ARRAY_REF' 11816 These nodes represent array accesses. The first operand is the 11817 array; the second is the index. To calculate the address of the 11818 memory accessed, you must scale the index by the size of the type 11819 of the array elements. The type of these expressions must be the 11820 type of a component of the array. The third and fourth operands 11821 are used after gimplification to represent the lower bound and 11822 component size but should not be used directly; call 11823 `array_ref_low_bound' and `array_ref_element_size' instead. 11824 11825 `ARRAY_RANGE_REF' 11826 These nodes represent access to a range (or "slice") of an array. 11827 The operands are the same as that for `ARRAY_REF' and have the same 11828 meanings. The type of these expressions must be an array whose 11829 component type is the same as that of the first operand. The 11830 range of that array type determines the amount of data these 11831 expressions access. 11832 11833 `TARGET_MEM_REF' 11834 These nodes represent memory accesses whose address directly map to 11835 an addressing mode of the target architecture. The first argument 11836 is `TMR_SYMBOL' and must be a `VAR_DECL' of an object with a fixed 11837 address. The second argument is `TMR_BASE' and the third one is 11838 `TMR_INDEX'. The fourth argument is `TMR_STEP' and must be an 11839 `INTEGER_CST'. The fifth argument is `TMR_OFFSET' and must be an 11840 `INTEGER_CST'. Any of the arguments may be NULL if the 11841 appropriate component does not appear in the address. Address of 11842 the `TARGET_MEM_REF' is determined in the following way. 11843 11844 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 11845 11846 The sixth argument is the reference to the original memory access, 11847 which is preserved for the purposes of the RTL alias analysis. 11848 The seventh argument is a tag representing the results of tree 11849 level alias analysis. 11850 11851 `ADDR_EXPR' 11852 These nodes are used to represent the address of an object. (These 11853 expressions will always have pointer or reference type.) The 11854 operand may be another expression, or it may be a declaration. 11855 11856 As an extension, GCC allows users to take the address of a label. 11857 In this case, the operand of the `ADDR_EXPR' will be a 11858 `LABEL_DECL'. The type of such an expression is `void*'. 11859 11860 If the object addressed is not an lvalue, a temporary is created, 11861 and the address of the temporary is used. 11862 11863 `INDIRECT_REF' 11864 These nodes are used to represent the object pointed to by a 11865 pointer. The operand is the pointer being dereferenced; it will 11866 always have pointer or reference type. 11867 11868 `MEM_REF' 11869 These nodes are used to represent the object pointed to by a 11870 pointer offset by a constant. The first operand is the pointer 11871 being dereferenced; it will always have pointer or reference type. 11872 The second operand is a pointer constant. Its type is specifying 11873 the type to be used for type-based alias analysis. 11874 11875 `COMPONENT_REF' 11876 These nodes represent non-static data member accesses. The first 11877 operand is the object (rather than a pointer to it); the second 11878 operand is the `FIELD_DECL' for the data member. The third 11879 operand represents the byte offset of the field, but should not be 11880 used directly; call `component_ref_field_offset' instead. 11881 11882 11883 11884 File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 11885 11886 11.6.3 Unary and Binary Expressions 11887 ----------------------------------- 11888 11889 `NEGATE_EXPR' 11890 These nodes represent unary negation of the single operand, for 11891 both integer and floating-point types. The type of negation can be 11892 determined by looking at the type of the expression. 11893 11894 The behavior of this operation on signed arithmetic overflow is 11895 controlled by the `flag_wrapv' and `flag_trapv' variables. 11896 11897 `ABS_EXPR' 11898 These nodes represent the absolute value of the single operand, for 11899 both integer and floating-point types. This is typically used to 11900 implement the `abs', `labs' and `llabs' builtins for integer 11901 types, and the `fabs', `fabsf' and `fabsl' builtins for floating 11902 point types. The type of abs operation can be determined by 11903 looking at the type of the expression. 11904 11905 This node is not used for complex types. To represent the modulus 11906 or complex abs of a complex value, use the `BUILT_IN_CABS', 11907 `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to 11908 implement the C99 `cabs', `cabsf' and `cabsl' built-in functions. 11909 11910 `BIT_NOT_EXPR' 11911 These nodes represent bitwise complement, and will always have 11912 integral type. The only operand is the value to be complemented. 11913 11914 `TRUTH_NOT_EXPR' 11915 These nodes represent logical negation, and will always have 11916 integral (or boolean) type. The operand is the value being 11917 negated. The type of the operand and that of the result are 11918 always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 11919 11920 `PREDECREMENT_EXPR' 11921 `PREINCREMENT_EXPR' 11922 `POSTDECREMENT_EXPR' 11923 `POSTINCREMENT_EXPR' 11924 These nodes represent increment and decrement expressions. The 11925 value of the single operand is computed, and the operand 11926 incremented or decremented. In the case of `PREDECREMENT_EXPR' and 11927 `PREINCREMENT_EXPR', the value of the expression is the value 11928 resulting after the increment or decrement; in the case of 11929 `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before 11930 the increment or decrement occurs. The type of the operand, like 11931 that of the result, will be either integral, boolean, or 11932 floating-point. 11933 11934 `FIX_TRUNC_EXPR' 11935 These nodes represent conversion of a floating-point value to an 11936 integer. The single operand will have a floating-point type, while 11937 the complete expression will have an integral (or boolean) type. 11938 The operand is rounded towards zero. 11939 11940 `FLOAT_EXPR' 11941 These nodes represent conversion of an integral (or boolean) value 11942 to a floating-point value. The single operand will have integral 11943 type, while the complete expression will have a floating-point 11944 type. 11945 11946 FIXME: How is the operand supposed to be rounded? Is this 11947 dependent on `-mieee'? 11948 11949 `COMPLEX_EXPR' 11950 These nodes are used to represent complex numbers constructed from 11951 two expressions of the same (integer or real) type. The first 11952 operand is the real part and the second operand is the imaginary 11953 part. 11954 11955 `CONJ_EXPR' 11956 These nodes represent the conjugate of their operand. 11957 11958 `REALPART_EXPR' 11959 `IMAGPART_EXPR' 11960 These nodes represent respectively the real and the imaginary parts 11961 of complex numbers (their sole argument). 11962 11963 `NON_LVALUE_EXPR' 11964 These nodes indicate that their one and only operand is not an 11965 lvalue. A back end can treat these identically to the single 11966 operand. 11967 11968 `NOP_EXPR' 11969 These nodes are used to represent conversions that do not require 11970 any code-generation. For example, conversion of a `char*' to an 11971 `int*' does not require any code be generated; such a conversion is 11972 represented by a `NOP_EXPR'. The single operand is the expression 11973 to be converted. The conversion from a pointer to a reference is 11974 also represented with a `NOP_EXPR'. 11975 11976 `CONVERT_EXPR' 11977 These nodes are similar to `NOP_EXPR's, but are used in those 11978 situations where code may need to be generated. For example, if an 11979 `int*' is converted to an `int' code may need to be generated on 11980 some platforms. These nodes are never used for C++-specific 11981 conversions, like conversions between pointers to different 11982 classes in an inheritance hierarchy. Any adjustments that need to 11983 be made in such cases are always indicated explicitly. Similarly, 11984 a user-defined conversion is never represented by a 11985 `CONVERT_EXPR'; instead, the function calls are made explicit. 11986 11987 `FIXED_CONVERT_EXPR' 11988 These nodes are used to represent conversions that involve 11989 fixed-point values. For example, from a fixed-point value to 11990 another fixed-point value, from an integer to a fixed-point value, 11991 from a fixed-point value to an integer, from a floating-point 11992 value to a fixed-point value, or from a fixed-point value to a 11993 floating-point value. 11994 11995 `LSHIFT_EXPR' 11996 `RSHIFT_EXPR' 11997 These nodes represent left and right shifts, respectively. The 11998 first operand is the value to shift; it will always be of integral 11999 type. The second operand is an expression for the number of bits 12000 by which to shift. Right shift should be treated as arithmetic, 12001 i.e., the high-order bits should be zero-filled when the 12002 expression has unsigned type and filled with the sign bit when the 12003 expression has signed type. Note that the result is undefined if 12004 the second operand is larger than or equal to the first operand's 12005 type size. Unlike most nodes, these can have a vector as first 12006 operand and a scalar as second operand. 12007 12008 `BIT_IOR_EXPR' 12009 `BIT_XOR_EXPR' 12010 `BIT_AND_EXPR' 12011 These nodes represent bitwise inclusive or, bitwise exclusive or, 12012 and bitwise and, respectively. Both operands will always have 12013 integral type. 12014 12015 `TRUTH_ANDIF_EXPR' 12016 `TRUTH_ORIF_EXPR' 12017 These nodes represent logical "and" and logical "or", respectively. 12018 These operators are not strict; i.e., the second operand is 12019 evaluated only if the value of the expression is not determined by 12020 evaluation of the first operand. The type of the operands and 12021 that of the result are always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 12022 12023 `TRUTH_AND_EXPR' 12024 `TRUTH_OR_EXPR' 12025 `TRUTH_XOR_EXPR' 12026 These nodes represent logical and, logical or, and logical 12027 exclusive or. They are strict; both arguments are always 12028 evaluated. There are no corresponding operators in C or C++, but 12029 the front end will sometimes generate these expressions anyhow, if 12030 it can tell that strictness does not matter. The type of the 12031 operands and that of the result are always of `BOOLEAN_TYPE' or 12032 `INTEGER_TYPE'. 12033 12034 `POINTER_PLUS_EXPR' 12035 This node represents pointer arithmetic. The first operand is 12036 always a pointer/reference type. The second operand is always an 12037 unsigned integer type compatible with sizetype. This is the only 12038 binary arithmetic operand that can operate on pointer types. 12039 12040 `PLUS_EXPR' 12041 `MINUS_EXPR' 12042 `MULT_EXPR' 12043 These nodes represent various binary arithmetic operations. 12044 Respectively, these operations are addition, subtraction (of the 12045 second operand from the first) and multiplication. Their operands 12046 may have either integral or floating type, but there will never be 12047 case in which one operand is of floating type and the other is of 12048 integral type. 12049 12050 The behavior of these operations on signed arithmetic overflow is 12051 controlled by the `flag_wrapv' and `flag_trapv' variables. 12052 12053 `MULT_HIGHPART_EXPR' 12054 This node represents the "high-part" of a widening multiplication. 12055 For an integral type with B bits of precision, the result is the 12056 most significant B bits of the full 2B product. 12057 12058 `RDIV_EXPR' 12059 This node represents a floating point division operation. 12060 12061 `TRUNC_DIV_EXPR' 12062 `FLOOR_DIV_EXPR' 12063 `CEIL_DIV_EXPR' 12064 `ROUND_DIV_EXPR' 12065 These nodes represent integer division operations that return an 12066 integer result. `TRUNC_DIV_EXPR' rounds towards zero, 12067 `FLOOR_DIV_EXPR' rounds towards negative infinity, `CEIL_DIV_EXPR' 12068 rounds towards positive infinity and `ROUND_DIV_EXPR' rounds to 12069 the closest integer. Integer division in C and C++ is truncating, 12070 i.e. `TRUNC_DIV_EXPR'. 12071 12072 The behavior of these operations on signed arithmetic overflow, 12073 when dividing the minimum signed integer by minus one, is 12074 controlled by the `flag_wrapv' and `flag_trapv' variables. 12075 12076 `TRUNC_MOD_EXPR' 12077 `FLOOR_MOD_EXPR' 12078 `CEIL_MOD_EXPR' 12079 `ROUND_MOD_EXPR' 12080 These nodes represent the integer remainder or modulus operation. 12081 The integer modulus of two operands `a' and `b' is defined as `a - 12082 (a/b)*b' where the division calculated using the corresponding 12083 division operator. Hence for `TRUNC_MOD_EXPR' this definition 12084 assumes division using truncation towards zero, i.e. 12085 `TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 12086 division, i.e. `TRUNC_MOD_EXPR'. 12087 12088 `EXACT_DIV_EXPR' 12089 The `EXACT_DIV_EXPR' code is used to represent integer divisions 12090 where the numerator is known to be an exact multiple of the 12091 denominator. This allows the backend to choose between the faster 12092 of `TRUNC_DIV_EXPR', `CEIL_DIV_EXPR' and `FLOOR_DIV_EXPR' for the 12093 current target. 12094 12095 `LT_EXPR' 12096 `LE_EXPR' 12097 `GT_EXPR' 12098 `GE_EXPR' 12099 `EQ_EXPR' 12100 `NE_EXPR' 12101 These nodes represent the less than, less than or equal to, greater 12102 than, greater than or equal to, equal, and not equal comparison 12103 operators. The first and second operands will either be both of 12104 integral type, both of floating type or both of vector type. The 12105 result type of these expressions will always be of integral, 12106 boolean or signed integral vector type. These operations return 12107 the result type's zero value for false, the result type's one 12108 value for true, and a vector whose elements are zero (false) or 12109 minus one (true) for vectors. 12110 12111 For floating point comparisons, if we honor IEEE NaNs and either 12112 operand is NaN, then `NE_EXPR' always returns true and the 12113 remaining operators always return false. On some targets, 12114 comparisons against an IEEE NaN, other than equality and 12115 inequality, may generate a floating point exception. 12116 12117 `ORDERED_EXPR' 12118 `UNORDERED_EXPR' 12119 These nodes represent non-trapping ordered and unordered comparison 12120 operators. These operations take two floating point operands and 12121 determine whether they are ordered or unordered relative to each 12122 other. If either operand is an IEEE NaN, their comparison is 12123 defined to be unordered, otherwise the comparison is defined to be 12124 ordered. The result type of these expressions will always be of 12125 integral or boolean type. These operations return the result 12126 type's zero value for false, and the result type's one value for 12127 true. 12128 12129 `UNLT_EXPR' 12130 `UNLE_EXPR' 12131 `UNGT_EXPR' 12132 `UNGE_EXPR' 12133 `UNEQ_EXPR' 12134 `LTGT_EXPR' 12135 These nodes represent the unordered comparison operators. These 12136 operations take two floating point operands and determine whether 12137 the operands are unordered or are less than, less than or equal to, 12138 greater than, greater than or equal to, or equal respectively. For 12139 example, `UNLT_EXPR' returns true if either operand is an IEEE NaN 12140 or the first operand is less than the second. With the possible 12141 exception of `LTGT_EXPR', all of these operations are guaranteed 12142 not to generate a floating point exception. The result type of 12143 these expressions will always be of integral or boolean type. 12144 These operations return the result type's zero value for false, 12145 and the result type's one value for true. 12146 12147 `MODIFY_EXPR' 12148 These nodes represent assignment. The left-hand side is the first 12149 operand; the right-hand side is the second operand. The left-hand 12150 side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or 12151 other lvalue. 12152 12153 These nodes are used to represent not only assignment with `=' but 12154 also compound assignments (like `+='), by reduction to `=' 12155 assignment. In other words, the representation for `i += 3' looks 12156 just like that for `i = i + 3'. 12157 12158 `INIT_EXPR' 12159 These nodes are just like `MODIFY_EXPR', but are used only when a 12160 variable is initialized, rather than assigned to subsequently. 12161 This means that we can assume that the target of the 12162 initialization is not used in computing its own value; any 12163 reference to the lhs in computing the rhs is undefined. 12164 12165 `COMPOUND_EXPR' 12166 These nodes represent comma-expressions. The first operand is an 12167 expression whose value is computed and thrown away prior to the 12168 evaluation of the second operand. The value of the entire 12169 expression is the value of the second operand. 12170 12171 `COND_EXPR' 12172 These nodes represent `?:' expressions. The first operand is of 12173 boolean or integral type. If it evaluates to a nonzero value, the 12174 second operand should be evaluated, and returned as the value of 12175 the expression. Otherwise, the third operand is evaluated, and 12176 returned as the value of the expression. 12177 12178 The second operand must have the same type as the entire 12179 expression, unless it unconditionally throws an exception or calls 12180 a noreturn function, in which case it should have void type. The 12181 same constraints apply to the third operand. This allows array 12182 bounds checks to be represented conveniently as `(i >= 0 && i < 12183 10) ? i : abort()'. 12184 12185 As a GNU extension, the C language front-ends allow the second 12186 operand of the `?:' operator may be omitted in the source. For 12187 example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x' 12188 is an expression without side-effects. In the tree 12189 representation, however, the second operand is always present, 12190 possibly protected by `SAVE_EXPR' if the first argument does cause 12191 side-effects. 12192 12193 `CALL_EXPR' 12194 These nodes are used to represent calls to functions, including 12195 non-static member functions. `CALL_EXPR's are implemented as 12196 expression nodes with a variable number of operands. Rather than 12197 using `TREE_OPERAND' to extract them, it is preferable to use the 12198 specialized accessor macros and functions that operate 12199 specifically on `CALL_EXPR' nodes. 12200 12201 `CALL_EXPR_FN' returns a pointer to the function to call; it is 12202 always an expression whose type is a `POINTER_TYPE'. 12203 12204 The number of arguments to the call is returned by 12205 `call_expr_nargs', while the arguments themselves can be accessed 12206 with the `CALL_EXPR_ARG' macro. The arguments are zero-indexed 12207 and numbered left-to-right. You can iterate over the arguments 12208 using `FOR_EACH_CALL_EXPR_ARG', as in: 12209 12210 tree call, arg; 12211 call_expr_arg_iterator iter; 12212 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 12213 /* arg is bound to successive arguments of call. */ 12214 ...; 12215 12216 For non-static member functions, there will be an operand 12217 corresponding to the `this' pointer. There will always be 12218 expressions corresponding to all of the arguments, even if the 12219 function is declared with default arguments and some arguments are 12220 not explicitly provided at the call sites. 12221 12222 `CALL_EXPR's also have a `CALL_EXPR_STATIC_CHAIN' operand that is 12223 used to implement nested functions. This operand is otherwise 12224 null. 12225 12226 `CLEANUP_POINT_EXPR' 12227 These nodes represent full-expressions. The single operand is an 12228 expression to evaluate. Any destructor calls engendered by the 12229 creation of temporaries during the evaluation of that expression 12230 should be performed immediately after the expression is evaluated. 12231 12232 `CONSTRUCTOR' 12233 These nodes represent the brace-enclosed initializers for a 12234 structure or array. The first operand is reserved for use by the 12235 back end. The second operand is a `TREE_LIST'. If the 12236 `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or 12237 `UNION_TYPE', then the `TREE_PURPOSE' of each node in the 12238 `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each 12239 node will be the expression used to initialize that field. 12240 12241 If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then 12242 the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an 12243 `INTEGER_CST' or a `RANGE_EXPR' of two `INTEGER_CST's. A single 12244 `INTEGER_CST' indicates which element of the array (indexed from 12245 zero) is being assigned to. A `RANGE_EXPR' indicates an inclusive 12246 range of elements to initialize. In both cases the `TREE_VALUE' 12247 is the corresponding initializer. It is re-evaluated for each 12248 element of a `RANGE_EXPR'. If the `TREE_PURPOSE' is `NULL_TREE', 12249 then the initializer is for the next available array element. 12250 12251 In the front end, you should not depend on the fields appearing in 12252 any particular order. However, in the middle end, fields must 12253 appear in declaration order. You should not assume that all 12254 fields will be represented. Unrepresented fields will be set to 12255 zero. 12256 12257 `COMPOUND_LITERAL_EXPR' 12258 These nodes represent ISO C99 compound literals. The 12259 `COMPOUND_LITERAL_EXPR_DECL_EXPR' is a `DECL_EXPR' containing an 12260 anonymous `VAR_DECL' for the unnamed object represented by the 12261 compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a 12262 `CONSTRUCTOR' representing the brace-enclosed list of initializers 12263 in the compound literal. That anonymous `VAR_DECL' can also be 12264 accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro. 12265 12266 `SAVE_EXPR' 12267 A `SAVE_EXPR' represents an expression (possibly involving 12268 side-effects) that is used more than once. The side-effects should 12269 occur only the first time the expression is evaluated. Subsequent 12270 uses should just reuse the computed value. The first operand to 12271 the `SAVE_EXPR' is the expression to evaluate. The side-effects 12272 should be executed where the `SAVE_EXPR' is first encountered in a 12273 depth-first preorder traversal of the expression tree. 12274 12275 `TARGET_EXPR' 12276 A `TARGET_EXPR' represents a temporary object. The first operand 12277 is a `VAR_DECL' for the temporary variable. The second operand is 12278 the initializer for the temporary. The initializer is evaluated 12279 and, if non-void, copied (bitwise) into the temporary. If the 12280 initializer is void, that means that it will perform the 12281 initialization itself. 12282 12283 Often, a `TARGET_EXPR' occurs on the right-hand side of an 12284 assignment, or as the second operand to a comma-expression which is 12285 itself the right-hand side of an assignment, etc. In this case, 12286 we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is 12287 "orphaned". For a normal `TARGET_EXPR' the temporary variable 12288 should be treated as an alias for the left-hand side of the 12289 assignment, rather than as a new temporary variable. 12290 12291 The third operand to the `TARGET_EXPR', if present, is a 12292 cleanup-expression (i.e., destructor call) for the temporary. If 12293 this expression is orphaned, then this expression must be executed 12294 when the statement containing this expression is complete. These 12295 cleanups must always be executed in the order opposite to that in 12296 which they were encountered. Note that if a temporary is created 12297 on one branch of a conditional operator (i.e., in the second or 12298 third operand to a `COND_EXPR'), the cleanup must be run only if 12299 that branch is actually executed. 12300 12301 `VA_ARG_EXPR' 12302 This node is used to implement support for the C/C++ variable 12303 argument-list mechanism. It represents expressions like `va_arg 12304 (ap, type)'. Its `TREE_TYPE' yields the tree representation for 12305 `type' and its sole argument yields the representation for `ap'. 12306 12307 12308 12309 File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 12310 12311 11.6.4 Vectors 12312 -------------- 12313 12314 `VEC_LSHIFT_EXPR' 12315 `VEC_RSHIFT_EXPR' 12316 These nodes represent whole vector left and right shifts, 12317 respectively. The first operand is the vector to shift; it will 12318 always be of vector type. The second operand is an expression for 12319 the number of bits by which to shift. Note that the result is 12320 undefined if the second operand is larger than or equal to the 12321 first operand's type size. 12322 12323 `VEC_WIDEN_MULT_HI_EXPR' 12324 `VEC_WIDEN_MULT_LO_EXPR' 12325 These nodes represent widening vector multiplication of the high 12326 and low parts of the two input vectors, respectively. Their 12327 operands are vectors that contain the same number of elements 12328 (`N') of the same integral type. The result is a vector that 12329 contains half as many elements, of an integral type whose size is 12330 twice as wide. In the case of `VEC_WIDEN_MULT_HI_EXPR' the high 12331 `N/2' elements of the two vector are multiplied to produce the 12332 vector of `N/2' products. In the case of `VEC_WIDEN_MULT_LO_EXPR' 12333 the low `N/2' elements of the two vector are multiplied to produce 12334 the vector of `N/2' products. 12335 12336 `VEC_UNPACK_HI_EXPR' 12337 `VEC_UNPACK_LO_EXPR' 12338 These nodes represent unpacking of the high and low parts of the 12339 input vector, respectively. The single operand is a vector that 12340 contains `N' elements of the same integral or floating point type. 12341 The result is a vector that contains half as many elements, of an 12342 integral or floating point type whose size is twice as wide. In 12343 the case of `VEC_UNPACK_HI_EXPR' the high `N/2' elements of the 12344 vector are extracted and widened (promoted). In the case of 12345 `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the vector are 12346 extracted and widened (promoted). 12347 12348 `VEC_UNPACK_FLOAT_HI_EXPR' 12349 `VEC_UNPACK_FLOAT_LO_EXPR' 12350 These nodes represent unpacking of the high and low parts of the 12351 input vector, where the values are converted from fixed point to 12352 floating point. The single operand is a vector that contains `N' 12353 elements of the same integral type. The result is a vector that 12354 contains half as many elements of a floating point type whose size 12355 is twice as wide. In the case of `VEC_UNPACK_HI_EXPR' the high 12356 `N/2' elements of the vector are extracted, converted and widened. 12357 In the case of `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the 12358 vector are extracted, converted and widened. 12359 12360 `VEC_PACK_TRUNC_EXPR' 12361 This node represents packing of truncated elements of the two 12362 input vectors into the output vector. Input operands are vectors 12363 that contain the same number of elements of the same integral or 12364 floating point type. The result is a vector that contains twice 12365 as many elements of an integral or floating point type whose size 12366 is half as wide. The elements of the two vectors are demoted and 12367 merged (concatenated) to form the output vector. 12368 12369 `VEC_PACK_SAT_EXPR' 12370 This node represents packing of elements of the two input vectors 12371 into the output vector using saturation. Input operands are 12372 vectors that contain the same number of elements of the same 12373 integral type. The result is a vector that contains twice as many 12374 elements of an integral type whose size is half as wide. The 12375 elements of the two vectors are demoted and merged (concatenated) 12376 to form the output vector. 12377 12378 `VEC_PACK_FIX_TRUNC_EXPR' 12379 This node represents packing of elements of the two input vectors 12380 into the output vector, where the values are converted from 12381 floating point to fixed point. Input operands are vectors that 12382 contain the same number of elements of a floating point type. The 12383 result is a vector that contains twice as many elements of an 12384 integral type whose size is half as wide. The elements of the two 12385 vectors are merged (concatenated) to form the output vector. 12386 12387 `VEC_COND_EXPR' 12388 These nodes represent `?:' expressions. The three operands must be 12389 vectors of the same size and number of elements. The second and 12390 third operands must have the same type as the entire expression. 12391 The first operand is of signed integral vector type. If an 12392 element of the first operand evaluates to a zero value, the 12393 corresponding element of the result is taken from the third 12394 operand. If it evaluates to a minus one value, it is taken from 12395 the second operand. It should never evaluate to any other value 12396 currently, but optimizations should not rely on that property. In 12397 contrast with a `COND_EXPR', all operands are always evaluated. 12398 12399 12400 File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 12401 12402 11.7 Statements 12403 =============== 12404 12405 Most statements in GIMPLE are assignment statements, represented by 12406 `GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 12407 a reference to a volatile object is converted into a `GIMPLE_ASSIGN'. 12408 12409 There are also several varieties of complex statements. 12410 12411 * Menu: 12412 12413 * Basic Statements:: 12414 * Blocks:: 12415 * Statement Sequences:: 12416 * Empty Statements:: 12417 * Jumps:: 12418 * Cleanups:: 12419 * OpenMP:: 12420 12421 12422 File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 12423 12424 11.7.1 Basic Statements 12425 ----------------------- 12426 12427 `ASM_EXPR' 12428 Used to represent an inline assembly statement. For an inline 12429 assembly statement like: 12430 asm ("mov x, y"); 12431 The `ASM_STRING' macro will return a `STRING_CST' node for `"mov 12432 x, y"'. If the original statement made use of the 12433 extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and 12434 `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the 12435 statement, represented as `STRING_CST' nodes. The 12436 extended-assembly syntax looks like: 12437 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 12438 The first string is the `ASM_STRING', containing the instruction 12439 template. The next two strings are the output and inputs, 12440 respectively; this statement has no clobbers. As this example 12441 indicates, "plain" assembly statements are merely a special case 12442 of extended assembly statements; they have no cv-qualifiers, 12443 outputs, inputs, or clobbers. All of the strings will be 12444 `NUL'-terminated, and will contain no embedded `NUL'-characters. 12445 12446 If the assembly statement is declared `volatile', or if the 12447 statement was not an extended assembly statement, and is therefore 12448 implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold 12449 of the `ASM_EXPR'. 12450 12451 `DECL_EXPR' 12452 Used to represent a local declaration. The `DECL_EXPR_DECL' macro 12453 can be used to obtain the entity declared. This declaration may 12454 be a `LABEL_DECL', indicating that the label declared is a local 12455 label. (As an extension, GCC allows the declaration of labels 12456 with scope.) In C, this declaration may be a `FUNCTION_DECL', 12457 indicating the use of the GCC nested function extension. For more 12458 information, *note Functions::. 12459 12460 `LABEL_EXPR' 12461 Used to represent a label. The `LABEL_DECL' declared by this 12462 statement can be obtained with the `LABEL_EXPR_LABEL' macro. The 12463 `IDENTIFIER_NODE' giving the name of the label can be obtained from 12464 the `LABEL_DECL' with `DECL_NAME'. 12465 12466 `GOTO_EXPR' 12467 Used to represent a `goto' statement. The `GOTO_DESTINATION' will 12468 usually be a `LABEL_DECL'. However, if the "computed goto" 12469 extension has been used, the `GOTO_DESTINATION' will be an 12470 arbitrary expression indicating the destination. This expression 12471 will always have pointer type. 12472 12473 `RETURN_EXPR' 12474 Used to represent a `return' statement. Operand 0 represents the 12475 value to return. It should either be the `RESULT_DECL' for the 12476 containing function, or a `MODIFY_EXPR' or `INIT_EXPR' setting the 12477 function's `RESULT_DECL'. It will be `NULL_TREE' if the statement 12478 was just 12479 return; 12480 12481 `LOOP_EXPR' 12482 These nodes represent "infinite" loops. The `LOOP_EXPR_BODY' 12483 represents the body of the loop. It should be executed forever, 12484 unless an `EXIT_EXPR' is encountered. 12485 12486 `EXIT_EXPR' 12487 These nodes represent conditional exits from the nearest enclosing 12488 `LOOP_EXPR'. The single operand is the condition; if it is 12489 nonzero, then the loop should be exited. An `EXIT_EXPR' will only 12490 appear within a `LOOP_EXPR'. 12491 12492 `SWITCH_STMT' 12493 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is 12494 the expression on which the switch is occurring. See the 12495 documentation for an `IF_STMT' for more information on the 12496 representation used for the condition. The `SWITCH_STMT_BODY' is 12497 the body of the switch statement. The `SWITCH_STMT_TYPE' is the 12498 original type of switch expression as given in the source, before 12499 any compiler conversions. 12500 12501 `CASE_LABEL_EXPR' 12502 Use to represent a `case' label, range of `case' labels, or a 12503 `default' label. If `CASE_LOW' is `NULL_TREE', then this is a 12504 `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then 12505 this is an ordinary `case' label. In this case, `CASE_LOW' is an 12506 expression giving the value of the label. Both `CASE_LOW' and 12507 `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the 12508 same type as the condition expression in the switch statement. 12509 12510 Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the 12511 statement is a range of case labels. Such statements originate 12512 with the extension that allows users to write things of the form: 12513 case 2 ... 5: 12514 The first value will be `CASE_LOW', while the second will be 12515 `CASE_HIGH'. 12516 12517 12518 12519 File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 12520 12521 11.7.2 Blocks 12522 ------------- 12523 12524 Block scopes and the variables they declare in GENERIC are expressed 12525 using the `BIND_EXPR' code, which in previous versions of GCC was 12526 primarily used for the C statement-expression extension. 12527 12528 Variables in a block are collected into `BIND_EXPR_VARS' in 12529 declaration order through their `TREE_CHAIN' field. Any runtime 12530 initialization is moved out of `DECL_INITIAL' and into a statement in 12531 the controlled block. When gimplifying from C or C++, this 12532 initialization replaces the `DECL_STMT'. These variables will never 12533 require cleanups. The scope of these variables is just the body 12534 12535 Variable-length arrays (VLAs) complicate this process, as their size 12536 often refers to variables initialized earlier in the block. To handle 12537 this, we currently split the block at that point, and move the VLA into 12538 a new, inner `BIND_EXPR'. This strategy may change in the future. 12539 12540 A C++ program will usually contain more `BIND_EXPR's than there are 12541 syntactic blocks in the source code, since several C++ constructs have 12542 implicit scopes associated with them. On the other hand, although the 12543 C++ front end uses pseudo-scopes to handle cleanups for objects with 12544 destructors, these don't translate into the GIMPLE form; multiple 12545 declarations at the same level use the same `BIND_EXPR'. 12546 12547 12548 File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 12549 12550 11.7.3 Statement Sequences 12551 -------------------------- 12552 12553 Multiple statements at the same nesting level are collected into a 12554 `STATEMENT_LIST'. Statement lists are modified and traversed using the 12555 interface in `tree-iterator.h'. 12556 12557 12558 File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 12559 12560 11.7.4 Empty Statements 12561 ----------------------- 12562 12563 Whenever possible, statements with no effect are discarded. But if 12564 they are nested within another construct which cannot be discarded for 12565 some reason, they are instead replaced with an empty statement, 12566 generated by `build_empty_stmt'. Initially, all empty statements were 12567 shared, after the pattern of the Java front end, but this caused a lot 12568 of trouble in practice. 12569 12570 An empty statement is represented as `(void)0'. 12571 12572 12573 File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 12574 12575 11.7.5 Jumps 12576 ------------ 12577 12578 Other jumps are expressed by either `GOTO_EXPR' or `RETURN_EXPR'. 12579 12580 The operand of a `GOTO_EXPR' must be either a label or a variable 12581 containing the address to jump to. 12582 12583 The operand of a `RETURN_EXPR' is either `NULL_TREE', `RESULT_DECL', 12584 or a `MODIFY_EXPR' which sets the return value. It would be nice to 12585 move the `MODIFY_EXPR' into a separate statement, but the special 12586 return semantics in `expand_return' make that difficult. It may still 12587 happen in the future, perhaps by moving most of that logic into 12588 `expand_assignment'. 12589 12590 12591 File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 12592 12593 11.7.6 Cleanups 12594 --------------- 12595 12596 Destructors for local C++ objects and similar dynamic cleanups are 12597 represented in GIMPLE by a `TRY_FINALLY_EXPR'. `TRY_FINALLY_EXPR' has 12598 two operands, both of which are a sequence of statements to execute. 12599 The first sequence is executed. When it completes the second sequence 12600 is executed. 12601 12602 The first sequence may complete in the following ways: 12603 12604 1. Execute the last statement in the sequence and fall off the end. 12605 12606 2. Execute a goto statement (`GOTO_EXPR') to an ordinary label 12607 outside the sequence. 12608 12609 3. Execute a return statement (`RETURN_EXPR'). 12610 12611 4. Throw an exception. This is currently not explicitly represented 12612 in GIMPLE. 12613 12614 12615 The second sequence is not executed if the first sequence completes by 12616 calling `setjmp' or `exit' or any other function that does not return. 12617 The second sequence is also not executed if the first sequence 12618 completes via a non-local goto or a computed goto (in general the 12619 compiler does not know whether such a goto statement exits the first 12620 sequence or not, so we assume that it doesn't). 12621 12622 After the second sequence is executed, if it completes normally by 12623 falling off the end, execution continues wherever the first sequence 12624 would have continued, by falling off the end, or doing a goto, etc. 12625 12626 `TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 12627 to appear on every edge out of the controlled block; this reduces the 12628 freedom to move code across these edges. Therefore, the EH lowering 12629 pass which runs before most of the optimization passes eliminates these 12630 expressions by explicitly adding the cleanup to each edge. Rethrowing 12631 the exception is represented using `RESX_EXPR'. 12632 12633 12634 File: gccint.info, Node: OpenMP, Prev: Cleanups, Up: Statements 12635 12636 11.7.7 OpenMP 12637 ------------- 12638 12639 All the statements starting with `OMP_' represent directives and 12640 clauses used by the OpenMP API `http://www.openmp.org/'. 12641 12642 `OMP_PARALLEL' 12643 Represents `#pragma omp parallel [clause1 ... clauseN]'. It has 12644 four operands: 12645 12646 Operand `OMP_PARALLEL_BODY' is valid while in GENERIC and High 12647 GIMPLE forms. It contains the body of code to be executed by all 12648 the threads. During GIMPLE lowering, this operand becomes `NULL' 12649 and the body is emitted linearly after `OMP_PARALLEL'. 12650 12651 Operand `OMP_PARALLEL_CLAUSES' is the list of clauses associated 12652 with the directive. 12653 12654 Operand `OMP_PARALLEL_FN' is created by `pass_lower_omp', it 12655 contains the `FUNCTION_DECL' for the function that will contain 12656 the body of the parallel region. 12657 12658 Operand `OMP_PARALLEL_DATA_ARG' is also created by 12659 `pass_lower_omp'. If there are shared variables to be communicated 12660 to the children threads, this operand will contain the `VAR_DECL' 12661 that contains all the shared values and variables. 12662 12663 `OMP_FOR' 12664 Represents `#pragma omp for [clause1 ... clauseN]'. It has 5 12665 operands: 12666 12667 Operand `OMP_FOR_BODY' contains the loop body. 12668 12669 Operand `OMP_FOR_CLAUSES' is the list of clauses associated with 12670 the directive. 12671 12672 Operand `OMP_FOR_INIT' is the loop initialization code of the form 12673 `VAR = N1'. 12674 12675 Operand `OMP_FOR_COND' is the loop conditional expression of the 12676 form `VAR {<,>,<=,>=} N2'. 12677 12678 Operand `OMP_FOR_INCR' is the loop index increment of the form 12679 `VAR {+=,-=} INCR'. 12680 12681 Operand `OMP_FOR_PRE_BODY' contains side-effect code from operands 12682 `OMP_FOR_INIT', `OMP_FOR_COND' and `OMP_FOR_INC'. These 12683 side-effects are part of the `OMP_FOR' block but must be evaluated 12684 before the start of loop body. 12685 12686 The loop index variable `VAR' must be a signed integer variable, 12687 which is implicitly private to each thread. Bounds `N1' and `N2' 12688 and the increment expression `INCR' are required to be loop 12689 invariant integer expressions that are evaluated without any 12690 synchronization. The evaluation order, frequency of evaluation and 12691 side-effects are unspecified by the standard. 12692 12693 `OMP_SECTIONS' 12694 Represents `#pragma omp sections [clause1 ... clauseN]'. 12695 12696 Operand `OMP_SECTIONS_BODY' contains the sections body, which in 12697 turn contains a set of `OMP_SECTION' nodes for each of the 12698 concurrent sections delimited by `#pragma omp section'. 12699 12700 Operand `OMP_SECTIONS_CLAUSES' is the list of clauses associated 12701 with the directive. 12702 12703 `OMP_SECTION' 12704 Section delimiter for `OMP_SECTIONS'. 12705 12706 `OMP_SINGLE' 12707 Represents `#pragma omp single'. 12708 12709 Operand `OMP_SINGLE_BODY' contains the body of code to be executed 12710 by a single thread. 12711 12712 Operand `OMP_SINGLE_CLAUSES' is the list of clauses associated 12713 with the directive. 12714 12715 `OMP_MASTER' 12716 Represents `#pragma omp master'. 12717 12718 Operand `OMP_MASTER_BODY' contains the body of code to be executed 12719 by the master thread. 12720 12721 `OMP_ORDERED' 12722 Represents `#pragma omp ordered'. 12723 12724 Operand `OMP_ORDERED_BODY' contains the body of code to be 12725 executed in the sequential order dictated by the loop index 12726 variable. 12727 12728 `OMP_CRITICAL' 12729 Represents `#pragma omp critical [name]'. 12730 12731 Operand `OMP_CRITICAL_BODY' is the critical section. 12732 12733 Operand `OMP_CRITICAL_NAME' is an optional identifier to label the 12734 critical section. 12735 12736 `OMP_RETURN' 12737 This does not represent any OpenMP directive, it is an artificial 12738 marker to indicate the end of the body of an OpenMP. It is used by 12739 the flow graph (`tree-cfg.c') and OpenMP region building code 12740 (`omp-low.c'). 12741 12742 `OMP_CONTINUE' 12743 Similarly, this instruction does not represent an OpenMP 12744 directive, it is used by `OMP_FOR' and `OMP_SECTIONS' to mark the 12745 place where the code needs to loop to the next iteration (in the 12746 case of `OMP_FOR') or the next section (in the case of 12747 `OMP_SECTIONS'). 12748 12749 In some cases, `OMP_CONTINUE' is placed right before `OMP_RETURN'. 12750 But if there are cleanups that need to occur right after the 12751 looping body, it will be emitted between `OMP_CONTINUE' and 12752 `OMP_RETURN'. 12753 12754 `OMP_ATOMIC' 12755 Represents `#pragma omp atomic'. 12756 12757 Operand 0 is the address at which the atomic operation is to be 12758 performed. 12759 12760 Operand 1 is the expression to evaluate. The gimplifier tries 12761 three alternative code generation strategies. Whenever possible, 12762 an atomic update built-in is used. If that fails, a 12763 compare-and-swap loop is attempted. If that also fails, a regular 12764 critical section around the expression is used. 12765 12766 `OMP_CLAUSE' 12767 Represents clauses associated with one of the `OMP_' directives. 12768 Clauses are represented by separate sub-codes defined in `tree.h'. 12769 Clauses codes can be one of: `OMP_CLAUSE_PRIVATE', 12770 `OMP_CLAUSE_SHARED', `OMP_CLAUSE_FIRSTPRIVATE', 12771 `OMP_CLAUSE_LASTPRIVATE', `OMP_CLAUSE_COPYIN', 12772 `OMP_CLAUSE_COPYPRIVATE', `OMP_CLAUSE_IF', 12773 `OMP_CLAUSE_NUM_THREADS', `OMP_CLAUSE_SCHEDULE', 12774 `OMP_CLAUSE_NOWAIT', `OMP_CLAUSE_ORDERED', `OMP_CLAUSE_DEFAULT', 12775 `OMP_CLAUSE_REDUCTION', `OMP_CLAUSE_COLLAPSE', `OMP_CLAUSE_UNTIED', 12776 `OMP_CLAUSE_FINAL', and `OMP_CLAUSE_MERGEABLE'. Each code 12777 represents the corresponding OpenMP clause. 12778 12779 Clauses associated with the same directive are chained together 12780 via `OMP_CLAUSE_CHAIN'. Those clauses that accept a list of 12781 variables are restricted to exactly one, accessed with 12782 `OMP_CLAUSE_VAR'. Therefore, multiple variables under the same 12783 clause `C' need to be represented as multiple `C' clauses chained 12784 together. This facilitates adding new clauses during compilation. 12785 12786 12787 12788 File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 12789 12790 11.8 Functions 12791 ============== 12792 12793 A function is represented by a `FUNCTION_DECL' node. It stores the 12794 basic pieces of the function such as body, parameters, and return type 12795 as well as information on the surrounding context, visibility, and 12796 linkage. 12797 12798 * Menu: 12799 12800 * Function Basics:: Function names, body, and parameters. 12801 * Function Properties:: Context, linkage, etc. 12802 12803 12804 File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 12805 12806 11.8.1 Function Basics 12807 ---------------------- 12808 12809 A function has four core parts: the name, the parameters, the result, 12810 and the body. The following macros and functions access these parts of 12811 a `FUNCTION_DECL' as well as other basic features: 12812 `DECL_NAME' 12813 This macro returns the unqualified name of the function, as an 12814 `IDENTIFIER_NODE'. For an instantiation of a function template, 12815 the `DECL_NAME' is the unqualified name of the template, not 12816 something like `f<int>'. The value of `DECL_NAME' is undefined 12817 when used on a constructor, destructor, overloaded operator, or 12818 type-conversion operator, or any function that is implicitly 12819 generated by the compiler. See below for macros that can be used 12820 to distinguish these cases. 12821 12822 `DECL_ASSEMBLER_NAME' 12823 This macro returns the mangled name of the function, also an 12824 `IDENTIFIER_NODE'. This name does not contain leading underscores 12825 on systems that prefix all identifiers with underscores. The 12826 mangled name is computed in the same way on all platforms; if 12827 special processing is required to deal with the object file format 12828 used on a particular platform, it is the responsibility of the 12829 back end to perform those modifications. (Of course, the back end 12830 should not modify `DECL_ASSEMBLER_NAME' itself.) 12831 12832 Using `DECL_ASSEMBLER_NAME' will cause additional memory to be 12833 allocated (for the mangled name of the entity) so it should be used 12834 only when emitting assembly code. It should not be used within the 12835 optimizers to determine whether or not two declarations are the 12836 same, even though some of the existing optimizers do use it in 12837 that way. These uses will be removed over time. 12838 12839 `DECL_ARGUMENTS' 12840 This macro returns the `PARM_DECL' for the first argument to the 12841 function. Subsequent `PARM_DECL' nodes can be obtained by 12842 following the `TREE_CHAIN' links. 12843 12844 `DECL_RESULT' 12845 This macro returns the `RESULT_DECL' for the function. 12846 12847 `DECL_SAVED_TREE' 12848 This macro returns the complete body of the function. 12849 12850 `TREE_TYPE' 12851 This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the 12852 function. 12853 12854 `DECL_INITIAL' 12855 A function that has a definition in the current translation unit 12856 will have a non-`NULL' `DECL_INITIAL'. However, back ends should 12857 not make use of the particular value given by `DECL_INITIAL'. 12858 12859 It should contain a tree of `BLOCK' nodes that mirrors the scopes 12860 that variables are bound in the function. Each block contains a 12861 list of decls declared in a basic block, a pointer to a chain of 12862 blocks at the next lower scope level, then a pointer to the next 12863 block at the same level and a backpointer to the parent `BLOCK' or 12864 `FUNCTION_DECL'. So given a function as follows: 12865 12866 void foo() 12867 { 12868 int a; 12869 { 12870 int b; 12871 } 12872 int c; 12873 } 12874 12875 you would get the following: 12876 12877 tree foo = FUNCTION_DECL; 12878 tree decl_a = VAR_DECL; 12879 tree decl_b = VAR_DECL; 12880 tree decl_c = VAR_DECL; 12881 tree block_a = BLOCK; 12882 tree block_b = BLOCK; 12883 tree block_c = BLOCK; 12884 BLOCK_VARS(block_a) = decl_a; 12885 BLOCK_SUBBLOCKS(block_a) = block_b; 12886 BLOCK_CHAIN(block_a) = block_c; 12887 BLOCK_SUPERCONTEXT(block_a) = foo; 12888 BLOCK_VARS(block_b) = decl_b; 12889 BLOCK_SUPERCONTEXT(block_b) = block_a; 12890 BLOCK_VARS(block_c) = decl_c; 12891 BLOCK_SUPERCONTEXT(block_c) = foo; 12892 DECL_INITIAL(foo) = block_a; 12893 12894 12895 12896 File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 12897 12898 11.8.2 Function Properties 12899 -------------------------- 12900 12901 To determine the scope of a function, you can use the `DECL_CONTEXT' 12902 macro. This macro will return the class (either a `RECORD_TYPE' or a 12903 `UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 12904 is a member. For a virtual function, this macro returns the class in 12905 which the function was actually defined, not the base class in which 12906 the virtual declaration occurred. 12907 12908 In C, the `DECL_CONTEXT' for a function maybe another function. This 12909 representation indicates that the GNU nested function extension is in 12910 use. For details on the semantics of nested functions, see the GCC 12911 Manual. The nested function can refer to local variables in its 12912 containing function. Such references are not explicitly marked in the 12913 tree structure; back ends must look at the `DECL_CONTEXT' for the 12914 referenced `VAR_DECL'. If the `DECL_CONTEXT' for the referenced 12915 `VAR_DECL' is not the same as the function currently being processed, 12916 and neither `DECL_EXTERNAL' nor `TREE_STATIC' hold, then the reference 12917 is to a local variable in a containing function, and the back end must 12918 take appropriate action. 12919 12920 `DECL_EXTERNAL' 12921 This predicate holds if the function is undefined. 12922 12923 `TREE_PUBLIC' 12924 This predicate holds if the function has external linkage. 12925 12926 `TREE_STATIC' 12927 This predicate holds if the function has been defined. 12928 12929 `TREE_THIS_VOLATILE' 12930 This predicate holds if the function does not return normally. 12931 12932 `TREE_READONLY' 12933 This predicate holds if the function can only read its arguments. 12934 12935 `DECL_PURE_P' 12936 This predicate holds if the function can only read its arguments, 12937 but may also read global memory. 12938 12939 `DECL_VIRTUAL_P' 12940 This predicate holds if the function is virtual. 12941 12942 `DECL_ARTIFICIAL' 12943 This macro holds if the function was implicitly generated by the 12944 compiler, rather than explicitly declared. In addition to 12945 implicitly generated class member functions, this macro holds for 12946 the special functions created to implement static initialization 12947 and destruction, to compute run-time type information, and so 12948 forth. 12949 12950 `DECL_FUNCTION_SPECIFIC_TARGET' 12951 This macro returns a tree node that holds the target options that 12952 are to be used to compile this particular function or `NULL_TREE' 12953 if the function is to be compiled with the target options 12954 specified on the command line. 12955 12956 `DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 12957 This macro returns a tree node that holds the optimization options 12958 that are to be used to compile this particular function or 12959 `NULL_TREE' if the function is to be compiled with the 12960 optimization options specified on the command line. 12961 12962 12963 12964 File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 12965 12966 11.9 Language-dependent trees 12967 ============================= 12968 12969 Front ends may wish to keep some state associated with various GENERIC 12970 trees while parsing. To support this, trees provide a set of flags 12971 that may be used by the front end. They are accessed using 12972 `TREE_LANG_FLAG_n' where `n' is currently 0 through 6. 12973 12974 If necessary, a front end can use some language-dependent tree codes 12975 in its GENERIC representation, so long as it provides a hook for 12976 converting them to GIMPLE and doesn't expect them to work with any 12977 (hypothetical) optimizers that run before the conversion to GIMPLE. The 12978 intermediate representation used while parsing C and C++ looks very 12979 little like GENERIC, but the C and C++ gimplifier hooks are perfectly 12980 happy to take it as input and spit out GIMPLE. 12981 12982 12983 File: gccint.info, Node: C and C++ Trees, Next: Java Trees, Prev: Language-dependent trees, Up: GENERIC 12984 12985 11.10 C and C++ Trees 12986 ===================== 12987 12988 This section documents the internal representation used by GCC to 12989 represent C and C++ source programs. When presented with a C or C++ 12990 source program, GCC parses the program, performs semantic analysis 12991 (including the generation of error messages), and then produces the 12992 internal representation described here. This representation contains a 12993 complete representation for the entire translation unit provided as 12994 input to the front end. This representation is then typically processed 12995 by a code-generator in order to produce machine code, but could also be 12996 used in the creation of source browsers, intelligent editors, automatic 12997 documentation generators, interpreters, and any other programs needing 12998 the ability to process C or C++ code. 12999 13000 This section explains the internal representation. In particular, it 13001 documents the internal representation for C and C++ source constructs, 13002 and the macros, functions, and variables that can be used to access 13003 these constructs. The C++ representation is largely a superset of the 13004 representation used in the C front end. There is only one construct 13005 used in C that does not appear in the C++ front end and that is the GNU 13006 "nested function" extension. Many of the macros documented here do not 13007 apply in C because the corresponding language constructs do not appear 13008 in C. 13009 13010 The C and C++ front ends generate a mix of GENERIC trees and ones 13011 specific to C and C++. These language-specific trees are higher-level 13012 constructs than the ones in GENERIC to make the parser's job easier. 13013 This section describes those trees that aren't part of GENERIC as well 13014 as aspects of GENERIC trees that are treated in a language-specific 13015 manner. 13016 13017 If you are developing a "back end", be it is a code-generator or some 13018 other tool, that uses this representation, you may occasionally find 13019 that you need to ask questions not easily answered by the functions and 13020 macros available here. If that situation occurs, it is quite likely 13021 that GCC already supports the functionality you desire, but that the 13022 interface is simply not documented here. In that case, you should ask 13023 the GCC maintainers (via mail to <gcc (a] gcc.gnu.org>) about documenting 13024 the functionality you require. Similarly, if you find yourself writing 13025 functions that do not deal directly with your back end, but instead 13026 might be useful to other people using the GCC front end, you should 13027 submit your patches for inclusion in GCC. 13028 13029 * Menu: 13030 13031 * Types for C++:: Fundamental and aggregate types. 13032 * Namespaces:: Namespaces. 13033 * Classes:: Classes. 13034 * Functions for C++:: Overloading and accessors for C++. 13035 * Statements for C++:: Statements specific to C and C++. 13036 * C++ Expressions:: From `typeid' to `throw'. 13037 13038 13039 File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 13040 13041 11.10.1 Types for C++ 13042 --------------------- 13043 13044 In C++, an array type is not qualified; rather the type of the array 13045 elements is qualified. This situation is reflected in the intermediate 13046 representation. The macros described here will always examine the 13047 qualification of the underlying element type when applied to an array 13048 type. (If the element type is itself an array, then the recursion 13049 continues until a non-array type is found, and the qualification of this 13050 type is examined.) So, for example, `CP_TYPE_CONST_P' will hold of the 13051 type `const int ()[7]', denoting an array of seven `int's. 13052 13053 The following functions and macros deal with cv-qualification of types: 13054 `cp_type_quals' 13055 This function returns the set of type qualifiers applied to this 13056 type. This value is `TYPE_UNQUALIFIED' if no qualifiers have been 13057 applied. The `TYPE_QUAL_CONST' bit is set if the type is 13058 `const'-qualified. The `TYPE_QUAL_VOLATILE' bit is set if the 13059 type is `volatile'-qualified. The `TYPE_QUAL_RESTRICT' bit is set 13060 if the type is `restrict'-qualified. 13061 13062 `CP_TYPE_CONST_P' 13063 This macro holds if the type is `const'-qualified. 13064 13065 `CP_TYPE_VOLATILE_P' 13066 This macro holds if the type is `volatile'-qualified. 13067 13068 `CP_TYPE_RESTRICT_P' 13069 This macro holds if the type is `restrict'-qualified. 13070 13071 `CP_TYPE_CONST_NON_VOLATILE_P' 13072 This predicate holds for a type that is `const'-qualified, but 13073 _not_ `volatile'-qualified; other cv-qualifiers are ignored as 13074 well: only the `const'-ness is tested. 13075 13076 13077 A few other macros and functions are usable with all types: 13078 `TYPE_SIZE' 13079 The number of bits required to represent the type, represented as 13080 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 13081 `NULL_TREE'. 13082 13083 `TYPE_ALIGN' 13084 The alignment of the type, in bits, represented as an `int'. 13085 13086 `TYPE_NAME' 13087 This macro returns a declaration (in the form of a `TYPE_DECL') for 13088 the type. (Note this macro does _not_ return an 13089 `IDENTIFIER_NODE', as you might expect, given its name!) You can 13090 look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual 13091 name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type 13092 that is not a built-in type, the result of a typedef, or a named 13093 class type. 13094 13095 `CP_INTEGRAL_TYPE' 13096 This predicate holds if the type is an integral type. Notice that 13097 in C++, enumerations are _not_ integral types. 13098 13099 `ARITHMETIC_TYPE_P' 13100 This predicate holds if the type is an integral type (in the C++ 13101 sense) or a floating point type. 13102 13103 `CLASS_TYPE_P' 13104 This predicate holds for a class-type. 13105 13106 `TYPE_BUILT_IN' 13107 This predicate holds for a built-in type. 13108 13109 `TYPE_PTRDATAMEM_P' 13110 This predicate holds if the type is a pointer to data member. 13111 13112 `TYPE_PTR_P' 13113 This predicate holds if the type is a pointer type, and the 13114 pointee is not a data member. 13115 13116 `TYPE_PTRFN_P' 13117 This predicate holds for a pointer to function type. 13118 13119 `TYPE_PTROB_P' 13120 This predicate holds for a pointer to object type. Note however 13121 that it does not hold for the generic pointer to object type `void 13122 *'. You may use `TYPE_PTROBV_P' to test for a pointer to object 13123 type as well as `void *'. 13124 13125 13126 The table below describes types specific to C and C++ as well as 13127 language-dependent info about GENERIC types. 13128 13129 `POINTER_TYPE' 13130 Used to represent pointer types, and pointer to data member types. 13131 If `TREE_TYPE' is a pointer to data member type, then 13132 `TYPE_PTRDATAMEM_P' will hold. For a pointer to data member type 13133 of the form `T X::*', `TYPE_PTRMEM_CLASS_TYPE' will be the type 13134 `X', while `TYPE_PTRMEM_POINTED_TO_TYPE' will be the type `T'. 13135 13136 `RECORD_TYPE' 13137 Used to represent `struct' and `class' types in C and C++. If 13138 `TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 13139 type. In that case, the `TYPE_PTRMEMFUNC_FN_TYPE' is a 13140 `POINTER_TYPE' pointing to a `METHOD_TYPE'. The `METHOD_TYPE' is 13141 the type of a function pointed to by the pointer-to-member 13142 function. If `TYPE_PTRMEMFUNC_P' does not hold, this type is a 13143 class type. For more information, *note Classes::. 13144 13145 `UNKNOWN_TYPE' 13146 This node is used to represent a type the knowledge of which is 13147 insufficient for a sound processing. 13148 13149 `TYPENAME_TYPE' 13150 Used to represent a construct of the form `typename T::A'. The 13151 `TYPE_CONTEXT' is `T'; the `TYPE_NAME' is an `IDENTIFIER_NODE' for 13152 `A'. If the type is specified via a template-id, then 13153 `TYPENAME_TYPE_FULLNAME' yields a `TEMPLATE_ID_EXPR'. The 13154 `TREE_TYPE' is non-`NULL' if the node is implicitly generated in 13155 support for the implicit typename extension; in which case the 13156 `TREE_TYPE' is a type node for the base-class. 13157 13158 `TYPEOF_TYPE' 13159 Used to represent the `__typeof__' extension. The `TYPE_FIELDS' 13160 is the expression the type of which is being represented. 13161 13162 13163 13164 File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 13165 13166 11.10.2 Namespaces 13167 ------------------ 13168 13169 The root of the entire intermediate representation is the variable 13170 `global_namespace'. This is the namespace specified with `::' in C++ 13171 source code. All other namespaces, types, variables, functions, and so 13172 forth can be found starting with this namespace. 13173 13174 However, except for the fact that it is distinguished as the root of 13175 the representation, the global namespace is no different from any other 13176 namespace. Thus, in what follows, we describe namespaces generally, 13177 rather than the global namespace in particular. 13178 13179 A namespace is represented by a `NAMESPACE_DECL' node. 13180 13181 The following macros and functions can be used on a `NAMESPACE_DECL': 13182 13183 `DECL_NAME' 13184 This macro is used to obtain the `IDENTIFIER_NODE' corresponding to 13185 the unqualified name of the name of the namespace (*note 13186 Identifiers::). The name of the global namespace is `::', even 13187 though in C++ the global namespace is unnamed. However, you 13188 should use comparison with `global_namespace', rather than 13189 `DECL_NAME' to determine whether or not a namespace is the global 13190 one. An unnamed namespace will have a `DECL_NAME' equal to 13191 `anonymous_namespace_name'. Within a single translation unit, all 13192 unnamed namespaces will have the same name. 13193 13194 `DECL_CONTEXT' 13195 This macro returns the enclosing namespace. The `DECL_CONTEXT' for 13196 the `global_namespace' is `NULL_TREE'. 13197 13198 `DECL_NAMESPACE_ALIAS' 13199 If this declaration is for a namespace alias, then 13200 `DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 13201 alias. 13202 13203 Do not attempt to use `cp_namespace_decls' for a namespace which is 13204 an alias. Instead, follow `DECL_NAMESPACE_ALIAS' links until you 13205 reach an ordinary, non-alias, namespace, and call 13206 `cp_namespace_decls' there. 13207 13208 `DECL_NAMESPACE_STD_P' 13209 This predicate holds if the namespace is the special `::std' 13210 namespace. 13211 13212 `cp_namespace_decls' 13213 This function will return the declarations contained in the 13214 namespace, including types, overloaded functions, other 13215 namespaces, and so forth. If there are no declarations, this 13216 function will return `NULL_TREE'. The declarations are connected 13217 through their `TREE_CHAIN' fields. 13218 13219 Although most entries on this list will be declarations, 13220 `TREE_LIST' nodes may also appear. In this case, the `TREE_VALUE' 13221 will be an `OVERLOAD'. The value of the `TREE_PURPOSE' is 13222 unspecified; back ends should ignore this value. As with the 13223 other kinds of declarations returned by `cp_namespace_decls', the 13224 `TREE_CHAIN' will point to the next declaration in this list. 13225 13226 For more information on the kinds of declarations that can occur 13227 on this list, *Note Declarations::. Some declarations will not 13228 appear on this list. In particular, no `FIELD_DECL', 13229 `LABEL_DECL', or `PARM_DECL' nodes will appear here. 13230 13231 This function cannot be used with namespaces that have 13232 `DECL_NAMESPACE_ALIAS' set. 13233 13234 13235 13236 File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 13237 13238 11.10.3 Classes 13239 --------------- 13240 13241 Besides namespaces, the other high-level scoping construct in C++ is the 13242 class. (Throughout this manual the term "class" is used to mean the 13243 types referred to in the ANSI/ISO C++ Standard as classes; these include 13244 types defined with the `class', `struct', and `union' keywords.) 13245 13246 A class type is represented by either a `RECORD_TYPE' or a 13247 `UNION_TYPE'. A class declared with the `union' tag is represented by 13248 a `UNION_TYPE', while classes declared with either the `struct' or the 13249 `class' tag are represented by `RECORD_TYPE's. You can use the 13250 `CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 13251 type is a `class' as opposed to a `struct'. This macro will be true 13252 only for classes declared with the `class' tag. 13253 13254 Almost all non-function members are available on the `TYPE_FIELDS' 13255 list. Given one member, the next can be found by following the 13256 `TREE_CHAIN'. You should not depend in any way on the order in which 13257 fields appear on this list. All nodes on this list will be `DECL' 13258 nodes. A `FIELD_DECL' is used to represent a non-static data member, a 13259 `VAR_DECL' is used to represent a static data member, and a `TYPE_DECL' 13260 is used to represent a type. Note that the `CONST_DECL' for an 13261 enumeration constant will appear on this list, if the enumeration type 13262 was declared in the class. (Of course, the `TYPE_DECL' for the 13263 enumeration type will appear here as well.) There are no entries for 13264 base classes on this list. In particular, there is no `FIELD_DECL' for 13265 the "base-class portion" of an object. 13266 13267 The `TYPE_VFIELD' is a compiler-generated field used to point to 13268 virtual function tables. It may or may not appear on the `TYPE_FIELDS' 13269 list. However, back ends should handle the `TYPE_VFIELD' just like all 13270 the entries on the `TYPE_FIELDS' list. 13271 13272 The function members are available on the `TYPE_METHODS' list. Again, 13273 subsequent members are found by following the `TREE_CHAIN' field. If a 13274 function is overloaded, each of the overloaded functions appears; no 13275 `OVERLOAD' nodes appear on the `TYPE_METHODS' list. Implicitly 13276 declared functions (including default constructors, copy constructors, 13277 assignment operators, and destructors) will appear on this list as well. 13278 13279 Every class has an associated "binfo", which can be obtained with 13280 `TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 13281 given by `TYPE_BINFO' is the degenerate case, whereby every class is 13282 considered to be its own base-class. The base binfos for a particular 13283 binfo are held in a vector, whose length is obtained with 13284 `BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 13285 `BINFO_BASE_BINFO' and `BINFO_BASE_ITERATE'. To add a new binfo, use 13286 `BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 13287 `BINFO_BASE_BINFOS', but normally you do not need to use that. The 13288 class type associated with a binfo is given by `BINFO_TYPE'. It is not 13289 always the case that `BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 13290 and qualified types. Neither is it the case that `TYPE_BINFO 13291 (BINFO_TYPE (y))' is the same binfo as `y'. The reason is that if `y' 13292 is a binfo representing a base-class `B' of a derived class `D', then 13293 `BINFO_TYPE (y)' will be `B', and `TYPE_BINFO (BINFO_TYPE (y))' will be 13294 `B' as its own base-class, rather than as a base-class of `D'. 13295 13296 The access to a base type can be found with `BINFO_BASE_ACCESS'. This 13297 will produce `access_public_node', `access_private_node' or 13298 `access_protected_node'. If bases are always public, 13299 `BINFO_BASE_ACCESSES' may be `NULL'. 13300 13301 `BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 13302 virtually or not. The other flags, `BINFO_MARKED_P' and `BINFO_FLAG_1' 13303 to `BINFO_FLAG_6' can be used for language specific use. 13304 13305 The following macros can be used on a tree node representing a 13306 class-type. 13307 13308 `LOCAL_CLASS_P' 13309 This predicate holds if the class is local class _i.e._ declared 13310 inside a function body. 13311 13312 `TYPE_POLYMORPHIC_P' 13313 This predicate holds if the class has at least one virtual function 13314 (declared or inherited). 13315 13316 `TYPE_HAS_DEFAULT_CONSTRUCTOR' 13317 This predicate holds whenever its argument represents a class-type 13318 with default constructor. 13319 13320 `CLASSTYPE_HAS_MUTABLE' 13321 `TYPE_HAS_MUTABLE_P' 13322 These predicates hold for a class-type having a mutable data 13323 member. 13324 13325 `CLASSTYPE_NON_POD_P' 13326 This predicate holds only for class-types that are not PODs. 13327 13328 `TYPE_HAS_NEW_OPERATOR' 13329 This predicate holds for a class-type that defines `operator new'. 13330 13331 `TYPE_HAS_ARRAY_NEW_OPERATOR' 13332 This predicate holds for a class-type for which `operator new[]' 13333 is defined. 13334 13335 `TYPE_OVERLOADS_CALL_EXPR' 13336 This predicate holds for class-type for which the function call 13337 `operator()' is overloaded. 13338 13339 `TYPE_OVERLOADS_ARRAY_REF' 13340 This predicate holds for a class-type that overloads `operator[]' 13341 13342 `TYPE_OVERLOADS_ARROW' 13343 This predicate holds for a class-type for which `operator->' is 13344 overloaded. 13345 13346 13347 13348 File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees 13349 13350 11.10.4 Functions for C++ 13351 ------------------------- 13352 13353 A function is represented by a `FUNCTION_DECL' node. A set of 13354 overloaded functions is sometimes represented by an `OVERLOAD' node. 13355 13356 An `OVERLOAD' node is not a declaration, so none of the `DECL_' macros 13357 should be used on an `OVERLOAD'. An `OVERLOAD' node is similar to a 13358 `TREE_LIST'. Use `OVL_CURRENT' to get the function associated with an 13359 `OVERLOAD' node; use `OVL_NEXT' to get the next `OVERLOAD' node in the 13360 list of overloaded functions. The macros `OVL_CURRENT' and `OVL_NEXT' 13361 are actually polymorphic; you can use them to work with `FUNCTION_DECL' 13362 nodes as well as with overloads. In the case of a `FUNCTION_DECL', 13363 `OVL_CURRENT' will always return the function itself, and `OVL_NEXT' 13364 will always be `NULL_TREE'. 13365 13366 To determine the scope of a function, you can use the `DECL_CONTEXT' 13367 macro. This macro will return the class (either a `RECORD_TYPE' or a 13368 `UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 13369 is a member. For a virtual function, this macro returns the class in 13370 which the function was actually defined, not the base class in which 13371 the virtual declaration occurred. 13372 13373 If a friend function is defined in a class scope, the 13374 `DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 13375 it was defined. For example, in 13376 class C { friend void f() {} }; 13377 the `DECL_CONTEXT' for `f' will be the `global_namespace', but the 13378 `DECL_FRIEND_CONTEXT' will be the `RECORD_TYPE' for `C'. 13379 13380 The following macros and functions can be used on a `FUNCTION_DECL': 13381 `DECL_MAIN_P' 13382 This predicate holds for a function that is the program entry point 13383 `::code'. 13384 13385 `DECL_LOCAL_FUNCTION_P' 13386 This predicate holds if the function was declared at block scope, 13387 even though it has a global scope. 13388 13389 `DECL_ANTICIPATED' 13390 This predicate holds if the function is a built-in function but its 13391 prototype is not yet explicitly declared. 13392 13393 `DECL_EXTERN_C_FUNCTION_P' 13394 This predicate holds if the function is declared as an ``extern 13395 "C"'' function. 13396 13397 `DECL_LINKONCE_P' 13398 This macro holds if multiple copies of this function may be 13399 emitted in various translation units. It is the responsibility of 13400 the linker to merge the various copies. Template instantiations 13401 are the most common example of functions for which 13402 `DECL_LINKONCE_P' holds; G++ instantiates needed templates in all 13403 translation units which require them, and then relies on the 13404 linker to remove duplicate instantiations. 13405 13406 FIXME: This macro is not yet implemented. 13407 13408 `DECL_FUNCTION_MEMBER_P' 13409 This macro holds if the function is a member of a class, rather 13410 than a member of a namespace. 13411 13412 `DECL_STATIC_FUNCTION_P' 13413 This predicate holds if the function a static member function. 13414 13415 `DECL_NONSTATIC_MEMBER_FUNCTION_P' 13416 This macro holds for a non-static member function. 13417 13418 `DECL_CONST_MEMFUNC_P' 13419 This predicate holds for a `const'-member function. 13420 13421 `DECL_VOLATILE_MEMFUNC_P' 13422 This predicate holds for a `volatile'-member function. 13423 13424 `DECL_CONSTRUCTOR_P' 13425 This macro holds if the function is a constructor. 13426 13427 `DECL_NONCONVERTING_P' 13428 This predicate holds if the constructor is a non-converting 13429 constructor. 13430 13431 `DECL_COMPLETE_CONSTRUCTOR_P' 13432 This predicate holds for a function which is a constructor for an 13433 object of a complete type. 13434 13435 `DECL_BASE_CONSTRUCTOR_P' 13436 This predicate holds for a function which is a constructor for a 13437 base class sub-object. 13438 13439 `DECL_COPY_CONSTRUCTOR_P' 13440 This predicate holds for a function which is a copy-constructor. 13441 13442 `DECL_DESTRUCTOR_P' 13443 This macro holds if the function is a destructor. 13444 13445 `DECL_COMPLETE_DESTRUCTOR_P' 13446 This predicate holds if the function is the destructor for an 13447 object a complete type. 13448 13449 `DECL_OVERLOADED_OPERATOR_P' 13450 This macro holds if the function is an overloaded operator. 13451 13452 `DECL_CONV_FN_P' 13453 This macro holds if the function is a type-conversion operator. 13454 13455 `DECL_GLOBAL_CTOR_P' 13456 This predicate holds if the function is a file-scope initialization 13457 function. 13458 13459 `DECL_GLOBAL_DTOR_P' 13460 This predicate holds if the function is a file-scope finalization 13461 function. 13462 13463 `DECL_THUNK_P' 13464 This predicate holds if the function is a thunk. 13465 13466 These functions represent stub code that adjusts the `this' pointer 13467 and then jumps to another function. When the jumped-to function 13468 returns, control is transferred directly to the caller, without 13469 returning to the thunk. The first parameter to the thunk is 13470 always the `this' pointer; the thunk should add `THUNK_DELTA' to 13471 this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.) 13472 13473 Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the 13474 adjusted `this' pointer must be adjusted again. The complete 13475 calculation is given by the following pseudo-code: 13476 13477 this += THUNK_DELTA 13478 if (THUNK_VCALL_OFFSET) 13479 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 13480 13481 Finally, the thunk should jump to the location given by 13482 `DECL_INITIAL'; this will always be an expression for the address 13483 of a function. 13484 13485 `DECL_NON_THUNK_FUNCTION_P' 13486 This predicate holds if the function is _not_ a thunk function. 13487 13488 `GLOBAL_INIT_PRIORITY' 13489 If either `DECL_GLOBAL_CTOR_P' or `DECL_GLOBAL_DTOR_P' holds, then 13490 this gives the initialization priority for the function. The 13491 linker will arrange that all functions for which 13492 `DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 13493 before `main' is called. When the program exits, all functions for 13494 which `DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 13495 13496 `TYPE_RAISES_EXCEPTIONS' 13497 This macro returns the list of exceptions that a (member-)function 13498 can raise. The returned list, if non `NULL', is comprised of nodes 13499 whose `TREE_VALUE' represents a type. 13500 13501 `TYPE_NOTHROW_P' 13502 This predicate holds when the exception-specification of its 13503 arguments is of the form ``()''. 13504 13505 `DECL_ARRAY_DELETE_OPERATOR_P' 13506 This predicate holds if the function an overloaded `operator 13507 delete[]'. 13508 13509 13510 13511 File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 13512 13513 11.10.5 Statements for C++ 13514 -------------------------- 13515 13516 A function that has a definition in the current translation unit will 13517 have a non-`NULL' `DECL_INITIAL'. However, back ends should not make 13518 use of the particular value given by `DECL_INITIAL'. 13519 13520 The `DECL_SAVED_TREE' macro will give the complete body of the 13521 function. 13522 13523 11.10.5.1 Statements 13524 .................... 13525 13526 There are tree nodes corresponding to all of the source-level statement 13527 constructs, used within the C and C++ frontends. These are enumerated 13528 here, together with a list of the various macros that can be used to 13529 obtain information about them. There are a few macros that can be used 13530 with all statements: 13531 13532 `STMT_IS_FULL_EXPR_P' 13533 In C++, statements normally constitute "full expressions"; 13534 temporaries created during a statement are destroyed when the 13535 statement is complete. However, G++ sometimes represents 13536 expressions by statements; these statements will not have 13537 `STMT_IS_FULL_EXPR_P' set. Temporaries created during such 13538 statements should be destroyed when the innermost enclosing 13539 statement with `STMT_IS_FULL_EXPR_P' set is exited. 13540 13541 13542 Here is the list of the various statement nodes, and the macros used to 13543 access them. This documentation describes the use of these nodes in 13544 non-template functions (including instantiations of template functions). 13545 In template functions, the same nodes are used, but sometimes in 13546 slightly different ways. 13547 13548 Many of the statements have substatements. For example, a `while' 13549 loop will have a body, which is itself a statement. If the substatement 13550 is `NULL_TREE', it is considered equivalent to a statement consisting 13551 of a single `;', i.e., an expression statement in which the expression 13552 has been omitted. A substatement may in fact be a list of statements, 13553 connected via their `TREE_CHAIN's. So, you should always process the 13554 statement tree by looping over substatements, like this: 13555 void process_stmt (stmt) 13556 tree stmt; 13557 { 13558 while (stmt) 13559 { 13560 switch (TREE_CODE (stmt)) 13561 { 13562 case IF_STMT: 13563 process_stmt (THEN_CLAUSE (stmt)); 13564 /* More processing here. */ 13565 break; 13566 13567 ... 13568 } 13569 13570 stmt = TREE_CHAIN (stmt); 13571 } 13572 } 13573 In other words, while the `then' clause of an `if' statement in C++ 13574 can be only one statement (although that one statement may be a 13575 compound statement), the intermediate representation will sometimes use 13576 several statements chained together. 13577 13578 `BREAK_STMT' 13579 Used to represent a `break' statement. There are no additional 13580 fields. 13581 13582 `CLEANUP_STMT' 13583 Used to represent an action that should take place upon exit from 13584 the enclosing scope. Typically, these actions are calls to 13585 destructors for local objects, but back ends cannot rely on this 13586 fact. If these nodes are in fact representing such destructors, 13587 `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise, 13588 `CLEANUP_DECL' will be `NULL_TREE'. In any case, the 13589 `CLEANUP_EXPR' is the expression to execute. The cleanups 13590 executed on exit from a scope should be run in the reverse order 13591 of the order in which the associated `CLEANUP_STMT's were 13592 encountered. 13593 13594 `CONTINUE_STMT' 13595 Used to represent a `continue' statement. There are no additional 13596 fields. 13597 13598 `CTOR_STMT' 13599 Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if 13600 `CTOR_END_P' holds of the main body of a constructor. See also 13601 `SUBOBJECT' for more information on how to use these nodes. 13602 13603 `DO_STMT' 13604 Used to represent a `do' loop. The body of the loop is given by 13605 `DO_BODY' while the termination condition for the loop is given by 13606 `DO_COND'. The condition for a `do'-statement is always an 13607 expression. 13608 13609 `EMPTY_CLASS_EXPR' 13610 Used to represent a temporary object of a class with no data whose 13611 address is never taken. (All such objects are interchangeable.) 13612 The `TREE_TYPE' represents the type of the object. 13613 13614 `EXPR_STMT' 13615 Used to represent an expression statement. Use `EXPR_STMT_EXPR' to 13616 obtain the expression. 13617 13618 `FOR_STMT' 13619 Used to represent a `for' statement. The `FOR_INIT_STMT' is the 13620 initialization statement for the loop. The `FOR_COND' is the 13621 termination condition. The `FOR_EXPR' is the expression executed 13622 right before the `FOR_COND' on each loop iteration; often, this 13623 expression increments a counter. The body of the loop is given by 13624 `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return 13625 statements, while `FOR_COND' and `FOR_EXPR' return expressions. 13626 13627 `HANDLER' 13628 Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the 13629 type of exception that will be caught by this handler; it is equal 13630 (by pointer equality) to `NULL' if this handler is for all types. 13631 `HANDLER_PARMS' is the `DECL_STMT' for the catch parameter, and 13632 `HANDLER_BODY' is the code for the block itself. 13633 13634 `IF_STMT' 13635 Used to represent an `if' statement. The `IF_COND' is the 13636 expression. 13637 13638 If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a 13639 statement (usually a `DECL_STMT'). Each time the condition is 13640 evaluated, the statement should be executed. Then, the 13641 `TREE_VALUE' should be used as the conditional expression itself. 13642 This representation is used to handle C++ code like this: 13643 13644 C++ distinguishes between this and `COND_EXPR' for handling 13645 templates. 13646 13647 if (int i = 7) ... 13648 13649 where there is a new local variable (or variables) declared within 13650 the condition. 13651 13652 The `THEN_CLAUSE' represents the statement given by the `then' 13653 condition, while the `ELSE_CLAUSE' represents the statement given 13654 by the `else' condition. 13655 13656 `SUBOBJECT' 13657 In a constructor, these nodes are used to mark the point at which a 13658 subobject of `this' is fully constructed. If, after this point, an 13659 exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is 13660 encountered, the `SUBOBJECT_CLEANUP' must be executed. The 13661 cleanups must be executed in the reverse order in which they 13662 appear. 13663 13664 `SWITCH_STMT' 13665 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is 13666 the expression on which the switch is occurring. See the 13667 documentation for an `IF_STMT' for more information on the 13668 representation used for the condition. The `SWITCH_STMT_BODY' is 13669 the body of the switch statement. The `SWITCH_STMT_TYPE' is the 13670 original type of switch expression as given in the source, before 13671 any compiler conversions. 13672 13673 `TRY_BLOCK' 13674 Used to represent a `try' block. The body of the try block is 13675 given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER' 13676 node. The first handler is given by `TRY_HANDLERS'. Subsequent 13677 handlers are obtained by following the `TREE_CHAIN' link from one 13678 handler to the next. The body of the handler is given by 13679 `HANDLER_BODY'. 13680 13681 If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS' 13682 will not be a `HANDLER' node. Instead, it will be an expression 13683 that should be executed if an exception is thrown in the try 13684 block. It must rethrow the exception after executing that code. 13685 And, if an exception is thrown while the expression is executing, 13686 `terminate' must be called. 13687 13688 `USING_STMT' 13689 Used to represent a `using' directive. The namespace is given by 13690 `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 13691 is needed inside template functions, to implement using directives 13692 during instantiation. 13693 13694 `WHILE_STMT' 13695 Used to represent a `while' loop. The `WHILE_COND' is the 13696 termination condition for the loop. See the documentation for an 13697 `IF_STMT' for more information on the representation used for the 13698 condition. 13699 13700 The `WHILE_BODY' is the body of the loop. 13701 13702 13703 13704 File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees 13705 13706 11.10.6 C++ Expressions 13707 ----------------------- 13708 13709 This section describes expressions specific to the C and C++ front ends. 13710 13711 `TYPEID_EXPR' 13712 Used to represent a `typeid' expression. 13713 13714 `NEW_EXPR' 13715 `VEC_NEW_EXPR' 13716 Used to represent a call to `new' and `new[]' respectively. 13717 13718 `DELETE_EXPR' 13719 `VEC_DELETE_EXPR' 13720 Used to represent a call to `delete' and `delete[]' respectively. 13721 13722 `MEMBER_REF' 13723 Represents a reference to a member of a class. 13724 13725 `THROW_EXPR' 13726 Represents an instance of `throw' in the program. Operand 0, 13727 which is the expression to throw, may be `NULL_TREE'. 13728 13729 `AGGR_INIT_EXPR' 13730 An `AGGR_INIT_EXPR' represents the initialization as the return 13731 value of a function call, or as the result of a constructor. An 13732 `AGGR_INIT_EXPR' will only appear as a full-expression, or as the 13733 second operand of a `TARGET_EXPR'. `AGGR_INIT_EXPR's have a 13734 representation similar to that of `CALL_EXPR's. You can use the 13735 `AGGR_INIT_EXPR_FN' and `AGGR_INIT_EXPR_ARG' macros to access the 13736 function to call and the arguments to pass. 13737 13738 If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the 13739 initialization is via a constructor call. The address of the 13740 `AGGR_INIT_EXPR_SLOT' operand, which is always a `VAR_DECL', is 13741 taken, and this value replaces the first argument in the argument 13742 list. 13743 13744 In either case, the expression is void. 13745 13746 13747 13748 File: gccint.info, Node: Java Trees, Prev: C and C++ Trees, Up: GENERIC 13749 13750 11.11 Java Trees 13751 ================ 13752 13753 13754 File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 13755 13756 12 GIMPLE 13757 ********* 13758 13759 GIMPLE is a three-address representation derived from GENERIC by 13760 breaking down GENERIC expressions into tuples of no more than 3 13761 operands (with some exceptions like function calls). GIMPLE was 13762 heavily influenced by the SIMPLE IL used by the McCAT compiler project 13763 at McGill University, though we have made some different choices. For 13764 one thing, SIMPLE doesn't support `goto'. 13765 13766 Temporaries are introduced to hold intermediate values needed to 13767 compute complex expressions. Additionally, all the control structures 13768 used in GENERIC are lowered into conditional jumps, lexical scopes are 13769 removed and exception regions are converted into an on the side 13770 exception region tree. 13771 13772 The compiler pass which converts GENERIC into GIMPLE is referred to as 13773 the `gimplifier'. The gimplifier works recursively, generating GIMPLE 13774 tuples out of the original GENERIC expressions. 13775 13776 One of the early implementation strategies used for the GIMPLE 13777 representation was to use the same internal data structures used by 13778 front ends to represent parse trees. This simplified implementation 13779 because we could leverage existing functionality and interfaces. 13780 However, GIMPLE is a much more restrictive representation than abstract 13781 syntax trees (AST), therefore it does not require the full structural 13782 complexity provided by the main tree data structure. 13783 13784 The GENERIC representation of a function is stored in the 13785 `DECL_SAVED_TREE' field of the associated `FUNCTION_DECL' tree node. 13786 It is converted to GIMPLE by a call to `gimplify_function_tree'. 13787 13788 If a front end wants to include language-specific tree codes in the 13789 tree representation which it provides to the back end, it must provide a 13790 definition of `LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 13791 front end trees to GIMPLE. Usually such a hook will involve much of 13792 the same code for expanding front end trees to RTL. This function can 13793 return fully lowered GIMPLE, or it can return GENERIC trees and let the 13794 main gimplifier lower them the rest of the way; this is often simpler. 13795 GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 13796 of the IL before the pass `pass_lower_cf'. High GIMPLE contains some 13797 container statements like lexical scopes (represented by `GIMPLE_BIND') 13798 and nested expressions (e.g., `GIMPLE_TRY'), while "Low GIMPLE" exposes 13799 all of the implicit jumps for control and exception expressions 13800 directly in the IL and EH region trees. 13801 13802 The C and C++ front ends currently convert directly from front end 13803 trees to GIMPLE, and hand that off to the back end rather than first 13804 converting to GENERIC. Their gimplifier hooks know about all the 13805 `_STMT' nodes and how to convert them to GENERIC forms. There was some 13806 work done on a genericization pass which would run first, but the 13807 existence of `STMT_EXPR' meant that in order to convert all of the C 13808 statements into GENERIC equivalents would involve walking the entire 13809 tree anyway, so it was simpler to lower all the way. This might change 13810 in the future if someone writes an optimization pass which would work 13811 better with higher-level trees, but currently the optimizers all expect 13812 GIMPLE. 13813 13814 You can request to dump a C-like representation of the GIMPLE form 13815 with the flag `-fdump-tree-gimple'. 13816 13817 * Menu: 13818 13819 * Tuple representation:: 13820 * GIMPLE instruction set:: 13821 * GIMPLE Exception Handling:: 13822 * Temporaries:: 13823 * Operands:: 13824 * Manipulating GIMPLE statements:: 13825 * Tuple specific accessors:: 13826 * GIMPLE sequences:: 13827 * Sequence iterators:: 13828 * Adding a new GIMPLE statement code:: 13829 * Statement and operand traversals:: 13830 13831 13832 File: gccint.info, Node: Tuple representation, Next: GIMPLE instruction set, Up: GIMPLE 13833 13834 12.1 Tuple representation 13835 ========================= 13836 13837 GIMPLE instructions are tuples of variable size divided in two groups: 13838 a header describing the instruction and its locations, and a variable 13839 length body with all the operands. Tuples are organized into a 13840 hierarchy with 3 main classes of tuples. 13841 13842 12.1.1 `gimple_statement_base' (gsbase) 13843 --------------------------------------- 13844 13845 This is the root of the hierarchy, it holds basic information needed by 13846 most GIMPLE statements. There are some fields that may not be relevant 13847 to every GIMPLE statement, but those were moved into the base structure 13848 to take advantage of holes left by other fields (thus making the 13849 structure more compact). The structure takes 4 words (32 bytes) on 64 13850 bit hosts: 13851 13852 Field Size (bits) 13853 `code' 8 13854 `subcode' 16 13855 `no_warning' 1 13856 `visited' 1 13857 `nontemporal_move' 1 13858 `plf' 2 13859 `modified' 1 13860 `has_volatile_ops' 1 13861 `references_memory_p' 1 13862 `uid' 32 13863 `location' 32 13864 `num_ops' 32 13865 `bb' 64 13866 `block' 63 13867 Total size 32 bytes 13868 13869 * `code' Main identifier for a GIMPLE instruction. 13870 13871 * `subcode' Used to distinguish different variants of the same basic 13872 instruction or provide flags applicable to a given code. The 13873 `subcode' flags field has different uses depending on the code of 13874 the instruction, but mostly it distinguishes instructions of the 13875 same family. The most prominent use of this field is in 13876 assignments, where subcode indicates the operation done on the RHS 13877 of the assignment. For example, a = b + c is encoded as 13878 `GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 13879 13880 * `no_warning' Bitflag to indicate whether a warning has already 13881 been issued on this statement. 13882 13883 * `visited' General purpose "visited" marker. Set and cleared by 13884 each pass when needed. 13885 13886 * `nontemporal_move' Bitflag used in assignments that represent 13887 non-temporal moves. Although this bitflag is only used in 13888 assignments, it was moved into the base to take advantage of the 13889 bit holes left by the previous fields. 13890 13891 * `plf' Pass Local Flags. This 2-bit mask can be used as general 13892 purpose markers by any pass. Passes are responsible for clearing 13893 and setting these two flags accordingly. 13894 13895 * `modified' Bitflag to indicate whether the statement has been 13896 modified. Used mainly by the operand scanner to determine when to 13897 re-scan a statement for operands. 13898 13899 * `has_volatile_ops' Bitflag to indicate whether this statement 13900 contains operands that have been marked volatile. 13901 13902 * `references_memory_p' Bitflag to indicate whether this statement 13903 contains memory references (i.e., its operands are either global 13904 variables, or pointer dereferences or anything that must reside in 13905 memory). 13906 13907 * `uid' This is an unsigned integer used by passes that want to 13908 assign IDs to every statement. These IDs must be assigned and used 13909 by each pass. 13910 13911 * `location' This is a `location_t' identifier to specify source code 13912 location for this statement. It is inherited from the front end. 13913 13914 * `num_ops' Number of operands that this statement has. This 13915 specifies the size of the operand vector embedded in the tuple. 13916 Only used in some tuples, but it is declared in the base tuple to 13917 take advantage of the 32-bit hole left by the previous fields. 13918 13919 * `bb' Basic block holding the instruction. 13920 13921 * `block' Lexical block holding this statement. Also used for debug 13922 information generation. 13923 13924 12.1.2 `gimple_statement_with_ops' 13925 ---------------------------------- 13926 13927 This tuple is actually split in two: `gimple_statement_with_ops_base' 13928 and `gimple_statement_with_ops'. This is needed to accommodate the way 13929 the operand vector is allocated. The operand vector is defined to be an 13930 array of 1 element. So, to allocate a dynamic number of operands, the 13931 memory allocator (`gimple_alloc') simply allocates enough memory to 13932 hold the structure itself plus `N - 1' operands which run "off the end" 13933 of the structure. For example, to allocate space for a tuple with 3 13934 operands, `gimple_alloc' reserves `sizeof (struct 13935 gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 13936 13937 On the other hand, several fields in this tuple need to be shared with 13938 the `gimple_statement_with_memory_ops' tuple. So, these common fields 13939 are placed in `gimple_statement_with_ops_base' which is then inherited 13940 from the other two tuples. 13941 13942 `gsbase' 256 13943 `def_ops' 64 13944 `use_ops' 64 13945 `op' `num_ops' * 64 13946 Total size 48 + 8 * `num_ops' bytes 13947 13948 * `gsbase' Inherited from `struct gimple_statement_base'. 13949 13950 * `def_ops' Array of pointers into the operand array indicating all 13951 the slots that contain a variable written-to by the statement. 13952 This array is also used for immediate use chaining. Note that it 13953 would be possible to not rely on this array, but the changes 13954 required to implement this are pretty invasive. 13955 13956 * `use_ops' Similar to `def_ops' but for variables read by the 13957 statement. 13958 13959 * `op' Array of trees with `num_ops' slots. 13960 13961 12.1.3 `gimple_statement_with_memory_ops' 13962 ----------------------------------------- 13963 13964 This tuple is essentially identical to `gimple_statement_with_ops', 13965 except that it contains 4 additional fields to hold vectors related 13966 memory stores and loads. Similar to the previous case, the structure 13967 is split in two to accommodate for the operand vector 13968 (`gimple_statement_with_memory_ops_base' and 13969 `gimple_statement_with_memory_ops'). 13970 13971 Field Size (bits) 13972 `gsbase' 256 13973 `def_ops' 64 13974 `use_ops' 64 13975 `vdef_ops' 64 13976 `vuse_ops' 64 13977 `stores' 64 13978 `loads' 64 13979 `op' `num_ops' * 64 13980 Total size 80 + 8 * `num_ops' bytes 13981 13982 * `vdef_ops' Similar to `def_ops' but for `VDEF' operators. There is 13983 one entry per memory symbol written by this statement. This is 13984 used to maintain the memory SSA use-def and def-def chains. 13985 13986 * `vuse_ops' Similar to `use_ops' but for `VUSE' operators. There is 13987 one entry per memory symbol loaded by this statement. This is used 13988 to maintain the memory SSA use-def chains. 13989 13990 * `stores' Bitset with all the UIDs for the symbols written-to by the 13991 statement. This is different than `vdef_ops' in that all the 13992 affected symbols are mentioned in this set. If memory 13993 partitioning is enabled, the `vdef_ops' vector will refer to memory 13994 partitions. Furthermore, no SSA information is stored in this set. 13995 13996 * `loads' Similar to `stores', but for memory loads. (Note that there 13997 is some amount of redundancy here, it should be possible to reduce 13998 memory utilization further by removing these sets). 13999 14000 All the other tuples are defined in terms of these three basic ones. 14001 Each tuple will add some fields. The main gimple type is defined to be 14002 the union of all these structures (`GTY' markers elided for clarity): 14003 14004 union gimple_statement_d 14005 { 14006 struct gimple_statement_base gsbase; 14007 struct gimple_statement_with_ops gsops; 14008 struct gimple_statement_with_memory_ops gsmem; 14009 struct gimple_statement_omp omp; 14010 struct gimple_statement_bind gimple_bind; 14011 struct gimple_statement_catch gimple_catch; 14012 struct gimple_statement_eh_filter gimple_eh_filter; 14013 struct gimple_statement_phi gimple_phi; 14014 struct gimple_statement_resx gimple_resx; 14015 struct gimple_statement_try gimple_try; 14016 struct gimple_statement_wce gimple_wce; 14017 struct gimple_statement_asm gimple_asm; 14018 struct gimple_statement_omp_critical gimple_omp_critical; 14019 struct gimple_statement_omp_for gimple_omp_for; 14020 struct gimple_statement_omp_parallel gimple_omp_parallel; 14021 struct gimple_statement_omp_task gimple_omp_task; 14022 struct gimple_statement_omp_sections gimple_omp_sections; 14023 struct gimple_statement_omp_single gimple_omp_single; 14024 struct gimple_statement_omp_continue gimple_omp_continue; 14025 struct gimple_statement_omp_atomic_load gimple_omp_atomic_load; 14026 struct gimple_statement_omp_atomic_store gimple_omp_atomic_store; 14027 }; 14028 14029 14030 File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Tuple representation, Up: GIMPLE 14031 14032 12.2 GIMPLE instruction set 14033 =========================== 14034 14035 The following table briefly describes the GIMPLE instruction set. 14036 14037 Instruction High GIMPLE Low GIMPLE 14038 `GIMPLE_ASM' x x 14039 `GIMPLE_ASSIGN' x x 14040 `GIMPLE_BIND' x 14041 `GIMPLE_CALL' x x 14042 `GIMPLE_CATCH' x 14043 `GIMPLE_COND' x x 14044 `GIMPLE_DEBUG' x x 14045 `GIMPLE_EH_FILTER' x 14046 `GIMPLE_GOTO' x x 14047 `GIMPLE_LABEL' x x 14048 `GIMPLE_NOP' x x 14049 `GIMPLE_OMP_ATOMIC_LOAD' x x 14050 `GIMPLE_OMP_ATOMIC_STORE' x x 14051 `GIMPLE_OMP_CONTINUE' x x 14052 `GIMPLE_OMP_CRITICAL' x x 14053 `GIMPLE_OMP_FOR' x x 14054 `GIMPLE_OMP_MASTER' x x 14055 `GIMPLE_OMP_ORDERED' x x 14056 `GIMPLE_OMP_PARALLEL' x x 14057 `GIMPLE_OMP_RETURN' x x 14058 `GIMPLE_OMP_SECTION' x x 14059 `GIMPLE_OMP_SECTIONS' x x 14060 `GIMPLE_OMP_SECTIONS_SWITCH' x x 14061 `GIMPLE_OMP_SINGLE' x x 14062 `GIMPLE_PHI' x 14063 `GIMPLE_RESX' x 14064 `GIMPLE_RETURN' x x 14065 `GIMPLE_SWITCH' x x 14066 `GIMPLE_TRY' x 14067 14068 14069 File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 14070 14071 12.3 Exception Handling 14072 ======================= 14073 14074 Other exception handling constructs are represented using 14075 `GIMPLE_TRY_CATCH'. `GIMPLE_TRY_CATCH' has two operands. The first 14076 operand is a sequence of statements to execute. If executing these 14077 statements does not throw an exception, then the second operand is 14078 ignored. Otherwise, if an exception is thrown, then the second operand 14079 of the `GIMPLE_TRY_CATCH' is checked. The second operand may have the 14080 following forms: 14081 14082 1. A sequence of statements to execute. When an exception occurs, 14083 these statements are executed, and then the exception is rethrown. 14084 14085 2. A sequence of `GIMPLE_CATCH' statements. Each `GIMPLE_CATCH' has 14086 a list of applicable exception types and handler code. If the 14087 thrown exception matches one of the caught types, the associated 14088 handler code is executed. If the handler code falls off the 14089 bottom, execution continues after the original `GIMPLE_TRY_CATCH'. 14090 14091 3. A `GIMPLE_EH_FILTER' statement. This has a list of permitted 14092 exception types, and code to handle a match failure. If the 14093 thrown exception does not match one of the allowed types, the 14094 associated match failure code is executed. If the thrown exception 14095 does match, it continues unwinding the stack looking for the next 14096 handler. 14097 14098 14099 Currently throwing an exception is not directly represented in GIMPLE, 14100 since it is implemented by calling a function. At some point in the 14101 future we will want to add some way to express that the call will throw 14102 an exception of a known type. 14103 14104 Just before running the optimizers, the compiler lowers the high-level 14105 EH constructs above into a set of `goto's, magic labels, and EH 14106 regions. Continuing to unwind at the end of a cleanup is represented 14107 with a `GIMPLE_RESX'. 14108 14109 14110 File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 14111 14112 12.4 Temporaries 14113 ================ 14114 14115 When gimplification encounters a subexpression that is too complex, it 14116 creates a new temporary variable to hold the value of the 14117 subexpression, and adds a new statement to initialize it before the 14118 current statement. These special temporaries are known as `expression 14119 temporaries', and are allocated using `get_formal_tmp_var'. The 14120 compiler tries to always evaluate identical expressions into the same 14121 temporary, to simplify elimination of redundant calculations. 14122 14123 We can only use expression temporaries when we know that it will not 14124 be reevaluated before its value is used, and that it will not be 14125 otherwise modified(1). Other temporaries can be allocated using 14126 `get_initialized_tmp_var' or `create_tmp_var'. 14127 14128 Currently, an expression like `a = b + 5' is not reduced any further. 14129 We tried converting it to something like 14130 T1 = b + 5; 14131 a = T1; 14132 but this bloated the representation for minimal benefit. However, a 14133 variable which must live in memory cannot appear in an expression; its 14134 value is explicitly loaded into a temporary first. Similarly, storing 14135 the value of an expression to a memory variable goes through a 14136 temporary. 14137 14138 ---------- Footnotes ---------- 14139 14140 (1) These restrictions are derived from those in Morgan 4.8. 14141 14142 14143 File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 14144 14145 12.5 Operands 14146 ============= 14147 14148 In general, expressions in GIMPLE consist of an operation and the 14149 appropriate number of simple operands; these operands must either be a 14150 GIMPLE rvalue (`is_gimple_val'), i.e. a constant or a register 14151 variable. More complex operands are factored out into temporaries, so 14152 that 14153 a = b + c + d 14154 becomes 14155 T1 = b + c; 14156 a = T1 + d; 14157 14158 The same rule holds for arguments to a `GIMPLE_CALL'. 14159 14160 The target of an assignment is usually a variable, but can also be a 14161 `MEM_REF' or a compound lvalue as described below. 14162 14163 * Menu: 14164 14165 * Compound Expressions:: 14166 * Compound Lvalues:: 14167 * Conditional Expressions:: 14168 * Logical Operators:: 14169 14170 14171 File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 14172 14173 12.5.1 Compound Expressions 14174 --------------------------- 14175 14176 The left-hand side of a C comma expression is simply moved into a 14177 separate statement. 14178 14179 14180 File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 14181 14182 12.5.2 Compound Lvalues 14183 ----------------------- 14184 14185 Currently compound lvalues involving array and structure field 14186 references are not broken down; an expression like `a.b[2] = 42' is not 14187 reduced any further (though complex array subscripts are). This 14188 restriction is a workaround for limitations in later optimizers; if we 14189 were to convert this to 14190 14191 T1 = &a.b; 14192 T1[2] = 42; 14193 14194 alias analysis would not remember that the reference to `T1[2]' came 14195 by way of `a.b', so it would think that the assignment could alias 14196 another member of `a'; this broke `struct-alias-1.c'. Future optimizer 14197 improvements may make this limitation unnecessary. 14198 14199 14200 File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 14201 14202 12.5.3 Conditional Expressions 14203 ------------------------------ 14204 14205 A C `?:' expression is converted into an `if' statement with each 14206 branch assigning to the same temporary. So, 14207 14208 a = b ? c : d; 14209 becomes 14210 if (b == 1) 14211 T1 = c; 14212 else 14213 T1 = d; 14214 a = T1; 14215 14216 The GIMPLE level if-conversion pass re-introduces `?:' expression, if 14217 appropriate. It is used to vectorize loops with conditions using vector 14218 conditional operations. 14219 14220 Note that in GIMPLE, `if' statements are represented using 14221 `GIMPLE_COND', as described below. 14222 14223 14224 File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 14225 14226 12.5.4 Logical Operators 14227 ------------------------ 14228 14229 Except when they appear in the condition operand of a `GIMPLE_COND', 14230 logical `and' and `or' operators are simplified as follows: `a = b && 14231 c' becomes 14232 14233 T1 = (bool)b; 14234 if (T1 == true) 14235 T1 = (bool)c; 14236 a = T1; 14237 14238 Note that `T1' in this example cannot be an expression temporary, 14239 because it has two different assignments. 14240 14241 12.5.5 Manipulating operands 14242 ---------------------------- 14243 14244 All gimple operands are of type `tree'. But only certain types of 14245 trees are allowed to be used as operand tuples. Basic validation is 14246 controlled by the function `get_gimple_rhs_class', which given a tree 14247 code, returns an `enum' with the following values of type `enum 14248 gimple_rhs_class' 14249 14250 * `GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 14251 14252 * `GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation. 14253 14254 * `GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 14255 14256 * `GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 14257 14258 * `GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 14259 split into simpler operands (for instance, `SSA_NAME', `VAR_DECL', 14260 `COMPONENT_REF', etc). 14261 14262 This operand class also acts as an escape hatch for tree nodes 14263 that may be flattened out into the operand vector, but would need 14264 more than two slots on the RHS. For instance, a `COND_EXPR' 14265 expression of the form `(a op b) ? x : y' could be flattened out 14266 on the operand vector using 4 slots, but it would also require 14267 additional processing to distinguish `c = a op b' from `c = a op b 14268 ? x : y'. Something similar occurs with `ASSERT_EXPR'. In time, 14269 these special case tree expressions should be flattened into the 14270 operand vector. 14271 14272 For tree nodes in the categories `GIMPLE_TERNARY_RHS', 14273 `GIMPLE_BINARY_RHS' and `GIMPLE_UNARY_RHS', they cannot be stored 14274 inside tuples directly. They first need to be flattened and separated 14275 into individual components. For instance, given the GENERIC expression 14276 14277 a = b + c 14278 14279 its tree representation is: 14280 14281 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 14282 14283 In this case, the GIMPLE form for this statement is logically 14284 identical to its GENERIC form but in GIMPLE, the `PLUS_EXPR' on the RHS 14285 of the assignment is not represented as a tree, instead the two 14286 operands are taken out of the `PLUS_EXPR' sub-tree and flattened into 14287 the GIMPLE tuple as follows: 14288 14289 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 14290 14291 12.5.6 Operand vector allocation 14292 -------------------------------- 14293 14294 The operand vector is stored at the bottom of the three tuple 14295 structures that accept operands. This means, that depending on the code 14296 of a given statement, its operand vector will be at different offsets 14297 from the base of the structure. To access tuple operands use the 14298 following accessors 14299 14300 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 14301 Returns the number of operands in statement G. 14302 14303 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 14304 Returns operand `I' from statement `G'. 14305 14306 -- GIMPLE function: tree * gimple_ops (gimple g) 14307 Returns a pointer into the operand vector for statement `G'. This 14308 is computed using an internal table called `gimple_ops_offset_'[]. 14309 This table is indexed by the gimple code of `G'. 14310 14311 When the compiler is built, this table is filled-in using the 14312 sizes of the structures used by each statement code defined in 14313 gimple.def. Since the operand vector is at the bottom of the 14314 structure, for a gimple code `C' the offset is computed as sizeof 14315 (struct-of `C') - sizeof (tree). 14316 14317 This mechanism adds one memory indirection to every access when 14318 using `gimple_op'(), if this becomes a bottleneck, a pass can 14319 choose to memoize the result from `gimple_ops'() and use that to 14320 access the operands. 14321 14322 12.5.7 Operand validation 14323 ------------------------- 14324 14325 When adding a new operand to a gimple statement, the operand will be 14326 validated according to what each tuple accepts in its operand vector. 14327 These predicates are called by the `gimple_NAME_set_...()'. Each tuple 14328 will use one of the following predicates (Note, this list is not 14329 exhaustive): 14330 14331 -- GIMPLE function: bool is_gimple_val (tree t) 14332 Returns true if t is a "GIMPLE value", which are all the 14333 non-addressable stack variables (variables for which 14334 `is_gimple_reg' returns true) and constants (expressions for which 14335 `is_gimple_min_invariant' returns true). 14336 14337 -- GIMPLE function: bool is_gimple_addressable (tree t) 14338 Returns true if t is a symbol or memory reference whose address 14339 can be taken. 14340 14341 -- GIMPLE function: bool is_gimple_asm_val (tree t) 14342 Similar to `is_gimple_val' but it also accepts hard registers. 14343 14344 -- GIMPLE function: bool is_gimple_call_addr (tree t) 14345 Return true if t is a valid expression to use as the function 14346 called by a `GIMPLE_CALL'. 14347 14348 -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t) 14349 Return true if t is a valid expression to use as first operand of 14350 a `MEM_REF' expression. 14351 14352 -- GIMPLE function: bool is_gimple_constant (tree t) 14353 Return true if t is a valid gimple constant. 14354 14355 -- GIMPLE function: bool is_gimple_min_invariant (tree t) 14356 Return true if t is a valid minimal invariant. This is different 14357 from constants, in that the specific value of t may not be known 14358 at compile time, but it is known that it doesn't change (e.g., the 14359 address of a function local variable). 14360 14361 -- GIMPLE function: bool is_gimple_ip_invariant (tree t) 14362 Return true if t is an interprocedural invariant. This means that 14363 t is a valid invariant in all functions (e.g. it can be an address 14364 of a global variable but not of a local one). 14365 14366 -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t) 14367 Return true if t is an `ADDR_EXPR' that does not change once the 14368 program is running (and which is valid in all functions). 14369 14370 12.5.8 Statement validation 14371 --------------------------- 14372 14373 -- GIMPLE function: bool is_gimple_assign (gimple g) 14374 Return true if the code of g is `GIMPLE_ASSIGN'. 14375 14376 -- GIMPLE function: bool is_gimple_call (gimple g) 14377 Return true if the code of g is `GIMPLE_CALL'. 14378 14379 -- GIMPLE function: bool is_gimple_debug (gimple g) 14380 Return true if the code of g is `GIMPLE_DEBUG'. 14381 14382 -- GIMPLE function: bool gimple_assign_cast_p (gimple g) 14383 Return true if g is a `GIMPLE_ASSIGN' that performs a type cast 14384 operation. 14385 14386 -- GIMPLE function: bool gimple_debug_bind_p (gimple g) 14387 Return true if g is a `GIMPLE_DEBUG' that binds the value of an 14388 expression to a variable. 14389 14390 14391 File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 14392 14393 12.6 Manipulating GIMPLE statements 14394 =================================== 14395 14396 This section documents all the functions available to handle each of 14397 the GIMPLE instructions. 14398 14399 12.6.1 Common accessors 14400 ----------------------- 14401 14402 The following are common accessors for gimple statements. 14403 14404 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 14405 Return the code for statement `G'. 14406 14407 -- GIMPLE function: basic_block gimple_bb (gimple g) 14408 Return the basic block to which statement `G' belongs to. 14409 14410 -- GIMPLE function: tree gimple_block (gimple g) 14411 Return the lexical scope block holding statement `G'. 14412 14413 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 14414 Return the type of the main expression computed by `STMT'. Return 14415 `void_type_node' if `STMT' computes nothing. This will only return 14416 something meaningful for `GIMPLE_ASSIGN', `GIMPLE_COND' and 14417 `GIMPLE_CALL'. For all other tuple codes, it will return 14418 `void_type_node'. 14419 14420 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 14421 Return the tree code for the expression computed by `STMT'. This 14422 is only meaningful for `GIMPLE_CALL', `GIMPLE_ASSIGN' and 14423 `GIMPLE_COND'. If `STMT' is `GIMPLE_CALL', it will return 14424 `CALL_EXPR'. For `GIMPLE_COND', it returns the code of the 14425 comparison predicate. For `GIMPLE_ASSIGN' it returns the code of 14426 the operation performed by the `RHS' of the assignment. 14427 14428 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 14429 Set the lexical scope block of `G' to `BLOCK'. 14430 14431 -- GIMPLE function: location_t gimple_locus (gimple g) 14432 Return locus information for statement `G'. 14433 14434 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 14435 Set locus information for statement `G'. 14436 14437 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 14438 Return true if `G' does not have locus information. 14439 14440 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 14441 Return true if no warnings should be emitted for statement `STMT'. 14442 14443 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 14444 visited_p) 14445 Set the visited status on statement `STMT' to `VISITED_P'. 14446 14447 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 14448 Return the visited status on statement `STMT'. 14449 14450 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 14451 plf, bool val_p) 14452 Set pass local flag `PLF' on statement `STMT' to `VAL_P'. 14453 14454 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum 14455 plf_mask plf) 14456 Return the value of pass local flag `PLF' on statement `STMT'. 14457 14458 -- GIMPLE function: bool gimple_has_ops (gimple g) 14459 Return true if statement `G' has register or memory operands. 14460 14461 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 14462 Return true if statement `G' has memory operands. 14463 14464 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 14465 Return the number of operands for statement `G'. 14466 14467 -- GIMPLE function: tree * gimple_ops (gimple g) 14468 Return the array of operands for statement `G'. 14469 14470 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 14471 Return operand `I' for statement `G'. 14472 14473 -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i) 14474 Return a pointer to operand `I' for statement `G'. 14475 14476 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 14477 Set operand `I' of statement `G' to `OP'. 14478 14479 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 14480 Return the set of symbols that have had their address taken by 14481 `STMT'. 14482 14483 -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g) 14484 Return the set of `DEF' operands for statement `G'. 14485 14486 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 14487 def_optype_d *def) 14488 Set `DEF' to be the set of `DEF' operands for statement `G'. 14489 14490 -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g) 14491 Return the set of `USE' operands for statement `G'. 14492 14493 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 14494 use_optype_d *use) 14495 Set `USE' to be the set of `USE' operands for statement `G'. 14496 14497 -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g) 14498 Return the set of `VUSE' operands for statement `G'. 14499 14500 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 14501 voptype_d *ops) 14502 Set `OPS' to be the set of `VUSE' operands for statement `G'. 14503 14504 -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g) 14505 Return the set of `VDEF' operands for statement `G'. 14506 14507 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 14508 voptype_d *ops) 14509 Set `OPS' to be the set of `VDEF' operands for statement `G'. 14510 14511 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 14512 Return the set of symbols loaded by statement `G'. Each element of 14513 the set is the `DECL_UID' of the corresponding symbol. 14514 14515 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 14516 Return the set of symbols stored by statement `G'. Each element of 14517 the set is the `DECL_UID' of the corresponding symbol. 14518 14519 -- GIMPLE function: bool gimple_modified_p (gimple g) 14520 Return true if statement `G' has operands and the modified field 14521 has been set. 14522 14523 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 14524 Return true if statement `STMT' contains volatile operands. 14525 14526 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, 14527 bool volatilep) 14528 Return true if statement `STMT' contains volatile operands. 14529 14530 -- GIMPLE function: void update_stmt (gimple s) 14531 Mark statement `S' as modified, and update it. 14532 14533 -- GIMPLE function: void update_stmt_if_modified (gimple s) 14534 Update statement `S' if it has been marked modified. 14535 14536 -- GIMPLE function: gimple gimple_copy (gimple stmt) 14537 Return a deep copy of statement `STMT'. 14538 14539 14540 File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 14541 14542 12.7 Tuple specific accessors 14543 ============================= 14544 14545 * Menu: 14546 14547 * `GIMPLE_ASM':: 14548 * `GIMPLE_ASSIGN':: 14549 * `GIMPLE_BIND':: 14550 * `GIMPLE_CALL':: 14551 * `GIMPLE_CATCH':: 14552 * `GIMPLE_COND':: 14553 * `GIMPLE_DEBUG':: 14554 * `GIMPLE_EH_FILTER':: 14555 * `GIMPLE_LABEL':: 14556 * `GIMPLE_NOP':: 14557 * `GIMPLE_OMP_ATOMIC_LOAD':: 14558 * `GIMPLE_OMP_ATOMIC_STORE':: 14559 * `GIMPLE_OMP_CONTINUE':: 14560 * `GIMPLE_OMP_CRITICAL':: 14561 * `GIMPLE_OMP_FOR':: 14562 * `GIMPLE_OMP_MASTER':: 14563 * `GIMPLE_OMP_ORDERED':: 14564 * `GIMPLE_OMP_PARALLEL':: 14565 * `GIMPLE_OMP_RETURN':: 14566 * `GIMPLE_OMP_SECTION':: 14567 * `GIMPLE_OMP_SECTIONS':: 14568 * `GIMPLE_OMP_SINGLE':: 14569 * `GIMPLE_PHI':: 14570 * `GIMPLE_RESX':: 14571 * `GIMPLE_RETURN':: 14572 * `GIMPLE_SWITCH':: 14573 * `GIMPLE_TRY':: 14574 * `GIMPLE_WITH_CLEANUP_EXPR':: 14575 14576 14577 File: gccint.info, Node: `GIMPLE_ASM', Next: `GIMPLE_ASSIGN', Up: Tuple specific accessors 14578 14579 12.7.1 `GIMPLE_ASM' 14580 ------------------- 14581 14582 -- GIMPLE function: gimple gimple_build_asm (const char *string, 14583 ninputs, noutputs, nclobbers, ...) 14584 Build a `GIMPLE_ASM' statement. This statement is used for 14585 building in-line assembly constructs. `STRING' is the assembly 14586 code. `NINPUT' is the number of register inputs. `NOUTPUT' is the 14587 number of register outputs. `NCLOBBERS' is the number of clobbered 14588 registers. The rest of the arguments trees for each input, 14589 output, and clobbered registers. 14590 14591 -- GIMPLE function: gimple gimple_build_asm_vec (const char *, 14592 VEC(tree,gc) *, VEC(tree,gc) *, VEC(tree,gc) *) 14593 Identical to gimple_build_asm, but the arguments are passed in 14594 VECs. 14595 14596 -- GIMPLE function: unsigned gimple_asm_ninputs (gimple g) 14597 Return the number of input operands for `GIMPLE_ASM' `G'. 14598 14599 -- GIMPLE function: unsigned gimple_asm_noutputs (gimple g) 14600 Return the number of output operands for `GIMPLE_ASM' `G'. 14601 14602 -- GIMPLE function: unsigned gimple_asm_nclobbers (gimple g) 14603 Return the number of clobber operands for `GIMPLE_ASM' `G'. 14604 14605 -- GIMPLE function: tree gimple_asm_input_op (gimple g, unsigned index) 14606 Return input operand `INDEX' of `GIMPLE_ASM' `G'. 14607 14608 -- GIMPLE function: void gimple_asm_set_input_op (gimple g, unsigned 14609 index, tree in_op) 14610 Set `IN_OP' to be input operand `INDEX' in `GIMPLE_ASM' `G'. 14611 14612 -- GIMPLE function: tree gimple_asm_output_op (gimple g, unsigned 14613 index) 14614 Return output operand `INDEX' of `GIMPLE_ASM' `G'. 14615 14616 -- GIMPLE function: void gimple_asm_set_output_op (gimple g, unsigned 14617 index, tree out_op) 14618 Set `OUT_OP' to be output operand `INDEX' in `GIMPLE_ASM' `G'. 14619 14620 -- GIMPLE function: tree gimple_asm_clobber_op (gimple g, unsigned 14621 index) 14622 Return clobber operand `INDEX' of `GIMPLE_ASM' `G'. 14623 14624 -- GIMPLE function: void gimple_asm_set_clobber_op (gimple g, unsigned 14625 index, tree clobber_op) 14626 Set `CLOBBER_OP' to be clobber operand `INDEX' in `GIMPLE_ASM' `G'. 14627 14628 -- GIMPLE function: const char * gimple_asm_string (gimple g) 14629 Return the string representing the assembly instruction in 14630 `GIMPLE_ASM' `G'. 14631 14632 -- GIMPLE function: bool gimple_asm_volatile_p (gimple g) 14633 Return true if `G' is an asm statement marked volatile. 14634 14635 -- GIMPLE function: void gimple_asm_set_volatile (gimple g) 14636 Mark asm statement `G' as volatile. 14637 14638 -- GIMPLE function: void gimple_asm_clear_volatile (gimple g) 14639 Remove volatile marker from asm statement `G'. 14640 14641 14642 File: gccint.info, Node: `GIMPLE_ASSIGN', Next: `GIMPLE_BIND', Prev: `GIMPLE_ASM', Up: Tuple specific accessors 14643 14644 12.7.2 `GIMPLE_ASSIGN' 14645 ---------------------- 14646 14647 -- GIMPLE function: gimple gimple_build_assign (tree lhs, tree rhs) 14648 Build a `GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 14649 passed in lhs. The right-hand side can be either a unary or 14650 binary tree expression. The expression tree rhs will be flattened 14651 and its operands assigned to the corresponding operand slots in 14652 the new statement. This function is useful when you already have 14653 a tree expression that you want to convert into a tuple. However, 14654 try to avoid building expression trees for the sole purpose of 14655 calling this function. If you already have the operands in 14656 separate trees, it is better to use `gimple_build_assign_with_ops'. 14657 14658 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 14659 gimple_seq *seq_p) 14660 Build a new `GIMPLE_ASSIGN' tuple and append it to the end of 14661 `*SEQ_P'. 14662 14663 `DST'/`SRC' are the destination and source respectively. You can pass 14664 ungimplified trees in `DST' or `SRC', in which case they will be 14665 converted to a gimple operand if necessary. 14666 14667 This function returns the newly created `GIMPLE_ASSIGN' tuple. 14668 14669 -- GIMPLE function: gimple gimple_build_assign_with_ops (enum 14670 tree_code subcode, tree lhs, tree op1, tree op2) 14671 This function is similar to `gimple_build_assign', but is used to 14672 build a `GIMPLE_ASSIGN' statement when the operands of the 14673 right-hand side of the assignment are already split into different 14674 operands. 14675 14676 The left-hand side is an lvalue passed in lhs. Subcode is the 14677 `tree_code' for the right-hand side of the assignment. Op1 and op2 14678 are the operands. If op2 is null, subcode must be a `tree_code' 14679 for a unary expression. 14680 14681 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 14682 Return the code of the expression computed on the `RHS' of 14683 assignment statement `G'. 14684 14685 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 14686 (gimple g) 14687 Return the gimple rhs class of the code for the expression 14688 computed on the rhs of assignment statement `G'. This will never 14689 return `GIMPLE_INVALID_RHS'. 14690 14691 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 14692 Return the `LHS' of assignment statement `G'. 14693 14694 -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g) 14695 Return a pointer to the `LHS' of assignment statement `G'. 14696 14697 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 14698 Return the first operand on the `RHS' of assignment statement `G'. 14699 14700 -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g) 14701 Return the address of the first operand on the `RHS' of assignment 14702 statement `G'. 14703 14704 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 14705 Return the second operand on the `RHS' of assignment statement `G'. 14706 14707 -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g) 14708 Return the address of the second operand on the `RHS' of assignment 14709 statement `G'. 14710 14711 -- GIMPLE function: tree gimple_assign_rhs3 (gimple g) 14712 Return the third operand on the `RHS' of assignment statement `G'. 14713 14714 -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g) 14715 Return the address of the third operand on the `RHS' of assignment 14716 statement `G'. 14717 14718 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 14719 Set `LHS' to be the `LHS' operand of assignment statement `G'. 14720 14721 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 14722 Set `RHS' to be the first operand on the `RHS' of assignment 14723 statement `G'. 14724 14725 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 14726 Set `RHS' to be the second operand on the `RHS' of assignment 14727 statement `G'. 14728 14729 -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs) 14730 Set `RHS' to be the third operand on the `RHS' of assignment 14731 statement `G'. 14732 14733 -- GIMPLE function: bool gimple_assign_cast_p (gimple s) 14734 Return true if `S' is a type-cast assignment. 14735 14736 14737 File: gccint.info, Node: `GIMPLE_BIND', Next: `GIMPLE_CALL', Prev: `GIMPLE_ASSIGN', Up: Tuple specific accessors 14738 14739 12.7.3 `GIMPLE_BIND' 14740 -------------------- 14741 14742 -- GIMPLE function: gimple gimple_build_bind (tree vars, gimple_seq 14743 body) 14744 Build a `GIMPLE_BIND' statement with a list of variables in `VARS' 14745 and a body of statements in sequence `BODY'. 14746 14747 -- GIMPLE function: tree gimple_bind_vars (gimple g) 14748 Return the variables declared in the `GIMPLE_BIND' statement `G'. 14749 14750 -- GIMPLE function: void gimple_bind_set_vars (gimple g, tree vars) 14751 Set `VARS' to be the set of variables declared in the `GIMPLE_BIND' 14752 statement `G'. 14753 14754 -- GIMPLE function: void gimple_bind_append_vars (gimple g, tree vars) 14755 Append `VARS' to the set of variables declared in the `GIMPLE_BIND' 14756 statement `G'. 14757 14758 -- GIMPLE function: gimple_seq gimple_bind_body (gimple g) 14759 Return the GIMPLE sequence contained in the `GIMPLE_BIND' statement 14760 `G'. 14761 14762 -- GIMPLE function: void gimple_bind_set_body (gimple g, gimple_seq 14763 seq) 14764 Set `SEQ' to be sequence contained in the `GIMPLE_BIND' statement 14765 `G'. 14766 14767 -- GIMPLE function: void gimple_bind_add_stmt (gimple gs, gimple stmt) 14768 Append a statement to the end of a `GIMPLE_BIND''s body. 14769 14770 -- GIMPLE function: void gimple_bind_add_seq (gimple gs, gimple_seq 14771 seq) 14772 Append a sequence of statements to the end of a `GIMPLE_BIND''s 14773 body. 14774 14775 -- GIMPLE function: tree gimple_bind_block (gimple g) 14776 Return the `TREE_BLOCK' node associated with `GIMPLE_BIND' 14777 statement `G'. This is analogous to the `BIND_EXPR_BLOCK' field in 14778 trees. 14779 14780 -- GIMPLE function: void gimple_bind_set_block (gimple g, tree block) 14781 Set `BLOCK' to be the `TREE_BLOCK' node associated with 14782 `GIMPLE_BIND' statement `G'. 14783 14784 14785 File: gccint.info, Node: `GIMPLE_CALL', Next: `GIMPLE_CATCH', Prev: `GIMPLE_BIND', Up: Tuple specific accessors 14786 14787 12.7.4 `GIMPLE_CALL' 14788 -------------------- 14789 14790 -- GIMPLE function: gimple gimple_build_call (tree fn, unsigned nargs, 14791 ...) 14792 Build a `GIMPLE_CALL' statement to function `FN'. The argument 14793 `FN' must be either a `FUNCTION_DECL' or a gimple call address as 14794 determined by `is_gimple_call_addr'. `NARGS' are the number of 14795 arguments. The rest of the arguments follow the argument `NARGS', 14796 and must be trees that are valid as rvalues in gimple (i.e., each 14797 operand is validated with `is_gimple_operand'). 14798 14799 -- GIMPLE function: gimple gimple_build_call_from_tree (tree call_expr) 14800 Build a `GIMPLE_CALL' from a `CALL_EXPR' node. The arguments and 14801 the function are taken from the expression directly. This routine 14802 assumes that `call_expr' is already in GIMPLE form. That is, its 14803 operands are GIMPLE values and the function call needs no further 14804 simplification. All the call flags in `call_expr' are copied over 14805 to the new `GIMPLE_CALL'. 14806 14807 -- GIMPLE function: gimple gimple_build_call_vec (tree fn, `VEC'(tree, 14808 heap) *args) 14809 Identical to `gimple_build_call' but the arguments are stored in a 14810 `VEC'(). 14811 14812 -- GIMPLE function: tree gimple_call_lhs (gimple g) 14813 Return the `LHS' of call statement `G'. 14814 14815 -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g) 14816 Return a pointer to the `LHS' of call statement `G'. 14817 14818 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 14819 Set `LHS' to be the `LHS' operand of call statement `G'. 14820 14821 -- GIMPLE function: tree gimple_call_fn (gimple g) 14822 Return the tree node representing the function called by call 14823 statement `G'. 14824 14825 -- GIMPLE function: void gimple_call_set_fn (gimple g, tree fn) 14826 Set `FN' to be the function called by call statement `G'. This has 14827 to be a gimple value specifying the address of the called function. 14828 14829 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 14830 If a given `GIMPLE_CALL''s callee is a `FUNCTION_DECL', return it. 14831 Otherwise return `NULL'. This function is analogous to 14832 `get_callee_fndecl' in `GENERIC'. 14833 14834 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 14835 Set the called function to `FNDECL'. 14836 14837 -- GIMPLE function: tree gimple_call_return_type (gimple g) 14838 Return the type returned by call statement `G'. 14839 14840 -- GIMPLE function: tree gimple_call_chain (gimple g) 14841 Return the static chain for call statement `G'. 14842 14843 -- GIMPLE function: void gimple_call_set_chain (gimple g, tree chain) 14844 Set `CHAIN' to be the static chain for call statement `G'. 14845 14846 -- GIMPLE function: unsigned gimple_call_num_args (gimple g) 14847 Return the number of arguments used by call statement `G'. 14848 14849 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 14850 Return the argument at position `INDEX' for call statement `G'. 14851 The first argument is 0. 14852 14853 -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned 14854 index) 14855 Return a pointer to the argument at position `INDEX' for call 14856 statement `G'. 14857 14858 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned 14859 index, tree arg) 14860 Set `ARG' to be the argument at position `INDEX' for call statement 14861 `G'. 14862 14863 -- GIMPLE function: void gimple_call_set_tail (gimple s) 14864 Mark call statement `S' as being a tail call (i.e., a call just 14865 before the exit of a function). These calls are candidate for tail 14866 call optimization. 14867 14868 -- GIMPLE function: bool gimple_call_tail_p (gimple s) 14869 Return true if `GIMPLE_CALL' `S' is marked as a tail call. 14870 14871 -- GIMPLE function: void gimple_call_mark_uninlinable (gimple s) 14872 Mark `GIMPLE_CALL' `S' as being uninlinable. 14873 14874 -- GIMPLE function: bool gimple_call_cannot_inline_p (gimple s) 14875 Return true if `GIMPLE_CALL' `S' cannot be inlined. 14876 14877 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 14878 Return true if `S' is a noreturn call. 14879 14880 -- GIMPLE function: gimple gimple_call_copy_skip_args (gimple stmt, 14881 bitmap args_to_skip) 14882 Build a `GIMPLE_CALL' identical to `STMT' but skipping the 14883 arguments in the positions marked by the set `ARGS_TO_SKIP'. 14884 14885 14886 File: gccint.info, Node: `GIMPLE_CATCH', Next: `GIMPLE_COND', Prev: `GIMPLE_CALL', Up: Tuple specific accessors 14887 14888 12.7.5 `GIMPLE_CATCH' 14889 --------------------- 14890 14891 -- GIMPLE function: gimple gimple_build_catch (tree types, gimple_seq 14892 handler) 14893 Build a `GIMPLE_CATCH' statement. `TYPES' are the tree types this 14894 catch handles. `HANDLER' is a sequence of statements with the code 14895 for the handler. 14896 14897 -- GIMPLE function: tree gimple_catch_types (gimple g) 14898 Return the types handled by `GIMPLE_CATCH' statement `G'. 14899 14900 -- GIMPLE function: tree * gimple_catch_types_ptr (gimple g) 14901 Return a pointer to the types handled by `GIMPLE_CATCH' statement 14902 `G'. 14903 14904 -- GIMPLE function: gimple_seq gimple_catch_handler (gimple g) 14905 Return the GIMPLE sequence representing the body of the handler of 14906 `GIMPLE_CATCH' statement `G'. 14907 14908 -- GIMPLE function: void gimple_catch_set_types (gimple g, tree t) 14909 Set `T' to be the set of types handled by `GIMPLE_CATCH' `G'. 14910 14911 -- GIMPLE function: void gimple_catch_set_handler (gimple g, 14912 gimple_seq handler) 14913 Set `HANDLER' to be the body of `GIMPLE_CATCH' `G'. 14914 14915 14916 File: gccint.info, Node: `GIMPLE_COND', Next: `GIMPLE_DEBUG', Prev: `GIMPLE_CATCH', Up: Tuple specific accessors 14917 14918 12.7.6 `GIMPLE_COND' 14919 -------------------- 14920 14921 -- GIMPLE function: gimple gimple_build_cond (enum tree_code 14922 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 14923 Build a `GIMPLE_COND' statement. `A' `GIMPLE_COND' statement 14924 compares `LHS' and `RHS' and if the condition in `PRED_CODE' is 14925 true, jump to the label in `t_label', otherwise jump to the label 14926 in `f_label'. `PRED_CODE' are relational operator tree codes like 14927 `EQ_EXPR', `LT_EXPR', `LE_EXPR', `NE_EXPR', etc. 14928 14929 -- GIMPLE function: gimple gimple_build_cond_from_tree (tree cond, 14930 tree t_label, tree f_label) 14931 Build a `GIMPLE_COND' statement from the conditional expression 14932 tree `COND'. `T_LABEL' and `F_LABEL' are as in 14933 `gimple_build_cond'. 14934 14935 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 14936 Return the code of the predicate computed by conditional statement 14937 `G'. 14938 14939 -- GIMPLE function: void gimple_cond_set_code (gimple g, enum 14940 tree_code code) 14941 Set `CODE' to be the predicate code for the conditional statement 14942 `G'. 14943 14944 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 14945 Return the `LHS' of the predicate computed by conditional statement 14946 `G'. 14947 14948 -- GIMPLE function: void gimple_cond_set_lhs (gimple g, tree lhs) 14949 Set `LHS' to be the `LHS' operand of the predicate computed by 14950 conditional statement `G'. 14951 14952 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 14953 Return the `RHS' operand of the predicate computed by conditional 14954 `G'. 14955 14956 -- GIMPLE function: void gimple_cond_set_rhs (gimple g, tree rhs) 14957 Set `RHS' to be the `RHS' operand of the predicate computed by 14958 conditional statement `G'. 14959 14960 -- GIMPLE function: tree gimple_cond_true_label (gimple g) 14961 Return the label used by conditional statement `G' when its 14962 predicate evaluates to true. 14963 14964 -- GIMPLE function: void gimple_cond_set_true_label (gimple g, tree 14965 label) 14966 Set `LABEL' to be the label used by conditional statement `G' when 14967 its predicate evaluates to true. 14968 14969 -- GIMPLE function: void gimple_cond_set_false_label (gimple g, tree 14970 label) 14971 Set `LABEL' to be the label used by conditional statement `G' when 14972 its predicate evaluates to false. 14973 14974 -- GIMPLE function: tree gimple_cond_false_label (gimple g) 14975 Return the label used by conditional statement `G' when its 14976 predicate evaluates to false. 14977 14978 -- GIMPLE function: void gimple_cond_make_false (gimple g) 14979 Set the conditional `COND_STMT' to be of the form 'if (1 == 0)'. 14980 14981 -- GIMPLE function: void gimple_cond_make_true (gimple g) 14982 Set the conditional `COND_STMT' to be of the form 'if (1 == 1)'. 14983 14984 14985 File: gccint.info, Node: `GIMPLE_DEBUG', Next: `GIMPLE_EH_FILTER', Prev: `GIMPLE_COND', Up: Tuple specific accessors 14986 14987 12.7.7 `GIMPLE_DEBUG' 14988 --------------------- 14989 14990 -- GIMPLE function: gimple gimple_build_debug_bind (tree var, tree 14991 value, gimple stmt) 14992 Build a `GIMPLE_DEBUG' statement with `GIMPLE_DEBUG_BIND' of 14993 `subcode'. The effect of this statement is to tell debug 14994 information generation machinery that the value of user variable 14995 `var' is given by `value' at that point, and to remain with that 14996 value until `var' runs out of scope, a dynamically-subsequent 14997 debug bind statement overrides the binding, or conflicting values 14998 reach a control flow merge point. Even if components of the 14999 `value' expression change afterwards, the variable is supposed to 15000 retain the same value, though not necessarily the same location. 15001 15002 It is expected that `var' be most often a tree for automatic user 15003 variables (`VAR_DECL' or `PARM_DECL') that satisfy the 15004 requirements for gimple registers, but it may also be a tree for a 15005 scalarized component of a user variable (`ARRAY_REF', 15006 `COMPONENT_REF'), or a debug temporary (`DEBUG_EXPR_DECL'). 15007 15008 As for `value', it can be an arbitrary tree expression, but it is 15009 recommended that it be in a suitable form for a gimple assignment 15010 `RHS'. It is not expected that user variables that could appear 15011 as `var' ever appear in `value', because in the latter we'd have 15012 their `SSA_NAME's instead, but even if they were not in SSA form, 15013 user variables appearing in `value' are to be regarded as part of 15014 the executable code space, whereas those in `var' are to be 15015 regarded as part of the source code space. There is no way to 15016 refer to the value bound to a user variable within a `value' 15017 expression. 15018 15019 If `value' is `GIMPLE_DEBUG_BIND_NOVALUE', debug information 15020 generation machinery is informed that the variable `var' is 15021 unbound, i.e., that its value is indeterminate, which sometimes 15022 means it is really unavailable, and other times that the compiler 15023 could not keep track of it. 15024 15025 Block and location information for the newly-created stmt are 15026 taken from `stmt', if given. 15027 15028 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 15029 Return the user variable VAR that is bound at `stmt'. 15030 15031 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 15032 Return the value expression that is bound to a user variable at 15033 `stmt'. 15034 15035 -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple 15036 stmt) 15037 Return a pointer to the value expression that is bound to a user 15038 variable at `stmt'. 15039 15040 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 15041 var) 15042 Modify the user variable bound at `stmt' to VAR. 15043 15044 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, 15045 tree var) 15046 Modify the value bound to the user variable bound at `stmt' to 15047 VALUE. 15048 15049 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 15050 Modify the value bound to the user variable bound at `stmt' so 15051 that the variable becomes unbound. 15052 15053 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 15054 Return `TRUE' if `stmt' binds a user variable to a value, and 15055 `FALSE' if it unbinds the variable. 15056 15057 15058 File: gccint.info, Node: `GIMPLE_EH_FILTER', Next: `GIMPLE_LABEL', Prev: `GIMPLE_DEBUG', Up: Tuple specific accessors 15059 15060 12.7.8 `GIMPLE_EH_FILTER' 15061 ------------------------- 15062 15063 -- GIMPLE function: gimple gimple_build_eh_filter (tree types, 15064 gimple_seq failure) 15065 Build a `GIMPLE_EH_FILTER' statement. `TYPES' are the filter's 15066 types. `FAILURE' is a sequence with the filter's failure action. 15067 15068 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 15069 Return the types handled by `GIMPLE_EH_FILTER' statement `G'. 15070 15071 -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g) 15072 Return a pointer to the types handled by `GIMPLE_EH_FILTER' 15073 statement `G'. 15074 15075 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 15076 Return the sequence of statement to execute when `GIMPLE_EH_FILTER' 15077 statement fails. 15078 15079 -- GIMPLE function: void gimple_eh_filter_set_types (gimple g, tree 15080 types) 15081 Set `TYPES' to be the set of types handled by `GIMPLE_EH_FILTER' 15082 `G'. 15083 15084 -- GIMPLE function: void gimple_eh_filter_set_failure (gimple g, 15085 gimple_seq failure) 15086 Set `FAILURE' to be the sequence of statements to execute on 15087 failure for `GIMPLE_EH_FILTER' `G'. 15088 15089 -- GIMPLE function: bool gimple_eh_filter_must_not_throw (gimple g) 15090 Return the `EH_FILTER_MUST_NOT_THROW' flag. 15091 15092 -- GIMPLE function: void gimple_eh_filter_set_must_not_throw (gimple 15093 g, bool mntp) 15094 Set the `EH_FILTER_MUST_NOT_THROW' flag. 15095 15096 15097 File: gccint.info, Node: `GIMPLE_LABEL', Next: `GIMPLE_NOP', Prev: `GIMPLE_EH_FILTER', Up: Tuple specific accessors 15098 15099 12.7.9 `GIMPLE_LABEL' 15100 --------------------- 15101 15102 -- GIMPLE function: gimple gimple_build_label (tree label) 15103 Build a `GIMPLE_LABEL' statement with corresponding to the tree 15104 label, `LABEL'. 15105 15106 -- GIMPLE function: tree gimple_label_label (gimple g) 15107 Return the `LABEL_DECL' node used by `GIMPLE_LABEL' statement `G'. 15108 15109 -- GIMPLE function: void gimple_label_set_label (gimple g, tree label) 15110 Set `LABEL' to be the `LABEL_DECL' node used by `GIMPLE_LABEL' 15111 statement `G'. 15112 15113 -- GIMPLE function: gimple gimple_build_goto (tree dest) 15114 Build a `GIMPLE_GOTO' statement to label `DEST'. 15115 15116 -- GIMPLE function: tree gimple_goto_dest (gimple g) 15117 Return the destination of the unconditional jump `G'. 15118 15119 -- GIMPLE function: void gimple_goto_set_dest (gimple g, tree dest) 15120 Set `DEST' to be the destination of the unconditional jump `G'. 15121 15122 15123 File: gccint.info, Node: `GIMPLE_NOP', Next: `GIMPLE_OMP_ATOMIC_LOAD', Prev: `GIMPLE_LABEL', Up: Tuple specific accessors 15124 15125 12.7.10 `GIMPLE_NOP' 15126 -------------------- 15127 15128 -- GIMPLE function: gimple gimple_build_nop (void) 15129 Build a `GIMPLE_NOP' statement. 15130 15131 -- GIMPLE function: bool gimple_nop_p (gimple g) 15132 Returns `TRUE' if statement `G' is a `GIMPLE_NOP'. 15133 15134 15135 File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_LOAD', Next: `GIMPLE_OMP_ATOMIC_STORE', Prev: `GIMPLE_NOP', Up: Tuple specific accessors 15136 15137 12.7.11 `GIMPLE_OMP_ATOMIC_LOAD' 15138 -------------------------------- 15139 15140 -- GIMPLE function: gimple gimple_build_omp_atomic_load (tree lhs, 15141 tree rhs) 15142 Build a `GIMPLE_OMP_ATOMIC_LOAD' statement. `LHS' is the left-hand 15143 side of the assignment. `RHS' is the right-hand side of the 15144 assignment. 15145 15146 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs (gimple g, 15147 tree lhs) 15148 Set the `LHS' of an atomic load. 15149 15150 -- GIMPLE function: tree gimple_omp_atomic_load_lhs (gimple g) 15151 Get the `LHS' of an atomic load. 15152 15153 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs (gimple g, 15154 tree rhs) 15155 Set the `RHS' of an atomic set. 15156 15157 -- GIMPLE function: tree gimple_omp_atomic_load_rhs (gimple g) 15158 Get the `RHS' of an atomic set. 15159 15160 15161 File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_STORE', Next: `GIMPLE_OMP_CONTINUE', Prev: `GIMPLE_OMP_ATOMIC_LOAD', Up: Tuple specific accessors 15162 15163 12.7.12 `GIMPLE_OMP_ATOMIC_STORE' 15164 --------------------------------- 15165 15166 -- GIMPLE function: gimple gimple_build_omp_atomic_store (tree val) 15167 Build a `GIMPLE_OMP_ATOMIC_STORE' statement. `VAL' is the value to 15168 be stored. 15169 15170 -- GIMPLE function: void gimple_omp_atomic_store_set_val (gimple g, 15171 tree val) 15172 Set the value being stored in an atomic store. 15173 15174 -- GIMPLE function: tree gimple_omp_atomic_store_val (gimple g) 15175 Return the value being stored in an atomic store. 15176 15177 15178 File: gccint.info, Node: `GIMPLE_OMP_CONTINUE', Next: `GIMPLE_OMP_CRITICAL', Prev: `GIMPLE_OMP_ATOMIC_STORE', Up: Tuple specific accessors 15179 15180 12.7.13 `GIMPLE_OMP_CONTINUE' 15181 ----------------------------- 15182 15183 -- GIMPLE function: gimple gimple_build_omp_continue (tree 15184 control_def, tree control_use) 15185 Build a `GIMPLE_OMP_CONTINUE' statement. `CONTROL_DEF' is the 15186 definition of the control variable. `CONTROL_USE' is the use of 15187 the control variable. 15188 15189 -- GIMPLE function: tree gimple_omp_continue_control_def (gimple s) 15190 Return the definition of the control variable on a 15191 `GIMPLE_OMP_CONTINUE' in `S'. 15192 15193 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr (gimple s) 15194 Same as above, but return the pointer. 15195 15196 -- GIMPLE function: tree gimple_omp_continue_set_control_def (gimple s) 15197 Set the control variable definition for a `GIMPLE_OMP_CONTINUE' 15198 statement in `S'. 15199 15200 -- GIMPLE function: tree gimple_omp_continue_control_use (gimple s) 15201 Return the use of the control variable on a `GIMPLE_OMP_CONTINUE' 15202 in `S'. 15203 15204 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr (gimple s) 15205 Same as above, but return the pointer. 15206 15207 -- GIMPLE function: tree gimple_omp_continue_set_control_use (gimple s) 15208 Set the control variable use for a `GIMPLE_OMP_CONTINUE' statement 15209 in `S'. 15210 15211 15212 File: gccint.info, Node: `GIMPLE_OMP_CRITICAL', Next: `GIMPLE_OMP_FOR', Prev: `GIMPLE_OMP_CONTINUE', Up: Tuple specific accessors 15213 15214 12.7.14 `GIMPLE_OMP_CRITICAL' 15215 ----------------------------- 15216 15217 -- GIMPLE function: gimple gimple_build_omp_critical (gimple_seq body, 15218 tree name) 15219 Build a `GIMPLE_OMP_CRITICAL' statement. `BODY' is the sequence of 15220 statements for which only one thread can execute. `NAME' is an 15221 optional identifier for this critical block. 15222 15223 -- GIMPLE function: tree gimple_omp_critical_name (gimple g) 15224 Return the name associated with `OMP_CRITICAL' statement `G'. 15225 15226 -- GIMPLE function: tree * gimple_omp_critical_name_ptr (gimple g) 15227 Return a pointer to the name associated with `OMP' critical 15228 statement `G'. 15229 15230 -- GIMPLE function: void gimple_omp_critical_set_name (gimple g, tree 15231 name) 15232 Set `NAME' to be the name associated with `OMP' critical statement 15233 `G'. 15234 15235 15236 File: gccint.info, Node: `GIMPLE_OMP_FOR', Next: `GIMPLE_OMP_MASTER', Prev: `GIMPLE_OMP_CRITICAL', Up: Tuple specific accessors 15237 15238 12.7.15 `GIMPLE_OMP_FOR' 15239 ------------------------ 15240 15241 -- GIMPLE function: gimple gimple_build_omp_for (gimple_seq body, tree 15242 clauses, tree index, tree initial, tree final, tree incr, 15243 gimple_seq pre_body, enum tree_code omp_for_cond) 15244 Build a `GIMPLE_OMP_FOR' statement. `BODY' is sequence of 15245 statements inside the for loop. `CLAUSES', are any of the `OMP' 15246 loop construct's clauses: private, firstprivate, lastprivate, 15247 reductions, ordered, schedule, and nowait. `PRE_BODY' is the 15248 sequence of statements that are loop invariant. `INDEX' is the 15249 index variable. `INITIAL' is the initial value of `INDEX'. 15250 `FINAL' is final value of `INDEX'. OMP_FOR_COND is the predicate 15251 used to compare `INDEX' and `FINAL'. `INCR' is the increment 15252 expression. 15253 15254 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 15255 Return the clauses associated with `OMP_FOR' `G'. 15256 15257 -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g) 15258 Return a pointer to the `OMP_FOR' `G'. 15259 15260 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 15261 clauses) 15262 Set `CLAUSES' to be the list of clauses associated with `OMP_FOR' 15263 `G'. 15264 15265 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 15266 Return the index variable for `OMP_FOR' `G'. 15267 15268 -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g) 15269 Return a pointer to the index variable for `OMP_FOR' `G'. 15270 15271 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 15272 index) 15273 Set `INDEX' to be the index variable for `OMP_FOR' `G'. 15274 15275 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 15276 Return the initial value for `OMP_FOR' `G'. 15277 15278 -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g) 15279 Return a pointer to the initial value for `OMP_FOR' `G'. 15280 15281 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 15282 initial) 15283 Set `INITIAL' to be the initial value for `OMP_FOR' `G'. 15284 15285 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 15286 Return the final value for `OMP_FOR' `G'. 15287 15288 -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g) 15289 turn a pointer to the final value for `OMP_FOR' `G'. 15290 15291 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 15292 final) 15293 Set `FINAL' to be the final value for `OMP_FOR' `G'. 15294 15295 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 15296 Return the increment value for `OMP_FOR' `G'. 15297 15298 -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g) 15299 Return a pointer to the increment value for `OMP_FOR' `G'. 15300 15301 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 15302 Set `INCR' to be the increment value for `OMP_FOR' `G'. 15303 15304 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 15305 Return the sequence of statements to execute before the `OMP_FOR' 15306 statement `G' starts. 15307 15308 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 15309 gimple_seq pre_body) 15310 Set `PRE_BODY' to be the sequence of statements to execute before 15311 the `OMP_FOR' statement `G' starts. 15312 15313 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 15314 tree_code cond) 15315 Set `COND' to be the condition code for `OMP_FOR' `G'. 15316 15317 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 15318 Return the condition code associated with `OMP_FOR' `G'. 15319 15320 15321 File: gccint.info, Node: `GIMPLE_OMP_MASTER', Next: `GIMPLE_OMP_ORDERED', Prev: `GIMPLE_OMP_FOR', Up: Tuple specific accessors 15322 15323 12.7.16 `GIMPLE_OMP_MASTER' 15324 --------------------------- 15325 15326 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 15327 Build a `GIMPLE_OMP_MASTER' statement. `BODY' is the sequence of 15328 statements to be executed by just the master. 15329 15330 15331 File: gccint.info, Node: `GIMPLE_OMP_ORDERED', Next: `GIMPLE_OMP_PARALLEL', Prev: `GIMPLE_OMP_MASTER', Up: Tuple specific accessors 15332 15333 12.7.17 `GIMPLE_OMP_ORDERED' 15334 ---------------------------- 15335 15336 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 15337 Build a `GIMPLE_OMP_ORDERED' statement. 15338 15339 `BODY' is the sequence of statements inside a loop that will executed 15340 in sequence. 15341 15342 15343 File: gccint.info, Node: `GIMPLE_OMP_PARALLEL', Next: `GIMPLE_OMP_RETURN', Prev: `GIMPLE_OMP_ORDERED', Up: Tuple specific accessors 15344 15345 12.7.18 `GIMPLE_OMP_PARALLEL' 15346 ----------------------------- 15347 15348 -- GIMPLE function: gimple gimple_build_omp_parallel (gimple_seq body, 15349 tree clauses, tree child_fn, tree data_arg) 15350 Build a `GIMPLE_OMP_PARALLEL' statement. 15351 15352 `BODY' is sequence of statements which are executed in parallel. 15353 `CLAUSES', are the `OMP' parallel construct's clauses. `CHILD_FN' is 15354 the function created for the parallel threads to execute. `DATA_ARG' 15355 are the shared data argument(s). 15356 15357 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 15358 Return true if `OMP' parallel statement `G' has the 15359 `GF_OMP_PARALLEL_COMBINED' flag set. 15360 15361 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 15362 Set the `GF_OMP_PARALLEL_COMBINED' field in `OMP' parallel 15363 statement `G'. 15364 15365 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 15366 Return the body for the `OMP' statement `G'. 15367 15368 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 15369 body) 15370 Set `BODY' to be the body for the `OMP' statement `G'. 15371 15372 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 15373 Return the clauses associated with `OMP_PARALLEL' `G'. 15374 15375 -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr (gimple g) 15376 Return a pointer to the clauses associated with `OMP_PARALLEL' `G'. 15377 15378 -- GIMPLE function: void gimple_omp_parallel_set_clauses (gimple g, 15379 tree clauses) 15380 Set `CLAUSES' to be the list of clauses associated with 15381 `OMP_PARALLEL' `G'. 15382 15383 -- GIMPLE function: tree gimple_omp_parallel_child_fn (gimple g) 15384 Return the child function used to hold the body of `OMP_PARALLEL' 15385 `G'. 15386 15387 -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr (gimple g) 15388 Return a pointer to the child function used to hold the body of 15389 `OMP_PARALLEL' `G'. 15390 15391 -- GIMPLE function: void gimple_omp_parallel_set_child_fn (gimple g, 15392 tree child_fn) 15393 Set `CHILD_FN' to be the child function for `OMP_PARALLEL' `G'. 15394 15395 -- GIMPLE function: tree gimple_omp_parallel_data_arg (gimple g) 15396 Return the artificial argument used to send variables and values 15397 from the parent to the children threads in `OMP_PARALLEL' `G'. 15398 15399 -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr (gimple g) 15400 Return a pointer to the data argument for `OMP_PARALLEL' `G'. 15401 15402 -- GIMPLE function: void gimple_omp_parallel_set_data_arg (gimple g, 15403 tree data_arg) 15404 Set `DATA_ARG' to be the data argument for `OMP_PARALLEL' `G'. 15405 15406 -- GIMPLE function: bool is_gimple_omp (gimple stmt) 15407 Returns true when the gimple statement `STMT' is any of the OpenMP 15408 types. 15409 15410 15411 File: gccint.info, Node: `GIMPLE_OMP_RETURN', Next: `GIMPLE_OMP_SECTION', Prev: `GIMPLE_OMP_PARALLEL', Up: Tuple specific accessors 15412 15413 12.7.19 `GIMPLE_OMP_RETURN' 15414 --------------------------- 15415 15416 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 15417 Build a `GIMPLE_OMP_RETURN' statement. `WAIT_P' is true if this is 15418 a non-waiting return. 15419 15420 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 15421 Set the nowait flag on `GIMPLE_OMP_RETURN' statement `S'. 15422 15423 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 15424 Return true if `OMP' return statement `G' has the 15425 `GF_OMP_RETURN_NOWAIT' flag set. 15426 15427 15428 File: gccint.info, Node: `GIMPLE_OMP_SECTION', Next: `GIMPLE_OMP_SECTIONS', Prev: `GIMPLE_OMP_RETURN', Up: Tuple specific accessors 15429 15430 12.7.20 `GIMPLE_OMP_SECTION' 15431 ---------------------------- 15432 15433 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 15434 Build a `GIMPLE_OMP_SECTION' statement for a sections statement. 15435 15436 `BODY' is the sequence of statements in the section. 15437 15438 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 15439 Return true if `OMP' section statement `G' has the 15440 `GF_OMP_SECTION_LAST' flag set. 15441 15442 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 15443 Set the `GF_OMP_SECTION_LAST' flag on `G'. 15444 15445 15446 File: gccint.info, Node: `GIMPLE_OMP_SECTIONS', Next: `GIMPLE_OMP_SINGLE', Prev: `GIMPLE_OMP_SECTION', Up: Tuple specific accessors 15447 15448 12.7.21 `GIMPLE_OMP_SECTIONS' 15449 ----------------------------- 15450 15451 -- GIMPLE function: gimple gimple_build_omp_sections (gimple_seq body, 15452 tree clauses) 15453 Build a `GIMPLE_OMP_SECTIONS' statement. `BODY' is a sequence of 15454 section statements. `CLAUSES' are any of the `OMP' sections 15455 construct's clauses: private, firstprivate, lastprivate, 15456 reduction, and nowait. 15457 15458 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 15459 Build a `GIMPLE_OMP_SECTIONS_SWITCH' statement. 15460 15461 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 15462 Return the control variable associated with the 15463 `GIMPLE_OMP_SECTIONS' in `G'. 15464 15465 -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g) 15466 Return a pointer to the clauses associated with the 15467 `GIMPLE_OMP_SECTIONS' in `G'. 15468 15469 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 15470 tree control) 15471 Set `CONTROL' to be the set of clauses associated with the 15472 `GIMPLE_OMP_SECTIONS' in `G'. 15473 15474 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 15475 Return the clauses associated with `OMP_SECTIONS' `G'. 15476 15477 -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g) 15478 Return a pointer to the clauses associated with `OMP_SECTIONS' `G'. 15479 15480 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 15481 tree clauses) 15482 Set `CLAUSES' to be the set of clauses associated with 15483 `OMP_SECTIONS' `G'. 15484 15485 15486 File: gccint.info, Node: `GIMPLE_OMP_SINGLE', Next: `GIMPLE_PHI', Prev: `GIMPLE_OMP_SECTIONS', Up: Tuple specific accessors 15487 15488 12.7.22 `GIMPLE_OMP_SINGLE' 15489 --------------------------- 15490 15491 -- GIMPLE function: gimple gimple_build_omp_single (gimple_seq body, 15492 tree clauses) 15493 Build a `GIMPLE_OMP_SINGLE' statement. `BODY' is the sequence of 15494 statements that will be executed once. `CLAUSES' are any of the 15495 `OMP' single construct's clauses: private, firstprivate, 15496 copyprivate, nowait. 15497 15498 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 15499 Return the clauses associated with `OMP_SINGLE' `G'. 15500 15501 -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g) 15502 Return a pointer to the clauses associated with `OMP_SINGLE' `G'. 15503 15504 -- GIMPLE function: void gimple_omp_single_set_clauses (gimple g, tree 15505 clauses) 15506 Set `CLAUSES' to be the clauses associated with `OMP_SINGLE' `G'. 15507 15508 15509 File: gccint.info, Node: `GIMPLE_PHI', Next: `GIMPLE_RESX', Prev: `GIMPLE_OMP_SINGLE', Up: Tuple specific accessors 15510 15511 12.7.23 `GIMPLE_PHI' 15512 -------------------- 15513 15514 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 15515 Return the maximum number of arguments supported by `GIMPLE_PHI' 15516 `G'. 15517 15518 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 15519 Return the number of arguments in `GIMPLE_PHI' `G'. This must 15520 always be exactly the number of incoming edges for the basic block 15521 holding `G'. 15522 15523 -- GIMPLE function: tree gimple_phi_result (gimple g) 15524 Return the `SSA' name created by `GIMPLE_PHI' `G'. 15525 15526 -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g) 15527 Return a pointer to the `SSA' name created by `GIMPLE_PHI' `G'. 15528 15529 -- GIMPLE function: void gimple_phi_set_result (gimple g, tree result) 15530 Set `RESULT' to be the `SSA' name created by `GIMPLE_PHI' `G'. 15531 15532 -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index) 15533 Return the `PHI' argument corresponding to incoming edge `INDEX' 15534 for `GIMPLE_PHI' `G'. 15535 15536 -- GIMPLE function: void gimple_phi_set_arg (gimple g, index, struct 15537 phi_arg_d * phiarg) 15538 Set `PHIARG' to be the argument corresponding to incoming edge 15539 `INDEX' for `GIMPLE_PHI' `G'. 15540 15541 15542 File: gccint.info, Node: `GIMPLE_RESX', Next: `GIMPLE_RETURN', Prev: `GIMPLE_PHI', Up: Tuple specific accessors 15543 15544 12.7.24 `GIMPLE_RESX' 15545 --------------------- 15546 15547 -- GIMPLE function: gimple gimple_build_resx (int region) 15548 Build a `GIMPLE_RESX' statement which is a statement. This 15549 statement is a placeholder for _Unwind_Resume before we know if a 15550 function call or a branch is needed. `REGION' is the exception 15551 region from which control is flowing. 15552 15553 -- GIMPLE function: int gimple_resx_region (gimple g) 15554 Return the region number for `GIMPLE_RESX' `G'. 15555 15556 -- GIMPLE function: void gimple_resx_set_region (gimple g, int region) 15557 Set `REGION' to be the region number for `GIMPLE_RESX' `G'. 15558 15559 15560 File: gccint.info, Node: `GIMPLE_RETURN', Next: `GIMPLE_SWITCH', Prev: `GIMPLE_RESX', Up: Tuple specific accessors 15561 15562 12.7.25 `GIMPLE_RETURN' 15563 ----------------------- 15564 15565 -- GIMPLE function: gimple gimple_build_return (tree retval) 15566 Build a `GIMPLE_RETURN' statement whose return value is retval. 15567 15568 -- GIMPLE function: tree gimple_return_retval (gimple g) 15569 Return the return value for `GIMPLE_RETURN' `G'. 15570 15571 -- GIMPLE function: void gimple_return_set_retval (gimple g, tree 15572 retval) 15573 Set `RETVAL' to be the return value for `GIMPLE_RETURN' `G'. 15574 15575 15576 File: gccint.info, Node: `GIMPLE_SWITCH', Next: `GIMPLE_TRY', Prev: `GIMPLE_RETURN', Up: Tuple specific accessors 15577 15578 12.7.26 `GIMPLE_SWITCH' 15579 ----------------------- 15580 15581 -- GIMPLE function: gimple gimple_build_switch (tree index, tree 15582 default_label, `VEC'(tree,heap) *args) 15583 Build a `GIMPLE_SWITCH' statement. `INDEX' is the index variable 15584 to switch on, and `DEFAULT_LABEL' represents the default label. 15585 `ARGS' is a vector of `CASE_LABEL_EXPR' trees that contain the 15586 non-default case labels. Each label is a tree of code 15587 `CASE_LABEL_EXPR'. 15588 15589 -- GIMPLE function: unsigned gimple_switch_num_labels (gimple g) 15590 Return the number of labels associated with the switch statement 15591 `G'. 15592 15593 -- GIMPLE function: void gimple_switch_set_num_labels (gimple g, 15594 unsigned nlabels) 15595 Set `NLABELS' to be the number of labels for the switch statement 15596 `G'. 15597 15598 -- GIMPLE function: tree gimple_switch_index (gimple g) 15599 Return the index variable used by the switch statement `G'. 15600 15601 -- GIMPLE function: void gimple_switch_set_index (gimple g, tree index) 15602 Set `INDEX' to be the index variable for switch statement `G'. 15603 15604 -- GIMPLE function: tree gimple_switch_label (gimple g, unsigned index) 15605 Return the label numbered `INDEX'. The default label is 0, followed 15606 by any labels in a switch statement. 15607 15608 -- GIMPLE function: void gimple_switch_set_label (gimple g, unsigned 15609 index, tree label) 15610 Set the label number `INDEX' to `LABEL'. 0 is always the default 15611 label. 15612 15613 -- GIMPLE function: tree gimple_switch_default_label (gimple g) 15614 Return the default label for a switch statement. 15615 15616 -- GIMPLE function: void gimple_switch_set_default_label (gimple g, 15617 tree label) 15618 Set the default label for a switch statement. 15619 15620 15621 File: gccint.info, Node: `GIMPLE_TRY', Next: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_SWITCH', Up: Tuple specific accessors 15622 15623 12.7.27 `GIMPLE_TRY' 15624 -------------------- 15625 15626 -- GIMPLE function: gimple gimple_build_try (gimple_seq eval, 15627 gimple_seq cleanup, unsigned int kind) 15628 Build a `GIMPLE_TRY' statement. `EVAL' is a sequence with the 15629 expression to evaluate. `CLEANUP' is a sequence of statements to 15630 run at clean-up time. `KIND' is the enumeration value 15631 `GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 15632 or `GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 15633 construct. 15634 15635 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 15636 Return the kind of try block represented by `GIMPLE_TRY' `G'. This 15637 is either `GIMPLE_TRY_CATCH' or `GIMPLE_TRY_FINALLY'. 15638 15639 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 15640 Return the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 15641 15642 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 15643 Return the sequence of statements used as the body for `GIMPLE_TRY' 15644 `G'. 15645 15646 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 15647 Return the sequence of statements used as the cleanup body for 15648 `GIMPLE_TRY' `G'. 15649 15650 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 15651 bool catch_is_cleanup) 15652 Set the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 15653 15654 -- GIMPLE function: void gimple_try_set_eval (gimple g, gimple_seq 15655 eval) 15656 Set `EVAL' to be the sequence of statements to use as the body for 15657 `GIMPLE_TRY' `G'. 15658 15659 -- GIMPLE function: void gimple_try_set_cleanup (gimple g, gimple_seq 15660 cleanup) 15661 Set `CLEANUP' to be the sequence of statements to use as the 15662 cleanup body for `GIMPLE_TRY' `G'. 15663 15664 15665 File: gccint.info, Node: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_TRY', Up: Tuple specific accessors 15666 15667 12.7.28 `GIMPLE_WITH_CLEANUP_EXPR' 15668 ---------------------------------- 15669 15670 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 15671 Build a `GIMPLE_WITH_CLEANUP_EXPR' statement. `CLEANUP' is the 15672 clean-up expression. 15673 15674 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 15675 Return the cleanup sequence for cleanup statement `G'. 15676 15677 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 15678 cleanup) 15679 Set `CLEANUP' to be the cleanup sequence for `G'. 15680 15681 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 15682 Return the `CLEANUP_EH_ONLY' flag for a `WCE' tuple. 15683 15684 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, 15685 bool eh_only_p) 15686 Set the `CLEANUP_EH_ONLY' flag for a `WCE' tuple. 15687 15688 15689 File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 15690 15691 12.8 GIMPLE sequences 15692 ===================== 15693 15694 GIMPLE sequences are the tuple equivalent of `STATEMENT_LIST''s used in 15695 `GENERIC'. They are used to chain statements together, and when used 15696 in conjunction with sequence iterators, provide a framework for 15697 iterating through statements. 15698 15699 GIMPLE sequences are of type struct `gimple_sequence', but are more 15700 commonly passed by reference to functions dealing with sequences. The 15701 type for a sequence pointer is `gimple_seq' which is the same as struct 15702 `gimple_sequence' *. When declaring a local sequence, you can define a 15703 local variable of type struct `gimple_sequence'. When declaring a 15704 sequence allocated on the garbage collected heap, use the function 15705 `gimple_seq_alloc' documented below. 15706 15707 There are convenience functions for iterating through sequences in the 15708 section entitled Sequence Iterators. 15709 15710 Below is a list of functions to manipulate and query sequences. 15711 15712 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 15713 g) 15714 Link a gimple statement to the end of the sequence *`SEQ' if `G' is 15715 not `NULL'. If *`SEQ' is `NULL', allocate a sequence before 15716 linking. 15717 15718 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 15719 gimple_seq src) 15720 Append sequence `SRC' to the end of sequence *`DEST' if `SRC' is 15721 not `NULL'. If *`DEST' is `NULL', allocate a new sequence before 15722 appending. 15723 15724 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 15725 Perform a deep copy of sequence `SRC' and return the result. 15726 15727 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 15728 Reverse the order of the statements in the sequence `SEQ'. Return 15729 `SEQ'. 15730 15731 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 15732 Return the first statement in sequence `S'. 15733 15734 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 15735 Return the last statement in sequence `S'. 15736 15737 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 15738 last) 15739 Set the last statement in sequence `S' to the statement in `LAST'. 15740 15741 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 15742 first) 15743 Set the first statement in sequence `S' to the statement in 15744 `FIRST'. 15745 15746 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 15747 Initialize sequence `S' to an empty sequence. 15748 15749 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 15750 Allocate a new sequence in the garbage collected store and return 15751 it. 15752 15753 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 15754 src) 15755 Copy the sequence `SRC' into the sequence `DEST'. 15756 15757 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 15758 Return true if the sequence `S' is empty. 15759 15760 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 15761 Returns the sequence of statements in `BB'. 15762 15763 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 15764 Sets the sequence of statements in `BB' to `SEQ'. 15765 15766 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 15767 Determine whether `SEQ' contains exactly one statement. 15768 15769 15770 File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 15771 15772 12.9 Sequence iterators 15773 ======================= 15774 15775 Sequence iterators are convenience constructs for iterating through 15776 statements in a sequence. Given a sequence `SEQ', here is a typical 15777 use of gimple sequence iterators: 15778 15779 gimple_stmt_iterator gsi; 15780 15781 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 15782 { 15783 gimple g = gsi_stmt (gsi); 15784 /* Do something with gimple statement `G'. */ 15785 } 15786 15787 Backward iterations are possible: 15788 15789 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 15790 15791 Forward and backward iterations on basic blocks are possible with 15792 `gsi_start_bb' and `gsi_last_bb'. 15793 15794 In the documentation below we sometimes refer to enum 15795 `gsi_iterator_update'. The valid options for this enumeration are: 15796 15797 * `GSI_NEW_STMT' Only valid when a single statement is added. Move 15798 the iterator to it. 15799 15800 * `GSI_SAME_STMT' Leave the iterator at the same statement. 15801 15802 * `GSI_CONTINUE_LINKING' Move iterator to whatever position is 15803 suitable for linking other statements in the same direction. 15804 15805 Below is a list of the functions used to manipulate and use statement 15806 iterators. 15807 15808 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 15809 Return a new iterator pointing to the sequence `SEQ''s first 15810 statement. If `SEQ' is empty, the iterator's basic block is 15811 `NULL'. Use `gsi_start_bb' instead when the iterator needs to 15812 always have the correct basic block set. 15813 15814 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 15815 Return a new iterator pointing to the first statement in basic 15816 block `BB'. 15817 15818 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 15819 Return a new iterator initially pointing to the last statement of 15820 sequence `SEQ'. If `SEQ' is empty, the iterator's basic block is 15821 `NULL'. Use `gsi_last_bb' instead when the iterator needs to 15822 always have the correct basic block set. 15823 15824 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 15825 Return a new iterator pointing to the last statement in basic 15826 block `BB'. 15827 15828 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 15829 Return `TRUE' if at the end of `I'. 15830 15831 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 15832 Return `TRUE' if we're one statement before the end of `I'. 15833 15834 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 15835 Advance the iterator to the next gimple statement. 15836 15837 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 15838 Advance the iterator to the previous gimple statement. 15839 15840 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 15841 Return the current stmt. 15842 15843 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 15844 bb) 15845 Return a block statement iterator that points to the first 15846 non-label statement in block `BB'. 15847 15848 -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i) 15849 Return a pointer to the current stmt. 15850 15851 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 15852 Return the basic block associated with this iterator. 15853 15854 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 15855 Return the sequence associated with this iterator. 15856 15857 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 15858 remove_eh_info) 15859 Remove the current stmt from the sequence. The iterator is 15860 updated to point to the next statement. When `REMOVE_EH_INFO' is 15861 true we remove the statement pointed to by iterator `I' from the 15862 `EH' tables. Otherwise we do not modify the `EH' tables. 15863 Generally, `REMOVE_EH_INFO' should be true when the statement is 15864 going to be removed from the `IL' and not reinserted elsewhere. 15865 15866 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 15867 gimple_seq seq, enum gsi_iterator_update mode) 15868 Links the sequence of statements `SEQ' before the statement pointed 15869 by iterator `I'. `MODE' indicates what to do with the iterator 15870 after insertion (see `enum gsi_iterator_update' above). 15871 15872 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 15873 gimple g, enum gsi_iterator_update mode) 15874 Links statement `G' before the statement pointed-to by iterator 15875 `I'. Updates iterator `I' according to `MODE'. 15876 15877 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 15878 gimple_seq seq, enum gsi_iterator_update mode) 15879 Links sequence `SEQ' after the statement pointed-to by iterator 15880 `I'. `MODE' is as in `gsi_insert_after'. 15881 15882 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 15883 gimple g, enum gsi_iterator_update mode) 15884 Links statement `G' after the statement pointed-to by iterator `I'. 15885 `MODE' is as in `gsi_insert_after'. 15886 15887 -- GIMPLE function: gimple_seq gsi_split_seq_after 15888 (gimple_stmt_iterator i) 15889 Move all statements in the sequence after `I' to a new sequence. 15890 Return this new sequence. 15891 15892 -- GIMPLE function: gimple_seq gsi_split_seq_before 15893 (gimple_stmt_iterator *i) 15894 Move all statements in the sequence before `I' to a new sequence. 15895 Return this new sequence. 15896 15897 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 15898 stmt, bool update_eh_info) 15899 Replace the statement pointed-to by `I' to `STMT'. If 15900 `UPDATE_EH_INFO' is true, the exception handling information of 15901 the original statement is moved to the new statement. 15902 15903 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 15904 gimple stmt, enum gsi_iterator_update mode) 15905 Insert statement `STMT' before the statement pointed-to by iterator 15906 `I', update `STMT''s basic block and scan it for new operands. 15907 `MODE' specifies how to update iterator `I' after insertion (see 15908 enum `gsi_iterator_update'). 15909 15910 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 15911 *i, gimple_seq seq, enum gsi_iterator_update mode) 15912 Like `gsi_insert_before', but for all the statements in `SEQ'. 15913 15914 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 15915 gimple stmt, enum gsi_iterator_update mode) 15916 Insert statement `STMT' after the statement pointed-to by iterator 15917 `I', update `STMT''s basic block and scan it for new operands. 15918 `MODE' specifies how to update iterator `I' after insertion (see 15919 enum `gsi_iterator_update'). 15920 15921 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator 15922 *i, gimple_seq seq, enum gsi_iterator_update mode) 15923 Like `gsi_insert_after', but for all the statements in `SEQ'. 15924 15925 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 15926 Finds iterator for `STMT'. 15927 15928 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 15929 gimple_stmt_iterator *to) 15930 Move the statement at `FROM' so it comes right after the statement 15931 at `TO'. 15932 15933 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 15934 gimple_stmt_iterator *to) 15935 Move the statement at `FROM' so it comes right before the statement 15936 at `TO'. 15937 15938 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 15939 *from, basic_block bb) 15940 Move the statement at `FROM' to the end of basic block `BB'. 15941 15942 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 15943 Add `STMT' to the pending list of edge `E'. No actual insertion is 15944 made until a call to `gsi_commit_edge_inserts'() is made. 15945 15946 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 15947 seq) 15948 Add the sequence of statements in `SEQ' to the pending list of edge 15949 `E'. No actual insertion is made until a call to 15950 `gsi_commit_edge_inserts'() is made. 15951 15952 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 15953 gimple stmt) 15954 Similar to `gsi_insert_on_edge'+`gsi_commit_edge_inserts'. If a 15955 new block has to be created, it is returned. 15956 15957 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 15958 basic_block *new_bb) 15959 Commit insertions pending at edge `E'. If a new block is created, 15960 set `NEW_BB' to this block, otherwise set it to `NULL'. 15961 15962 -- GIMPLE function: void gsi_commit_edge_inserts (void) 15963 This routine will commit all pending edge insertions, creating any 15964 new basic blocks which are necessary. 15965 15966 15967 File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 15968 15969 12.10 Adding a new GIMPLE statement code 15970 ======================================== 15971 15972 The first step in adding a new GIMPLE statement code, is modifying the 15973 file `gimple.def', which contains all the GIMPLE codes. Then you must 15974 add a corresponding structure, and an entry in `union 15975 gimple_statement_d', both of which are located in `gimple.h'. This in 15976 turn, will require you to add a corresponding `GTY' tag in 15977 `gsstruct.def', and code to handle this tag in `gss_for_code' which is 15978 located in `gimple.c'. 15979 15980 In order for the garbage collector to know the size of the structure 15981 you created in `gimple.h', you need to add a case to handle your new 15982 GIMPLE statement in `gimple_size' which is located in `gimple.c'. 15983 15984 You will probably want to create a function to build the new gimple 15985 statement in `gimple.c'. The function should be called 15986 `gimple_build_NEW-TUPLE-NAME', and should return the new tuple of type 15987 gimple. 15988 15989 If your new statement requires accessors for any members or operands 15990 it may have, put simple inline accessors in `gimple.h' and any 15991 non-trivial accessors in `gimple.c' with a corresponding prototype in 15992 `gimple.h'. 15993 15994 15995 File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 15996 15997 12.11 Statement and operand traversals 15998 ====================================== 15999 16000 There are two functions available for walking statements and sequences: 16001 `walk_gimple_stmt' and `walk_gimple_seq', accordingly, and a third 16002 function for walking the operands in a statement: `walk_gimple_op'. 16003 16004 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 16005 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 16006 walk_stmt_info *wi) 16007 This function is used to walk the current statement in `GSI', 16008 optionally using traversal state stored in `WI'. If `WI' is 16009 `NULL', no state is kept during the traversal. 16010 16011 The callback `CALLBACK_STMT' is called. If `CALLBACK_STMT' returns 16012 true, it means that the callback function has handled all the 16013 operands of the statement and it is not necessary to walk its 16014 operands. 16015 16016 If `CALLBACK_STMT' is `NULL' or it returns false, `CALLBACK_OP' is 16017 called on each operand of the statement via `walk_gimple_op'. If 16018 `walk_gimple_op' returns non-`NULL' for any operand, the remaining 16019 operands are not scanned. 16020 16021 The return value is that returned by the last call to 16022 `walk_gimple_op', or `NULL_TREE' if no `CALLBACK_OP' is specified. 16023 16024 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 16025 callback_op, struct walk_stmt_info *wi) 16026 Use this function to walk the operands of statement `STMT'. Every 16027 operand is walked via `walk_tree' with optional state information 16028 in `WI'. 16029 16030 `CALLBACK_OP' is called on each operand of `STMT' via `walk_tree'. 16031 Additional parameters to `walk_tree' must be stored in `WI'. For 16032 each operand `OP', `walk_tree' is called as: 16033 16034 walk_tree (&`OP', `CALLBACK_OP', `WI', `PSET') 16035 16036 If `CALLBACK_OP' returns non-`NULL' for an operand, the remaining 16037 operands are not scanned. The return value is that returned by 16038 the last call to `walk_tree', or `NULL_TREE' if no `CALLBACK_OP' is 16039 specified. 16040 16041 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 16042 callback_stmt, walk_tree_fn callback_op, struct 16043 walk_stmt_info *wi) 16044 This function walks all the statements in the sequence `SEQ' 16045 calling `walk_gimple_stmt' on each one. `WI' is as in 16046 `walk_gimple_stmt'. If `walk_gimple_stmt' returns non-`NULL', the 16047 walk is stopped and the value returned. Otherwise, all the 16048 statements are walked and `NULL_TREE' returned. 16049 16050 16051 File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 16052 16053 13 Analysis and Optimization of GIMPLE tuples 16054 ********************************************* 16055 16056 GCC uses three main intermediate languages to represent the program 16057 during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 16058 language-independent representation generated by each front end. It is 16059 used to serve as an interface between the parser and optimizer. 16060 GENERIC is a common representation that is able to represent programs 16061 written in all the languages supported by GCC. 16062 16063 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 16064 target and language independent optimizations (e.g., inlining, constant 16065 propagation, tail call elimination, redundancy elimination, etc). Much 16066 like GENERIC, GIMPLE is a language independent, tree based 16067 representation. However, it differs from GENERIC in that the GIMPLE 16068 grammar is more restrictive: expressions contain no more than 3 16069 operands (except function calls), it has no control flow structures and 16070 expressions with side-effects are only allowed on the right hand side 16071 of assignments. See the chapter describing GENERIC and GIMPLE for more 16072 details. 16073 16074 This chapter describes the data structures and functions used in the 16075 GIMPLE optimizers (also known as "tree optimizers" or "middle end"). 16076 In particular, it focuses on all the macros, data structures, functions 16077 and programming constructs needed to implement optimization passes for 16078 GIMPLE. 16079 16080 * Menu: 16081 16082 * Annotations:: Attributes for variables. 16083 * SSA Operands:: SSA names referenced by GIMPLE statements. 16084 * SSA:: Static Single Assignment representation. 16085 * Alias analysis:: Representing aliased loads and stores. 16086 * Memory model:: Memory model used by the middle-end. 16087 16088 16089 File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 16090 16091 13.1 Annotations 16092 ================ 16093 16094 The optimizers need to associate attributes with variables during the 16095 optimization process. For instance, we need to know whether a variable 16096 has aliases. All these attributes are stored in data structures called 16097 annotations which are then linked to the field `ann' in `struct 16098 tree_common'. 16099 16100 Presently, we define annotations for variables (`var_ann_t'). 16101 Annotations are defined and documented in `tree-flow.h'. 16102 16103 16104 File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 16105 16106 13.2 SSA Operands 16107 ================= 16108 16109 Almost every GIMPLE statement will contain a reference to a variable or 16110 memory location. Since statements come in different shapes and sizes, 16111 their operands are going to be located at various spots inside the 16112 statement's tree. To facilitate access to the statement's operands, 16113 they are organized into lists associated inside each statement's 16114 annotation. Each element in an operand list is a pointer to a 16115 `VAR_DECL', `PARM_DECL' or `SSA_NAME' tree node. This provides a very 16116 convenient way of examining and replacing operands. 16117 16118 Data flow analysis and optimization is done on all tree nodes 16119 representing variables. Any node for which `SSA_VAR_P' returns nonzero 16120 is considered when scanning statement operands. However, not all 16121 `SSA_VAR_P' variables are processed in the same way. For the purposes 16122 of optimization, we need to distinguish between references to local 16123 scalar variables and references to globals, statics, structures, 16124 arrays, aliased variables, etc. The reason is simple, the compiler can 16125 gather complete data flow information for a local scalar. On the other 16126 hand, a global variable may be modified by a function call, it may not 16127 be possible to keep track of all the elements of an array or the fields 16128 of a structure, etc. 16129 16130 The operand scanner gathers two kinds of operands: "real" and 16131 "virtual". An operand for which `is_gimple_reg' returns true is 16132 considered real, otherwise it is a virtual operand. We also 16133 distinguish between uses and definitions. An operand is used if its 16134 value is loaded by the statement (e.g., the operand at the RHS of an 16135 assignment). If the statement assigns a new value to the operand, the 16136 operand is considered a definition (e.g., the operand at the LHS of an 16137 assignment). 16138 16139 Virtual and real operands also have very different data flow 16140 properties. Real operands are unambiguous references to the full 16141 object that they represent. For instance, given 16142 16143 { 16144 int a, b; 16145 a = b 16146 } 16147 16148 Since `a' and `b' are non-aliased locals, the statement `a = b' will 16149 have one real definition and one real use because variable `a' is 16150 completely modified with the contents of variable `b'. Real definition 16151 are also known as "killing definitions". Similarly, the use of `b' 16152 reads all its bits. 16153 16154 In contrast, virtual operands are used with variables that can have a 16155 partial or ambiguous reference. This includes structures, arrays, 16156 globals, and aliased variables. In these cases, we have two types of 16157 definitions. For globals, structures, and arrays, we can determine from 16158 a statement whether a variable of these types has a killing definition. 16159 If the variable does, then the statement is marked as having a "must 16160 definition" of that variable. However, if a statement is only defining 16161 a part of the variable (i.e. a field in a structure), or if we know 16162 that a statement might define the variable but we cannot say for sure, 16163 then we mark that statement as having a "may definition". For 16164 instance, given 16165 16166 { 16167 int a, b, *p; 16168 16169 if (...) 16170 p = &a; 16171 else 16172 p = &b; 16173 *p = 5; 16174 return *p; 16175 } 16176 16177 The assignment `*p = 5' may be a definition of `a' or `b'. If we 16178 cannot determine statically where `p' is pointing to at the time of the 16179 store operation, we create virtual definitions to mark that statement 16180 as a potential definition site for `a' and `b'. Memory loads are 16181 similarly marked with virtual use operands. Virtual operands are shown 16182 in tree dumps right before the statement that contains them. To 16183 request a tree dump with virtual operands, use the `-vops' option to 16184 `-fdump-tree': 16185 16186 { 16187 int a, b, *p; 16188 16189 if (...) 16190 p = &a; 16191 else 16192 p = &b; 16193 # a = VDEF <a> 16194 # b = VDEF <b> 16195 *p = 5; 16196 16197 # VUSE <a> 16198 # VUSE <b> 16199 return *p; 16200 } 16201 16202 Notice that `VDEF' operands have two copies of the referenced 16203 variable. This indicates that this is not a killing definition of that 16204 variable. In this case we refer to it as a "may definition" or 16205 "aliased store". The presence of the second copy of the variable in 16206 the `VDEF' operand will become important when the function is converted 16207 into SSA form. This will be used to link all the non-killing 16208 definitions to prevent optimizations from making incorrect assumptions 16209 about them. 16210 16211 Operands are updated as soon as the statement is finished via a call 16212 to `update_stmt'. If statement elements are changed via `SET_USE' or 16213 `SET_DEF', then no further action is required (i.e., those macros take 16214 care of updating the statement). If changes are made by manipulating 16215 the statement's tree directly, then a call must be made to 16216 `update_stmt' when complete. Calling one of the `bsi_insert' routines 16217 or `bsi_replace' performs an implicit call to `update_stmt'. 16218 16219 13.2.1 Operand Iterators And Access Routines 16220 -------------------------------------------- 16221 16222 Operands are collected by `tree-ssa-operands.c'. They are stored 16223 inside each statement's annotation and can be accessed through either 16224 the operand iterators or an access routine. 16225 16226 The following access routines are available for examining operands: 16227 16228 1. `SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 16229 NULL unless there is exactly one operand matching the specified 16230 flags. If there is exactly one operand, the operand is returned 16231 as either a `tree', `def_operand_p', or `use_operand_p'. 16232 16233 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 16234 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 16235 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 16236 16237 2. `ZERO_SSA_OPERANDS': This macro returns true if there are no 16238 operands matching the specified flags. 16239 16240 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 16241 return; 16242 16243 3. `NUM_SSA_OPERANDS': This macro Returns the number of operands 16244 matching 'flags'. This actually executes a loop to perform the 16245 count, so only use this if it is really needed. 16246 16247 int count = NUM_SSA_OPERANDS (stmt, flags) 16248 16249 If you wish to iterate over some or all operands, use the 16250 `FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 16251 all the operands for a statement: 16252 16253 void 16254 print_ops (tree stmt) 16255 { 16256 ssa_op_iter; 16257 tree var; 16258 16259 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 16260 print_generic_expr (stderr, var, TDF_SLIM); 16261 } 16262 16263 How to choose the appropriate iterator: 16264 16265 1. Determine whether you are need to see the operand pointers, or 16266 just the trees, and choose the appropriate macro: 16267 16268 Need Macro: 16269 ---- ------- 16270 use_operand_p FOR_EACH_SSA_USE_OPERAND 16271 def_operand_p FOR_EACH_SSA_DEF_OPERAND 16272 tree FOR_EACH_SSA_TREE_OPERAND 16273 16274 2. You need to declare a variable of the type you are interested in, 16275 and an ssa_op_iter structure which serves as the loop controlling 16276 variable. 16277 16278 3. Determine which operands you wish to use, and specify the flags of 16279 those you are interested in. They are documented in 16280 `tree-ssa-operands.h': 16281 16282 #define SSA_OP_USE 0x01 /* Real USE operands. */ 16283 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 16284 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 16285 #define SSA_OP_VMAYUSE 0x08 /* USE portion of VDEFS. */ 16286 #define SSA_OP_VDEF 0x10 /* DEF portion of VDEFS. */ 16287 16288 /* These are commonly grouped operand flags. */ 16289 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE | SSA_OP_VMAYUSE) 16290 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 16291 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 16292 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 16293 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 16294 16295 So if you want to look at the use pointers for all the `USE' and 16296 `VUSE' operands, you would do something like: 16297 16298 use_operand_p use_p; 16299 ssa_op_iter iter; 16300 16301 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 16302 { 16303 process_use_ptr (use_p); 16304 } 16305 16306 The `TREE' macro is basically the same as the `USE' and `DEF' macros, 16307 only with the use or def dereferenced via `USE_FROM_PTR (use_p)' and 16308 `DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use 16309 and defs flags can be mixed. 16310 16311 tree var; 16312 ssa_op_iter iter; 16313 16314 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 16315 { 16316 print_generic_expr (stderr, var, TDF_SLIM); 16317 } 16318 16319 `VDEF's are broken into two flags, one for the `DEF' portion 16320 (`SSA_OP_VDEF') and one for the USE portion (`SSA_OP_VMAYUSE'). If all 16321 you want to look at are the `VDEF's together, there is a fourth 16322 iterator macro for this, which returns both a def_operand_p and a 16323 use_operand_p for each `VDEF' in the statement. Note that you don't 16324 need any flags for this one. 16325 16326 use_operand_p use_p; 16327 def_operand_p def_p; 16328 ssa_op_iter iter; 16329 16330 FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter) 16331 { 16332 my_code; 16333 } 16334 16335 There are many examples in the code as well, as well as the 16336 documentation in `tree-ssa-operands.h'. 16337 16338 There are also a couple of variants on the stmt iterators regarding PHI 16339 nodes. 16340 16341 `FOR_EACH_PHI_ARG' Works exactly like `FOR_EACH_SSA_USE_OPERAND', 16342 except it works over `PHI' arguments instead of statement operands. 16343 16344 /* Look at every virtual PHI use. */ 16345 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 16346 { 16347 my_code; 16348 } 16349 16350 /* Look at every real PHI use. */ 16351 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 16352 my_code; 16353 16354 /* Look at every PHI use. */ 16355 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 16356 my_code; 16357 16358 `FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 16359 `FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 16360 statement or a `PHI' node. These should be used when it is appropriate 16361 but they are not quite as efficient as the individual `FOR_EACH_PHI' 16362 and `FOR_EACH_SSA' routines. 16363 16364 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 16365 { 16366 my_code; 16367 } 16368 16369 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 16370 { 16371 my_code; 16372 } 16373 16374 13.2.2 Immediate Uses 16375 --------------------- 16376 16377 Immediate use information is now always available. Using the immediate 16378 use iterators, you may examine every use of any `SSA_NAME'. For 16379 instance, to change each use of `ssa_var' to `ssa_var2' and call 16380 fold_stmt on each stmt after that is done: 16381 16382 use_operand_p imm_use_p; 16383 imm_use_iterator iterator; 16384 tree ssa_var, stmt; 16385 16386 16387 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 16388 { 16389 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 16390 SET_USE (imm_use_p, ssa_var_2); 16391 fold_stmt (stmt); 16392 } 16393 16394 There are 2 iterators which can be used. `FOR_EACH_IMM_USE_FAST' is 16395 used when the immediate uses are not changed, i.e., you are looking at 16396 the uses, but not setting them. 16397 16398 If they do get changed, then care must be taken that things are not 16399 changed under the iterators, so use the `FOR_EACH_IMM_USE_STMT' and 16400 `FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 16401 sanity of the use list by moving all the uses for a statement into a 16402 controlled position, and then iterating over those uses. Then the 16403 optimization can manipulate the stmt when all the uses have been 16404 processed. This is a little slower than the FAST version since it adds 16405 a placeholder element and must sort through the list a bit for each 16406 statement. This placeholder element must be also be removed if the 16407 loop is terminated early. The macro `BREAK_FROM_IMM_USE_SAFE' is 16408 provided to do this : 16409 16410 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 16411 { 16412 if (stmt == last_stmt) 16413 BREAK_FROM_SAFE_IMM_USE (iter); 16414 16415 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 16416 SET_USE (imm_use_p, ssa_var_2); 16417 fold_stmt (stmt); 16418 } 16419 16420 There are checks in `verify_ssa' which verify that the immediate use 16421 list is up to date, as well as checking that an optimization didn't 16422 break from the loop without using this macro. It is safe to simply 16423 'break'; from a `FOR_EACH_IMM_USE_FAST' traverse. 16424 16425 Some useful functions and macros: 16426 1. `has_zero_uses (ssa_var)' : Returns true if there are no uses of 16427 `ssa_var'. 16428 16429 2. `has_single_use (ssa_var)' : Returns true if there is only a 16430 single use of `ssa_var'. 16431 16432 3. `single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 16433 Returns true if there is only a single use of `ssa_var', and also 16434 returns the use pointer and statement it occurs in, in the second 16435 and third parameters. 16436 16437 4. `num_imm_uses (ssa_var)' : Returns the number of immediate uses of 16438 `ssa_var'. It is better not to use this if possible since it simply 16439 utilizes a loop to count the uses. 16440 16441 5. `PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a `PHI' 16442 node, return the index number for the use. An assert is triggered 16443 if the use isn't located in a `PHI' node. 16444 16445 6. `USE_STMT (use_p)' : Return the statement a use occurs in. 16446 16447 Note that uses are not put into an immediate use list until their 16448 statement is actually inserted into the instruction stream via a 16449 `bsi_*' routine. 16450 16451 It is also still possible to utilize lazy updating of statements, but 16452 this should be used only when absolutely required. Both alias analysis 16453 and the dominator optimizations currently do this. 16454 16455 When lazy updating is being used, the immediate use information is out 16456 of date and cannot be used reliably. Lazy updating is achieved by 16457 simply marking statements modified via calls to `mark_stmt_modified' 16458 instead of `update_stmt'. When lazy updating is no longer required, 16459 all the modified statements must have `update_stmt' called in order to 16460 bring them up to date. This must be done before the optimization is 16461 finished, or `verify_ssa' will trigger an abort. 16462 16463 This is done with a simple loop over the instruction stream: 16464 block_stmt_iterator bsi; 16465 basic_block bb; 16466 FOR_EACH_BB (bb) 16467 { 16468 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 16469 update_stmt_if_modified (bsi_stmt (bsi)); 16470 } 16471 16472 16473 File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 16474 16475 13.3 Static Single Assignment 16476 ============================= 16477 16478 Most of the tree optimizers rely on the data flow information provided 16479 by the Static Single Assignment (SSA) form. We implement the SSA form 16480 as described in `R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 16481 Zadeck. Efficiently Computing Static Single Assignment Form and the 16482 Control Dependence Graph. ACM Transactions on Programming Languages 16483 and Systems, 13(4):451-490, October 1991'. 16484 16485 The SSA form is based on the premise that program variables are 16486 assigned in exactly one location in the program. Multiple assignments 16487 to the same variable create new versions of that variable. Naturally, 16488 actual programs are seldom in SSA form initially because variables tend 16489 to be assigned multiple times. The compiler modifies the program 16490 representation so that every time a variable is assigned in the code, a 16491 new version of the variable is created. Different versions of the same 16492 variable are distinguished by subscripting the variable name with its 16493 version number. Variables used in the right-hand side of expressions 16494 are renamed so that their version number matches that of the most 16495 recent assignment. 16496 16497 We represent variable versions using `SSA_NAME' nodes. The renaming 16498 process in `tree-ssa.c' wraps every real and virtual operand with an 16499 `SSA_NAME' node which contains the version number and the statement 16500 that created the `SSA_NAME'. Only definitions and virtual definitions 16501 may create new `SSA_NAME' nodes. 16502 16503 Sometimes, flow of control makes it impossible to determine the most 16504 recent version of a variable. In these cases, the compiler inserts an 16505 artificial definition for that variable called "PHI function" or "PHI 16506 node". This new definition merges all the incoming versions of the 16507 variable to create a new name for it. For instance, 16508 16509 if (...) 16510 a_1 = 5; 16511 else if (...) 16512 a_2 = 2; 16513 else 16514 a_3 = 13; 16515 16516 # a_4 = PHI <a_1, a_2, a_3> 16517 return a_4; 16518 16519 Since it is not possible to determine which of the three branches will 16520 be taken at runtime, we don't know which of `a_1', `a_2' or `a_3' to 16521 use at the return statement. So, the SSA renamer creates a new version 16522 `a_4' which is assigned the result of "merging" `a_1', `a_2' and `a_3'. 16523 Hence, PHI nodes mean "one of these operands. I don't know which". 16524 16525 The following macros can be used to examine PHI nodes 16526 16527 -- Macro: PHI_RESULT (PHI) 16528 Returns the `SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 16529 16530 -- Macro: PHI_NUM_ARGS (PHI) 16531 Returns the number of arguments in PHI. This number is exactly 16532 the number of incoming edges to the basic block holding PHI. 16533 16534 -- Macro: PHI_ARG_ELT (PHI, I) 16535 Returns a tuple representing the Ith argument of PHI. Each 16536 element of this tuple contains an `SSA_NAME' VAR and the incoming 16537 edge through which VAR flows. 16538 16539 -- Macro: PHI_ARG_EDGE (PHI, I) 16540 Returns the incoming edge for the Ith argument of PHI. 16541 16542 -- Macro: PHI_ARG_DEF (PHI, I) 16543 Returns the `SSA_NAME' for the Ith argument of PHI. 16544 16545 13.3.1 Preserving the SSA form 16546 ------------------------------ 16547 16548 Some optimization passes make changes to the function that invalidate 16549 the SSA property. This can happen when a pass has added new symbols or 16550 changed the program so that variables that were previously aliased 16551 aren't anymore. Whenever something like this happens, the affected 16552 symbols must be renamed into SSA form again. Transformations that emit 16553 new code or replicate existing statements will also need to update the 16554 SSA form. 16555 16556 Since GCC implements two different SSA forms for register and virtual 16557 variables, keeping the SSA form up to date depends on whether you are 16558 updating register or virtual names. In both cases, the general idea 16559 behind incremental SSA updates is similar: when new SSA names are 16560 created, they typically are meant to replace other existing names in 16561 the program. 16562 16563 For instance, given the following code: 16564 16565 1 L0: 16566 2 x_1 = PHI (0, x_5) 16567 3 if (x_1 < 10) 16568 4 if (x_1 > 7) 16569 5 y_2 = 0 16570 6 else 16571 7 y_3 = x_1 + x_7 16572 8 endif 16573 9 x_5 = x_1 + 1 16574 10 goto L0; 16575 11 endif 16576 16577 Suppose that we insert new names `x_10' and `x_11' (lines `4' and `8'). 16578 16579 1 L0: 16580 2 x_1 = PHI (0, x_5) 16581 3 if (x_1 < 10) 16582 4 x_10 = ... 16583 5 if (x_1 > 7) 16584 6 y_2 = 0 16585 7 else 16586 8 x_11 = ... 16587 9 y_3 = x_1 + x_7 16588 10 endif 16589 11 x_5 = x_1 + 1 16590 12 goto L0; 16591 13 endif 16592 16593 We want to replace all the uses of `x_1' with the new definitions of 16594 `x_10' and `x_11'. Note that the only uses that should be replaced are 16595 those at lines `5', `9' and `11'. Also, the use of `x_7' at line `9' 16596 should _not_ be replaced (this is why we cannot just mark symbol `x' for 16597 renaming). 16598 16599 Additionally, we may need to insert a PHI node at line `11' because 16600 that is a merge point for `x_10' and `x_11'. So the use of `x_1' at 16601 line `11' will be replaced with the new PHI node. The insertion of PHI 16602 nodes is optional. They are not strictly necessary to preserve the SSA 16603 form, and depending on what the caller inserted, they may not even be 16604 useful for the optimizers. 16605 16606 Updating the SSA form is a two step process. First, the pass has to 16607 identify which names need to be updated and/or which symbols need to be 16608 renamed into SSA form for the first time. When new names are 16609 introduced to replace existing names in the program, the mapping 16610 between the old and the new names are registered by calling 16611 `register_new_name_mapping' (note that if your pass creates new code by 16612 duplicating basic blocks, the call to `tree_duplicate_bb' will set up 16613 the necessary mappings automatically). 16614 16615 After the replacement mappings have been registered and new symbols 16616 marked for renaming, a call to `update_ssa' makes the registered 16617 changes. This can be done with an explicit call or by creating `TODO' 16618 flags in the `tree_opt_pass' structure for your pass. There are 16619 several `TODO' flags that control the behavior of `update_ssa': 16620 16621 * `TODO_update_ssa'. Update the SSA form inserting PHI nodes for 16622 newly exposed symbols and virtual names marked for updating. When 16623 updating real names, only insert PHI nodes for a real name `O_j' 16624 in blocks reached by all the new and old definitions for `O_j'. 16625 If the iterated dominance frontier for `O_j' is not pruned, we may 16626 end up inserting PHI nodes in blocks that have one or more edges 16627 with no incoming definition for `O_j'. This would lead to 16628 uninitialized warnings for `O_j''s symbol. 16629 16630 * `TODO_update_ssa_no_phi'. Update the SSA form without inserting 16631 any new PHI nodes at all. This is used by passes that have either 16632 inserted all the PHI nodes themselves or passes that need only to 16633 patch use-def and def-def chains for virtuals (e.g., DCE). 16634 16635 * `TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 16636 needed. No pruning of the IDF is done. This is used by passes 16637 that need the PHI nodes for `O_j' even if it means that some 16638 arguments will come from the default definition of `O_j''s symbol 16639 (e.g., `pass_linear_transform'). 16640 16641 WARNING: If you need to use this flag, chances are that your pass 16642 may be doing something wrong. Inserting PHI nodes for an old name 16643 where not all edges carry a new replacement may lead to silent 16644 codegen errors or spurious uninitialized warnings. 16645 16646 * `TODO_update_ssa_only_virtuals'. Passes that update the SSA form 16647 on their own may want to delegate the updating of virtual names to 16648 the generic updater. Since FUD chains are easier to maintain, 16649 this simplifies the work they need to do. NOTE: If this flag is 16650 used, any OLD->NEW mappings for real names are explicitly 16651 destroyed and only the symbols marked for renaming are processed. 16652 16653 13.3.2 Preserving the virtual SSA form 16654 -------------------------------------- 16655 16656 The virtual SSA form is harder to preserve than the non-virtual SSA form 16657 mainly because the set of virtual operands for a statement may change at 16658 what some would consider unexpected times. In general, statement 16659 modifications should be bracketed between calls to `push_stmt_changes' 16660 and `pop_stmt_changes'. For example, 16661 16662 munge_stmt (tree stmt) 16663 { 16664 push_stmt_changes (&stmt); 16665 ... rewrite STMT ... 16666 pop_stmt_changes (&stmt); 16667 } 16668 16669 The call to `push_stmt_changes' saves the current state of the 16670 statement operands and the call to `pop_stmt_changes' compares the 16671 saved state with the current one and does the appropriate symbol 16672 marking for the SSA renamer. 16673 16674 It is possible to modify several statements at a time, provided that 16675 `push_stmt_changes' and `pop_stmt_changes' are called in LIFO order, as 16676 when processing a stack of statements. 16677 16678 Additionally, if the pass discovers that it did not need to make 16679 changes to the statement after calling `push_stmt_changes', it can 16680 simply discard the topmost change buffer by calling 16681 `discard_stmt_changes'. This will avoid the expensive operand re-scan 16682 operation and the buffer comparison that determines if symbols need to 16683 be marked for renaming. 16684 16685 13.3.3 Examining `SSA_NAME' nodes 16686 --------------------------------- 16687 16688 The following macros can be used to examine `SSA_NAME' nodes 16689 16690 -- Macro: SSA_NAME_DEF_STMT (VAR) 16691 Returns the statement S that creates the `SSA_NAME' VAR. If S is 16692 an empty statement (i.e., `IS_EMPTY_STMT (S)' returns `true'), it 16693 means that the first reference to this variable is a USE or a VUSE. 16694 16695 -- Macro: SSA_NAME_VERSION (VAR) 16696 Returns the version number of the `SSA_NAME' object VAR. 16697 16698 13.3.4 Walking use-def chains 16699 ----------------------------- 16700 16701 -- Tree SSA function: void walk_use_def_chains (VAR, FN, DATA) 16702 Walks use-def chains starting at the `SSA_NAME' node VAR. Calls 16703 function FN at each reaching definition found. Function FN takes 16704 three arguments: VAR, its defining statement (DEF_STMT) and a 16705 generic pointer to whatever state information that FN may want to 16706 maintain (DATA). Function FN is able to stop the walk by 16707 returning `true', otherwise in order to continue the walk, FN 16708 should return `false'. 16709 16710 Note, that if DEF_STMT is a `PHI' node, the semantics are slightly 16711 different. For each argument ARG of the PHI node, this function 16712 will: 16713 16714 1. Walk the use-def chains for ARG. 16715 16716 2. Call `FN (ARG, PHI, DATA)'. 16717 16718 Note how the first argument to FN is no longer the original 16719 variable VAR, but the PHI argument currently being examined. If 16720 FN wants to get at VAR, it should call `PHI_RESULT' (PHI). 16721 16722 13.3.5 Walking the dominator tree 16723 --------------------------------- 16724 16725 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 16726 This function walks the dominator tree for the current CFG calling 16727 a set of callback functions defined in STRUCT DOM_WALK_DATA in 16728 `domwalk.h'. The call back functions you need to define give you 16729 hooks to execute custom code at various points during traversal: 16730 16731 1. Once to initialize any local data needed while processing BB 16732 and its children. This local data is pushed into an internal 16733 stack which is automatically pushed and popped as the walker 16734 traverses the dominator tree. 16735 16736 2. Once before traversing all the statements in the BB. 16737 16738 3. Once for every statement inside BB. 16739 16740 4. Once after traversing all the statements and before recursing 16741 into BB's dominator children. 16742 16743 5. It then recurses into all the dominator children of BB. 16744 16745 6. After recursing into all the dominator children of BB it can, 16746 optionally, traverse every statement in BB again (i.e., 16747 repeating steps 2 and 3). 16748 16749 7. Once after walking the statements in BB and BB's dominator 16750 children. At this stage, the block local data stack is 16751 popped. 16752 16753 16754 File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 16755 16756 13.4 Alias analysis 16757 =================== 16758 16759 Alias analysis in GIMPLE SSA form consists of two pieces. First the 16760 virtual SSA web ties conflicting memory accesses and provides a SSA 16761 use-def chain and SSA immediate-use chains for walking possibly 16762 dependent memory accesses. Second an alias-oracle can be queried to 16763 disambiguate explicit and implicit memory references. 16764 16765 1. Memory SSA form. 16766 16767 All statements that may use memory have exactly one accompanied 16768 use of a virtual SSA name that represents the state of memory at 16769 the given point in the IL. 16770 16771 All statements that may define memory have exactly one accompanied 16772 definition of a virtual SSA name using the previous state of memory 16773 and defining the new state of memory after the given point in the 16774 IL. 16775 16776 int i; 16777 int foo (void) 16778 { 16779 # .MEM_3 = VDEF <.MEM_2(D)> 16780 i = 1; 16781 # VUSE <.MEM_3> 16782 return i; 16783 } 16784 16785 The virtual SSA names in this case are `.MEM_2(D)' and `.MEM_3'. 16786 The store to the global variable `i' defines `.MEM_3' invalidating 16787 `.MEM_2(D)'. The load from `i' uses that new state `.MEM_3'. 16788 16789 The virtual SSA web serves as constraints to SSA optimizers 16790 preventing illegitimate code-motion and optimization. It also 16791 provides a way to walk related memory statements. 16792 16793 2. Points-to and escape analysis. 16794 16795 Points-to analysis builds a set of constraints from the GIMPLE SSA 16796 IL representing all pointer operations and facts we do or do not 16797 know about pointers. Solving this set of constraints yields a 16798 conservatively correct solution for each pointer variable in the 16799 program (though we are only interested in SSA name pointers) as to 16800 what it may possibly point to. 16801 16802 This points-to solution for a given SSA name pointer is stored in 16803 the `pt_solution' sub-structure of the `SSA_NAME_PTR_INFO' record. 16804 The following accessor functions are available: 16805 16806 * `pt_solution_includes' 16807 16808 * `pt_solutions_intersect' 16809 16810 Points-to analysis also computes the solution for two special set 16811 of pointers, `ESCAPED' and `CALLUSED'. Those represent all memory 16812 that has escaped the scope of analysis or that is used by pure or 16813 nested const calls. 16814 16815 3. Type-based alias analysis 16816 16817 Type-based alias analysis is frontend dependent though generic 16818 support is provided by the middle-end in `alias.c'. TBAA code is 16819 used by both tree optimizers and RTL optimizers. 16820 16821 Every language that wishes to perform language-specific alias 16822 analysis should define a function that computes, given a `tree' 16823 node, an alias set for the node. Nodes in different alias sets 16824 are not allowed to alias. For an example, see the C front-end 16825 function `c_get_alias_set'. 16826 16827 4. Tree alias-oracle 16828 16829 The tree alias-oracle provides means to disambiguate two memory 16830 references and memory references against statements. The following 16831 queries are available: 16832 16833 * `refs_may_alias_p' 16834 16835 * `ref_maybe_used_by_stmt_p' 16836 16837 * `stmt_may_clobber_ref_p' 16838 16839 In addition to those two kind of statement walkers are available 16840 walking statements related to a reference ref. 16841 `walk_non_aliased_vuses' walks over dominating memory defining 16842 statements and calls back if the statement does not clobber ref 16843 providing the non-aliased VUSE. The walk stops at the first 16844 clobbering statement or if asked to. `walk_aliased_vdefs' walks 16845 over dominating memory defining statements and calls back on each 16846 statement clobbering ref providing its aliasing VDEF. The walk 16847 stops if asked to. 16848 16849 16850 16851 File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 16852 16853 13.5 Memory model 16854 ================= 16855 16856 The memory model used by the middle-end models that of the C/C++ 16857 languages. The middle-end has the notion of an effective type of a 16858 memory region which is used for type-based alias analysis. 16859 16860 The following is a refinement of ISO C99 6.5/6, clarifying the block 16861 copy case to follow common sense and extending the concept of a dynamic 16862 effective type to objects with a declared type as required for C++. 16863 16864 The effective type of an object for an access to its stored value is 16865 the declared type of the object or the effective type determined by 16866 a previous store to it. If a value is stored into an object through 16867 an lvalue having a type that is not a character type, then the 16868 type of the lvalue becomes the effective type of the object for that 16869 access and for subsequent accesses that do not modify the stored value. 16870 If a value is copied into an object using `memcpy' or `memmove', 16871 or is copied as an array of character type, then the effective type 16872 of the modified object for that access and for subsequent accesses that 16873 do not modify the value is undetermined. For all other accesses to an 16874 object, the effective type of the object is simply the type of the 16875 lvalue used for the access. 16876 16877 16878 File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 16879 16880 14 Analysis and Representation of Loops 16881 *************************************** 16882 16883 GCC provides extensive infrastructure for work with natural loops, i.e., 16884 strongly connected components of CFG with only one entry block. This 16885 chapter describes representation of loops in GCC, both on GIMPLE and in 16886 RTL, as well as the interfaces to loop-related analyses (induction 16887 variable analysis and number of iterations analysis). 16888 16889 * Menu: 16890 16891 * Loop representation:: Representation and analysis of loops. 16892 * Loop querying:: Getting information about loops. 16893 * Loop manipulation:: Loop manipulation functions. 16894 * LCSSA:: Loop-closed SSA form. 16895 * Scalar evolutions:: Induction variables on GIMPLE. 16896 * loop-iv:: Induction variables on RTL. 16897 * Number of iterations:: Number of iterations analysis. 16898 * Dependency analysis:: Data dependency analysis. 16899 * Lambda:: Linear loop transformations framework. 16900 * Omega:: A solver for linear programming problems. 16901 16902 16903 File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 16904 16905 14.1 Loop representation 16906 ======================== 16907 16908 This chapter describes the representation of loops in GCC, and functions 16909 that can be used to build, modify and analyze this representation. Most 16910 of the interfaces and data structures are declared in `cfgloop.h'. At 16911 the moment, loop structures are analyzed and this information is 16912 updated only by the optimization passes that deal with loops, but some 16913 efforts are being made to make it available throughout most of the 16914 optimization passes. 16915 16916 In general, a natural loop has one entry block (header) and possibly 16917 several back edges (latches) leading to the header from the inside of 16918 the loop. Loops with several latches may appear if several loops share 16919 a single header, or if there is a branching in the middle of the loop. 16920 The representation of loops in GCC however allows only loops with a 16921 single latch. During loop analysis, headers of such loops are split and 16922 forwarder blocks are created in order to disambiguate their structures. 16923 Heuristic based on profile information and structure of the induction 16924 variables in the loops is used to determine whether the latches 16925 correspond to sub-loops or to control flow in a single loop. This means 16926 that the analysis sometimes changes the CFG, and if you run it in the 16927 middle of an optimization pass, you must be able to deal with the new 16928 blocks. You may avoid CFG changes by passing 16929 `LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 16930 however that most other loop manipulation functions will not work 16931 correctly for loops with multiple latch edges (the functions that only 16932 query membership of blocks to loops and subloop relationships, or 16933 enumerate and test loop exits, can be expected to work). 16934 16935 Body of the loop is the set of blocks that are dominated by its header, 16936 and reachable from its latch against the direction of edges in CFG. The 16937 loops are organized in a containment hierarchy (tree) such that all the 16938 loops immediately contained inside loop L are the children of L in the 16939 tree. This tree is represented by the `struct loops' structure. The 16940 root of this tree is a fake loop that contains all blocks in the 16941 function. Each of the loops is represented in a `struct loop' 16942 structure. Each loop is assigned an index (`num' field of the `struct 16943 loop' structure), and the pointer to the loop is stored in the 16944 corresponding field of the `larray' vector in the loops structure. The 16945 indices do not have to be continuous, there may be empty (`NULL') 16946 entries in the `larray' created by deleting loops. Also, there is no 16947 guarantee on the relative order of a loop and its subloops in the 16948 numbering. The index of a loop never changes. 16949 16950 The entries of the `larray' field should not be accessed directly. 16951 The function `get_loop' returns the loop description for a loop with 16952 the given index. `number_of_loops' function returns number of loops in 16953 the function. To traverse all loops, use `FOR_EACH_LOOP' macro. The 16954 `flags' argument of the macro is used to determine the direction of 16955 traversal and the set of loops visited. Each loop is guaranteed to be 16956 visited exactly once, regardless of the changes to the loop tree, and 16957 the loops may be removed during the traversal. The newly created loops 16958 are never traversed, if they need to be visited, this must be done 16959 separately after their creation. The `FOR_EACH_LOOP' macro allocates 16960 temporary variables. If the `FOR_EACH_LOOP' loop were ended using 16961 break or goto, they would not be released; `FOR_EACH_LOOP_BREAK' macro 16962 must be used instead. 16963 16964 Each basic block contains the reference to the innermost loop it 16965 belongs to (`loop_father'). For this reason, it is only possible to 16966 have one `struct loops' structure initialized at the same time for each 16967 CFG. The global variable `current_loops' contains the `struct loops' 16968 structure. Many of the loop manipulation functions assume that 16969 dominance information is up-to-date. 16970 16971 The loops are analyzed through `loop_optimizer_init' function. The 16972 argument of this function is a set of flags represented in an integer 16973 bitmask. These flags specify what other properties of the loop 16974 structures should be calculated/enforced and preserved later: 16975 16976 * `LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 16977 to CFG will be performed in the loop analysis, in particular, 16978 loops with multiple latch edges will not be disambiguated. If a 16979 loop has multiple latches, its latch block is set to NULL. Most of 16980 the loop manipulation functions will not work for loops in this 16981 shape. No other flags that require CFG changes can be passed to 16982 loop_optimizer_init. 16983 16984 * `LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a 16985 way that each loop has only one entry edge, and additionally, the 16986 source block of this entry edge has only one successor. This 16987 creates a natural place where the code can be moved out of the 16988 loop, and ensures that the entry edge of the loop leads from its 16989 immediate super-loop. 16990 16991 * `LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 16992 the latch block of each loop to have only one successor. This 16993 ensures that the latch of the loop does not belong to any of its 16994 sub-loops, and makes manipulation with the loops significantly 16995 easier. Most of the loop manipulation functions assume that the 16996 loops are in this shape. Note that with this flag, the "normal" 16997 loop without any control flow inside and with one exit consists of 16998 two basic blocks. 16999 17000 * `LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 17001 the strongly connected components that are not natural loops (have 17002 more than one entry block) are marked with `BB_IRREDUCIBLE_LOOP' 17003 and `EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 17004 and edges that belong to natural loops that are in such an 17005 irreducible region (but it is set for the entry and exit edges of 17006 such a loop, if they lead to/from this region). 17007 17008 * `LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 17009 updated for each loop. This makes some functions (e.g., 17010 `get_loop_exit_edges') more efficient. Some functions (e.g., 17011 `single_exit') can be used only if the lists of exits are recorded. 17012 17013 These properties may also be computed/enforced later, using functions 17014 `create_preheaders', `force_single_succ_latches', 17015 `mark_irreducible_loops' and `record_loop_exits'. 17016 17017 The memory occupied by the loops structures should be freed with 17018 `loop_optimizer_finalize' function. 17019 17020 The CFG manipulation functions in general do not update loop 17021 structures. Specialized versions that additionally do so are provided 17022 for the most common tasks. On GIMPLE, `cleanup_tree_cfg_loop' function 17023 can be used to cleanup CFG while updating the loops structures if 17024 `current_loops' is set. 17025 17026 17027 File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 17028 17029 14.2 Loop querying 17030 ================== 17031 17032 The functions to query the information about loops are declared in 17033 `cfgloop.h'. Some of the information can be taken directly from the 17034 structures. `loop_father' field of each basic block contains the 17035 innermost loop to that the block belongs. The most useful fields of 17036 loop structure (that are kept up-to-date at all times) are: 17037 17038 * `header', `latch': Header and latch basic blocks of the loop. 17039 17040 * `num_nodes': Number of basic blocks in the loop (including the 17041 basic blocks of the sub-loops). 17042 17043 * `depth': The depth of the loop in the loops tree, i.e., the number 17044 of super-loops of the loop. 17045 17046 * `outer', `inner', `next': The super-loop, the first sub-loop, and 17047 the sibling of the loop in the loops tree. 17048 17049 There are other fields in the loop structures, many of them used only 17050 by some of the passes, or not updated during CFG changes; in general, 17051 they should not be accessed directly. 17052 17053 The most important functions to query loop structures are: 17054 17055 * `flow_loops_dump': Dumps the information about loops to a file. 17056 17057 * `verify_loop_structure': Checks consistency of the loop structures. 17058 17059 * `loop_latch_edge': Returns the latch edge of a loop. 17060 17061 * `loop_preheader_edge': If loops have preheaders, returns the 17062 preheader edge of a loop. 17063 17064 * `flow_loop_nested_p': Tests whether loop is a sub-loop of another 17065 loop. 17066 17067 * `flow_bb_inside_loop_p': Tests whether a basic block belongs to a 17068 loop (including its sub-loops). 17069 17070 * `find_common_loop': Finds the common super-loop of two loops. 17071 17072 * `superloop_at_depth': Returns the super-loop of a loop with the 17073 given depth. 17074 17075 * `tree_num_loop_insns', `num_loop_insns': Estimates the number of 17076 insns in the loop, on GIMPLE and on RTL. 17077 17078 * `loop_exit_edge_p': Tests whether edge is an exit from a loop. 17079 17080 * `mark_loop_exit_edges': Marks all exit edges of all loops with 17081 `EDGE_LOOP_EXIT' flag. 17082 17083 * `get_loop_body', `get_loop_body_in_dom_order', 17084 `get_loop_body_in_bfs_order': Enumerates the basic blocks in the 17085 loop in depth-first search order in reversed CFG, ordered by 17086 dominance relation, and breath-first search order, respectively. 17087 17088 * `single_exit': Returns the single exit edge of the loop, or `NULL' 17089 if the loop has more than one exit. You can only use this 17090 function if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 17091 17092 * `get_loop_exit_edges': Enumerates the exit edges of a loop. 17093 17094 * `just_once_each_iteration_p': Returns true if the basic block is 17095 executed exactly once during each iteration of a loop (that is, it 17096 does not belong to a sub-loop, and it dominates the latch of the 17097 loop). 17098 17099 17100 File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 17101 17102 14.3 Loop manipulation 17103 ====================== 17104 17105 The loops tree can be manipulated using the following functions: 17106 17107 * `flow_loop_tree_node_add': Adds a node to the tree. 17108 17109 * `flow_loop_tree_node_remove': Removes a node from the tree. 17110 17111 * `add_bb_to_loop': Adds a basic block to a loop. 17112 17113 * `remove_bb_from_loops': Removes a basic block from loops. 17114 17115 Most low-level CFG functions update loops automatically. The following 17116 functions handle some more complicated cases of CFG manipulations: 17117 17118 * `remove_path': Removes an edge and all blocks it dominates. 17119 17120 * `split_loop_exit_edge': Splits exit edge of the loop, ensuring 17121 that PHI node arguments remain in the loop (this ensures that 17122 loop-closed SSA form is preserved). Only useful on GIMPLE. 17123 17124 Finally, there are some higher-level loop transformations implemented. 17125 While some of them are written so that they should work on non-innermost 17126 loops, they are mostly untested in that case, and at the moment, they 17127 are only reliable for the innermost loops: 17128 17129 * `create_iv': Creates a new induction variable. Only works on 17130 GIMPLE. `standard_iv_increment_position' can be used to find a 17131 suitable place for the iv increment. 17132 17133 * `duplicate_loop_to_header_edge', 17134 `tree_duplicate_loop_to_header_edge': These functions (on RTL and 17135 on GIMPLE) duplicate the body of the loop prescribed number of 17136 times on one of the edges entering loop header, thus performing 17137 either loop unrolling or loop peeling. `can_duplicate_loop_p' 17138 (`can_unroll_loop_p' on GIMPLE) must be true for the duplicated 17139 loop. 17140 17141 * `loop_version', `tree_ssa_loop_version': These function create a 17142 copy of a loop, and a branch before them that selects one of them 17143 depending on the prescribed condition. This is useful for 17144 optimizations that need to verify some assumptions in runtime (one 17145 of the copies of the loop is usually left unchanged, while the 17146 other one is transformed in some way). 17147 17148 * `tree_unroll_loop': Unrolls the loop, including peeling the extra 17149 iterations to make the number of iterations divisible by unroll 17150 factor, updating the exit condition, and removing the exits that 17151 now cannot be taken. Works only on GIMPLE. 17152 17153 17154 File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 17155 17156 14.4 Loop-closed SSA form 17157 ========================= 17158 17159 Throughout the loop optimizations on tree level, one extra condition is 17160 enforced on the SSA form: No SSA name is used outside of the loop in 17161 that it is defined. The SSA form satisfying this condition is called 17162 "loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 17163 created at the exits of the loops for the SSA names that are used 17164 outside of them. Only the real operands (not virtual SSA names) are 17165 held in LCSSA, in order to save memory. 17166 17167 There are various benefits of LCSSA: 17168 17169 * Many optimizations (value range analysis, final value replacement) 17170 are interested in the values that are defined in the loop and used 17171 outside of it, i.e., exactly those for that we create new PHI 17172 nodes. 17173 17174 * In induction variable analysis, it is not necessary to specify the 17175 loop in that the analysis should be performed - the scalar 17176 evolution analysis always returns the results with respect to the 17177 loop in that the SSA name is defined. 17178 17179 * It makes updating of SSA form during loop transformations simpler. 17180 Without LCSSA, operations like loop unrolling may force creation 17181 of PHI nodes arbitrarily far from the loop, while in LCSSA, the 17182 SSA form can be updated locally. However, since we only keep real 17183 operands in LCSSA, we cannot use this advantage (we could have 17184 local updating of real operands, but it is not much more efficient 17185 than to use generic SSA form updating for it as well; the amount 17186 of changes to SSA is the same). 17187 17188 However, it also means LCSSA must be updated. This is usually 17189 straightforward, unless you create a new value in loop and use it 17190 outside, or unless you manipulate loop exit edges (functions are 17191 provided to make these manipulations simple). 17192 `rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, 17193 and `verify_loop_closed_ssa' to check that the invariant of LCSSA is 17194 preserved. 17195 17196 17197 File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 17198 17199 14.5 Scalar evolutions 17200 ====================== 17201 17202 Scalar evolutions (SCEV) are used to represent results of induction 17203 variable analysis on GIMPLE. They enable us to represent variables with 17204 complicated behavior in a simple and consistent way (we only use it to 17205 express values of polynomial induction variables, but it is possible to 17206 extend it). The interfaces to SCEV analysis are declared in 17207 `tree-scalar-evolution.h'. To use scalar evolutions analysis, 17208 `scev_initialize' must be used. To stop using SCEV, `scev_finalize' 17209 should be used. SCEV analysis caches results in order to save time and 17210 memory. This cache however is made invalid by most of the loop 17211 transformations, including removal of code. If such a transformation 17212 is performed, `scev_reset' must be called to clean the caches. 17213 17214 Given an SSA name, its behavior in loops can be analyzed using the 17215 `analyze_scalar_evolution' function. The returned SCEV however does 17216 not have to be fully analyzed and it may contain references to other 17217 SSA names defined in the loop. To resolve these (potentially 17218 recursive) references, `instantiate_parameters' or `resolve_mixers' 17219 functions must be used. `instantiate_parameters' is useful when you 17220 use the results of SCEV only for some analysis, and when you work with 17221 whole nest of loops at once. It will try replacing all SSA names by 17222 their SCEV in all loops, including the super-loops of the current loop, 17223 thus providing a complete information about the behavior of the 17224 variable in the loop nest. `resolve_mixers' is useful if you work with 17225 only one loop at a time, and if you possibly need to create code based 17226 on the value of the induction variable. It will only resolve the SSA 17227 names defined in the current loop, leaving the SSA names defined 17228 outside unchanged, even if their evolution in the outer loops is known. 17229 17230 The SCEV is a normal tree expression, except for the fact that it may 17231 contain several special tree nodes. One of them is `SCEV_NOT_KNOWN', 17232 used for SSA names whose value cannot be expressed. The other one is 17233 `POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 17234 and loop (both base and step may contain further polynomial chrecs). 17235 Type of the expression and of base and step must be the same. A 17236 variable has evolution `POLYNOMIAL_CHREC(base, step, loop)' if it is 17237 (in the specified loop) equivalent to `x_1' in the following example 17238 17239 while (...) 17240 { 17241 x_1 = phi (base, x_2); 17242 x_2 = x_1 + step; 17243 } 17244 17245 Note that this includes the language restrictions on the operations. 17246 For example, if we compile C code and `x' has signed type, then the 17247 overflow in addition would cause undefined behavior, and we may assume 17248 that this does not happen. Hence, the value with this SCEV cannot 17249 overflow (which restricts the number of iterations of such a loop). 17250 17251 In many cases, one wants to restrict the attention just to affine 17252 induction variables. In this case, the extra expressive power of SCEV 17253 is not useful, and may complicate the optimizations. In this case, 17254 `simple_iv' function may be used to analyze a value - the result is a 17255 loop-invariant base and step. 17256 17257 17258 File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 17259 17260 14.6 IV analysis on RTL 17261 ======================= 17262 17263 The induction variable on RTL is simple and only allows analysis of 17264 affine induction variables, and only in one loop at once. The interface 17265 is declared in `cfgloop.h'. Before analyzing induction variables in a 17266 loop L, `iv_analysis_loop_init' function must be called on L. After 17267 the analysis (possibly calling `iv_analysis_loop_init' for several 17268 loops) is finished, `iv_analysis_done' should be called. The following 17269 functions can be used to access the results of the analysis: 17270 17271 * `iv_analyze': Analyzes a single register used in the given insn. 17272 If no use of the register in this insn is found, the following 17273 insns are scanned, so that this function can be called on the insn 17274 returned by get_condition. 17275 17276 * `iv_analyze_result': Analyzes result of the assignment in the 17277 given insn. 17278 17279 * `iv_analyze_expr': Analyzes a more complicated expression. All 17280 its operands are analyzed by `iv_analyze', and hence they must be 17281 used in the specified insn or one of the following insns. 17282 17283 The description of the induction variable is provided in `struct 17284 rtx_iv'. In order to handle subregs, the representation is a bit 17285 complicated; if the value of the `extend' field is not `UNKNOWN', the 17286 value of the induction variable in the i-th iteration is 17287 17288 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 17289 17290 with the following exception: if `first_special' is true, then the 17291 value in the first iteration (when `i' is zero) is `delta + mult * 17292 base'. However, if `extend' is equal to `UNKNOWN', then 17293 `first_special' must be false, `delta' 0, `mult' 1 and the value in the 17294 i-th iteration is 17295 17296 subreg_{mode} (base + i * step) 17297 17298 The function `get_iv_value' can be used to perform these calculations. 17299 17300 17301 File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 17302 17303 14.7 Number of iterations analysis 17304 ================================== 17305 17306 Both on GIMPLE and on RTL, there are functions available to determine 17307 the number of iterations of a loop, with a similar interface. The 17308 number of iterations of a loop in GCC is defined as the number of 17309 executions of the loop latch. In many cases, it is not possible to 17310 determine the number of iterations unconditionally - the determined 17311 number is correct only if some assumptions are satisfied. The analysis 17312 tries to verify these conditions using the information contained in the 17313 program; if it fails, the conditions are returned together with the 17314 result. The following information and conditions are provided by the 17315 analysis: 17316 17317 * `assumptions': If this condition is false, the rest of the 17318 information is invalid. 17319 17320 * `noloop_assumptions' on RTL, `may_be_zero' on GIMPLE: If this 17321 condition is true, the loop exits in the first iteration. 17322 17323 * `infinite': If this condition is true, the loop is infinite. This 17324 condition is only available on RTL. On GIMPLE, conditions for 17325 finiteness of the loop are included in `assumptions'. 17326 17327 * `niter_expr' on RTL, `niter' on GIMPLE: The expression that gives 17328 number of iterations. The number of iterations is defined as the 17329 number of executions of the loop latch. 17330 17331 Both on GIMPLE and on RTL, it necessary for the induction variable 17332 analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 17333 On GIMPLE, the results are stored to `struct tree_niter_desc' 17334 structure. Number of iterations before the loop is exited through a 17335 given exit can be determined using `number_of_iterations_exit' 17336 function. On RTL, the results are returned in `struct niter_desc' 17337 structure. The corresponding function is named `check_simple_exit'. 17338 There are also functions that pass through all the exits of a loop and 17339 try to find one with easy to determine number of iterations - 17340 `find_loop_niter' on GIMPLE and `find_simple_exit' on RTL. Finally, 17341 there are functions that provide the same information, but additionally 17342 cache it, so that repeated calls to number of iterations are not so 17343 costly - `number_of_latch_executions' on GIMPLE and 17344 `get_simple_loop_desc' on RTL. 17345 17346 Note that some of these functions may behave slightly differently than 17347 others - some of them return only the expression for the number of 17348 iterations, and fail if there are some assumptions. The function 17349 `number_of_latch_executions' works only for single-exit loops. The 17350 function `number_of_cond_exit_executions' can be used to determine 17351 number of executions of the exit condition of a single-exit loop (i.e., 17352 the `number_of_latch_executions' increased by one). 17353 17354 17355 File: gccint.info, Node: Dependency analysis, Next: Lambda, Prev: Number of iterations, Up: Loop Analysis and Representation 17356 17357 14.8 Data Dependency Analysis 17358 ============================= 17359 17360 The code for the data dependence analysis can be found in 17361 `tree-data-ref.c' and its interface and data structures are described 17362 in `tree-data-ref.h'. The function that computes the data dependences 17363 for all the array and pointer references for a given loop is 17364 `compute_data_dependences_for_loop'. This function is currently used 17365 by the linear loop transform and the vectorization passes. Before 17366 calling this function, one has to allocate two vectors: a first vector 17367 will contain the set of data references that are contained in the 17368 analyzed loop body, and the second vector will contain the dependence 17369 relations between the data references. Thus if the vector of data 17370 references is of size `n', the vector containing the dependence 17371 relations will contain `n*n' elements. However if the analyzed loop 17372 contains side effects, such as calls that potentially can interfere 17373 with the data references in the current analyzed loop, the analysis 17374 stops while scanning the loop body for data references, and inserts a 17375 single `chrec_dont_know' in the dependence relation array. 17376 17377 The data references are discovered in a particular order during the 17378 scanning of the loop body: the loop body is analyzed in execution order, 17379 and the data references of each statement are pushed at the end of the 17380 data reference array. Two data references syntactically occur in the 17381 program in the same order as in the array of data references. This 17382 syntactic order is important in some classical data dependence tests, 17383 and mapping this order to the elements of this array avoids costly 17384 queries to the loop body representation. 17385 17386 Three types of data references are currently handled: ARRAY_REF, 17387 INDIRECT_REF and COMPONENT_REF. The data structure for the data 17388 reference is `data_reference', where `data_reference_p' is a name of a 17389 pointer to the data reference structure. The structure contains the 17390 following elements: 17391 17392 * `base_object_info': Provides information about the base object of 17393 the data reference and its access functions. These access functions 17394 represent the evolution of the data reference in the loop relative 17395 to its base, in keeping with the classical meaning of the data 17396 reference access function for the support of arrays. For example, 17397 for a reference `a.b[i][j]', the base object is `a.b' and the 17398 access functions, one for each array subscript, are: `{i_init, + 17399 i_step}_1, {j_init, +, j_step}_2'. 17400 17401 * `first_location_in_loop': Provides information about the first 17402 location accessed by the data reference in the loop and about the 17403 access function used to represent evolution relative to this 17404 location. This data is used to support pointers, and is not used 17405 for arrays (for which we have base objects). Pointer accesses are 17406 represented as a one-dimensional access that starts from the first 17407 location accessed in the loop. For example: 17408 17409 for1 i 17410 for2 j 17411 *((int *)p + i + j) = a[i][j]; 17412 17413 The access function of the pointer access is `{0, + 4B}_for2' 17414 relative to `p + i'. The access functions of the array are 17415 `{i_init, + i_step}_for1' and `{j_init, +, j_step}_for2' relative 17416 to `a'. 17417 17418 Usually, the object the pointer refers to is either unknown, or we 17419 can't prove that the access is confined to the boundaries of a 17420 certain object. 17421 17422 Two data references can be compared only if at least one of these 17423 two representations has all its fields filled for both data 17424 references. 17425 17426 The current strategy for data dependence tests is as follows: If 17427 both `a' and `b' are represented as arrays, compare 17428 `a.base_object' and `b.base_object'; if they are equal, apply 17429 dependence tests (use access functions based on base_objects). 17430 Else if both `a' and `b' are represented as pointers, compare 17431 `a.first_location' and `b.first_location'; if they are equal, 17432 apply dependence tests (use access functions based on first 17433 location). However, if `a' and `b' are represented differently, 17434 only try to prove that the bases are definitely different. 17435 17436 * Aliasing information. 17437 17438 * Alignment information. 17439 17440 The structure describing the relation between two data references is 17441 `data_dependence_relation' and the shorter name for a pointer to such a 17442 structure is `ddr_p'. This structure contains: 17443 17444 * a pointer to each data reference, 17445 17446 * a tree node `are_dependent' that is set to `chrec_known' if the 17447 analysis has proved that there is no dependence between these two 17448 data references, `chrec_dont_know' if the analysis was not able to 17449 determine any useful result and potentially there could exist a 17450 dependence between these data references, and `are_dependent' is 17451 set to `NULL_TREE' if there exist a dependence relation between the 17452 data references, and the description of this dependence relation is 17453 given in the `subscripts', `dir_vects', and `dist_vects' arrays, 17454 17455 * a boolean that determines whether the dependence relation can be 17456 represented by a classical distance vector, 17457 17458 * an array `subscripts' that contains a description of each 17459 subscript of the data references. Given two array accesses a 17460 subscript is the tuple composed of the access functions for a given 17461 dimension. For example, given `A[f1][f2][f3]' and 17462 `B[g1][g2][g3]', there are three subscripts: `(f1, g1), (f2, g2), 17463 (f3, g3)'. 17464 17465 * two arrays `dir_vects' and `dist_vects' that contain classical 17466 representations of the data dependences under the form of 17467 direction and distance dependence vectors, 17468 17469 * an array of loops `loop_nest' that contains the loops to which the 17470 distance and direction vectors refer to. 17471 17472 Several functions for pretty printing the information extracted by the 17473 data dependence analysis are available: `dump_ddrs' prints with a 17474 maximum verbosity the details of a data dependence relations array, 17475 `dump_dist_dir_vectors' prints only the classical distance and 17476 direction vectors for a data dependence relations array, and 17477 `dump_data_references' prints the details of the data references 17478 contained in a data reference array. 17479 17480 17481 File: gccint.info, Node: Lambda, Next: Omega, Prev: Dependency analysis, Up: Loop Analysis and Representation 17482 17483 14.9 Linear loop transformations framework 17484 ========================================== 17485 17486 Lambda is a framework that allows transformations of loops using 17487 non-singular matrix based transformations of the iteration space and 17488 loop bounds. This allows compositions of skewing, scaling, interchange, 17489 and reversal transformations. These transformations are often used to 17490 improve cache behavior or remove inner loop dependencies to allow 17491 parallelization and vectorization to take place. 17492 17493 To perform these transformations, Lambda requires that the loopnest be 17494 converted into an internal form that can be matrix transformed easily. 17495 To do this conversion, the function `gcc_loopnest_to_lambda_loopnest' 17496 is provided. If the loop cannot be transformed using lambda, this 17497 function will return NULL. 17498 17499 Once a `lambda_loopnest' is obtained from the conversion function, it 17500 can be transformed by using `lambda_loopnest_transform', which takes a 17501 transformation matrix to apply. Note that it is up to the caller to 17502 verify that the transformation matrix is legal to apply to the loop 17503 (dependence respecting, etc). Lambda simply applies whatever matrix it 17504 is told to provide. It can be extended to make legal matrices out of 17505 any non-singular matrix, but this is not currently implemented. 17506 Legality of a matrix for a given loopnest can be verified using 17507 `lambda_transform_legal_p'. 17508 17509 Given a transformed loopnest, conversion back into gcc IR is done by 17510 `lambda_loopnest_to_gcc_loopnest'. This function will modify the loops 17511 so that they match the transformed loopnest. 17512 17513 17514 File: gccint.info, Node: Omega, Prev: Lambda, Up: Loop Analysis and Representation 17515 17516 14.10 Omega a solver for linear programming problems 17517 ==================================================== 17518 17519 The data dependence analysis contains several solvers triggered 17520 sequentially from the less complex ones to the more sophisticated. For 17521 ensuring the consistency of the results of these solvers, a data 17522 dependence check pass has been implemented based on two different 17523 solvers. The second method that has been integrated to GCC is based on 17524 the Omega dependence solver, written in the 1990's by William Pugh and 17525 David Wonnacott. Data dependence tests can be formulated using a 17526 subset of the Presburger arithmetics that can be translated to linear 17527 constraint systems. These linear constraint systems can then be solved 17528 using the Omega solver. 17529 17530 The Omega solver is using Fourier-Motzkin's algorithm for variable 17531 elimination: a linear constraint system containing `n' variables is 17532 reduced to a linear constraint system with `n-1' variables. The Omega 17533 solver can also be used for solving other problems that can be 17534 expressed under the form of a system of linear equalities and 17535 inequalities. The Omega solver is known to have an exponential worst 17536 case, also known under the name of "omega nightmare" in the literature, 17537 but in practice, the omega test is known to be efficient for the common 17538 data dependence tests. 17539 17540 The interface used by the Omega solver for describing the linear 17541 programming problems is described in `omega.h', and the solver is 17542 `omega_solve_problem'. 17543 17544 17545 File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 17546 17547 15 Control Flow Graph 17548 ********************* 17549 17550 A control flow graph (CFG) is a data structure built on top of the 17551 intermediate code representation (the RTL or `GIMPLE' instruction 17552 stream) abstracting the control flow behavior of a function that is 17553 being compiled. The CFG is a directed graph where the vertices 17554 represent basic blocks and edges represent possible transfer of control 17555 flow from one basic block to another. The data structures used to 17556 represent the control flow graph are defined in `basic-block.h'. 17557 17558 In GCC, the representation of control flow is maintained throughout 17559 the compilation process, from constructing the CFG early in 17560 `pass_build_cfg' to `pass_free_cfg' (see `passes.c'). The CFG takes 17561 various different modes and may undergo extensive manipulations, but 17562 the graph is always valid between its construction and its release. 17563 This way, transfer of information such as data flow, a measured 17564 profile, or the loop tree, can be propagated through the passes 17565 pipeline, and even from `GIMPLE' to `RTL'. 17566 17567 Often the CFG may be better viewed as integral part of instruction 17568 chain, than structure built on the top of it. Updating the compiler's 17569 intermediate representation for instructions can not be easily done 17570 without proper maintenance of the CFG simultaneously. 17571 17572 * Menu: 17573 17574 * Basic Blocks:: The definition and representation of basic blocks. 17575 * Edges:: Types of edges and their representation. 17576 * Profile information:: Representation of frequencies and probabilities. 17577 * Maintaining the CFG:: Keeping the control flow graph and up to date. 17578 * Liveness information:: Using and maintaining liveness information. 17579 17580 17581 File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 17582 17583 15.1 Basic Blocks 17584 ================= 17585 17586 A basic block is a straight-line sequence of code with only one entry 17587 point and only one exit. In GCC, basic blocks are represented using 17588 the `basic_block' data type. 17589 17590 Special basic blocks represent possible entry and exit points of a 17591 function. These blocks are called `ENTRY_BLOCK_PTR' and 17592 `EXIT_BLOCK_PTR'. These blocks do not contain any code. 17593 17594 The `BASIC_BLOCK' array contains all basic blocks in an unspecified 17595 order. Each `basic_block' structure has a field that holds a unique 17596 integer identifier `index' that is the index of the block in the 17597 `BASIC_BLOCK' array. The total number of basic blocks in the function 17598 is `n_basic_blocks'. Both the basic block indices and the total number 17599 of basic blocks may vary during the compilation process, as passes 17600 reorder, create, duplicate, and destroy basic blocks. The index for 17601 any block should never be greater than `last_basic_block'. The indices 17602 0 and 1 are special codes reserved for `ENTRY_BLOCK' and `EXIT_BLOCK', 17603 the indices of `ENTRY_BLOCK_PTR' and `EXIT_BLOCK_PTR'. 17604 17605 Two pointer members of the `basic_block' structure are the pointers 17606 `next_bb' and `prev_bb'. These are used to keep doubly linked chain of 17607 basic blocks in the same order as the underlying instruction stream. 17608 The chain of basic blocks is updated transparently by the provided API 17609 for manipulating the CFG. The macro `FOR_EACH_BB' can be used to visit 17610 all the basic blocks in lexicographical order, except `ENTRY_BLOCK' and 17611 `EXIT_BLOCK'. The macro `FOR_ALL_BB' also visits all basic blocks in 17612 lexicographical order, including `ENTRY_BLOCK' and `EXIT_BLOCK'. 17613 17614 The functions `post_order_compute' and `inverted_post_order_compute' 17615 can be used to compute topological orders of the CFG. The orders are 17616 stored as vectors of basic block indices. The `BASIC_BLOCK' array can 17617 be used to iterate each basic block by index. Dominator traversals are 17618 also possible using `walk_dominator_tree'. Given two basic blocks A 17619 and B, block A dominates block B if A is _always_ executed before B. 17620 17621 Each `basic_block' also contains pointers to the first instruction 17622 (the "head") and the last instruction (the "tail") or "end" of the 17623 instruction stream contained in a basic block. In fact, since the 17624 `basic_block' data type is used to represent blocks in both major 17625 intermediate representations of GCC (`GIMPLE' and RTL), there are 17626 pointers to the head and end of a basic block for both representations, 17627 stored in intermediate representation specific data in the `il' field 17628 of `struct basic_block_def'. 17629 17630 For RTL, these pointers are `BB_HEAD' and `BB_END'. 17631 17632 In the RTL representation of a function, the instruction stream 17633 contains not only the "real" instructions, but also "notes" or "insn 17634 notes" (to distinguish them from "reg notes"). Any function that moves 17635 or duplicates the basic blocks needs to take care of updating of these 17636 notes. Many of these notes expect that the instruction stream consists 17637 of linear regions, so updating can sometimes be tedious. All types of 17638 insn notes are defined in `insn-notes.def'. 17639 17640 In the RTL function representation, the instructions contained in a 17641 basic block always follow a `NOTE_INSN_BASIC_BLOCK', but zero or more 17642 `CODE_LABEL' nodes can precede the block note. A basic block ends with 17643 a control flow instruction or with the last instruction before the next 17644 `CODE_LABEL' or `NOTE_INSN_BASIC_BLOCK'. By definition, a `CODE_LABEL' 17645 cannot appear in the middle of the instruction stream of a basic block. 17646 17647 In addition to notes, the jump table vectors are also represented as 17648 "pseudo-instructions" inside the insn stream. These vectors never 17649 appear in the basic block and should always be placed just after the 17650 table jump instructions referencing them. After removing the 17651 table-jump it is often difficult to eliminate the code computing the 17652 address and referencing the vector, so cleaning up these vectors is 17653 postponed until after liveness analysis. Thus the jump table vectors 17654 may appear in the insn stream unreferenced and without any purpose. 17655 Before any edge is made "fall-thru", the existence of such construct in 17656 the way needs to be checked by calling `can_fallthru' function. 17657 17658 For the `GIMPLE' representation, the PHI nodes and statements 17659 contained in a basic block are in a `gimple_seq' pointed to by the 17660 basic block intermediate language specific pointers. Abstract 17661 containers and iterators are used to access the PHI nodes and 17662 statements in a basic blocks. These iterators are called "GIMPLE 17663 statement iterators" (GSIs). Grep for `^gsi' in the various `gimple-*' 17664 and `tree-*' files. The following snippet will pretty-print all PHI 17665 nodes the statements of the current function in the GIMPLE 17666 representation. 17667 17668 basic_block bb; 17669 17670 FOR_EACH_BB (bb) 17671 { 17672 gimple_stmt_iterator si; 17673 17674 for (si = gsi_start_phis (bb); !gsi_end_p (si); gsi_next (&si)) 17675 { 17676 gimple phi = gsi_stmt (si); 17677 print_gimple_stmt (dump_file, phi, 0, TDF_SLIM); 17678 } 17679 for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si)) 17680 { 17681 gimple stmt = gsi_stmt (si); 17682 print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM); 17683 } 17684 } 17685 17686 17687 File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 17688 17689 15.2 Edges 17690 ========== 17691 17692 Edges represent possible control flow transfers from the end of some 17693 basic block A to the head of another basic block B. We say that A is a 17694 predecessor of B, and B is a successor of A. Edges are represented in 17695 GCC with the `edge' data type. Each `edge' acts as a link between two 17696 basic blocks: The `src' member of an edge points to the predecessor 17697 basic block of the `dest' basic block. The members `preds' and `succs' 17698 of the `basic_block' data type point to type-safe vectors of edges to 17699 the predecessors and successors of the block. 17700 17701 When walking the edges in an edge vector, "edge iterators" should be 17702 used. Edge iterators are constructed using the `edge_iterator' data 17703 structure and several methods are available to operate on them: 17704 17705 `ei_start' 17706 This function initializes an `edge_iterator' that points to the 17707 first edge in a vector of edges. 17708 17709 `ei_last' 17710 This function initializes an `edge_iterator' that points to the 17711 last edge in a vector of edges. 17712 17713 `ei_end_p' 17714 This predicate is `true' if an `edge_iterator' represents the last 17715 edge in an edge vector. 17716 17717 `ei_one_before_end_p' 17718 This predicate is `true' if an `edge_iterator' represents the 17719 second last edge in an edge vector. 17720 17721 `ei_next' 17722 This function takes a pointer to an `edge_iterator' and makes it 17723 point to the next edge in the sequence. 17724 17725 `ei_prev' 17726 This function takes a pointer to an `edge_iterator' and makes it 17727 point to the previous edge in the sequence. 17728 17729 `ei_edge' 17730 This function returns the `edge' currently pointed to by an 17731 `edge_iterator'. 17732 17733 `ei_safe_safe' 17734 This function returns the `edge' currently pointed to by an 17735 `edge_iterator', but returns `NULL' if the iterator is pointing at 17736 the end of the sequence. This function has been provided for 17737 existing code makes the assumption that a `NULL' edge indicates 17738 the end of the sequence. 17739 17740 17741 The convenience macro `FOR_EACH_EDGE' can be used to visit all of the 17742 edges in a sequence of predecessor or successor edges. It must not be 17743 used when an element might be removed during the traversal, otherwise 17744 elements will be missed. Here is an example of how to use the macro: 17745 17746 edge e; 17747 edge_iterator ei; 17748 17749 FOR_EACH_EDGE (e, ei, bb->succs) 17750 { 17751 if (e->flags & EDGE_FALLTHRU) 17752 break; 17753 } 17754 17755 There are various reasons why control flow may transfer from one block 17756 to another. One possibility is that some instruction, for example a 17757 `CODE_LABEL', in a linearized instruction stream just always starts a 17758 new basic block. In this case a "fall-thru" edge links the basic block 17759 to the first following basic block. But there are several other 17760 reasons why edges may be created. The `flags' field of the `edge' data 17761 type is used to store information about the type of edge we are dealing 17762 with. Each edge is of one of the following types: 17763 17764 _jump_ 17765 No type flags are set for edges corresponding to jump instructions. 17766 These edges are used for unconditional or conditional jumps and in 17767 RTL also for table jumps. They are the easiest to manipulate as 17768 they may be freely redirected when the flow graph is not in SSA 17769 form. 17770 17771 _fall-thru_ 17772 Fall-thru edges are present in case where the basic block may 17773 continue execution to the following one without branching. These 17774 edges have the `EDGE_FALLTHRU' flag set. Unlike other types of 17775 edges, these edges must come into the basic block immediately 17776 following in the instruction stream. The function 17777 `force_nonfallthru' is available to insert an unconditional jump 17778 in the case that redirection is needed. Note that this may 17779 require creation of a new basic block. 17780 17781 _exception handling_ 17782 Exception handling edges represent possible control transfers from 17783 a trapping instruction to an exception handler. The definition of 17784 "trapping" varies. In C++, only function calls can throw, but for 17785 Java and Ada, exceptions like division by zero or segmentation 17786 fault are defined and thus each instruction possibly throwing this 17787 kind of exception needs to be handled as control flow instruction. 17788 Exception edges have the `EDGE_ABNORMAL' and `EDGE_EH' flags set. 17789 17790 When updating the instruction stream it is easy to change possibly 17791 trapping instruction to non-trapping, by simply removing the 17792 exception edge. The opposite conversion is difficult, but should 17793 not happen anyway. The edges can be eliminated via 17794 `purge_dead_edges' call. 17795 17796 In the RTL representation, the destination of an exception edge is 17797 specified by `REG_EH_REGION' note attached to the insn. In case 17798 of a trapping call the `EDGE_ABNORMAL_CALL' flag is set too. In 17799 the `GIMPLE' representation, this extra flag is not set. 17800 17801 In the RTL representation, the predicate `may_trap_p' may be used 17802 to check whether instruction still may trap or not. For the tree 17803 representation, the `tree_could_trap_p' predicate is available, 17804 but this predicate only checks for possible memory traps, as in 17805 dereferencing an invalid pointer location. 17806 17807 _sibling calls_ 17808 Sibling calls or tail calls terminate the function in a 17809 non-standard way and thus an edge to the exit must be present. 17810 `EDGE_SIBCALL' and `EDGE_ABNORMAL' are set in such case. These 17811 edges only exist in the RTL representation. 17812 17813 _computed jumps_ 17814 Computed jumps contain edges to all labels in the function 17815 referenced from the code. All those edges have `EDGE_ABNORMAL' 17816 flag set. The edges used to represent computed jumps often cause 17817 compile time performance problems, since functions consisting of 17818 many taken labels and many computed jumps may have _very_ dense 17819 flow graphs, so these edges need to be handled with special care. 17820 During the earlier stages of the compilation process, GCC tries to 17821 avoid such dense flow graphs by factoring computed jumps. For 17822 example, given the following series of jumps, 17823 17824 goto *x; 17825 [ ... ] 17826 17827 goto *x; 17828 [ ... ] 17829 17830 goto *x; 17831 [ ... ] 17832 17833 factoring the computed jumps results in the following code sequence 17834 which has a much simpler flow graph: 17835 17836 goto y; 17837 [ ... ] 17838 17839 goto y; 17840 [ ... ] 17841 17842 goto y; 17843 [ ... ] 17844 17845 y: 17846 goto *x; 17847 17848 However, the classic problem with this transformation is that it 17849 has a runtime cost in there resulting code: An extra jump. 17850 Therefore, the computed jumps are un-factored in the later passes 17851 of the compiler (in the pass called 17852 `pass_duplicate_computed_gotos'). Be aware of that when you work 17853 on passes in that area. There have been numerous examples already 17854 where the compile time for code with unfactored computed jumps 17855 caused some serious headaches. 17856 17857 _nonlocal goto handlers_ 17858 GCC allows nested functions to return into caller using a `goto' 17859 to a label passed to as an argument to the callee. The labels 17860 passed to nested functions contain special code to cleanup after 17861 function call. Such sections of code are referred to as "nonlocal 17862 goto receivers". If a function contains such nonlocal goto 17863 receivers, an edge from the call to the label is created with the 17864 `EDGE_ABNORMAL' and `EDGE_ABNORMAL_CALL' flags set. 17865 17866 _function entry points_ 17867 By definition, execution of function starts at basic block 0, so 17868 there is always an edge from the `ENTRY_BLOCK_PTR' to basic block 17869 0. There is no `GIMPLE' representation for alternate entry points 17870 at this moment. In RTL, alternate entry points are specified by 17871 `CODE_LABEL' with `LABEL_ALTERNATE_NAME' defined. This feature is 17872 currently used for multiple entry point prologues and is limited 17873 to post-reload passes only. This can be used by back-ends to emit 17874 alternate prologues for functions called from different contexts. 17875 In future full support for multiple entry functions defined by 17876 Fortran 90 needs to be implemented. 17877 17878 _function exits_ 17879 In the pre-reload representation a function terminates after the 17880 last instruction in the insn chain and no explicit return 17881 instructions are used. This corresponds to the fall-thru edge 17882 into exit block. After reload, optimal RTL epilogues are used 17883 that use explicit (conditional) return instructions that are 17884 represented by edges with no flags set. 17885 17886 17887 17888 File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 17889 17890 15.3 Profile information 17891 ======================== 17892 17893 In many cases a compiler must make a choice whether to trade speed in 17894 one part of code for speed in another, or to trade code size for code 17895 speed. In such cases it is useful to know information about how often 17896 some given block will be executed. That is the purpose for maintaining 17897 profile within the flow graph. GCC can handle profile information 17898 obtained through "profile feedback", but it can also estimate branch 17899 probabilities based on statics and heuristics. 17900 17901 The feedback based profile is produced by compiling the program with 17902 instrumentation, executing it on a train run and reading the numbers of 17903 executions of basic blocks and edges back to the compiler while 17904 re-compiling the program to produce the final executable. This method 17905 provides very accurate information about where a program spends most of 17906 its time on the train run. Whether it matches the average run of 17907 course depends on the choice of train data set, but several studies 17908 have shown that the behavior of a program usually changes just 17909 marginally over different data sets. 17910 17911 When profile feedback is not available, the compiler may be asked to 17912 attempt to predict the behavior of each branch in the program using a 17913 set of heuristics (see `predict.def' for details) and compute estimated 17914 frequencies of each basic block by propagating the probabilities over 17915 the graph. 17916 17917 Each `basic_block' contains two integer fields to represent profile 17918 information: `frequency' and `count'. The `frequency' is an estimation 17919 how often is basic block executed within a function. It is represented 17920 as an integer scaled in the range from 0 to `BB_FREQ_BASE'. The most 17921 frequently executed basic block in function is initially set to 17922 `BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 17923 During optimization, the frequency of the most frequent basic block can 17924 both decrease (for instance by loop unrolling) or grow (for instance by 17925 cross-jumping optimization), so scaling sometimes has to be performed 17926 multiple times. 17927 17928 The `count' contains hard-counted numbers of execution measured during 17929 training runs and is nonzero only when profile feedback is available. 17930 This value is represented as the host's widest integer (typically a 64 17931 bit integer) of the special type `gcov_type'. 17932 17933 Most optimization passes can use only the frequency information of a 17934 basic block, but a few passes may want to know hard execution counts. 17935 The frequencies should always match the counts after scaling, however 17936 during updating of the profile information numerical error may 17937 accumulate into quite large errors. 17938 17939 Each edge also contains a branch probability field: an integer in the 17940 range from 0 to `REG_BR_PROB_BASE'. It represents probability of 17941 passing control from the end of the `src' basic block to the `dest' 17942 basic block, i.e. the probability that control will flow along this 17943 edge. The `EDGE_FREQUENCY' macro is available to compute how 17944 frequently a given edge is taken. There is a `count' field for each 17945 edge as well, representing same information as for a basic block. 17946 17947 The basic block frequencies are not represented in the instruction 17948 stream, but in the RTL representation the edge frequencies are 17949 represented for conditional jumps (via the `REG_BR_PROB' macro) since 17950 they are used when instructions are output to the assembly file and the 17951 flow graph is no longer maintained. 17952 17953 The probability that control flow arrives via a given edge to its 17954 destination basic block is called "reverse probability" and is not 17955 directly represented, but it may be easily computed from frequencies of 17956 basic blocks. 17957 17958 Updating profile information is a delicate task that can unfortunately 17959 not be easily integrated with the CFG manipulation API. Many of the 17960 functions and hooks to modify the CFG, such as 17961 `redirect_edge_and_branch', do not have enough information to easily 17962 update the profile, so updating it is in the majority of cases left up 17963 to the caller. It is difficult to uncover bugs in the profile updating 17964 code, because they manifest themselves only by producing worse code, 17965 and checking profile consistency is not possible because of numeric 17966 error accumulation. Hence special attention needs to be given to this 17967 issue in each pass that modifies the CFG. 17968 17969 It is important to point out that `REG_BR_PROB_BASE' and 17970 `BB_FREQ_BASE' are both set low enough to be possible to compute second 17971 power of any frequency or probability in the flow graph, it is not 17972 possible to even square the `count' field, as modern CPUs are fast 17973 enough to execute $2^32$ operations quickly. 17974 17975 17976 File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 17977 17978 15.4 Maintaining the CFG 17979 ======================== 17980 17981 An important task of each compiler pass is to keep both the control 17982 flow graph and all profile information up-to-date. Reconstruction of 17983 the control flow graph after each pass is not an option, since it may be 17984 very expensive and lost profile information cannot be reconstructed at 17985 all. 17986 17987 GCC has two major intermediate representations, and both use the 17988 `basic_block' and `edge' data types to represent control flow. Both 17989 representations share as much of the CFG maintenance code as possible. 17990 For each representation, a set of "hooks" is defined so that each 17991 representation can provide its own implementation of CFG manipulation 17992 routines when necessary. These hooks are defined in `cfghooks.h'. 17993 There are hooks for almost all common CFG manipulations, including 17994 block splitting and merging, edge redirection and creating and deleting 17995 basic blocks. These hooks should provide everything you need to 17996 maintain and manipulate the CFG in both the RTL and `GIMPLE' 17997 representation. 17998 17999 At the moment, the basic block boundaries are maintained transparently 18000 when modifying instructions, so there rarely is a need to move them 18001 manually (such as in case someone wants to output instruction outside 18002 basic block explicitly). 18003 18004 In the RTL representation, each instruction has a `BLOCK_FOR_INSN' 18005 value that represents pointer to the basic block that contains the 18006 instruction. In the `GIMPLE' representation, the function `gimple_bb' 18007 returns a pointer to the basic block containing the queried statement. 18008 18009 When changes need to be applied to a function in its `GIMPLE' 18010 representation, "GIMPLE statement iterators" should be used. These 18011 iterators provide an integrated abstraction of the flow graph and the 18012 instruction stream. Block statement iterators are constructed using 18013 the `gimple_stmt_iterator' data structure and several modifier are 18014 available, including the following: 18015 18016 `gsi_start' 18017 This function initializes a `gimple_stmt_iterator' that points to 18018 the first non-empty statement in a basic block. 18019 18020 `gsi_last' 18021 This function initializes a `gimple_stmt_iterator' that points to 18022 the last statement in a basic block. 18023 18024 `gsi_end_p' 18025 This predicate is `true' if a `gimple_stmt_iterator' represents 18026 the end of a basic block. 18027 18028 `gsi_next' 18029 This function takes a `gimple_stmt_iterator' and makes it point to 18030 its successor. 18031 18032 `gsi_prev' 18033 This function takes a `gimple_stmt_iterator' and makes it point to 18034 its predecessor. 18035 18036 `gsi_insert_after' 18037 This function inserts a statement after the `gimple_stmt_iterator' 18038 passed in. The final parameter determines whether the statement 18039 iterator is updated to point to the newly inserted statement, or 18040 left pointing to the original statement. 18041 18042 `gsi_insert_before' 18043 This function inserts a statement before the `gimple_stmt_iterator' 18044 passed in. The final parameter determines whether the statement 18045 iterator is updated to point to the newly inserted statement, or 18046 left pointing to the original statement. 18047 18048 `gsi_remove' 18049 This function removes the `gimple_stmt_iterator' passed in and 18050 rechains the remaining statements in a basic block, if any. 18051 18052 In the RTL representation, the macros `BB_HEAD' and `BB_END' may be 18053 used to get the head and end `rtx' of a basic block. No abstract 18054 iterators are defined for traversing the insn chain, but you can just 18055 use `NEXT_INSN' and `PREV_INSN' instead. *Note Insns::. 18056 18057 Usually a code manipulating pass simplifies the instruction stream and 18058 the flow of control, possibly eliminating some edges. This may for 18059 example happen when a conditional jump is replaced with an 18060 unconditional jump, but also when simplifying possibly trapping 18061 instruction to non-trapping while compiling Java. Updating of edges is 18062 not transparent and each optimization pass is required to do so 18063 manually. However only few cases occur in practice. The pass may call 18064 `purge_dead_edges' on a given basic block to remove superfluous edges, 18065 if any. 18066 18067 Another common scenario is redirection of branch instructions, but 18068 this is best modeled as redirection of edges in the control flow graph 18069 and thus use of `redirect_edge_and_branch' is preferred over more low 18070 level functions, such as `redirect_jump' that operate on RTL chain 18071 only. The CFG hooks defined in `cfghooks.h' should provide the 18072 complete API required for manipulating and maintaining the CFG. 18073 18074 It is also possible that a pass has to insert control flow instruction 18075 into the middle of a basic block, thus creating an entry point in the 18076 middle of the basic block, which is impossible by definition: The block 18077 must be split to make sure it only has one entry point, i.e. the head 18078 of the basic block. The CFG hook `split_block' may be used when an 18079 instruction in the middle of a basic block has to become the target of 18080 a jump or branch instruction. 18081 18082 For a global optimizer, a common operation is to split edges in the 18083 flow graph and insert instructions on them. In the RTL representation, 18084 this can be easily done using the `insert_insn_on_edge' function that 18085 emits an instruction "on the edge", caching it for a later 18086 `commit_edge_insertions' call that will take care of moving the 18087 inserted instructions off the edge into the instruction stream 18088 contained in a basic block. This includes the creation of new basic 18089 blocks where needed. In the `GIMPLE' representation, the equivalent 18090 functions are `gsi_insert_on_edge' which inserts a block statement 18091 iterator on an edge, and `gsi_commit_edge_inserts' which flushes the 18092 instruction to actual instruction stream. 18093 18094 While debugging the optimization pass, the `verify_flow_info' function 18095 may be useful to find bugs in the control flow graph updating code. 18096 18097 18098 File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 18099 18100 15.5 Liveness information 18101 ========================= 18102 18103 Liveness information is useful to determine whether some register is 18104 "live" at given point of program, i.e. that it contains a value that 18105 may be used at a later point in the program. This information is used, 18106 for instance, during register allocation, as the pseudo registers only 18107 need to be assigned to a unique hard register or to a stack slot if 18108 they are live. The hard registers and stack slots may be freely reused 18109 for other values when a register is dead. 18110 18111 Liveness information is available in the back end starting with 18112 `pass_df_initialize' and ending with `pass_df_finish'. Three flavors 18113 of live analysis are available: With `LR', it is possible to determine 18114 at any point `P' in the function if the register may be used on some 18115 path from `P' to the end of the function. With `UR', it is possible to 18116 determine if there is a path from the beginning of the function to `P' 18117 that defines the variable. `LIVE' is the intersection of the `LR' and 18118 `UR' and a variable is live at `P' if there is both an assignment that 18119 reaches it from the beginning of the function and a use that can be 18120 reached on some path from `P' to the end of the function. 18121 18122 In general `LIVE' is the most useful of the three. The macros 18123 `DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 18124 macros take a basic block number and return a bitmap that is indexed by 18125 the register number. This information is only guaranteed to be up to 18126 date after calls are made to `df_analyze'. See the file `df-core.c' 18127 for details on using the dataflow. 18128 18129 The liveness information is stored partly in the RTL instruction stream 18130 and partly in the flow graph. Local information is stored in the 18131 instruction stream: Each instruction may contain `REG_DEAD' notes 18132 representing that the value of a given register is no longer needed, or 18133 `REG_UNUSED' notes representing that the value computed by the 18134 instruction is never used. The second is useful for instructions 18135 computing multiple values at once. 18136 18137 18138 File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 18139 18140 16 Machine Descriptions 18141 *********************** 18142 18143 A machine description has two parts: a file of instruction patterns 18144 (`.md' file) and a C header file of macro definitions. 18145 18146 The `.md' file for a target machine contains a pattern for each 18147 instruction that the target machine supports (or at least each 18148 instruction that is worth telling the compiler about). It may also 18149 contain comments. A semicolon causes the rest of the line to be a 18150 comment, unless the semicolon is inside a quoted string. 18151 18152 See the next chapter for information on the C header file. 18153 18154 * Menu: 18155 18156 * Overview:: How the machine description is used. 18157 * Patterns:: How to write instruction patterns. 18158 * Example:: An explained example of a `define_insn' pattern. 18159 * RTL Template:: The RTL template defines what insns match a pattern. 18160 * Output Template:: The output template says how to make assembler code 18161 from such an insn. 18162 * Output Statement:: For more generality, write C code to output 18163 the assembler code. 18164 * Predicates:: Controlling what kinds of operands can be used 18165 for an insn. 18166 * Constraints:: Fine-tuning operand selection. 18167 * Standard Names:: Names mark patterns to use for code generation. 18168 * Pattern Ordering:: When the order of patterns makes a difference. 18169 * Dependent Patterns:: Having one pattern may make you need another. 18170 * Jump Patterns:: Special considerations for patterns for jump insns. 18171 * Looping Patterns:: How to define patterns for special looping insns. 18172 * Insn Canonicalizations::Canonicalization of Instructions 18173 * Expander Definitions::Generating a sequence of several RTL insns 18174 for a standard operation. 18175 * Insn Splitting:: Splitting Instructions into Multiple Instructions. 18176 * Including Patterns:: Including Patterns in Machine Descriptions. 18177 * Peephole Definitions::Defining machine-specific peephole optimizations. 18178 * Insn Attributes:: Specifying the value of attributes for generated insns. 18179 * Conditional Execution::Generating `define_insn' patterns for 18180 predication. 18181 * Define Subst:: Generating `define_insn' and `define_expand' 18182 patterns from other patterns. 18183 * Constant Definitions::Defining symbolic constants that can be used in the 18184 md file. 18185 * Iterators:: Using iterators to generate patterns from a template. 18186 18187 18188 File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 18189 18190 16.1 Overview of How the Machine Description is Used 18191 ==================================================== 18192 18193 There are three main conversions that happen in the compiler: 18194 18195 1. The front end reads the source code and builds a parse tree. 18196 18197 2. The parse tree is used to generate an RTL insn list based on named 18198 instruction patterns. 18199 18200 3. The insn list is matched against the RTL templates to produce 18201 assembler code. 18202 18203 18204 For the generate pass, only the names of the insns matter, from either 18205 a named `define_insn' or a `define_expand'. The compiler will choose 18206 the pattern with the right name and apply the operands according to the 18207 documentation later in this chapter, without regard for the RTL 18208 template or operand constraints. Note that the names the compiler looks 18209 for are hard-coded in the compiler--it will ignore unnamed patterns and 18210 patterns with names it doesn't know about, but if you don't provide a 18211 named pattern it needs, it will abort. 18212 18213 If a `define_insn' is used, the template given is inserted into the 18214 insn list. If a `define_expand' is used, one of three things happens, 18215 based on the condition logic. The condition logic may manually create 18216 new insns for the insn list, say via `emit_insn()', and invoke `DONE'. 18217 For certain named patterns, it may invoke `FAIL' to tell the compiler 18218 to use an alternate way of performing that task. If it invokes neither 18219 `DONE' nor `FAIL', the template given in the pattern is inserted, as if 18220 the `define_expand' were a `define_insn'. 18221 18222 Once the insn list is generated, various optimization passes convert, 18223 replace, and rearrange the insns in the insn list. This is where the 18224 `define_split' and `define_peephole' patterns get used, for example. 18225 18226 Finally, the insn list's RTL is matched up with the RTL templates in 18227 the `define_insn' patterns, and those patterns are used to emit the 18228 final assembly code. For this purpose, each named `define_insn' acts 18229 like it's unnamed, since the names are ignored. 18230 18231 18232 File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 18233 18234 16.2 Everything about Instruction Patterns 18235 ========================================== 18236 18237 Each instruction pattern contains an incomplete RTL expression, with 18238 pieces to be filled in later, operand constraints that restrict how the 18239 pieces can be filled in, and an output pattern or C code to generate 18240 the assembler output, all wrapped up in a `define_insn' expression. 18241 18242 A `define_insn' is an RTL expression containing four or five operands: 18243 18244 1. An optional name. The presence of a name indicate that this 18245 instruction pattern can perform a certain standard job for the 18246 RTL-generation pass of the compiler. This pass knows certain 18247 names and will use the instruction patterns with those names, if 18248 the names are defined in the machine description. 18249 18250 The absence of a name is indicated by writing an empty string 18251 where the name should go. Nameless instruction patterns are never 18252 used for generating RTL code, but they may permit several simpler 18253 insns to be combined later on. 18254 18255 Names that are not thus known and used in RTL-generation have no 18256 effect; they are equivalent to no name at all. 18257 18258 For the purpose of debugging the compiler, you may also specify a 18259 name beginning with the `*' character. Such a name is used only 18260 for identifying the instruction in RTL dumps; it is entirely 18261 equivalent to having a nameless pattern for all other purposes. 18262 18263 2. The "RTL template" (*note RTL Template::) is a vector of incomplete 18264 RTL expressions which show what the instruction should look like. 18265 It is incomplete because it may contain `match_operand', 18266 `match_operator', and `match_dup' expressions that stand for 18267 operands of the instruction. 18268 18269 If the vector has only one element, that element is the template 18270 for the instruction pattern. If the vector has multiple elements, 18271 then the instruction pattern is a `parallel' expression containing 18272 the elements described. 18273 18274 3. A condition. This is a string which contains a C expression that 18275 is the final test to decide whether an insn body matches this 18276 pattern. 18277 18278 For a named pattern, the condition (if present) may not depend on 18279 the data in the insn being matched, but only the 18280 target-machine-type flags. The compiler needs to test these 18281 conditions during initialization in order to learn exactly which 18282 named instructions are available in a particular run. 18283 18284 For nameless patterns, the condition is applied only when matching 18285 an individual insn, and only after the insn has matched the 18286 pattern's recognition template. The insn's operands may be found 18287 in the vector `operands'. For an insn where the condition has 18288 once matched, it can't be used to control register allocation, for 18289 example by excluding certain hard registers or hard register 18290 combinations. 18291 18292 4. The "output template": a string that says how to output matching 18293 insns as assembler code. `%' in this string specifies where to 18294 substitute the value of an operand. *Note Output Template::. 18295 18296 When simple substitution isn't general enough, you can specify a 18297 piece of C code to compute the output. *Note Output Statement::. 18298 18299 5. Optionally, a vector containing the values of attributes for insns 18300 matching this pattern. *Note Insn Attributes::. 18301 18302 18303 File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 18304 18305 16.3 Example of `define_insn' 18306 ============================= 18307 18308 Here is an actual example of an instruction pattern, for the 18309 68000/68020. 18310 18311 (define_insn "tstsi" 18312 [(set (cc0) 18313 (match_operand:SI 0 "general_operand" "rm"))] 18314 "" 18315 "* 18316 { 18317 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18318 return \"tstl %0\"; 18319 return \"cmpl #0,%0\"; 18320 }") 18321 18322 This can also be written using braced strings: 18323 18324 (define_insn "tstsi" 18325 [(set (cc0) 18326 (match_operand:SI 0 "general_operand" "rm"))] 18327 "" 18328 { 18329 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18330 return "tstl %0"; 18331 return "cmpl #0,%0"; 18332 }) 18333 18334 This is an instruction that sets the condition codes based on the 18335 value of a general operand. It has no condition, so any insn whose RTL 18336 description has the form shown may be handled according to this 18337 pattern. The name `tstsi' means "test a `SImode' value" and tells the 18338 RTL generation pass that, when it is necessary to test such a value, an 18339 insn to do so can be constructed using this pattern. 18340 18341 The output control string is a piece of C code which chooses which 18342 output template to return based on the kind of operand and the specific 18343 type of CPU for which code is being generated. 18344 18345 `"rm"' is an operand constraint. Its meaning is explained below. 18346 18347 18348 File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 18349 18350 16.4 RTL Template 18351 ================= 18352 18353 The RTL template is used to define which insns match the particular 18354 pattern and how to find their operands. For named patterns, the RTL 18355 template also says how to construct an insn from specified operands. 18356 18357 Construction involves substituting specified operands into a copy of 18358 the template. Matching involves determining the values that serve as 18359 the operands in the insn being matched. Both of these activities are 18360 controlled by special expression types that direct matching and 18361 substitution of the operands. 18362 18363 `(match_operand:M N PREDICATE CONSTRAINT)' 18364 This expression is a placeholder for operand number N of the insn. 18365 When constructing an insn, operand number N will be substituted at 18366 this point. When matching an insn, whatever appears at this 18367 position in the insn will be taken as operand number N; but it 18368 must satisfy PREDICATE or this instruction pattern will not match 18369 at all. 18370 18371 Operand numbers must be chosen consecutively counting from zero in 18372 each instruction pattern. There may be only one `match_operand' 18373 expression in the pattern for each operand number. Usually 18374 operands are numbered in the order of appearance in `match_operand' 18375 expressions. In the case of a `define_expand', any operand numbers 18376 used only in `match_dup' expressions have higher values than all 18377 other operand numbers. 18378 18379 PREDICATE is a string that is the name of a function that accepts 18380 two arguments, an expression and a machine mode. *Note 18381 Predicates::. During matching, the function will be called with 18382 the putative operand as the expression and M as the mode argument 18383 (if M is not specified, `VOIDmode' will be used, which normally 18384 causes PREDICATE to accept any mode). If it returns zero, this 18385 instruction pattern fails to match. PREDICATE may be an empty 18386 string; then it means no test is to be done on the operand, so 18387 anything which occurs in this position is valid. 18388 18389 Most of the time, PREDICATE will reject modes other than M--but 18390 not always. For example, the predicate `address_operand' uses M 18391 as the mode of memory ref that the address should be valid for. 18392 Many predicates accept `const_int' nodes even though their mode is 18393 `VOIDmode'. 18394 18395 CONSTRAINT controls reloading and the choice of the best register 18396 class to use for a value, as explained later (*note Constraints::). 18397 If the constraint would be an empty string, it can be omitted. 18398 18399 People are often unclear on the difference between the constraint 18400 and the predicate. The predicate helps decide whether a given 18401 insn matches the pattern. The constraint plays no role in this 18402 decision; instead, it controls various decisions in the case of an 18403 insn which does match. 18404 18405 `(match_scratch:M N CONSTRAINT)' 18406 This expression is also a placeholder for operand number N and 18407 indicates that operand must be a `scratch' or `reg' expression. 18408 18409 When matching patterns, this is equivalent to 18410 18411 (match_operand:M N "scratch_operand" PRED) 18412 18413 but, when generating RTL, it produces a (`scratch':M) expression. 18414 18415 If the last few expressions in a `parallel' are `clobber' 18416 expressions whose operands are either a hard register or 18417 `match_scratch', the combiner can add or delete them when 18418 necessary. *Note Side Effects::. 18419 18420 `(match_dup N)' 18421 This expression is also a placeholder for operand number N. It is 18422 used when the operand needs to appear more than once in the insn. 18423 18424 In construction, `match_dup' acts just like `match_operand': the 18425 operand is substituted into the insn being constructed. But in 18426 matching, `match_dup' behaves differently. It assumes that operand 18427 number N has already been determined by a `match_operand' 18428 appearing earlier in the recognition template, and it matches only 18429 an identical-looking expression. 18430 18431 Note that `match_dup' should not be used to tell the compiler that 18432 a particular register is being used for two operands (example: 18433 `add' that adds one register to another; the second register is 18434 both an input operand and the output operand). Use a matching 18435 constraint (*note Simple Constraints::) for those. `match_dup' is 18436 for the cases where one operand is used in two places in the 18437 template, such as an instruction that computes both a quotient and 18438 a remainder, where the opcode takes two input operands but the RTL 18439 template has to refer to each of those twice; once for the 18440 quotient pattern and once for the remainder pattern. 18441 18442 `(match_operator:M N PREDICATE [OPERANDS...])' 18443 This pattern is a kind of placeholder for a variable RTL expression 18444 code. 18445 18446 When constructing an insn, it stands for an RTL expression whose 18447 expression code is taken from that of operand N, and whose 18448 operands are constructed from the patterns OPERANDS. 18449 18450 When matching an expression, it matches an expression if the 18451 function PREDICATE returns nonzero on that expression _and_ the 18452 patterns OPERANDS match the operands of the expression. 18453 18454 Suppose that the function `commutative_operator' is defined as 18455 follows, to match any expression whose operator is one of the 18456 commutative arithmetic operators of RTL and whose mode is MODE: 18457 18458 int 18459 commutative_integer_operator (x, mode) 18460 rtx x; 18461 enum machine_mode mode; 18462 { 18463 enum rtx_code code = GET_CODE (x); 18464 if (GET_MODE (x) != mode) 18465 return 0; 18466 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 18467 || code == EQ || code == NE); 18468 } 18469 18470 Then the following pattern will match any RTL expression consisting 18471 of a commutative operator applied to two general operands: 18472 18473 (match_operator:SI 3 "commutative_operator" 18474 [(match_operand:SI 1 "general_operand" "g") 18475 (match_operand:SI 2 "general_operand" "g")]) 18476 18477 Here the vector `[OPERANDS...]' contains two patterns because the 18478 expressions to be matched all contain two operands. 18479 18480 When this pattern does match, the two operands of the commutative 18481 operator are recorded as operands 1 and 2 of the insn. (This is 18482 done by the two instances of `match_operand'.) Operand 3 of the 18483 insn will be the entire commutative expression: use `GET_CODE 18484 (operands[3])' to see which commutative operator was used. 18485 18486 The machine mode M of `match_operator' works like that of 18487 `match_operand': it is passed as the second argument to the 18488 predicate function, and that function is solely responsible for 18489 deciding whether the expression to be matched "has" that mode. 18490 18491 When constructing an insn, argument 3 of the gen-function will 18492 specify the operation (i.e. the expression code) for the 18493 expression to be made. It should be an RTL expression, whose 18494 expression code is copied into a new expression whose operands are 18495 arguments 1 and 2 of the gen-function. The subexpressions of 18496 argument 3 are not used; only its expression code matters. 18497 18498 When `match_operator' is used in a pattern for matching an insn, 18499 it usually best if the operand number of the `match_operator' is 18500 higher than that of the actual operands of the insn. This improves 18501 register allocation because the register allocator often looks at 18502 operands 1 and 2 of insns to see if it can do register tying. 18503 18504 There is no way to specify constraints in `match_operator'. The 18505 operand of the insn which corresponds to the `match_operator' 18506 never has any constraints because it is never reloaded as a whole. 18507 However, if parts of its OPERANDS are matched by `match_operand' 18508 patterns, those parts may have constraints of their own. 18509 18510 `(match_op_dup:M N[OPERANDS...])' 18511 Like `match_dup', except that it applies to operators instead of 18512 operands. When constructing an insn, operand number N will be 18513 substituted at this point. But in matching, `match_op_dup' behaves 18514 differently. It assumes that operand number N has already been 18515 determined by a `match_operator' appearing earlier in the 18516 recognition template, and it matches only an identical-looking 18517 expression. 18518 18519 `(match_parallel N PREDICATE [SUBPAT...])' 18520 This pattern is a placeholder for an insn that consists of a 18521 `parallel' expression with a variable number of elements. This 18522 expression should only appear at the top level of an insn pattern. 18523 18524 When constructing an insn, operand number N will be substituted at 18525 this point. When matching an insn, it matches if the body of the 18526 insn is a `parallel' expression with at least as many elements as 18527 the vector of SUBPAT expressions in the `match_parallel', if each 18528 SUBPAT matches the corresponding element of the `parallel', _and_ 18529 the function PREDICATE returns nonzero on the `parallel' that is 18530 the body of the insn. It is the responsibility of the predicate 18531 to validate elements of the `parallel' beyond those listed in the 18532 `match_parallel'. 18533 18534 A typical use of `match_parallel' is to match load and store 18535 multiple expressions, which can contain a variable number of 18536 elements in a `parallel'. For example, 18537 18538 (define_insn "" 18539 [(match_parallel 0 "load_multiple_operation" 18540 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 18541 (match_operand:SI 2 "memory_operand" "m")) 18542 (use (reg:SI 179)) 18543 (clobber (reg:SI 179))])] 18544 "" 18545 "loadm 0,0,%1,%2") 18546 18547 This example comes from `a29k.md'. The function 18548 `load_multiple_operation' is defined in `a29k.c' and checks that 18549 subsequent elements in the `parallel' are the same as the `set' in 18550 the pattern, except that they are referencing subsequent registers 18551 and memory locations. 18552 18553 An insn that matches this pattern might look like: 18554 18555 (parallel 18556 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 18557 (use (reg:SI 179)) 18558 (clobber (reg:SI 179)) 18559 (set (reg:SI 21) 18560 (mem:SI (plus:SI (reg:SI 100) 18561 (const_int 4)))) 18562 (set (reg:SI 22) 18563 (mem:SI (plus:SI (reg:SI 100) 18564 (const_int 8))))]) 18565 18566 `(match_par_dup N [SUBPAT...])' 18567 Like `match_op_dup', but for `match_parallel' instead of 18568 `match_operator'. 18569 18570 18571 18572 File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 18573 18574 16.5 Output Templates and Operand Substitution 18575 ============================================== 18576 18577 The "output template" is a string which specifies how to output the 18578 assembler code for an instruction pattern. Most of the template is a 18579 fixed string which is output literally. The character `%' is used to 18580 specify where to substitute an operand; it can also be used to identify 18581 places where different variants of the assembler require different 18582 syntax. 18583 18584 In the simplest case, a `%' followed by a digit N says to output 18585 operand N at that point in the string. 18586 18587 `%' followed by a letter and a digit says to output an operand in an 18588 alternate fashion. Four letters have standard, built-in meanings 18589 described below. The machine description macro `PRINT_OPERAND' can 18590 define additional letters with nonstandard meanings. 18591 18592 `%cDIGIT' can be used to substitute an operand that is a constant 18593 value without the syntax that normally indicates an immediate operand. 18594 18595 `%nDIGIT' is like `%cDIGIT' except that the value of the constant is 18596 negated before printing. 18597 18598 `%aDIGIT' can be used to substitute an operand as if it were a memory 18599 reference, with the actual operand treated as the address. This may be 18600 useful when outputting a "load address" instruction, because often the 18601 assembler syntax for such an instruction requires you to write the 18602 operand as if it were a memory reference. 18603 18604 `%lDIGIT' is used to substitute a `label_ref' into a jump instruction. 18605 18606 `%=' outputs a number which is unique to each instruction in the 18607 entire compilation. This is useful for making local labels to be 18608 referred to more than once in a single template that generates multiple 18609 assembler instructions. 18610 18611 `%' followed by a punctuation character specifies a substitution that 18612 does not use an operand. Only one case is standard: `%%' outputs a `%' 18613 into the assembler code. Other nonstandard cases can be defined in the 18614 `PRINT_OPERAND' macro. You must also define which punctuation 18615 characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. 18616 18617 The template may generate multiple assembler instructions. Write the 18618 text for the instructions, with `\;' between them. 18619 18620 When the RTL contains two operands which are required by constraint to 18621 match each other, the output template must refer only to the 18622 lower-numbered operand. Matching operands are not always identical, 18623 and the rest of the compiler arranges to put the proper RTL expression 18624 for printing into the lower-numbered operand. 18625 18626 One use of nonstandard letters or punctuation following `%' is to 18627 distinguish between different assembler languages for the same machine; 18628 for example, Motorola syntax versus MIT syntax for the 68000. Motorola 18629 syntax requires periods in most opcode names, while MIT syntax does 18630 not. For example, the opcode `movel' in MIT syntax is `move.l' in 18631 Motorola syntax. The same file of patterns is used for both kinds of 18632 output syntax, but the character sequence `%.' is used in each place 18633 where Motorola syntax wants a period. The `PRINT_OPERAND' macro for 18634 Motorola syntax defines the sequence to output a period; the macro for 18635 MIT syntax defines it to do nothing. 18636 18637 As a special case, a template consisting of the single character `#' 18638 instructs the compiler to first split the insn, and then output the 18639 resulting instructions separately. This helps eliminate redundancy in 18640 the output templates. If you have a `define_insn' that needs to emit 18641 multiple assembler instructions, and there is a matching `define_split' 18642 already defined, then you can simply use `#' as the output template 18643 instead of writing an output template that emits the multiple assembler 18644 instructions. 18645 18646 If the macro `ASSEMBLER_DIALECT' is defined, you can use construct of 18647 the form `{option0|option1|option2}' in the templates. These describe 18648 multiple variants of assembler language syntax. *Note Instruction 18649 Output::. 18650 18651 18652 File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 18653 18654 16.6 C Statements for Assembler Output 18655 ====================================== 18656 18657 Often a single fixed template string cannot produce correct and 18658 efficient assembler code for all the cases that are recognized by a 18659 single instruction pattern. For example, the opcodes may depend on the 18660 kinds of operands; or some unfortunate combinations of operands may 18661 require extra machine instructions. 18662 18663 If the output control string starts with a `@', then it is actually a 18664 series of templates, each on a separate line. (Blank lines and leading 18665 spaces and tabs are ignored.) The templates correspond to the 18666 pattern's constraint alternatives (*note Multi-Alternative::). For 18667 example, if a target machine has a two-address add instruction `addr' 18668 to add into a register and another `addm' to add a register to memory, 18669 you might write this pattern: 18670 18671 (define_insn "addsi3" 18672 [(set (match_operand:SI 0 "general_operand" "=r,m") 18673 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 18674 (match_operand:SI 2 "general_operand" "g,r")))] 18675 "" 18676 "@ 18677 addr %2,%0 18678 addm %2,%0") 18679 18680 If the output control string starts with a `*', then it is not an 18681 output template but rather a piece of C program that should compute a 18682 template. It should execute a `return' statement to return the 18683 template-string you want. Most such templates use C string literals, 18684 which require doublequote characters to delimit them. To include these 18685 doublequote characters in the string, prefix each one with `\'. 18686 18687 If the output control string is written as a brace block instead of a 18688 double-quoted string, it is automatically assumed to be C code. In that 18689 case, it is not necessary to put in a leading asterisk, or to escape the 18690 doublequotes surrounding C string literals. 18691 18692 The operands may be found in the array `operands', whose C data type 18693 is `rtx []'. 18694 18695 It is very common to select different ways of generating assembler code 18696 based on whether an immediate operand is within a certain range. Be 18697 careful when doing this, because the result of `INTVAL' is an integer 18698 on the host machine. If the host machine has more bits in an `int' 18699 than the target machine has in the mode in which the constant will be 18700 used, then some of the bits you get from `INTVAL' will be superfluous. 18701 For proper results, you must carefully disregard the values of those 18702 bits. 18703 18704 It is possible to output an assembler instruction and then go on to 18705 output or compute more of them, using the subroutine `output_asm_insn'. 18706 This receives two arguments: a template-string and a vector of 18707 operands. The vector may be `operands', or it may be another array of 18708 `rtx' that you declare locally and initialize yourself. 18709 18710 When an insn pattern has multiple alternatives in its constraints, 18711 often the appearance of the assembler code is determined mostly by 18712 which alternative was matched. When this is so, the C code can test 18713 the variable `which_alternative', which is the ordinal number of the 18714 alternative that was actually satisfied (0 for the first, 1 for the 18715 second alternative, etc.). 18716 18717 For example, suppose there are two opcodes for storing zero, `clrreg' 18718 for registers and `clrmem' for memory locations. Here is how a pattern 18719 could use `which_alternative' to choose between them: 18720 18721 (define_insn "" 18722 [(set (match_operand:SI 0 "general_operand" "=r,m") 18723 (const_int 0))] 18724 "" 18725 { 18726 return (which_alternative == 0 18727 ? "clrreg %0" : "clrmem %0"); 18728 }) 18729 18730 The example above, where the assembler code to generate was _solely_ 18731 determined by the alternative, could also have been specified as 18732 follows, having the output control string start with a `@': 18733 18734 (define_insn "" 18735 [(set (match_operand:SI 0 "general_operand" "=r,m") 18736 (const_int 0))] 18737 "" 18738 "@ 18739 clrreg %0 18740 clrmem %0") 18741 18742 If you just need a little bit of C code in one (or a few) alternatives, 18743 you can use `*' inside of a `@' multi-alternative template: 18744 18745 (define_insn "" 18746 [(set (match_operand:SI 0 "general_operand" "=r,<,m") 18747 (const_int 0))] 18748 "" 18749 "@ 18750 clrreg %0 18751 * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\"; 18752 clrmem %0") 18753 18754 18755 File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 18756 18757 16.7 Predicates 18758 =============== 18759 18760 A predicate determines whether a `match_operand' or `match_operator' 18761 expression matches, and therefore whether the surrounding instruction 18762 pattern will be used for that combination of operands. GCC has a 18763 number of machine-independent predicates, and you can define 18764 machine-specific predicates as needed. By convention, predicates used 18765 with `match_operand' have names that end in `_operand', and those used 18766 with `match_operator' have names that end in `_operator'. 18767 18768 All predicates are Boolean functions (in the mathematical sense) of 18769 two arguments: the RTL expression that is being considered at that 18770 position in the instruction pattern, and the machine mode that the 18771 `match_operand' or `match_operator' specifies. In this section, the 18772 first argument is called OP and the second argument MODE. Predicates 18773 can be called from C as ordinary two-argument functions; this can be 18774 useful in output templates or other machine-specific code. 18775 18776 Operand predicates can allow operands that are not actually acceptable 18777 to the hardware, as long as the constraints give reload the ability to 18778 fix them up (*note Constraints::). However, GCC will usually generate 18779 better code if the predicates specify the requirements of the machine 18780 instructions as closely as possible. Reload cannot fix up operands 18781 that must be constants ("immediate operands"); you must use a predicate 18782 that allows only constants, or else enforce the requirement in the 18783 extra condition. 18784 18785 Most predicates handle their MODE argument in a uniform manner. If 18786 MODE is `VOIDmode' (unspecified), then OP can have any mode. If MODE 18787 is anything else, then OP must have the same mode, unless OP is a 18788 `CONST_INT' or integer `CONST_DOUBLE'. These RTL expressions always 18789 have `VOIDmode', so it would be counterproductive to check that their 18790 mode matches. Instead, predicates that accept `CONST_INT' and/or 18791 integer `CONST_DOUBLE' check that the value stored in the constant will 18792 fit in the requested mode. 18793 18794 Predicates with this behavior are called "normal". `genrecog' can 18795 optimize the instruction recognizer based on knowledge of how normal 18796 predicates treat modes. It can also diagnose certain kinds of common 18797 errors in the use of normal predicates; for instance, it is almost 18798 always an error to use a normal predicate without specifying a mode. 18799 18800 Predicates that do something different with their MODE argument are 18801 called "special". The generic predicates `address_operand' and 18802 `pmode_register_operand' are special predicates. `genrecog' does not 18803 do any optimizations or diagnosis when special predicates are used. 18804 18805 * Menu: 18806 18807 * Machine-Independent Predicates:: Predicates available to all back ends. 18808 * Defining Predicates:: How to write machine-specific predicate 18809 functions. 18810 18811 18812 File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 18813 18814 16.7.1 Machine-Independent Predicates 18815 ------------------------------------- 18816 18817 These are the generic predicates available to all back ends. They are 18818 defined in `recog.c'. The first category of predicates allow only 18819 constant, or "immediate", operands. 18820 18821 -- Function: immediate_operand 18822 This predicate allows any sort of constant that fits in MODE. It 18823 is an appropriate choice for instructions that take operands that 18824 must be constant. 18825 18826 -- Function: const_int_operand 18827 This predicate allows any `CONST_INT' expression that fits in 18828 MODE. It is an appropriate choice for an immediate operand that 18829 does not allow a symbol or label. 18830 18831 -- Function: const_double_operand 18832 This predicate accepts any `CONST_DOUBLE' expression that has 18833 exactly MODE. If MODE is `VOIDmode', it will also accept 18834 `CONST_INT'. It is intended for immediate floating point 18835 constants. 18836 18837 The second category of predicates allow only some kind of machine 18838 register. 18839 18840 -- Function: register_operand 18841 This predicate allows any `REG' or `SUBREG' expression that is 18842 valid for MODE. It is often suitable for arithmetic instruction 18843 operands on a RISC machine. 18844 18845 -- Function: pmode_register_operand 18846 This is a slight variant on `register_operand' which works around 18847 a limitation in the machine-description reader. 18848 18849 (match_operand N "pmode_register_operand" CONSTRAINT) 18850 18851 means exactly what 18852 18853 (match_operand:P N "register_operand" CONSTRAINT) 18854 18855 would mean, if the machine-description reader accepted `:P' mode 18856 suffixes. Unfortunately, it cannot, because `Pmode' is an alias 18857 for some other mode, and might vary with machine-specific options. 18858 *Note Misc::. 18859 18860 -- Function: scratch_operand 18861 This predicate allows hard registers and `SCRATCH' expressions, 18862 but not pseudo-registers. It is used internally by 18863 `match_scratch'; it should not be used directly. 18864 18865 The third category of predicates allow only some kind of memory 18866 reference. 18867 18868 -- Function: memory_operand 18869 This predicate allows any valid reference to a quantity of mode 18870 MODE in memory, as determined by the weak form of 18871 `GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 18872 18873 -- Function: address_operand 18874 This predicate is a little unusual; it allows any operand that is a 18875 valid expression for the _address_ of a quantity of mode MODE, 18876 again determined by the weak form of `GO_IF_LEGITIMATE_ADDRESS'. 18877 To first order, if `(mem:MODE (EXP))' is acceptable to 18878 `memory_operand', then EXP is acceptable to `address_operand'. 18879 Note that EXP does not necessarily have the mode MODE. 18880 18881 -- Function: indirect_operand 18882 This is a stricter form of `memory_operand' which allows only 18883 memory references with a `general_operand' as the address 18884 expression. New uses of this predicate are discouraged, because 18885 `general_operand' is very permissive, so it's hard to tell what an 18886 `indirect_operand' does or does not allow. If a target has 18887 different requirements for memory operands for different 18888 instructions, it is better to define target-specific predicates 18889 which enforce the hardware's requirements explicitly. 18890 18891 -- Function: push_operand 18892 This predicate allows a memory reference suitable for pushing a 18893 value onto the stack. This will be a `MEM' which refers to 18894 `stack_pointer_rtx', with a side-effect in its address expression 18895 (*note Incdec::); which one is determined by the `STACK_PUSH_CODE' 18896 macro (*note Frame Layout::). 18897 18898 -- Function: pop_operand 18899 This predicate allows a memory reference suitable for popping a 18900 value off the stack. Again, this will be a `MEM' referring to 18901 `stack_pointer_rtx', with a side-effect in its address expression. 18902 However, this time `STACK_POP_CODE' is expected. 18903 18904 The fourth category of predicates allow some combination of the above 18905 operands. 18906 18907 -- Function: nonmemory_operand 18908 This predicate allows any immediate or register operand valid for 18909 MODE. 18910 18911 -- Function: nonimmediate_operand 18912 This predicate allows any register or memory operand valid for 18913 MODE. 18914 18915 -- Function: general_operand 18916 This predicate allows any immediate, register, or memory operand 18917 valid for MODE. 18918 18919 Finally, there are two generic operator predicates. 18920 18921 -- Function: comparison_operator 18922 This predicate matches any expression which performs an arithmetic 18923 comparison in MODE; that is, `COMPARISON_P' is true for the 18924 expression code. 18925 18926 -- Function: ordered_comparison_operator 18927 This predicate matches any expression which performs an arithmetic 18928 comparison in MODE and whose expression code is valid for integer 18929 modes; that is, the expression code will be one of `eq', `ne', 18930 `lt', `ltu', `le', `leu', `gt', `gtu', `ge', `geu'. 18931 18932 18933 File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 18934 18935 16.7.2 Defining Machine-Specific Predicates 18936 ------------------------------------------- 18937 18938 Many machines have requirements for their operands that cannot be 18939 expressed precisely using the generic predicates. You can define 18940 additional predicates using `define_predicate' and 18941 `define_special_predicate' expressions. These expressions have three 18942 operands: 18943 18944 * The name of the predicate, as it will be referred to in 18945 `match_operand' or `match_operator' expressions. 18946 18947 * An RTL expression which evaluates to true if the predicate allows 18948 the operand OP, false if it does not. This expression can only use 18949 the following RTL codes: 18950 18951 `MATCH_OPERAND' 18952 When written inside a predicate expression, a `MATCH_OPERAND' 18953 expression evaluates to true if the predicate it names would 18954 allow OP. The operand number and constraint are ignored. 18955 Due to limitations in `genrecog', you can only refer to 18956 generic predicates and predicates that have already been 18957 defined. 18958 18959 `MATCH_CODE' 18960 This expression evaluates to true if OP or a specified 18961 subexpression of OP has one of a given list of RTX codes. 18962 18963 The first operand of this expression is a string constant 18964 containing a comma-separated list of RTX code names (in lower 18965 case). These are the codes for which the `MATCH_CODE' will 18966 be true. 18967 18968 The second operand is a string constant which indicates what 18969 subexpression of OP to examine. If it is absent or the empty 18970 string, OP itself is examined. Otherwise, the string constant 18971 must be a sequence of digits and/or lowercase letters. Each 18972 character indicates a subexpression to extract from the 18973 current expression; for the first character this is OP, for 18974 the second and subsequent characters it is the result of the 18975 previous character. A digit N extracts `XEXP (E, N)'; a 18976 letter L extracts `XVECEXP (E, 0, N)' where N is the 18977 alphabetic ordinal of L (0 for `a', 1 for 'b', and so on). 18978 The `MATCH_CODE' then examines the RTX code of the 18979 subexpression extracted by the complete string. It is not 18980 possible to extract components of an `rtvec' that is not at 18981 position 0 within its RTX object. 18982 18983 `MATCH_TEST' 18984 This expression has one operand, a string constant containing 18985 a C expression. The predicate's arguments, OP and MODE, are 18986 available with those names in the C expression. The 18987 `MATCH_TEST' evaluates to true if the C expression evaluates 18988 to a nonzero value. `MATCH_TEST' expressions must not have 18989 side effects. 18990 18991 `AND' 18992 `IOR' 18993 `NOT' 18994 `IF_THEN_ELSE' 18995 The basic `MATCH_' expressions can be combined using these 18996 logical operators, which have the semantics of the C operators 18997 `&&', `||', `!', and `? :' respectively. As in Common Lisp, 18998 you may give an `AND' or `IOR' expression an arbitrary number 18999 of arguments; this has exactly the same effect as writing a 19000 chain of two-argument `AND' or `IOR' expressions. 19001 19002 * An optional block of C code, which should execute `return true' if 19003 the predicate is found to match and `return false' if it does not. 19004 It must not have any side effects. The predicate arguments, OP 19005 and MODE, are available with those names. 19006 19007 If a code block is present in a predicate definition, then the RTL 19008 expression must evaluate to true _and_ the code block must execute 19009 `return true' for the predicate to allow the operand. The RTL 19010 expression is evaluated first; do not re-check anything in the 19011 code block that was checked in the RTL expression. 19012 19013 The program `genrecog' scans `define_predicate' and 19014 `define_special_predicate' expressions to determine which RTX codes are 19015 possibly allowed. You should always make this explicit in the RTL 19016 predicate expression, using `MATCH_OPERAND' and `MATCH_CODE'. 19017 19018 Here is an example of a simple predicate definition, from the IA64 19019 machine description: 19020 19021 ;; True if OP is a `SYMBOL_REF' which refers to the sdata section. 19022 (define_predicate "small_addr_symbolic_operand" 19023 (and (match_code "symbol_ref") 19024 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 19025 19026 And here is another, showing the use of the C block. 19027 19028 ;; True if OP is a register operand that is (or could be) a GR reg. 19029 (define_predicate "gr_register_operand" 19030 (match_operand 0 "register_operand") 19031 { 19032 unsigned int regno; 19033 if (GET_CODE (op) == SUBREG) 19034 op = SUBREG_REG (op); 19035 19036 regno = REGNO (op); 19037 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 19038 }) 19039 19040 Predicates written with `define_predicate' automatically include a 19041 test that MODE is `VOIDmode', or OP has the same mode as MODE, or OP is 19042 a `CONST_INT' or `CONST_DOUBLE'. They do _not_ check specifically for 19043 integer `CONST_DOUBLE', nor do they test that the value of either kind 19044 of constant fits in the requested mode. This is because 19045 target-specific predicates that take constants usually have to do more 19046 stringent value checks anyway. If you need the exact same treatment of 19047 `CONST_INT' or `CONST_DOUBLE' that the generic predicates provide, use 19048 a `MATCH_OPERAND' subexpression to call `const_int_operand', 19049 `const_double_operand', or `immediate_operand'. 19050 19051 Predicates written with `define_special_predicate' do not get any 19052 automatic mode checks, and are treated as having special mode handling 19053 by `genrecog'. 19054 19055 The program `genpreds' is responsible for generating code to test 19056 predicates. It also writes a header file containing function 19057 declarations for all machine-specific predicates. It is not necessary 19058 to declare these predicates in `CPU-protos.h'. 19059 19060 19061 File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 19062 19063 16.8 Operand Constraints 19064 ======================== 19065 19066 Each `match_operand' in an instruction pattern can specify constraints 19067 for the operands allowed. The constraints allow you to fine-tune 19068 matching within the set of operands allowed by the predicate. 19069 19070 Constraints can say whether an operand may be in a register, and which 19071 kinds of register; whether the operand can be a memory reference, and 19072 which kinds of address; whether the operand may be an immediate 19073 constant, and which possible values it may have. Constraints can also 19074 require two operands to match. Side-effects aren't allowed in operands 19075 of inline `asm', unless `<' or `>' constraints are used, because there 19076 is no guarantee that the side-effects will happen exactly once in an 19077 instruction that can update the addressing register. 19078 19079 * Menu: 19080 19081 * Simple Constraints:: Basic use of constraints. 19082 * Multi-Alternative:: When an insn has two alternative constraint-patterns. 19083 * Class Preferences:: Constraints guide which hard register to put things in. 19084 * Modifiers:: More precise control over effects of constraints. 19085 * Machine Constraints:: Existing constraints for some particular machines. 19086 * Disable Insn Alternatives:: Disable insn alternatives using the `enabled' attribute. 19087 * Define Constraints:: How to define machine-specific constraints. 19088 * C Constraint Interface:: How to test constraints from C code. 19089 19090 19091 File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 19092 19093 16.8.1 Simple Constraints 19094 ------------------------- 19095 19096 The simplest kind of constraint is a string full of letters, each of 19097 which describes one kind of operand that is permitted. Here are the 19098 letters that are allowed: 19099 19100 whitespace 19101 Whitespace characters are ignored and can be inserted at any 19102 position except the first. This enables each alternative for 19103 different operands to be visually aligned in the machine 19104 description even if they have different number of constraints and 19105 modifiers. 19106 19107 `m' 19108 A memory operand is allowed, with any kind of address that the 19109 machine supports in general. Note that the letter used for the 19110 general memory constraint can be re-defined by a back end using 19111 the `TARGET_MEM_CONSTRAINT' macro. 19112 19113 `o' 19114 A memory operand is allowed, but only if the address is 19115 "offsettable". This means that adding a small integer (actually, 19116 the width in bytes of the operand, as determined by its machine 19117 mode) may be added to the address and the result is also a valid 19118 memory address. 19119 19120 For example, an address which is constant is offsettable; so is an 19121 address that is the sum of a register and a constant (as long as a 19122 slightly larger constant is also within the range of 19123 address-offsets supported by the machine); but an autoincrement or 19124 autodecrement address is not offsettable. More complicated 19125 indirect/indexed addresses may or may not be offsettable depending 19126 on the other addressing modes that the machine supports. 19127 19128 Note that in an output operand which can be matched by another 19129 operand, the constraint letter `o' is valid only when accompanied 19130 by both `<' (if the target machine has predecrement addressing) 19131 and `>' (if the target machine has preincrement addressing). 19132 19133 `V' 19134 A memory operand that is not offsettable. In other words, 19135 anything that would fit the `m' constraint but not the `o' 19136 constraint. 19137 19138 `<' 19139 A memory operand with autodecrement addressing (either 19140 predecrement or postdecrement) is allowed. In inline `asm' this 19141 constraint is only allowed if the operand is used exactly once in 19142 an instruction that can handle the side-effects. Not using an 19143 operand with `<' in constraint string in the inline `asm' pattern 19144 at all or using it in multiple instructions isn't valid, because 19145 the side-effects wouldn't be performed or would be performed more 19146 than once. Furthermore, on some targets the operand with `<' in 19147 constraint string must be accompanied by special instruction 19148 suffixes like `%U0' instruction suffix on PowerPC or `%P0' on 19149 IA-64. 19150 19151 `>' 19152 A memory operand with autoincrement addressing (either 19153 preincrement or postincrement) is allowed. In inline `asm' the 19154 same restrictions as for `<' apply. 19155 19156 `r' 19157 A register operand is allowed provided that it is in a general 19158 register. 19159 19160 `i' 19161 An immediate integer operand (one with constant value) is allowed. 19162 This includes symbolic constants whose values will be known only at 19163 assembly time or later. 19164 19165 `n' 19166 An immediate integer operand with a known numeric value is allowed. 19167 Many systems cannot support assembly-time constants for operands 19168 less than a word wide. Constraints for these operands should use 19169 `n' rather than `i'. 19170 19171 `I', `J', `K', ... `P' 19172 Other letters in the range `I' through `P' may be defined in a 19173 machine-dependent fashion to permit immediate integer operands with 19174 explicit integer values in specified ranges. For example, on the 19175 68000, `I' is defined to stand for the range of values 1 to 8. 19176 This is the range permitted as a shift count in the shift 19177 instructions. 19178 19179 `E' 19180 An immediate floating operand (expression code `const_double') is 19181 allowed, but only if the target floating point format is the same 19182 as that of the host machine (on which the compiler is running). 19183 19184 `F' 19185 An immediate floating operand (expression code `const_double' or 19186 `const_vector') is allowed. 19187 19188 `G', `H' 19189 `G' and `H' may be defined in a machine-dependent fashion to 19190 permit immediate floating operands in particular ranges of values. 19191 19192 `s' 19193 An immediate integer operand whose value is not an explicit 19194 integer is allowed. 19195 19196 This might appear strange; if an insn allows a constant operand 19197 with a value not known at compile time, it certainly must allow 19198 any known value. So why use `s' instead of `i'? Sometimes it 19199 allows better code to be generated. 19200 19201 For example, on the 68000 in a fullword instruction it is possible 19202 to use an immediate operand; but if the immediate value is between 19203 -128 and 127, better code results from loading the value into a 19204 register and using the register. This is because the load into 19205 the register can be done with a `moveq' instruction. We arrange 19206 for this to happen by defining the letter `K' to mean "any integer 19207 outside the range -128 to 127", and then specifying `Ks' in the 19208 operand constraints. 19209 19210 `g' 19211 Any register, memory or immediate integer operand is allowed, 19212 except for registers that are not general registers. 19213 19214 `X' 19215 Any operand whatsoever is allowed, even if it does not satisfy 19216 `general_operand'. This is normally used in the constraint of a 19217 `match_scratch' when certain alternatives will not actually 19218 require a scratch register. 19219 19220 `0', `1', `2', ... `9' 19221 An operand that matches the specified operand number is allowed. 19222 If a digit is used together with letters within the same 19223 alternative, the digit should come last. 19224 19225 This number is allowed to be more than a single digit. If multiple 19226 digits are encountered consecutively, they are interpreted as a 19227 single decimal integer. There is scant chance for ambiguity, 19228 since to-date it has never been desirable that `10' be interpreted 19229 as matching either operand 1 _or_ operand 0. Should this be 19230 desired, one can use multiple alternatives instead. 19231 19232 This is called a "matching constraint" and what it really means is 19233 that the assembler has only a single operand that fills two roles 19234 considered separate in the RTL insn. For example, an add insn has 19235 two input operands and one output operand in the RTL, but on most 19236 CISC machines an add instruction really has only two operands, one 19237 of them an input-output operand: 19238 19239 addl #35,r12 19240 19241 Matching constraints are used in these circumstances. More 19242 precisely, the two operands that match must include one input-only 19243 operand and one output-only operand. Moreover, the digit must be a 19244 smaller number than the number of the operand that uses it in the 19245 constraint. 19246 19247 For operands to match in a particular case usually means that they 19248 are identical-looking RTL expressions. But in a few special cases 19249 specific kinds of dissimilarity are allowed. For example, `*x' as 19250 an input operand will match `*x++' as an output operand. For 19251 proper results in such cases, the output template should always 19252 use the output-operand's number when printing the operand. 19253 19254 `p' 19255 An operand that is a valid memory address is allowed. This is for 19256 "load address" and "push address" instructions. 19257 19258 `p' in the constraint must be accompanied by `address_operand' as 19259 the predicate in the `match_operand'. This predicate interprets 19260 the mode specified in the `match_operand' as the mode of the memory 19261 reference for which the address would be valid. 19262 19263 OTHER-LETTERS 19264 Other letters can be defined in machine-dependent fashion to stand 19265 for particular classes of registers or other arbitrary operand 19266 types. `d', `a' and `f' are defined on the 68000/68020 to stand 19267 for data, address and floating point registers. 19268 19269 In order to have valid assembler code, each operand must satisfy its 19270 constraint. But a failure to do so does not prevent the pattern from 19271 applying to an insn. Instead, it directs the compiler to modify the 19272 code so that the constraint will be satisfied. Usually this is done by 19273 copying an operand into a register. 19274 19275 Contrast, therefore, the two instruction patterns that follow: 19276 19277 (define_insn "" 19278 [(set (match_operand:SI 0 "general_operand" "=r") 19279 (plus:SI (match_dup 0) 19280 (match_operand:SI 1 "general_operand" "r")))] 19281 "" 19282 "...") 19283 19284 which has two operands, one of which must appear in two places, and 19285 19286 (define_insn "" 19287 [(set (match_operand:SI 0 "general_operand" "=r") 19288 (plus:SI (match_operand:SI 1 "general_operand" "0") 19289 (match_operand:SI 2 "general_operand" "r")))] 19290 "" 19291 "...") 19292 19293 which has three operands, two of which are required by a constraint to 19294 be identical. If we are considering an insn of the form 19295 19296 (insn N PREV NEXT 19297 (set (reg:SI 3) 19298 (plus:SI (reg:SI 6) (reg:SI 109))) 19299 ...) 19300 19301 the first pattern would not apply at all, because this insn does not 19302 contain two identical subexpressions in the right place. The pattern 19303 would say, "That does not look like an add instruction; try other 19304 patterns". The second pattern would say, "Yes, that's an add 19305 instruction, but there is something wrong with it". It would direct 19306 the reload pass of the compiler to generate additional insns to make 19307 the constraint true. The results might look like this: 19308 19309 (insn N2 PREV N 19310 (set (reg:SI 3) (reg:SI 6)) 19311 ...) 19312 19313 (insn N N2 NEXT 19314 (set (reg:SI 3) 19315 (plus:SI (reg:SI 3) (reg:SI 109))) 19316 ...) 19317 19318 It is up to you to make sure that each operand, in each pattern, has 19319 constraints that can handle any RTL expression that could be present for 19320 that operand. (When multiple alternatives are in use, each pattern 19321 must, for each possible combination of operand expressions, have at 19322 least one alternative which can handle that combination of operands.) 19323 The constraints don't need to _allow_ any possible operand--when this is 19324 the case, they do not constrain--but they must at least point the way to 19325 reloading any possible operand so that it will fit. 19326 19327 * If the constraint accepts whatever operands the predicate permits, 19328 there is no problem: reloading is never necessary for this operand. 19329 19330 For example, an operand whose constraints permit everything except 19331 registers is safe provided its predicate rejects registers. 19332 19333 An operand whose predicate accepts only constant values is safe 19334 provided its constraints include the letter `i'. If any possible 19335 constant value is accepted, then nothing less than `i' will do; if 19336 the predicate is more selective, then the constraints may also be 19337 more selective. 19338 19339 * Any operand expression can be reloaded by copying it into a 19340 register. So if an operand's constraints allow some kind of 19341 register, it is certain to be safe. It need not permit all 19342 classes of registers; the compiler knows how to copy a register 19343 into another register of the proper class in order to make an 19344 instruction valid. 19345 19346 * A nonoffsettable memory reference can be reloaded by copying the 19347 address into a register. So if the constraint uses the letter 19348 `o', all memory references are taken care of. 19349 19350 * A constant operand can be reloaded by allocating space in memory to 19351 hold it as preinitialized data. Then the memory reference can be 19352 used in place of the constant. So if the constraint uses the 19353 letters `o' or `m', constant operands are not a problem. 19354 19355 * If the constraint permits a constant and a pseudo register used in 19356 an insn was not allocated to a hard register and is equivalent to 19357 a constant, the register will be replaced with the constant. If 19358 the predicate does not permit a constant and the insn is 19359 re-recognized for some reason, the compiler will crash. Thus the 19360 predicate must always recognize any objects allowed by the 19361 constraint. 19362 19363 If the operand's predicate can recognize registers, but the constraint 19364 does not permit them, it can make the compiler crash. When this 19365 operand happens to be a register, the reload pass will be stymied, 19366 because it does not know how to copy a register temporarily into memory. 19367 19368 If the predicate accepts a unary operator, the constraint applies to 19369 the operand. For example, the MIPS processor at ISA level 3 supports an 19370 instruction which adds two registers in `SImode' to produce a `DImode' 19371 result, but only if the registers are correctly sign extended. This 19372 predicate for the input operands accepts a `sign_extend' of an `SImode' 19373 register. Write the constraint to indicate the type of register that 19374 is required for the operand of the `sign_extend'. 19375 19376 19377 File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 19378 19379 16.8.2 Multiple Alternative Constraints 19380 --------------------------------------- 19381 19382 Sometimes a single instruction has multiple alternative sets of possible 19383 operands. For example, on the 68000, a logical-or instruction can 19384 combine register or an immediate value into memory, or it can combine 19385 any kind of operand into a register; but it cannot combine one memory 19386 location into another. 19387 19388 These constraints are represented as multiple alternatives. An 19389 alternative can be described by a series of letters for each operand. 19390 The overall constraint for an operand is made from the letters for this 19391 operand from the first alternative, a comma, the letters for this 19392 operand from the second alternative, a comma, and so on until the last 19393 alternative. Here is how it is done for fullword logical-or on the 19394 68000: 19395 19396 (define_insn "iorsi3" 19397 [(set (match_operand:SI 0 "general_operand" "=m,d") 19398 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 19399 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 19400 ...) 19401 19402 The first alternative has `m' (memory) for operand 0, `0' for operand 19403 1 (meaning it must match operand 0), and `dKs' for operand 2. The 19404 second alternative has `d' (data register) for operand 0, `0' for 19405 operand 1, and `dmKs' for operand 2. The `=' and `%' in the 19406 constraints apply to all the alternatives; their meaning is explained 19407 in the next section (*note Class Preferences::). 19408 19409 If all the operands fit any one alternative, the instruction is valid. 19410 Otherwise, for each alternative, the compiler counts how many 19411 instructions must be added to copy the operands so that that 19412 alternative applies. The alternative requiring the least copying is 19413 chosen. If two alternatives need the same amount of copying, the one 19414 that comes first is chosen. These choices can be altered with the `?' 19415 and `!' characters: 19416 19417 `?' 19418 Disparage slightly the alternative that the `?' appears in, as a 19419 choice when no alternative applies exactly. The compiler regards 19420 this alternative as one unit more costly for each `?' that appears 19421 in it. 19422 19423 `!' 19424 Disparage severely the alternative that the `!' appears in. This 19425 alternative can still be used if it fits without reloading, but if 19426 reloading is needed, some other alternative will be used. 19427 19428 When an insn pattern has multiple alternatives in its constraints, 19429 often the appearance of the assembler code is determined mostly by which 19430 alternative was matched. When this is so, the C code for writing the 19431 assembler code can use the variable `which_alternative', which is the 19432 ordinal number of the alternative that was actually satisfied (0 for 19433 the first, 1 for the second alternative, etc.). *Note Output 19434 Statement::. 19435 19436 19437 File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 19438 19439 16.8.3 Register Class Preferences 19440 --------------------------------- 19441 19442 The operand constraints have another function: they enable the compiler 19443 to decide which kind of hardware register a pseudo register is best 19444 allocated to. The compiler examines the constraints that apply to the 19445 insns that use the pseudo register, looking for the machine-dependent 19446 letters such as `d' and `a' that specify classes of registers. The 19447 pseudo register is put in whichever class gets the most "votes". The 19448 constraint letters `g' and `r' also vote: they vote in favor of a 19449 general register. The machine description says which registers are 19450 considered general. 19451 19452 Of course, on some machines all registers are equivalent, and no 19453 register classes are defined. Then none of this complexity is relevant. 19454 19455 19456 File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 19457 19458 16.8.4 Constraint Modifier Characters 19459 ------------------------------------- 19460 19461 Here are constraint modifier characters. 19462 19463 `=' 19464 Means that this operand is write-only for this instruction: the 19465 previous value is discarded and replaced by output data. 19466 19467 `+' 19468 Means that this operand is both read and written by the 19469 instruction. 19470 19471 When the compiler fixes up the operands to satisfy the constraints, 19472 it needs to know which operands are inputs to the instruction and 19473 which are outputs from it. `=' identifies an output; `+' 19474 identifies an operand that is both input and output; all other 19475 operands are assumed to be input only. 19476 19477 If you specify `=' or `+' in a constraint, you put it in the first 19478 character of the constraint string. 19479 19480 `&' 19481 Means (in a particular alternative) that this operand is an 19482 "earlyclobber" operand, which is modified before the instruction is 19483 finished using the input operands. Therefore, this operand may 19484 not lie in a register that is used as an input operand or as part 19485 of any memory address. 19486 19487 `&' applies only to the alternative in which it is written. In 19488 constraints with multiple alternatives, sometimes one alternative 19489 requires `&' while others do not. See, for example, the `movdf' 19490 insn of the 68000. 19491 19492 An input operand can be tied to an earlyclobber operand if its only 19493 use as an input occurs before the early result is written. Adding 19494 alternatives of this form often allows GCC to produce better code 19495 when only some of the inputs can be affected by the earlyclobber. 19496 See, for example, the `mulsi3' insn of the ARM. 19497 19498 `&' does not obviate the need to write `='. 19499 19500 `%' 19501 Declares the instruction to be commutative for this operand and the 19502 following operand. This means that the compiler may interchange 19503 the two operands if that is the cheapest way to make all operands 19504 fit the constraints. This is often used in patterns for addition 19505 instructions that really have only two operands: the result must 19506 go in one of the arguments. Here for example, is how the 68000 19507 halfword-add instruction is defined: 19508 19509 (define_insn "addhi3" 19510 [(set (match_operand:HI 0 "general_operand" "=m,r") 19511 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 19512 (match_operand:HI 2 "general_operand" "di,g")))] 19513 ...) 19514 GCC can only handle one commutative pair in an asm; if you use 19515 more, the compiler may fail. Note that you need not use the 19516 modifier if the two alternatives are strictly identical; this 19517 would only waste time in the reload pass. The modifier is not 19518 operational after register allocation, so the result of 19519 `define_peephole2' and `define_split's performed after reload 19520 cannot rely on `%' to make the intended insn match. 19521 19522 `#' 19523 Says that all following characters, up to the next comma, are to be 19524 ignored as a constraint. They are significant only for choosing 19525 register preferences. 19526 19527 `*' 19528 Says that the following character should be ignored when choosing 19529 register preferences. `*' has no effect on the meaning of the 19530 constraint as a constraint, and no effect on reloading. For LRA 19531 `*' additionally disparages slightly the alternative if the 19532 following character matches the operand. 19533 19534 Here is an example: the 68000 has an instruction to sign-extend a 19535 halfword in a data register, and can also sign-extend a value by 19536 copying it into an address register. While either kind of 19537 register is acceptable, the constraints on an address-register 19538 destination are less strict, so it is best if register allocation 19539 makes an address register its goal. Therefore, `*' is used so 19540 that the `d' constraint letter (for data register) is ignored when 19541 computing register preferences. 19542 19543 (define_insn "extendhisi2" 19544 [(set (match_operand:SI 0 "general_operand" "=*d,a") 19545 (sign_extend:SI 19546 (match_operand:HI 1 "general_operand" "0,g")))] 19547 ...) 19548 19549 19550 File: gccint.info, Node: Machine Constraints, Next: Disable Insn Alternatives, Prev: Modifiers, Up: Constraints 19551 19552 16.8.5 Constraints for Particular Machines 19553 ------------------------------------------ 19554 19555 Whenever possible, you should use the general-purpose constraint letters 19556 in `asm' arguments, since they will convey meaning more readily to 19557 people reading your code. Failing that, use the constraint letters 19558 that usually have very similar meanings across architectures. The most 19559 commonly used constraints are `m' and `r' (for memory and 19560 general-purpose registers respectively; *note Simple Constraints::), and 19561 `I', usually the letter indicating the most common immediate-constant 19562 format. 19563 19564 Each architecture defines additional constraints. These constraints 19565 are used by the compiler itself for instruction generation, as well as 19566 for `asm' statements; therefore, some of the constraints are not 19567 particularly useful for `asm'. Here is a summary of some of the 19568 machine-dependent constraints available on some particular machines; it 19569 includes both constraints that are useful for `asm' and constraints 19570 that aren't. The compiler source file mentioned in the table heading 19571 for each architecture is the definitive reference for the meanings of 19572 that architecture's constraints. 19573 19574 _AArch64 family--`config/aarch64/constraints.md'_ 19575 19576 `k' 19577 The stack pointer register (`SP') 19578 19579 `w' 19580 Floating point or SIMD vector register 19581 19582 `I' 19583 Integer constant that is valid as an immediate operand in an 19584 `ADD' instruction 19585 19586 `J' 19587 Integer constant that is valid as an immediate operand in a 19588 `SUB' instruction (once negated) 19589 19590 `K' 19591 Integer constant that can be used with a 32-bit logical 19592 instruction 19593 19594 `L' 19595 Integer constant that can be used with a 64-bit logical 19596 instruction 19597 19598 `M' 19599 Integer constant that is valid as an immediate operand in a 19600 32-bit `MOV' pseudo instruction. The `MOV' may be assembled 19601 to one of several different machine instructions depending on 19602 the value 19603 19604 `N' 19605 Integer constant that is valid as an immediate operand in a 19606 64-bit `MOV' pseudo instruction 19607 19608 `S' 19609 An absolute symbolic address or a label reference 19610 19611 `Y' 19612 Floating point constant zero 19613 19614 `Z' 19615 Integer constant zero 19616 19617 `Usa' 19618 An absolute symbolic address 19619 19620 `Ush' 19621 The high part (bits 12 and upwards) of the pc-relative 19622 address of a symbol within 4GB of the instruction 19623 19624 `Q' 19625 A memory address which uses a single base register with no 19626 offset 19627 19628 `Ump' 19629 A memory address suitable for a load/store pair instruction 19630 in SI, DI, SF and DF modes 19631 19632 19633 _ARM family--`config/arm/constraints.md'_ 19634 19635 `w' 19636 VFP floating-point register 19637 19638 `G' 19639 The floating-point constant 0.0 19640 19641 `I' 19642 Integer that is valid as an immediate operand in a data 19643 processing instruction. That is, an integer in the range 0 19644 to 255 rotated by a multiple of 2 19645 19646 `J' 19647 Integer in the range -4095 to 4095 19648 19649 `K' 19650 Integer that satisfies constraint `I' when inverted (ones 19651 complement) 19652 19653 `L' 19654 Integer that satisfies constraint `I' when negated (twos 19655 complement) 19656 19657 `M' 19658 Integer in the range 0 to 32 19659 19660 `Q' 19661 A memory reference where the exact address is in a single 19662 register (``m'' is preferable for `asm' statements) 19663 19664 `R' 19665 An item in the constant pool 19666 19667 `S' 19668 A symbol in the text segment of the current file 19669 19670 `Uv' 19671 A memory reference suitable for VFP load/store insns 19672 (reg+constant offset) 19673 19674 `Uy' 19675 A memory reference suitable for iWMMXt load/store 19676 instructions. 19677 19678 `Uq' 19679 A memory reference suitable for the ARMv4 ldrsb instruction. 19680 19681 _AVR family--`config/avr/constraints.md'_ 19682 19683 `l' 19684 Registers from r0 to r15 19685 19686 `a' 19687 Registers from r16 to r23 19688 19689 `d' 19690 Registers from r16 to r31 19691 19692 `w' 19693 Registers from r24 to r31. These registers can be used in 19694 `adiw' command 19695 19696 `e' 19697 Pointer register (r26-r31) 19698 19699 `b' 19700 Base pointer register (r28-r31) 19701 19702 `q' 19703 Stack pointer register (SPH:SPL) 19704 19705 `t' 19706 Temporary register r0 19707 19708 `x' 19709 Register pair X (r27:r26) 19710 19711 `y' 19712 Register pair Y (r29:r28) 19713 19714 `z' 19715 Register pair Z (r31:r30) 19716 19717 `I' 19718 Constant greater than -1, less than 64 19719 19720 `J' 19721 Constant greater than -64, less than 1 19722 19723 `K' 19724 Constant integer 2 19725 19726 `L' 19727 Constant integer 0 19728 19729 `M' 19730 Constant that fits in 8 bits 19731 19732 `N' 19733 Constant integer -1 19734 19735 `O' 19736 Constant integer 8, 16, or 24 19737 19738 `P' 19739 Constant integer 1 19740 19741 `G' 19742 A floating point constant 0.0 19743 19744 `Q' 19745 A memory address based on Y or Z pointer with displacement. 19746 19747 _Epiphany--`config/epiphany/constraints.md'_ 19748 19749 `U16' 19750 An unsigned 16-bit constant. 19751 19752 `K' 19753 An unsigned 5-bit constant. 19754 19755 `L' 19756 A signed 11-bit constant. 19757 19758 `Cm1' 19759 A signed 11-bit constant added to -1. Can only match when 19760 the `-m1reg-REG' option is active. 19761 19762 `Cl1' 19763 Left-shift of -1, i.e., a bit mask with a block of leading 19764 ones, the rest being a block of trailing zeroes. Can only 19765 match when the `-m1reg-REG' option is active. 19766 19767 `Cr1' 19768 Right-shift of -1, i.e., a bit mask with a trailing block of 19769 ones, the rest being zeroes. Or to put it another way, one 19770 less than a power of two. Can only match when the 19771 `-m1reg-REG' option is active. 19772 19773 `Cal' 19774 Constant for arithmetic/logical operations. This is like 19775 `i', except that for position independent code, no symbols / 19776 expressions needing relocations are allowed. 19777 19778 `Csy' 19779 Symbolic constant for call/jump instruction. 19780 19781 `Rcs' 19782 The register class usable in short insns. This is a register 19783 class constraint, and can thus drive register allocation. 19784 This constraint won't match unless `-mprefer-short-insn-regs' 19785 is in effect. 19786 19787 `Rsc' 19788 The the register class of registers that can be used to hold a 19789 sibcall call address. I.e., a caller-saved register. 19790 19791 `Rct' 19792 Core control register class. 19793 19794 `Rgs' 19795 The register group usable in short insns. This constraint 19796 does not use a register class, so that it only passively 19797 matches suitable registers, and doesn't drive register 19798 allocation. 19799 19800 `Car' 19801 Constant suitable for the addsi3_r pattern. This is a valid 19802 offset For byte, halfword, or word addressing. 19803 19804 `Rra' 19805 Matches the return address if it can be replaced with the 19806 link register. 19807 19808 `Rcc' 19809 Matches the integer condition code register. 19810 19811 `Sra' 19812 Matches the return address if it is in a stack slot. 19813 19814 `Cfm' 19815 Matches control register values to switch fp mode, which are 19816 encapsulated in `UNSPEC_FP_MODE'. 19817 19818 _CR16 Architecture--`config/cr16/cr16.h'_ 19819 19820 `b' 19821 Registers from r0 to r14 (registers without stack pointer) 19822 19823 `t' 19824 Register from r0 to r11 (all 16-bit registers) 19825 19826 `p' 19827 Register from r12 to r15 (all 32-bit registers) 19828 19829 `I' 19830 Signed constant that fits in 4 bits 19831 19832 `J' 19833 Signed constant that fits in 5 bits 19834 19835 `K' 19836 Signed constant that fits in 6 bits 19837 19838 `L' 19839 Unsigned constant that fits in 4 bits 19840 19841 `M' 19842 Signed constant that fits in 32 bits 19843 19844 `N' 19845 Check for 64 bits wide constants for add/sub instructions 19846 19847 `G' 19848 Floating point constant that is legal for store immediate 19849 19850 _Hewlett-Packard PA-RISC--`config/pa/pa.h'_ 19851 19852 `a' 19853 General register 1 19854 19855 `f' 19856 Floating point register 19857 19858 `q' 19859 Shift amount register 19860 19861 `x' 19862 Floating point register (deprecated) 19863 19864 `y' 19865 Upper floating point register (32-bit), floating point 19866 register (64-bit) 19867 19868 `Z' 19869 Any register 19870 19871 `I' 19872 Signed 11-bit integer constant 19873 19874 `J' 19875 Signed 14-bit integer constant 19876 19877 `K' 19878 Integer constant that can be deposited with a `zdepi' 19879 instruction 19880 19881 `L' 19882 Signed 5-bit integer constant 19883 19884 `M' 19885 Integer constant 0 19886 19887 `N' 19888 Integer constant that can be loaded with a `ldil' instruction 19889 19890 `O' 19891 Integer constant whose value plus one is a power of 2 19892 19893 `P' 19894 Integer constant that can be used for `and' operations in 19895 `depi' and `extru' instructions 19896 19897 `S' 19898 Integer constant 31 19899 19900 `U' 19901 Integer constant 63 19902 19903 `G' 19904 Floating-point constant 0.0 19905 19906 `A' 19907 A `lo_sum' data-linkage-table memory operand 19908 19909 `Q' 19910 A memory operand that can be used as the destination operand 19911 of an integer store instruction 19912 19913 `R' 19914 A scaled or unscaled indexed memory operand 19915 19916 `T' 19917 A memory operand for floating-point loads and stores 19918 19919 `W' 19920 A register indirect memory operand 19921 19922 _picoChip family--`picochip.h'_ 19923 19924 `k' 19925 Stack register. 19926 19927 `f' 19928 Pointer register. A register which can be used to access 19929 memory without supplying an offset. Any other register can 19930 be used to access memory, but will need a constant offset. 19931 In the case of the offset being zero, it is more efficient to 19932 use a pointer register, since this reduces code size. 19933 19934 `t' 19935 A twin register. A register which may be paired with an 19936 adjacent register to create a 32-bit register. 19937 19938 `a' 19939 Any absolute memory address (e.g., symbolic constant, symbolic 19940 constant + offset). 19941 19942 `I' 19943 4-bit signed integer. 19944 19945 `J' 19946 4-bit unsigned integer. 19947 19948 `K' 19949 8-bit signed integer. 19950 19951 `M' 19952 Any constant whose absolute value is no greater than 4-bits. 19953 19954 `N' 19955 10-bit signed integer 19956 19957 `O' 19958 16-bit signed integer. 19959 19960 19961 _PowerPC and IBM RS6000--`config/rs6000/constraints.md'_ 19962 19963 `b' 19964 Address base register 19965 19966 `d' 19967 Floating point register (containing 64-bit value) 19968 19969 `f' 19970 Floating point register (containing 32-bit value) 19971 19972 `v' 19973 Altivec vector register 19974 19975 `wa' 19976 Any VSX register if the -mvsx option was used or NO_REGS. 19977 19978 `wd' 19979 VSX vector register to hold vector double data or NO_REGS. 19980 19981 `wf' 19982 VSX vector register to hold vector float data or NO_REGS. 19983 19984 `wg' 19985 If `-mmfpgpr' was used, a floating point register or NO_REGS. 19986 19987 `wl' 19988 Floating point register if the LFIWAX instruction is enabled 19989 or NO_REGS. 19990 19991 `wm' 19992 VSX register if direct move instructions are enabled, or 19993 NO_REGS. 19994 19995 `wn' 19996 No register (NO_REGS). 19997 19998 `wr' 19999 General purpose register if 64-bit instructions are enabled 20000 or NO_REGS. 20001 20002 `ws' 20003 VSX vector register to hold scalar double values or NO_REGS. 20004 20005 `wt' 20006 VSX vector register to hold 128 bit integer or NO_REGS. 20007 20008 `wu' 20009 Altivec register to use for float/32-bit int loads/stores or 20010 NO_REGS. 20011 20012 `wv' 20013 Altivec register to use for double loads/stores or NO_REGS. 20014 20015 `ww' 20016 FP or VSX register to perform float operations under `-mvsx' 20017 or NO_REGS. 20018 20019 `wx' 20020 Floating point register if the STFIWX instruction is enabled 20021 or NO_REGS. 20022 20023 `wy' 20024 VSX vector register to hold scalar float values or NO_REGS. 20025 20026 `wz' 20027 Floating point register if the LFIWZX instruction is enabled 20028 or NO_REGS. 20029 20030 `wQ' 20031 A memory address that will work with the `lq' and `stq' 20032 instructions. 20033 20034 `h' 20035 `MQ', `CTR', or `LINK' register 20036 20037 `q' 20038 `MQ' register 20039 20040 `c' 20041 `CTR' register 20042 20043 `l' 20044 `LINK' register 20045 20046 `x' 20047 `CR' register (condition register) number 0 20048 20049 `y' 20050 `CR' register (condition register) 20051 20052 `z' 20053 `XER[CA]' carry bit (part of the XER register) 20054 20055 `I' 20056 Signed 16-bit constant 20057 20058 `J' 20059 Unsigned 16-bit constant shifted left 16 bits (use `L' 20060 instead for `SImode' constants) 20061 20062 `K' 20063 Unsigned 16-bit constant 20064 20065 `L' 20066 Signed 16-bit constant shifted left 16 bits 20067 20068 `M' 20069 Constant larger than 31 20070 20071 `N' 20072 Exact power of 2 20073 20074 `O' 20075 Zero 20076 20077 `P' 20078 Constant whose negation is a signed 16-bit constant 20079 20080 `G' 20081 Floating point constant that can be loaded into a register 20082 with one instruction per word 20083 20084 `H' 20085 Integer/Floating point constant that can be loaded into a 20086 register using three instructions 20087 20088 `m' 20089 Memory operand. Normally, `m' does not allow addresses that 20090 update the base register. If `<' or `>' constraint is also 20091 used, they are allowed and therefore on PowerPC targets in 20092 that case it is only safe to use `m<>' in an `asm' statement 20093 if that `asm' statement accesses the operand exactly once. 20094 The `asm' statement must also use `%U<OPNO>' as a placeholder 20095 for the "update" flag in the corresponding load or store 20096 instruction. For example: 20097 20098 asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); 20099 20100 is correct but: 20101 20102 asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); 20103 20104 is not. 20105 20106 `es' 20107 A "stable" memory operand; that is, one which does not 20108 include any automodification of the base register. This used 20109 to be useful when `m' allowed automodification of the base 20110 register, but as those are now only allowed when `<' or `>' 20111 is used, `es' is basically the same as `m' without `<' and 20112 `>'. 20113 20114 `Q' 20115 Memory operand that is an offset from a register (it is 20116 usually better to use `m' or `es' in `asm' statements) 20117 20118 `Z' 20119 Memory operand that is an indexed or indirect from a register 20120 (it is usually better to use `m' or `es' in `asm' statements) 20121 20122 `R' 20123 AIX TOC entry 20124 20125 `a' 20126 Address operand that is an indexed or indirect from a 20127 register (`p' is preferable for `asm' statements) 20128 20129 `S' 20130 Constant suitable as a 64-bit mask operand 20131 20132 `T' 20133 Constant suitable as a 32-bit mask operand 20134 20135 `U' 20136 System V Release 4 small data area reference 20137 20138 `t' 20139 AND masks that can be performed by two rldic{l, r} 20140 instructions 20141 20142 `W' 20143 Vector constant that does not require memory 20144 20145 `j' 20146 Vector constant that is all zeros. 20147 20148 20149 _Intel 386--`config/i386/constraints.md'_ 20150 20151 `R' 20152 Legacy register--the eight integer registers available on all 20153 i386 processors (`a', `b', `c', `d', `si', `di', `bp', `sp'). 20154 20155 `q' 20156 Any register accessible as `Rl'. In 32-bit mode, `a', `b', 20157 `c', and `d'; in 64-bit mode, any integer register. 20158 20159 `Q' 20160 Any register accessible as `Rh': `a', `b', `c', and `d'. 20161 20162 `l' 20163 Any register that can be used as the index in a base+index 20164 memory access: that is, any general register except the stack 20165 pointer. 20166 20167 `a' 20168 The `a' register. 20169 20170 `b' 20171 The `b' register. 20172 20173 `c' 20174 The `c' register. 20175 20176 `d' 20177 The `d' register. 20178 20179 `S' 20180 The `si' register. 20181 20182 `D' 20183 The `di' register. 20184 20185 `A' 20186 The `a' and `d' registers. This class is used for 20187 instructions that return double word results in the `ax:dx' 20188 register pair. Single word values will be allocated either 20189 in `ax' or `dx'. For example on i386 the following 20190 implements `rdtsc': 20191 20192 unsigned long long rdtsc (void) 20193 { 20194 unsigned long long tick; 20195 __asm__ __volatile__("rdtsc":"=A"(tick)); 20196 return tick; 20197 } 20198 20199 This is not correct on x86_64 as it would allocate tick in 20200 either `ax' or `dx'. You have to use the following variant 20201 instead: 20202 20203 unsigned long long rdtsc (void) 20204 { 20205 unsigned int tickl, tickh; 20206 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); 20207 return ((unsigned long long)tickh << 32)|tickl; 20208 } 20209 20210 `f' 20211 Any 80387 floating-point (stack) register. 20212 20213 `t' 20214 Top of 80387 floating-point stack (`%st(0)'). 20215 20216 `u' 20217 Second from top of 80387 floating-point stack (`%st(1)'). 20218 20219 `y' 20220 Any MMX register. 20221 20222 `x' 20223 Any SSE register. 20224 20225 `Yz' 20226 First SSE register (`%xmm0'). 20227 20228 `Y2' 20229 Any SSE register, when SSE2 is enabled. 20230 20231 `Yi' 20232 Any SSE register, when SSE2 and inter-unit moves are enabled. 20233 20234 `Ym' 20235 Any MMX register, when inter-unit moves are enabled. 20236 20237 `I' 20238 Integer constant in the range 0 ... 31, for 32-bit shifts. 20239 20240 `J' 20241 Integer constant in the range 0 ... 63, for 64-bit shifts. 20242 20243 `K' 20244 Signed 8-bit integer constant. 20245 20246 `L' 20247 `0xFF' or `0xFFFF', for andsi as a zero-extending move. 20248 20249 `M' 20250 0, 1, 2, or 3 (shifts for the `lea' instruction). 20251 20252 `N' 20253 Unsigned 8-bit integer constant (for `in' and `out' 20254 instructions). 20255 20256 `O' 20257 Integer constant in the range 0 ... 127, for 128-bit shifts. 20258 20259 `G' 20260 Standard 80387 floating point constant. 20261 20262 `C' 20263 Standard SSE floating point constant. 20264 20265 `e' 20266 32-bit signed integer constant, or a symbolic reference known 20267 to fit that range (for immediate operands in sign-extending 20268 x86-64 instructions). 20269 20270 `Z' 20271 32-bit unsigned integer constant, or a symbolic reference 20272 known to fit that range (for immediate operands in 20273 zero-extending x86-64 instructions). 20274 20275 20276 _Intel IA-64--`config/ia64/ia64.h'_ 20277 20278 `a' 20279 General register `r0' to `r3' for `addl' instruction 20280 20281 `b' 20282 Branch register 20283 20284 `c' 20285 Predicate register (`c' as in "conditional") 20286 20287 `d' 20288 Application register residing in M-unit 20289 20290 `e' 20291 Application register residing in I-unit 20292 20293 `f' 20294 Floating-point register 20295 20296 `m' 20297 Memory operand. If used together with `<' or `>', the 20298 operand can have postincrement and postdecrement which 20299 require printing with `%Pn' on IA-64. 20300 20301 `G' 20302 Floating-point constant 0.0 or 1.0 20303 20304 `I' 20305 14-bit signed integer constant 20306 20307 `J' 20308 22-bit signed integer constant 20309 20310 `K' 20311 8-bit signed integer constant for logical instructions 20312 20313 `L' 20314 8-bit adjusted signed integer constant for compare pseudo-ops 20315 20316 `M' 20317 6-bit unsigned integer constant for shift counts 20318 20319 `N' 20320 9-bit signed integer constant for load and store 20321 postincrements 20322 20323 `O' 20324 The constant zero 20325 20326 `P' 20327 0 or -1 for `dep' instruction 20328 20329 `Q' 20330 Non-volatile memory for floating-point loads and stores 20331 20332 `R' 20333 Integer constant in the range 1 to 4 for `shladd' instruction 20334 20335 `S' 20336 Memory operand except postincrement and postdecrement. This 20337 is now roughly the same as `m' when not used together with `<' 20338 or `>'. 20339 20340 _FRV--`config/frv/frv.h'_ 20341 20342 `a' 20343 Register in the class `ACC_REGS' (`acc0' to `acc7'). 20344 20345 `b' 20346 Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7'). 20347 20348 `c' 20349 Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0' 20350 to `icc3'). 20351 20352 `d' 20353 Register in the class `GPR_REGS' (`gr0' to `gr63'). 20354 20355 `e' 20356 Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd 20357 registers are excluded not in the class but through the use 20358 of a machine mode larger than 4 bytes. 20359 20360 `f' 20361 Register in the class `FPR_REGS' (`fr0' to `fr63'). 20362 20363 `h' 20364 Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd 20365 registers are excluded not in the class but through the use 20366 of a machine mode larger than 4 bytes. 20367 20368 `l' 20369 Register in the class `LR_REG' (the `lr' register). 20370 20371 `q' 20372 Register in the class `QUAD_REGS' (`gr2' to `gr63'). 20373 Register numbers not divisible by 4 are excluded not in the 20374 class but through the use of a machine mode larger than 8 20375 bytes. 20376 20377 `t' 20378 Register in the class `ICC_REGS' (`icc0' to `icc3'). 20379 20380 `u' 20381 Register in the class `FCC_REGS' (`fcc0' to `fcc3'). 20382 20383 `v' 20384 Register in the class `ICR_REGS' (`cc4' to `cc7'). 20385 20386 `w' 20387 Register in the class `FCR_REGS' (`cc0' to `cc3'). 20388 20389 `x' 20390 Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63'). 20391 Register numbers not divisible by 4 are excluded not in the 20392 class but through the use of a machine mode larger than 8 20393 bytes. 20394 20395 `z' 20396 Register in the class `SPR_REGS' (`lcr' and `lr'). 20397 20398 `A' 20399 Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7'). 20400 20401 `B' 20402 Register in the class `ACCG_REGS' (`accg0' to `accg7'). 20403 20404 `C' 20405 Register in the class `CR_REGS' (`cc0' to `cc7'). 20406 20407 `G' 20408 Floating point constant zero 20409 20410 `I' 20411 6-bit signed integer constant 20412 20413 `J' 20414 10-bit signed integer constant 20415 20416 `L' 20417 16-bit signed integer constant 20418 20419 `M' 20420 16-bit unsigned integer constant 20421 20422 `N' 20423 12-bit signed integer constant that is negative--i.e. in the 20424 range of -2048 to -1 20425 20426 `O' 20427 Constant zero 20428 20429 `P' 20430 12-bit signed integer constant that is greater than 20431 zero--i.e. in the range of 1 to 2047. 20432 20433 20434 _Blackfin family--`config/bfin/constraints.md'_ 20435 20436 `a' 20437 P register 20438 20439 `d' 20440 D register 20441 20442 `z' 20443 A call clobbered P register. 20444 20445 `qN' 20446 A single register. If N is in the range 0 to 7, the 20447 corresponding D register. If it is `A', then the register P0. 20448 20449 `D' 20450 Even-numbered D register 20451 20452 `W' 20453 Odd-numbered D register 20454 20455 `e' 20456 Accumulator register. 20457 20458 `A' 20459 Even-numbered accumulator register. 20460 20461 `B' 20462 Odd-numbered accumulator register. 20463 20464 `b' 20465 I register 20466 20467 `v' 20468 B register 20469 20470 `f' 20471 M register 20472 20473 `c' 20474 Registers used for circular buffering, i.e. I, B, or L 20475 registers. 20476 20477 `C' 20478 The CC register. 20479 20480 `t' 20481 LT0 or LT1. 20482 20483 `k' 20484 LC0 or LC1. 20485 20486 `u' 20487 LB0 or LB1. 20488 20489 `x' 20490 Any D, P, B, M, I or L register. 20491 20492 `y' 20493 Additional registers typically used only in prologues and 20494 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 20495 USP. 20496 20497 `w' 20498 Any register except accumulators or CC. 20499 20500 `Ksh' 20501 Signed 16 bit integer (in the range -32768 to 32767) 20502 20503 `Kuh' 20504 Unsigned 16 bit integer (in the range 0 to 65535) 20505 20506 `Ks7' 20507 Signed 7 bit integer (in the range -64 to 63) 20508 20509 `Ku7' 20510 Unsigned 7 bit integer (in the range 0 to 127) 20511 20512 `Ku5' 20513 Unsigned 5 bit integer (in the range 0 to 31) 20514 20515 `Ks4' 20516 Signed 4 bit integer (in the range -8 to 7) 20517 20518 `Ks3' 20519 Signed 3 bit integer (in the range -3 to 4) 20520 20521 `Ku3' 20522 Unsigned 3 bit integer (in the range 0 to 7) 20523 20524 `PN' 20525 Constant N, where N is a single-digit constant in the range 0 20526 to 4. 20527 20528 `PA' 20529 An integer equal to one of the MACFLAG_XXX constants that is 20530 suitable for use with either accumulator. 20531 20532 `PB' 20533 An integer equal to one of the MACFLAG_XXX constants that is 20534 suitable for use only with accumulator A1. 20535 20536 `M1' 20537 Constant 255. 20538 20539 `M2' 20540 Constant 65535. 20541 20542 `J' 20543 An integer constant with exactly a single bit set. 20544 20545 `L' 20546 An integer constant with all bits set except exactly one. 20547 20548 `H' 20549 20550 `Q' 20551 Any SYMBOL_REF. 20552 20553 _M32C--`config/m32c/m32c.c'_ 20554 20555 `Rsp' 20556 `Rfb' 20557 `Rsb' 20558 `$sp', `$fb', `$sb'. 20559 20560 `Rcr' 20561 Any control register, when they're 16 bits wide (nothing if 20562 control registers are 24 bits wide) 20563 20564 `Rcl' 20565 Any control register, when they're 24 bits wide. 20566 20567 `R0w' 20568 `R1w' 20569 `R2w' 20570 `R3w' 20571 $r0, $r1, $r2, $r3. 20572 20573 `R02' 20574 $r0 or $r2, or $r2r0 for 32 bit values. 20575 20576 `R13' 20577 $r1 or $r3, or $r3r1 for 32 bit values. 20578 20579 `Rdi' 20580 A register that can hold a 64 bit value. 20581 20582 `Rhl' 20583 $r0 or $r1 (registers with addressable high/low bytes) 20584 20585 `R23' 20586 $r2 or $r3 20587 20588 `Raa' 20589 Address registers 20590 20591 `Raw' 20592 Address registers when they're 16 bits wide. 20593 20594 `Ral' 20595 Address registers when they're 24 bits wide. 20596 20597 `Rqi' 20598 Registers that can hold QI values. 20599 20600 `Rad' 20601 Registers that can be used with displacements ($a0, $a1, $sb). 20602 20603 `Rsi' 20604 Registers that can hold 32 bit values. 20605 20606 `Rhi' 20607 Registers that can hold 16 bit values. 20608 20609 `Rhc' 20610 Registers chat can hold 16 bit values, including all control 20611 registers. 20612 20613 `Rra' 20614 $r0 through R1, plus $a0 and $a1. 20615 20616 `Rfl' 20617 The flags register. 20618 20619 `Rmm' 20620 The memory-based pseudo-registers $mem0 through $mem15. 20621 20622 `Rpi' 20623 Registers that can hold pointers (16 bit registers for r8c, 20624 m16c; 24 bit registers for m32cm, m32c). 20625 20626 `Rpa' 20627 Matches multiple registers in a PARALLEL to form a larger 20628 register. Used to match function return values. 20629 20630 `Is3' 20631 -8 ... 7 20632 20633 `IS1' 20634 -128 ... 127 20635 20636 `IS2' 20637 -32768 ... 32767 20638 20639 `IU2' 20640 0 ... 65535 20641 20642 `In4' 20643 -8 ... -1 or 1 ... 8 20644 20645 `In5' 20646 -16 ... -1 or 1 ... 16 20647 20648 `In6' 20649 -32 ... -1 or 1 ... 32 20650 20651 `IM2' 20652 -65536 ... -1 20653 20654 `Ilb' 20655 An 8 bit value with exactly one bit set. 20656 20657 `Ilw' 20658 A 16 bit value with exactly one bit set. 20659 20660 `Sd' 20661 The common src/dest memory addressing modes. 20662 20663 `Sa' 20664 Memory addressed using $a0 or $a1. 20665 20666 `Si' 20667 Memory addressed with immediate addresses. 20668 20669 `Ss' 20670 Memory addressed using the stack pointer ($sp). 20671 20672 `Sf' 20673 Memory addressed using the frame base register ($fb). 20674 20675 `Ss' 20676 Memory addressed using the small base register ($sb). 20677 20678 `S1' 20679 $r1h 20680 20681 _MeP--`config/mep/constraints.md'_ 20682 20683 `a' 20684 The $sp register. 20685 20686 `b' 20687 The $tp register. 20688 20689 `c' 20690 Any control register. 20691 20692 `d' 20693 Either the $hi or the $lo register. 20694 20695 `em' 20696 Coprocessor registers that can be directly loaded ($c0-$c15). 20697 20698 `ex' 20699 Coprocessor registers that can be moved to each other. 20700 20701 `er' 20702 Coprocessor registers that can be moved to core registers. 20703 20704 `h' 20705 The $hi register. 20706 20707 `j' 20708 The $rpc register. 20709 20710 `l' 20711 The $lo register. 20712 20713 `t' 20714 Registers which can be used in $tp-relative addressing. 20715 20716 `v' 20717 The $gp register. 20718 20719 `x' 20720 The coprocessor registers. 20721 20722 `y' 20723 The coprocessor control registers. 20724 20725 `z' 20726 The $0 register. 20727 20728 `A' 20729 User-defined register set A. 20730 20731 `B' 20732 User-defined register set B. 20733 20734 `C' 20735 User-defined register set C. 20736 20737 `D' 20738 User-defined register set D. 20739 20740 `I' 20741 Offsets for $gp-rel addressing. 20742 20743 `J' 20744 Constants that can be used directly with boolean insns. 20745 20746 `K' 20747 Constants that can be moved directly to registers. 20748 20749 `L' 20750 Small constants that can be added to registers. 20751 20752 `M' 20753 Long shift counts. 20754 20755 `N' 20756 Small constants that can be compared to registers. 20757 20758 `O' 20759 Constants that can be loaded into the top half of registers. 20760 20761 `S' 20762 Signed 8-bit immediates. 20763 20764 `T' 20765 Symbols encoded for $tp-rel or $gp-rel addressing. 20766 20767 `U' 20768 Non-constant addresses for loading/saving coprocessor 20769 registers. 20770 20771 `W' 20772 The top half of a symbol's value. 20773 20774 `Y' 20775 A register indirect address without offset. 20776 20777 `Z' 20778 Symbolic references to the control bus. 20779 20780 20781 _MicroBlaze--`config/microblaze/constraints.md'_ 20782 20783 `d' 20784 A general register (`r0' to `r31'). 20785 20786 `z' 20787 A status register (`rmsr', `$fcc1' to `$fcc7'). 20788 20789 20790 _MIPS--`config/mips/constraints.md'_ 20791 20792 `d' 20793 An address register. This is equivalent to `r' unless 20794 generating MIPS16 code. 20795 20796 `f' 20797 A floating-point register (if available). 20798 20799 `h' 20800 Formerly the `hi' register. This constraint is no longer 20801 supported. 20802 20803 `l' 20804 The `lo' register. Use this register to store values that are 20805 no bigger than a word. 20806 20807 `x' 20808 The concatenated `hi' and `lo' registers. Use this register 20809 to store doubleword values. 20810 20811 `c' 20812 A register suitable for use in an indirect jump. This will 20813 always be `$25' for `-mabicalls'. 20814 20815 `v' 20816 Register `$3'. Do not use this constraint in new code; it is 20817 retained only for compatibility with glibc. 20818 20819 `y' 20820 Equivalent to `r'; retained for backwards compatibility. 20821 20822 `z' 20823 A floating-point condition code register. 20824 20825 `I' 20826 A signed 16-bit constant (for arithmetic instructions). 20827 20828 `J' 20829 Integer zero. 20830 20831 `K' 20832 An unsigned 16-bit constant (for logic instructions). 20833 20834 `L' 20835 A signed 32-bit constant in which the lower 16 bits are zero. 20836 Such constants can be loaded using `lui'. 20837 20838 `M' 20839 A constant that cannot be loaded using `lui', `addiu' or 20840 `ori'. 20841 20842 `N' 20843 A constant in the range -65535 to -1 (inclusive). 20844 20845 `O' 20846 A signed 15-bit constant. 20847 20848 `P' 20849 A constant in the range 1 to 65535 (inclusive). 20850 20851 `G' 20852 Floating-point zero. 20853 20854 `R' 20855 An address that can be used in a non-macro load or store. 20856 20857 _Motorola 680x0--`config/m68k/constraints.md'_ 20858 20859 `a' 20860 Address register 20861 20862 `d' 20863 Data register 20864 20865 `f' 20866 68881 floating-point register, if available 20867 20868 `I' 20869 Integer in the range 1 to 8 20870 20871 `J' 20872 16-bit signed number 20873 20874 `K' 20875 Signed number whose magnitude is greater than 0x80 20876 20877 `L' 20878 Integer in the range -8 to -1 20879 20880 `M' 20881 Signed number whose magnitude is greater than 0x100 20882 20883 `N' 20884 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 20885 20886 `O' 20887 16 (for rotate using swap) 20888 20889 `P' 20890 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 20891 20892 `R' 20893 Numbers that mov3q can handle 20894 20895 `G' 20896 Floating point constant that is not a 68881 constant 20897 20898 `S' 20899 Operands that satisfy 'm' when -mpcrel is in effect 20900 20901 `T' 20902 Operands that satisfy 's' when -mpcrel is not in effect 20903 20904 `Q' 20905 Address register indirect addressing mode 20906 20907 `U' 20908 Register offset addressing 20909 20910 `W' 20911 const_call_operand 20912 20913 `Cs' 20914 symbol_ref or const 20915 20916 `Ci' 20917 const_int 20918 20919 `C0' 20920 const_int 0 20921 20922 `Cj' 20923 Range of signed numbers that don't fit in 16 bits 20924 20925 `Cmvq' 20926 Integers valid for mvq 20927 20928 `Capsw' 20929 Integers valid for a moveq followed by a swap 20930 20931 `Cmvz' 20932 Integers valid for mvz 20933 20934 `Cmvs' 20935 Integers valid for mvs 20936 20937 `Ap' 20938 push_operand 20939 20940 `Ac' 20941 Non-register operands allowed in clr 20942 20943 20944 _Moxie--`config/moxie/constraints.md'_ 20945 20946 `A' 20947 An absolute address 20948 20949 `B' 20950 An offset address 20951 20952 `W' 20953 A register indirect memory operand 20954 20955 `I' 20956 A constant in the range of 0 to 255. 20957 20958 `N' 20959 A constant in the range of 0 to -255. 20960 20961 20962 _PDP-11--`config/pdp11/constraints.md'_ 20963 20964 `a' 20965 Floating point registers AC0 through AC3. These can be 20966 loaded from/to memory with a single instruction. 20967 20968 `d' 20969 Odd numbered general registers (R1, R3, R5). These are used 20970 for 16-bit multiply operations. 20971 20972 `f' 20973 Any of the floating point registers (AC0 through AC5). 20974 20975 `G' 20976 Floating point constant 0. 20977 20978 `I' 20979 An integer constant that fits in 16 bits. 20980 20981 `J' 20982 An integer constant whose low order 16 bits are zero. 20983 20984 `K' 20985 An integer constant that does not meet the constraints for 20986 codes `I' or `J'. 20987 20988 `L' 20989 The integer constant 1. 20990 20991 `M' 20992 The integer constant -1. 20993 20994 `N' 20995 The integer constant 0. 20996 20997 `O' 20998 Integer constants -4 through -1 and 1 through 4; shifts by 20999 these amounts are handled as multiple single-bit shifts 21000 rather than a single variable-length shift. 21001 21002 `Q' 21003 A memory reference which requires an additional word (address 21004 or offset) after the opcode. 21005 21006 `R' 21007 A memory reference that is encoded within the opcode. 21008 21009 21010 _RL78--`config/rl78/constraints.md'_ 21011 21012 `Int3' 21013 An integer constant in the range 1 ... 7. 21014 21015 `Int8' 21016 An integer constant in the range 0 ... 255. 21017 21018 `J' 21019 An integer constant in the range -255 ... 0 21020 21021 `K' 21022 The integer constant 1. 21023 21024 `L' 21025 The integer constant -1. 21026 21027 `M' 21028 The integer constant 0. 21029 21030 `N' 21031 The integer constant 2. 21032 21033 `O' 21034 The integer constant -2. 21035 21036 `P' 21037 An integer constant in the range 1 ... 15. 21038 21039 `Qbi' 21040 The built-in compare types-eq, ne, gtu, ltu, geu, and leu. 21041 21042 `Qsc' 21043 The synthetic compare types-gt, lt, ge, and le. 21044 21045 `Wab' 21046 A memory reference with an absolute address. 21047 21048 `Wbc' 21049 A memory reference using `BC' as a base register, with an 21050 optional offset. 21051 21052 `Wca' 21053 A memory reference using `AX', `BC', `DE', or `HL' for the 21054 address, for calls. 21055 21056 `Wcv' 21057 A memory reference using any 16-bit register pair for the 21058 address, for calls. 21059 21060 `Wd2' 21061 A memory reference using `DE' as a base register, with an 21062 optional offset. 21063 21064 `Wde' 21065 A memory reference using `DE' as a base register, without any 21066 offset. 21067 21068 `Wfr' 21069 Any memory reference to an address in the far address space. 21070 21071 `Wh1' 21072 A memory reference using `HL' as a base register, with an 21073 optional one-byte offset. 21074 21075 `Whb' 21076 A memory reference using `HL' as a base register, with `B' or 21077 `C' as the index register. 21078 21079 `Whl' 21080 A memory reference using `HL' as a base register, without any 21081 offset. 21082 21083 `Ws1' 21084 A memory reference using `SP' as a base register, with an 21085 optional one-byte offset. 21086 21087 `Y' 21088 Any memory reference to an address in the near address space. 21089 21090 `A' 21091 The `AX' register. 21092 21093 `B' 21094 The `BC' register. 21095 21096 `D' 21097 The `DE' register. 21098 21099 `R' 21100 `A' through `L' registers. 21101 21102 `S' 21103 The `SP' register. 21104 21105 `T' 21106 The `HL' register. 21107 21108 `Z08W' 21109 The 16-bit `R8' register. 21110 21111 `Z10W' 21112 The 16-bit `R10' register. 21113 21114 `Zint' 21115 The registers reserved for interrupts (`R24' to `R31'). 21116 21117 `a' 21118 The `A' register. 21119 21120 `b' 21121 The `B' register. 21122 21123 `c' 21124 The `C' register. 21125 21126 `d' 21127 The `D' register. 21128 21129 `e' 21130 The `E' register. 21131 21132 `h' 21133 The `H' register. 21134 21135 `l' 21136 The `L' register. 21137 21138 `v' 21139 The virtual registers. 21140 21141 `w' 21142 The `PSW' register. 21143 21144 `x' 21145 The `X' register. 21146 21147 21148 _RX--`config/rx/constraints.md'_ 21149 21150 `Q' 21151 An address which does not involve register indirect 21152 addressing or pre/post increment/decrement addressing. 21153 21154 `Symbol' 21155 A symbol reference. 21156 21157 `Int08' 21158 A constant in the range -256 to 255, inclusive. 21159 21160 `Sint08' 21161 A constant in the range -128 to 127, inclusive. 21162 21163 `Sint16' 21164 A constant in the range -32768 to 32767, inclusive. 21165 21166 `Sint24' 21167 A constant in the range -8388608 to 8388607, inclusive. 21168 21169 `Uint04' 21170 A constant in the range 0 to 15, inclusive. 21171 21172 21173 _SPARC--`config/sparc/sparc.h'_ 21174 21175 `f' 21176 Floating-point register on the SPARC-V8 architecture and 21177 lower floating-point register on the SPARC-V9 architecture. 21178 21179 `e' 21180 Floating-point register. It is equivalent to `f' on the 21181 SPARC-V8 architecture and contains both lower and upper 21182 floating-point registers on the SPARC-V9 architecture. 21183 21184 `c' 21185 Floating-point condition code register. 21186 21187 `d' 21188 Lower floating-point register. It is only valid on the 21189 SPARC-V9 architecture when the Visual Instruction Set is 21190 available. 21191 21192 `b' 21193 Floating-point register. It is only valid on the SPARC-V9 21194 architecture when the Visual Instruction Set is available. 21195 21196 `h' 21197 64-bit global or out register for the SPARC-V8+ architecture. 21198 21199 `C' 21200 The constant all-ones, for floating-point. 21201 21202 `A' 21203 Signed 5-bit constant 21204 21205 `D' 21206 A vector constant 21207 21208 `I' 21209 Signed 13-bit constant 21210 21211 `J' 21212 Zero 21213 21214 `K' 21215 32-bit constant with the low 12 bits clear (a constant that 21216 can be loaded with the `sethi' instruction) 21217 21218 `L' 21219 A constant in the range supported by `movcc' instructions 21220 (11-bit signed immediate) 21221 21222 `M' 21223 A constant in the range supported by `movrcc' instructions 21224 (10-bit signed immediate) 21225 21226 `N' 21227 Same as `K', except that it verifies that bits that are not 21228 in the lower 32-bit range are all zero. Must be used instead 21229 of `K' for modes wider than `SImode' 21230 21231 `O' 21232 The constant 4096 21233 21234 `G' 21235 Floating-point zero 21236 21237 `H' 21238 Signed 13-bit constant, sign-extended to 32 or 64 bits 21239 21240 `P' 21241 The constant -1 21242 21243 `Q' 21244 Floating-point constant whose integral representation can be 21245 moved into an integer register using a single sethi 21246 instruction 21247 21248 `R' 21249 Floating-point constant whose integral representation can be 21250 moved into an integer register using a single mov instruction 21251 21252 `S' 21253 Floating-point constant whose integral representation can be 21254 moved into an integer register using a high/lo_sum 21255 instruction sequence 21256 21257 `T' 21258 Memory address aligned to an 8-byte boundary 21259 21260 `U' 21261 Even register 21262 21263 `W' 21264 Memory address for `e' constraint registers 21265 21266 `w' 21267 Memory address with only a base register 21268 21269 `Y' 21270 Vector zero 21271 21272 21273 _SPU--`config/spu/spu.h'_ 21274 21275 `a' 21276 An immediate which can be loaded with the il/ila/ilh/ilhu 21277 instructions. const_int is treated as a 64 bit value. 21278 21279 `c' 21280 An immediate for and/xor/or instructions. const_int is 21281 treated as a 64 bit value. 21282 21283 `d' 21284 An immediate for the `iohl' instruction. const_int is 21285 treated as a 64 bit value. 21286 21287 `f' 21288 An immediate which can be loaded with `fsmbi'. 21289 21290 `A' 21291 An immediate which can be loaded with the il/ila/ilh/ilhu 21292 instructions. const_int is treated as a 32 bit value. 21293 21294 `B' 21295 An immediate for most arithmetic instructions. const_int is 21296 treated as a 32 bit value. 21297 21298 `C' 21299 An immediate for and/xor/or instructions. const_int is 21300 treated as a 32 bit value. 21301 21302 `D' 21303 An immediate for the `iohl' instruction. const_int is 21304 treated as a 32 bit value. 21305 21306 `I' 21307 A constant in the range [-64, 63] for shift/rotate 21308 instructions. 21309 21310 `J' 21311 An unsigned 7-bit constant for conversion/nop/channel 21312 instructions. 21313 21314 `K' 21315 A signed 10-bit constant for most arithmetic instructions. 21316 21317 `M' 21318 A signed 16 bit immediate for `stop'. 21319 21320 `N' 21321 An unsigned 16-bit constant for `iohl' and `fsmbi'. 21322 21323 `O' 21324 An unsigned 7-bit constant whose 3 least significant bits are 21325 0. 21326 21327 `P' 21328 An unsigned 3-bit constant for 16-byte rotates and shifts 21329 21330 `R' 21331 Call operand, reg, for indirect calls 21332 21333 `S' 21334 Call operand, symbol, for relative calls. 21335 21336 `T' 21337 Call operand, const_int, for absolute calls. 21338 21339 `U' 21340 An immediate which can be loaded with the il/ila/ilh/ilhu 21341 instructions. const_int is sign extended to 128 bit. 21342 21343 `W' 21344 An immediate for shift and rotate instructions. const_int is 21345 treated as a 32 bit value. 21346 21347 `Y' 21348 An immediate for and/xor/or instructions. const_int is sign 21349 extended as a 128 bit. 21350 21351 `Z' 21352 An immediate for the `iohl' instruction. const_int is sign 21353 extended to 128 bit. 21354 21355 21356 _S/390 and zSeries--`config/s390/s390.h'_ 21357 21358 `a' 21359 Address register (general purpose register except r0) 21360 21361 `c' 21362 Condition code register 21363 21364 `d' 21365 Data register (arbitrary general purpose register) 21366 21367 `f' 21368 Floating-point register 21369 21370 `I' 21371 Unsigned 8-bit constant (0-255) 21372 21373 `J' 21374 Unsigned 12-bit constant (0-4095) 21375 21376 `K' 21377 Signed 16-bit constant (-32768-32767) 21378 21379 `L' 21380 Value appropriate as displacement. 21381 `(0..4095)' 21382 for short displacement 21383 21384 `(-524288..524287)' 21385 for long displacement 21386 21387 `M' 21388 Constant integer with a value of 0x7fffffff. 21389 21390 `N' 21391 Multiple letter constraint followed by 4 parameter letters. 21392 `0..9:' 21393 number of the part counting from most to least 21394 significant 21395 21396 `H,Q:' 21397 mode of the part 21398 21399 `D,S,H:' 21400 mode of the containing operand 21401 21402 `0,F:' 21403 value of the other parts (F--all bits set) 21404 The constraint matches if the specified part of a constant 21405 has a value different from its other parts. 21406 21407 `Q' 21408 Memory reference without index register and with short 21409 displacement. 21410 21411 `R' 21412 Memory reference with index register and short displacement. 21413 21414 `S' 21415 Memory reference without index register but with long 21416 displacement. 21417 21418 `T' 21419 Memory reference with index register and long displacement. 21420 21421 `U' 21422 Pointer with short displacement. 21423 21424 `W' 21425 Pointer with long displacement. 21426 21427 `Y' 21428 Shift count operand. 21429 21430 21431 _Score family--`config/score/score.h'_ 21432 21433 `d' 21434 Registers from r0 to r32. 21435 21436 `e' 21437 Registers from r0 to r16. 21438 21439 `t' 21440 r8--r11 or r22--r27 registers. 21441 21442 `h' 21443 hi register. 21444 21445 `l' 21446 lo register. 21447 21448 `x' 21449 hi + lo register. 21450 21451 `q' 21452 cnt register. 21453 21454 `y' 21455 lcb register. 21456 21457 `z' 21458 scb register. 21459 21460 `a' 21461 cnt + lcb + scb register. 21462 21463 `c' 21464 cr0--cr15 register. 21465 21466 `b' 21467 cp1 registers. 21468 21469 `f' 21470 cp2 registers. 21471 21472 `i' 21473 cp3 registers. 21474 21475 `j' 21476 cp1 + cp2 + cp3 registers. 21477 21478 `I' 21479 High 16-bit constant (32-bit constant with 16 LSBs zero). 21480 21481 `J' 21482 Unsigned 5 bit integer (in the range 0 to 31). 21483 21484 `K' 21485 Unsigned 16 bit integer (in the range 0 to 65535). 21486 21487 `L' 21488 Signed 16 bit integer (in the range -32768 to 32767). 21489 21490 `M' 21491 Unsigned 14 bit integer (in the range 0 to 16383). 21492 21493 `N' 21494 Signed 14 bit integer (in the range -8192 to 8191). 21495 21496 `Z' 21497 Any SYMBOL_REF. 21498 21499 _Xstormy16--`config/stormy16/stormy16.h'_ 21500 21501 `a' 21502 Register r0. 21503 21504 `b' 21505 Register r1. 21506 21507 `c' 21508 Register r2. 21509 21510 `d' 21511 Register r8. 21512 21513 `e' 21514 Registers r0 through r7. 21515 21516 `t' 21517 Registers r0 and r1. 21518 21519 `y' 21520 The carry register. 21521 21522 `z' 21523 Registers r8 and r9. 21524 21525 `I' 21526 A constant between 0 and 3 inclusive. 21527 21528 `J' 21529 A constant that has exactly one bit set. 21530 21531 `K' 21532 A constant that has exactly one bit clear. 21533 21534 `L' 21535 A constant between 0 and 255 inclusive. 21536 21537 `M' 21538 A constant between -255 and 0 inclusive. 21539 21540 `N' 21541 A constant between -3 and 0 inclusive. 21542 21543 `O' 21544 A constant between 1 and 4 inclusive. 21545 21546 `P' 21547 A constant between -4 and -1 inclusive. 21548 21549 `Q' 21550 A memory reference that is a stack push. 21551 21552 `R' 21553 A memory reference that is a stack pop. 21554 21555 `S' 21556 A memory reference that refers to a constant address of known 21557 value. 21558 21559 `T' 21560 The register indicated by Rx (not implemented yet). 21561 21562 `U' 21563 A constant that is not between 2 and 15 inclusive. 21564 21565 `Z' 21566 The constant 0. 21567 21568 21569 _TI C6X family--`config/c6x/constraints.md'_ 21570 21571 `a' 21572 Register file A (A0-A31). 21573 21574 `b' 21575 Register file B (B0-B31). 21576 21577 `A' 21578 Predicate registers in register file A (A0-A2 on C64X and 21579 higher, A1 and A2 otherwise). 21580 21581 `B' 21582 Predicate registers in register file B (B0-B2). 21583 21584 `C' 21585 A call-used register in register file B (B0-B9, B16-B31). 21586 21587 `Da' 21588 Register file A, excluding predicate registers (A3-A31, plus 21589 A0 if not C64X or higher). 21590 21591 `Db' 21592 Register file B, excluding predicate registers (B3-B31). 21593 21594 `Iu4' 21595 Integer constant in the range 0 ... 15. 21596 21597 `Iu5' 21598 Integer constant in the range 0 ... 31. 21599 21600 `In5' 21601 Integer constant in the range -31 ... 0. 21602 21603 `Is5' 21604 Integer constant in the range -16 ... 15. 21605 21606 `I5x' 21607 Integer constant that can be the operand of an ADDA or a SUBA 21608 insn. 21609 21610 `IuB' 21611 Integer constant in the range 0 ... 65535. 21612 21613 `IsB' 21614 Integer constant in the range -32768 ... 32767. 21615 21616 `IsC' 21617 Integer constant in the range -2^20 ... 2^20 - 1. 21618 21619 `Jc' 21620 Integer constant that is a valid mask for the clr instruction. 21621 21622 `Js' 21623 Integer constant that is a valid mask for the set instruction. 21624 21625 `Q' 21626 Memory location with A base register. 21627 21628 `R' 21629 Memory location with B base register. 21630 21631 `S0' 21632 On C64x+ targets, a GP-relative small data reference. 21633 21634 `S1' 21635 Any kind of `SYMBOL_REF', for use in a call address. 21636 21637 `Si' 21638 Any kind of immediate operand, unless it matches the S0 21639 constraint. 21640 21641 `T' 21642 Memory location with B base register, but not using a long 21643 offset. 21644 21645 `W' 21646 A memory operand with an address that can't be used in an 21647 unaligned access. 21648 21649 `Z' 21650 Register B14 (aka DP). 21651 21652 21653 _TILE-Gx--`config/tilegx/constraints.md'_ 21654 21655 `R00' 21656 `R01' 21657 `R02' 21658 `R03' 21659 `R04' 21660 `R05' 21661 `R06' 21662 `R07' 21663 `R08' 21664 `R09' 21665 `R10' 21666 Each of these represents a register constraint for an 21667 individual register, from r0 to r10. 21668 21669 `I' 21670 Signed 8-bit integer constant. 21671 21672 `J' 21673 Signed 16-bit integer constant. 21674 21675 `K' 21676 Unsigned 16-bit integer constant. 21677 21678 `L' 21679 Integer constant that fits in one signed byte when 21680 incremented by one (-129 ... 126). 21681 21682 `m' 21683 Memory operand. If used together with `<' or `>', the 21684 operand can have postincrement which requires printing with 21685 `%In' and `%in' on TILE-Gx. For example: 21686 21687 asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val)); 21688 21689 `M' 21690 A bit mask suitable for the BFINS instruction. 21691 21692 `N' 21693 Integer constant that is a byte tiled out eight times. 21694 21695 `O' 21696 The integer zero constant. 21697 21698 `P' 21699 Integer constant that is a sign-extended byte tiled out as 21700 four shorts. 21701 21702 `Q' 21703 Integer constant that fits in one signed byte when incremented 21704 (-129 ... 126), but excluding -1. 21705 21706 `S' 21707 Integer constant that has all 1 bits consecutive and starting 21708 at bit 0. 21709 21710 `T' 21711 A 16-bit fragment of a got, tls, or pc-relative reference. 21712 21713 `U' 21714 Memory operand except postincrement. This is roughly the 21715 same as `m' when not used together with `<' or `>'. 21716 21717 `W' 21718 An 8-element vector constant with identical elements. 21719 21720 `Y' 21721 A 4-element vector constant with identical elements. 21722 21723 `Z0' 21724 The integer constant 0xffffffff. 21725 21726 `Z1' 21727 The integer constant 0xffffffff00000000. 21728 21729 21730 _TILEPro--`config/tilepro/constraints.md'_ 21731 21732 `R00' 21733 `R01' 21734 `R02' 21735 `R03' 21736 `R04' 21737 `R05' 21738 `R06' 21739 `R07' 21740 `R08' 21741 `R09' 21742 `R10' 21743 Each of these represents a register constraint for an 21744 individual register, from r0 to r10. 21745 21746 `I' 21747 Signed 8-bit integer constant. 21748 21749 `J' 21750 Signed 16-bit integer constant. 21751 21752 `K' 21753 Nonzero integer constant with low 16 bits zero. 21754 21755 `L' 21756 Integer constant that fits in one signed byte when 21757 incremented by one (-129 ... 126). 21758 21759 `m' 21760 Memory operand. If used together with `<' or `>', the 21761 operand can have postincrement which requires printing with 21762 `%In' and `%in' on TILEPro. For example: 21763 21764 asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val)); 21765 21766 `M' 21767 A bit mask suitable for the MM instruction. 21768 21769 `N' 21770 Integer constant that is a byte tiled out four times. 21771 21772 `O' 21773 The integer zero constant. 21774 21775 `P' 21776 Integer constant that is a sign-extended byte tiled out as 21777 two shorts. 21778 21779 `Q' 21780 Integer constant that fits in one signed byte when incremented 21781 (-129 ... 126), but excluding -1. 21782 21783 `T' 21784 A symbolic operand, or a 16-bit fragment of a got, tls, or 21785 pc-relative reference. 21786 21787 `U' 21788 Memory operand except postincrement. This is roughly the 21789 same as `m' when not used together with `<' or `>'. 21790 21791 `W' 21792 A 4-element vector constant with identical elements. 21793 21794 `Y' 21795 A 2-element vector constant with identical elements. 21796 21797 21798 _Xtensa--`config/xtensa/constraints.md'_ 21799 21800 `a' 21801 General-purpose 32-bit register 21802 21803 `b' 21804 One-bit boolean register 21805 21806 `A' 21807 MAC16 40-bit accumulator register 21808 21809 `I' 21810 Signed 12-bit integer constant, for use in MOVI instructions 21811 21812 `J' 21813 Signed 8-bit integer constant, for use in ADDI instructions 21814 21815 `K' 21816 Integer constant valid for BccI instructions 21817 21818 `L' 21819 Unsigned constant valid for BccUI instructions 21820 21821 21822 21823 21824 File: gccint.info, Node: Disable Insn Alternatives, Next: Define Constraints, Prev: Machine Constraints, Up: Constraints 21825 21826 16.8.6 Disable insn alternatives using the `enabled' attribute 21827 -------------------------------------------------------------- 21828 21829 The `enabled' insn attribute may be used to disable certain insn 21830 alternatives for machine-specific reasons. This is useful when adding 21831 new instructions to an existing pattern which are only available for 21832 certain cpu architecture levels as specified with the `-march=' option. 21833 21834 If an insn alternative is disabled, then it will never be used. The 21835 compiler treats the constraints for the disabled alternative as 21836 unsatisfiable. 21837 21838 In order to make use of the `enabled' attribute a back end has to add 21839 in the machine description files: 21840 21841 1. A definition of the `enabled' insn attribute. The attribute is 21842 defined as usual using the `define_attr' command. This definition 21843 should be based on other insn attributes and/or target flags. The 21844 `enabled' attribute is a numeric attribute and should evaluate to 21845 `(const_int 1)' for an enabled alternative and to `(const_int 0)' 21846 otherwise. 21847 21848 2. A definition of another insn attribute used to describe for what 21849 reason an insn alternative might be available or not. E.g. 21850 `cpu_facility' as in the example below. 21851 21852 3. An assignment for the second attribute to each insn definition 21853 combining instructions which are not all available under the same 21854 circumstances. (Note: It obviously only makes sense for 21855 definitions with more than one alternative. Otherwise the insn 21856 pattern should be disabled or enabled using the insn condition.) 21857 21858 E.g. the following two patterns could easily be merged using the 21859 `enabled' attribute: 21860 21861 21862 (define_insn "*movdi_old" 21863 [(set (match_operand:DI 0 "register_operand" "=d") 21864 (match_operand:DI 1 "register_operand" " d"))] 21865 "!TARGET_NEW" 21866 "lgr %0,%1") 21867 21868 (define_insn "*movdi_new" 21869 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 21870 (match_operand:DI 1 "register_operand" " d,d,f"))] 21871 "TARGET_NEW" 21872 "@ 21873 lgr %0,%1 21874 ldgr %0,%1 21875 lgdr %0,%1") 21876 21877 to: 21878 21879 21880 (define_insn "*movdi_combined" 21881 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 21882 (match_operand:DI 1 "register_operand" " d,d,f"))] 21883 "" 21884 "@ 21885 lgr %0,%1 21886 ldgr %0,%1 21887 lgdr %0,%1" 21888 [(set_attr "cpu_facility" "*,new,new")]) 21889 21890 with the `enabled' attribute defined like this: 21891 21892 21893 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 21894 21895 (define_attr "enabled" "" 21896 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 21897 (and (eq_attr "cpu_facility" "new") 21898 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 21899 (const_int 1)] 21900 (const_int 0))) 21901 21902 21903 File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Disable Insn Alternatives, Up: Constraints 21904 21905 16.8.7 Defining Machine-Specific Constraints 21906 -------------------------------------------- 21907 21908 Machine-specific constraints fall into two categories: register and 21909 non-register constraints. Within the latter category, constraints 21910 which allow subsets of all possible memory or address operands should 21911 be specially marked, to give `reload' more information. 21912 21913 Machine-specific constraints can be given names of arbitrary length, 21914 but they must be entirely composed of letters, digits, underscores 21915 (`_'), and angle brackets (`< >'). Like C identifiers, they must begin 21916 with a letter or underscore. 21917 21918 In order to avoid ambiguity in operand constraint strings, no 21919 constraint can have a name that begins with any other constraint's 21920 name. For example, if `x' is defined as a constraint name, `xy' may 21921 not be, and vice versa. As a consequence of this rule, no constraint 21922 may begin with one of the generic constraint letters: `E F V X g i m n 21923 o p r s'. 21924 21925 Register constraints correspond directly to register classes. *Note 21926 Register Classes::. There is thus not much flexibility in their 21927 definitions. 21928 21929 -- MD Expression: define_register_constraint name regclass docstring 21930 All three arguments are string constants. NAME is the name of the 21931 constraint, as it will appear in `match_operand' expressions. If 21932 NAME is a multi-letter constraint its length shall be the same for 21933 all constraints starting with the same letter. REGCLASS can be 21934 either the name of the corresponding register class (*note 21935 Register Classes::), or a C expression which evaluates to the 21936 appropriate register class. If it is an expression, it must have 21937 no side effects, and it cannot look at the operand. The usual use 21938 of expressions is to map some register constraints to `NO_REGS' 21939 when the register class is not available on a given 21940 subarchitecture. 21941 21942 DOCSTRING is a sentence documenting the meaning of the constraint. 21943 Docstrings are explained further below. 21944 21945 Non-register constraints are more like predicates: the constraint 21946 definition gives a Boolean expression which indicates whether the 21947 constraint matches. 21948 21949 -- MD Expression: define_constraint name docstring exp 21950 The NAME and DOCSTRING arguments are the same as for 21951 `define_register_constraint', but note that the docstring comes 21952 immediately after the name for these expressions. EXP is an RTL 21953 expression, obeying the same rules as the RTL expressions in 21954 predicate definitions. *Note Defining Predicates::, for details. 21955 If it evaluates true, the constraint matches; if it evaluates 21956 false, it doesn't. Constraint expressions should indicate which 21957 RTL codes they might match, just like predicate expressions. 21958 21959 `match_test' C expressions have access to the following variables: 21960 21961 OP 21962 The RTL object defining the operand. 21963 21964 MODE 21965 The machine mode of OP. 21966 21967 IVAL 21968 `INTVAL (OP)', if OP is a `const_int'. 21969 21970 HVAL 21971 `CONST_DOUBLE_HIGH (OP)', if OP is an integer `const_double'. 21972 21973 LVAL 21974 `CONST_DOUBLE_LOW (OP)', if OP is an integer `const_double'. 21975 21976 RVAL 21977 `CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 21978 `const_double'. 21979 21980 The *VAL variables should only be used once another piece of the 21981 expression has verified that OP is the appropriate kind of RTL 21982 object. 21983 21984 Most non-register constraints should be defined with 21985 `define_constraint'. The remaining two definition expressions are only 21986 appropriate for constraints that should be handled specially by 21987 `reload' if they fail to match. 21988 21989 -- MD Expression: define_memory_constraint name docstring exp 21990 Use this expression for constraints that match a subset of all 21991 memory operands: that is, `reload' can make them match by 21992 converting the operand to the form `(mem (reg X))', where X is a 21993 base register (from the register class specified by 21994 `BASE_REG_CLASS', *note Register Classes::). 21995 21996 For example, on the S/390, some instructions do not accept 21997 arbitrary memory references, but only those that do not make use 21998 of an index register. The constraint letter `Q' is defined to 21999 represent a memory address of this type. If `Q' is defined with 22000 `define_memory_constraint', a `Q' constraint can handle any memory 22001 operand, because `reload' knows it can simply copy the memory 22002 address into a base register if required. This is analogous to 22003 the way an `o' constraint can handle any memory operand. 22004 22005 The syntax and semantics are otherwise identical to 22006 `define_constraint'. 22007 22008 -- MD Expression: define_address_constraint name docstring exp 22009 Use this expression for constraints that match a subset of all 22010 address operands: that is, `reload' can make the constraint match 22011 by converting the operand to the form `(reg X)', again with X a 22012 base register. 22013 22014 Constraints defined with `define_address_constraint' can only be 22015 used with the `address_operand' predicate, or machine-specific 22016 predicates that work the same way. They are treated analogously to 22017 the generic `p' constraint. 22018 22019 The syntax and semantics are otherwise identical to 22020 `define_constraint'. 22021 22022 For historical reasons, names beginning with the letters `G H' are 22023 reserved for constraints that match only `const_double's, and names 22024 beginning with the letters `I J K L M N O P' are reserved for 22025 constraints that match only `const_int's. This may change in the 22026 future. For the time being, constraints with these names must be 22027 written in a stylized form, so that `genpreds' can tell you did it 22028 correctly: 22029 22030 (define_constraint "[GHIJKLMNOP]..." 22031 "DOC..." 22032 (and (match_code "const_int") ; `const_double' for G/H 22033 CONDITION...)) ; usually a `match_test' 22034 22035 It is fine to use names beginning with other letters for constraints 22036 that match `const_double's or `const_int's. 22037 22038 Each docstring in a constraint definition should be one or more 22039 complete sentences, marked up in Texinfo format. _They are currently 22040 unused._ In the future they will be copied into the GCC manual, in 22041 *note Machine Constraints::, replacing the hand-maintained tables 22042 currently found in that section. Also, in the future the compiler may 22043 use this to give more helpful diagnostics when poor choice of `asm' 22044 constraints causes a reload failure. 22045 22046 If you put the pseudo-Texinfo directive `@internal' at the beginning 22047 of a docstring, then (in the future) it will appear only in the 22048 internals manual's version of the machine-specific constraint tables. 22049 Use this for constraints that should not appear in `asm' statements. 22050 22051 22052 File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 22053 22054 16.8.8 Testing constraints from C 22055 --------------------------------- 22056 22057 It is occasionally useful to test a constraint from C code rather than 22058 implicitly via the constraint string in a `match_operand'. The 22059 generated file `tm_p.h' declares a few interfaces for working with 22060 machine-specific constraints. None of these interfaces work with the 22061 generic constraints described in *note Simple Constraints::. This may 22062 change in the future. 22063 22064 *Warning:* `tm_p.h' may declare other functions that operate on 22065 constraints, besides the ones documented here. Do not use those 22066 functions from machine-dependent code. They exist to implement the old 22067 constraint interface that machine-independent components of the 22068 compiler still expect. They will change or disappear in the future. 22069 22070 Some valid constraint names are not valid C identifiers, so there is a 22071 mangling scheme for referring to them from C. Constraint names that do 22072 not contain angle brackets or underscores are left unchanged. 22073 Underscores are doubled, each `<' is replaced with `_l', and each `>' 22074 with `_g'. Here are some examples: 22075 22076 *Original* *Mangled* 22077 `x' `x' 22078 `P42x' `P42x' 22079 `P4_x' `P4__x' 22080 `P4>x' `P4_gx' 22081 `P4>>' `P4_g_g' 22082 `P4_g>' `P4__g_g' 22083 22084 Throughout this section, the variable C is either a constraint in the 22085 abstract sense, or a constant from `enum constraint_num'; the variable 22086 M is a mangled constraint name (usually as part of a larger identifier). 22087 22088 -- Enum: constraint_num 22089 For each machine-specific constraint, there is a corresponding 22090 enumeration constant: `CONSTRAINT_' plus the mangled name of the 22091 constraint. Functions that take an `enum constraint_num' as an 22092 argument expect one of these constants. 22093 22094 Machine-independent constraints do not have associated constants. 22095 This may change in the future. 22096 22097 -- Function: inline bool satisfies_constraint_M (rtx EXP) 22098 For each machine-specific, non-register constraint M, there is one 22099 of these functions; it returns `true' if EXP satisfies the 22100 constraint. These functions are only visible if `rtl.h' was 22101 included before `tm_p.h'. 22102 22103 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 22104 C) 22105 Like the `satisfies_constraint_M' functions, but the constraint to 22106 test is given as an argument, C. If C specifies a register 22107 constraint, this function will always return `false'. 22108 22109 -- Function: enum reg_class regclass_for_constraint (enum 22110 constraint_num C) 22111 Returns the register class associated with C. If C is not a 22112 register constraint, or those registers are not available for the 22113 currently selected subtarget, returns `NO_REGS'. 22114 22115 Here is an example use of `satisfies_constraint_M'. In peephole 22116 optimizations (*note Peephole Definitions::), operand constraint 22117 strings are ignored, so if there are relevant constraints, they must be 22118 tested in the C condition. In the example, the optimization is applied 22119 if operand 2 does _not_ satisfy the `K' constraint. (This is a 22120 simplified version of a peephole definition from the i386 machine 22121 description.) 22122 22123 (define_peephole2 22124 [(match_scratch:SI 3 "r") 22125 (set (match_operand:SI 0 "register_operand" "") 22126 (mult:SI (match_operand:SI 1 "memory_operand" "") 22127 (match_operand:SI 2 "immediate_operand" "")))] 22128 22129 "!satisfies_constraint_K (operands[2])" 22130 22131 [(set (match_dup 3) (match_dup 1)) 22132 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 22133 22134 "") 22135 22136 22137 File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 22138 22139 16.9 Standard Pattern Names For Generation 22140 ========================================== 22141 22142 Here is a table of the instruction names that are meaningful in the RTL 22143 generation pass of the compiler. Giving one of these names to an 22144 instruction pattern tells the RTL generation pass that it can use the 22145 pattern to accomplish a certain task. 22146 22147 `movM' 22148 Here M stands for a two-letter machine mode name, in lowercase. 22149 This instruction pattern moves data with that machine mode from 22150 operand 1 to operand 0. For example, `movsi' moves full-word data. 22151 22152 If operand 0 is a `subreg' with mode M of a register whose own 22153 mode is wider than M, the effect of this instruction is to store 22154 the specified value in the part of the register that corresponds 22155 to mode M. Bits outside of M, but which are within the same 22156 target word as the `subreg' are undefined. Bits which are outside 22157 the target word are left unchanged. 22158 22159 This class of patterns is special in several ways. First of all, 22160 each of these names up to and including full word size _must_ be 22161 defined, because there is no other way to copy a datum from one 22162 place to another. If there are patterns accepting operands in 22163 larger modes, `movM' must be defined for integer modes of those 22164 sizes. 22165 22166 Second, these patterns are not used solely in the RTL generation 22167 pass. Even the reload pass can generate move insns to copy values 22168 from stack slots into temporary registers. When it does so, one 22169 of the operands is a hard register and the other is an operand 22170 that can need to be reloaded into a register. 22171 22172 Therefore, when given such a pair of operands, the pattern must 22173 generate RTL which needs no reloading and needs no temporary 22174 registers--no registers other than the operands. For example, if 22175 you support the pattern with a `define_expand', then in such a 22176 case the `define_expand' mustn't call `force_reg' or any other such 22177 function which might generate new pseudo registers. 22178 22179 This requirement exists even for subword modes on a RISC machine 22180 where fetching those modes from memory normally requires several 22181 insns and some temporary registers. 22182 22183 During reload a memory reference with an invalid address may be 22184 passed as an operand. Such an address will be replaced with a 22185 valid address later in the reload pass. In this case, nothing may 22186 be done with the address except to use it as it stands. If it is 22187 copied, it will not be replaced with a valid address. No attempt 22188 should be made to make such an address into a valid address and no 22189 routine (such as `change_address') that will do so may be called. 22190 Note that `general_operand' will fail when applied to such an 22191 address. 22192 22193 The global variable `reload_in_progress' (which must be explicitly 22194 declared if required) can be used to determine whether such special 22195 handling is required. 22196 22197 The variety of operands that have reloads depends on the rest of 22198 the machine description, but typically on a RISC machine these can 22199 only be pseudo registers that did not get hard registers, while on 22200 other machines explicit memory references will get optional 22201 reloads. 22202 22203 If a scratch register is required to move an object to or from 22204 memory, it can be allocated using `gen_reg_rtx' prior to life 22205 analysis. 22206 22207 If there are cases which need scratch registers during or after 22208 reload, you must provide an appropriate secondary_reload target 22209 hook. 22210 22211 The macro `can_create_pseudo_p' can be used to determine if it is 22212 unsafe to create new pseudo registers. If this variable is 22213 nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new 22214 pseudo. 22215 22216 The constraints on a `movM' must permit moving any hard register 22217 to any other hard register provided that `HARD_REGNO_MODE_OK' 22218 permits mode M in both registers and `TARGET_REGISTER_MOVE_COST' 22219 applied to their classes returns a value of 2. 22220 22221 It is obligatory to support floating point `movM' instructions 22222 into and out of any registers that can hold fixed point values, 22223 because unions and structures (which have modes `SImode' or 22224 `DImode') can be in those registers and they may have floating 22225 point members. 22226 22227 There may also be a need to support fixed point `movM' 22228 instructions in and out of floating point registers. 22229 Unfortunately, I have forgotten why this was so, and I don't know 22230 whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed 22231 point values in floating point registers, then the constraints of 22232 the fixed point `movM' instructions must be designed to avoid ever 22233 trying to reload into a floating point register. 22234 22235 `reload_inM' 22236 `reload_outM' 22237 These named patterns have been obsoleted by the target hook 22238 `secondary_reload'. 22239 22240 Like `movM', but used when a scratch register is required to move 22241 between operand 0 and operand 1. Operand 2 describes the scratch 22242 register. See the discussion of the `SECONDARY_RELOAD_CLASS' 22243 macro in *note Register Classes::. 22244 22245 There are special restrictions on the form of the `match_operand's 22246 used in these patterns. First, only the predicate for the reload 22247 operand is examined, i.e., `reload_in' examines operand 1, but not 22248 the predicates for operand 0 or 2. Second, there may be only one 22249 alternative in the constraints. Third, only a single register 22250 class letter may be used for the constraint; subsequent constraint 22251 letters are ignored. As a special exception, an empty constraint 22252 string matches the `ALL_REGS' register class. This may relieve 22253 ports of the burden of defining an `ALL_REGS' constraint letter 22254 just for these patterns. 22255 22256 `movstrictM' 22257 Like `movM' except that if operand 0 is a `subreg' with mode M of 22258 a register whose natural mode is wider, the `movstrictM' 22259 instruction is guaranteed not to alter any of the register except 22260 the part which belongs to mode M. 22261 22262 `movmisalignM' 22263 This variant of a move pattern is designed to load or store a value 22264 from a memory address that is not naturally aligned for its mode. 22265 For a store, the memory will be in operand 0; for a load, the 22266 memory will be in operand 1. The other operand is guaranteed not 22267 to be a memory, so that it's easy to tell whether this is a load 22268 or store. 22269 22270 This pattern is used by the autovectorizer, and when expanding a 22271 `MISALIGNED_INDIRECT_REF' expression. 22272 22273 `load_multiple' 22274 Load several consecutive memory locations into consecutive 22275 registers. Operand 0 is the first of the consecutive registers, 22276 operand 1 is the first memory location, and operand 2 is a 22277 constant: the number of consecutive registers. 22278 22279 Define this only if the target machine really has such an 22280 instruction; do not define this if the most efficient way of 22281 loading consecutive registers from memory is to do them one at a 22282 time. 22283 22284 On some machines, there are restrictions as to which consecutive 22285 registers can be stored into memory, such as particular starting or 22286 ending register numbers or only a range of valid counts. For those 22287 machines, use a `define_expand' (*note Expander Definitions::) and 22288 make the pattern fail if the restrictions are not met. 22289 22290 Write the generated insn as a `parallel' with elements being a 22291 `set' of one register from the appropriate memory location (you may 22292 also need `use' or `clobber' elements). Use a `match_parallel' 22293 (*note RTL Template::) to recognize the insn. See `rs6000.md' for 22294 examples of the use of this insn pattern. 22295 22296 `store_multiple' 22297 Similar to `load_multiple', but store several consecutive registers 22298 into consecutive memory locations. Operand 0 is the first of the 22299 consecutive memory locations, operand 1 is the first register, and 22300 operand 2 is a constant: the number of consecutive registers. 22301 22302 `vec_load_lanesMN' 22303 Perform an interleaved load of several vectors from memory operand 22304 1 into register operand 0. Both operands have mode M. The 22305 register operand is viewed as holding consecutive vectors of mode 22306 N, while the memory operand is a flat array that contains the same 22307 number of elements. The operation is equivalent to: 22308 22309 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 22310 for (j = 0; j < GET_MODE_NUNITS (N); j++) 22311 for (i = 0; i < c; i++) 22312 operand0[i][j] = operand1[j * c + i]; 22313 22314 For example, `vec_load_lanestiv4hi' loads 8 16-bit values from 22315 memory into a register of mode `TI'. The register contains two 22316 consecutive vectors of mode `V4HI'. 22317 22318 This pattern can only be used if: 22319 TARGET_ARRAY_MODE_SUPPORTED_P (N, C) 22320 is true. GCC assumes that, if a target supports this kind of 22321 instruction for some mode N, it also supports unaligned loads for 22322 vectors of mode N. 22323 22324 `vec_store_lanesMN' 22325 Equivalent to `vec_load_lanesMN', with the memory and register 22326 operands reversed. That is, the instruction is equivalent to: 22327 22328 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 22329 for (j = 0; j < GET_MODE_NUNITS (N); j++) 22330 for (i = 0; i < c; i++) 22331 operand0[j * c + i] = operand1[i][j]; 22332 22333 for a memory operand 0 and register operand 1. 22334 22335 `vec_setM' 22336 Set given field in the vector value. Operand 0 is the vector to 22337 modify, operand 1 is new value of field and operand 2 specify the 22338 field index. 22339 22340 `vec_extractM' 22341 Extract given field from the vector value. Operand 1 is the 22342 vector, operand 2 specify field index and operand 0 place to store 22343 value into. 22344 22345 `vec_initM' 22346 Initialize the vector to given values. Operand 0 is the vector to 22347 initialize and operand 1 is parallel containing values for 22348 individual fields. 22349 22350 `vcondMN' 22351 Output a conditional vector move. Operand 0 is the destination to 22352 receive a combination of operand 1 and operand 2, which are of 22353 mode M, dependent on the outcome of the predicate in operand 3 22354 which is a vector comparison with operands of mode N in operands 4 22355 and 5. The modes M and N should have the same size. Operand 0 22356 will be set to the value OP1 & MSK | OP2 & ~MSK where MSK is 22357 computed by element-wise evaluation of the vector comparison with 22358 a truth value of all-ones and a false value of all-zeros. 22359 22360 `vec_permM' 22361 Output a (variable) vector permutation. Operand 0 is the 22362 destination to receive elements from operand 1 and operand 2, 22363 which are of mode M. Operand 3 is the "selector". It is an 22364 integral mode vector of the same width and number of elements as 22365 mode M. 22366 22367 The input elements are numbered from 0 in operand 1 through 2*N-1 22368 in operand 2. The elements of the selector must be computed 22369 modulo 2*N. Note that if `rtx_equal_p(operand1, operand2)', this 22370 can be implemented with just operand 1 and selector elements 22371 modulo N. 22372 22373 In order to make things easy for a number of targets, if there is 22374 no `vec_perm' pattern for mode M, but there is for mode Q where Q 22375 is a vector of `QImode' of the same width as M, the middle-end 22376 will lower the mode M `VEC_PERM_EXPR' to mode Q. 22377 22378 `vec_perm_constM' 22379 Like `vec_perm' except that the permutation is a compile-time 22380 constant. That is, operand 3, the "selector", is a `CONST_VECTOR'. 22381 22382 Some targets cannot perform a permutation with a variable selector, 22383 but can efficiently perform a constant permutation. Further, the 22384 target hook `vec_perm_ok' is queried to determine if the specific 22385 constant permutation is available efficiently; the named pattern 22386 is never expanded without `vec_perm_ok' returning true. 22387 22388 There is no need for a target to supply both `vec_permM' and 22389 `vec_perm_constM' if the former can trivially implement the 22390 operation with, say, the vector constant loaded into a register. 22391 22392 `pushM1' 22393 Output a push instruction. Operand 0 is value to push. Used only 22394 when `PUSH_ROUNDING' is defined. For historical reason, this 22395 pattern may be missing and in such case an `mov' expander is used 22396 instead, with a `MEM' expression forming the push operation. The 22397 `mov' expander method is deprecated. 22398 22399 `addM3' 22400 Add operand 2 and operand 1, storing the result in operand 0. All 22401 operands must have mode M. This can be used even on two-address 22402 machines, by means of constraints requiring operands 1 and 0 to be 22403 the same location. 22404 22405 `ssaddM3', `usaddM3' 22406 `subM3', `sssubM3', `ussubM3' 22407 `mulM3', `ssmulM3', `usmulM3' 22408 `divM3', `ssdivM3' 22409 `udivM3', `usdivM3' 22410 `modM3', `umodM3' 22411 `uminM3', `umaxM3' 22412 `andM3', `iorM3', `xorM3' 22413 Similar, for other arithmetic operations. 22414 22415 `fmaM4' 22416 Multiply operand 2 and operand 1, then add operand 3, storing the 22417 result in operand 0 without doing an intermediate rounding step. 22418 All operands must have mode M. This pattern is used to implement 22419 the `fma', `fmaf', and `fmal' builtin functions from the ISO C99 22420 standard. 22421 22422 `fmsM4' 22423 Like `fmaM4', except operand 3 subtracted from the product instead 22424 of added to the product. This is represented in the rtl as 22425 22426 (fma:M OP1 OP2 (neg:M OP3)) 22427 22428 `fnmaM4' 22429 Like `fmaM4' except that the intermediate product is negated 22430 before being added to operand 3. This is represented in the rtl as 22431 22432 (fma:M (neg:M OP1) OP2 OP3) 22433 22434 `fnmsM4' 22435 Like `fmsM4' except that the intermediate product is negated 22436 before subtracting operand 3. This is represented in the rtl as 22437 22438 (fma:M (neg:M OP1) OP2 (neg:M OP3)) 22439 22440 `sminM3', `smaxM3' 22441 Signed minimum and maximum operations. When used with floating 22442 point, if both operands are zeros, or if either operand is `NaN', 22443 then it is unspecified which of the two operands is returned as 22444 the result. 22445 22446 `reduc_smin_M', `reduc_smax_M' 22447 Find the signed minimum/maximum of the elements of a vector. The 22448 vector is operand 1, and the scalar result is stored in the least 22449 significant bits of operand 0 (also a vector). The output and 22450 input vector should have the same modes. 22451 22452 `reduc_umin_M', `reduc_umax_M' 22453 Find the unsigned minimum/maximum of the elements of a vector. The 22454 vector is operand 1, and the scalar result is stored in the least 22455 significant bits of operand 0 (also a vector). The output and 22456 input vector should have the same modes. 22457 22458 `reduc_splus_M' 22459 Compute the sum of the signed elements of a vector. The vector is 22460 operand 1, and the scalar result is stored in the least 22461 significant bits of operand 0 (also a vector). The output and 22462 input vector should have the same modes. 22463 22464 `reduc_uplus_M' 22465 Compute the sum of the unsigned elements of a vector. The vector 22466 is operand 1, and the scalar result is stored in the least 22467 significant bits of operand 0 (also a vector). The output and 22468 input vector should have the same modes. 22469 22470 `sdot_prodM' 22471 22472 `udot_prodM' 22473 Compute the sum of the products of two signed/unsigned elements. 22474 Operand 1 and operand 2 are of the same mode. Their product, which 22475 is of a wider mode, is computed and added to operand 3. Operand 3 22476 is of a mode equal or wider than the mode of the product. The 22477 result is placed in operand 0, which is of the same mode as 22478 operand 3. 22479 22480 `ssum_widenM3' 22481 22482 `usum_widenM3' 22483 Operands 0 and 2 are of the same mode, which is wider than the 22484 mode of operand 1. Add operand 1 to operand 2 and place the 22485 widened result in operand 0. (This is used express accumulation of 22486 elements into an accumulator of a wider mode.) 22487 22488 `vec_shl_M', `vec_shr_M' 22489 Whole vector left/right shift in bits. Operand 1 is a vector to 22490 be shifted. Operand 2 is an integer shift amount in bits. 22491 Operand 0 is where the resulting shifted vector is stored. The 22492 output and input vectors should have the same modes. 22493 22494 `vec_pack_trunc_M' 22495 Narrow (demote) and merge the elements of two vectors. Operands 1 22496 and 2 are vectors of the same mode having N integral or floating 22497 point elements of size S. Operand 0 is the resulting vector in 22498 which 2*N elements of size N/2 are concatenated after narrowing 22499 them down using truncation. 22500 22501 `vec_pack_ssat_M', `vec_pack_usat_M' 22502 Narrow (demote) and merge the elements of two vectors. Operands 1 22503 and 2 are vectors of the same mode having N integral elements of 22504 size S. Operand 0 is the resulting vector in which the elements 22505 of the two input vectors are concatenated after narrowing them 22506 down using signed/unsigned saturating arithmetic. 22507 22508 `vec_pack_sfix_trunc_M', `vec_pack_ufix_trunc_M' 22509 Narrow, convert to signed/unsigned integral type and merge the 22510 elements of two vectors. Operands 1 and 2 are vectors of the same 22511 mode having N floating point elements of size S. Operand 0 is the 22512 resulting vector in which 2*N elements of size N/2 are 22513 concatenated. 22514 22515 `vec_unpacks_hi_M', `vec_unpacks_lo_M' 22516 Extract and widen (promote) the high/low part of a vector of signed 22517 integral or floating point elements. The input vector (operand 1) 22518 has N elements of size S. Widen (promote) the high/low elements 22519 of the vector using signed or floating point extension and place 22520 the resulting N/2 values of size 2*S in the output vector (operand 22521 0). 22522 22523 `vec_unpacku_hi_M', `vec_unpacku_lo_M' 22524 Extract and widen (promote) the high/low part of a vector of 22525 unsigned integral elements. The input vector (operand 1) has N 22526 elements of size S. Widen (promote) the high/low elements of the 22527 vector using zero extension and place the resulting N/2 values of 22528 size 2*S in the output vector (operand 0). 22529 22530 `vec_unpacks_float_hi_M', `vec_unpacks_float_lo_M' 22531 `vec_unpacku_float_hi_M', `vec_unpacku_float_lo_M' 22532 Extract, convert to floating point type and widen the high/low 22533 part of a vector of signed/unsigned integral elements. The input 22534 vector (operand 1) has N elements of size S. Convert the high/low 22535 elements of the vector using floating point conversion and place 22536 the resulting N/2 values of size 2*S in the output vector (operand 22537 0). 22538 22539 `vec_widen_umult_hi_M', `vec_widen_umult_lo_M' 22540 `vec_widen_smult_hi_M', `vec_widen_smult_lo_M' 22541 `vec_widen_umult_even_M', `vec_widen_umult_odd_M' 22542 `vec_widen_smult_even_M', `vec_widen_smult_odd_M' 22543 Signed/Unsigned widening multiplication. The two inputs (operands 22544 1 and 2) are vectors with N signed/unsigned elements of size S. 22545 Multiply the high/low or even/odd elements of the two vectors, and 22546 put the N/2 products of size 2*S in the output vector (operand 0). 22547 22548 `vec_widen_ushiftl_hi_M', `vec_widen_ushiftl_lo_M' 22549 `vec_widen_sshiftl_hi_M', `vec_widen_sshiftl_lo_M' 22550 Signed/Unsigned widening shift left. The first input (operand 1) 22551 is a vector with N signed/unsigned elements of size S. Operand 2 22552 is a constant. Shift the high/low elements of operand 1, and put 22553 the N/2 results of size 2*S in the output vector (operand 0). 22554 22555 `mulhisi3' 22556 Multiply operands 1 and 2, which have mode `HImode', and store a 22557 `SImode' product in operand 0. 22558 22559 `mulqihi3', `mulsidi3' 22560 Similar widening-multiplication instructions of other widths. 22561 22562 `umulqihi3', `umulhisi3', `umulsidi3' 22563 Similar widening-multiplication instructions that do unsigned 22564 multiplication. 22565 22566 `usmulqihi3', `usmulhisi3', `usmulsidi3' 22567 Similar widening-multiplication instructions that interpret the 22568 first operand as unsigned and the second operand as signed, then 22569 do a signed multiplication. 22570 22571 `smulM3_highpart' 22572 Perform a signed multiplication of operands 1 and 2, which have 22573 mode M, and store the most significant half of the product in 22574 operand 0. The least significant half of the product is discarded. 22575 22576 `umulM3_highpart' 22577 Similar, but the multiplication is unsigned. 22578 22579 `maddMN4' 22580 Multiply operands 1 and 2, sign-extend them to mode N, add operand 22581 3, and store the result in operand 0. Operands 1 and 2 have mode 22582 M and operands 0 and 3 have mode N. Both modes must be integer or 22583 fixed-point modes and N must be twice the size of M. 22584 22585 In other words, `maddMN4' is like `mulMN3' except that it also 22586 adds operand 3. 22587 22588 These instructions are not allowed to `FAIL'. 22589 22590 `umaddMN4' 22591 Like `maddMN4', but zero-extend the multiplication operands 22592 instead of sign-extending them. 22593 22594 `ssmaddMN4' 22595 Like `maddMN4', but all involved operations must be 22596 signed-saturating. 22597 22598 `usmaddMN4' 22599 Like `umaddMN4', but all involved operations must be 22600 unsigned-saturating. 22601 22602 `msubMN4' 22603 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 22604 result from operand 3, and store the result in operand 0. 22605 Operands 1 and 2 have mode M and operands 0 and 3 have mode N. 22606 Both modes must be integer or fixed-point modes and N must be twice 22607 the size of M. 22608 22609 In other words, `msubMN4' is like `mulMN3' except that it also 22610 subtracts the result from operand 3. 22611 22612 These instructions are not allowed to `FAIL'. 22613 22614 `umsubMN4' 22615 Like `msubMN4', but zero-extend the multiplication operands 22616 instead of sign-extending them. 22617 22618 `ssmsubMN4' 22619 Like `msubMN4', but all involved operations must be 22620 signed-saturating. 22621 22622 `usmsubMN4' 22623 Like `umsubMN4', but all involved operations must be 22624 unsigned-saturating. 22625 22626 `divmodM4' 22627 Signed division that produces both a quotient and a remainder. 22628 Operand 1 is divided by operand 2 to produce a quotient stored in 22629 operand 0 and a remainder stored in operand 3. 22630 22631 For machines with an instruction that produces both a quotient and 22632 a remainder, provide a pattern for `divmodM4' but do not provide 22633 patterns for `divM3' and `modM3'. This allows optimization in the 22634 relatively common case when both the quotient and remainder are 22635 computed. 22636 22637 If an instruction that just produces a quotient or just a remainder 22638 exists and is more efficient than the instruction that produces 22639 both, write the output routine of `divmodM4' to call 22640 `find_reg_note' and look for a `REG_UNUSED' note on the quotient 22641 or remainder and generate the appropriate instruction. 22642 22643 `udivmodM4' 22644 Similar, but does unsigned division. 22645 22646 `ashlM3', `ssashlM3', `usashlM3' 22647 Arithmetic-shift operand 1 left by a number of bits specified by 22648 operand 2, and store the result in operand 0. Here M is the mode 22649 of operand 0 and operand 1; operand 2's mode is specified by the 22650 instruction pattern, and the compiler will convert the operand to 22651 that mode before generating the instruction. The meaning of 22652 out-of-range shift counts can optionally be specified by 22653 `TARGET_SHIFT_TRUNCATION_MASK'. *Note 22654 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 22655 22656 `ashrM3', `lshrM3', `rotlM3', `rotrM3' 22657 Other shift and rotate instructions, analogous to the `ashlM3' 22658 instructions. Operand 2 is always a scalar type. 22659 22660 `vashlM3', `vashrM3', `vlshrM3', `vrotlM3', `vrotrM3' 22661 Vector shift and rotate instructions that take vectors as operand 2 22662 instead of a scalar type. 22663 22664 `bswapM2' 22665 Reverse the order of bytes of operand 1 and store the result in 22666 operand 0. 22667 22668 `negM2', `ssnegM2', `usnegM2' 22669 Negate operand 1 and store the result in operand 0. 22670 22671 `absM2' 22672 Store the absolute value of operand 1 into operand 0. 22673 22674 `sqrtM2' 22675 Store the square root of operand 1 into operand 0. 22676 22677 The `sqrt' built-in function of C always uses the mode which 22678 corresponds to the C data type `double' and the `sqrtf' built-in 22679 function uses the mode which corresponds to the C data type 22680 `float'. 22681 22682 `fmodM3' 22683 Store the remainder of dividing operand 1 by operand 2 into 22684 operand 0, rounded towards zero to an integer. 22685 22686 The `fmod' built-in function of C always uses the mode which 22687 corresponds to the C data type `double' and the `fmodf' built-in 22688 function uses the mode which corresponds to the C data type 22689 `float'. 22690 22691 `remainderM3' 22692 Store the remainder of dividing operand 1 by operand 2 into 22693 operand 0, rounded to the nearest integer. 22694 22695 The `remainder' built-in function of C always uses the mode which 22696 corresponds to the C data type `double' and the `remainderf' 22697 built-in function uses the mode which corresponds to the C data 22698 type `float'. 22699 22700 `cosM2' 22701 Store the cosine of operand 1 into operand 0. 22702 22703 The `cos' built-in function of C always uses the mode which 22704 corresponds to the C data type `double' and the `cosf' built-in 22705 function uses the mode which corresponds to the C data type 22706 `float'. 22707 22708 `sinM2' 22709 Store the sine of operand 1 into operand 0. 22710 22711 The `sin' built-in function of C always uses the mode which 22712 corresponds to the C data type `double' and the `sinf' built-in 22713 function uses the mode which corresponds to the C data type 22714 `float'. 22715 22716 `sincosM3' 22717 Store the cosine of operand 2 into operand 0 and the sine of 22718 operand 2 into operand 1. 22719 22720 The `sin' and `cos' built-in functions of C always use the mode 22721 which corresponds to the C data type `double' and the `sinf' and 22722 `cosf' built-in function use the mode which corresponds to the C 22723 data type `float'. Targets that can calculate the sine and cosine 22724 simultaneously can implement this pattern as opposed to 22725 implementing individual `sinM2' and `cosM2' patterns. The `sin' 22726 and `cos' built-in functions will then be expanded to the 22727 `sincosM3' pattern, with one of the output values left unused. 22728 22729 `expM2' 22730 Store the exponential of operand 1 into operand 0. 22731 22732 The `exp' built-in function of C always uses the mode which 22733 corresponds to the C data type `double' and the `expf' built-in 22734 function uses the mode which corresponds to the C data type 22735 `float'. 22736 22737 `logM2' 22738 Store the natural logarithm of operand 1 into operand 0. 22739 22740 The `log' built-in function of C always uses the mode which 22741 corresponds to the C data type `double' and the `logf' built-in 22742 function uses the mode which corresponds to the C data type 22743 `float'. 22744 22745 `powM3' 22746 Store the value of operand 1 raised to the exponent operand 2 into 22747 operand 0. 22748 22749 The `pow' built-in function of C always uses the mode which 22750 corresponds to the C data type `double' and the `powf' built-in 22751 function uses the mode which corresponds to the C data type 22752 `float'. 22753 22754 `atan2M3' 22755 Store the arc tangent (inverse tangent) of operand 1 divided by 22756 operand 2 into operand 0, using the signs of both arguments to 22757 determine the quadrant of the result. 22758 22759 The `atan2' built-in function of C always uses the mode which 22760 corresponds to the C data type `double' and the `atan2f' built-in 22761 function uses the mode which corresponds to the C data type 22762 `float'. 22763 22764 `floorM2' 22765 Store the largest integral value not greater than argument. 22766 22767 The `floor' built-in function of C always uses the mode which 22768 corresponds to the C data type `double' and the `floorf' built-in 22769 function uses the mode which corresponds to the C data type 22770 `float'. 22771 22772 `btruncM2' 22773 Store the argument rounded to integer towards zero. 22774 22775 The `trunc' built-in function of C always uses the mode which 22776 corresponds to the C data type `double' and the `truncf' built-in 22777 function uses the mode which corresponds to the C data type 22778 `float'. 22779 22780 `roundM2' 22781 Store the argument rounded to integer away from zero. 22782 22783 The `round' built-in function of C always uses the mode which 22784 corresponds to the C data type `double' and the `roundf' built-in 22785 function uses the mode which corresponds to the C data type 22786 `float'. 22787 22788 `ceilM2' 22789 Store the argument rounded to integer away from zero. 22790 22791 The `ceil' built-in function of C always uses the mode which 22792 corresponds to the C data type `double' and the `ceilf' built-in 22793 function uses the mode which corresponds to the C data type 22794 `float'. 22795 22796 `nearbyintM2' 22797 Store the argument rounded according to the default rounding mode 22798 22799 The `nearbyint' built-in function of C always uses the mode which 22800 corresponds to the C data type `double' and the `nearbyintf' 22801 built-in function uses the mode which corresponds to the C data 22802 type `float'. 22803 22804 `rintM2' 22805 Store the argument rounded according to the default rounding mode 22806 and raise the inexact exception when the result differs in value 22807 from the argument 22808 22809 The `rint' built-in function of C always uses the mode which 22810 corresponds to the C data type `double' and the `rintf' built-in 22811 function uses the mode which corresponds to the C data type 22812 `float'. 22813 22814 `lrintMN2' 22815 Convert operand 1 (valid for floating point mode M) to fixed point 22816 mode N as a signed number according to the current rounding mode 22817 and store in operand 0 (which has mode N). 22818 22819 `lroundMN2' 22820 Convert operand 1 (valid for floating point mode M) to fixed point 22821 mode N as a signed number rounding to nearest and away from zero 22822 and store in operand 0 (which has mode N). 22823 22824 `lfloorMN2' 22825 Convert operand 1 (valid for floating point mode M) to fixed point 22826 mode N as a signed number rounding down and store in operand 0 22827 (which has mode N). 22828 22829 `lceilMN2' 22830 Convert operand 1 (valid for floating point mode M) to fixed point 22831 mode N as a signed number rounding up and store in operand 0 22832 (which has mode N). 22833 22834 `copysignM3' 22835 Store a value with the magnitude of operand 1 and the sign of 22836 operand 2 into operand 0. 22837 22838 The `copysign' built-in function of C always uses the mode which 22839 corresponds to the C data type `double' and the `copysignf' 22840 built-in function uses the mode which corresponds to the C data 22841 type `float'. 22842 22843 `ffsM2' 22844 Store into operand 0 one plus the index of the least significant 22845 1-bit of operand 1. If operand 1 is zero, store zero. M is the 22846 mode of operand 0; operand 1's mode is specified by the instruction 22847 pattern, and the compiler will convert the operand to that mode 22848 before generating the instruction. 22849 22850 The `ffs' built-in function of C always uses the mode which 22851 corresponds to the C data type `int'. 22852 22853 `clzM2' 22854 Store into operand 0 the number of leading 0-bits in X, starting 22855 at the most significant bit position. If X is 0, the 22856 `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 22857 result is undefined or has a useful value. M is the mode of 22858 operand 0; operand 1's mode is specified by the instruction 22859 pattern, and the compiler will convert the operand to that mode 22860 before generating the instruction. 22861 22862 `ctzM2' 22863 Store into operand 0 the number of trailing 0-bits in X, starting 22864 at the least significant bit position. If X is 0, the 22865 `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 22866 result is undefined or has a useful value. M is the mode of 22867 operand 0; operand 1's mode is specified by the instruction 22868 pattern, and the compiler will convert the operand to that mode 22869 before generating the instruction. 22870 22871 `popcountM2' 22872 Store into operand 0 the number of 1-bits in X. M is the mode of 22873 operand 0; operand 1's mode is specified by the instruction 22874 pattern, and the compiler will convert the operand to that mode 22875 before generating the instruction. 22876 22877 `parityM2' 22878 Store into operand 0 the parity of X, i.e. the number of 1-bits in 22879 X modulo 2. M is the mode of operand 0; operand 1's mode is 22880 specified by the instruction pattern, and the compiler will convert 22881 the operand to that mode before generating the instruction. 22882 22883 `one_cmplM2' 22884 Store the bitwise-complement of operand 1 into operand 0. 22885 22886 `movmemM' 22887 Block move instruction. The destination and source blocks of 22888 memory are the first two operands, and both are `mem:BLK's with an 22889 address in mode `Pmode'. 22890 22891 The number of bytes to move is the third operand, in mode M. 22892 Usually, you specify `word_mode' for M. However, if you can 22893 generate better code knowing the range of valid lengths is smaller 22894 than those representable in a full word, you should provide a 22895 pattern with a mode corresponding to the range of values you can 22896 handle efficiently (e.g., `QImode' for values in the range 0-127; 22897 note we avoid numbers that appear negative) and also a pattern 22898 with `word_mode'. 22899 22900 The fourth operand is the known shared alignment of the source and 22901 destination, in the form of a `const_int' rtx. Thus, if the 22902 compiler knows that both source and destination are word-aligned, 22903 it may provide the value 4 for this operand. 22904 22905 Optional operands 5 and 6 specify expected alignment and size of 22906 block respectively. The expected alignment differs from alignment 22907 in operand 4 in a way that the blocks are not required to be 22908 aligned according to it in all cases. This expected alignment is 22909 also in bytes, just like operand 4. Expected size, when unknown, 22910 is set to `(const_int -1)'. 22911 22912 Descriptions of multiple `movmemM' patterns can only be beneficial 22913 if the patterns for smaller modes have fewer restrictions on their 22914 first, second and fourth operands. Note that the mode M in 22915 `movmemM' does not impose any restriction on the mode of 22916 individually moved data units in the block. 22917 22918 These patterns need not give special consideration to the 22919 possibility that the source and destination strings might overlap. 22920 22921 `movstr' 22922 String copy instruction, with `stpcpy' semantics. Operand 0 is an 22923 output operand in mode `Pmode'. The addresses of the destination 22924 and source strings are operands 1 and 2, and both are `mem:BLK's 22925 with addresses in mode `Pmode'. The execution of the expansion of 22926 this pattern should store in operand 0 the address in which the 22927 `NUL' terminator was stored in the destination string. 22928 22929 `setmemM' 22930 Block set instruction. The destination string is the first 22931 operand, given as a `mem:BLK' whose address is in mode `Pmode'. 22932 The number of bytes to set is the second operand, in mode M. The 22933 value to initialize the memory with is the third operand. Targets 22934 that only support the clearing of memory should reject any value 22935 that is not the constant 0. See `movmemM' for a discussion of the 22936 choice of mode. 22937 22938 The fourth operand is the known alignment of the destination, in 22939 the form of a `const_int' rtx. Thus, if the compiler knows that 22940 the destination is word-aligned, it may provide the value 4 for 22941 this operand. 22942 22943 Optional operands 5 and 6 specify expected alignment and size of 22944 block respectively. The expected alignment differs from alignment 22945 in operand 4 in a way that the blocks are not required to be 22946 aligned according to it in all cases. This expected alignment is 22947 also in bytes, just like operand 4. Expected size, when unknown, 22948 is set to `(const_int -1)'. 22949 22950 The use for multiple `setmemM' is as for `movmemM'. 22951 22952 `cmpstrnM' 22953 String compare instruction, with five operands. Operand 0 is the 22954 output; it has mode M. The remaining four operands are like the 22955 operands of `movmemM'. The two memory blocks specified are 22956 compared byte by byte in lexicographic order starting at the 22957 beginning of each string. The instruction is not allowed to 22958 prefetch more than one byte at a time since either string may end 22959 in the first byte and reading past that may access an invalid page 22960 or segment and cause a fault. The comparison terminates early if 22961 the fetched bytes are different or if they are equal to zero. The 22962 effect of the instruction is to store a value in operand 0 whose 22963 sign indicates the result of the comparison. 22964 22965 `cmpstrM' 22966 String compare instruction, without known maximum length. Operand 22967 0 is the output; it has mode M. The second and third operand are 22968 the blocks of memory to be compared; both are `mem:BLK' with an 22969 address in mode `Pmode'. 22970 22971 The fourth operand is the known shared alignment of the source and 22972 destination, in the form of a `const_int' rtx. Thus, if the 22973 compiler knows that both source and destination are word-aligned, 22974 it may provide the value 4 for this operand. 22975 22976 The two memory blocks specified are compared byte by byte in 22977 lexicographic order starting at the beginning of each string. The 22978 instruction is not allowed to prefetch more than one byte at a 22979 time since either string may end in the first byte and reading 22980 past that may access an invalid page or segment and cause a fault. 22981 The comparison will terminate when the fetched bytes are different 22982 or if they are equal to zero. The effect of the instruction is to 22983 store a value in operand 0 whose sign indicates the result of the 22984 comparison. 22985 22986 `cmpmemM' 22987 Block compare instruction, with five operands like the operands of 22988 `cmpstrM'. The two memory blocks specified are compared byte by 22989 byte in lexicographic order starting at the beginning of each 22990 block. Unlike `cmpstrM' the instruction can prefetch any bytes in 22991 the two memory blocks. Also unlike `cmpstrM' the comparison will 22992 not stop if both bytes are zero. The effect of the instruction is 22993 to store a value in operand 0 whose sign indicates the result of 22994 the comparison. 22995 22996 `strlenM' 22997 Compute the length of a string, with three operands. Operand 0 is 22998 the result (of mode M), operand 1 is a `mem' referring to the 22999 first character of the string, operand 2 is the character to 23000 search for (normally zero), and operand 3 is a constant describing 23001 the known alignment of the beginning of the string. 23002 23003 `floatMN2' 23004 Convert signed integer operand 1 (valid for fixed point mode M) to 23005 floating point mode N and store in operand 0 (which has mode N). 23006 23007 `floatunsMN2' 23008 Convert unsigned integer operand 1 (valid for fixed point mode M) 23009 to floating point mode N and store in operand 0 (which has mode N). 23010 23011 `fixMN2' 23012 Convert operand 1 (valid for floating point mode M) to fixed point 23013 mode N as a signed number and store in operand 0 (which has mode 23014 N). This instruction's result is defined only when the value of 23015 operand 1 is an integer. 23016 23017 If the machine description defines this pattern, it also needs to 23018 define the `ftrunc' pattern. 23019 23020 `fixunsMN2' 23021 Convert operand 1 (valid for floating point mode M) to fixed point 23022 mode N as an unsigned number and store in operand 0 (which has 23023 mode N). This instruction's result is defined only when the value 23024 of operand 1 is an integer. 23025 23026 `ftruncM2' 23027 Convert operand 1 (valid for floating point mode M) to an integer 23028 value, still represented in floating point mode M, and store it in 23029 operand 0 (valid for floating point mode M). 23030 23031 `fix_truncMN2' 23032 Like `fixMN2' but works for any floating point value of mode M by 23033 converting the value to an integer. 23034 23035 `fixuns_truncMN2' 23036 Like `fixunsMN2' but works for any floating point value of mode M 23037 by converting the value to an integer. 23038 23039 `truncMN2' 23040 Truncate operand 1 (valid for mode M) to mode N and store in 23041 operand 0 (which has mode N). Both modes must be fixed point or 23042 both floating point. 23043 23044 `extendMN2' 23045 Sign-extend operand 1 (valid for mode M) to mode N and store in 23046 operand 0 (which has mode N). Both modes must be fixed point or 23047 both floating point. 23048 23049 `zero_extendMN2' 23050 Zero-extend operand 1 (valid for mode M) to mode N and store in 23051 operand 0 (which has mode N). Both modes must be fixed point. 23052 23053 `fractMN2' 23054 Convert operand 1 of mode M to mode N and store in operand 0 23055 (which has mode N). Mode M and mode N could be fixed-point to 23056 fixed-point, signed integer to fixed-point, fixed-point to signed 23057 integer, floating-point to fixed-point, or fixed-point to 23058 floating-point. When overflows or underflows happen, the results 23059 are undefined. 23060 23061 `satfractMN2' 23062 Convert operand 1 of mode M to mode N and store in operand 0 23063 (which has mode N). Mode M and mode N could be fixed-point to 23064 fixed-point, signed integer to fixed-point, or floating-point to 23065 fixed-point. When overflows or underflows happen, the instruction 23066 saturates the results to the maximum or the minimum. 23067 23068 `fractunsMN2' 23069 Convert operand 1 of mode M to mode N and store in operand 0 23070 (which has mode N). Mode M and mode N could be unsigned integer 23071 to fixed-point, or fixed-point to unsigned integer. When 23072 overflows or underflows happen, the results are undefined. 23073 23074 `satfractunsMN2' 23075 Convert unsigned integer operand 1 of mode M to fixed-point mode N 23076 and store in operand 0 (which has mode N). When overflows or 23077 underflows happen, the instruction saturates the results to the 23078 maximum or the minimum. 23079 23080 `extvM' 23081 Extract a bit-field from register operand 1, sign-extend it, and 23082 store it in operand 0. Operand 2 specifies the width of the field 23083 in bits and operand 3 the starting bit, which counts from the most 23084 significant bit if `BITS_BIG_ENDIAN' is true and from the least 23085 significant bit otherwise. 23086 23087 Operands 0 and 1 both have mode M. Operands 2 and 3 have a 23088 target-specific mode. 23089 23090 `extvmisalignM' 23091 Extract a bit-field from memory operand 1, sign extend it, and 23092 store it in operand 0. Operand 2 specifies the width in bits and 23093 operand 3 the starting bit. The starting bit is always somewhere 23094 in the first byte of operand 1; it counts from the most 23095 significant bit if `BITS_BIG_ENDIAN' is true and from the least 23096 significant bit otherwise. 23097 23098 Operand 0 has mode M while operand 1 has `BLK' mode. Operands 2 23099 and 3 have a target-specific mode. 23100 23101 The instruction must not read beyond the last byte of the 23102 bit-field. 23103 23104 `extzvM' 23105 Like `extvM' except that the bit-field value is zero-extended. 23106 23107 `extzvmisalignM' 23108 Like `extvmisalignM' except that the bit-field value is 23109 zero-extended. 23110 23111 `insvM' 23112 Insert operand 3 into a bit-field of register operand 0. Operand 1 23113 specifies the width of the field in bits and operand 2 the 23114 starting bit, which counts from the most significant bit if 23115 `BITS_BIG_ENDIAN' is true and from the least significant bit 23116 otherwise. 23117 23118 Operands 0 and 3 both have mode M. Operands 1 and 2 have a 23119 target-specific mode. 23120 23121 `insvmisalignM' 23122 Insert operand 3 into a bit-field of memory operand 0. Operand 1 23123 specifies the width of the field in bits and operand 2 the 23124 starting bit. The starting bit is always somewhere in the first 23125 byte of operand 0; it counts from the most significant bit if 23126 `BITS_BIG_ENDIAN' is true and from the least significant bit 23127 otherwise. 23128 23129 Operand 3 has mode M while operand 0 has `BLK' mode. Operands 1 23130 and 2 have a target-specific mode. 23131 23132 The instruction must not read or write beyond the last byte of the 23133 bit-field. 23134 23135 `extv' 23136 Extract a bit-field from operand 1 (a register or memory operand), 23137 where operand 2 specifies the width in bits and operand 3 the 23138 starting bit, and store it in operand 0. Operand 0 must have mode 23139 `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode'; 23140 often `word_mode' is allowed only for registers. Operands 2 and 3 23141 must be valid for `word_mode'. 23142 23143 The RTL generation pass generates this instruction only with 23144 constants for operands 2 and 3 and the constant is never zero for 23145 operand 2. 23146 23147 The bit-field value is sign-extended to a full word integer before 23148 it is stored in operand 0. 23149 23150 This pattern is deprecated; please use `extvM' and `extvmisalignM' 23151 instead. 23152 23153 `extzv' 23154 Like `extv' except that the bit-field value is zero-extended. 23155 23156 This pattern is deprecated; please use `extzvM' and 23157 `extzvmisalignM' instead. 23158 23159 `insv' 23160 Store operand 3 (which must be valid for `word_mode') into a 23161 bit-field in operand 0, where operand 1 specifies the width in 23162 bits and operand 2 the starting bit. Operand 0 may have mode 23163 `byte_mode' or `word_mode'; often `word_mode' is allowed only for 23164 registers. Operands 1 and 2 must be valid for `word_mode'. 23165 23166 The RTL generation pass generates this instruction only with 23167 constants for operands 1 and 2 and the constant is never zero for 23168 operand 1. 23169 23170 This pattern is deprecated; please use `insvM' and `insvmisalignM' 23171 instead. 23172 23173 `movMODEcc' 23174 Conditionally move operand 2 or operand 3 into operand 0 according 23175 to the comparison in operand 1. If the comparison is true, 23176 operand 2 is moved into operand 0, otherwise operand 3 is moved. 23177 23178 The mode of the operands being compared need not be the same as 23179 the operands being moved. Some machines, sparc64 for example, 23180 have instructions that conditionally move an integer value based 23181 on the floating point condition codes and vice versa. 23182 23183 If the machine does not have conditional move instructions, do not 23184 define these patterns. 23185 23186 `addMODEcc' 23187 Similar to `movMODEcc' but for conditional addition. Conditionally 23188 move operand 2 or (operands 2 + operand 3) into operand 0 23189 according to the comparison in operand 1. If the comparison is 23190 false, operand 2 is moved into operand 0, otherwise (operand 2 + 23191 operand 3) is moved. 23192 23193 `cstoreMODE4' 23194 Store zero or nonzero in operand 0 according to whether a 23195 comparison is true. Operand 1 is a comparison operator. Operand 23196 2 and operand 3 are the first and second operand of the 23197 comparison, respectively. You specify the mode that operand 0 23198 must have when you write the `match_operand' expression. The 23199 compiler automatically sees which mode you have used and supplies 23200 an operand of that mode. 23201 23202 The value stored for a true condition must have 1 as its low bit, 23203 or else must be negative. Otherwise the instruction is not 23204 suitable and you should omit it from the machine description. You 23205 describe to the compiler exactly which value is stored by defining 23206 the macro `STORE_FLAG_VALUE' (*note Misc::). If a description 23207 cannot be found that can be used for all the possible comparison 23208 operators, you should pick one and use a `define_expand' to map 23209 all results onto the one you chose. 23210 23211 These operations may `FAIL', but should do so only in relatively 23212 uncommon cases; if they would `FAIL' for common cases involving 23213 integer comparisons, it is best to restrict the predicates to not 23214 allow these operands. Likewise if a given comparison operator will 23215 always fail, independent of the operands (for floating-point 23216 modes, the `ordered_comparison_operator' predicate is often useful 23217 in this case). 23218 23219 If this pattern is omitted, the compiler will generate a 23220 conditional branch--for example, it may copy a constant one to the 23221 target and branching around an assignment of zero to the 23222 target--or a libcall. If the predicate for operand 1 only rejects 23223 some operators, it will also try reordering the operands and/or 23224 inverting the result value (e.g. by an exclusive OR). These 23225 possibilities could be cheaper or equivalent to the instructions 23226 used for the `cstoreMODE4' pattern followed by those required to 23227 convert a positive result from `STORE_FLAG_VALUE' to 1; in this 23228 case, you can and should make operand 1's predicate reject some 23229 operators in the `cstoreMODE4' pattern, or remove the pattern 23230 altogether from the machine description. 23231 23232 `cbranchMODE4' 23233 Conditional branch instruction combined with a compare instruction. 23234 Operand 0 is a comparison operator. Operand 1 and operand 2 are 23235 the first and second operands of the comparison, respectively. 23236 Operand 3 is a `label_ref' that refers to the label to jump to. 23237 23238 `jump' 23239 A jump inside a function; an unconditional branch. Operand 0 is 23240 the `label_ref' of the label to jump to. This pattern name is 23241 mandatory on all machines. 23242 23243 `call' 23244 Subroutine call instruction returning no value. Operand 0 is the 23245 function to call; operand 1 is the number of bytes of arguments 23246 pushed as a `const_int'; operand 2 is the number of registers used 23247 as operands. 23248 23249 On most machines, operand 2 is not actually stored into the RTL 23250 pattern. It is supplied for the sake of some RISC machines which 23251 need to put this information into the assembler code; they can put 23252 it in the RTL instead of operand 1. 23253 23254 Operand 0 should be a `mem' RTX whose address is the address of the 23255 function. Note, however, that this address can be a `symbol_ref' 23256 expression even if it would not be a legitimate memory address on 23257 the target machine. If it is also not a valid argument for a call 23258 instruction, the pattern for this operation should be a 23259 `define_expand' (*note Expander Definitions::) that places the 23260 address into a register and uses that register in the call 23261 instruction. 23262 23263 `call_value' 23264 Subroutine call instruction returning a value. Operand 0 is the 23265 hard register in which the value is returned. There are three more 23266 operands, the same as the three operands of the `call' instruction 23267 (but with numbers increased by one). 23268 23269 Subroutines that return `BLKmode' objects use the `call' insn. 23270 23271 `call_pop', `call_value_pop' 23272 Similar to `call' and `call_value', except used if defined and if 23273 `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that 23274 contains both the function call and a `set' to indicate the 23275 adjustment made to the frame pointer. 23276 23277 For machines where `RETURN_POPS_ARGS' can be nonzero, the use of 23278 these patterns increases the number of functions for which the 23279 frame pointer can be eliminated, if desired. 23280 23281 `untyped_call' 23282 Subroutine call instruction returning a value of any type. 23283 Operand 0 is the function to call; operand 1 is a memory location 23284 where the result of calling the function is to be stored; operand 23285 2 is a `parallel' expression where each element is a `set' 23286 expression that indicates the saving of a function return value 23287 into the result block. 23288 23289 This instruction pattern should be defined to support 23290 `__builtin_apply' on machines where special instructions are needed 23291 to call a subroutine with arbitrary arguments or to save the value 23292 returned. This instruction pattern is required on machines that 23293 have multiple registers that can hold a return value (i.e. 23294 `FUNCTION_VALUE_REGNO_P' is true for more than one register). 23295 23296 `return' 23297 Subroutine return instruction. This instruction pattern name 23298 should be defined only if a single instruction can do all the work 23299 of returning from a function. 23300 23301 Like the `movM' patterns, this pattern is also used after the RTL 23302 generation phase. In this case it is to support machines where 23303 multiple instructions are usually needed to return from a 23304 function, but some class of functions only requires one 23305 instruction to implement a return. Normally, the applicable 23306 functions are those which do not need to save any registers or 23307 allocate stack space. 23308 23309 It is valid for this pattern to expand to an instruction using 23310 `simple_return' if no epilogue is required. 23311 23312 `simple_return' 23313 Subroutine return instruction. This instruction pattern name 23314 should be defined only if a single instruction can do all the work 23315 of returning from a function on a path where no epilogue is 23316 required. This pattern is very similar to the `return' 23317 instruction pattern, but it is emitted only by the shrink-wrapping 23318 optimization on paths where the function prologue has not been 23319 executed, and a function return should occur without any of the 23320 effects of the epilogue. Additional uses may be introduced on 23321 paths where both the prologue and the epilogue have executed. 23322 23323 For such machines, the condition specified in this pattern should 23324 only be true when `reload_completed' is nonzero and the function's 23325 epilogue would only be a single instruction. For machines with 23326 register windows, the routine `leaf_function_p' may be used to 23327 determine if a register window push is required. 23328 23329 Machines that have conditional return instructions should define 23330 patterns such as 23331 23332 (define_insn "" 23333 [(set (pc) 23334 (if_then_else (match_operator 23335 0 "comparison_operator" 23336 [(cc0) (const_int 0)]) 23337 (return) 23338 (pc)))] 23339 "CONDITION" 23340 "...") 23341 23342 where CONDITION would normally be the same condition specified on 23343 the named `return' pattern. 23344 23345 `untyped_return' 23346 Untyped subroutine return instruction. This instruction pattern 23347 should be defined to support `__builtin_return' on machines where 23348 special instructions are needed to return a value of any type. 23349 23350 Operand 0 is a memory location where the result of calling a 23351 function with `__builtin_apply' is stored; operand 1 is a 23352 `parallel' expression where each element is a `set' expression 23353 that indicates the restoring of a function return value from the 23354 result block. 23355 23356 `nop' 23357 No-op instruction. This instruction pattern name should always be 23358 defined to output a no-op in assembler code. `(const_int 0)' will 23359 do as an RTL pattern. 23360 23361 `indirect_jump' 23362 An instruction to jump to an address which is operand zero. This 23363 pattern name is mandatory on all machines. 23364 23365 `casesi' 23366 Instruction to jump through a dispatch table, including bounds 23367 checking. This instruction takes five operands: 23368 23369 1. The index to dispatch on, which has mode `SImode'. 23370 23371 2. The lower bound for indices in the table, an integer constant. 23372 23373 3. The total range of indices in the table--the largest index 23374 minus the smallest one (both inclusive). 23375 23376 4. A label that precedes the table itself. 23377 23378 5. A label to jump to if the index has a value outside the 23379 bounds. 23380 23381 The table is an `addr_vec' or `addr_diff_vec' inside of a 23382 `jump_insn'. The number of elements in the table is one plus the 23383 difference between the upper bound and the lower bound. 23384 23385 `tablejump' 23386 Instruction to jump to a variable address. This is a low-level 23387 capability which can be used to implement a dispatch table when 23388 there is no `casesi' pattern. 23389 23390 This pattern requires two operands: the address or offset, and a 23391 label which should immediately precede the jump table. If the 23392 macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 23393 the first operand is an offset which counts from the address of 23394 the table; otherwise, it is an absolute address to jump to. In 23395 either case, the first operand has mode `Pmode'. 23396 23397 The `tablejump' insn is always the last insn before the jump table 23398 it uses. Its assembler code normally has no need to use the 23399 second operand, but you should incorporate it in the RTL pattern so 23400 that the jump optimizer will not delete the table as unreachable 23401 code. 23402 23403 `decrement_and_branch_until_zero' 23404 Conditional branch instruction that decrements a register and 23405 jumps if the register is nonzero. Operand 0 is the register to 23406 decrement and test; operand 1 is the label to jump to if the 23407 register is nonzero. *Note Looping Patterns::. 23408 23409 This optional instruction pattern is only used by the combiner, 23410 typically for loops reversed by the loop optimizer when strength 23411 reduction is enabled. 23412 23413 `doloop_end' 23414 Conditional branch instruction that decrements a register and 23415 jumps if the register is nonzero. This instruction takes five 23416 operands: Operand 0 is the register to decrement and test; operand 23417 1 is the number of loop iterations as a `const_int' or 23418 `const0_rtx' if this cannot be determined until run-time; operand 23419 2 is the actual or estimated maximum number of iterations as a 23420 `const_int'; operand 3 is the number of enclosed loops as a 23421 `const_int' (an innermost loop has a value of 1); operand 4 is the 23422 label to jump to if the register is nonzero; operand 5 is 23423 const1_rtx if the loop in entered at its top, const0_rtx otherwise. 23424 *Note Looping Patterns::. 23425 23426 This optional instruction pattern should be defined for machines 23427 with low-overhead looping instructions as the loop optimizer will 23428 try to modify suitable loops to utilize it. If nested 23429 low-overhead looping is not supported, use a `define_expand' 23430 (*note Expander Definitions::) and make the pattern fail if 23431 operand 3 is not `const1_rtx'. Similarly, if the actual or 23432 estimated maximum number of iterations is too large for this 23433 instruction, make it fail. 23434 23435 `doloop_begin' 23436 Companion instruction to `doloop_end' required for machines that 23437 need to perform some initialization, such as loading special 23438 registers used by a low-overhead looping instruction. If 23439 initialization insns do not always need to be emitted, use a 23440 `define_expand' (*note Expander Definitions::) and make it fail. 23441 23442 `canonicalize_funcptr_for_compare' 23443 Canonicalize the function pointer in operand 1 and store the result 23444 into operand 0. 23445 23446 Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be 23447 a `reg', `mem', `symbol_ref', `const_int', etc and also has mode 23448 `Pmode'. 23449 23450 Canonicalization of a function pointer usually involves computing 23451 the address of the function which would be called if the function 23452 pointer were used in an indirect call. 23453 23454 Only define this pattern if function pointers on the target machine 23455 can have different values but still call the same function when 23456 used in an indirect call. 23457 23458 `save_stack_block' 23459 `save_stack_function' 23460 `save_stack_nonlocal' 23461 `restore_stack_block' 23462 `restore_stack_function' 23463 `restore_stack_nonlocal' 23464 Most machines save and restore the stack pointer by copying it to 23465 or from an object of mode `Pmode'. Do not define these patterns on 23466 such machines. 23467 23468 Some machines require special handling for stack pointer saves and 23469 restores. On those machines, define the patterns corresponding to 23470 the non-standard cases by using a `define_expand' (*note Expander 23471 Definitions::) that produces the required insns. The three types 23472 of saves and restores are: 23473 23474 1. `save_stack_block' saves the stack pointer at the start of a 23475 block that allocates a variable-sized object, and 23476 `restore_stack_block' restores the stack pointer when the 23477 block is exited. 23478 23479 2. `save_stack_function' and `restore_stack_function' do a 23480 similar job for the outermost block of a function and are 23481 used when the function allocates variable-sized objects or 23482 calls `alloca'. Only the epilogue uses the restored stack 23483 pointer, allowing a simpler save or restore sequence on some 23484 machines. 23485 23486 3. `save_stack_nonlocal' is used in functions that contain labels 23487 branched to by nested functions. It saves the stack pointer 23488 in such a way that the inner function can use 23489 `restore_stack_nonlocal' to restore the stack pointer. The 23490 compiler generates code to restore the frame and argument 23491 pointer registers, but some machines require saving and 23492 restoring additional data such as register window information 23493 or stack backchains. Place insns in these patterns to save 23494 and restore any such required data. 23495 23496 When saving the stack pointer, operand 0 is the save area and 23497 operand 1 is the stack pointer. The mode used to allocate the 23498 save area defaults to `Pmode' but you can override that choice by 23499 defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 23500 You must specify an integral mode, or `VOIDmode' if no save area 23501 is needed for a particular type of save (either because no save is 23502 needed or because a machine-specific save area can be used). 23503 Operand 0 is the stack pointer and operand 1 is the save area for 23504 restore operations. If `save_stack_block' is defined, operand 0 23505 must not be `VOIDmode' since these saves can be arbitrarily nested. 23506 23507 A save area is a `mem' that is at a constant offset from 23508 `virtual_stack_vars_rtx' when the stack pointer is saved for use by 23509 nonlocal gotos and a `reg' in the other two cases. 23510 23511 `allocate_stack' 23512 Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1 23513 from the stack pointer to create space for dynamically allocated 23514 data. 23515 23516 Store the resultant pointer to this space into operand 0. If you 23517 are allocating space from the main stack, do this by emitting a 23518 move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If 23519 you are allocating the space elsewhere, generate code to copy the 23520 location of the space to operand 0. In the latter case, you must 23521 ensure this space gets freed when the corresponding space on the 23522 main stack is free. 23523 23524 Do not define this pattern if all that must be done is the 23525 subtraction. Some machines require other operations such as stack 23526 probes or maintaining the back chain. Define this pattern to emit 23527 those operations in addition to updating the stack pointer. 23528 23529 `check_stack' 23530 If stack checking (*note Stack Checking::) cannot be done on your 23531 system by probing the stack, define this pattern to perform the 23532 needed check and signal an error if the stack has overflowed. The 23533 single operand is the address in the stack farthest from the 23534 current stack pointer that you need to validate. Normally, on 23535 platforms where this pattern is needed, you would obtain the stack 23536 limit from a global or thread-specific variable or register. 23537 23538 `probe_stack_address' 23539 If stack checking (*note Stack Checking::) can be done on your 23540 system by probing the stack but without the need to actually 23541 access it, define this pattern and signal an error if the stack 23542 has overflowed. The single operand is the memory address in the 23543 stack that needs to be probed. 23544 23545 `probe_stack' 23546 If stack checking (*note Stack Checking::) can be done on your 23547 system by probing the stack but doing it with a "store zero" 23548 instruction is not valid or optimal, define this pattern to do the 23549 probing differently and signal an error if the stack has 23550 overflowed. The single operand is the memory reference in the 23551 stack that needs to be probed. 23552 23553 `nonlocal_goto' 23554 Emit code to generate a non-local goto, e.g., a jump from one 23555 function to a label in an outer function. This pattern has four 23556 arguments, each representing a value to be used in the jump. The 23557 first argument is to be loaded into the frame pointer, the second 23558 is the address to branch to (code to dispatch to the actual label), 23559 the third is the address of a location where the stack is saved, 23560 and the last is the address of the label, to be placed in the 23561 location for the incoming static chain. 23562 23563 On most machines you need not define this pattern, since GCC will 23564 already generate the correct code, which is to load the frame 23565 pointer and static chain, restore the stack (using the 23566 `restore_stack_nonlocal' pattern, if defined), and jump indirectly 23567 to the dispatcher. You need only define this pattern if this code 23568 will not work on your machine. 23569 23570 `nonlocal_goto_receiver' 23571 This pattern, if defined, contains code needed at the target of a 23572 nonlocal goto after the code already generated by GCC. You will 23573 not normally need to define this pattern. A typical reason why 23574 you might need this pattern is if some value, such as a pointer to 23575 a global table, must be restored when the frame pointer is 23576 restored. Note that a nonlocal goto only occurs within a 23577 unit-of-translation, so a global table pointer that is shared by 23578 all functions of a given module need not be restored. There are 23579 no arguments. 23580 23581 `exception_receiver' 23582 This pattern, if defined, contains code needed at the site of an 23583 exception handler that isn't needed at the site of a nonlocal 23584 goto. You will not normally need to define this pattern. A 23585 typical reason why you might need this pattern is if some value, 23586 such as a pointer to a global table, must be restored after 23587 control flow is branched to the handler of an exception. There 23588 are no arguments. 23589 23590 `builtin_setjmp_setup' 23591 This pattern, if defined, contains additional code needed to 23592 initialize the `jmp_buf'. You will not normally need to define 23593 this pattern. A typical reason why you might need this pattern is 23594 if some value, such as a pointer to a global table, must be 23595 restored. Though it is preferred that the pointer value be 23596 recalculated if possible (given the address of a label for 23597 instance). The single argument is a pointer to the `jmp_buf'. 23598 Note that the buffer is five words long and that the first three 23599 are normally used by the generic mechanism. 23600 23601 `builtin_setjmp_receiver' 23602 This pattern, if defined, contains code needed at the site of a 23603 built-in setjmp that isn't needed at the site of a nonlocal goto. 23604 You will not normally need to define this pattern. A typical 23605 reason why you might need this pattern is if some value, such as a 23606 pointer to a global table, must be restored. It takes one 23607 argument, which is the label to which builtin_longjmp transferred 23608 control; this pattern may be emitted at a small offset from that 23609 label. 23610 23611 `builtin_longjmp' 23612 This pattern, if defined, performs the entire action of the 23613 longjmp. You will not normally need to define this pattern unless 23614 you also define `builtin_setjmp_setup'. The single argument is a 23615 pointer to the `jmp_buf'. 23616 23617 `eh_return' 23618 This pattern, if defined, affects the way `__builtin_eh_return', 23619 and thence the call frame exception handling library routines, are 23620 built. It is intended to handle non-trivial actions needed along 23621 the abnormal return path. 23622 23623 The address of the exception handler to which the function should 23624 return is passed as operand to this pattern. It will normally 23625 need to copied by the pattern to some special register or memory 23626 location. If the pattern needs to determine the location of the 23627 target call frame in order to do so, it may use 23628 `EH_RETURN_STACKADJ_RTX', if defined; it will have already been 23629 assigned. 23630 23631 If this pattern is not defined, the default action will be to 23632 simply copy the return address to `EH_RETURN_HANDLER_RTX'. Either 23633 that macro or this pattern needs to be defined if call frame 23634 exception handling is to be used. 23635 23636 `prologue' 23637 This pattern, if defined, emits RTL for entry to a function. The 23638 function entry is responsible for setting up the stack frame, 23639 initializing the frame pointer register, saving callee saved 23640 registers, etc. 23641 23642 Using a prologue pattern is generally preferred over defining 23643 `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 23644 prologue. 23645 23646 The `prologue' pattern is particularly useful for targets which 23647 perform instruction scheduling. 23648 23649 `window_save' 23650 This pattern, if defined, emits RTL for a register window save. 23651 It should be defined if the target machine has register windows 23652 but the window events are decoupled from calls to subroutines. 23653 The canonical example is the SPARC architecture. 23654 23655 `epilogue' 23656 This pattern emits RTL for exit from a function. The function 23657 exit is responsible for deallocating the stack frame, restoring 23658 callee saved registers and emitting the return instruction. 23659 23660 Using an epilogue pattern is generally preferred over defining 23661 `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 23662 epilogue. 23663 23664 The `epilogue' pattern is particularly useful for targets which 23665 perform instruction scheduling or which have delay slots for their 23666 return instruction. 23667 23668 `sibcall_epilogue' 23669 This pattern, if defined, emits RTL for exit from a function 23670 without the final branch back to the calling function. This 23671 pattern will be emitted before any sibling call (aka tail call) 23672 sites. 23673 23674 The `sibcall_epilogue' pattern must not clobber any arguments used 23675 for parameter passing or any stack slots for arguments passed to 23676 the current function. 23677 23678 `trap' 23679 This pattern, if defined, signals an error, typically by causing 23680 some kind of signal to be raised. Among other places, it is used 23681 by the Java front end to signal `invalid array index' exceptions. 23682 23683 `ctrapMM4' 23684 Conditional trap instruction. Operand 0 is a piece of RTL which 23685 performs a comparison, and operands 1 and 2 are the arms of the 23686 comparison. Operand 3 is the trap code, an integer. 23687 23688 A typical `ctrap' pattern looks like 23689 23690 (define_insn "ctrapsi4" 23691 [(trap_if (match_operator 0 "trap_operator" 23692 [(match_operand 1 "register_operand") 23693 (match_operand 2 "immediate_operand")]) 23694 (match_operand 3 "const_int_operand" "i"))] 23695 "" 23696 "...") 23697 23698 `prefetch' 23699 This pattern, if defined, emits code for a non-faulting data 23700 prefetch instruction. Operand 0 is the address of the memory to 23701 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 23702 for a write to the memory address, or a constant 0 otherwise. 23703 Operand 2 is the expected degree of temporal locality of the data 23704 and is a value between 0 and 3, inclusive; 0 means that the data 23705 has no temporal locality, so it need not be left in the cache 23706 after the access; 3 means that the data has a high degree of 23707 temporal locality and should be left in all levels of cache 23708 possible; 1 and 2 mean, respectively, a low or moderate degree of 23709 temporal locality. 23710 23711 Targets that do not support write prefetches or locality hints can 23712 ignore the values of operands 1 and 2. 23713 23714 `blockage' 23715 This pattern defines a pseudo insn that prevents the instruction 23716 scheduler and other passes from moving instructions and using 23717 register equivalences across the boundary defined by the blockage 23718 insn. This needs to be an UNSPEC_VOLATILE pattern or a volatile 23719 ASM. 23720 23721 `memory_barrier' 23722 If the target memory model is not fully synchronous, then this 23723 pattern should be defined to an instruction that orders both loads 23724 and stores before the instruction with respect to loads and stores 23725 after the instruction. This pattern has no operands. 23726 23727 `sync_compare_and_swapMODE' 23728 This pattern, if defined, emits code for an atomic compare-and-swap 23729 operation. Operand 1 is the memory on which the atomic operation 23730 is performed. Operand 2 is the "old" value to be compared against 23731 the current contents of the memory location. Operand 3 is the 23732 "new" value to store in the memory if the compare succeeds. 23733 Operand 0 is the result of the operation; it should contain the 23734 contents of the memory before the operation. If the compare 23735 succeeds, this should obviously be a copy of operand 2. 23736 23737 This pattern must show that both operand 0 and operand 1 are 23738 modified. 23739 23740 This pattern must issue any memory barrier instructions such that 23741 all memory operations before the atomic operation occur before the 23742 atomic operation and all memory operations after the atomic 23743 operation occur after the atomic operation. 23744 23745 For targets where the success or failure of the compare-and-swap 23746 operation is available via the status flags, it is possible to 23747 avoid a separate compare operation and issue the subsequent branch 23748 or store-flag operation immediately after the compare-and-swap. 23749 To this end, GCC will look for a `MODE_CC' set in the output of 23750 `sync_compare_and_swapMODE'; if the machine description includes 23751 such a set, the target should also define special `cbranchcc4' 23752 and/or `cstorecc4' instructions. GCC will then be able to take 23753 the destination of the `MODE_CC' set and pass it to the 23754 `cbranchcc4' or `cstorecc4' pattern as the first operand of the 23755 comparison (the second will be `(const_int 0)'). 23756 23757 For targets where the operating system may provide support for this 23758 operation via library calls, the `sync_compare_and_swap_optab' may 23759 be initialized to a function with the same interface as the 23760 `__sync_val_compare_and_swap_N' built-in. If the entire set of 23761 __SYNC builtins are supported via library calls, the target can 23762 initialize all of the optabs at once with `init_sync_libfuncs'. 23763 For the purposes of C++11 `std::atomic::is_lock_free', it is 23764 assumed that these library calls do _not_ use any kind of 23765 interruptable locking. 23766 23767 `sync_addMODE', `sync_subMODE' 23768 `sync_iorMODE', `sync_andMODE' 23769 `sync_xorMODE', `sync_nandMODE' 23770 These patterns emit code for an atomic operation on memory. 23771 Operand 0 is the memory on which the atomic operation is performed. 23772 Operand 1 is the second operand to the binary operator. 23773 23774 This pattern must issue any memory barrier instructions such that 23775 all memory operations before the atomic operation occur before the 23776 atomic operation and all memory operations after the atomic 23777 operation occur after the atomic operation. 23778 23779 If these patterns are not defined, the operation will be 23780 constructed from a compare-and-swap operation, if defined. 23781 23782 `sync_old_addMODE', `sync_old_subMODE' 23783 `sync_old_iorMODE', `sync_old_andMODE' 23784 `sync_old_xorMODE', `sync_old_nandMODE' 23785 These patterns emit code for an atomic operation on memory, and 23786 return the value that the memory contained before the operation. 23787 Operand 0 is the result value, operand 1 is the memory on which the 23788 atomic operation is performed, and operand 2 is the second operand 23789 to the binary operator. 23790 23791 This pattern must issue any memory barrier instructions such that 23792 all memory operations before the atomic operation occur before the 23793 atomic operation and all memory operations after the atomic 23794 operation occur after the atomic operation. 23795 23796 If these patterns are not defined, the operation will be 23797 constructed from a compare-and-swap operation, if defined. 23798 23799 `sync_new_addMODE', `sync_new_subMODE' 23800 `sync_new_iorMODE', `sync_new_andMODE' 23801 `sync_new_xorMODE', `sync_new_nandMODE' 23802 These patterns are like their `sync_old_OP' counterparts, except 23803 that they return the value that exists in the memory location 23804 after the operation, rather than before the operation. 23805 23806 `sync_lock_test_and_setMODE' 23807 This pattern takes two forms, based on the capabilities of the 23808 target. In either case, operand 0 is the result of the operand, 23809 operand 1 is the memory on which the atomic operation is 23810 performed, and operand 2 is the value to set in the lock. 23811 23812 In the ideal case, this operation is an atomic exchange operation, 23813 in which the previous value in memory operand is copied into the 23814 result operand, and the value operand is stored in the memory 23815 operand. 23816 23817 For less capable targets, any value operand that is not the 23818 constant 1 should be rejected with `FAIL'. In this case the 23819 target may use an atomic test-and-set bit operation. The result 23820 operand should contain 1 if the bit was previously set and 0 if 23821 the bit was previously clear. The true contents of the memory 23822 operand are implementation defined. 23823 23824 This pattern must issue any memory barrier instructions such that 23825 the pattern as a whole acts as an acquire barrier, that is all 23826 memory operations after the pattern do not occur until the lock is 23827 acquired. 23828 23829 If this pattern is not defined, the operation will be constructed 23830 from a compare-and-swap operation, if defined. 23831 23832 `sync_lock_releaseMODE' 23833 This pattern, if defined, releases a lock set by 23834 `sync_lock_test_and_setMODE'. Operand 0 is the memory that 23835 contains the lock; operand 1 is the value to store in the lock. 23836 23837 If the target doesn't implement full semantics for 23838 `sync_lock_test_and_setMODE', any value operand which is not the 23839 constant 0 should be rejected with `FAIL', and the true contents 23840 of the memory operand are implementation defined. 23841 23842 This pattern must issue any memory barrier instructions such that 23843 the pattern as a whole acts as a release barrier, that is the lock 23844 is released only after all previous memory operations have 23845 completed. 23846 23847 If this pattern is not defined, then a `memory_barrier' pattern 23848 will be emitted, followed by a store of the value to the memory 23849 operand. 23850 23851 `atomic_compare_and_swapMODE' 23852 This pattern, if defined, emits code for an atomic compare-and-swap 23853 operation with memory model semantics. Operand 2 is the memory on 23854 which the atomic operation is performed. Operand 0 is an output 23855 operand which is set to true or false based on whether the 23856 operation succeeded. Operand 1 is an output operand which is set 23857 to the contents of the memory before the operation was attempted. 23858 Operand 3 is the value that is expected to be in memory. Operand 23859 4 is the value to put in memory if the expected value is found 23860 there. Operand 5 is set to 1 if this compare and swap is to be 23861 treated as a weak operation. Operand 6 is the memory model to be 23862 used if the operation is a success. Operand 7 is the memory model 23863 to be used if the operation fails. 23864 23865 If memory referred to in operand 2 contains the value in operand 23866 3, then operand 4 is stored in memory pointed to by operand 2 and 23867 fencing based on the memory model in operand 6 is issued. 23868 23869 If memory referred to in operand 2 does not contain the value in 23870 operand 3, then fencing based on the memory model in operand 7 is 23871 issued. 23872 23873 If a target does not support weak compare-and-swap operations, or 23874 the port elects not to implement weak operations, the argument in 23875 operand 5 can be ignored. Note a strong implementation must be 23876 provided. 23877 23878 If this pattern is not provided, the `__atomic_compare_exchange' 23879 built-in functions will utilize the legacy `sync_compare_and_swap' 23880 pattern with an `__ATOMIC_SEQ_CST' memory model. 23881 23882 `atomic_loadMODE' 23883 This pattern implements an atomic load operation with memory model 23884 semantics. Operand 1 is the memory address being loaded from. 23885 Operand 0 is the result of the load. Operand 2 is the memory 23886 model to be used for the load operation. 23887 23888 If not present, the `__atomic_load' built-in function will either 23889 resort to a normal load with memory barriers, or a compare-and-swap 23890 operation if a normal load would not be atomic. 23891 23892 `atomic_storeMODE' 23893 This pattern implements an atomic store operation with memory model 23894 semantics. Operand 0 is the memory address being stored to. 23895 Operand 1 is the value to be written. Operand 2 is the memory 23896 model to be used for the operation. 23897 23898 If not present, the `__atomic_store' built-in function will 23899 attempt to perform a normal store and surround it with any 23900 required memory fences. If the store would not be atomic, then an 23901 `__atomic_exchange' is attempted with the result being ignored. 23902 23903 `atomic_exchangeMODE' 23904 This pattern implements an atomic exchange operation with memory 23905 model semantics. Operand 1 is the memory location the operation 23906 is performed on. Operand 0 is an output operand which is set to 23907 the original value contained in the memory pointed to by operand 23908 1. Operand 2 is the value to be stored. Operand 3 is the memory 23909 model to be used. 23910 23911 If this pattern is not present, the built-in function 23912 `__atomic_exchange' will attempt to preform the operation with a 23913 compare and swap loop. 23914 23915 `atomic_addMODE', `atomic_subMODE' 23916 `atomic_orMODE', `atomic_andMODE' 23917 `atomic_xorMODE', `atomic_nandMODE' 23918 These patterns emit code for an atomic operation on memory with 23919 memory model semantics. Operand 0 is the memory on which the 23920 atomic operation is performed. Operand 1 is the second operand to 23921 the binary operator. Operand 2 is the memory model to be used by 23922 the operation. 23923 23924 If these patterns are not defined, attempts will be made to use 23925 legacy `sync' patterns, or equivalent patterns which return a 23926 result. If none of these are available a compare-and-swap loop 23927 will be used. 23928 23929 `atomic_fetch_addMODE', `atomic_fetch_subMODE' 23930 `atomic_fetch_orMODE', `atomic_fetch_andMODE' 23931 `atomic_fetch_xorMODE', `atomic_fetch_nandMODE' 23932 These patterns emit code for an atomic operation on memory with 23933 memory model semantics, and return the original value. Operand 0 23934 is an output operand which contains the value of the memory 23935 location before the operation was performed. Operand 1 is the 23936 memory on which the atomic operation is performed. Operand 2 is 23937 the second operand to the binary operator. Operand 3 is the 23938 memory model to be used by the operation. 23939 23940 If these patterns are not defined, attempts will be made to use 23941 legacy `sync' patterns. If none of these are available a 23942 compare-and-swap loop will be used. 23943 23944 `atomic_add_fetchMODE', `atomic_sub_fetchMODE' 23945 `atomic_or_fetchMODE', `atomic_and_fetchMODE' 23946 `atomic_xor_fetchMODE', `atomic_nand_fetchMODE' 23947 These patterns emit code for an atomic operation on memory with 23948 memory model semantics and return the result after the operation 23949 is performed. Operand 0 is an output operand which contains the 23950 value after the operation. Operand 1 is the memory on which the 23951 atomic operation is performed. Operand 2 is the second operand to 23952 the binary operator. Operand 3 is the memory model to be used by 23953 the operation. 23954 23955 If these patterns are not defined, attempts will be made to use 23956 legacy `sync' patterns, or equivalent patterns which return the 23957 result before the operation followed by the arithmetic operation 23958 required to produce the result. If none of these are available a 23959 compare-and-swap loop will be used. 23960 23961 `atomic_test_and_set' 23962 This pattern emits code for `__builtin_atomic_test_and_set'. 23963 Operand 0 is an output operand which is set to true if the previous 23964 previous contents of the byte was "set", and false otherwise. 23965 Operand 1 is the `QImode' memory to be modified. Operand 2 is the 23966 memory model to be used. 23967 23968 The specific value that defines "set" is implementation defined, 23969 and is normally based on what is performed by the native atomic 23970 test and set instruction. 23971 23972 `mem_thread_fenceMODE' 23973 This pattern emits code required to implement a thread fence with 23974 memory model semantics. Operand 0 is the memory model to be used. 23975 23976 If this pattern is not specified, all memory models except 23977 `__ATOMIC_RELAXED' will result in issuing a `sync_synchronize' 23978 barrier pattern. 23979 23980 `mem_signal_fenceMODE' 23981 This pattern emits code required to implement a signal fence with 23982 memory model semantics. Operand 0 is the memory model to be used. 23983 23984 This pattern should impact the compiler optimizers the same way 23985 that mem_signal_fence does, but it does not need to issue any 23986 barrier instructions. 23987 23988 If this pattern is not specified, all memory models except 23989 `__ATOMIC_RELAXED' will result in issuing a `sync_synchronize' 23990 barrier pattern. 23991 23992 `get_thread_pointerMODE' 23993 `set_thread_pointerMODE' 23994 These patterns emit code that reads/sets the TLS thread pointer. 23995 Currently, these are only needed if the target needs to support the 23996 `__builtin_thread_pointer' and `__builtin_set_thread_pointer' 23997 builtins. 23998 23999 The get/set patterns have a single output/input operand 24000 respectively, with MODE intended to be `Pmode'. 24001 24002 `stack_protect_set' 24003 This pattern, if defined, moves a `ptr_mode' value from the memory 24004 in operand 1 to the memory in operand 0 without leaving the value 24005 in a register afterward. This is to avoid leaking the value some 24006 place that an attacker might use to rewrite the stack guard slot 24007 after having clobbered it. 24008 24009 If this pattern is not defined, then a plain move pattern is 24010 generated. 24011 24012 `stack_protect_test' 24013 This pattern, if defined, compares a `ptr_mode' value from the 24014 memory in operand 1 with the memory in operand 0 without leaving 24015 the value in a register afterward and branches to operand 2 if the 24016 values were equal. 24017 24018 If this pattern is not defined, then a plain compare pattern and 24019 conditional branch pattern is used. 24020 24021 `clear_cache' 24022 This pattern, if defined, flushes the instruction cache for a 24023 region of memory. The region is bounded to by the Pmode pointers 24024 in operand 0 inclusive and operand 1 exclusive. 24025 24026 If this pattern is not defined, a call to the library function 24027 `__clear_cache' is used. 24028 24029 24030 24031 File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 24032 24033 16.10 When the Order of Patterns Matters 24034 ======================================== 24035 24036 Sometimes an insn can match more than one instruction pattern. Then the 24037 pattern that appears first in the machine description is the one used. 24038 Therefore, more specific patterns (patterns that will match fewer 24039 things) and faster instructions (those that will produce better code 24040 when they do match) should usually go first in the description. 24041 24042 In some cases the effect of ordering the patterns can be used to hide 24043 a pattern when it is not valid. For example, the 68000 has an 24044 instruction for converting a fullword to floating point and another for 24045 converting a byte to floating point. An instruction converting an 24046 integer to floating point could match either one. We put the pattern 24047 to convert the fullword first to make sure that one will be used rather 24048 than the other. (Otherwise a large integer might be generated as a 24049 single-byte immediate quantity, which would not work.) Instead of 24050 using this pattern ordering it would be possible to make the pattern 24051 for convert-a-byte smart enough to deal properly with any constant 24052 value. 24053 24054 24055 File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 24056 24057 16.11 Interdependence of Patterns 24058 ================================= 24059 24060 In some cases machines support instructions identical except for the 24061 machine mode of one or more operands. For example, there may be 24062 "sign-extend halfword" and "sign-extend byte" instructions whose 24063 patterns are 24064 24065 (set (match_operand:SI 0 ...) 24066 (extend:SI (match_operand:HI 1 ...))) 24067 24068 (set (match_operand:SI 0 ...) 24069 (extend:SI (match_operand:QI 1 ...))) 24070 24071 Constant integers do not specify a machine mode, so an instruction to 24072 extend a constant value could match either pattern. The pattern it 24073 actually will match is the one that appears first in the file. For 24074 correct results, this must be the one for the widest possible mode 24075 (`HImode', here). If the pattern matches the `QImode' instruction, the 24076 results will be incorrect if the constant value does not actually fit 24077 that mode. 24078 24079 Such instructions to extend constants are rarely generated because 24080 they are optimized away, but they do occasionally happen in nonoptimized 24081 compilations. 24082 24083 If a constraint in a pattern allows a constant, the reload pass may 24084 replace a register with a constant permitted by the constraint in some 24085 cases. Similarly for memory references. Because of this substitution, 24086 you should not provide separate patterns for increment and decrement 24087 instructions. Instead, they should be generated from the same pattern 24088 that supports register-register add insns by examining the operands and 24089 generating the appropriate machine instruction. 24090 24091 24092 File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 24093 24094 16.12 Defining Jump Instruction Patterns 24095 ======================================== 24096 24097 GCC does not assume anything about how the machine realizes jumps. The 24098 machine description should define a single pattern, usually a 24099 `define_expand', which expands to all the required insns. 24100 24101 Usually, this would be a comparison insn to set the condition code and 24102 a separate branch insn testing the condition code and branching or not 24103 according to its value. For many machines, however, separating 24104 compares and branches is limiting, which is why the more flexible 24105 approach with one `define_expand' is used in GCC. The machine 24106 description becomes clearer for architectures that have 24107 compare-and-branch instructions but no condition code. It also works 24108 better when different sets of comparison operators are supported by 24109 different kinds of conditional branches (e.g. integer vs. 24110 floating-point), or by conditional branches with respect to conditional 24111 stores. 24112 24113 Two separate insns are always used if the machine description 24114 represents a condition code register using the legacy RTL expression 24115 `(cc0)', and on most machines that use a separate condition code 24116 register (*note Condition Code::). For machines that use `(cc0)', in 24117 fact, the set and use of the condition code must be separate and 24118 adjacent(1), thus allowing flags in `cc_status' to be used (*note 24119 Condition Code::) and so that the comparison and branch insns could be 24120 located from each other by using the functions `prev_cc0_setter' and 24121 `next_cc0_user'. 24122 24123 Even in this case having a single entry point for conditional branches 24124 is advantageous, because it handles equally well the case where a single 24125 comparison instruction records the results of both signed and unsigned 24126 comparison of the given operands (with the branch insns coming in 24127 distinct signed and unsigned flavors) as in the x86 or SPARC, and the 24128 case where there are distinct signed and unsigned compare instructions 24129 and only one set of conditional branch instructions as in the PowerPC. 24130 24131 ---------- Footnotes ---------- 24132 24133 (1) `note' insns can separate them, though. 24134 24135 24136 File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 24137 24138 16.13 Defining Looping Instruction Patterns 24139 =========================================== 24140 24141 Some machines have special jump instructions that can be utilized to 24142 make loops more efficient. A common example is the 68000 `dbra' 24143 instruction which performs a decrement of a register and a branch if the 24144 result was greater than zero. Other machines, in particular digital 24145 signal processors (DSPs), have special block repeat instructions to 24146 provide low-overhead loop support. For example, the TI TMS320C3x/C4x 24147 DSPs have a block repeat instruction that loads special registers to 24148 mark the top and end of a loop and to count the number of loop 24149 iterations. This avoids the need for fetching and executing a 24150 `dbra'-like instruction and avoids pipeline stalls associated with the 24151 jump. 24152 24153 GCC has three special named patterns to support low overhead looping. 24154 They are `decrement_and_branch_until_zero', `doloop_begin', and 24155 `doloop_end'. The first pattern, `decrement_and_branch_until_zero', is 24156 not emitted during RTL generation but may be emitted during the 24157 instruction combination phase. This requires the assistance of the 24158 loop optimizer, using information collected during strength reduction, 24159 to reverse a loop to count down to zero. Some targets also require the 24160 loop optimizer to add a `REG_NONNEG' note to indicate that the 24161 iteration count is always positive. This is needed if the target 24162 performs a signed loop termination test. For example, the 68000 uses a 24163 pattern similar to the following for its `dbra' instruction: 24164 24165 (define_insn "decrement_and_branch_until_zero" 24166 [(set (pc) 24167 (if_then_else 24168 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") 24169 (const_int -1)) 24170 (const_int 0)) 24171 (label_ref (match_operand 1 "" "")) 24172 (pc))) 24173 (set (match_dup 0) 24174 (plus:SI (match_dup 0) 24175 (const_int -1)))] 24176 "find_reg_note (insn, REG_NONNEG, 0)" 24177 "...") 24178 24179 Note that since the insn is both a jump insn and has an output, it must 24180 deal with its own reloads, hence the `m' constraints. Also note that 24181 since this insn is generated by the instruction combination phase 24182 combining two sequential insns together into an implicit parallel insn, 24183 the iteration counter needs to be biased by the same amount as the 24184 decrement operation, in this case -1. Note that the following similar 24185 pattern will not be matched by the combiner. 24186 24187 (define_insn "decrement_and_branch_until_zero" 24188 [(set (pc) 24189 (if_then_else 24190 (ge (match_operand:SI 0 "general_operand" "+d*am") 24191 (const_int 1)) 24192 (label_ref (match_operand 1 "" "")) 24193 (pc))) 24194 (set (match_dup 0) 24195 (plus:SI (match_dup 0) 24196 (const_int -1)))] 24197 "find_reg_note (insn, REG_NONNEG, 0)" 24198 "...") 24199 24200 The other two special looping patterns, `doloop_begin' and 24201 `doloop_end', are emitted by the loop optimizer for certain 24202 well-behaved loops with a finite number of loop iterations using 24203 information collected during strength reduction. 24204 24205 The `doloop_end' pattern describes the actual looping instruction (or 24206 the implicit looping operation) and the `doloop_begin' pattern is an 24207 optional companion pattern that can be used for initialization needed 24208 for some low-overhead looping instructions. 24209 24210 Note that some machines require the actual looping instruction to be 24211 emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 24212 the true RTL for a looping instruction at the top of the loop can cause 24213 problems with flow analysis. So instead, a dummy `doloop' insn is 24214 emitted at the end of the loop. The machine dependent reorg pass checks 24215 for the presence of this `doloop' insn and then searches back to the 24216 top of the loop, where it inserts the true looping insn (provided there 24217 are no instructions in the loop which would cause problems). Any 24218 additional labels can be emitted at this point. In addition, if the 24219 desired special iteration counter register was not allocated, this 24220 machine dependent reorg pass could emit a traditional compare and jump 24221 instruction pair. 24222 24223 The essential difference between the `decrement_and_branch_until_zero' 24224 and the `doloop_end' patterns is that the loop optimizer allocates an 24225 additional pseudo register for the latter as an iteration counter. 24226 This pseudo register cannot be used within the loop (i.e., general 24227 induction variables cannot be derived from it), however, in many cases 24228 the loop induction variable may become redundant and removed by the 24229 flow pass. 24230 24231 24232 File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 24233 24234 16.14 Canonicalization of Instructions 24235 ====================================== 24236 24237 There are often cases where multiple RTL expressions could represent an 24238 operation performed by a single machine instruction. This situation is 24239 most commonly encountered with logical, branch, and multiply-accumulate 24240 instructions. In such cases, the compiler attempts to convert these 24241 multiple RTL expressions into a single canonical form to reduce the 24242 number of insn patterns required. 24243 24244 In addition to algebraic simplifications, following canonicalizations 24245 are performed: 24246 24247 * For commutative and comparison operators, a constant is always 24248 made the second operand. If a machine only supports a constant as 24249 the second operand, only patterns that match a constant in the 24250 second operand need be supplied. 24251 24252 * For associative operators, a sequence of operators will always 24253 chain to the left; for instance, only the left operand of an 24254 integer `plus' can itself be a `plus'. `and', `ior', `xor', 24255 `plus', `mult', `smin', `smax', `umin', and `umax' are associative 24256 when applied to integers, and sometimes to floating-point. 24257 24258 * For these operators, if only one operand is a `neg', `not', 24259 `mult', `plus', or `minus' expression, it will be the first 24260 operand. 24261 24262 * In combinations of `neg', `mult', `plus', and `minus', the `neg' 24263 operations (if any) will be moved inside the operations as far as 24264 possible. For instance, `(neg (mult A B))' is canonicalized as 24265 `(mult (neg A) B)', but `(plus (mult (neg B) C) A)' is 24266 canonicalized as `(minus A (mult B C))'. 24267 24268 * For the `compare' operator, a constant is always the second operand 24269 if the first argument is a condition code register or `(cc0)'. 24270 24271 * An operand of `neg', `not', `mult', `plus', or `minus' is made the 24272 first operand under the same conditions as above. 24273 24274 * `(ltu (plus A B) B)' is converted to `(ltu (plus A B) A)'. 24275 Likewise with `geu' instead of `ltu'. 24276 24277 * `(minus X (const_int N))' is converted to `(plus X (const_int 24278 -N))'. 24279 24280 * Within address computations (i.e., inside `mem'), a left shift is 24281 converted into the appropriate multiplication by a power of two. 24282 24283 * De Morgan's Law is used to move bitwise negation inside a bitwise 24284 logical-and or logical-or operation. If this results in only one 24285 operand being a `not' expression, it will be the first one. 24286 24287 A machine that has an instruction that performs a bitwise 24288 logical-and of one operand with the bitwise negation of the other 24289 should specify the pattern for that instruction as 24290 24291 (define_insn "" 24292 [(set (match_operand:M 0 ...) 24293 (and:M (not:M (match_operand:M 1 ...)) 24294 (match_operand:M 2 ...)))] 24295 "..." 24296 "...") 24297 24298 Similarly, a pattern for a "NAND" instruction should be written 24299 24300 (define_insn "" 24301 [(set (match_operand:M 0 ...) 24302 (ior:M (not:M (match_operand:M 1 ...)) 24303 (not:M (match_operand:M 2 ...))))] 24304 "..." 24305 "...") 24306 24307 In both cases, it is not necessary to include patterns for the many 24308 logically equivalent RTL expressions. 24309 24310 * The only possible RTL expressions involving both bitwise 24311 exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M 24312 (xor:M X Y))'. 24313 24314 * The sum of three items, one of which is a constant, will only 24315 appear in the form 24316 24317 (plus:M (plus:M X Y) CONSTANT) 24318 24319 * Equality comparisons of a group of bits (usually a single bit) 24320 with zero will be written using `zero_extract' rather than the 24321 equivalent `and' or `sign_extract' operations. 24322 24323 * `(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))' 24324 is converted to `(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))', 24325 and likewise for `zero_extend'. 24326 24327 * `(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))' 24328 is converted to `(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S)) 24329 (sign_extend:M1 Y))', and likewise for patterns using 24330 `zero_extend' and `lshiftrt'. If the second operand of `mult' is 24331 also a shift, then that is extended also. This transformation is 24332 only applied when it can be proven that the original operation had 24333 sufficient precision to prevent overflow. 24334 24335 24336 Further canonicalization rules are defined in the function 24337 `commutative_operand_precedence' in `gcc/rtlanal.c'. 24338 24339 24340 File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 24341 24342 16.15 Defining RTL Sequences for Code Generation 24343 ================================================ 24344 24345 On some target machines, some standard pattern names for RTL generation 24346 cannot be handled with single insn, but a sequence of RTL insns can 24347 represent them. For these target machines, you can write a 24348 `define_expand' to specify how to generate the sequence of RTL. 24349 24350 A `define_expand' is an RTL expression that looks almost like a 24351 `define_insn'; but, unlike the latter, a `define_expand' is used only 24352 for RTL generation and it can produce more than one RTL insn. 24353 24354 A `define_expand' RTX has four operands: 24355 24356 * The name. Each `define_expand' must have a name, since the only 24357 use for it is to refer to it by name. 24358 24359 * The RTL template. This is a vector of RTL expressions representing 24360 a sequence of separate instructions. Unlike `define_insn', there 24361 is no implicit surrounding `PARALLEL'. 24362 24363 * The condition, a string containing a C expression. This 24364 expression is used to express how the availability of this pattern 24365 depends on subclasses of target machine, selected by command-line 24366 options when GCC is run. This is just like the condition of a 24367 `define_insn' that has a standard name. Therefore, the condition 24368 (if present) may not depend on the data in the insn being matched, 24369 but only the target-machine-type flags. The compiler needs to 24370 test these conditions during initialization in order to learn 24371 exactly which named instructions are available in a particular run. 24372 24373 * The preparation statements, a string containing zero or more C 24374 statements which are to be executed before RTL code is generated 24375 from the RTL template. 24376 24377 Usually these statements prepare temporary registers for use as 24378 internal operands in the RTL template, but they can also generate 24379 RTL insns directly by calling routines such as `emit_insn', etc. 24380 Any such insns precede the ones that come from the RTL template. 24381 24382 * Optionally, a vector containing the values of attributes. *Note 24383 Insn Attributes::. 24384 24385 Every RTL insn emitted by a `define_expand' must match some 24386 `define_insn' in the machine description. Otherwise, the compiler will 24387 crash when trying to generate code for the insn or trying to optimize 24388 it. 24389 24390 The RTL template, in addition to controlling generation of RTL insns, 24391 also describes the operands that need to be specified when this pattern 24392 is used. In particular, it gives a predicate for each operand. 24393 24394 A true operand, which needs to be specified in order to generate RTL 24395 from the pattern, should be described with a `match_operand' in its 24396 first occurrence in the RTL template. This enters information on the 24397 operand's predicate into the tables that record such things. GCC uses 24398 the information to preload the operand into a register if that is 24399 required for valid RTL code. If the operand is referred to more than 24400 once, subsequent references should use `match_dup'. 24401 24402 The RTL template may also refer to internal "operands" which are 24403 temporary registers or labels used only within the sequence made by the 24404 `define_expand'. Internal operands are substituted into the RTL 24405 template with `match_dup', never with `match_operand'. The values of 24406 the internal operands are not passed in as arguments by the compiler 24407 when it requests use of this pattern. Instead, they are computed 24408 within the pattern, in the preparation statements. These statements 24409 compute the values and store them into the appropriate elements of 24410 `operands' so that `match_dup' can find them. 24411 24412 There are two special macros defined for use in the preparation 24413 statements: `DONE' and `FAIL'. Use them with a following semicolon, as 24414 a statement. 24415 24416 `DONE' 24417 Use the `DONE' macro to end RTL generation for the pattern. The 24418 only RTL insns resulting from the pattern on this occasion will be 24419 those already emitted by explicit calls to `emit_insn' within the 24420 preparation statements; the RTL template will not be generated. 24421 24422 `FAIL' 24423 Make the pattern fail on this occasion. When a pattern fails, it 24424 means that the pattern was not truly available. The calling 24425 routines in the compiler will try other strategies for code 24426 generation using other patterns. 24427 24428 Failure is currently supported only for binary (addition, 24429 multiplication, shifting, etc.) and bit-field (`extv', `extzv', 24430 and `insv') operations. 24431 24432 If the preparation falls through (invokes neither `DONE' nor `FAIL'), 24433 then the `define_expand' acts like a `define_insn' in that the RTL 24434 template is used to generate the insn. 24435 24436 The RTL template is not used for matching, only for generating the 24437 initial insn list. If the preparation statement always invokes `DONE' 24438 or `FAIL', the RTL template may be reduced to a simple list of 24439 operands, such as this example: 24440 24441 (define_expand "addsi3" 24442 [(match_operand:SI 0 "register_operand" "") 24443 (match_operand:SI 1 "register_operand" "") 24444 (match_operand:SI 2 "register_operand" "")] 24445 "" 24446 " 24447 { 24448 handle_add (operands[0], operands[1], operands[2]); 24449 DONE; 24450 }") 24451 24452 Here is an example, the definition of left-shift for the SPUR chip: 24453 24454 (define_expand "ashlsi3" 24455 [(set (match_operand:SI 0 "register_operand" "") 24456 (ashift:SI 24457 (match_operand:SI 1 "register_operand" "") 24458 (match_operand:SI 2 "nonmemory_operand" "")))] 24459 "" 24460 " 24461 24462 { 24463 if (GET_CODE (operands[2]) != CONST_INT 24464 || (unsigned) INTVAL (operands[2]) > 3) 24465 FAIL; 24466 }") 24467 24468 This example uses `define_expand' so that it can generate an RTL insn 24469 for shifting when the shift-count is in the supported range of 0 to 3 24470 but fail in other cases where machine insns aren't available. When it 24471 fails, the compiler tries another strategy using different patterns 24472 (such as, a library call). 24473 24474 If the compiler were able to handle nontrivial condition-strings in 24475 patterns with names, then it would be possible to use a `define_insn' 24476 in that case. Here is another case (zero-extension on the 68000) which 24477 makes more use of the power of `define_expand': 24478 24479 (define_expand "zero_extendhisi2" 24480 [(set (match_operand:SI 0 "general_operand" "") 24481 (const_int 0)) 24482 (set (strict_low_part 24483 (subreg:HI 24484 (match_dup 0) 24485 0)) 24486 (match_operand:HI 1 "general_operand" ""))] 24487 "" 24488 "operands[1] = make_safe_from (operands[1], operands[0]);") 24489 24490 Here two RTL insns are generated, one to clear the entire output operand 24491 and the other to copy the input operand into its low half. This 24492 sequence is incorrect if the input operand refers to [the old value of] 24493 the output operand, so the preparation statement makes sure this isn't 24494 so. The function `make_safe_from' copies the `operands[1]' into a 24495 temporary register if it refers to `operands[0]'. It does this by 24496 emitting another RTL insn. 24497 24498 Finally, a third example shows the use of an internal operand. 24499 Zero-extension on the SPUR chip is done by `and'-ing the result against 24500 a halfword mask. But this mask cannot be represented by a `const_int' 24501 because the constant value is too large to be legitimate on this 24502 machine. So it must be copied into a register with `force_reg' and 24503 then the register used in the `and'. 24504 24505 (define_expand "zero_extendhisi2" 24506 [(set (match_operand:SI 0 "register_operand" "") 24507 (and:SI (subreg:SI 24508 (match_operand:HI 1 "register_operand" "") 24509 0) 24510 (match_dup 2)))] 24511 "" 24512 "operands[2] 24513 = force_reg (SImode, GEN_INT (65535)); ") 24514 24515 _Note:_ If the `define_expand' is used to serve a standard binary or 24516 unary arithmetic operation or a bit-field operation, then the last insn 24517 it generates must not be a `code_label', `barrier' or `note'. It must 24518 be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn 24519 at the end, emit an insn to copy the result of the operation into 24520 itself. Such an insn will generate no code, but it can avoid problems 24521 in the compiler. 24522 24523 24524 File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 24525 24526 16.16 Defining How to Split Instructions 24527 ======================================== 24528 24529 There are two cases where you should specify how to split a pattern 24530 into multiple insns. On machines that have instructions requiring 24531 delay slots (*note Delay Slots::) or that have instructions whose 24532 output is not available for multiple cycles (*note Processor pipeline 24533 description::), the compiler phases that optimize these cases need to 24534 be able to move insns into one-instruction delay slots. However, some 24535 insns may generate more than one machine instruction. These insns 24536 cannot be placed into a delay slot. 24537 24538 Often you can rewrite the single insn as a list of individual insns, 24539 each corresponding to one machine instruction. The disadvantage of 24540 doing so is that it will cause the compilation to be slower and require 24541 more space. If the resulting insns are too complex, it may also 24542 suppress some optimizations. The compiler splits the insn if there is a 24543 reason to believe that it might improve instruction or delay slot 24544 scheduling. 24545 24546 The insn combiner phase also splits putative insns. If three insns are 24547 merged into one insn with a complex expression that cannot be matched by 24548 some `define_insn' pattern, the combiner phase attempts to split the 24549 complex pattern into two insns that are recognized. Usually it can 24550 break the complex pattern into two patterns by splitting out some 24551 subexpression. However, in some other cases, such as performing an 24552 addition of a large constant in two insns on a RISC machine, the way to 24553 split the addition into two insns is machine-dependent. 24554 24555 The `define_split' definition tells the compiler how to split a 24556 complex insn into several simpler insns. It looks like this: 24557 24558 (define_split 24559 [INSN-PATTERN] 24560 "CONDITION" 24561 [NEW-INSN-PATTERN-1 24562 NEW-INSN-PATTERN-2 24563 ...] 24564 "PREPARATION-STATEMENTS") 24565 24566 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 24567 final condition to be tested, as in a `define_insn'. When an insn 24568 matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 24569 in the insn list with the insns given by NEW-INSN-PATTERN-1, 24570 NEW-INSN-PATTERN-2, etc. 24571 24572 The PREPARATION-STATEMENTS are similar to those statements that are 24573 specified for `define_expand' (*note Expander Definitions::) and are 24574 executed before the new RTL is generated to prepare for the generated 24575 code or emit some insns whose pattern is not fixed. Unlike those in 24576 `define_expand', however, these statements must not generate any new 24577 pseudo-registers. Once reload has completed, they also must not 24578 allocate any space in the stack frame. 24579 24580 Patterns are matched against INSN-PATTERN in two different 24581 circumstances. If an insn needs to be split for delay slot scheduling 24582 or insn scheduling, the insn is already known to be valid, which means 24583 that it must have been matched by some `define_insn' and, if 24584 `reload_completed' is nonzero, is known to satisfy the constraints of 24585 that `define_insn'. In that case, the new insn patterns must also be 24586 insns that are matched by some `define_insn' and, if `reload_completed' 24587 is nonzero, must also satisfy the constraints of those definitions. 24588 24589 As an example of this usage of `define_split', consider the following 24590 example from `a29k.md', which splits a `sign_extend' from `HImode' to 24591 `SImode' into a pair of shift insns: 24592 24593 (define_split 24594 [(set (match_operand:SI 0 "gen_reg_operand" "") 24595 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 24596 "" 24597 [(set (match_dup 0) 24598 (ashift:SI (match_dup 1) 24599 (const_int 16))) 24600 (set (match_dup 0) 24601 (ashiftrt:SI (match_dup 0) 24602 (const_int 16)))] 24603 " 24604 { operands[1] = gen_lowpart (SImode, operands[1]); }") 24605 24606 When the combiner phase tries to split an insn pattern, it is always 24607 the case that the pattern is _not_ matched by any `define_insn'. The 24608 combiner pass first tries to split a single `set' expression and then 24609 the same `set' expression inside a `parallel', but followed by a 24610 `clobber' of a pseudo-reg to use as a scratch register. In these 24611 cases, the combiner expects exactly two new insn patterns to be 24612 generated. It will verify that these patterns match some `define_insn' 24613 definitions, so you need not do this test in the `define_split' (of 24614 course, there is no point in writing a `define_split' that will never 24615 produce insns that match). 24616 24617 Here is an example of this use of `define_split', taken from 24618 `rs6000.md': 24619 24620 (define_split 24621 [(set (match_operand:SI 0 "gen_reg_operand" "") 24622 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 24623 (match_operand:SI 2 "non_add_cint_operand" "")))] 24624 "" 24625 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 24626 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 24627 " 24628 { 24629 int low = INTVAL (operands[2]) & 0xffff; 24630 int high = (unsigned) INTVAL (operands[2]) >> 16; 24631 24632 if (low & 0x8000) 24633 high++, low |= 0xffff0000; 24634 24635 operands[3] = GEN_INT (high << 16); 24636 operands[4] = GEN_INT (low); 24637 }") 24638 24639 Here the predicate `non_add_cint_operand' matches any `const_int' that 24640 is _not_ a valid operand of a single add insn. The add with the 24641 smaller displacement is written so that it can be substituted into the 24642 address of a subsequent operation. 24643 24644 An example that uses a scratch register, from the same file, generates 24645 an equality comparison of a register and a large constant: 24646 24647 (define_split 24648 [(set (match_operand:CC 0 "cc_reg_operand" "") 24649 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 24650 (match_operand:SI 2 "non_short_cint_operand" ""))) 24651 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 24652 "find_single_use (operands[0], insn, 0) 24653 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 24654 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 24655 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 24656 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 24657 " 24658 { 24659 /* Get the constant we are comparing against, C, and see what it 24660 looks like sign-extended to 16 bits. Then see what constant 24661 could be XOR'ed with C to get the sign-extended value. */ 24662 24663 int c = INTVAL (operands[2]); 24664 int sextc = (c << 16) >> 16; 24665 int xorv = c ^ sextc; 24666 24667 operands[4] = GEN_INT (xorv); 24668 operands[5] = GEN_INT (sextc); 24669 }") 24670 24671 To avoid confusion, don't write a single `define_split' that accepts 24672 some insns that match some `define_insn' as well as some insns that 24673 don't. Instead, write two separate `define_split' definitions, one for 24674 the insns that are valid and one for the insns that are not valid. 24675 24676 The splitter is allowed to split jump instructions into sequence of 24677 jumps or create new jumps in while splitting non-jump instructions. As 24678 the central flowgraph and branch prediction information needs to be 24679 updated, several restriction apply. 24680 24681 Splitting of jump instruction into sequence that over by another jump 24682 instruction is always valid, as compiler expect identical behavior of 24683 new jump. When new sequence contains multiple jump instructions or new 24684 labels, more assistance is needed. Splitter is required to create only 24685 unconditional jumps, or simple conditional jump instructions. 24686 Additionally it must attach a `REG_BR_PROB' note to each conditional 24687 jump. A global variable `split_branch_probability' holds the 24688 probability of the original branch in case it was a simple conditional 24689 jump, -1 otherwise. To simplify recomputing of edge frequencies, the 24690 new sequence is required to have only forward jumps to the newly 24691 created labels. 24692 24693 For the common case where the pattern of a define_split exactly 24694 matches the pattern of a define_insn, use `define_insn_and_split'. It 24695 looks like this: 24696 24697 (define_insn_and_split 24698 [INSN-PATTERN] 24699 "CONDITION" 24700 "OUTPUT-TEMPLATE" 24701 "SPLIT-CONDITION" 24702 [NEW-INSN-PATTERN-1 24703 NEW-INSN-PATTERN-2 24704 ...] 24705 "PREPARATION-STATEMENTS" 24706 [INSN-ATTRIBUTES]) 24707 24708 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 24709 as in `define_insn'. The NEW-INSN-PATTERN vector and the 24710 PREPARATION-STATEMENTS are used as in a `define_split'. The 24711 SPLIT-CONDITION is also used as in `define_split', with the additional 24712 behavior that if the condition starts with `&&', the condition used for 24713 the split will be the constructed as a logical "and" of the split 24714 condition with the insn condition. For example, from i386.md: 24715 24716 (define_insn_and_split "zero_extendhisi2_and" 24717 [(set (match_operand:SI 0 "register_operand" "=r") 24718 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 24719 (clobber (reg:CC 17))] 24720 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 24721 "#" 24722 "&& reload_completed" 24723 [(parallel [(set (match_dup 0) 24724 (and:SI (match_dup 0) (const_int 65535))) 24725 (clobber (reg:CC 17))])] 24726 "" 24727 [(set_attr "type" "alu1")]) 24728 24729 In this case, the actual split condition will be 24730 `TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 24731 24732 The `define_insn_and_split' construction provides exactly the same 24733 functionality as two separate `define_insn' and `define_split' 24734 patterns. It exists for compactness, and as a maintenance tool to 24735 prevent having to ensure the two patterns' templates match. 24736 24737 24738 File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 24739 24740 16.17 Including Patterns in Machine Descriptions. 24741 ================================================= 24742 24743 The `include' pattern tells the compiler tools where to look for 24744 patterns that are in files other than in the file `.md'. This is used 24745 only at build time and there is no preprocessing allowed. 24746 24747 It looks like: 24748 24749 24750 (include 24751 PATHNAME) 24752 24753 For example: 24754 24755 24756 (include "filestuff") 24757 24758 Where PATHNAME is a string that specifies the location of the file, 24759 specifies the include file to be in `gcc/config/target/filestuff'. The 24760 directory `gcc/config/target' is regarded as the default directory. 24761 24762 Machine descriptions may be split up into smaller more manageable 24763 subsections and placed into subdirectories. 24764 24765 By specifying: 24766 24767 24768 (include "BOGUS/filestuff") 24769 24770 the include file is specified to be in 24771 `gcc/config/TARGET/BOGUS/filestuff'. 24772 24773 Specifying an absolute path for the include file such as; 24774 24775 (include "/u2/BOGUS/filestuff") 24776 is permitted but is not encouraged. 24777 24778 16.17.1 RTL Generation Tool Options for Directory Search 24779 -------------------------------------------------------- 24780 24781 The `-IDIR' option specifies directories to search for machine 24782 descriptions. For example: 24783 24784 24785 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 24786 24787 Add the directory DIR to the head of the list of directories to be 24788 searched for header files. This can be used to override a system 24789 machine definition file, substituting your own version, since these 24790 directories are searched before the default machine description file 24791 directories. If you use more than one `-I' option, the directories are 24792 scanned in left-to-right order; the standard default directory come 24793 after. 24794 24795 24796 File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 24797 24798 16.18 Machine-Specific Peephole Optimizers 24799 ========================================== 24800 24801 In addition to instruction patterns the `md' file may contain 24802 definitions of machine-specific peephole optimizations. 24803 24804 The combiner does not notice certain peephole optimizations when the 24805 data flow in the program does not suggest that it should try them. For 24806 example, sometimes two consecutive insns related in purpose can be 24807 combined even though the second one does not appear to use a register 24808 computed in the first one. A machine-specific peephole optimizer can 24809 detect such opportunities. 24810 24811 There are two forms of peephole definitions that may be used. The 24812 original `define_peephole' is run at assembly output time to match 24813 insns and substitute assembly text. Use of `define_peephole' is 24814 deprecated. 24815 24816 A newer `define_peephole2' matches insns and substitutes new insns. 24817 The `peephole2' pass is run after register allocation but before 24818 scheduling, which may result in much better code for targets that do 24819 scheduling. 24820 24821 * Menu: 24822 24823 * define_peephole:: RTL to Text Peephole Optimizers 24824 * define_peephole2:: RTL to RTL Peephole Optimizers 24825 24826 24827 File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 24828 24829 16.18.1 RTL to Text Peephole Optimizers 24830 --------------------------------------- 24831 24832 A definition looks like this: 24833 24834 (define_peephole 24835 [INSN-PATTERN-1 24836 INSN-PATTERN-2 24837 ...] 24838 "CONDITION" 24839 "TEMPLATE" 24840 "OPTIONAL-INSN-ATTRIBUTES") 24841 24842 The last string operand may be omitted if you are not using any 24843 machine-specific information in this machine description. If present, 24844 it must obey the same rules as in a `define_insn'. 24845 24846 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 24847 consecutive insns. The optimization applies to a sequence of insns when 24848 INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 24849 and so on. 24850 24851 Each of the insns matched by a peephole must also match a 24852 `define_insn'. Peepholes are checked only at the last stage just 24853 before code generation, and only optionally. Therefore, any insn which 24854 would match a peephole but no `define_insn' will cause a crash in code 24855 generation in an unoptimized compilation, or at various optimization 24856 stages. 24857 24858 The operands of the insns are matched with `match_operands', 24859 `match_operator', and `match_dup', as usual. What is not usual is that 24860 the operand numbers apply to all the insn patterns in the definition. 24861 So, you can check for identical operands in two insns by using 24862 `match_operand' in one insn and `match_dup' in the other. 24863 24864 The operand constraints used in `match_operand' patterns do not have 24865 any direct effect on the applicability of the peephole, but they will 24866 be validated afterward, so make sure your constraints are general enough 24867 to apply whenever the peephole matches. If the peephole matches but 24868 the constraints are not satisfied, the compiler will crash. 24869 24870 It is safe to omit constraints in all the operands of the peephole; or 24871 you can write constraints which serve as a double-check on the criteria 24872 previously tested. 24873 24874 Once a sequence of insns matches the patterns, the CONDITION is 24875 checked. This is a C expression which makes the final decision whether 24876 to perform the optimization (we do so if the expression is nonzero). If 24877 CONDITION is omitted (in other words, the string is empty) then the 24878 optimization is applied to every sequence of insns that matches the 24879 patterns. 24880 24881 The defined peephole optimizations are applied after register 24882 allocation is complete. Therefore, the peephole definition can check 24883 which operands have ended up in which kinds of registers, just by 24884 looking at the operands. 24885 24886 The way to refer to the operands in CONDITION is to write 24887 `operands[I]' for operand number I (as matched by `(match_operand I 24888 ...)'). Use the variable `insn' to refer to the last of the insns 24889 being matched; use `prev_active_insn' to find the preceding insns. 24890 24891 When optimizing computations with intermediate results, you can use 24892 CONDITION to match only when the intermediate results are not used 24893 elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN 24894 is the insn in which you expect the value to be used for the last time 24895 (from the value of `insn', together with use of `prev_nonnote_insn'), 24896 and OP is the intermediate value (from `operands[I]'). 24897 24898 Applying the optimization means replacing the sequence of insns with 24899 one new insn. The TEMPLATE controls ultimate output of assembler code 24900 for this combined insn. It works exactly like the template of a 24901 `define_insn'. Operand numbers in this template are the same ones used 24902 in matching the original sequence of insns. 24903 24904 The result of a defined peephole optimizer does not need to match any 24905 of the insn patterns in the machine description; it does not even have 24906 an opportunity to match them. The peephole optimizer definition itself 24907 serves as the insn pattern to control how the insn is output. 24908 24909 Defined peephole optimizers are run as assembler code is being output, 24910 so the insns they produce are never combined or rearranged in any way. 24911 24912 Here is an example, taken from the 68000 machine description: 24913 24914 (define_peephole 24915 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 24916 (set (match_operand:DF 0 "register_operand" "=f") 24917 (match_operand:DF 1 "register_operand" "ad"))] 24918 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 24919 { 24920 rtx xoperands[2]; 24921 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 24922 #ifdef MOTOROLA 24923 output_asm_insn ("move.l %1,(sp)", xoperands); 24924 output_asm_insn ("move.l %1,-(sp)", operands); 24925 return "fmove.d (sp)+,%0"; 24926 #else 24927 output_asm_insn ("movel %1,sp@", xoperands); 24928 output_asm_insn ("movel %1,sp@-", operands); 24929 return "fmoved sp@+,%0"; 24930 #endif 24931 }) 24932 24933 The effect of this optimization is to change 24934 24935 jbsr _foobar 24936 addql #4,sp 24937 movel d1,sp@- 24938 movel d0,sp@- 24939 fmoved sp@+,fp0 24940 24941 into 24942 24943 jbsr _foobar 24944 movel d1,sp@ 24945 movel d0,sp@- 24946 fmoved sp@+,fp0 24947 24948 INSN-PATTERN-1 and so on look _almost_ like the second operand of 24949 `define_insn'. There is one important difference: the second operand 24950 of `define_insn' consists of one or more RTX's enclosed in square 24951 brackets. Usually, there is only one: then the same action can be 24952 written as an element of a `define_peephole'. But when there are 24953 multiple actions in a `define_insn', they are implicitly enclosed in a 24954 `parallel'. Then you must explicitly write the `parallel', and the 24955 square brackets within it, in the `define_peephole'. Thus, if an insn 24956 pattern looks like this, 24957 24958 (define_insn "divmodsi4" 24959 [(set (match_operand:SI 0 "general_operand" "=d") 24960 (div:SI (match_operand:SI 1 "general_operand" "0") 24961 (match_operand:SI 2 "general_operand" "dmsK"))) 24962 (set (match_operand:SI 3 "general_operand" "=d") 24963 (mod:SI (match_dup 1) (match_dup 2)))] 24964 "TARGET_68020" 24965 "divsl%.l %2,%3:%0") 24966 24967 then the way to mention this insn in a peephole is as follows: 24968 24969 (define_peephole 24970 [... 24971 (parallel 24972 [(set (match_operand:SI 0 "general_operand" "=d") 24973 (div:SI (match_operand:SI 1 "general_operand" "0") 24974 (match_operand:SI 2 "general_operand" "dmsK"))) 24975 (set (match_operand:SI 3 "general_operand" "=d") 24976 (mod:SI (match_dup 1) (match_dup 2)))]) 24977 ...] 24978 ...) 24979 24980 24981 File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 24982 24983 16.18.2 RTL to RTL Peephole Optimizers 24984 -------------------------------------- 24985 24986 The `define_peephole2' definition tells the compiler how to substitute 24987 one sequence of instructions for another sequence, what additional 24988 scratch registers may be needed and what their lifetimes must be. 24989 24990 (define_peephole2 24991 [INSN-PATTERN-1 24992 INSN-PATTERN-2 24993 ...] 24994 "CONDITION" 24995 [NEW-INSN-PATTERN-1 24996 NEW-INSN-PATTERN-2 24997 ...] 24998 "PREPARATION-STATEMENTS") 24999 25000 The definition is almost identical to `define_split' (*note Insn 25001 Splitting::) except that the pattern to match is not a single 25002 instruction, but a sequence of instructions. 25003 25004 It is possible to request additional scratch registers for use in the 25005 output template. If appropriate registers are not free, the pattern 25006 will simply not match. 25007 25008 Scratch registers are requested with a `match_scratch' pattern at the 25009 top level of the input pattern. The allocated register (initially) will 25010 be dead at the point requested within the original sequence. If the 25011 scratch is used at more than a single point, a `match_dup' pattern at 25012 the top level of the input pattern marks the last position in the input 25013 sequence at which the register must be available. 25014 25015 Here is an example from the IA-32 machine description: 25016 25017 (define_peephole2 25018 [(match_scratch:SI 2 "r") 25019 (parallel [(set (match_operand:SI 0 "register_operand" "") 25020 (match_operator:SI 3 "arith_or_logical_operator" 25021 [(match_dup 0) 25022 (match_operand:SI 1 "memory_operand" "")])) 25023 (clobber (reg:CC 17))])] 25024 "! optimize_size && ! TARGET_READ_MODIFY" 25025 [(set (match_dup 2) (match_dup 1)) 25026 (parallel [(set (match_dup 0) 25027 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 25028 (clobber (reg:CC 17))])] 25029 "") 25030 25031 This pattern tries to split a load from its use in the hopes that we'll 25032 be able to schedule around the memory load latency. It allocates a 25033 single `SImode' register of class `GENERAL_REGS' (`"r"') that needs to 25034 be live only at the point just before the arithmetic. 25035 25036 A real example requiring extended scratch lifetimes is harder to come 25037 by, so here's a silly made-up example: 25038 25039 (define_peephole2 25040 [(match_scratch:SI 4 "r") 25041 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 25042 (set (match_operand:SI 2 "" "") (match_dup 1)) 25043 (match_dup 4) 25044 (set (match_operand:SI 3 "" "") (match_dup 1))] 25045 "/* determine 1 does not overlap 0 and 2 */" 25046 [(set (match_dup 4) (match_dup 1)) 25047 (set (match_dup 0) (match_dup 4)) 25048 (set (match_dup 2) (match_dup 4))] 25049 (set (match_dup 3) (match_dup 4))] 25050 "") 25051 25052 If we had not added the `(match_dup 4)' in the middle of the input 25053 sequence, it might have been the case that the register we chose at the 25054 beginning of the sequence is killed by the first or second `set'. 25055 25056 25057 File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 25058 25059 16.19 Instruction Attributes 25060 ============================ 25061 25062 In addition to describing the instruction supported by the target 25063 machine, the `md' file also defines a group of "attributes" and a set of 25064 values for each. Every generated insn is assigned a value for each 25065 attribute. One possible attribute would be the effect that the insn 25066 has on the machine's condition code. This attribute can then be used 25067 by `NOTICE_UPDATE_CC' to track the condition codes. 25068 25069 * Menu: 25070 25071 * Defining Attributes:: Specifying attributes and their values. 25072 * Expressions:: Valid expressions for attribute values. 25073 * Tagging Insns:: Assigning attribute values to insns. 25074 * Attr Example:: An example of assigning attributes. 25075 * Insn Lengths:: Computing the length of insns. 25076 * Constant Attributes:: Defining attributes that are constant. 25077 * Delay Slots:: Defining delay slots required for a machine. 25078 * Processor pipeline description:: Specifying information for insn scheduling. 25079 25080 25081 File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 25082 25083 16.19.1 Defining Attributes and their Values 25084 -------------------------------------------- 25085 25086 The `define_attr' expression is used to define each attribute required 25087 by the target machine. It looks like: 25088 25089 (define_attr NAME LIST-OF-VALUES DEFAULT) 25090 25091 NAME is a string specifying the name of the attribute being defined. 25092 Some attributes are used in a special way by the rest of the compiler. 25093 The `enabled' attribute can be used to conditionally enable or disable 25094 insn alternatives (*note Disable Insn Alternatives::). The `predicable' 25095 attribute, together with a suitable `define_cond_exec' (*note 25096 Conditional Execution::), can be used to automatically generate 25097 conditional variants of instruction patterns. The compiler internally 25098 uses the names `ce_enabled' and `nonce_enabled', so they should not be 25099 used elsewhere as alternative names. 25100 25101 LIST-OF-VALUES is either a string that specifies a comma-separated 25102 list of values that can be assigned to the attribute, or a null string 25103 to indicate that the attribute takes numeric values. 25104 25105 DEFAULT is an attribute expression that gives the value of this 25106 attribute for insns that match patterns whose definition does not 25107 include an explicit value for this attribute. *Note Attr Example::, 25108 for more information on the handling of defaults. *Note Constant 25109 Attributes::, for information on attributes that do not depend on any 25110 particular insn. 25111 25112 For each defined attribute, a number of definitions are written to the 25113 `insn-attr.h' file. For cases where an explicit set of values is 25114 specified for an attribute, the following are defined: 25115 25116 * A `#define' is written for the symbol `HAVE_ATTR_NAME'. 25117 25118 * An enumerated class is defined for `attr_NAME' with elements of 25119 the form `UPPER-NAME_UPPER-VALUE' where the attribute name and 25120 value are first converted to uppercase. 25121 25122 * A function `get_attr_NAME' is defined that is passed an insn and 25123 returns the attribute value for that insn. 25124 25125 For example, if the following is present in the `md' file: 25126 25127 (define_attr "type" "branch,fp,load,store,arith" ...) 25128 25129 the following lines will be written to the file `insn-attr.h'. 25130 25131 #define HAVE_ATTR_type 1 25132 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 25133 TYPE_STORE, TYPE_ARITH}; 25134 extern enum attr_type get_attr_type (); 25135 25136 If the attribute takes numeric values, no `enum' type will be defined 25137 and the function to obtain the attribute's value will return `int'. 25138 25139 There are attributes which are tied to a specific meaning. These 25140 attributes are not free to use for other purposes: 25141 25142 `length' 25143 The `length' attribute is used to calculate the length of emitted 25144 code chunks. This is especially important when verifying branch 25145 distances. *Note Insn Lengths::. 25146 25147 `enabled' 25148 The `enabled' attribute can be defined to prevent certain 25149 alternatives of an insn definition from being used during code 25150 generation. *Note Disable Insn Alternatives::. 25151 25152 For each of these special attributes, the corresponding 25153 `HAVE_ATTR_NAME' `#define' is also written when the attribute is not 25154 defined; in that case, it is defined as `0'. 25155 25156 Another way of defining an attribute is to use: 25157 25158 (define_enum_attr "ATTR" "ENUM" DEFAULT) 25159 25160 This works in just the same way as `define_attr', except that the list 25161 of values is taken from a separate enumeration called ENUM (*note 25162 define_enum::). This form allows you to use the same list of values 25163 for several attributes without having to repeat the list each time. 25164 For example: 25165 25166 (define_enum "processor" [ 25167 model_a 25168 model_b 25169 ... 25170 ]) 25171 (define_enum_attr "arch" "processor" 25172 (const (symbol_ref "target_arch"))) 25173 (define_enum_attr "tune" "processor" 25174 (const (symbol_ref "target_tune"))) 25175 25176 defines the same attributes as: 25177 25178 (define_attr "arch" "model_a,model_b,..." 25179 (const (symbol_ref "target_arch"))) 25180 (define_attr "tune" "model_a,model_b,..." 25181 (const (symbol_ref "target_tune"))) 25182 25183 but without duplicating the processor list. The second example 25184 defines two separate C enums (`attr_arch' and `attr_tune') whereas the 25185 first defines a single C enum (`processor'). 25186 25187 25188 File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 25189 25190 16.19.2 Attribute Expressions 25191 ----------------------------- 25192 25193 RTL expressions used to define attributes use the codes described above 25194 plus a few specific to attribute definitions, to be discussed below. 25195 Attribute value expressions must have one of the following forms: 25196 25197 `(const_int I)' 25198 The integer I specifies the value of a numeric attribute. I must 25199 be non-negative. 25200 25201 The value of a numeric attribute can be specified either with a 25202 `const_int', or as an integer represented as a string in 25203 `const_string', `eq_attr' (see below), `attr', `symbol_ref', 25204 simple arithmetic expressions, and `set_attr' overrides on 25205 specific instructions (*note Tagging Insns::). 25206 25207 `(const_string VALUE)' 25208 The string VALUE specifies a constant attribute value. If VALUE 25209 is specified as `"*"', it means that the default value of the 25210 attribute is to be used for the insn containing this expression. 25211 `"*"' obviously cannot be used in the DEFAULT expression of a 25212 `define_attr'. 25213 25214 If the attribute whose value is being specified is numeric, VALUE 25215 must be a string containing a non-negative integer (normally 25216 `const_int' would be used in this case). Otherwise, it must 25217 contain one of the valid values for the attribute. 25218 25219 `(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 25220 TEST specifies an attribute test, whose format is defined below. 25221 The value of this expression is TRUE-VALUE if TEST is true, 25222 otherwise it is FALSE-VALUE. 25223 25224 `(cond [TEST1 VALUE1 ...] DEFAULT)' 25225 The first operand of this expression is a vector containing an even 25226 number of expressions and consisting of pairs of TEST and VALUE 25227 expressions. The value of the `cond' expression is that of the 25228 VALUE corresponding to the first true TEST expression. If none of 25229 the TEST expressions are true, the value of the `cond' expression 25230 is that of the DEFAULT expression. 25231 25232 TEST expressions can have one of the following forms: 25233 25234 `(const_int I)' 25235 This test is true if I is nonzero and false otherwise. 25236 25237 `(not TEST)' 25238 `(ior TEST1 TEST2)' 25239 `(and TEST1 TEST2)' 25240 These tests are true if the indicated logical function is true. 25241 25242 `(match_operand:M N PRED CONSTRAINTS)' 25243 This test is true if operand N of the insn whose attribute value 25244 is being determined has mode M (this part of the test is ignored 25245 if M is `VOIDmode') and the function specified by the string PRED 25246 returns a nonzero value when passed operand N and mode M (this 25247 part of the test is ignored if PRED is the null string). 25248 25249 The CONSTRAINTS operand is ignored and should be the null string. 25250 25251 `(match_test C-EXPR)' 25252 The test is true if C expression C-EXPR is true. In non-constant 25253 attributes, C-EXPR has access to the following variables: 25254 25255 INSN 25256 The rtl instruction under test. 25257 25258 WHICH_ALTERNATIVE 25259 The `define_insn' alternative that INSN matches. *Note 25260 Output Statement::. 25261 25262 OPERANDS 25263 An array of INSN's rtl operands. 25264 25265 C-EXPR behaves like the condition in a C `if' statement, so there 25266 is no need to explicitly convert the expression into a boolean 0 25267 or 1 value. For example, the following two tests are equivalent: 25268 25269 (match_test "x & 2") 25270 (match_test "(x & 2) != 0") 25271 25272 `(le ARITH1 ARITH2)' 25273 `(leu ARITH1 ARITH2)' 25274 `(lt ARITH1 ARITH2)' 25275 `(ltu ARITH1 ARITH2)' 25276 `(gt ARITH1 ARITH2)' 25277 `(gtu ARITH1 ARITH2)' 25278 `(ge ARITH1 ARITH2)' 25279 `(geu ARITH1 ARITH2)' 25280 `(ne ARITH1 ARITH2)' 25281 `(eq ARITH1 ARITH2)' 25282 These tests are true if the indicated comparison of the two 25283 arithmetic expressions is true. Arithmetic expressions are formed 25284 with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and', 25285 `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt' 25286 expressions. 25287 25288 `const_int' and `symbol_ref' are always valid terms (*note Insn 25289 Lengths::,for additional forms). `symbol_ref' is a string 25290 denoting a C expression that yields an `int' when evaluated by the 25291 `get_attr_...' routine. It should normally be a global variable. 25292 25293 `(eq_attr NAME VALUE)' 25294 NAME is a string specifying the name of an attribute. 25295 25296 VALUE is a string that is either a valid value for attribute NAME, 25297 a comma-separated list of values, or `!' followed by a value or 25298 list. If VALUE does not begin with a `!', this test is true if 25299 the value of the NAME attribute of the current insn is in the list 25300 specified by VALUE. If VALUE begins with a `!', this test is true 25301 if the attribute's value is _not_ in the specified list. 25302 25303 For example, 25304 25305 (eq_attr "type" "load,store") 25306 25307 is equivalent to 25308 25309 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 25310 25311 If NAME specifies an attribute of `alternative', it refers to the 25312 value of the compiler variable `which_alternative' (*note Output 25313 Statement::) and the values must be small integers. For example, 25314 25315 (eq_attr "alternative" "2,3") 25316 25317 is equivalent to 25318 25319 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 25320 (eq (symbol_ref "which_alternative") (const_int 3))) 25321 25322 Note that, for most attributes, an `eq_attr' test is simplified in 25323 cases where the value of the attribute being tested is known for 25324 all insns matching a particular pattern. This is by far the most 25325 common case. 25326 25327 `(attr_flag NAME)' 25328 The value of an `attr_flag' expression is true if the flag 25329 specified by NAME is true for the `insn' currently being scheduled. 25330 25331 NAME is a string specifying one of a fixed set of flags to test. 25332 Test the flags `forward' and `backward' to determine the direction 25333 of a conditional branch. 25334 25335 This example describes a conditional branch delay slot which can 25336 be nullified for forward branches that are taken (annul-true) or 25337 for backward branches which are not taken (annul-false). 25338 25339 (define_delay (eq_attr "type" "cbranch") 25340 [(eq_attr "in_branch_delay" "true") 25341 (and (eq_attr "in_branch_delay" "true") 25342 (attr_flag "forward")) 25343 (and (eq_attr "in_branch_delay" "true") 25344 (attr_flag "backward"))]) 25345 25346 The `forward' and `backward' flags are false if the current `insn' 25347 being scheduled is not a conditional branch. 25348 25349 `attr_flag' is only used during delay slot scheduling and has no 25350 meaning to other passes of the compiler. 25351 25352 `(attr NAME)' 25353 The value of another attribute is returned. This is most useful 25354 for numeric attributes, as `eq_attr' and `attr_flag' produce more 25355 efficient code for non-numeric attributes. 25356 25357 25358 File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 25359 25360 16.19.3 Assigning Attribute Values to Insns 25361 ------------------------------------------- 25362 25363 The value assigned to an attribute of an insn is primarily determined by 25364 which pattern is matched by that insn (or which `define_peephole' 25365 generated it). Every `define_insn' and `define_peephole' can have an 25366 optional last argument to specify the values of attributes for matching 25367 insns. The value of any attribute not specified in a particular insn 25368 is set to the default value for that attribute, as specified in its 25369 `define_attr'. Extensive use of default values for attributes permits 25370 the specification of the values for only one or two attributes in the 25371 definition of most insn patterns, as seen in the example in the next 25372 section. 25373 25374 The optional last argument of `define_insn' and `define_peephole' is a 25375 vector of expressions, each of which defines the value for a single 25376 attribute. The most general way of assigning an attribute's value is 25377 to use a `set' expression whose first operand is an `attr' expression 25378 giving the name of the attribute being set. The second operand of the 25379 `set' is an attribute expression (*note Expressions::) giving the value 25380 of the attribute. 25381 25382 When the attribute value depends on the `alternative' attribute (i.e., 25383 which is the applicable alternative in the constraint of the insn), the 25384 `set_attr_alternative' expression can be used. It allows the 25385 specification of a vector of attribute expressions, one for each 25386 alternative. 25387 25388 When the generality of arbitrary attribute expressions is not required, 25389 the simpler `set_attr' expression can be used, which allows specifying 25390 a string giving either a single attribute value or a list of attribute 25391 values, one for each alternative. 25392 25393 The form of each of the above specifications is shown below. In each 25394 case, NAME is a string specifying the attribute to be set. 25395 25396 `(set_attr NAME VALUE-STRING)' 25397 VALUE-STRING is either a string giving the desired attribute value, 25398 or a string containing a comma-separated list giving the values for 25399 succeeding alternatives. The number of elements must match the 25400 number of alternatives in the constraint of the insn pattern. 25401 25402 Note that it may be useful to specify `*' for some alternative, in 25403 which case the attribute will assume its default value for insns 25404 matching that alternative. 25405 25406 `(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 25407 Depending on the alternative of the insn, the value will be one of 25408 the specified values. This is a shorthand for using a `cond' with 25409 tests on the `alternative' attribute. 25410 25411 `(set (attr NAME) VALUE)' 25412 The first operand of this `set' must be the special RTL expression 25413 `attr', whose sole operand is a string giving the name of the 25414 attribute being set. VALUE is the value of the attribute. 25415 25416 The following shows three different ways of representing the same 25417 attribute value specification: 25418 25419 (set_attr "type" "load,store,arith") 25420 25421 (set_attr_alternative "type" 25422 [(const_string "load") (const_string "store") 25423 (const_string "arith")]) 25424 25425 (set (attr "type") 25426 (cond [(eq_attr "alternative" "1") (const_string "load") 25427 (eq_attr "alternative" "2") (const_string "store")] 25428 (const_string "arith"))) 25429 25430 The `define_asm_attributes' expression provides a mechanism to specify 25431 the attributes assigned to insns produced from an `asm' statement. It 25432 has the form: 25433 25434 (define_asm_attributes [ATTR-SETS]) 25435 25436 where ATTR-SETS is specified the same as for both the `define_insn' and 25437 the `define_peephole' expressions. 25438 25439 These values will typically be the "worst case" attribute values. For 25440 example, they might indicate that the condition code will be clobbered. 25441 25442 A specification for a `length' attribute is handled specially. The 25443 way to compute the length of an `asm' insn is to multiply the length 25444 specified in the expression `define_asm_attributes' by the number of 25445 machine instructions specified in the `asm' statement, determined by 25446 counting the number of semicolons and newlines in the string. 25447 Therefore, the value of the `length' attribute specified in a 25448 `define_asm_attributes' should be the maximum possible length of a 25449 single machine instruction. 25450 25451 25452 File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 25453 25454 16.19.4 Example of Attribute Specifications 25455 ------------------------------------------- 25456 25457 The judicious use of defaulting is important in the efficient use of 25458 insn attributes. Typically, insns are divided into "types" and an 25459 attribute, customarily called `type', is used to represent this value. 25460 This attribute is normally used only to define the default value for 25461 other attributes. An example will clarify this usage. 25462 25463 Assume we have a RISC machine with a condition code and in which only 25464 full-word operations are performed in registers. Let us assume that we 25465 can divide all insns into loads, stores, (integer) arithmetic 25466 operations, floating point operations, and branches. 25467 25468 Here we will concern ourselves with determining the effect of an insn 25469 on the condition code and will limit ourselves to the following possible 25470 effects: The condition code can be set unpredictably (clobbered), not 25471 be changed, be set to agree with the results of the operation, or only 25472 changed if the item previously set into the condition code has been 25473 modified. 25474 25475 Here is part of a sample `md' file for such a machine: 25476 25477 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 25478 25479 (define_attr "cc" "clobber,unchanged,set,change0" 25480 (cond [(eq_attr "type" "load") 25481 (const_string "change0") 25482 (eq_attr "type" "store,branch") 25483 (const_string "unchanged") 25484 (eq_attr "type" "arith") 25485 (if_then_else (match_operand:SI 0 "" "") 25486 (const_string "set") 25487 (const_string "clobber"))] 25488 (const_string "clobber"))) 25489 25490 (define_insn "" 25491 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 25492 (match_operand:SI 1 "general_operand" "r,m,r"))] 25493 "" 25494 "@ 25495 move %0,%1 25496 load %0,%1 25497 store %0,%1" 25498 [(set_attr "type" "arith,load,store")]) 25499 25500 Note that we assume in the above example that arithmetic operations 25501 performed on quantities smaller than a machine word clobber the 25502 condition code since they will set the condition code to a value 25503 corresponding to the full-word result. 25504 25505 25506 File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 25507 25508 16.19.5 Computing the Length of an Insn 25509 --------------------------------------- 25510 25511 For many machines, multiple types of branch instructions are provided, 25512 each for different length branch displacements. In most cases, the 25513 assembler will choose the correct instruction to use. However, when 25514 the assembler cannot do so, GCC can when a special attribute, the 25515 `length' attribute, is defined. This attribute must be defined to have 25516 numeric values by specifying a null string in its `define_attr'. 25517 25518 In the case of the `length' attribute, two additional forms of 25519 arithmetic terms are allowed in test expressions: 25520 25521 `(match_dup N)' 25522 This refers to the address of operand N of the current insn, which 25523 must be a `label_ref'. 25524 25525 `(pc)' 25526 This refers to the address of the _current_ insn. It might have 25527 been more consistent with other usage to make this the address of 25528 the _next_ insn but this would be confusing because the length of 25529 the current insn is to be computed. 25530 25531 For normal insns, the length will be determined by value of the 25532 `length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn 25533 patterns, the length is computed as the number of vectors multiplied by 25534 the size of each vector. 25535 25536 Lengths are measured in addressable storage units (bytes). 25537 25538 The following macros can be used to refine the length computation: 25539 25540 `ADJUST_INSN_LENGTH (INSN, LENGTH)' 25541 If defined, modifies the length assigned to instruction INSN as a 25542 function of the context in which it is used. LENGTH is an lvalue 25543 that contains the initially computed length of the insn and should 25544 be updated with the correct length of the insn. 25545 25546 This macro will normally not be required. A case in which it is 25547 required is the ROMP. On this machine, the size of an `addr_vec' 25548 insn must be increased by two to compensate for the fact that 25549 alignment may be required. 25550 25551 The routine that returns `get_attr_length' (the value of the `length' 25552 attribute) can be used by the output routine to determine the form of 25553 the branch instruction to be written, as the example below illustrates. 25554 25555 As an example of the specification of variable-length branches, 25556 consider the IBM 360. If we adopt the convention that a register will 25557 be set to the starting address of a function, we can jump to labels 25558 within 4k of the start using a four-byte instruction. Otherwise, we 25559 need a six-byte sequence to load the address from memory and then 25560 branch to it. 25561 25562 On such a machine, a pattern for a branch instruction might be 25563 specified as follows: 25564 25565 (define_insn "jump" 25566 [(set (pc) 25567 (label_ref (match_operand 0 "" "")))] 25568 "" 25569 { 25570 return (get_attr_length (insn) == 4 25571 ? "b %l0" : "l r15,=a(%l0); br r15"); 25572 } 25573 [(set (attr "length") 25574 (if_then_else (lt (match_dup 0) (const_int 4096)) 25575 (const_int 4) 25576 (const_int 6)))]) 25577 25578 25579 File: gccint.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes 25580 25581 16.19.6 Constant Attributes 25582 --------------------------- 25583 25584 A special form of `define_attr', where the expression for the default 25585 value is a `const' expression, indicates an attribute that is constant 25586 for a given run of the compiler. Constant attributes may be used to 25587 specify which variety of processor is used. For example, 25588 25589 (define_attr "cpu" "m88100,m88110,m88000" 25590 (const 25591 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 25592 (symbol_ref "TARGET_88110") (const_string "m88110")] 25593 (const_string "m88000")))) 25594 25595 (define_attr "memory" "fast,slow" 25596 (const 25597 (if_then_else (symbol_ref "TARGET_FAST_MEM") 25598 (const_string "fast") 25599 (const_string "slow")))) 25600 25601 The routine generated for constant attributes has no parameters as it 25602 does not depend on any particular insn. RTL expressions used to define 25603 the value of a constant attribute may use the `symbol_ref' form, but 25604 may not use either the `match_operand' form or `eq_attr' forms 25605 involving insn attributes. 25606 25607 25608 File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Constant Attributes, Up: Insn Attributes 25609 25610 16.19.7 Delay Slot Scheduling 25611 ----------------------------- 25612 25613 The insn attribute mechanism can be used to specify the requirements for 25614 delay slots, if any, on a target machine. An instruction is said to 25615 require a "delay slot" if some instructions that are physically after 25616 the instruction are executed as if they were located before it. 25617 Classic examples are branch and call instructions, which often execute 25618 the following instruction before the branch or call is performed. 25619 25620 On some machines, conditional branch instructions can optionally 25621 "annul" instructions in the delay slot. This means that the 25622 instruction will not be executed for certain branch outcomes. Both 25623 instructions that annul if the branch is true and instructions that 25624 annul if the branch is false are supported. 25625 25626 Delay slot scheduling differs from instruction scheduling in that 25627 determining whether an instruction needs a delay slot is dependent only 25628 on the type of instruction being generated, not on data flow between the 25629 instructions. See the next section for a discussion of data-dependent 25630 instruction scheduling. 25631 25632 The requirement of an insn needing one or more delay slots is indicated 25633 via the `define_delay' expression. It has the following form: 25634 25635 (define_delay TEST 25636 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 25637 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 25638 ...]) 25639 25640 TEST is an attribute test that indicates whether this `define_delay' 25641 applies to a particular insn. If so, the number of required delay 25642 slots is determined by the length of the vector specified as the second 25643 argument. An insn placed in delay slot N must satisfy attribute test 25644 DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 25645 may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 25646 specifies which insns in the delay slot may be annulled if the branch 25647 is false. If annulling is not supported for that delay slot, `(nil)' 25648 should be coded. 25649 25650 For example, in the common case where branch and call insns require a 25651 single delay slot, which may contain any insn other than a branch or 25652 call, the following would be placed in the `md' file: 25653 25654 (define_delay (eq_attr "type" "branch,call") 25655 [(eq_attr "type" "!branch,call") (nil) (nil)]) 25656 25657 Multiple `define_delay' expressions may be specified. In this case, 25658 each such expression specifies different delay slot requirements and 25659 there must be no insn for which tests in two `define_delay' expressions 25660 are both true. 25661 25662 For example, if we have a machine that requires one delay slot for 25663 branches but two for calls, no delay slot can contain a branch or call 25664 insn, and any valid insn in the delay slot for the branch can be 25665 annulled if the branch is true, we might represent this as follows: 25666 25667 (define_delay (eq_attr "type" "branch") 25668 [(eq_attr "type" "!branch,call") 25669 (eq_attr "type" "!branch,call") 25670 (nil)]) 25671 25672 (define_delay (eq_attr "type" "call") 25673 [(eq_attr "type" "!branch,call") (nil) (nil) 25674 (eq_attr "type" "!branch,call") (nil) (nil)]) 25675 25676 25677 File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 25678 25679 16.19.8 Specifying processor pipeline description 25680 ------------------------------------------------- 25681 25682 To achieve better performance, most modern processors (super-pipelined, 25683 superscalar RISC, and VLIW processors) have many "functional units" on 25684 which several instructions can be executed simultaneously. An 25685 instruction starts execution if its issue conditions are satisfied. If 25686 not, the instruction is stalled until its conditions are satisfied. 25687 Such "interlock (pipeline) delay" causes interruption of the fetching 25688 of successor instructions (or demands nop instructions, e.g. for some 25689 MIPS processors). 25690 25691 There are two major kinds of interlock delays in modern processors. 25692 The first one is a data dependence delay determining "instruction 25693 latency time". The instruction execution is not started until all 25694 source data have been evaluated by prior instructions (there are more 25695 complex cases when the instruction execution starts even when the data 25696 are not available but will be ready in given time after the instruction 25697 execution start). Taking the data dependence delays into account is 25698 simple. The data dependence (true, output, and anti-dependence) delay 25699 between two instructions is given by a constant. In most cases this 25700 approach is adequate. The second kind of interlock delays is a 25701 reservation delay. The reservation delay means that two instructions 25702 under execution will be in need of shared processors resources, i.e. 25703 buses, internal registers, and/or functional units, which are reserved 25704 for some time. Taking this kind of delay into account is complex 25705 especially for modern RISC processors. 25706 25707 The task of exploiting more processor parallelism is solved by an 25708 instruction scheduler. For a better solution to this problem, the 25709 instruction scheduler has to have an adequate description of the 25710 processor parallelism (or "pipeline description"). GCC machine 25711 descriptions describe processor parallelism and functional unit 25712 reservations for groups of instructions with the aid of "regular 25713 expressions". 25714 25715 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 25716 figure out the possibility of the instruction issue by the processor on 25717 a given simulated processor cycle. The pipeline hazard recognizer is 25718 automatically generated from the processor pipeline description. The 25719 pipeline hazard recognizer generated from the machine description is 25720 based on a deterministic finite state automaton (DFA): the instruction 25721 issue is possible if there is a transition from one automaton state to 25722 another one. This algorithm is very fast, and furthermore, its speed 25723 is not dependent on processor complexity(1). 25724 25725 The rest of this section describes the directives that constitute an 25726 automaton-based processor pipeline description. The order of these 25727 constructions within the machine description file is not important. 25728 25729 The following optional construction describes names of automata 25730 generated and used for the pipeline hazards recognition. Sometimes the 25731 generated finite state automaton used by the pipeline hazard recognizer 25732 is large. If we use more than one automaton and bind functional units 25733 to the automata, the total size of the automata is usually less than 25734 the size of the single automaton. If there is no one such 25735 construction, only one finite state automaton is generated. 25736 25737 (define_automaton AUTOMATA-NAMES) 25738 25739 AUTOMATA-NAMES is a string giving names of the automata. The names 25740 are separated by commas. All the automata should have unique names. 25741 The automaton name is used in the constructions `define_cpu_unit' and 25742 `define_query_cpu_unit'. 25743 25744 Each processor functional unit used in the description of instruction 25745 reservations should be described by the following construction. 25746 25747 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 25748 25749 UNIT-NAMES is a string giving the names of the functional units 25750 separated by commas. Don't use name `nothing', it is reserved for 25751 other goals. 25752 25753 AUTOMATON-NAME is a string giving the name of the automaton with which 25754 the unit is bound. The automaton should be described in construction 25755 `define_automaton'. You should give "automaton-name", if there is a 25756 defined automaton. 25757 25758 The assignment of units to automata are constrained by the uses of the 25759 units in insn reservations. The most important constraint is: if a 25760 unit reservation is present on a particular cycle of an alternative for 25761 an insn reservation, then some unit from the same automaton must be 25762 present on the same cycle for the other alternatives of the insn 25763 reservation. The rest of the constraints are mentioned in the 25764 description of the subsequent constructions. 25765 25766 The following construction describes CPU functional units analogously 25767 to `define_cpu_unit'. The reservation of such units can be queried for 25768 an automaton state. The instruction scheduler never queries 25769 reservation of functional units for given automaton state. So as a 25770 rule, you don't need this construction. This construction could be 25771 used for future code generation goals (e.g. to generate VLIW insn 25772 templates). 25773 25774 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 25775 25776 UNIT-NAMES is a string giving names of the functional units separated 25777 by commas. 25778 25779 AUTOMATON-NAME is a string giving the name of the automaton with which 25780 the unit is bound. 25781 25782 The following construction is the major one to describe pipeline 25783 characteristics of an instruction. 25784 25785 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 25786 CONDITION REGEXP) 25787 25788 DEFAULT_LATENCY is a number giving latency time of the instruction. 25789 There is an important difference between the old description and the 25790 automaton based pipeline description. The latency time is used for all 25791 dependencies when we use the old description. In the automaton based 25792 pipeline description, the given latency time is only used for true 25793 dependencies. The cost of anti-dependencies is always zero and the 25794 cost of output dependencies is the difference between latency times of 25795 the producing and consuming insns (if the difference is negative, the 25796 cost is considered to be zero). You can always change the default 25797 costs for any description by using the target hook 25798 `TARGET_SCHED_ADJUST_COST' (*note Scheduling::). 25799 25800 INSN-NAME is a string giving the internal name of the insn. The 25801 internal names are used in constructions `define_bypass' and in the 25802 automaton description file generated for debugging. The internal name 25803 has nothing in common with the names in `define_insn'. It is a good 25804 practice to use insn classes described in the processor manual. 25805 25806 CONDITION defines what RTL insns are described by this construction. 25807 You should remember that you will be in trouble if CONDITION for two or 25808 more different `define_insn_reservation' constructions is TRUE for an 25809 insn. In this case what reservation will be used for the insn is not 25810 defined. Such cases are not checked during generation of the pipeline 25811 hazards recognizer because in general recognizing that two conditions 25812 may have the same value is quite difficult (especially if the conditions 25813 contain `symbol_ref'). It is also not checked during the pipeline 25814 hazard recognizer work because it would slow down the recognizer 25815 considerably. 25816 25817 REGEXP is a string describing the reservation of the cpu's functional 25818 units by the instruction. The reservations are described by a regular 25819 expression according to the following syntax: 25820 25821 regexp = regexp "," oneof 25822 | oneof 25823 25824 oneof = oneof "|" allof 25825 | allof 25826 25827 allof = allof "+" repeat 25828 | repeat 25829 25830 repeat = element "*" number 25831 | element 25832 25833 element = cpu_function_unit_name 25834 | reservation_name 25835 | result_name 25836 | "nothing" 25837 | "(" regexp ")" 25838 25839 * `,' is used for describing the start of the next cycle in the 25840 reservation. 25841 25842 * `|' is used for describing a reservation described by the first 25843 regular expression *or* a reservation described by the second 25844 regular expression *or* etc. 25845 25846 * `+' is used for describing a reservation described by the first 25847 regular expression *and* a reservation described by the second 25848 regular expression *and* etc. 25849 25850 * `*' is used for convenience and simply means a sequence in which 25851 the regular expression are repeated NUMBER times with cycle 25852 advancing (see `,'). 25853 25854 * `cpu_function_unit_name' denotes reservation of the named 25855 functional unit. 25856 25857 * `reservation_name' -- see description of construction 25858 `define_reservation'. 25859 25860 * `nothing' denotes no unit reservations. 25861 25862 Sometimes unit reservations for different insns contain common parts. 25863 In such case, you can simplify the pipeline description by describing 25864 the common part by the following construction 25865 25866 (define_reservation RESERVATION-NAME REGEXP) 25867 25868 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 25869 names and reservation names are in the same name space. So the 25870 reservation names should be different from the functional unit names 25871 and can not be the reserved name `nothing'. 25872 25873 The following construction is used to describe exceptions in the 25874 latency time for given instruction pair. This is so called bypasses. 25875 25876 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 25877 [GUARD]) 25878 25879 NUMBER defines when the result generated by the instructions given in 25880 string OUT_INSN_NAMES will be ready for the instructions given in 25881 string IN_INSN_NAMES. Each of these strings is a comma-separated list 25882 of filename-style globs and they refer to the names of 25883 `define_insn_reservation's. For example: 25884 (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") 25885 defines a bypass between instructions that start with `cpu1_load_' or 25886 `cpu1_store_' and those that start with `cpu1_load_'. 25887 25888 GUARD is an optional string giving the name of a C function which 25889 defines an additional guard for the bypass. The function will get the 25890 two insns as parameters. If the function returns zero the bypass will 25891 be ignored for this case. The additional guard is necessary to 25892 recognize complicated bypasses, e.g. when the consumer is only an 25893 address of insn `store' (not a stored value). 25894 25895 If there are more one bypass with the same output and input insns, the 25896 chosen bypass is the first bypass with a guard in description whose 25897 guard function returns nonzero. If there is no such bypass, then 25898 bypass without the guard function is chosen. 25899 25900 The following five constructions are usually used to describe VLIW 25901 processors, or more precisely, to describe a placement of small 25902 instructions into VLIW instruction slots. They can be used for RISC 25903 processors, too. 25904 25905 (exclusion_set UNIT-NAMES UNIT-NAMES) 25906 (presence_set UNIT-NAMES PATTERNS) 25907 (final_presence_set UNIT-NAMES PATTERNS) 25908 (absence_set UNIT-NAMES PATTERNS) 25909 (final_absence_set UNIT-NAMES PATTERNS) 25910 25911 UNIT-NAMES is a string giving names of functional units separated by 25912 commas. 25913 25914 PATTERNS is a string giving patterns of functional units separated by 25915 comma. Currently pattern is one unit or units separated by 25916 white-spaces. 25917 25918 The first construction (`exclusion_set') means that each functional 25919 unit in the first string can not be reserved simultaneously with a unit 25920 whose name is in the second string and vice versa. For example, the 25921 construction is useful for describing processors (e.g. some SPARC 25922 processors) with a fully pipelined floating point functional unit which 25923 can execute simultaneously only single floating point insns or only 25924 double floating point insns. 25925 25926 The second construction (`presence_set') means that each functional 25927 unit in the first string can not be reserved unless at least one of 25928 pattern of units whose names are in the second string is reserved. 25929 This is an asymmetric relation. For example, it is useful for 25930 description that VLIW `slot1' is reserved after `slot0' reservation. 25931 We could describe it by the following construction 25932 25933 (presence_set "slot1" "slot0") 25934 25935 Or `slot1' is reserved only after `slot0' and unit `b0' reservation. 25936 In this case we could write 25937 25938 (presence_set "slot1" "slot0 b0") 25939 25940 The third construction (`final_presence_set') is analogous to 25941 `presence_set'. The difference between them is when checking is done. 25942 When an instruction is issued in given automaton state reflecting all 25943 current and planned unit reservations, the automaton state is changed. 25944 The first state is a source state, the second one is a result state. 25945 Checking for `presence_set' is done on the source state reservation, 25946 checking for `final_presence_set' is done on the result reservation. 25947 This construction is useful to describe a reservation which is actually 25948 two subsequent reservations. For example, if we use 25949 25950 (presence_set "slot1" "slot0") 25951 25952 the following insn will be never issued (because `slot1' requires 25953 `slot0' which is absent in the source state). 25954 25955 (define_reservation "insn_and_nop" "slot0 + slot1") 25956 25957 but it can be issued if we use analogous `final_presence_set'. 25958 25959 The forth construction (`absence_set') means that each functional unit 25960 in the first string can be reserved only if each pattern of units whose 25961 names are in the second string is not reserved. This is an asymmetric 25962 relation (actually `exclusion_set' is analogous to this one but it is 25963 symmetric). For example it might be useful in a VLIW description to 25964 say that `slot0' cannot be reserved after either `slot1' or `slot2' 25965 have been reserved. This can be described as: 25966 25967 (absence_set "slot0" "slot1, slot2") 25968 25969 Or `slot2' can not be reserved if `slot0' and unit `b0' are reserved 25970 or `slot1' and unit `b1' are reserved. In this case we could write 25971 25972 (absence_set "slot2" "slot0 b0, slot1 b1") 25973 25974 All functional units mentioned in a set should belong to the same 25975 automaton. 25976 25977 The last construction (`final_absence_set') is analogous to 25978 `absence_set' but checking is done on the result (state) reservation. 25979 See comments for `final_presence_set'. 25980 25981 You can control the generator of the pipeline hazard recognizer with 25982 the following construction. 25983 25984 (automata_option OPTIONS) 25985 25986 OPTIONS is a string giving options which affect the generated code. 25987 Currently there are the following options: 25988 25989 * "no-minimization" makes no minimization of the automaton. This is 25990 only worth to do when we are debugging the description and need to 25991 look more accurately at reservations of states. 25992 25993 * "time" means printing time statistics about the generation of 25994 automata. 25995 25996 * "stats" means printing statistics about the generated automata 25997 such as the number of DFA states, NDFA states and arcs. 25998 25999 * "v" means a generation of the file describing the result automata. 26000 The file has suffix `.dfa' and can be used for the description 26001 verification and debugging. 26002 26003 * "w" means a generation of warning instead of error for 26004 non-critical errors. 26005 26006 * "no-comb-vect" prevents the automaton generator from generating 26007 two data structures and comparing them for space efficiency. Using 26008 a comb vector to represent transitions may be better, but it can be 26009 very expensive to construct. This option is useful if the build 26010 process spends an unacceptably long time in genautomata. 26011 26012 * "ndfa" makes nondeterministic finite state automata. This affects 26013 the treatment of operator `|' in the regular expressions. The 26014 usual treatment of the operator is to try the first alternative 26015 and, if the reservation is not possible, the second alternative. 26016 The nondeterministic treatment means trying all alternatives, some 26017 of them may be rejected by reservations in the subsequent insns. 26018 26019 * "collapse-ndfa" modifies the behaviour of the generator when 26020 producing an automaton. An additional state transition to 26021 collapse a nondeterministic NDFA state to a deterministic DFA 26022 state is generated. It can be triggered by passing `const0_rtx' to 26023 state_transition. In such an automaton, cycle advance transitions 26024 are available only for these collapsed states. This option is 26025 useful for ports that want to use the `ndfa' option, but also want 26026 to use `define_query_cpu_unit' to assign units to insns issued in 26027 a cycle. 26028 26029 * "progress" means output of a progress bar showing how many states 26030 were generated so far for automaton being processed. This is 26031 useful during debugging a DFA description. If you see too many 26032 generated states, you could interrupt the generator of the pipeline 26033 hazard recognizer and try to figure out a reason for generation of 26034 the huge automaton. 26035 26036 As an example, consider a superscalar RISC machine which can issue 26037 three insns (two integer insns and one floating point insn) on the 26038 cycle but can finish only two insns. To describe this, we define the 26039 following functional units. 26040 26041 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 26042 (define_cpu_unit "port0, port1") 26043 26044 All simple integer insns can be executed in any integer pipeline and 26045 their result is ready in two cycles. The simple integer insns are 26046 issued into the first pipeline unless it is reserved, otherwise they 26047 are issued into the second pipeline. Integer division and 26048 multiplication insns can be executed only in the second integer 26049 pipeline and their results are ready correspondingly in 8 and 4 cycles. 26050 The integer division is not pipelined, i.e. the subsequent integer 26051 division insn can not be issued until the current division insn 26052 finished. Floating point insns are fully pipelined and their results 26053 are ready in 3 cycles. Where the result of a floating point insn is 26054 used by an integer insn, an additional delay of one cycle is incurred. 26055 To describe all of this we could specify 26056 26057 (define_cpu_unit "div") 26058 26059 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 26060 "(i0_pipeline | i1_pipeline), (port0 | port1)") 26061 26062 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 26063 "i1_pipeline, nothing*2, (port0 | port1)") 26064 26065 (define_insn_reservation "div" 8 (eq_attr "type" "div") 26066 "i1_pipeline, div*7, div + (port0 | port1)") 26067 26068 (define_insn_reservation "float" 3 (eq_attr "type" "float") 26069 "f_pipeline, nothing, (port0 | port1)) 26070 26071 (define_bypass 4 "float" "simple,mult,div") 26072 26073 To simplify the description we could describe the following reservation 26074 26075 (define_reservation "finish" "port0|port1") 26076 26077 and use it in all `define_insn_reservation' as in the following 26078 construction 26079 26080 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 26081 "(i0_pipeline | i1_pipeline), finish") 26082 26083 ---------- Footnotes ---------- 26084 26085 (1) However, the size of the automaton depends on processor 26086 complexity. To limit this effect, machine descriptions can split 26087 orthogonal parts of the machine description among several automata: but 26088 then, since each of these must be stepped independently, this does 26089 cause a small decrease in the algorithm's performance. 26090 26091 26092 File: gccint.info, Node: Conditional Execution, Next: Define Subst, Prev: Insn Attributes, Up: Machine Desc 26093 26094 16.20 Conditional Execution 26095 =========================== 26096 26097 A number of architectures provide for some form of conditional 26098 execution, or predication. The hallmark of this feature is the ability 26099 to nullify most of the instructions in the instruction set. When the 26100 instruction set is large and not entirely symmetric, it can be quite 26101 tedious to describe these forms directly in the `.md' file. An 26102 alternative is the `define_cond_exec' template. 26103 26104 (define_cond_exec 26105 [PREDICATE-PATTERN] 26106 "CONDITION" 26107 "OUTPUT-TEMPLATE") 26108 26109 PREDICATE-PATTERN is the condition that must be true for the insn to 26110 be executed at runtime and should match a relational operator. One can 26111 use `match_operator' to match several relational operators at once. 26112 Any `match_operand' operands must have no more than one alternative. 26113 26114 CONDITION is a C expression that must be true for the generated 26115 pattern to match. 26116 26117 OUTPUT-TEMPLATE is a string similar to the `define_insn' output 26118 template (*note Output Template::), except that the `*' and `@' special 26119 cases do not apply. This is only useful if the assembly text for the 26120 predicate is a simple prefix to the main insn. In order to handle the 26121 general case, there is a global variable `current_insn_predicate' that 26122 will contain the entire predicate if the current insn is predicated, 26123 and will otherwise be `NULL'. 26124 26125 When `define_cond_exec' is used, an implicit reference to the 26126 `predicable' instruction attribute is made. *Note Insn Attributes::. 26127 This attribute must be a boolean (i.e. have exactly two elements in its 26128 LIST-OF-VALUES), with the possible values being `no' and `yes'. The 26129 default and all uses in the insns must be a simple constant, not a 26130 complex expressions. It may, however, depend on the alternative, by 26131 using a comma-separated list of values. If that is the case, the port 26132 should also define an `enabled' attribute (*note Disable Insn 26133 Alternatives::), which should also allow only `no' and `yes' as its 26134 values. 26135 26136 For each `define_insn' for which the `predicable' attribute is true, a 26137 new `define_insn' pattern will be generated that matches a predicated 26138 version of the instruction. For example, 26139 26140 (define_insn "addsi" 26141 [(set (match_operand:SI 0 "register_operand" "r") 26142 (plus:SI (match_operand:SI 1 "register_operand" "r") 26143 (match_operand:SI 2 "register_operand" "r")))] 26144 "TEST1" 26145 "add %2,%1,%0") 26146 26147 (define_cond_exec 26148 [(ne (match_operand:CC 0 "register_operand" "c") 26149 (const_int 0))] 26150 "TEST2" 26151 "(%0)") 26152 26153 generates a new pattern 26154 26155 (define_insn "" 26156 [(cond_exec 26157 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 26158 (set (match_operand:SI 0 "register_operand" "r") 26159 (plus:SI (match_operand:SI 1 "register_operand" "r") 26160 (match_operand:SI 2 "register_operand" "r"))))] 26161 "(TEST2) && (TEST1)" 26162 "(%3) add %2,%1,%0") 26163 26164 26165 File: gccint.info, Node: Define Subst, Next: Constant Definitions, Prev: Conditional Execution, Up: Machine Desc 26166 26167 16.21 RTL Templates Transformations 26168 =================================== 26169 26170 For some hardware architectures there are common cases when the RTL 26171 templates for the instructions can be derived from the other RTL 26172 templates using simple transformations. E.g., `i386.md' contains an 26173 RTL template for the ordinary `sub' instruction-- `*subsi_1', and for 26174 the `sub' instruction with subsequent zero-extension--`*subsi_1_zext'. 26175 Such cases can be easily implemented by a single meta-template capable 26176 of generating a modified case based on the initial one: 26177 26178 (define_subst "NAME" 26179 [INPUT-TEMPLATE] 26180 "CONDITION" 26181 [OUTPUT-TEMPLATE]) 26182 INPUT-TEMPLATE is a pattern describing the source RTL template, which 26183 will be transformed. 26184 26185 CONDITION is a C expression that is conjunct with the condition from 26186 the input-template to generate a condition to be used in the 26187 output-template. 26188 26189 OUTPUT-TEMPLATE is a pattern that will be used in the resulting 26190 template. 26191 26192 `define_subst' mechanism is tightly coupled with the notion of the 26193 subst attribute (*note Subst Iterators::). The use of `define_subst' 26194 is triggered by a reference to a subst attribute in the transforming 26195 RTL template. This reference initiates duplication of the source RTL 26196 template and substitution of the attributes with their values. The 26197 source RTL template is left unchanged, while the copy is transformed by 26198 `define_subst'. This transformation can fail in the case when the 26199 source RTL template is not matched against the input-template of the 26200 `define_subst'. In such case the copy is deleted. 26201 26202 `define_subst' can be used only in `define_insn' and `define_expand', 26203 it cannot be used in other expressions (e.g. in 26204 `define_insn_and_split'). 26205 26206 * Menu: 26207 26208 * Define Subst Example:: Example of `define_subst' work. 26209 * Define Subst Pattern Matching:: Process of template comparison. 26210 * Define Subst Output Template:: Generation of output template. 26211 26212 26213 File: gccint.info, Node: Define Subst Example, Next: Define Subst Pattern Matching, Up: Define Subst 26214 26215 16.21.1 `define_subst' Example 26216 ------------------------------ 26217 26218 To illustrate how `define_subst' works, let us examine a simple 26219 template transformation. 26220 26221 Suppose there are two kinds of instructions: one that touches flags and 26222 the other that does not. The instructions of the second type could be 26223 generated with the following `define_subst': 26224 26225 (define_subst "add_clobber_subst" 26226 [(set (match_operand:SI 0 "" "") 26227 (match_operand:SI 1 "" ""))] 26228 "" 26229 [(set (match_dup 0) 26230 (match_dup 1)) 26231 (clobber (reg:CC FLAGS_REG))] 26232 26233 This `define_subst' can be applied to any RTL pattern containing `set' 26234 of mode SI and generates a copy with clobber when it is applied. 26235 26236 Assume there is an RTL template for a `max' instruction to be used in 26237 `define_subst' mentioned above: 26238 26239 (define_insn "maxsi" 26240 [(set (match_operand:SI 0 "register_operand" "=r") 26241 (max:SI 26242 (match_operand:SI 1 "register_operand" "r") 26243 (match_operand:SI 2 "register_operand" "r")))] 26244 "" 26245 "max\t{%2, %1, %0|%0, %1, %2}" 26246 [...]) 26247 26248 To mark the RTL template for `define_subst' application, 26249 subst-attributes are used. They should be declared in advance: 26250 26251 (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber") 26252 26253 Here `add_clobber_name' is the attribute name, `add_clobber_subst' is 26254 the name of the corresponding `define_subst', the third argument 26255 (`_noclobber') is the attribute value that would be substituted into 26256 the unchanged version of the source RTL template, and the last argument 26257 (`_clobber') is the value that would be substituted into the second, 26258 transformed, version of the RTL template. 26259 26260 Once the subst-attribute has been defined, it should be used in RTL 26261 templates which need to be processed by the `define_subst'. So, the 26262 original RTL template should be changed: 26263 26264 (define_insn "maxsi<add_clobber_name>" 26265 [(set (match_operand:SI 0 "register_operand" "=r") 26266 (max:SI 26267 (match_operand:SI 1 "register_operand" "r") 26268 (match_operand:SI 2 "register_operand" "r")))] 26269 "" 26270 "max\t{%2, %1, %0|%0, %1, %2}" 26271 [...]) 26272 26273 The result of the `define_subst' usage would look like the following: 26274 26275 (define_insn "maxsi_noclobber" 26276 [(set (match_operand:SI 0 "register_operand" "=r") 26277 (max:SI 26278 (match_operand:SI 1 "register_operand" "r") 26279 (match_operand:SI 2 "register_operand" "r")))] 26280 "" 26281 "max\t{%2, %1, %0|%0, %1, %2}" 26282 [...]) 26283 (define_insn "maxsi_clobber" 26284 [(set (match_operand:SI 0 "register_operand" "=r") 26285 (max:SI 26286 (match_operand:SI 1 "register_operand" "r") 26287 (match_operand:SI 2 "register_operand" "r"))) 26288 (clobber (reg:CC FLAGS_REG))] 26289 "" 26290 "max\t{%2, %1, %0|%0, %1, %2}" 26291 [...]) 26292 26293 26294 File: gccint.info, Node: Define Subst Pattern Matching, Next: Define Subst Output Template, Prev: Define Subst Example, Up: Define Subst 26295 26296 16.21.2 Pattern Matching in `define_subst' 26297 ------------------------------------------ 26298 26299 All expressions, allowed in `define_insn' or `define_expand', are 26300 allowed in the input-template of `define_subst', except 26301 `match_par_dup', `match_scratch', `match_parallel'. The meanings of 26302 expressions in the input-template were changed: 26303 26304 `match_operand' matches any expression (possibly, a subtree in 26305 RTL-template), if modes of the `match_operand' and this expression are 26306 the same, or mode of the `match_operand' is `VOIDmode', or this 26307 expression is `match_dup', `match_op_dup'. If the expression is 26308 `match_operand' too, and predicate of `match_operand' from the input 26309 pattern is not empty, then the predicates are compared. That can be 26310 used for more accurate filtering of accepted RTL-templates. 26311 26312 `match_operator' matches common operators (like `plus', `minus'), 26313 `unspec', `unspec_volatile' operators and `match_operator's from the 26314 original pattern if the modes match and `match_operator' from the input 26315 pattern has the same number of operands as the operator from the 26316 original pattern. 26317 26318 26319 File: gccint.info, Node: Define Subst Output Template, Prev: Define Subst Pattern Matching, Up: Define Subst 26320 26321 16.21.3 Generation of output template in `define_subst' 26322 ------------------------------------------------------- 26323 26324 If all necessary checks for `define_subst' application pass, a new 26325 RTL-pattern, based on the output-template, is created to replace the old 26326 template. Like in input-patterns, meanings of some RTL expressions are 26327 changed when they are used in output-patterns of a `define_subst'. 26328 Thus, `match_dup' is used for copying the whole expression from the 26329 original pattern, which matched corresponding `match_operand' from the 26330 input pattern. 26331 26332 `match_dup N' is used in the output template to be replaced with the 26333 expression from the original pattern, which matched `match_operand N' 26334 from the input pattern. As a consequence, `match_dup' cannot be used 26335 to point to `match_operand's from the output pattern, it should always 26336 refer to a `match_operand' from the input pattern. 26337 26338 In the output template one can refer to the expressions from the 26339 original pattern and create new ones. For instance, some operands could 26340 be added by means of standard `match_operand'. 26341 26342 After replacing `match_dup' with some RTL-subtree from the original 26343 pattern, it could happen that several `match_operand's in the output 26344 pattern have the same indexes. It is unknown, how many and what 26345 indexes would be used in the expression which would replace 26346 `match_dup', so such conflicts in indexes are inevitable. To overcome 26347 this issue, `match_operands' and `match_operators', which were 26348 introduced into the output pattern, are renumerated when all 26349 `match_dup's are replaced. 26350 26351 Number of alternatives in `match_operand's introduced into the output 26352 template `M' could differ from the number of alternatives in the 26353 original pattern `N', so in the resultant pattern there would be `N*M' 26354 alternatives. Thus, constraints from the original pattern would be 26355 duplicated `N' times, constraints from the output pattern would be 26356 duplicated `M' times, producing all possible combinations. 26357 26358 26359 File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Define Subst, Up: Machine Desc 26360 26361 16.22 Constant Definitions 26362 ========================== 26363 26364 Using literal constants inside instruction patterns reduces legibility 26365 and can be a maintenance problem. 26366 26367 To overcome this problem, you may use the `define_constants' 26368 expression. It contains a vector of name-value pairs. From that point 26369 on, wherever any of the names appears in the MD file, it is as if the 26370 corresponding value had been written instead. You may use 26371 `define_constants' multiple times; each appearance adds more constants 26372 to the table. It is an error to redefine a constant with a different 26373 value. 26374 26375 To come back to the a29k load multiple example, instead of 26376 26377 (define_insn "" 26378 [(match_parallel 0 "load_multiple_operation" 26379 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 26380 (match_operand:SI 2 "memory_operand" "m")) 26381 (use (reg:SI 179)) 26382 (clobber (reg:SI 179))])] 26383 "" 26384 "loadm 0,0,%1,%2") 26385 26386 You could write: 26387 26388 (define_constants [ 26389 (R_BP 177) 26390 (R_FC 178) 26391 (R_CR 179) 26392 (R_Q 180) 26393 ]) 26394 26395 (define_insn "" 26396 [(match_parallel 0 "load_multiple_operation" 26397 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 26398 (match_operand:SI 2 "memory_operand" "m")) 26399 (use (reg:SI R_CR)) 26400 (clobber (reg:SI R_CR))])] 26401 "" 26402 "loadm 0,0,%1,%2") 26403 26404 The constants that are defined with a define_constant are also output 26405 in the insn-codes.h header file as #defines. 26406 26407 You can also use the machine description file to define enumerations. 26408 Like the constants defined by `define_constant', these enumerations are 26409 visible to both the machine description file and the main C code. 26410 26411 The syntax is as follows: 26412 26413 (define_c_enum "NAME" [ 26414 VALUE0 26415 VALUE1 26416 ... 26417 VALUEN 26418 ]) 26419 26420 This definition causes the equivalent of the following C code to appear 26421 in `insn-constants.h': 26422 26423 enum NAME { 26424 VALUE0 = 0, 26425 VALUE1 = 1, 26426 ... 26427 VALUEN = N 26428 }; 26429 #define NUM_CNAME_VALUES (N + 1) 26430 26431 where CNAME is the capitalized form of NAME. It also makes each 26432 VALUEI available in the machine description file, just as if it had 26433 been declared with: 26434 26435 (define_constants [(VALUEI I)]) 26436 26437 Each VALUEI is usually an upper-case identifier and usually begins 26438 with CNAME. 26439 26440 You can split the enumeration definition into as many statements as 26441 you like. The above example is directly equivalent to: 26442 26443 (define_c_enum "NAME" [VALUE0]) 26444 (define_c_enum "NAME" [VALUE1]) 26445 ... 26446 (define_c_enum "NAME" [VALUEN]) 26447 26448 Splitting the enumeration helps to improve the modularity of each 26449 individual `.md' file. For example, if a port defines its 26450 synchronization instructions in a separate `sync.md' file, it is 26451 convenient to define all synchronization-specific enumeration values in 26452 `sync.md' rather than in the main `.md' file. 26453 26454 Some enumeration names have special significance to GCC: 26455 26456 `unspecv' 26457 If an enumeration called `unspecv' is defined, GCC will use it 26458 when printing out `unspec_volatile' expressions. For example: 26459 26460 (define_c_enum "unspecv" [ 26461 UNSPECV_BLOCKAGE 26462 ]) 26463 26464 causes GCC to print `(unspec_volatile ... 0)' as: 26465 26466 (unspec_volatile ... UNSPECV_BLOCKAGE) 26467 26468 `unspec' 26469 If an enumeration called `unspec' is defined, GCC will use it when 26470 printing out `unspec' expressions. GCC will also use it when 26471 printing out `unspec_volatile' expressions unless an `unspecv' 26472 enumeration is also defined. You can therefore decide whether to 26473 keep separate enumerations for volatile and non-volatile 26474 expressions or whether to use the same enumeration for both. 26475 26476 Another way of defining an enumeration is to use `define_enum': 26477 26478 (define_enum "NAME" [ 26479 VALUE0 26480 VALUE1 26481 ... 26482 VALUEN 26483 ]) 26484 26485 This directive implies: 26486 26487 (define_c_enum "NAME" [ 26488 CNAME_CVALUE0 26489 CNAME_CVALUE1 26490 ... 26491 CNAME_CVALUEN 26492 ]) 26493 26494 where CVALUEI is the capitalized form of VALUEI. However, unlike 26495 `define_c_enum', the enumerations defined by `define_enum' can be used 26496 in attribute specifications (*note define_enum_attr::). 26497 26498 26499 File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 26500 26501 16.23 Iterators 26502 =============== 26503 26504 Ports often need to define similar patterns for more than one machine 26505 mode or for more than one rtx code. GCC provides some simple iterator 26506 facilities to make this process easier. 26507 26508 * Menu: 26509 26510 * Mode Iterators:: Generating variations of patterns for different modes. 26511 * Code Iterators:: Doing the same for codes. 26512 * Int Iterators:: Doing the same for integers. 26513 * Subst Iterators:: Generating variations of patterns for define_subst. 26514 26515 26516 File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 26517 26518 16.23.1 Mode Iterators 26519 ---------------------- 26520 26521 Ports often need to define similar patterns for two or more different 26522 modes. For example: 26523 26524 * If a processor has hardware support for both single and double 26525 floating-point arithmetic, the `SFmode' patterns tend to be very 26526 similar to the `DFmode' ones. 26527 26528 * If a port uses `SImode' pointers in one configuration and `DImode' 26529 pointers in another, it will usually have very similar `SImode' 26530 and `DImode' patterns for manipulating pointers. 26531 26532 Mode iterators allow several patterns to be instantiated from one 26533 `.md' file template. They can be used with any type of rtx-based 26534 construct, such as a `define_insn', `define_split', or 26535 `define_peephole2'. 26536 26537 * Menu: 26538 26539 * Defining Mode Iterators:: Defining a new mode iterator. 26540 * Substitutions:: Combining mode iterators with substitutions 26541 * Examples:: Examples 26542 26543 26544 File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 26545 26546 16.23.1.1 Defining Mode Iterators 26547 ................................. 26548 26549 The syntax for defining a mode iterator is: 26550 26551 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 26552 26553 This allows subsequent `.md' file constructs to use the mode suffix 26554 `:NAME'. Every construct that does so will be expanded N times, once 26555 with every use of `:NAME' replaced by `:MODE1', once with every use 26556 replaced by `:MODE2', and so on. In the expansion for a particular 26557 MODEI, every C condition will also require that CONDI be true. 26558 26559 For example: 26560 26561 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 26562 26563 defines a new mode suffix `:P'. Every construct that uses `:P' will 26564 be expanded twice, once with every `:P' replaced by `:SI' and once with 26565 every `:P' replaced by `:DI'. The `:SI' version will only apply if 26566 `Pmode == SImode' and the `:DI' version will only apply if `Pmode == 26567 DImode'. 26568 26569 As with other `.md' conditions, an empty string is treated as "always 26570 true". `(MODE "")' can also be abbreviated to `MODE'. For example: 26571 26572 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 26573 26574 means that the `:DI' expansion only applies if `TARGET_64BIT' but that 26575 the `:SI' expansion has no such constraint. 26576 26577 Iterators are applied in the order they are defined. This can be 26578 significant if two iterators are used in a construct that requires 26579 substitutions. *Note Substitutions::. 26580 26581 26582 File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 26583 26584 16.23.1.2 Substitution in Mode Iterators 26585 ........................................ 26586 26587 If an `.md' file construct uses mode iterators, each version of the 26588 construct will often need slightly different strings or modes. For 26589 example: 26590 26591 * When a `define_expand' defines several `addM3' patterns (*note 26592 Standard Names::), each expander will need to use the appropriate 26593 mode name for M. 26594 26595 * When a `define_insn' defines several instruction patterns, each 26596 instruction will often use a different assembler mnemonic. 26597 26598 * When a `define_insn' requires operands with different modes, using 26599 an iterator for one of the operand modes usually requires a 26600 specific mode for the other operand(s). 26601 26602 GCC supports such variations through a system of "mode attributes". 26603 There are two standard attributes: `mode', which is the name of the 26604 mode in lower case, and `MODE', which is the same thing in upper case. 26605 You can define other attributes using: 26606 26607 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 26608 26609 where NAME is the name of the attribute and VALUEI is the value 26610 associated with MODEI. 26611 26612 When GCC replaces some :ITERATOR with :MODE, it will scan each string 26613 and mode in the pattern for sequences of the form `<ITERATOR:ATTR>', 26614 where ATTR is the name of a mode attribute. If the attribute is 26615 defined for MODE, the whole `<...>' sequence will be replaced by the 26616 appropriate attribute value. 26617 26618 For example, suppose an `.md' file has: 26619 26620 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 26621 (define_mode_attr load [(SI "lw") (DI "ld")]) 26622 26623 If one of the patterns that uses `:P' contains the string 26624 `"<P:load>\t%0,%1"', the `SI' version of that pattern will use 26625 `"lw\t%0,%1"' and the `DI' version will use `"ld\t%0,%1"'. 26626 26627 Here is an example of using an attribute for a mode: 26628 26629 (define_mode_iterator LONG [SI DI]) 26630 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 26631 (define_insn ... 26632 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 26633 26634 The `ITERATOR:' prefix may be omitted, in which case the substitution 26635 will be attempted for every iterator expansion. 26636 26637 26638 File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 26639 26640 16.23.1.3 Mode Iterator Examples 26641 ................................ 26642 26643 Here is an example from the MIPS port. It defines the following modes 26644 and attributes (among others): 26645 26646 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 26647 (define_mode_attr d [(SI "") (DI "d")]) 26648 26649 and uses the following template to define both `subsi3' and `subdi3': 26650 26651 (define_insn "sub<mode>3" 26652 [(set (match_operand:GPR 0 "register_operand" "=d") 26653 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 26654 (match_operand:GPR 2 "register_operand" "d")))] 26655 "" 26656 "<d>subu\t%0,%1,%2" 26657 [(set_attr "type" "arith") 26658 (set_attr "mode" "<MODE>")]) 26659 26660 This is exactly equivalent to: 26661 26662 (define_insn "subsi3" 26663 [(set (match_operand:SI 0 "register_operand" "=d") 26664 (minus:SI (match_operand:SI 1 "register_operand" "d") 26665 (match_operand:SI 2 "register_operand" "d")))] 26666 "" 26667 "subu\t%0,%1,%2" 26668 [(set_attr "type" "arith") 26669 (set_attr "mode" "SI")]) 26670 26671 (define_insn "subdi3" 26672 [(set (match_operand:DI 0 "register_operand" "=d") 26673 (minus:DI (match_operand:DI 1 "register_operand" "d") 26674 (match_operand:DI 2 "register_operand" "d")))] 26675 "" 26676 "dsubu\t%0,%1,%2" 26677 [(set_attr "type" "arith") 26678 (set_attr "mode" "DI")]) 26679 26680 26681 File: gccint.info, Node: Code Iterators, Next: Int Iterators, Prev: Mode Iterators, Up: Iterators 26682 26683 16.23.2 Code Iterators 26684 ---------------------- 26685 26686 Code iterators operate in a similar way to mode iterators. *Note Mode 26687 Iterators::. 26688 26689 The construct: 26690 26691 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 26692 26693 defines a pseudo rtx code NAME that can be instantiated as CODEI if 26694 condition CONDI is true. Each CODEI must have the same rtx format. 26695 *Note RTL Classes::. 26696 26697 As with mode iterators, each pattern that uses NAME will be expanded N 26698 times, once with all uses of NAME replaced by CODE1, once with all uses 26699 replaced by CODE2, and so on. *Note Defining Mode Iterators::. 26700 26701 It is possible to define attributes for codes as well as for modes. 26702 There are two standard code attributes: `code', the name of the code in 26703 lower case, and `CODE', the name of the code in upper case. Other 26704 attributes are defined using: 26705 26706 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 26707 26708 Here's an example of code iterators in action, taken from the MIPS 26709 port: 26710 26711 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 26712 eq ne gt ge lt le gtu geu ltu leu]) 26713 26714 (define_expand "b<code>" 26715 [(set (pc) 26716 (if_then_else (any_cond:CC (cc0) 26717 (const_int 0)) 26718 (label_ref (match_operand 0 "")) 26719 (pc)))] 26720 "" 26721 { 26722 gen_conditional_branch (operands, <CODE>); 26723 DONE; 26724 }) 26725 26726 This is equivalent to: 26727 26728 (define_expand "bunordered" 26729 [(set (pc) 26730 (if_then_else (unordered:CC (cc0) 26731 (const_int 0)) 26732 (label_ref (match_operand 0 "")) 26733 (pc)))] 26734 "" 26735 { 26736 gen_conditional_branch (operands, UNORDERED); 26737 DONE; 26738 }) 26739 26740 (define_expand "bordered" 26741 [(set (pc) 26742 (if_then_else (ordered:CC (cc0) 26743 (const_int 0)) 26744 (label_ref (match_operand 0 "")) 26745 (pc)))] 26746 "" 26747 { 26748 gen_conditional_branch (operands, ORDERED); 26749 DONE; 26750 }) 26751 26752 ... 26753 26754 26755 File: gccint.info, Node: Int Iterators, Next: Subst Iterators, Prev: Code Iterators, Up: Iterators 26756 26757 16.23.3 Int Iterators 26758 --------------------- 26759 26760 Int iterators operate in a similar way to code iterators. *Note Code 26761 Iterators::. 26762 26763 The construct: 26764 26765 (define_int_iterator NAME [(INT1 "COND1") ... (INTN "CONDN")]) 26766 26767 defines a pseudo integer constant NAME that can be instantiated as 26768 INTI if condition CONDI is true. Each INT must have the same rtx 26769 format. *Note RTL Classes::. Int iterators can appear in only those 26770 rtx fields that have 'i' as the specifier. This means that each INT has 26771 to be a constant defined using define_constant or define_c_enum. 26772 26773 As with mode and code iterators, each pattern that uses NAME will be 26774 expanded N times, once with all uses of NAME replaced by INT1, once 26775 with all uses replaced by INT2, and so on. *Note Defining Mode 26776 Iterators::. 26777 26778 It is possible to define attributes for ints as well as for codes and 26779 modes. Attributes are defined using: 26780 26781 (define_int_attr NAME [(INT1 "VALUE1") ... (INTN "VALUEN")]) 26782 26783 Here's an example of int iterators in action, taken from the ARM port: 26784 26785 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 26786 26787 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 26788 26789 (define_insn "neon_vq<absneg><mode>" 26790 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 26791 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 26792 (match_operand:SI 2 "immediate_operand" "i")] 26793 QABSNEG))] 26794 "TARGET_NEON" 26795 "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 26796 [(set_attr "neon_type" "neon_vqneg_vqabs")] 26797 ) 26798 26799 This is equivalent to: 26800 26801 (define_insn "neon_vqabs<mode>" 26802 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 26803 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 26804 (match_operand:SI 2 "immediate_operand" "i")] 26805 UNSPEC_VQABS))] 26806 "TARGET_NEON" 26807 "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 26808 [(set_attr "neon_type" "neon_vqneg_vqabs")] 26809 ) 26810 26811 (define_insn "neon_vqneg<mode>" 26812 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 26813 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 26814 (match_operand:SI 2 "immediate_operand" "i")] 26815 UNSPEC_VQNEG))] 26816 "TARGET_NEON" 26817 "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 26818 [(set_attr "neon_type" "neon_vqneg_vqabs")] 26819 ) 26820 26821 26822 File: gccint.info, Node: Subst Iterators, Prev: Int Iterators, Up: Iterators 26823 26824 16.23.4 Subst Iterators 26825 ----------------------- 26826 26827 Subst iterators are special type of iterators with the following 26828 restrictions: they could not be declared explicitly, they always have 26829 only two values, and they do not have explicit dedicated name. 26830 Subst-iterators are triggered only when corresponding subst-attribute is 26831 used in RTL-pattern. 26832 26833 Subst iterators transform templates in the following way: the templates 26834 are duplicated, the subst-attributes in these templates are replaced 26835 with the corresponding values, and a new attribute is implicitly added 26836 to the given `define_insn'/`define_expand'. The name of the added 26837 attribute matches the name of `define_subst'. Such attributes are 26838 declared implicitly, and it is not allowed to have a `define_attr' 26839 named as a `define_subst'. 26840 26841 Each subst iterator is linked to a `define_subst'. It is declared 26842 implicitly by the first appearance of the corresponding 26843 `define_subst_attr', and it is not allowed to define it explicitly. 26844 26845 Declarations of subst-attributes have the following syntax: 26846 26847 (define_subst_attr "NAME" 26848 "SUBST-NAME" 26849 "NO-SUBST-VALUE" 26850 "SUBST-APPLIED-VALUE") 26851 26852 NAME is a string with which the given subst-attribute could be 26853 referred to. 26854 26855 SUBST-NAME shows which `define_subst' should be applied to an 26856 RTL-template if the given subst-attribute is present in the 26857 RTL-template. 26858 26859 NO-SUBST-VALUE is a value with which subst-attribute would be replaced 26860 in the first copy of the original RTL-template. 26861 26862 SUBST-APPLIED-VALUE is a value with which subst-attribute would be 26863 replaced in the second copy of the original RTL-template. 26864 26865 26866 File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 26867 26868 17 Target Description Macros and Functions 26869 ****************************************** 26870 26871 In addition to the file `MACHINE.md', a machine description includes a 26872 C header file conventionally given the name `MACHINE.h' and a C source 26873 file named `MACHINE.c'. The header file defines numerous macros that 26874 convey the information about the target machine that does not fit into 26875 the scheme of the `.md' file. The file `tm.h' should be a link to 26876 `MACHINE.h'. The header file `config.h' includes `tm.h' and most 26877 compiler source files include `config.h'. The source file defines a 26878 variable `targetm', which is a structure containing pointers to 26879 functions and data relating to the target machine. `MACHINE.c' should 26880 also contain their definitions, if they are not defined elsewhere in 26881 GCC, and other functions called through the macros defined in the `.h' 26882 file. 26883 26884 * Menu: 26885 26886 * Target Structure:: The `targetm' variable. 26887 * Driver:: Controlling how the driver runs the compilation passes. 26888 * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. 26889 * Per-Function Data:: Defining data structures for per-function information. 26890 * Storage Layout:: Defining sizes and alignments of data. 26891 * Type Layout:: Defining sizes and properties of basic user data types. 26892 * Registers:: Naming and describing the hardware registers. 26893 * Register Classes:: Defining the classes of hardware registers. 26894 * Old Constraints:: The old way to define machine-specific constraints. 26895 * Stack and Calling:: Defining which way the stack grows and by how much. 26896 * Varargs:: Defining the varargs macros. 26897 * Trampolines:: Code set up at run time to enter a nested function. 26898 * Library Calls:: Controlling how library routines are implicitly called. 26899 * Addressing Modes:: Defining addressing modes valid for memory operands. 26900 * Anchored Addresses:: Defining how `-fsection-anchors' should work. 26901 * Condition Code:: Defining how insns update the condition code. 26902 * Costs:: Defining relative costs of different operations. 26903 * Scheduling:: Adjusting the behavior of the instruction scheduler. 26904 * Sections:: Dividing storage into text, data, and other sections. 26905 * PIC:: Macros for position independent code. 26906 * Assembler Format:: Defining how to write insns and pseudo-ops to output. 26907 * Debugging Info:: Defining the format of debugging output. 26908 * Floating Point:: Handling floating point for cross-compilers. 26909 * Mode Switching:: Insertion of mode-switching instructions. 26910 * Target Attributes:: Defining target-specific uses of `__attribute__'. 26911 * Emulated TLS:: Emulated TLS support. 26912 * MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 26913 * PCH Target:: Validity checking for precompiled headers. 26914 * C++ ABI:: Controlling C++ ABI changes. 26915 * Named Address Spaces:: Adding support for named address spaces 26916 * Misc:: Everything else. 26917 26918 26919 File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 26920 26921 17.1 The Global `targetm' Variable 26922 ================================== 26923 26924 -- Variable: struct gcc_target targetm 26925 The target `.c' file must define the global `targetm' variable 26926 which contains pointers to functions and data relating to the 26927 target machine. The variable is declared in `target.h'; 26928 `target-def.h' defines the macro `TARGET_INITIALIZER' which is 26929 used to initialize the variable, and macros for the default 26930 initializers for elements of the structure. The `.c' file should 26931 override those macros for which the default definition is 26932 inappropriate. For example: 26933 #include "target.h" 26934 #include "target-def.h" 26935 26936 /* Initialize the GCC target structure. */ 26937 26938 #undef TARGET_COMP_TYPE_ATTRIBUTES 26939 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 26940 26941 struct gcc_target targetm = TARGET_INITIALIZER; 26942 26943 Where a macro should be defined in the `.c' file in this manner to form 26944 part of the `targetm' structure, it is documented below as a "Target 26945 Hook" with a prototype. Many macros will change in future from being 26946 defined in the `.h' file to being part of the `targetm' structure. 26947 26948 Similarly, there is a `targetcm' variable for hooks that are specific 26949 to front ends for C-family languages, documented as "C Target Hook". 26950 This is declared in `c-family/c-target.h', the initializer 26951 `TARGETCM_INITIALIZER' in `c-family/c-target-def.h'. If targets 26952 initialize `targetcm' themselves, they should set 26953 `target_has_targetcm=yes' in `config.gcc'; otherwise a default 26954 definition is used. 26955 26956 Similarly, there is a `targetm_common' variable for hooks that are 26957 shared between the compiler driver and the compilers proper, documented 26958 as "Common Target Hook". This is declared in `common/common-target.h', 26959 the initializer `TARGETM_COMMON_INITIALIZER' in 26960 `common/common-target-def.h'. If targets initialize `targetm_common' 26961 themselves, they should set `target_has_targetm_common=yes' in 26962 `config.gcc'; otherwise a default definition is used. 26963 26964 26965 File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 26966 26967 17.2 Controlling the Compilation Driver, `gcc' 26968 ============================================== 26969 26970 You can control the compilation driver. 26971 26972 -- Macro: DRIVER_SELF_SPECS 26973 A list of specs for the driver itself. It should be a suitable 26974 initializer for an array of strings, with no surrounding braces. 26975 26976 The driver applies these specs to its own command line between 26977 loading default `specs' files (but not command-line specified 26978 ones) and choosing the multilib directory or running any 26979 subcommands. It applies them in the order given, so each spec can 26980 depend on the options added by earlier ones. It is also possible 26981 to remove options using `%<OPTION' in the usual way. 26982 26983 This macro can be useful when a port has several interdependent 26984 target options. It provides a way of standardizing the command 26985 line so that the other specs are easier to write. 26986 26987 Do not define this macro if it does not need to do anything. 26988 26989 -- Macro: OPTION_DEFAULT_SPECS 26990 A list of specs used to support configure-time default options 26991 (i.e. `--with' options) in the driver. It should be a suitable 26992 initializer for an array of structures, each containing two 26993 strings, without the outermost pair of surrounding braces. 26994 26995 The first item in the pair is the name of the default. This must 26996 match the code in `config.gcc' for the target. The second item is 26997 a spec to apply if a default with this name was specified. The 26998 string `%(VALUE)' in the spec will be replaced by the value of the 26999 default everywhere it occurs. 27000 27001 The driver will apply these specs to its own command line between 27002 loading default `specs' files and processing `DRIVER_SELF_SPECS', 27003 using the same mechanism as `DRIVER_SELF_SPECS'. 27004 27005 Do not define this macro if it does not need to do anything. 27006 27007 -- Macro: CPP_SPEC 27008 A C string constant that tells the GCC driver program options to 27009 pass to CPP. It can also specify how to translate options you 27010 give to GCC into options for GCC to pass to the CPP. 27011 27012 Do not define this macro if it does not need to do anything. 27013 27014 -- Macro: CPLUSPLUS_CPP_SPEC 27015 This macro is just like `CPP_SPEC', but is used for C++, rather 27016 than C. If you do not define this macro, then the value of 27017 `CPP_SPEC' (if any) will be used instead. 27018 27019 -- Macro: CC1_SPEC 27020 A C string constant that tells the GCC driver program options to 27021 pass to `cc1', `cc1plus', `f771', and the other language front 27022 ends. It can also specify how to translate options you give to 27023 GCC into options for GCC to pass to front ends. 27024 27025 Do not define this macro if it does not need to do anything. 27026 27027 -- Macro: CC1PLUS_SPEC 27028 A C string constant that tells the GCC driver program options to 27029 pass to `cc1plus'. It can also specify how to translate options 27030 you give to GCC into options for GCC to pass to the `cc1plus'. 27031 27032 Do not define this macro if it does not need to do anything. Note 27033 that everything defined in CC1_SPEC is already passed to `cc1plus' 27034 so there is no need to duplicate the contents of CC1_SPEC in 27035 CC1PLUS_SPEC. 27036 27037 -- Macro: ASM_SPEC 27038 A C string constant that tells the GCC driver program options to 27039 pass to the assembler. It can also specify how to translate 27040 options you give to GCC into options for GCC to pass to the 27041 assembler. See the file `sun3.h' for an example of this. 27042 27043 Do not define this macro if it does not need to do anything. 27044 27045 -- Macro: ASM_FINAL_SPEC 27046 A C string constant that tells the GCC driver program how to run 27047 any programs which cleanup after the normal assembler. Normally, 27048 this is not needed. See the file `mips.h' for an example of this. 27049 27050 Do not define this macro if it does not need to do anything. 27051 27052 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 27053 Define this macro, with no value, if the driver should give the 27054 assembler an argument consisting of a single dash, `-', to 27055 instruct it to read from its standard input (which will be a pipe 27056 connected to the output of the compiler proper). This argument is 27057 given after any `-o' option specifying the name of the output file. 27058 27059 If you do not define this macro, the assembler is assumed to read 27060 its standard input if given no non-option arguments. If your 27061 assembler cannot read standard input at all, use a `%{pipe:%e}' 27062 construct; see `mips.h' for instance. 27063 27064 -- Macro: LINK_SPEC 27065 A C string constant that tells the GCC driver program options to 27066 pass to the linker. It can also specify how to translate options 27067 you give to GCC into options for GCC to pass to the linker. 27068 27069 Do not define this macro if it does not need to do anything. 27070 27071 -- Macro: LIB_SPEC 27072 Another C string constant used much like `LINK_SPEC'. The 27073 difference between the two is that `LIB_SPEC' is used at the end 27074 of the command given to the linker. 27075 27076 If this macro is not defined, a default is provided that loads the 27077 standard C library from the usual place. See `gcc.c'. 27078 27079 -- Macro: LIBGCC_SPEC 27080 Another C string constant that tells the GCC driver program how 27081 and when to place a reference to `libgcc.a' into the linker 27082 command line. This constant is placed both before and after the 27083 value of `LIB_SPEC'. 27084 27085 If this macro is not defined, the GCC driver provides a default 27086 that passes the string `-lgcc' to the linker. 27087 27088 -- Macro: REAL_LIBGCC_SPEC 27089 By default, if `ENABLE_SHARED_LIBGCC' is defined, the 27090 `LIBGCC_SPEC' is not directly used by the driver program but is 27091 instead modified to refer to different versions of `libgcc.a' 27092 depending on the values of the command line flags `-static', 27093 `-shared', `-static-libgcc', and `-shared-libgcc'. On targets 27094 where these modifications are inappropriate, define 27095 `REAL_LIBGCC_SPEC' instead. `REAL_LIBGCC_SPEC' tells the driver 27096 how to place a reference to `libgcc' on the link command line, 27097 but, unlike `LIBGCC_SPEC', it is used unmodified. 27098 27099 -- Macro: USE_LD_AS_NEEDED 27100 A macro that controls the modifications to `LIBGCC_SPEC' mentioned 27101 in `REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 27102 uses -as-needed and the shared libgcc in place of the static 27103 exception handler library, when linking without any of `-static', 27104 `-static-libgcc', or `-shared-libgcc'. 27105 27106 -- Macro: LINK_EH_SPEC 27107 If defined, this C string constant is added to `LINK_SPEC'. When 27108 `USE_LD_AS_NEEDED' is zero or undefined, it also affects the 27109 modifications to `LIBGCC_SPEC' mentioned in `REAL_LIBGCC_SPEC'. 27110 27111 -- Macro: STARTFILE_SPEC 27112 Another C string constant used much like `LINK_SPEC'. The 27113 difference between the two is that `STARTFILE_SPEC' is used at the 27114 very beginning of the command given to the linker. 27115 27116 If this macro is not defined, a default is provided that loads the 27117 standard C startup file from the usual place. See `gcc.c'. 27118 27119 -- Macro: ENDFILE_SPEC 27120 Another C string constant used much like `LINK_SPEC'. The 27121 difference between the two is that `ENDFILE_SPEC' is used at the 27122 very end of the command given to the linker. 27123 27124 Do not define this macro if it does not need to do anything. 27125 27126 -- Macro: THREAD_MODEL_SPEC 27127 GCC `-v' will print the thread model GCC was configured to use. 27128 However, this doesn't work on platforms that are multilibbed on 27129 thread models, such as AIX 4.3. On such platforms, define 27130 `THREAD_MODEL_SPEC' such that it evaluates to a string without 27131 blanks that names one of the recognized thread models. `%*', the 27132 default value of this macro, will expand to the value of 27133 `thread_file' set in `config.gcc'. 27134 27135 -- Macro: SYSROOT_SUFFIX_SPEC 27136 Define this macro to add a suffix to the target sysroot when GCC is 27137 configured with a sysroot. This will cause GCC to search for 27138 usr/lib, et al, within sysroot+suffix. 27139 27140 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 27141 Define this macro to add a headers_suffix to the target sysroot 27142 when GCC is configured with a sysroot. This will cause GCC to 27143 pass the updated sysroot+headers_suffix to CPP, causing it to 27144 search for usr/include, et al, within sysroot+headers_suffix. 27145 27146 -- Macro: EXTRA_SPECS 27147 Define this macro to provide additional specifications to put in 27148 the `specs' file that can be used in various specifications like 27149 `CC1_SPEC'. 27150 27151 The definition should be an initializer for an array of structures, 27152 containing a string constant, that defines the specification name, 27153 and a string constant that provides the specification. 27154 27155 Do not define this macro if it does not need to do anything. 27156 27157 `EXTRA_SPECS' is useful when an architecture contains several 27158 related targets, which have various `..._SPECS' which are similar 27159 to each other, and the maintainer would like one central place to 27160 keep these definitions. 27161 27162 For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to 27163 define either `_CALL_SYSV' when the System V calling sequence is 27164 used or `_CALL_AIX' when the older AIX-based calling sequence is 27165 used. 27166 27167 The `config/rs6000/rs6000.h' target file defines: 27168 27169 #define EXTRA_SPECS \ 27170 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 27171 27172 #define CPP_SYS_DEFAULT "" 27173 27174 The `config/rs6000/sysv.h' target file defines: 27175 #undef CPP_SPEC 27176 #define CPP_SPEC \ 27177 "%{posix: -D_POSIX_SOURCE } \ 27178 %{mcall-sysv: -D_CALL_SYSV } \ 27179 %{!mcall-sysv: %(cpp_sysv_default) } \ 27180 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 27181 27182 #undef CPP_SYSV_DEFAULT 27183 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 27184 27185 while the `config/rs6000/eabiaix.h' target file defines 27186 `CPP_SYSV_DEFAULT' as: 27187 27188 #undef CPP_SYSV_DEFAULT 27189 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 27190 27191 -- Macro: LINK_LIBGCC_SPECIAL_1 27192 Define this macro if the driver program should find the library 27193 `libgcc.a'. If you do not define this macro, the driver program 27194 will pass the argument `-lgcc' to tell the linker to do the search. 27195 27196 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 27197 The sequence in which libgcc and libc are specified to the linker. 27198 By default this is `%G %L %G'. 27199 27200 -- Macro: LINK_COMMAND_SPEC 27201 A C string constant giving the complete command line need to 27202 execute the linker. When you do this, you will need to update 27203 your port each time a change is made to the link command line 27204 within `gcc.c'. Therefore, define this macro only if you need to 27205 completely redefine the command line for invoking the linker and 27206 there is no other way to accomplish the effect you need. 27207 Overriding this macro may be avoidable by overriding 27208 `LINK_GCC_C_SEQUENCE_SPEC' instead. 27209 27210 -- Common Target Hook: bool TARGET_ALWAYS_STRIP_DOTDOT 27211 True if `..' components should always be removed from directory 27212 names computed relative to GCC's internal directories, false 27213 (default) if such components should be preserved and directory 27214 names containing them passed to other tools such as the linker. 27215 27216 -- Macro: MULTILIB_DEFAULTS 27217 Define this macro as a C expression for the initializer of an 27218 array of string to tell the driver program which options are 27219 defaults for this target and thus do not need to be handled 27220 specially when using `MULTILIB_OPTIONS'. 27221 27222 Do not define this macro if `MULTILIB_OPTIONS' is not defined in 27223 the target makefile fragment or if none of the options listed in 27224 `MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 27225 27226 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 27227 Define this macro to tell `gcc' that it should only translate a 27228 `-B' prefix into a `-L' linker option if the prefix indicates an 27229 absolute file name. 27230 27231 -- Macro: MD_EXEC_PREFIX 27232 If defined, this macro is an additional prefix to try after 27233 `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the 27234 compiler is built as a cross compiler. If you define 27235 `MD_EXEC_PREFIX', then be sure to add it to the list of 27236 directories used to find the assembler in `configure.in'. 27237 27238 -- Macro: STANDARD_STARTFILE_PREFIX 27239 Define this macro as a C string constant if you wish to override 27240 the standard choice of `libdir' as the default prefix to try when 27241 searching for startup files such as `crt0.o'. 27242 `STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 27243 built as a cross compiler. 27244 27245 -- Macro: STANDARD_STARTFILE_PREFIX_1 27246 Define this macro as a C string constant if you wish to override 27247 the standard choice of `/lib' as a prefix to try after the default 27248 prefix when searching for startup files such as `crt0.o'. 27249 `STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 27250 built as a cross compiler. 27251 27252 -- Macro: STANDARD_STARTFILE_PREFIX_2 27253 Define this macro as a C string constant if you wish to override 27254 the standard choice of `/lib' as yet another prefix to try after 27255 the default prefix when searching for startup files such as 27256 `crt0.o'. `STANDARD_STARTFILE_PREFIX_2' is not searched when the 27257 compiler is built as a cross compiler. 27258 27259 -- Macro: MD_STARTFILE_PREFIX 27260 If defined, this macro supplies an additional prefix to try after 27261 the standard prefixes. `MD_EXEC_PREFIX' is not searched when the 27262 compiler is built as a cross compiler. 27263 27264 -- Macro: MD_STARTFILE_PREFIX_1 27265 If defined, this macro supplies yet another prefix to try after the 27266 standard prefixes. It is not searched when the compiler is built 27267 as a cross compiler. 27268 27269 -- Macro: INIT_ENVIRONMENT 27270 Define this macro as a C string constant if you wish to set 27271 environment variables for programs called by the driver, such as 27272 the assembler and loader. The driver passes the value of this 27273 macro to `putenv' to initialize the necessary environment 27274 variables. 27275 27276 -- Macro: LOCAL_INCLUDE_DIR 27277 Define this macro as a C string constant if you wish to override 27278 the standard choice of `/usr/local/include' as the default prefix 27279 to try when searching for local header files. `LOCAL_INCLUDE_DIR' 27280 comes before `NATIVE_SYSTEM_HEADER_DIR' (set in `config.gcc', 27281 normally `/usr/include') in the search order. 27282 27283 Cross compilers do not search either `/usr/local/include' or its 27284 replacement. 27285 27286 -- Macro: NATIVE_SYSTEM_HEADER_COMPONENT 27287 The "component" corresponding to `NATIVE_SYSTEM_HEADER_DIR'. See 27288 `INCLUDE_DEFAULTS', below, for the description of components. If 27289 you do not define this macro, no component is used. 27290 27291 -- Macro: INCLUDE_DEFAULTS 27292 Define this macro if you wish to override the entire default 27293 search path for include files. For a native compiler, the default 27294 search path usually consists of `GCC_INCLUDE_DIR', 27295 `LOCAL_INCLUDE_DIR', `GPLUSPLUS_INCLUDE_DIR', and 27296 `NATIVE_SYSTEM_HEADER_DIR'. In addition, `GPLUSPLUS_INCLUDE_DIR' 27297 and `GCC_INCLUDE_DIR' are defined automatically by `Makefile', and 27298 specify private search areas for GCC. The directory 27299 `GPLUSPLUS_INCLUDE_DIR' is used only for C++ programs. 27300 27301 The definition should be an initializer for an array of structures. 27302 Each array element should have four elements: the directory name (a 27303 string constant), the component name (also a string constant), a 27304 flag for C++-only directories, and a flag showing that the 27305 includes in the directory don't need to be wrapped in `extern `C'' 27306 when compiling C++. Mark the end of the array with a null element. 27307 27308 The component name denotes what GNU package the include file is 27309 part of, if any, in all uppercase letters. For example, it might 27310 be `GCC' or `BINUTILS'. If the package is part of a 27311 vendor-supplied operating system, code the component name as `0'. 27312 27313 For example, here is the definition used for VAX/VMS: 27314 27315 #define INCLUDE_DEFAULTS \ 27316 { \ 27317 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 27318 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 27319 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 27320 { ".", 0, 0, 0}, \ 27321 { 0, 0, 0, 0} \ 27322 } 27323 27324 Here is the order of prefixes tried for exec files: 27325 27326 1. Any prefixes specified by the user with `-B'. 27327 27328 2. The environment variable `GCC_EXEC_PREFIX' or, if `GCC_EXEC_PREFIX' 27329 is not set and the compiler has not been installed in the 27330 configure-time PREFIX, the location in which the compiler has 27331 actually been installed. 27332 27333 3. The directories specified by the environment variable 27334 `COMPILER_PATH'. 27335 27336 4. The macro `STANDARD_EXEC_PREFIX', if the compiler has been 27337 installed in the configured-time PREFIX. 27338 27339 5. The location `/usr/libexec/gcc/', but only if this is a native 27340 compiler. 27341 27342 6. The location `/usr/lib/gcc/', but only if this is a native 27343 compiler. 27344 27345 7. The macro `MD_EXEC_PREFIX', if defined, but only if this is a 27346 native compiler. 27347 27348 Here is the order of prefixes tried for startfiles: 27349 27350 1. Any prefixes specified by the user with `-B'. 27351 27352 2. The environment variable `GCC_EXEC_PREFIX' or its automatically 27353 determined value based on the installed toolchain location. 27354 27355 3. The directories specified by the environment variable 27356 `LIBRARY_PATH' (or port-specific name; native only, cross 27357 compilers do not use this). 27358 27359 4. The macro `STANDARD_EXEC_PREFIX', but only if the toolchain is 27360 installed in the configured PREFIX or this is a native compiler. 27361 27362 5. The location `/usr/lib/gcc/', but only if this is a native 27363 compiler. 27364 27365 6. The macro `MD_EXEC_PREFIX', if defined, but only if this is a 27366 native compiler. 27367 27368 7. The macro `MD_STARTFILE_PREFIX', if defined, but only if this is a 27369 native compiler, or we have a target system root. 27370 27371 8. The macro `MD_STARTFILE_PREFIX_1', if defined, but only if this is 27372 a native compiler, or we have a target system root. 27373 27374 9. The macro `STANDARD_STARTFILE_PREFIX', with any sysroot 27375 modifications. If this path is relative it will be prefixed by 27376 `GCC_EXEC_PREFIX' and the machine suffix or `STANDARD_EXEC_PREFIX' 27377 and the machine suffix. 27378 27379 10. The macro `STANDARD_STARTFILE_PREFIX_1', but only if this is a 27380 native compiler, or we have a target system root. The default for 27381 this macro is `/lib/'. 27382 27383 11. The macro `STANDARD_STARTFILE_PREFIX_2', but only if this is a 27384 native compiler, or we have a target system root. The default for 27385 this macro is `/usr/lib/'. 27386 27387 27388 File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 27389 27390 17.3 Run-time Target Specification 27391 ================================== 27392 27393 Here are run-time target specifications. 27394 27395 -- Macro: TARGET_CPU_CPP_BUILTINS () 27396 This function-like macro expands to a block of code that defines 27397 built-in preprocessor macros and assertions for the target CPU, 27398 using the functions `builtin_define', `builtin_define_std' and 27399 `builtin_assert'. When the front end calls this macro it provides 27400 a trailing semicolon, and since it has finished command line 27401 option processing your code can use those results freely. 27402 27403 `builtin_assert' takes a string in the form you pass to the 27404 command-line option `-A', such as `cpu=mips', and creates the 27405 assertion. `builtin_define' takes a string in the form accepted 27406 by option `-D' and unconditionally defines the macro. 27407 27408 `builtin_define_std' takes a string representing the name of an 27409 object-like macro. If it doesn't lie in the user's namespace, 27410 `builtin_define_std' defines it unconditionally. Otherwise, it 27411 defines a version with two leading underscores, and another version 27412 with two leading and trailing underscores, and defines the original 27413 only if an ISO standard was not requested on the command line. For 27414 example, passing `unix' defines `__unix', `__unix__' and possibly 27415 `unix'; passing `_mips' defines `__mips', `__mips__' and possibly 27416 `_mips', and passing `_ABI64' defines only `_ABI64'. 27417 27418 You can also test for the C dialect being compiled. The variable 27419 `c_language' is set to one of `clk_c', `clk_cplusplus' or 27420 `clk_objective_c'. Note that if we are preprocessing assembler, 27421 this variable will be `clk_c' but the function-like macro 27422 `preprocessing_asm_p()' will return true, so you might want to 27423 check for that first. If you need to check for strict ANSI, the 27424 variable `flag_iso' can be used. The function-like macro 27425 `preprocessing_trad_p()' can be used to check for traditional 27426 preprocessing. 27427 27428 -- Macro: TARGET_OS_CPP_BUILTINS () 27429 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 27430 and is used for the target operating system instead. 27431 27432 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 27433 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 27434 and is used for the target object format. `elfos.h' uses this 27435 macro to define `__ELF__', so you probably do not need to define 27436 it yourself. 27437 27438 -- Variable: extern int target_flags 27439 This variable is declared in `options.h', which is included before 27440 any target-specific headers. 27441 27442 -- Common Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 27443 This variable specifies the initial value of `target_flags'. Its 27444 default setting is 0. 27445 27446 -- Common Target Hook: bool TARGET_HANDLE_OPTION (struct gcc_options 27447 *OPTS, struct gcc_options *OPTS_SET, const struct 27448 cl_decoded_option *DECODED, location_t LOC) 27449 This hook is called whenever the user specifies one of the 27450 target-specific options described by the `.opt' definition files 27451 (*note Options::). It has the opportunity to do some 27452 option-specific processing and should return true if the option is 27453 valid. The default definition does nothing but return true. 27454 27455 DECODED specifies the option and its arguments. OPTS and OPTS_SET 27456 are the `gcc_options' structures to be used for storing option 27457 state, and LOC is the location at which the option was passed 27458 (`UNKNOWN_LOCATION' except for options passed via attributes). 27459 27460 -- C Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 27461 *ARG, int VALUE) 27462 This target hook is called whenever the user specifies one of the 27463 target-specific C language family options described by the `.opt' 27464 definition files(*note Options::). It has the opportunity to do 27465 some option-specific processing and should return true if the 27466 option is valid. The arguments are like for 27467 `TARGET_HANDLE_OPTION'. The default definition does nothing but 27468 return false. 27469 27470 In general, you should use `TARGET_HANDLE_OPTION' to handle 27471 options. However, if processing an option requires routines that 27472 are only available in the C (and related language) front ends, 27473 then you should use `TARGET_HANDLE_C_OPTION' instead. 27474 27475 -- C Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree 27476 STRING) 27477 Targets may provide a string object type that can be used within 27478 and between C, C++ and their respective Objective-C dialects. A 27479 string object might, for example, embed encoding and length 27480 information. These objects are considered opaque to the compiler 27481 and handled as references. An ideal implementation makes the 27482 composition of the string object match that of the Objective-C 27483 `NSString' (`NXString' for GNUStep), allowing efficient 27484 interworking between C-only and Objective-C code. If a target 27485 implements string objects then this hook should return a reference 27486 to such an object constructed from the normal `C' string 27487 representation provided in STRING. At present, the hook is used by 27488 Objective-C only, to obtain a common-format string object when the 27489 target provides one. 27490 27491 -- C Target Hook: void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE 27492 (const char *CLASSNAME) 27493 Declare that Objective C class CLASSNAME is referenced by the 27494 current TU. 27495 27496 -- C Target Hook: void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const 27497 char *CLASSNAME) 27498 Declare that Objective C class CLASSNAME is defined by the 27499 current TU. 27500 27501 -- C Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 27502 STRINGREF) 27503 If a target implements string objects then this hook should return 27504 `true' if STRINGREF is a valid reference to such an object. 27505 27506 -- C Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree 27507 FORMAT_ARG, tree ARGS_LIST) 27508 If a target implements string objects then this hook should should 27509 provide a facility to check the function arguments in ARGS_LIST 27510 against the format specifiers in FORMAT_ARG where the type of 27511 FORMAT_ARG is one recognized as a valid string reference type. 27512 27513 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 27514 This target function is similar to the hook 27515 `TARGET_OPTION_OVERRIDE' but is called when the optimize level is 27516 changed via an attribute or pragma or when it is reset at the end 27517 of the code affected by the attribute or pragma. It is not called 27518 at the beginning of compilation when `TARGET_OPTION_OVERRIDE' is 27519 called so if you want to perform these actions then, you should 27520 have `TARGET_OPTION_OVERRIDE' call 27521 `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 27522 27523 -- Macro: C_COMMON_OVERRIDE_OPTIONS 27524 This is similar to the `TARGET_OPTION_OVERRIDE' hook but is only 27525 used in the C language frontends (C, Objective-C, C++, 27526 Objective-C++) and so can be used to alter option flag variables 27527 which only exist in those frontends. 27528 27529 -- Common Target Hook: const struct default_options * 27530 TARGET_OPTION_OPTIMIZATION_TABLE 27531 Some machines may desire to change what optimizations are 27532 performed for various optimization levels. This variable, if 27533 defined, describes options to enable at particular sets of 27534 optimization levels. These options are processed once just after 27535 the optimization level is determined and before the remainder of 27536 the command options have been parsed, so may be overridden by other 27537 options passed explicitly. 27538 27539 This processing is run once at program startup and when the 27540 optimization options are changed via `#pragma GCC optimize' or by 27541 using the `optimize' attribute. 27542 27543 -- Common Target Hook: void TARGET_OPTION_INIT_STRUCT (struct 27544 gcc_options *OPTS) 27545 Set target-dependent initial values of fields in OPTS. 27546 27547 -- Common Target Hook: void TARGET_OPTION_DEFAULT_PARAMS (void) 27548 Set target-dependent default values for `--param' settings, using 27549 calls to `set_default_param_value'. 27550 27551 -- Macro: SWITCHABLE_TARGET 27552 Some targets need to switch between substantially different 27553 subtargets during compilation. For example, the MIPS target has 27554 one subtarget for the traditional MIPS architecture and another 27555 for MIPS16. Source code can switch between these two 27556 subarchitectures using the `mips16' and `nomips16' attributes. 27557 27558 Such subtargets can differ in things like the set of available 27559 registers, the set of available instructions, the costs of various 27560 operations, and so on. GCC caches a lot of this type of 27561 information in global variables, and recomputing them for each 27562 subtarget takes a significant amount of time. The compiler 27563 therefore provides a facility for maintaining several versions of 27564 the global variables and quickly switching between them; see 27565 `target-globals.h' for details. 27566 27567 Define this macro to 1 if your target needs this facility. The 27568 default is 0. 27569 27570 27571 File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 27572 27573 17.4 Defining data structures for per-function information. 27574 =========================================================== 27575 27576 If the target needs to store information on a per-function basis, GCC 27577 provides a macro and a couple of variables to allow this. Note, just 27578 using statics to store the information is a bad idea, since GCC supports 27579 nested functions, so you can be halfway through encoding one function 27580 when another one comes along. 27581 27582 GCC defines a data structure called `struct function' which contains 27583 all of the data specific to an individual function. This structure 27584 contains a field called `machine' whose type is `struct 27585 machine_function *', which can be used by targets to point to their own 27586 specific data. 27587 27588 If a target needs per-function specific data it should define the type 27589 `struct machine_function' and also the macro `INIT_EXPANDERS'. This 27590 macro should be used to initialize the function pointer 27591 `init_machine_status'. This pointer is explained below. 27592 27593 One typical use of per-function, target specific data is to create an 27594 RTX to hold the register containing the function's return address. This 27595 RTX can then be used to implement the `__builtin_return_address' 27596 function, for level 0. 27597 27598 Note--earlier implementations of GCC used a single data area to hold 27599 all of the per-function information. Thus when processing of a nested 27600 function began the old per-function data had to be pushed onto a stack, 27601 and when the processing was finished, it had to be popped off the 27602 stack. GCC used to provide function pointers called 27603 `save_machine_status' and `restore_machine_status' to handle the saving 27604 and restoring of the target specific information. Since the single 27605 data area approach is no longer used, these pointers are no longer 27606 supported. 27607 27608 -- Macro: INIT_EXPANDERS 27609 Macro called to initialize any target specific information. This 27610 macro is called once per function, before generation of any RTL 27611 has begun. The intention of this macro is to allow the 27612 initialization of the function pointer `init_machine_status'. 27613 27614 -- Variable: void (*)(struct function *) init_machine_status 27615 If this function pointer is non-`NULL' it will be called once per 27616 function, before function compilation starts, in order to allow the 27617 target to perform any target specific initialization of the 27618 `struct function' structure. It is intended that this would be 27619 used to initialize the `machine' of that structure. 27620 27621 `struct machine_function' structures are expected to be freed by 27622 GC. Generally, any memory that they reference must be allocated 27623 by using GC allocation, including the structure itself. 27624 27625 27626 File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 27627 27628 17.5 Storage Layout 27629 =================== 27630 27631 Note that the definitions of the macros in this table which are sizes or 27632 alignments measured in bits do not need to be constant. They can be C 27633 expressions that refer to static variables, such as the `target_flags'. 27634 *Note Run-time Target::. 27635 27636 -- Macro: BITS_BIG_ENDIAN 27637 Define this macro to have the value 1 if the most significant bit 27638 in a byte has the lowest number; otherwise define it to have the 27639 value zero. This means that bit-field instructions count from the 27640 most significant bit. If the machine has no bit-field 27641 instructions, then this must still be defined, but it doesn't 27642 matter which value it is defined to. This macro need not be a 27643 constant. 27644 27645 This macro does not affect the way structure fields are packed into 27646 bytes or words; that is controlled by `BYTES_BIG_ENDIAN'. 27647 27648 -- Macro: BYTES_BIG_ENDIAN 27649 Define this macro to have the value 1 if the most significant byte 27650 in a word has the lowest number. This macro need not be a 27651 constant. 27652 27653 -- Macro: WORDS_BIG_ENDIAN 27654 Define this macro to have the value 1 if, in a multiword object, 27655 the most significant word has the lowest number. This applies to 27656 both memory locations and registers; see `REG_WORDS_BIG_ENDIAN' if 27657 the order of words in memory is not the same as the order in 27658 registers. This macro need not be a constant. 27659 27660 -- Macro: REG_WORDS_BIG_ENDIAN 27661 On some machines, the order of words in a multiword object differs 27662 between registers in memory. In such a situation, define this 27663 macro to describe the order of words in a register. The macro 27664 `WORDS_BIG_ENDIAN' controls the order of words in memory. 27665 27666 -- Macro: FLOAT_WORDS_BIG_ENDIAN 27667 Define this macro to have the value 1 if `DFmode', `XFmode' or 27668 `TFmode' floating point numbers are stored in memory with the word 27669 containing the sign bit at the lowest address; otherwise define it 27670 to have the value 0. This macro need not be a constant. 27671 27672 You need not define this macro if the ordering is the same as for 27673 multi-word integers. 27674 27675 -- Macro: BITS_PER_UNIT 27676 Define this macro to be the number of bits in an addressable 27677 storage unit (byte). If you do not define this macro the default 27678 is 8. 27679 27680 -- Macro: BITS_PER_WORD 27681 Number of bits in a word. If you do not define this macro, the 27682 default is `BITS_PER_UNIT * UNITS_PER_WORD'. 27683 27684 -- Macro: MAX_BITS_PER_WORD 27685 Maximum number of bits in a word. If this is undefined, the 27686 default is `BITS_PER_WORD'. Otherwise, it is the constant value 27687 that is the largest value that `BITS_PER_WORD' can have at 27688 run-time. 27689 27690 -- Macro: UNITS_PER_WORD 27691 Number of storage units in a word; normally the size of a 27692 general-purpose register, a power of two from 1 or 8. 27693 27694 -- Macro: MIN_UNITS_PER_WORD 27695 Minimum number of units in a word. If this is undefined, the 27696 default is `UNITS_PER_WORD'. Otherwise, it is the constant value 27697 that is the smallest value that `UNITS_PER_WORD' can have at 27698 run-time. 27699 27700 -- Macro: POINTER_SIZE 27701 Width of a pointer, in bits. You must specify a value no wider 27702 than the width of `Pmode'. If it is not equal to the width of 27703 `Pmode', you must define `POINTERS_EXTEND_UNSIGNED'. If you do 27704 not specify a value the default is `BITS_PER_WORD'. 27705 27706 -- Macro: POINTERS_EXTEND_UNSIGNED 27707 A C expression that determines how pointers should be extended from 27708 `ptr_mode' to either `Pmode' or `word_mode'. It is greater than 27709 zero if pointers should be zero-extended, zero if they should be 27710 sign-extended, and negative if some other sort of conversion is 27711 needed. In the last case, the extension is done by the target's 27712 `ptr_extend' instruction. 27713 27714 You need not define this macro if the `ptr_mode', `Pmode' and 27715 `word_mode' are all the same width. 27716 27717 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 27718 A macro to update M and UNSIGNEDP when an object whose type is 27719 TYPE and which has the specified mode and signedness is to be 27720 stored in a register. This macro is only called when TYPE is a 27721 scalar type. 27722 27723 On most RISC machines, which only have operations that operate on 27724 a full register, define this macro to set M to `word_mode' if M is 27725 an integer mode narrower than `BITS_PER_WORD'. In most cases, 27726 only integer modes should be widened because wider-precision 27727 floating-point operations are usually more expensive than their 27728 narrower counterparts. 27729 27730 For most machines, the macro definition does not change UNSIGNEDP. 27731 However, some machines, have instructions that preferentially 27732 handle either signed or unsigned quantities of certain modes. For 27733 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 27734 instructions sign-extend the result to 64 bits. On such machines, 27735 set UNSIGNEDP according to which kind of extension is more 27736 efficient. 27737 27738 Do not define this macro if it would never modify M. 27739 27740 -- Target Hook: enum machine_mode TARGET_PROMOTE_FUNCTION_MODE 27741 (const_tree TYPE, enum machine_mode MODE, int *PUNSIGNEDP, 27742 const_tree FUNTYPE, int FOR_RETURN) 27743 Like `PROMOTE_MODE', but it is applied to outgoing function 27744 arguments or function return values. The target hook should 27745 return the new mode and possibly change `*PUNSIGNEDP' if the 27746 promotion should change signedness. This function is called only 27747 for scalar _or pointer_ types. 27748 27749 FOR_RETURN allows to distinguish the promotion of arguments and 27750 return values. If it is `1', a return value is being promoted and 27751 `TARGET_FUNCTION_VALUE' must perform the same promotions done here. 27752 If it is `2', the returned mode should be that of the register in 27753 which an incoming parameter is copied, or the outgoing result is 27754 computed; then the hook should return the same mode as 27755 `promote_mode', though the signedness may be different. 27756 27757 TYPE can be NULL when promoting function arguments of libcalls. 27758 27759 The default is to not promote arguments and return values. You can 27760 also define the hook to 27761 `default_promote_function_mode_always_promote' if you would like 27762 to apply the same rules given by `PROMOTE_MODE'. 27763 27764 -- Macro: PARM_BOUNDARY 27765 Normal alignment required for function parameters on the stack, in 27766 bits. All stack parameters receive at least this much alignment 27767 regardless of data type. On most machines, this is the same as the 27768 size of an integer. 27769 27770 -- Macro: STACK_BOUNDARY 27771 Define this macro to the minimum alignment enforced by hardware 27772 for the stack pointer on this machine. The definition is a C 27773 expression for the desired alignment (measured in bits). This 27774 value is used as a default if `PREFERRED_STACK_BOUNDARY' is not 27775 defined. On most machines, this should be the same as 27776 `PARM_BOUNDARY'. 27777 27778 -- Macro: PREFERRED_STACK_BOUNDARY 27779 Define this macro if you wish to preserve a certain alignment for 27780 the stack pointer, greater than what the hardware enforces. The 27781 definition is a C expression for the desired alignment (measured 27782 in bits). This macro must evaluate to a value equal to or larger 27783 than `STACK_BOUNDARY'. 27784 27785 -- Macro: INCOMING_STACK_BOUNDARY 27786 Define this macro if the incoming stack boundary may be different 27787 from `PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 27788 value equal to or larger than `STACK_BOUNDARY'. 27789 27790 -- Macro: FUNCTION_BOUNDARY 27791 Alignment required for a function entry point, in bits. 27792 27793 -- Macro: BIGGEST_ALIGNMENT 27794 Biggest alignment that any data type can require on this machine, 27795 in bits. Note that this is not the biggest alignment that is 27796 supported, just the biggest alignment that, when violated, may 27797 cause a fault. 27798 27799 -- Macro: MALLOC_ABI_ALIGNMENT 27800 Alignment, in bits, a C conformant malloc implementation has to 27801 provide. If not defined, the default value is `BITS_PER_WORD'. 27802 27803 -- Macro: ATTRIBUTE_ALIGNED_VALUE 27804 Alignment used by the `__attribute__ ((aligned))' construct. If 27805 not defined, the default value is `BIGGEST_ALIGNMENT'. 27806 27807 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 27808 If defined, the smallest alignment, in bits, that can be given to 27809 an object that can be referenced in one operation, without 27810 disturbing any nearby object. Normally, this is `BITS_PER_UNIT', 27811 but may be larger on machines that don't have byte or half-word 27812 store operations. 27813 27814 -- Macro: BIGGEST_FIELD_ALIGNMENT 27815 Biggest alignment that any structure or union field can require on 27816 this machine, in bits. If defined, this overrides 27817 `BIGGEST_ALIGNMENT' for structure and union fields only, unless 27818 the field alignment has been set by the `__attribute__ ((aligned 27819 (N)))' construct. 27820 27821 -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED) 27822 An expression for the alignment of a structure field FIELD if the 27823 alignment computed in the usual way (including applying of 27824 `BIGGEST_ALIGNMENT' and `BIGGEST_FIELD_ALIGNMENT' to the 27825 alignment) is COMPUTED. It overrides alignment only if the field 27826 alignment has not been set by the `__attribute__ ((aligned (N)))' 27827 construct. 27828 27829 -- Macro: MAX_STACK_ALIGNMENT 27830 Biggest stack alignment guaranteed by the backend. Use this macro 27831 to specify the maximum alignment of a variable on stack. 27832 27833 If not defined, the default value is `STACK_BOUNDARY'. 27834 27835 27836 -- Macro: MAX_OFILE_ALIGNMENT 27837 Biggest alignment supported by the object file format of this 27838 machine. Use this macro to limit the alignment which can be 27839 specified using the `__attribute__ ((aligned (N)))' construct. If 27840 not defined, the default value is `BIGGEST_ALIGNMENT'. 27841 27842 On systems that use ELF, the default (in `config/elfos.h') is the 27843 largest supported 32-bit ELF section alignment representable on a 27844 32-bit host e.g. `(((unsigned HOST_WIDEST_INT) 1 << 28) * 8)'. On 27845 32-bit ELF the largest supported section alignment in bits is 27846 `(0x80000000 * 8)', but this is not representable on 32-bit hosts. 27847 27848 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 27849 If defined, a C expression to compute the alignment for a variable 27850 in the static store. TYPE is the data type, and BASIC-ALIGN is 27851 the alignment that the object would ordinarily have. The value of 27852 this macro is used instead of that alignment to align the object. 27853 27854 If this macro is not defined, then BASIC-ALIGN is used. 27855 27856 One use of this macro is to increase alignment of medium-size data 27857 to make it all fit in fewer cache lines. Another is to cause 27858 character arrays to be word-aligned so that `strcpy' calls that 27859 copy constants to character arrays can be done inline. 27860 27861 -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN) 27862 If defined, a C expression to compute the alignment given to a 27863 constant that is being placed in memory. CONSTANT is the constant 27864 and BASIC-ALIGN is the alignment that the object would ordinarily 27865 have. The value of this macro is used instead of that alignment to 27866 align the object. 27867 27868 If this macro is not defined, then BASIC-ALIGN is used. 27869 27870 The typical use of this macro is to increase alignment for string 27871 constants to be word aligned so that `strcpy' calls that copy 27872 constants can be done inline. 27873 27874 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 27875 If defined, a C expression to compute the alignment for a variable 27876 in the local store. TYPE is the data type, and BASIC-ALIGN is the 27877 alignment that the object would ordinarily have. The value of this 27878 macro is used instead of that alignment to align the object. 27879 27880 If this macro is not defined, then BASIC-ALIGN is used. 27881 27882 One use of this macro is to increase alignment of medium-size data 27883 to make it all fit in fewer cache lines. 27884 27885 If the value of this macro has a type, it should be an unsigned 27886 type. 27887 27888 -- Target Hook: HOST_WIDE_INT TARGET_VECTOR_ALIGNMENT (const_tree TYPE) 27889 This hook can be used to define the alignment for a vector of type 27890 TYPE, in order to comply with a platform ABI. The default is to 27891 require natural alignment for vector types. The alignment 27892 returned by this hook must be a power-of-two multiple of the 27893 default alignment of the vector element type. 27894 27895 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 27896 If defined, a C expression to compute the alignment for stack slot. 27897 TYPE is the data type, MODE is the widest mode available, and 27898 BASIC-ALIGN is the alignment that the slot would ordinarily have. 27899 The value of this macro is used instead of that alignment to align 27900 the slot. 27901 27902 If this macro is not defined, then BASIC-ALIGN is used when TYPE 27903 is `NULL'. Otherwise, `LOCAL_ALIGNMENT' will be used. 27904 27905 This macro is to set alignment of stack slot to the maximum 27906 alignment of all possible modes which the slot may have. 27907 27908 If the value of this macro has a type, it should be an unsigned 27909 type. 27910 27911 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 27912 If defined, a C expression to compute the alignment for a local 27913 variable DECL. 27914 27915 If this macro is not defined, then `LOCAL_ALIGNMENT (TREE_TYPE 27916 (DECL), DECL_ALIGN (DECL))' is used. 27917 27918 One use of this macro is to increase alignment of medium-size data 27919 to make it all fit in fewer cache lines. 27920 27921 If the value of this macro has a type, it should be an unsigned 27922 type. 27923 27924 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 27925 If defined, a C expression to compute the minimum required 27926 alignment for dynamic stack realignment purposes for EXP (a type 27927 or decl), MODE, assuming normal alignment ALIGN. 27928 27929 If this macro is not defined, then ALIGN will be used. 27930 27931 -- Macro: EMPTY_FIELD_BOUNDARY 27932 Alignment in bits to be given to a structure bit-field that 27933 follows an empty field such as `int : 0;'. 27934 27935 If `PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 27936 27937 -- Macro: STRUCTURE_SIZE_BOUNDARY 27938 Number of bits which any structure or union's size must be a 27939 multiple of. Each structure or union's size is rounded up to a 27940 multiple of this. 27941 27942 If you do not define this macro, the default is the same as 27943 `BITS_PER_UNIT'. 27944 27945 -- Macro: STRICT_ALIGNMENT 27946 Define this macro to be the value 1 if instructions will fail to 27947 work if given data not on the nominal alignment. If instructions 27948 will merely go slower in that case, define this macro as 0. 27949 27950 -- Macro: PCC_BITFIELD_TYPE_MATTERS 27951 Define this if you wish to imitate the way many other C compilers 27952 handle alignment of bit-fields and the structures that contain 27953 them. 27954 27955 The behavior is that the type written for a named bit-field (`int', 27956 `short', or other integer type) imposes an alignment for the entire 27957 structure, as if the structure really did contain an ordinary 27958 field of that type. In addition, the bit-field is placed within 27959 the structure so that it would fit within such a field, not 27960 crossing a boundary for it. 27961 27962 Thus, on most machines, a named bit-field whose type is written as 27963 `int' would not cross a four-byte boundary, and would force 27964 four-byte alignment for the whole structure. (The alignment used 27965 may not be four bytes; it is controlled by the other alignment 27966 parameters.) 27967 27968 An unnamed bit-field will not affect the alignment of the 27969 containing structure. 27970 27971 If the macro is defined, its definition should be a C expression; 27972 a nonzero value for the expression enables this behavior. 27973 27974 Note that if this macro is not defined, or its value is zero, some 27975 bit-fields may cross more than one alignment boundary. The 27976 compiler can support such references if there are `insv', `extv', 27977 and `extzv' insns that can directly reference memory. 27978 27979 The other known way of making bit-fields work is to define 27980 `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then 27981 every structure can be accessed with fullwords. 27982 27983 Unless the machine has bit-field instructions or you define 27984 `STRUCTURE_SIZE_BOUNDARY' that way, you must define 27985 `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 27986 27987 If your aim is to make GCC use the same conventions for laying out 27988 bit-fields as are used by another compiler, here is how to 27989 investigate what the other compiler does. Compile and run this 27990 program: 27991 27992 struct foo1 27993 { 27994 char x; 27995 char :0; 27996 char y; 27997 }; 27998 27999 struct foo2 28000 { 28001 char x; 28002 int :0; 28003 char y; 28004 }; 28005 28006 main () 28007 { 28008 printf ("Size of foo1 is %d\n", 28009 sizeof (struct foo1)); 28010 printf ("Size of foo2 is %d\n", 28011 sizeof (struct foo2)); 28012 exit (0); 28013 } 28014 28015 If this prints 2 and 5, then the compiler's behavior is what you 28016 would get from `PCC_BITFIELD_TYPE_MATTERS'. 28017 28018 -- Macro: BITFIELD_NBYTES_LIMITED 28019 Like `PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 28020 to aligning a bit-field within the structure. 28021 28022 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 28023 When `PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 28024 whether unnamed bitfields affect the alignment of the containing 28025 structure. The hook should return true if the structure should 28026 inherit the alignment requirements of an unnamed bitfield's type. 28027 28028 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 28029 This target hook should return `true' if accesses to volatile 28030 bitfields should use the narrowest mode possible. It should 28031 return `false' if these accesses should use the bitfield container 28032 type. 28033 28034 The default is `!TARGET_STRICT_ALIGN'. 28035 28036 -- Target Hook: bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree FIELD, 28037 enum machine_mode MODE) 28038 Return true if a structure, union or array containing FIELD should 28039 be accessed using `BLKMODE'. 28040 28041 If FIELD is the only field in the structure, MODE is its mode, 28042 otherwise MODE is VOIDmode. MODE is provided in the case where 28043 structures of one field would require the structure's mode to 28044 retain the field's mode. 28045 28046 Normally, this is not needed. 28047 28048 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 28049 Define this macro as an expression for the alignment of a type 28050 (given by TYPE as a tree node) if the alignment computed in the 28051 usual way is COMPUTED and the alignment explicitly specified was 28052 SPECIFIED. 28053 28054 The default is to use SPECIFIED if it is larger; otherwise, use 28055 the smaller of COMPUTED and `BIGGEST_ALIGNMENT' 28056 28057 -- Macro: MAX_FIXED_MODE_SIZE 28058 An integer expression for the size in bits of the largest integer 28059 machine mode that should actually be used. All integer machine 28060 modes of this size or smaller can be used for structures and 28061 unions with the appropriate sizes. If this macro is undefined, 28062 `GET_MODE_BITSIZE (DImode)' is assumed. 28063 28064 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 28065 If defined, an expression of type `enum machine_mode' that 28066 specifies the mode of the save area operand of a 28067 `save_stack_LEVEL' named pattern (*note Standard Names::). 28068 SAVE_LEVEL is one of `SAVE_BLOCK', `SAVE_FUNCTION', or 28069 `SAVE_NONLOCAL' and selects which of the three named patterns is 28070 having its mode specified. 28071 28072 You need not define this macro if it always returns `Pmode'. You 28073 would most commonly define this macro if the `save_stack_LEVEL' 28074 patterns need to support both a 32- and a 64-bit mode. 28075 28076 -- Macro: STACK_SIZE_MODE 28077 If defined, an expression of type `enum machine_mode' that 28078 specifies the mode of the size increment operand of an 28079 `allocate_stack' named pattern (*note Standard Names::). 28080 28081 You need not define this macro if it always returns `word_mode'. 28082 You would most commonly define this macro if the `allocate_stack' 28083 pattern needs to support both a 32- and a 64-bit mode. 28084 28085 -- Target Hook: enum machine_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 28086 This target hook should return the mode to be used for the return 28087 value of compare instructions expanded to libgcc calls. If not 28088 defined `word_mode' is returned which is the right choice for a 28089 majority of targets. 28090 28091 -- Target Hook: enum machine_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 28092 This target hook should return the mode to be used for the shift 28093 count operand of shift instructions expanded to libgcc calls. If 28094 not defined `word_mode' is returned which is the right choice for 28095 a majority of targets. 28096 28097 -- Target Hook: enum machine_mode TARGET_UNWIND_WORD_MODE (void) 28098 Return machine mode to be used for `_Unwind_Word' type. The 28099 default is to use `word_mode'. 28100 28101 -- Macro: ROUND_TOWARDS_ZERO 28102 If defined, this macro should be true if the prevailing rounding 28103 mode is towards zero. 28104 28105 Defining this macro only affects the way `libgcc.a' emulates 28106 floating-point arithmetic. 28107 28108 Not defining this macro is equivalent to returning zero. 28109 28110 -- Macro: LARGEST_EXPONENT_IS_NORMAL (SIZE) 28111 This macro should return true if floats with SIZE bits do not have 28112 a NaN or infinity representation, but use the largest exponent for 28113 normal numbers instead. 28114 28115 Defining this macro only affects the way `libgcc.a' emulates 28116 floating-point arithmetic. 28117 28118 The default definition of this macro returns false for all sizes. 28119 28120 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 28121 RECORD_TYPE) 28122 This target hook returns `true' if bit-fields in the given 28123 RECORD_TYPE are to be laid out following the rules of Microsoft 28124 Visual C/C++, namely: (i) a bit-field won't share the same storage 28125 unit with the previous bit-field if their underlying types have 28126 different sizes, and the bit-field will be aligned to the highest 28127 alignment of the underlying types of itself and of the previous 28128 bit-field; (ii) a zero-sized bit-field will affect the alignment of 28129 the whole enclosing structure, even if it is unnamed; except that 28130 (iii) a zero-sized bit-field will be disregarded unless it follows 28131 another bit-field of nonzero size. If this hook returns `true', 28132 other macros that control bit-field layout are ignored. 28133 28134 When a bit-field is inserted into a packed record, the whole size 28135 of the underlying type is used by one or more same-size adjacent 28136 bit-fields (that is, if its long:3, 32 bits is used in the record, 28137 and any additional adjacent long bit-fields are packed into the 28138 same chunk of 32 bits. However, if the size changes, a new field 28139 of that size is allocated). In an unpacked record, this is the 28140 same as using alignment, but not equivalent when packing. 28141 28142 If both MS bit-fields and `__attribute__((packed))' are used, the 28143 latter will take precedence. If `__attribute__((packed))' is used 28144 on a single field when MS bit-fields are in use, it will take 28145 precedence for that field, but the alignment of the rest of the 28146 structure may affect its placement. 28147 28148 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 28149 Returns true if the target supports decimal floating point. 28150 28151 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 28152 Returns true if the target supports fixed-point arithmetic. 28153 28154 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 28155 This hook is called just before expansion into rtl, allowing the 28156 target to perform additional initializations or analysis before 28157 the expansion. For example, the rs6000 port uses it to allocate a 28158 scratch stack slot for use in copying SDmode values between memory 28159 and floating point registers whenever the function being expanded 28160 has any SDmode usage. 28161 28162 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 28163 This hook allows the backend to perform additional instantiations 28164 on rtl that are not actually in any insns yet, but will be later. 28165 28166 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 28167 If your target defines any fundamental types, or any types your 28168 target uses should be mangled differently from the default, define 28169 this hook to return the appropriate encoding for these types as 28170 part of a C++ mangled name. The TYPE argument is the tree 28171 structure representing the type to be mangled. The hook may be 28172 applied to trees which are not target-specific fundamental types; 28173 it should return `NULL' for all such types, as well as arguments 28174 it does not recognize. If the return value is not `NULL', it must 28175 point to a statically-allocated string constant. 28176 28177 Target-specific fundamental types might be new fundamental types or 28178 qualified versions of ordinary fundamental types. Encode new 28179 fundamental types as `u N NAME', where NAME is the name used for 28180 the type in source code, and N is the length of NAME in decimal. 28181 Encode qualified versions of ordinary types as `U N NAME CODE', 28182 where NAME is the name used for the type qualifier in source code, 28183 N is the length of NAME as above, and CODE is the code used to 28184 represent the unqualified version of this type. (See 28185 `write_builtin_type' in `cp/mangle.c' for the list of codes.) In 28186 both cases the spaces are for clarity; do not include any spaces 28187 in your string. 28188 28189 This hook is applied to types prior to typedef resolution. If the 28190 mangled name for a particular type depends only on that type's 28191 main variant, you can perform typedef resolution yourself using 28192 `TYPE_MAIN_VARIANT' before mangling. 28193 28194 The default version of this hook always returns `NULL', which is 28195 appropriate for a target that does not define any new fundamental 28196 types. 28197 28198 28199 File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 28200 28201 17.6 Layout of Source Language Data Types 28202 ========================================= 28203 28204 These macros define the sizes and other characteristics of the standard 28205 basic data types used in programs being compiled. Unlike the macros in 28206 the previous section, these apply to specific features of C and related 28207 languages, rather than to fundamental aspects of storage layout. 28208 28209 -- Macro: INT_TYPE_SIZE 28210 A C expression for the size in bits of the type `int' on the 28211 target machine. If you don't define this, the default is one word. 28212 28213 -- Macro: SHORT_TYPE_SIZE 28214 A C expression for the size in bits of the type `short' on the 28215 target machine. If you don't define this, the default is half a 28216 word. (If this would be less than one storage unit, it is rounded 28217 up to one unit.) 28218 28219 -- Macro: LONG_TYPE_SIZE 28220 A C expression for the size in bits of the type `long' on the 28221 target machine. If you don't define this, the default is one word. 28222 28223 -- Macro: ADA_LONG_TYPE_SIZE 28224 On some machines, the size used for the Ada equivalent of the type 28225 `long' by a native Ada compiler differs from that used by C. In 28226 that situation, define this macro to be a C expression to be used 28227 for the size of that type. If you don't define this, the default 28228 is the value of `LONG_TYPE_SIZE'. 28229 28230 -- Macro: LONG_LONG_TYPE_SIZE 28231 A C expression for the size in bits of the type `long long' on the 28232 target machine. If you don't define this, the default is two 28233 words. If you want to support GNU Ada on your machine, the value 28234 of this macro must be at least 64. 28235 28236 -- Macro: CHAR_TYPE_SIZE 28237 A C expression for the size in bits of the type `char' on the 28238 target machine. If you don't define this, the default is 28239 `BITS_PER_UNIT'. 28240 28241 -- Macro: BOOL_TYPE_SIZE 28242 A C expression for the size in bits of the C++ type `bool' and C99 28243 type `_Bool' on the target machine. If you don't define this, and 28244 you probably shouldn't, the default is `CHAR_TYPE_SIZE'. 28245 28246 -- Macro: FLOAT_TYPE_SIZE 28247 A C expression for the size in bits of the type `float' on the 28248 target machine. If you don't define this, the default is one word. 28249 28250 -- Macro: DOUBLE_TYPE_SIZE 28251 A C expression for the size in bits of the type `double' on the 28252 target machine. If you don't define this, the default is two 28253 words. 28254 28255 -- Macro: LONG_DOUBLE_TYPE_SIZE 28256 A C expression for the size in bits of the type `long double' on 28257 the target machine. If you don't define this, the default is two 28258 words. 28259 28260 -- Macro: SHORT_FRACT_TYPE_SIZE 28261 A C expression for the size in bits of the type `short _Fract' on 28262 the target machine. If you don't define this, the default is 28263 `BITS_PER_UNIT'. 28264 28265 -- Macro: FRACT_TYPE_SIZE 28266 A C expression for the size in bits of the type `_Fract' on the 28267 target machine. If you don't define this, the default is 28268 `BITS_PER_UNIT * 2'. 28269 28270 -- Macro: LONG_FRACT_TYPE_SIZE 28271 A C expression for the size in bits of the type `long _Fract' on 28272 the target machine. If you don't define this, the default is 28273 `BITS_PER_UNIT * 4'. 28274 28275 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 28276 A C expression for the size in bits of the type `long long _Fract' 28277 on the target machine. If you don't define this, the default is 28278 `BITS_PER_UNIT * 8'. 28279 28280 -- Macro: SHORT_ACCUM_TYPE_SIZE 28281 A C expression for the size in bits of the type `short _Accum' on 28282 the target machine. If you don't define this, the default is 28283 `BITS_PER_UNIT * 2'. 28284 28285 -- Macro: ACCUM_TYPE_SIZE 28286 A C expression for the size in bits of the type `_Accum' on the 28287 target machine. If you don't define this, the default is 28288 `BITS_PER_UNIT * 4'. 28289 28290 -- Macro: LONG_ACCUM_TYPE_SIZE 28291 A C expression for the size in bits of the type `long _Accum' on 28292 the target machine. If you don't define this, the default is 28293 `BITS_PER_UNIT * 8'. 28294 28295 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 28296 A C expression for the size in bits of the type `long long _Accum' 28297 on the target machine. If you don't define this, the default is 28298 `BITS_PER_UNIT * 16'. 28299 28300 -- Macro: LIBGCC2_LONG_DOUBLE_TYPE_SIZE 28301 Define this macro if `LONG_DOUBLE_TYPE_SIZE' is not constant or if 28302 you want routines in `libgcc2.a' for a size other than 28303 `LONG_DOUBLE_TYPE_SIZE'. If you don't define this, the default is 28304 `LONG_DOUBLE_TYPE_SIZE'. 28305 28306 -- Macro: LIBGCC2_HAS_DF_MODE 28307 Define this macro if neither `DOUBLE_TYPE_SIZE' nor 28308 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is `DFmode' but you want `DFmode' 28309 routines in `libgcc2.a' anyway. If you don't define this and 28310 either `DOUBLE_TYPE_SIZE' or `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64 28311 then the default is 1, otherwise it is 0. 28312 28313 -- Macro: LIBGCC2_HAS_XF_MODE 28314 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not 28315 `XFmode' but you want `XFmode' routines in `libgcc2.a' anyway. If 28316 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 80 28317 then the default is 1, otherwise it is 0. 28318 28319 -- Macro: LIBGCC2_HAS_TF_MODE 28320 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not 28321 `TFmode' but you want `TFmode' routines in `libgcc2.a' anyway. If 28322 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 128 28323 then the default is 1, otherwise it is 0. 28324 28325 -- Macro: LIBGCC2_GNU_PREFIX 28326 This macro corresponds to the `TARGET_LIBFUNC_GNU_PREFIX' target 28327 hook and should be defined if that hook is overriden to be true. 28328 It causes function names in libgcc to be changed to use a `__gnu_' 28329 prefix for their name rather than the default `__'. A port which 28330 uses this macro should also arrange to use `t-gnu-prefix' in the 28331 libgcc `config.host'. 28332 28333 -- Macro: SF_SIZE 28334 -- Macro: DF_SIZE 28335 -- Macro: XF_SIZE 28336 -- Macro: TF_SIZE 28337 Define these macros to be the size in bits of the mantissa of 28338 `SFmode', `DFmode', `XFmode' and `TFmode' values, if the defaults 28339 in `libgcc2.h' are inappropriate. By default, `FLT_MANT_DIG' is 28340 used for `SF_SIZE', `LDBL_MANT_DIG' for `XF_SIZE' and `TF_SIZE', 28341 and `DBL_MANT_DIG' or `LDBL_MANT_DIG' for `DF_SIZE' according to 28342 whether `DOUBLE_TYPE_SIZE' or `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 28343 64. 28344 28345 -- Macro: TARGET_FLT_EVAL_METHOD 28346 A C expression for the value for `FLT_EVAL_METHOD' in `float.h', 28347 assuming, if applicable, that the floating-point control word is 28348 in its default state. If you do not define this macro the value of 28349 `FLT_EVAL_METHOD' will be zero. 28350 28351 -- Macro: WIDEST_HARDWARE_FP_SIZE 28352 A C expression for the size in bits of the widest floating-point 28353 format supported by the hardware. If you define this macro, you 28354 must specify a value less than or equal to the value of 28355 `LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 28356 value of `LONG_DOUBLE_TYPE_SIZE' is the default. 28357 28358 -- Macro: DEFAULT_SIGNED_CHAR 28359 An expression whose value is 1 or 0, according to whether the type 28360 `char' should be signed or unsigned by default. The user can 28361 always override this default with the options `-fsigned-char' and 28362 `-funsigned-char'. 28363 28364 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 28365 This target hook should return true if the compiler should give an 28366 `enum' type only as many bytes as it takes to represent the range 28367 of possible values of that type. It should return false if all 28368 `enum' types should be allocated like `int'. 28369 28370 The default is to return false. 28371 28372 -- Macro: SIZE_TYPE 28373 A C expression for a string describing the name of the data type 28374 to use for size values. The typedef name `size_t' is defined 28375 using the contents of the string. 28376 28377 The string can contain more than one keyword. If so, separate 28378 them with spaces, and write first any length keyword, then 28379 `unsigned' if appropriate, and finally `int'. The string must 28380 exactly match one of the data type names defined in the function 28381 `c_common_nodes_and_builtins' in the file `c-family/c-common.c'. 28382 You may not omit `int' or change the order--that would cause the 28383 compiler to crash on startup. 28384 28385 If you don't define this macro, the default is `"long unsigned 28386 int"'. 28387 28388 -- Macro: SIZETYPE 28389 GCC defines internal types (`sizetype', `ssizetype', `bitsizetype' 28390 and `sbitsizetype') for expressions dealing with size. This macro 28391 is a C expression for a string describing the name of the data 28392 type from which the precision of `sizetype' is extracted. 28393 28394 The string has the same restrictions as `SIZE_TYPE' string. 28395 28396 If you don't define this macro, the default is `SIZE_TYPE'. 28397 28398 -- Macro: PTRDIFF_TYPE 28399 A C expression for a string describing the name of the data type 28400 to use for the result of subtracting two pointers. The typedef 28401 name `ptrdiff_t' is defined using the contents of the string. See 28402 `SIZE_TYPE' above for more information. 28403 28404 If you don't define this macro, the default is `"long int"'. 28405 28406 -- Macro: WCHAR_TYPE 28407 A C expression for a string describing the name of the data type 28408 to use for wide characters. The typedef name `wchar_t' is defined 28409 using the contents of the string. See `SIZE_TYPE' above for more 28410 information. 28411 28412 If you don't define this macro, the default is `"int"'. 28413 28414 -- Macro: WCHAR_TYPE_SIZE 28415 A C expression for the size in bits of the data type for wide 28416 characters. This is used in `cpp', which cannot make use of 28417 `WCHAR_TYPE'. 28418 28419 -- Macro: WINT_TYPE 28420 A C expression for a string describing the name of the data type to 28421 use for wide characters passed to `printf' and returned from 28422 `getwc'. The typedef name `wint_t' is defined using the contents 28423 of the string. See `SIZE_TYPE' above for more information. 28424 28425 If you don't define this macro, the default is `"unsigned int"'. 28426 28427 -- Macro: INTMAX_TYPE 28428 A C expression for a string describing the name of the data type 28429 that can represent any value of any standard or extended signed 28430 integer type. The typedef name `intmax_t' is defined using the 28431 contents of the string. See `SIZE_TYPE' above for more 28432 information. 28433 28434 If you don't define this macro, the default is the first of 28435 `"int"', `"long int"', or `"long long int"' that has as much 28436 precision as `long long int'. 28437 28438 -- Macro: UINTMAX_TYPE 28439 A C expression for a string describing the name of the data type 28440 that can represent any value of any standard or extended unsigned 28441 integer type. The typedef name `uintmax_t' is defined using the 28442 contents of the string. See `SIZE_TYPE' above for more 28443 information. 28444 28445 If you don't define this macro, the default is the first of 28446 `"unsigned int"', `"long unsigned int"', or `"long long unsigned 28447 int"' that has as much precision as `long long unsigned int'. 28448 28449 -- Macro: SIG_ATOMIC_TYPE 28450 -- Macro: INT8_TYPE 28451 -- Macro: INT16_TYPE 28452 -- Macro: INT32_TYPE 28453 -- Macro: INT64_TYPE 28454 -- Macro: UINT8_TYPE 28455 -- Macro: UINT16_TYPE 28456 -- Macro: UINT32_TYPE 28457 -- Macro: UINT64_TYPE 28458 -- Macro: INT_LEAST8_TYPE 28459 -- Macro: INT_LEAST16_TYPE 28460 -- Macro: INT_LEAST32_TYPE 28461 -- Macro: INT_LEAST64_TYPE 28462 -- Macro: UINT_LEAST8_TYPE 28463 -- Macro: UINT_LEAST16_TYPE 28464 -- Macro: UINT_LEAST32_TYPE 28465 -- Macro: UINT_LEAST64_TYPE 28466 -- Macro: INT_FAST8_TYPE 28467 -- Macro: INT_FAST16_TYPE 28468 -- Macro: INT_FAST32_TYPE 28469 -- Macro: INT_FAST64_TYPE 28470 -- Macro: UINT_FAST8_TYPE 28471 -- Macro: UINT_FAST16_TYPE 28472 -- Macro: UINT_FAST32_TYPE 28473 -- Macro: UINT_FAST64_TYPE 28474 -- Macro: INTPTR_TYPE 28475 -- Macro: UINTPTR_TYPE 28476 C expressions for the standard types `sig_atomic_t', `int8_t', 28477 `int16_t', `int32_t', `int64_t', `uint8_t', `uint16_t', 28478 `uint32_t', `uint64_t', `int_least8_t', `int_least16_t', 28479 `int_least32_t', `int_least64_t', `uint_least8_t', 28480 `uint_least16_t', `uint_least32_t', `uint_least64_t', 28481 `int_fast8_t', `int_fast16_t', `int_fast32_t', `int_fast64_t', 28482 `uint_fast8_t', `uint_fast16_t', `uint_fast32_t', `uint_fast64_t', 28483 `intptr_t', and `uintptr_t'. See `SIZE_TYPE' above for more 28484 information. 28485 28486 If any of these macros evaluates to a null pointer, the 28487 corresponding type is not supported; if GCC is configured to 28488 provide `<stdint.h>' in such a case, the header provided may not 28489 conform to C99, depending on the type in question. The defaults 28490 for all of these macros are null pointers. 28491 28492 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 28493 The C++ compiler represents a pointer-to-member-function with a 28494 struct that looks like: 28495 28496 struct { 28497 union { 28498 void (*fn)(); 28499 ptrdiff_t vtable_index; 28500 }; 28501 ptrdiff_t delta; 28502 }; 28503 28504 The C++ compiler must use one bit to indicate whether the function 28505 that will be called through a pointer-to-member-function is 28506 virtual. Normally, we assume that the low-order bit of a function 28507 pointer must always be zero. Then, by ensuring that the 28508 vtable_index is odd, we can distinguish which variant of the union 28509 is in use. But, on some platforms function pointers can be odd, 28510 and so this doesn't work. In that case, we use the low-order bit 28511 of the `delta' field, and shift the remainder of the `delta' field 28512 to the left. 28513 28514 GCC will automatically make the right selection about where to 28515 store this bit using the `FUNCTION_BOUNDARY' setting for your 28516 platform. However, some platforms such as ARM/Thumb have 28517 `FUNCTION_BOUNDARY' set such that functions always start at even 28518 addresses, but the lowest bit of pointers to functions indicate 28519 whether the function at that address is in ARM or Thumb mode. If 28520 this is the case of your architecture, you should define this 28521 macro to `ptrmemfunc_vbit_in_delta'. 28522 28523 In general, you should not have to define this macro. On 28524 architectures in which function addresses are always even, 28525 according to `FUNCTION_BOUNDARY', GCC will automatically define 28526 this macro to `ptrmemfunc_vbit_in_pfn'. 28527 28528 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 28529 Normally, the C++ compiler uses function pointers in vtables. This 28530 macro allows the target to change to use "function descriptors" 28531 instead. Function descriptors are found on targets for whom a 28532 function pointer is actually a small data structure. Normally the 28533 data structure consists of the actual code address plus a data 28534 pointer to which the function's data is relative. 28535 28536 If vtables are used, the value of this macro should be the number 28537 of words that the function descriptor occupies. 28538 28539 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 28540 By default, the vtable entries are void pointers, the so the 28541 alignment is the same as pointer alignment. The value of this 28542 macro specifies the alignment of the vtable entry in bits. It 28543 should be defined only when special alignment is necessary. */ 28544 28545 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 28546 There are a few non-descriptor entries in the vtable at offsets 28547 below zero. If these entries must be padded (say, to preserve the 28548 alignment specified by `TARGET_VTABLE_ENTRY_ALIGN'), set this to 28549 the number of words in each data entry. 28550 28551 28552 File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 28553 28554 17.7 Register Usage 28555 =================== 28556 28557 This section explains how to describe what registers the target machine 28558 has, and how (in general) they can be used. 28559 28560 The description of which registers a specific instruction can use is 28561 done with register classes; see *note Register Classes::. For 28562 information on using registers to access a stack frame, see *note Frame 28563 Registers::. For passing values in registers, see *note Register 28564 Arguments::. For returning values in registers, see *note Scalar 28565 Return::. 28566 28567 * Menu: 28568 28569 * Register Basics:: Number and kinds of registers. 28570 * Allocation Order:: Order in which registers are allocated. 28571 * Values in Registers:: What kinds of values each reg can hold. 28572 * Leaf Functions:: Renumbering registers for leaf functions. 28573 * Stack Registers:: Handling a register stack such as 80387. 28574 28575 28576 File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 28577 28578 17.7.1 Basic Characteristics of Registers 28579 ----------------------------------------- 28580 28581 Registers have various characteristics. 28582 28583 -- Macro: FIRST_PSEUDO_REGISTER 28584 Number of hardware registers known to the compiler. They receive 28585 numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first 28586 pseudo register's number really is assigned the number 28587 `FIRST_PSEUDO_REGISTER'. 28588 28589 -- Macro: FIXED_REGISTERS 28590 An initializer that says which registers are used for fixed 28591 purposes all throughout the compiled code and are therefore not 28592 available for general allocation. These would include the stack 28593 pointer, the frame pointer (except on machines where that can be 28594 used as a general register when no frame pointer is needed), the 28595 program counter on machines where that is considered one of the 28596 addressable registers, and any other numbered register with a 28597 standard use. 28598 28599 This information is expressed as a sequence of numbers, separated 28600 by commas and surrounded by braces. The Nth number is 1 if 28601 register N is fixed, 0 otherwise. 28602 28603 The table initialized from this macro, and the table initialized by 28604 the following one, may be overridden at run time either 28605 automatically, by the actions of the macro 28606 `CONDITIONAL_REGISTER_USAGE', or by the user with the command 28607 options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'. 28608 28609 -- Macro: CALL_USED_REGISTERS 28610 Like `FIXED_REGISTERS' but has 1 for each register that is 28611 clobbered (in general) by function calls as well as for fixed 28612 registers. This macro therefore identifies the registers that are 28613 not available for general allocation of values that must live 28614 across function calls. 28615 28616 If a register has 0 in `CALL_USED_REGISTERS', the compiler 28617 automatically saves it on function entry and restores it on 28618 function exit, if the register is used within the function. 28619 28620 -- Macro: CALL_REALLY_USED_REGISTERS 28621 Like `CALL_USED_REGISTERS' except this macro doesn't require that 28622 the entire set of `FIXED_REGISTERS' be included. 28623 (`CALL_USED_REGISTERS' must be a superset of `FIXED_REGISTERS'). 28624 This macro is optional. If not specified, it defaults to the value 28625 of `CALL_USED_REGISTERS'. 28626 28627 -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE) 28628 A C expression that is nonzero if it is not permissible to store a 28629 value of mode MODE in hard register number REGNO across a call 28630 without some part of it being clobbered. For most machines this 28631 macro need not be defined. It is only required for machines that 28632 do not preserve the entire contents of a register across a call. 28633 28634 -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void) 28635 This hook may conditionally modify five variables `fixed_regs', 28636 `call_used_regs', `global_regs', `reg_names', and 28637 `reg_class_contents', to take into account any dependence of these 28638 register sets on target flags. The first three of these are of 28639 type `char []' (interpreted as Boolean vectors). `global_regs' is 28640 a `const char *[]', and `reg_class_contents' is a `HARD_REG_SET'. 28641 Before the macro is called, `fixed_regs', `call_used_regs', 28642 `reg_class_contents', and `reg_names' have been initialized from 28643 `FIXED_REGISTERS', `CALL_USED_REGISTERS', `REG_CLASS_CONTENTS', 28644 and `REGISTER_NAMES', respectively. `global_regs' has been 28645 cleared, and any `-ffixed-REG', `-fcall-used-REG' and 28646 `-fcall-saved-REG' command options have been applied. 28647 28648 If the usage of an entire class of registers depends on the target 28649 flags, you may indicate this to GCC by using this macro to modify 28650 `fixed_regs' and `call_used_regs' to 1 for each of the registers 28651 in the classes which should not be used by GCC. Also define the 28652 macro `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' to 28653 return `NO_REGS' if it is called with a letter for a class that 28654 shouldn't be used. 28655 28656 (However, if this class is not included in `GENERAL_REGS' and all 28657 of the insn patterns whose constraints permit this class are 28658 controlled by target switches, then GCC will automatically avoid 28659 using these registers when the target switches are opposed to 28660 them.) 28661 28662 -- Macro: INCOMING_REGNO (OUT) 28663 Define this macro if the target machine has register windows. 28664 This C expression returns the register number as seen by the 28665 called function corresponding to the register number OUT as seen 28666 by the calling function. Return OUT if register number OUT is not 28667 an outbound register. 28668 28669 -- Macro: OUTGOING_REGNO (IN) 28670 Define this macro if the target machine has register windows. 28671 This C expression returns the register number as seen by the 28672 calling function corresponding to the register number IN as seen 28673 by the called function. Return IN if register number IN is not an 28674 inbound register. 28675 28676 -- Macro: LOCAL_REGNO (REGNO) 28677 Define this macro if the target machine has register windows. 28678 This C expression returns true if the register is call-saved but 28679 is in the register window. Unlike most call-saved registers, such 28680 registers need not be explicitly restored on function exit or 28681 during non-local gotos. 28682 28683 -- Macro: PC_REGNUM 28684 If the program counter has a register number, define this as that 28685 register number. Otherwise, do not define it. 28686 28687 28688 File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 28689 28690 17.7.2 Order of Allocation of Registers 28691 --------------------------------------- 28692 28693 Registers are allocated in order. 28694 28695 -- Macro: REG_ALLOC_ORDER 28696 If defined, an initializer for a vector of integers, containing the 28697 numbers of hard registers in the order in which GCC should prefer 28698 to use them (from most preferred to least). 28699 28700 If this macro is not defined, registers are used lowest numbered 28701 first (all else being equal). 28702 28703 One use of this macro is on machines where the highest numbered 28704 registers must always be saved and the save-multiple-registers 28705 instruction supports only sequences of consecutive registers. On 28706 such machines, define `REG_ALLOC_ORDER' to be an initializer that 28707 lists the highest numbered allocable register first. 28708 28709 -- Macro: ADJUST_REG_ALLOC_ORDER 28710 A C statement (sans semicolon) to choose the order in which to 28711 allocate hard registers for pseudo-registers local to a basic 28712 block. 28713 28714 Store the desired register order in the array `reg_alloc_order'. 28715 Element 0 should be the register to allocate first; element 1, the 28716 next register; and so on. 28717 28718 The macro body should not assume anything about the contents of 28719 `reg_alloc_order' before execution of the macro. 28720 28721 On most machines, it is not necessary to define this macro. 28722 28723 -- Macro: HONOR_REG_ALLOC_ORDER 28724 Normally, IRA tries to estimate the costs for saving a register in 28725 the prologue and restoring it in the epilogue. This discourages 28726 it from using call-saved registers. If a machine wants to ensure 28727 that IRA allocates registers in the order given by REG_ALLOC_ORDER 28728 even if some call-saved registers appear earlier than call-used 28729 ones, this macro should be defined. 28730 28731 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 28732 In some case register allocation order is not enough for the 28733 Integrated Register Allocator (IRA) to generate a good code. If 28734 this macro is defined, it should return a floating point value 28735 based on REGNO. The cost of using REGNO for a pseudo will be 28736 increased by approximately the pseudo's usage frequency times the 28737 value returned by this macro. Not defining this macro is 28738 equivalent to having it always return `0.0'. 28739 28740 On most machines, it is not necessary to define this macro. 28741 28742 28743 File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 28744 28745 17.7.3 How Values Fit in Registers 28746 ---------------------------------- 28747 28748 This section discusses the macros that describe which kinds of values 28749 (specifically, which machine modes) each register can hold, and how many 28750 consecutive registers are needed for a given mode. 28751 28752 -- Macro: HARD_REGNO_NREGS (REGNO, MODE) 28753 A C expression for the number of consecutive hard registers, 28754 starting at register number REGNO, required to hold a value of mode 28755 MODE. This macro must never return zero, even if a register 28756 cannot hold the requested mode - indicate that with 28757 HARD_REGNO_MODE_OK and/or CANNOT_CHANGE_MODE_CLASS instead. 28758 28759 On a machine where all registers are exactly one word, a suitable 28760 definition of this macro is 28761 28762 #define HARD_REGNO_NREGS(REGNO, MODE) \ 28763 ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ 28764 / UNITS_PER_WORD) 28765 28766 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 28767 A C expression that is nonzero if a value of mode MODE, stored in 28768 memory, ends with padding that causes it to take up more space than 28769 in registers starting at register number REGNO (as determined by 28770 multiplying GCC's notion of the size of the register when 28771 containing this mode by the number of registers returned by 28772 `HARD_REGNO_NREGS'). By default this is zero. 28773 28774 For example, if a floating-point value is stored in three 32-bit 28775 registers but takes up 128 bits in memory, then this would be 28776 nonzero. 28777 28778 This macros only needs to be defined if there are cases where 28779 `subreg_get_info' would otherwise wrongly determine that a 28780 `subreg' can be represented by an offset to the register number, 28781 when in fact such a `subreg' would contain some of the padding not 28782 stored in registers and so not be representable. 28783 28784 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 28785 For values of REGNO and MODE for which 28786 `HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 28787 returning the greater number of registers required to hold the 28788 value including any padding. In the example above, the value 28789 would be four. 28790 28791 -- Macro: REGMODE_NATURAL_SIZE (MODE) 28792 Define this macro if the natural size of registers that hold values 28793 of mode MODE is not the word size. It is a C expression that 28794 should give the natural size in bytes for the specified mode. It 28795 is used by the register allocator to try to optimize its results. 28796 This happens for example on SPARC 64-bit where the natural size of 28797 floating-point registers is still 32-bit. 28798 28799 -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE) 28800 A C expression that is nonzero if it is permissible to store a 28801 value of mode MODE in hard register number REGNO (or in several 28802 registers starting with that one). For a machine where all 28803 registers are equivalent, a suitable definition is 28804 28805 #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 28806 28807 You need not include code to check for the numbers of fixed 28808 registers, because the allocation mechanism considers them to be 28809 always occupied. 28810 28811 On some machines, double-precision values must be kept in even/odd 28812 register pairs. You can implement that by defining this macro to 28813 reject odd register numbers for such modes. 28814 28815 The minimum requirement for a mode to be OK in a register is that 28816 the `movMODE' instruction pattern support moves between the 28817 register and other hard register in the same class and that moving 28818 a value into the register and back out not alter it. 28819 28820 Since the same instruction used to move `word_mode' will work for 28821 all narrower integer modes, it is not necessary on any machine for 28822 `HARD_REGNO_MODE_OK' to distinguish between these modes, provided 28823 you define patterns `movhi', etc., to take advantage of this. This 28824 is useful because of the interaction between `HARD_REGNO_MODE_OK' 28825 and `MODES_TIEABLE_P'; it is very desirable for all integer modes 28826 to be tieable. 28827 28828 Many machines have special registers for floating point arithmetic. 28829 Often people assume that floating point machine modes are allowed 28830 only in floating point registers. This is not true. Any 28831 registers that can hold integers can safely _hold_ a floating 28832 point machine mode, whether or not floating arithmetic can be done 28833 on it in those registers. Integer move instructions can be used 28834 to move the values. 28835 28836 On some machines, though, the converse is true: fixed-point machine 28837 modes may not go in floating registers. This is true if the 28838 floating registers normalize any value stored in them, because 28839 storing a non-floating value there would garble it. In this case, 28840 `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in 28841 floating registers. But if the floating registers do not 28842 automatically normalize, if you can store any bit pattern in one 28843 and retrieve it unchanged without a trap, then any machine mode 28844 may go in a floating register, so you can define this macro to say 28845 so. 28846 28847 The primary significance of special floating registers is rather 28848 that they are the registers acceptable in floating point arithmetic 28849 instructions. However, this is of no concern to 28850 `HARD_REGNO_MODE_OK'. You handle it by writing the proper 28851 constraints for those instructions. 28852 28853 On some machines, the floating registers are especially slow to 28854 access, so that it is better to store a value in a stack frame 28855 than in such a register if floating point arithmetic is not being 28856 done. As long as the floating registers are not in class 28857 `GENERAL_REGS', they will not be used unless some pattern's 28858 constraint asks for one. 28859 28860 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 28861 A C expression that is nonzero if it is OK to rename a hard 28862 register FROM to another hard register TO. 28863 28864 One common use of this macro is to prevent renaming of a register 28865 to another register that is not saved by a prologue in an interrupt 28866 handler. 28867 28868 The default is always nonzero. 28869 28870 -- Macro: MODES_TIEABLE_P (MODE1, MODE2) 28871 A C expression that is nonzero if a value of mode MODE1 is 28872 accessible in mode MODE2 without copying. 28873 28874 If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, 28875 MODE2)' are always the same for any R, then `MODES_TIEABLE_P 28876 (MODE1, MODE2)' should be nonzero. If they differ for any R, you 28877 should define this macro to return zero unless some other 28878 mechanism ensures the accessibility of the value in a narrower 28879 mode. 28880 28881 You should define this macro to return nonzero in as many cases as 28882 possible since doing so will allow GCC to perform better register 28883 allocation. 28884 28885 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 28886 This target hook should return `true' if it is OK to use a hard 28887 register REGNO as scratch reg in peephole2. 28888 28889 One common use of this macro is to prevent using of a register that 28890 is not saved by a prologue in an interrupt handler. 28891 28892 The default version of this hook always returns `true'. 28893 28894 -- Macro: AVOID_CCMODE_COPIES 28895 Define this macro if the compiler should avoid copies to/from 28896 `CCmode' registers. You should only define this macro if support 28897 for copying to/from `CCmode' is incomplete. 28898 28899 28900 File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 28901 28902 17.7.4 Handling Leaf Functions 28903 ------------------------------ 28904 28905 On some machines, a leaf function (i.e., one which makes no calls) can 28906 run more efficiently if it does not make its own register window. 28907 Often this means it is required to receive its arguments in the 28908 registers where they are passed by the caller, instead of the registers 28909 where they would normally arrive. 28910 28911 The special treatment for leaf functions generally applies only when 28912 other conditions are met; for example, often they may use only those 28913 registers for its own variables and temporaries. We use the term "leaf 28914 function" to mean a function that is suitable for this special 28915 handling, so that functions with no calls are not necessarily "leaf 28916 functions". 28917 28918 GCC assigns register numbers before it knows whether the function is 28919 suitable for leaf function treatment. So it needs to renumber the 28920 registers in order to output a leaf function. The following macros 28921 accomplish this. 28922 28923 -- Macro: LEAF_REGISTERS 28924 Name of a char vector, indexed by hard register number, which 28925 contains 1 for a register that is allowable in a candidate for leaf 28926 function treatment. 28927 28928 If leaf function treatment involves renumbering the registers, 28929 then the registers marked here should be the ones before 28930 renumbering--those that GCC would ordinarily allocate. The 28931 registers which will actually be used in the assembler code, after 28932 renumbering, should not be marked with 1 in this vector. 28933 28934 Define this macro only if the target machine offers a way to 28935 optimize the treatment of leaf functions. 28936 28937 -- Macro: LEAF_REG_REMAP (REGNO) 28938 A C expression whose value is the register number to which REGNO 28939 should be renumbered, when a function is treated as a leaf 28940 function. 28941 28942 If REGNO is a register number which should not appear in a leaf 28943 function before renumbering, then the expression should yield -1, 28944 which will cause the compiler to abort. 28945 28946 Define this macro only if the target machine offers a way to 28947 optimize the treatment of leaf functions, and registers need to be 28948 renumbered to do this. 28949 28950 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' must 28951 usually treat leaf functions specially. They can test the C variable 28952 `current_function_is_leaf' which is nonzero for leaf functions. 28953 `current_function_is_leaf' is set prior to local register allocation 28954 and is valid for the remaining compiler passes. They can also test the 28955 C variable `current_function_uses_only_leaf_regs' which is nonzero for 28956 leaf functions which only use leaf registers. 28957 `current_function_uses_only_leaf_regs' is valid after all passes that 28958 modify the instructions have been run and is only useful if 28959 `LEAF_REGISTERS' is defined. 28960 28961 28962 File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 28963 28964 17.7.5 Registers That Form a Stack 28965 ---------------------------------- 28966 28967 There are special features to handle computers where some of the 28968 "registers" form a stack. Stack registers are normally written by 28969 pushing onto the stack, and are numbered relative to the top of the 28970 stack. 28971 28972 Currently, GCC can only handle one group of stack-like registers, and 28973 they must be consecutively numbered. Furthermore, the existing support 28974 for stack-like registers is specific to the 80387 floating point 28975 coprocessor. If you have a new architecture that uses stack-like 28976 registers, you will need to do substantial work on `reg-stack.c' and 28977 write your machine description to cooperate with it, as well as 28978 defining these macros. 28979 28980 -- Macro: STACK_REGS 28981 Define this if the machine has any stack-like registers. 28982 28983 -- Macro: STACK_REG_COVER_CLASS 28984 This is a cover class containing the stack registers. Define this 28985 if the machine has any stack-like registers. 28986 28987 -- Macro: FIRST_STACK_REG 28988 The number of the first stack-like register. This one is the top 28989 of the stack. 28990 28991 -- Macro: LAST_STACK_REG 28992 The number of the last stack-like register. This one is the 28993 bottom of the stack. 28994 28995 28996 File: gccint.info, Node: Register Classes, Next: Old Constraints, Prev: Registers, Up: Target Macros 28997 28998 17.8 Register Classes 28999 ===================== 29000 29001 On many machines, the numbered registers are not all equivalent. For 29002 example, certain registers may not be allowed for indexed addressing; 29003 certain registers may not be allowed in some instructions. These 29004 machine restrictions are described to the compiler using "register 29005 classes". 29006 29007 You define a number of register classes, giving each one a name and 29008 saying which of the registers belong to it. Then you can specify 29009 register classes that are allowed as operands to particular instruction 29010 patterns. 29011 29012 In general, each register will belong to several classes. In fact, one 29013 class must be named `ALL_REGS' and contain all the registers. Another 29014 class must be named `NO_REGS' and contain no registers. Often the 29015 union of two classes will be another class; however, this is not 29016 required. 29017 29018 One of the classes must be named `GENERAL_REGS'. There is nothing 29019 terribly special about the name, but the operand constraint letters `r' 29020 and `g' specify this class. If `GENERAL_REGS' is the same as 29021 `ALL_REGS', just define it as a macro which expands to `ALL_REGS'. 29022 29023 Order the classes so that if class X is contained in class Y then X 29024 has a lower class number than Y. 29025 29026 The way classes other than `GENERAL_REGS' are specified in operand 29027 constraints is through machine-dependent operand constraint letters. 29028 You can define such letters to correspond to various classes, then use 29029 them in operand constraints. 29030 29031 You must define the narrowest register classes for allocatable 29032 registers, so that each class either has no subclasses, or that for 29033 some mode, the move cost between registers within the class is cheaper 29034 than moving a register in the class to or from memory (*note Costs::). 29035 29036 You should define a class for the union of two classes whenever some 29037 instruction allows both classes. For example, if an instruction allows 29038 either a floating point (coprocessor) register or a general register 29039 for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' 29040 which includes both of them. Otherwise you will get suboptimal code, 29041 or even internal compiler errors when reload cannot find a register in 29042 the class computed via `reg_class_subunion'. 29043 29044 You must also specify certain redundant information about the register 29045 classes: for each class, which classes contain it and which ones are 29046 contained in it; for each pair of classes, the largest class contained 29047 in their union. 29048 29049 When a value occupying several consecutive registers is expected in a 29050 certain class, all the registers used must belong to that class. 29051 Therefore, register classes cannot be used to enforce a requirement for 29052 a register pair to start with an even-numbered register. The way to 29053 specify this requirement is with `HARD_REGNO_MODE_OK'. 29054 29055 Register classes used for input-operands of bitwise-and or shift 29056 instructions have a special requirement: each such class must have, for 29057 each fixed-point machine mode, a subclass whose registers can transfer 29058 that mode to or from memory. For example, on some machines, the 29059 operations for single-byte values (`QImode') are limited to certain 29060 registers. When this is so, each register class that is used in a 29061 bitwise-and or shift instruction must have a subclass consisting of 29062 registers from which single-byte values can be loaded or stored. This 29063 is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to 29064 return. 29065 29066 -- Data type: enum reg_class 29067 An enumerated type that must be defined with all the register 29068 class names as enumerated values. `NO_REGS' must be first. 29069 `ALL_REGS' must be the last register class, followed by one more 29070 enumerated value, `LIM_REG_CLASSES', which is not a register class 29071 but rather tells how many classes there are. 29072 29073 Each register class has a number, which is the value of casting 29074 the class name to type `int'. The number serves as an index in 29075 many of the tables described below. 29076 29077 -- Macro: N_REG_CLASSES 29078 The number of distinct register classes, defined as follows: 29079 29080 #define N_REG_CLASSES (int) LIM_REG_CLASSES 29081 29082 -- Macro: REG_CLASS_NAMES 29083 An initializer containing the names of the register classes as C 29084 string constants. These names are used in writing some of the 29085 debugging dumps. 29086 29087 -- Macro: REG_CLASS_CONTENTS 29088 An initializer containing the contents of the register classes, as 29089 integers which are bit masks. The Nth integer specifies the 29090 contents of class N. The way the integer MASK is interpreted is 29091 that register R is in the class if `MASK & (1 << R)' is 1. 29092 29093 When the machine has more than 32 registers, an integer does not 29094 suffice. Then the integers are replaced by sub-initializers, 29095 braced groupings containing several integers. Each 29096 sub-initializer must be suitable as an initializer for the type 29097 `HARD_REG_SET' which is defined in `hard-reg-set.h'. In this 29098 situation, the first integer in each sub-initializer corresponds to 29099 registers 0 through 31, the second integer to registers 32 through 29100 63, and so on. 29101 29102 -- Macro: REGNO_REG_CLASS (REGNO) 29103 A C expression whose value is a register class containing hard 29104 register REGNO. In general there is more than one such class; 29105 choose a class which is "minimal", meaning that no smaller class 29106 also contains the register. 29107 29108 -- Macro: BASE_REG_CLASS 29109 A macro whose definition is the name of the class to which a valid 29110 base register must belong. A base register is one used in an 29111 address which is the register value plus a displacement. 29112 29113 -- Macro: MODE_BASE_REG_CLASS (MODE) 29114 This is a variation of the `BASE_REG_CLASS' macro which allows the 29115 selection of a base register in a mode dependent manner. If MODE 29116 is VOIDmode then it should return the same value as 29117 `BASE_REG_CLASS'. 29118 29119 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 29120 A C expression whose value is the register class to which a valid 29121 base register must belong in order to be used in a base plus index 29122 register address. You should define this macro if base plus index 29123 addresses have different requirements than other base register 29124 uses. 29125 29126 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, ADDRESS_SPACE, OUTER_CODE, 29127 INDEX_CODE) 29128 A C expression whose value is the register class to which a valid 29129 base register for a memory reference in mode MODE to address space 29130 ADDRESS_SPACE must belong. OUTER_CODE and INDEX_CODE define the 29131 context in which the base register occurs. OUTER_CODE is the code 29132 of the immediately enclosing expression (`MEM' for the top level 29133 of an address, `ADDRESS' for something that occurs in an 29134 `address_operand'). INDEX_CODE is the code of the corresponding 29135 index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise. 29136 29137 -- Macro: INDEX_REG_CLASS 29138 A macro whose definition is the name of the class to which a valid 29139 index register must belong. An index register is one used in an 29140 address where its value is either multiplied by a scale factor or 29141 added to another register (as well as added to a displacement). 29142 29143 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 29144 A C expression which is nonzero if register number NUM is suitable 29145 for use as a base register in operand addresses. 29146 29147 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 29148 A C expression that is just like `REGNO_OK_FOR_BASE_P', except that 29149 that expression may examine the mode of the memory reference in 29150 MODE. You should define this macro if the mode of the memory 29151 reference affects whether a register may be used as a base 29152 register. If you define this macro, the compiler will use it 29153 instead of `REGNO_OK_FOR_BASE_P'. The mode may be `VOIDmode' for 29154 addresses that appear outside a `MEM', i.e., as an 29155 `address_operand'. 29156 29157 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 29158 A C expression which is nonzero if register number NUM is suitable 29159 for use as a base register in base plus index operand addresses, 29160 accessing memory in mode MODE. It may be either a suitable hard 29161 register or a pseudo register that has been allocated such a hard 29162 register. You should define this macro if base plus index 29163 addresses have different requirements than other base register 29164 uses. 29165 29166 Use of this macro is deprecated; please use the more general 29167 `REGNO_MODE_CODE_OK_FOR_BASE_P'. 29168 29169 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE, 29170 OUTER_CODE, INDEX_CODE) 29171 A C expression which is nonzero if register number NUM is suitable 29172 for use as a base register in operand addresses, accessing memory 29173 in mode MODE in address space ADDRESS_SPACE. This is similar to 29174 `REGNO_MODE_OK_FOR_BASE_P', except that that expression may 29175 examine the context in which the register appears in the memory 29176 reference. OUTER_CODE is the code of the immediately enclosing 29177 expression (`MEM' if at the top level of the address, `ADDRESS' 29178 for something that occurs in an `address_operand'). INDEX_CODE is 29179 the code of the corresponding index expression if OUTER_CODE is 29180 `PLUS'; `SCRATCH' otherwise. The mode may be `VOIDmode' for 29181 addresses that appear outside a `MEM', i.e., as an 29182 `address_operand'. 29183 29184 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 29185 A C expression which is nonzero if register number NUM is suitable 29186 for use as an index register in operand addresses. It may be 29187 either a suitable hard register or a pseudo register that has been 29188 allocated such a hard register. 29189 29190 The difference between an index register and a base register is 29191 that the index register may be scaled. If an address involves the 29192 sum of two registers, neither one of them scaled, then either one 29193 may be labeled the "base" and the other the "index"; but whichever 29194 labeling is used must fit the machine's constraints of which 29195 registers may serve in each capacity. The compiler will try both 29196 labelings, looking for one that is valid, and will reload one or 29197 both registers only if neither labeling works. 29198 29199 -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t 29200 RCLASS) 29201 A target hook that places additional preference on the register 29202 class to use when it is necessary to rename a register in class 29203 RCLASS to another class, or perhaps NO_REGS, if no preferred 29204 register class is found or hook `preferred_rename_class' is not 29205 implemented. Sometimes returning a more restrictive class makes 29206 better code. For example, on ARM, thumb-2 instructions using 29207 `LO_REGS' may be smaller than instructions using `GENERIC_REGS'. 29208 By returning `LO_REGS' from `preferred_rename_class', code size 29209 can be reduced. 29210 29211 -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X, 29212 reg_class_t RCLASS) 29213 A target hook that places additional restrictions on the register 29214 class to use when it is necessary to copy value X into a register 29215 in class RCLASS. The value is a register class; perhaps RCLASS, 29216 or perhaps another, smaller class. 29217 29218 The default version of this hook always returns value of `rclass' 29219 argument. 29220 29221 Sometimes returning a more restrictive class makes better code. 29222 For example, on the 68000, when X is an integer constant that is 29223 in range for a `moveq' instruction, the value of this macro is 29224 always `DATA_REGS' as long as RCLASS includes the data registers. 29225 Requiring a data register guarantees that a `moveq' will be used. 29226 29227 One case where `TARGET_PREFERRED_RELOAD_CLASS' must not return 29228 RCLASS is if X is a legitimate constant which cannot be loaded 29229 into some register class. By returning `NO_REGS' you can force X 29230 into a memory location. For example, rs6000 can load immediate 29231 values into general-purpose registers, but does not have an 29232 instruction for loading an immediate value into a floating-point 29233 register, so `TARGET_PREFERRED_RELOAD_CLASS' returns `NO_REGS' when 29234 X is a floating-point constant. If the constant can't be loaded 29235 into any kind of register, code generation will be better if 29236 `TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 29237 instead of using `TARGET_PREFERRED_RELOAD_CLASS'. 29238 29239 If an insn has pseudos in it after register allocation, reload 29240 will go through the alternatives and call repeatedly 29241 `TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning 29242 `NO_REGS', in this case, makes reload add a `!' in front of the 29243 constraint: the x86 back-end uses this feature to discourage usage 29244 of 387 registers when math is done in the SSE registers (and vice 29245 versa). 29246 29247 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 29248 A C expression that places additional restrictions on the register 29249 class to use when it is necessary to copy value X into a register 29250 in class CLASS. The value is a register class; perhaps CLASS, or 29251 perhaps another, smaller class. On many machines, the following 29252 definition is safe: 29253 29254 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 29255 29256 Sometimes returning a more restrictive class makes better code. 29257 For example, on the 68000, when X is an integer constant that is 29258 in range for a `moveq' instruction, the value of this macro is 29259 always `DATA_REGS' as long as CLASS includes the data registers. 29260 Requiring a data register guarantees that a `moveq' will be used. 29261 29262 One case where `PREFERRED_RELOAD_CLASS' must not return CLASS is 29263 if X is a legitimate constant which cannot be loaded into some 29264 register class. By returning `NO_REGS' you can force X into a 29265 memory location. For example, rs6000 can load immediate values 29266 into general-purpose registers, but does not have an instruction 29267 for loading an immediate value into a floating-point register, so 29268 `PREFERRED_RELOAD_CLASS' returns `NO_REGS' when X is a 29269 floating-point constant. If the constant can't be loaded into any 29270 kind of register, code generation will be better if 29271 `TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 29272 instead of using `TARGET_PREFERRED_RELOAD_CLASS'. 29273 29274 If an insn has pseudos in it after register allocation, reload 29275 will go through the alternatives and call repeatedly 29276 `PREFERRED_RELOAD_CLASS' to find the best one. Returning 29277 `NO_REGS', in this case, makes reload add a `!' in front of the 29278 constraint: the x86 back-end uses this feature to discourage usage 29279 of 387 registers when math is done in the SSE registers (and vice 29280 versa). 29281 29282 -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx 29283 X, reg_class_t RCLASS) 29284 Like `TARGET_PREFERRED_RELOAD_CLASS', but for output reloads 29285 instead of input reloads. 29286 29287 The default version of this hook always returns value of `rclass' 29288 argument. 29289 29290 You can also use `TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to 29291 discourage reload from using some alternatives, like 29292 `TARGET_PREFERRED_RELOAD_CLASS'. 29293 29294 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 29295 A C expression that places additional restrictions on the register 29296 class to use when it is necessary to be able to hold a value of 29297 mode MODE in a reload register for which class CLASS would 29298 ordinarily be used. 29299 29300 Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when 29301 there are certain modes that simply can't go in certain reload 29302 classes. 29303 29304 The value is a register class; perhaps CLASS, or perhaps another, 29305 smaller class. 29306 29307 Don't define this macro unless the target machine has limitations 29308 which require the macro to do something nontrivial. 29309 29310 -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X, 29311 reg_class_t RELOAD_CLASS, enum machine_mode RELOAD_MODE, 29312 secondary_reload_info *SRI) 29313 Many machines have some registers that cannot be copied directly 29314 to or from memory or even from other types of registers. An 29315 example is the `MQ' register, which on most machines, can only be 29316 copied to or from general registers, but not memory. Below, we 29317 shall be using the term 'intermediate register' when a move 29318 operation cannot be performed directly, but has to be done by 29319 copying the source into the intermediate register first, and then 29320 copying the intermediate register to the destination. An 29321 intermediate register always has the same mode as source and 29322 destination. Since it holds the actual value being copied, reload 29323 might apply optimizations to re-use an intermediate register and 29324 eliding the copy from the source when it can determine that the 29325 intermediate register still holds the required value. 29326 29327 Another kind of secondary reload is required on some machines which 29328 allow copying all registers to and from memory, but require a 29329 scratch register for stores to some memory locations (e.g., those 29330 with symbolic address on the RT, and those with certain symbolic 29331 address on the SPARC when compiling PIC). Scratch registers need 29332 not have the same mode as the value being copied, and usually hold 29333 a different value than that being copied. Special patterns in the 29334 md file are needed to describe how the copy is performed with the 29335 help of the scratch register; these patterns also describe the 29336 number, register class(es) and mode(s) of the scratch register(s). 29337 29338 In some cases, both an intermediate and a scratch register are 29339 required. 29340 29341 For input reloads, this target hook is called with nonzero IN_P, 29342 and X is an rtx that needs to be copied to a register of class 29343 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 29344 is called with zero IN_P, and a register of class RELOAD_CLASS 29345 needs to be copied to rtx X in RELOAD_MODE. 29346 29347 If copying a register of RELOAD_CLASS from/to X requires an 29348 intermediate register, the hook `secondary_reload' should return 29349 the register class required for this intermediate register. If no 29350 intermediate register is required, it should return NO_REGS. If 29351 more than one intermediate register is required, describe the one 29352 that is closest in the copy chain to the reload register. 29353 29354 If scratch registers are needed, you also have to describe how to 29355 perform the copy from/to the reload register to/from this closest 29356 intermediate register. Or if no intermediate register is 29357 required, but still a scratch register is needed, describe the 29358 copy from/to the reload register to/from the reload operand X. 29359 29360 You do this by setting `sri->icode' to the instruction code of a 29361 pattern in the md file which performs the move. Operands 0 and 1 29362 are the output and input of this copy, respectively. Operands 29363 from operand 2 onward are for scratch operands. These scratch 29364 operands must have a mode, and a single-register-class output 29365 constraint. 29366 29367 When an intermediate register is used, the `secondary_reload' hook 29368 will be called again to determine how to copy the intermediate 29369 register to/from the reload operand X, so your hook must also have 29370 code to handle the register class of the intermediate operand. 29371 29372 X might be a pseudo-register or a `subreg' of a pseudo-register, 29373 which could either be in a hard register or in memory. Use 29374 `true_regnum' to find out; it will return -1 if the pseudo is in 29375 memory and the hard register number if it is in a register. 29376 29377 Scratch operands in memory (constraint `"=m"' / `"=&m"') are 29378 currently not supported. For the time being, you will have to 29379 continue to use `SECONDARY_MEMORY_NEEDED' for that purpose. 29380 29381 `copy_cost' also uses this target hook to find out how values are 29382 copied. If you want it to include some extra cost for the need to 29383 allocate (a) scratch register(s), set `sri->extra_cost' to the 29384 additional cost. Or if two dependent moves are supposed to have a 29385 lower cost than the sum of the individual moves due to expected 29386 fortuitous scheduling and/or special forwarding logic, you can set 29387 `sri->extra_cost' to a negative amount. 29388 29389 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 29390 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 29391 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 29392 These macros are obsolete, new ports should use the target hook 29393 `TARGET_SECONDARY_RELOAD' instead. 29394 29395 These are obsolete macros, replaced by the 29396 `TARGET_SECONDARY_RELOAD' target hook. Older ports still define 29397 these macros to indicate to the reload phase that it may need to 29398 allocate at least one register for a reload in addition to the 29399 register to contain the data. Specifically, if copying X to a 29400 register CLASS in MODE requires an intermediate register, you were 29401 supposed to define `SECONDARY_INPUT_RELOAD_CLASS' to return the 29402 largest register class all of whose registers can be used as 29403 intermediate registers or scratch registers. 29404 29405 If copying a register CLASS in MODE to X requires an intermediate 29406 or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 29407 to be defined be defined to return the largest register class 29408 required. If the requirements for input and output reloads were 29409 the same, the macro `SECONDARY_RELOAD_CLASS' should have been used 29410 instead of defining both macros identically. 29411 29412 The values returned by these macros are often `GENERAL_REGS'. 29413 Return `NO_REGS' if no spare register is needed; i.e., if X can be 29414 directly copied to or from a register of CLASS in MODE without 29415 requiring a scratch register. Do not define this macro if it 29416 would always return `NO_REGS'. 29417 29418 If a scratch register is required (either with or without an 29419 intermediate register), you were supposed to define patterns for 29420 `reload_inM' or `reload_outM', as required (*note Standard 29421 Names::. These patterns, which were normally implemented with a 29422 `define_expand', should be similar to the `movM' patterns, except 29423 that operand 2 is the scratch register. 29424 29425 These patterns need constraints for the reload register and scratch 29426 register that contain a single register class. If the original 29427 reload register (whose class is CLASS) can meet the constraint 29428 given in the pattern, the value returned by these macros is used 29429 for the class of the scratch register. Otherwise, two additional 29430 reload registers are required. Their classes are obtained from 29431 the constraints in the insn pattern. 29432 29433 X might be a pseudo-register or a `subreg' of a pseudo-register, 29434 which could either be in a hard register or in memory. Use 29435 `true_regnum' to find out; it will return -1 if the pseudo is in 29436 memory and the hard register number if it is in a register. 29437 29438 These macros should not be used in the case where a particular 29439 class of registers can only be copied to memory and not to another 29440 class of registers. In that case, secondary reload registers are 29441 not needed and would not be helpful. Instead, a stack location 29442 must be used to perform the copy and the `movM' pattern should use 29443 memory as an intermediate storage. This case often occurs between 29444 floating-point and general registers. 29445 29446 -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M) 29447 Certain machines have the property that some registers cannot be 29448 copied to some other registers without using memory. Define this 29449 macro on those machines to be a C expression that is nonzero if 29450 objects of mode M in registers of CLASS1 can only be copied to 29451 registers of class CLASS2 by storing a register of CLASS1 into 29452 memory and loading that memory location into a register of CLASS2. 29453 29454 Do not define this macro if its value would always be zero. 29455 29456 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 29457 Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler 29458 allocates a stack slot for a memory location needed for register 29459 copies. If this macro is defined, the compiler instead uses the 29460 memory location defined by this macro. 29461 29462 Do not define this macro if you do not define 29463 `SECONDARY_MEMORY_NEEDED'. 29464 29465 -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE) 29466 When the compiler needs a secondary memory location to copy 29467 between two registers of mode MODE, it normally allocates 29468 sufficient memory to hold a quantity of `BITS_PER_WORD' bits and 29469 performs the store and load operations in a mode that many bits 29470 wide and whose class is the same as that of MODE. 29471 29472 This is right thing to do on most machines because it ensures that 29473 all bits of the register are copied and prevents accesses to the 29474 registers in a narrower mode, which some machines prohibit for 29475 floating-point registers. 29476 29477 However, this default behavior is not correct on some machines, 29478 such as the DEC Alpha, that store short integers in floating-point 29479 registers differently than in integer registers. On those 29480 machines, the default widening will not work correctly and you 29481 must define this macro to suppress that widening in some cases. 29482 See the file `alpha.h' for details. 29483 29484 Do not define this macro if you do not define 29485 `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is 29486 `BITS_PER_WORD' bits wide is correct for your machine. 29487 29488 -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS) 29489 A target hook which returns `true' if pseudos that have been 29490 assigned to registers of class RCLASS would likely be spilled 29491 because registers of RCLASS are needed for spill registers. 29492 29493 The default version of this target hook returns `true' if RCLASS 29494 has exactly one register and `false' otherwise. On most machines, 29495 this default should be used. For generally register-starved 29496 machines, such as i386, or machines with right register 29497 constraints, such as SH, this hook can be used to avoid excessive 29498 spilling. 29499 29500 This hook is also used by some of the global intra-procedural code 29501 transformations to throtle code motion, to avoid increasing 29502 register pressure. 29503 29504 -- Target Hook: unsigned char TARGET_CLASS_MAX_NREGS (reg_class_t 29505 RCLASS, enum machine_mode MODE) 29506 A target hook returns the maximum number of consecutive registers 29507 of class RCLASS needed to hold a value of mode MODE. 29508 29509 This is closely related to the macro `HARD_REGNO_NREGS'. In fact, 29510 the value returned by `TARGET_CLASS_MAX_NREGS (RCLASS, MODE)' 29511 target hook should be the maximum value of `HARD_REGNO_NREGS 29512 (REGNO, MODE)' for all REGNO values in the class RCLASS. 29513 29514 This target hook helps control the handling of multiple-word values 29515 in the reload pass. 29516 29517 The default version of this target hook returns the size of MODE 29518 in words. 29519 29520 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 29521 A C expression for the maximum number of consecutive registers of 29522 class CLASS needed to hold a value of mode MODE. 29523 29524 This is closely related to the macro `HARD_REGNO_NREGS'. In fact, 29525 the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be 29526 the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all 29527 REGNO values in the class CLASS. 29528 29529 This macro helps control the handling of multiple-word values in 29530 the reload pass. 29531 29532 -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS) 29533 If defined, a C expression that returns nonzero for a CLASS for 29534 which a change from mode FROM to mode TO is invalid. 29535 29536 For the example, loading 32-bit integer or floating-point objects 29537 into floating-point registers on the Alpha extends them to 64 bits. 29538 Therefore loading a 64-bit object and then storing it as a 32-bit 29539 object does not store the low-order 32 bits, as would be the case 29540 for a normal register. Therefore, `alpha.h' defines 29541 `CANNOT_CHANGE_MODE_CLASS' as below: 29542 29543 #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ 29544 (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ 29545 ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0) 29546 29547 -- Target Hook: bool TARGET_LRA_P (void) 29548 A target hook which returns true if we use LRA instead of reload 29549 pass. It means that LRA was ported to the target. The default 29550 version of this target hook returns always false. 29551 29552 -- Target Hook: int TARGET_REGISTER_PRIORITY (int) 29553 A target hook which returns the register priority number to which 29554 the register HARD_REGNO belongs to. The bigger the number, the 29555 more preferable the hard register usage (when all other conditions 29556 are the same). This hook can be used to prefer some hard 29557 register over others in LRA. For example, some x86-64 register 29558 usage needs additional prefix which makes instructions longer. 29559 The hook can return lower priority number for such registers make 29560 them less favorable and as result making the generated code 29561 smaller. The default version of this target hook returns always 29562 zero. 29563 29564 -- Target Hook: bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void) 29565 A target hook which returns true if an address with the same 29566 structure can have different maximal legitimate displacement. 29567 For example, the displacement can depend on memory mode or on 29568 operand combinations in the insn. The default version of this 29569 target hook returns always false. 29570 29571 -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t, enum 29572 MACHINE_MODE) 29573 This hook defines a class of registers which could be used for 29574 spilling pseudos of the given mode and class, or `NO_REGS' if 29575 only memory should be used. Not defining this hook is equivalent 29576 to returning `NO_REGS' for all inputs. 29577 29578 29579 File: gccint.info, Node: Old Constraints, Next: Stack and Calling, Prev: Register Classes, Up: Target Macros 29580 29581 17.9 Obsolete Macros for Defining Constraints 29582 ============================================= 29583 29584 Machine-specific constraints can be defined with these macros instead 29585 of the machine description constructs described in *note Define 29586 Constraints::. This mechanism is obsolete. New ports should not use 29587 it; old ports should convert to the new mechanism. 29588 29589 -- Macro: CONSTRAINT_LEN (CHAR, STR) 29590 For the constraint at the start of STR, which starts with the 29591 letter C, return the length. This allows you to have register 29592 class / constant / extra constraints that are longer than a single 29593 letter; you don't need to define this macro if you can do with 29594 single-letter constraints only. The definition of this macro 29595 should use DEFAULT_CONSTRAINT_LEN for all the characters that you 29596 don't want to handle specially. There are some sanity checks in 29597 genoutput.c that check the constraint lengths for the md file, so 29598 you can also use this macro to help you while you are 29599 transitioning from a byzantine single-letter-constraint scheme: 29600 when you return a negative length for a constraint you want to 29601 re-use, genoutput will complain about every instance where it is 29602 used in the md file. 29603 29604 -- Macro: REG_CLASS_FROM_LETTER (CHAR) 29605 A C expression which defines the machine-dependent operand 29606 constraint letters for register classes. If CHAR is such a 29607 letter, the value should be the register class corresponding to 29608 it. Otherwise, the value should be `NO_REGS'. The register 29609 letter `r', corresponding to class `GENERAL_REGS', will not be 29610 passed to this macro; you do not need to handle it. 29611 29612 -- Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR) 29613 Like `REG_CLASS_FROM_LETTER', but you also get the constraint 29614 string passed in STR, so that you can use suffixes to distinguish 29615 between different variants. 29616 29617 -- Macro: CONST_OK_FOR_LETTER_P (VALUE, C) 29618 A C expression that defines the machine-dependent operand 29619 constraint letters (`I', `J', `K', ... `P') that specify 29620 particular ranges of integer values. If C is one of those 29621 letters, the expression should check that VALUE, an integer, is in 29622 the appropriate range and return 1 if so, 0 otherwise. If C is 29623 not one of those letters, the value should be 0 regardless of 29624 VALUE. 29625 29626 -- Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 29627 Like `CONST_OK_FOR_LETTER_P', but you also get the constraint 29628 string passed in STR, so that you can use suffixes to distinguish 29629 between different variants. 29630 29631 -- Macro: CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C) 29632 A C expression that defines the machine-dependent operand 29633 constraint letters that specify particular ranges of 29634 `const_double' values (`G' or `H'). 29635 29636 If C is one of those letters, the expression should check that 29637 VALUE, an RTX of code `const_double', is in the appropriate range 29638 and return 1 if so, 0 otherwise. If C is not one of those 29639 letters, the value should be 0 regardless of VALUE. 29640 29641 `const_double' is used for all floating-point constants and for 29642 `DImode' fixed-point constants. A given letter can accept either 29643 or both kinds of values. It can use `GET_MODE' to distinguish 29644 between these kinds. 29645 29646 -- Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 29647 Like `CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the 29648 constraint string passed in STR, so that you can use suffixes to 29649 distinguish between different variants. 29650 29651 -- Macro: EXTRA_CONSTRAINT (VALUE, C) 29652 A C expression that defines the optional machine-dependent 29653 constraint letters that can be used to segregate specific types of 29654 operands, usually memory references, for the target machine. Any 29655 letter that is not elsewhere defined and not matched by 29656 `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' may be used. 29657 Normally this macro will not be defined. 29658 29659 If it is required for a particular target machine, it should 29660 return 1 if VALUE corresponds to the operand type represented by 29661 the constraint letter C. If C is not defined as an extra 29662 constraint, the value returned should be 0 regardless of VALUE. 29663 29664 For example, on the ROMP, load instructions cannot have their 29665 output in r0 if the memory reference contains a symbolic address. 29666 Constraint letter `Q' is defined as representing a memory address 29667 that does _not_ contain a symbolic address. An alternative is 29668 specified with a `Q' constraint on the input and `r' on the 29669 output. The next alternative specifies `m' on the input and a 29670 register class that does not include r0 on the output. 29671 29672 -- Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR) 29673 Like `EXTRA_CONSTRAINT', but you also get the constraint string 29674 passed in STR, so that you can use suffixes to distinguish between 29675 different variants. 29676 29677 -- Macro: EXTRA_MEMORY_CONSTRAINT (C, STR) 29678 A C expression that defines the optional machine-dependent 29679 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT', 29680 that should be treated like memory constraints by the reload pass. 29681 29682 It should return 1 if the operand type represented by the 29683 constraint at the start of STR, the first letter of which is the 29684 letter C, comprises a subset of all memory references including 29685 all those whose address is simply a base register. This allows 29686 the reload pass to reload an operand, if it does not directly 29687 correspond to the operand type of C, by copying its address into a 29688 base register. 29689 29690 For example, on the S/390, some instructions do not accept 29691 arbitrary memory references, but only those that do not make use 29692 of an index register. The constraint letter `Q' is defined via 29693 `EXTRA_CONSTRAINT' as representing a memory address of this type. 29694 If the letter `Q' is marked as `EXTRA_MEMORY_CONSTRAINT', a `Q' 29695 constraint can handle any memory operand, because the reload pass 29696 knows it can be reloaded by copying the memory address into a base 29697 register if required. This is analogous to the way an `o' 29698 constraint can handle any memory operand. 29699 29700 -- Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR) 29701 A C expression that defines the optional machine-dependent 29702 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT' / 29703 `EXTRA_CONSTRAINT_STR', that should be treated like address 29704 constraints by the reload pass. 29705 29706 It should return 1 if the operand type represented by the 29707 constraint at the start of STR, which starts with the letter C, 29708 comprises a subset of all memory addresses including all those 29709 that consist of just a base register. This allows the reload pass 29710 to reload an operand, if it does not directly correspond to the 29711 operand type of STR, by copying it into a base register. 29712 29713 Any constraint marked as `EXTRA_ADDRESS_CONSTRAINT' can only be 29714 used with the `address_operand' predicate. It is treated 29715 analogously to the `p' constraint. 29716 29717 29718 File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Old Constraints, Up: Target Macros 29719 29720 17.10 Stack Layout and Calling Conventions 29721 ========================================== 29722 29723 This describes the stack layout and calling conventions. 29724 29725 * Menu: 29726 29727 * Frame Layout:: 29728 * Exception Handling:: 29729 * Stack Checking:: 29730 * Frame Registers:: 29731 * Elimination:: 29732 * Stack Arguments:: 29733 * Register Arguments:: 29734 * Scalar Return:: 29735 * Aggregate Return:: 29736 * Caller Saves:: 29737 * Function Entry:: 29738 * Profiling:: 29739 * Tail Calls:: 29740 * Stack Smashing Protection:: 29741 29742 29743 File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 29744 29745 17.10.1 Basic Stack Layout 29746 -------------------------- 29747 29748 Here is the basic stack layout. 29749 29750 -- Macro: STACK_GROWS_DOWNWARD 29751 Define this macro if pushing a word onto the stack moves the stack 29752 pointer to a smaller address. 29753 29754 When we say, "define this macro if ...", it means that the 29755 compiler checks this macro only with `#ifdef' so the precise 29756 definition used does not matter. 29757 29758 -- Macro: STACK_PUSH_CODE 29759 This macro defines the operation used when something is pushed on 29760 the stack. In RTL, a push operation will be `(set (mem 29761 (STACK_PUSH_CODE (reg sp))) ...)' 29762 29763 The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'. 29764 Which of these is correct depends on the stack direction and on 29765 whether the stack pointer points to the last item on the stack or 29766 whether it points to the space for the next item on the stack. 29767 29768 The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined, 29769 which is almost always right, and `PRE_INC' otherwise, which is 29770 often wrong. 29771 29772 -- Macro: FRAME_GROWS_DOWNWARD 29773 Define this macro to nonzero value if the addresses of local 29774 variable slots are at negative offsets from the frame pointer. 29775 29776 -- Macro: ARGS_GROW_DOWNWARD 29777 Define this macro if successive arguments to a function occupy 29778 decreasing addresses on the stack. 29779 29780 -- Macro: STARTING_FRAME_OFFSET 29781 Offset from the frame pointer to the first local variable slot to 29782 be allocated. 29783 29784 If `FRAME_GROWS_DOWNWARD', find the next slot's offset by 29785 subtracting the first slot's length from `STARTING_FRAME_OFFSET'. 29786 Otherwise, it is found by adding the length of the first slot to 29787 the value `STARTING_FRAME_OFFSET'. 29788 29789 -- Macro: STACK_ALIGNMENT_NEEDED 29790 Define to zero to disable final alignment of the stack during 29791 reload. The nonzero default for this macro is suitable for most 29792 ports. 29793 29794 On ports where `STARTING_FRAME_OFFSET' is nonzero or where there 29795 is a register save block following the local block that doesn't 29796 require alignment to `STACK_BOUNDARY', it may be beneficial to 29797 disable stack alignment and do it in the backend. 29798 29799 -- Macro: STACK_POINTER_OFFSET 29800 Offset from the stack pointer register to the first location at 29801 which outgoing arguments are placed. If not specified, the 29802 default value of zero is used. This is the proper value for most 29803 machines. 29804 29805 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 29806 the first location at which outgoing arguments are placed. 29807 29808 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 29809 Offset from the argument pointer register to the first argument's 29810 address. On some machines it may depend on the data type of the 29811 function. 29812 29813 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 29814 the first argument's address. 29815 29816 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 29817 Offset from the stack pointer register to an item dynamically 29818 allocated on the stack, e.g., by `alloca'. 29819 29820 The default value for this macro is `STACK_POINTER_OFFSET' plus the 29821 length of the outgoing arguments. The default is correct for most 29822 machines. See `function.c' for details. 29823 29824 -- Macro: INITIAL_FRAME_ADDRESS_RTX 29825 A C expression whose value is RTL representing the address of the 29826 initial stack frame. This address is passed to `RETURN_ADDR_RTX' 29827 and `DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 29828 reasonable default value will be used. Define this macro in order 29829 to make frame pointer elimination work in the presence of 29830 `__builtin_frame_address (count)' and `__builtin_return_address 29831 (count)' for `count' not equal to zero. 29832 29833 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 29834 A C expression whose value is RTL representing the address in a 29835 stack frame where the pointer to the caller's frame is stored. 29836 Assume that FRAMEADDR is an RTL expression for the address of the 29837 stack frame itself. 29838 29839 If you don't define this macro, the default is to return the value 29840 of FRAMEADDR--that is, the stack frame address is also the address 29841 of the stack word that points to the previous frame. 29842 29843 -- Macro: SETUP_FRAME_ADDRESSES 29844 If defined, a C expression that produces the machine-specific code 29845 to setup the stack so that arbitrary frames can be accessed. For 29846 example, on the SPARC, we must flush all of the register windows 29847 to the stack before we can access arbitrary stack frames. You 29848 will seldom need to define this macro. 29849 29850 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 29851 This target hook should return an rtx that is used to store the 29852 address of the current frame into the built in `setjmp' buffer. 29853 The default value, `virtual_stack_vars_rtx', is correct for most 29854 machines. One reason you may need to define this target hook is if 29855 `hard_frame_pointer_rtx' is the appropriate value on your machine. 29856 29857 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 29858 A C expression whose value is RTL representing the value of the 29859 frame address for the current frame. FRAMEADDR is the frame 29860 pointer of the current frame. This is used for 29861 __builtin_frame_address. You need only define this macro if the 29862 frame address is not the same as the frame pointer. Most machines 29863 do not need to define it. 29864 29865 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 29866 A C expression whose value is RTL representing the value of the 29867 return address for the frame COUNT steps up from the current 29868 frame, after the prologue. FRAMEADDR is the frame pointer of the 29869 COUNT frame, or the frame pointer of the COUNT - 1 frame if 29870 `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined. 29871 29872 The value of the expression must always be the correct address when 29873 COUNT is zero, but may be `NULL_RTX' if there is no way to 29874 determine the return address of other frames. 29875 29876 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 29877 Define this if the return address of a particular stack frame is 29878 accessed from the frame pointer of the previous stack frame. 29879 29880 -- Macro: INCOMING_RETURN_ADDR_RTX 29881 A C expression whose value is RTL representing the location of the 29882 incoming return address at the beginning of any function, before 29883 the prologue. This RTL is either a `REG', indicating that the 29884 return value is saved in `REG', or a `MEM' representing a location 29885 in the stack. 29886 29887 You only need to define this macro if you want to support call 29888 frame debugging information like that provided by DWARF 2. 29889 29890 If this RTL is a `REG', you should also define 29891 `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'. 29892 29893 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 29894 A C expression whose value is an integer giving a DWARF 2 column 29895 number that may be used as an alternative return column. The 29896 column must not correspond to any gcc hard register (that is, it 29897 must not be in the range of `DWARF_FRAME_REGNUM'). 29898 29899 This macro can be useful if `DWARF_FRAME_RETURN_COLUMN' is set to a 29900 general register, but an alternative column needs to be used for 29901 signal frames. Some targets have also used different frame return 29902 columns over time. 29903 29904 -- Macro: DWARF_ZERO_REG 29905 A C expression whose value is an integer giving a DWARF 2 register 29906 number that is considered to always have the value zero. This 29907 should only be defined if the target has an architected zero 29908 register, and someone decided it was a good idea to use that 29909 register number to terminate the stack backtrace. New ports 29910 should avoid this. 29911 29912 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 29913 *LABEL, rtx PATTERN, int INDEX) 29914 This target hook allows the backend to emit frame-related insns 29915 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 29916 debugging info engine will invoke it on insns of the form 29917 (set (reg) (unspec [...] UNSPEC_INDEX)) 29918 and 29919 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 29920 to let the backend emit the call frame instructions. LABEL is the 29921 CFI label attached to the insn, PATTERN is the pattern of the insn 29922 and INDEX is `UNSPEC_INDEX' or `UNSPECV_INDEX'. 29923 29924 -- Macro: INCOMING_FRAME_SP_OFFSET 29925 A C expression whose value is an integer giving the offset, in 29926 bytes, from the value of the stack pointer register to the top of 29927 the stack frame at the beginning of any function, before the 29928 prologue. The top of the frame is defined to be the value of the 29929 stack pointer in the previous frame, just before the call 29930 instruction. 29931 29932 You only need to define this macro if you want to support call 29933 frame debugging information like that provided by DWARF 2. 29934 29935 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 29936 A C expression whose value is an integer giving the offset, in 29937 bytes, from the argument pointer to the canonical frame address 29938 (cfa). The final value should coincide with that calculated by 29939 `INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 29940 during virtual register instantiation. 29941 29942 The default value for this macro is `FIRST_PARM_OFFSET (fundecl) + 29943 crtl->args.pretend_args_size', which is correct for most machines; 29944 in general, the arguments are found immediately before the stack 29945 frame. Note that this is not the case on some targets that save 29946 registers into the caller's frame, such as SPARC and rs6000, and 29947 so such targets need to define this macro. 29948 29949 You only need to define this macro if the default is incorrect, 29950 and you want to support call frame debugging information like that 29951 provided by DWARF 2. 29952 29953 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 29954 If defined, a C expression whose value is an integer giving the 29955 offset in bytes from the frame pointer to the canonical frame 29956 address (cfa). The final value should coincide with that 29957 calculated by `INCOMING_FRAME_SP_OFFSET'. 29958 29959 Normally the CFA is calculated as an offset from the argument 29960 pointer, via `ARG_POINTER_CFA_OFFSET', but if the argument pointer 29961 is variable due to the ABI, this may not be possible. If this 29962 macro is defined, it implies that the virtual register 29963 instantiation should be based on the frame pointer instead of the 29964 argument pointer. Only one of `FRAME_POINTER_CFA_OFFSET' and 29965 `ARG_POINTER_CFA_OFFSET' should be defined. 29966 29967 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 29968 If defined, a C expression whose value is an integer giving the 29969 offset in bytes from the canonical frame address (cfa) to the 29970 frame base used in DWARF 2 debug information. The default is 29971 zero. A different value may reduce the size of debug information 29972 on some ports. 29973 29974 29975 File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 29976 29977 17.10.2 Exception Handling Support 29978 ---------------------------------- 29979 29980 -- Macro: EH_RETURN_DATA_REGNO (N) 29981 A C expression whose value is the Nth register number used for 29982 data by exception handlers, or `INVALID_REGNUM' if fewer than N 29983 registers are usable. 29984 29985 The exception handling library routines communicate with the 29986 exception handlers via a set of agreed upon registers. Ideally 29987 these registers should be call-clobbered; it is possible to use 29988 call-saved registers, but may negatively impact code size. The 29989 target must support at least 2 data registers, but should define 4 29990 if there are enough free registers. 29991 29992 You must define this macro if you want to support call frame 29993 exception handling like that provided by DWARF 2. 29994 29995 -- Macro: EH_RETURN_STACKADJ_RTX 29996 A C expression whose value is RTL representing a location in which 29997 to store a stack adjustment to be applied before function return. 29998 This is used to unwind the stack to an exception handler's call 29999 frame. It will be assigned zero on code paths that return 30000 normally. 30001 30002 Typically this is a call-clobbered hard register that is otherwise 30003 untouched by the epilogue, but could also be a stack slot. 30004 30005 Do not define this macro if the stack pointer is saved and restored 30006 by the regular prolog and epilog code in the call frame itself; in 30007 this case, the exception handling library routines will update the 30008 stack location to be restored in place. Otherwise, you must define 30009 this macro if you want to support call frame exception handling 30010 like that provided by DWARF 2. 30011 30012 -- Macro: EH_RETURN_HANDLER_RTX 30013 A C expression whose value is RTL representing a location in which 30014 to store the address of an exception handler to which we should 30015 return. It will not be assigned on code paths that return 30016 normally. 30017 30018 Typically this is the location in the call frame at which the 30019 normal return address is stored. For targets that return by 30020 popping an address off the stack, this might be a memory address 30021 just below the _target_ call frame rather than inside the current 30022 call frame. If defined, `EH_RETURN_STACKADJ_RTX' will have already 30023 been assigned, so it may be used to calculate the location of the 30024 target call frame. 30025 30026 Some targets have more complex requirements than storing to an 30027 address calculable during initial code generation. In that case 30028 the `eh_return' instruction pattern should be used instead. 30029 30030 If you want to support call frame exception handling, you must 30031 define either this macro or the `eh_return' instruction pattern. 30032 30033 -- Macro: RETURN_ADDR_OFFSET 30034 If defined, an integer-valued C expression for which rtl will be 30035 generated to add it to the exception handler address before it is 30036 searched in the exception handling tables, and to subtract it 30037 again from the address before using it to return to the exception 30038 handler. 30039 30040 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 30041 This macro chooses the encoding of pointers embedded in the 30042 exception handling sections. If at all possible, this should be 30043 defined such that the exception handling section will not require 30044 dynamic relocations, and so may be read-only. 30045 30046 CODE is 0 for data, 1 for code labels, 2 for function pointers. 30047 GLOBAL is true if the symbol may be affected by dynamic 30048 relocations. The macro should return a combination of the 30049 `DW_EH_PE_*' defines as found in `dwarf2.h'. 30050 30051 If this macro is not defined, pointers will not be encoded but 30052 represented directly. 30053 30054 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 30055 ADDR, DONE) 30056 This macro allows the target to emit whatever special magic is 30057 required to represent the encoding chosen by 30058 `ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 30059 pc-relative and indirect encodings; this must be defined if the 30060 target uses text-relative or data-relative encodings. 30061 30062 This is a C statement that branches to DONE if the format was 30063 handled. ENCODING is the format chosen, SIZE is the number of 30064 bytes that the format occupies, ADDR is the `SYMBOL_REF' to be 30065 emitted. 30066 30067 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 30068 This macro allows the target to add CPU and operating system 30069 specific code to the call-frame unwinder for use when there is no 30070 unwind data available. The most common reason to implement this 30071 macro is to unwind through signal frames. 30072 30073 This macro is called from `uw_frame_state_for' in `unwind-dw2.c', 30074 `unwind-dw2-xtensa.c' and `unwind-ia64.c'. CONTEXT is an 30075 `_Unwind_Context'; FS is an `_Unwind_FrameState'. Examine 30076 `context->ra' for the address of the code being executed and 30077 `context->cfa' for the stack pointer value. If the frame can be 30078 decoded, the register save addresses should be updated in FS and 30079 the macro should evaluate to `_URC_NO_REASON'. If the frame 30080 cannot be decoded, the macro should evaluate to 30081 `_URC_END_OF_STACK'. 30082 30083 For proper signal handling in Java this macro is accompanied by 30084 `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h' 30085 headers. 30086 30087 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 30088 This macro allows the target to add operating system specific code 30089 to the call-frame unwinder to handle the IA-64 `.unwabi' unwinding 30090 directive, usually used for signal or interrupt frames. 30091 30092 This macro is called from `uw_update_context' in libgcc's 30093 `unwind-ia64.c'. CONTEXT is an `_Unwind_Context'; FS is an 30094 `_Unwind_FrameState'. Examine `fs->unwabi' for the abi and 30095 context in the `.unwabi' directive. If the `.unwabi' directive 30096 can be handled, the register save addresses should be updated in 30097 FS. 30098 30099 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 30100 A C expression that evaluates to true if the target requires unwind 30101 info to be given comdat linkage. Define it to be `1' if comdat 30102 linkage is necessary. The default is `0'. 30103 30104 30105 File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 30106 30107 17.10.3 Specifying How Stack Checking is Done 30108 --------------------------------------------- 30109 30110 GCC will check that stack references are within the boundaries of the 30111 stack, if the option `-fstack-check' is specified, in one of three ways: 30112 30113 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC 30114 will assume that you have arranged for full stack checking to be 30115 done at appropriate places in the configuration files. GCC will 30116 not do other special processing. 30117 30118 2. If `STACK_CHECK_BUILTIN' is zero and the value of the 30119 `STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume 30120 that you have arranged for static stack checking (checking of the 30121 static stack frame of functions) to be done at appropriate places 30122 in the configuration files. GCC will only emit code to do dynamic 30123 stack checking (checking on dynamic stack allocations) using the 30124 third approach below. 30125 30126 3. If neither of the above are true, GCC will generate code to 30127 periodically "probe" the stack pointer using the values of the 30128 macros defined below. 30129 30130 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 30131 defined, GCC will change its allocation strategy for large objects if 30132 the option `-fstack-check' is specified: they will always be allocated 30133 dynamically if their size exceeds `STACK_CHECK_MAX_VAR_SIZE' bytes. 30134 30135 -- Macro: STACK_CHECK_BUILTIN 30136 A nonzero value if stack checking is done by the configuration 30137 files in a machine-dependent manner. You should define this macro 30138 if stack checking is required by the ABI of your machine or if you 30139 would like to do stack checking in some more efficient way than 30140 the generic approach. The default value of this macro is zero. 30141 30142 -- Macro: STACK_CHECK_STATIC_BUILTIN 30143 A nonzero value if static stack checking is done by the 30144 configuration files in a machine-dependent manner. You should 30145 define this macro if you would like to do static stack checking in 30146 some more efficient way than the generic approach. The default 30147 value of this macro is zero. 30148 30149 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 30150 An integer specifying the interval at which GCC must generate 30151 stack probe instructions, defined as 2 raised to this integer. 30152 You will normally define this macro so that the interval be no 30153 larger than the size of the "guard pages" at the end of a stack 30154 area. The default value of 12 (4096-byte interval) is suitable 30155 for most systems. 30156 30157 -- Macro: STACK_CHECK_MOVING_SP 30158 An integer which is nonzero if GCC should move the stack pointer 30159 page by page when doing probes. This can be necessary on systems 30160 where the stack pointer contains the bottom address of the memory 30161 area accessible to the executing thread at any point in time. In 30162 this situation an alternate signal stack is required in order to 30163 be able to recover from a stack overflow. The default value of 30164 this macro is zero. 30165 30166 -- Macro: STACK_CHECK_PROTECT 30167 The number of bytes of stack needed to recover from a stack 30168 overflow, for languages where such a recovery is supported. The 30169 default value of 75 words with the `setjmp'/`longjmp'-based 30170 exception handling mechanism and 8192 bytes with other exception 30171 handling mechanisms should be adequate for most machines. 30172 30173 The following macros are relevant only if neither STACK_CHECK_BUILTIN 30174 nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 30175 in the opposite case. 30176 30177 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 30178 The maximum size of a stack frame, in bytes. GCC will generate 30179 probe instructions in non-leaf functions to ensure at least this 30180 many bytes of stack are available. If a stack frame is larger 30181 than this size, stack checking will not be reliable and GCC will 30182 issue a warning. The default is chosen so that GCC only generates 30183 one instruction on most systems. You should normally not change 30184 the default value of this macro. 30185 30186 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 30187 GCC uses this value to generate the above warning message. It 30188 represents the amount of fixed frame used by a function, not 30189 including space for any callee-saved registers, temporaries and 30190 user variables. You need only specify an upper bound for this 30191 amount and will normally use the default of four words. 30192 30193 -- Macro: STACK_CHECK_MAX_VAR_SIZE 30194 The maximum size, in bytes, of an object that GCC will place in the 30195 fixed area of the stack frame when the user specifies 30196 `-fstack-check'. GCC computed the default from the values of the 30197 above macros and you will normally not need to override that 30198 default. 30199 30200 30201 File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 30202 30203 17.10.4 Registers That Address the Stack Frame 30204 ---------------------------------------------- 30205 30206 This discusses registers that address the stack frame. 30207 30208 -- Macro: STACK_POINTER_REGNUM 30209 The register number of the stack pointer register, which must also 30210 be a fixed register according to `FIXED_REGISTERS'. On most 30211 machines, the hardware determines which register this is. 30212 30213 -- Macro: FRAME_POINTER_REGNUM 30214 The register number of the frame pointer register, which is used to 30215 access automatic variables in the stack frame. On some machines, 30216 the hardware determines which register this is. On other 30217 machines, you can choose any register you wish for this purpose. 30218 30219 -- Macro: HARD_FRAME_POINTER_REGNUM 30220 On some machines the offset between the frame pointer and starting 30221 offset of the automatic variables is not known until after register 30222 allocation has been done (for example, because the saved registers 30223 are between these two locations). On those machines, define 30224 `FRAME_POINTER_REGNUM' the number of a special, fixed register to 30225 be used internally until the offset is known, and define 30226 `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 30227 used for the frame pointer. 30228 30229 You should define this macro only in the very rare circumstances 30230 when it is not possible to calculate the offset between the frame 30231 pointer and the automatic variables until after register 30232 allocation has been completed. When this macro is defined, you 30233 must also indicate in your definition of `ELIMINABLE_REGS' how to 30234 eliminate `FRAME_POINTER_REGNUM' into either 30235 `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'. 30236 30237 Do not define this macro if it would be the same as 30238 `FRAME_POINTER_REGNUM'. 30239 30240 -- Macro: ARG_POINTER_REGNUM 30241 The register number of the arg pointer register, which is used to 30242 access the function's argument list. On some machines, this is 30243 the same as the frame pointer register. On some machines, the 30244 hardware determines which register this is. On other machines, 30245 you can choose any register you wish for this purpose. If this is 30246 not the same register as the frame pointer register, then you must 30247 mark it as a fixed register according to `FIXED_REGISTERS', or 30248 arrange to be able to eliminate it (*note Elimination::). 30249 30250 -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER 30251 Define this to a preprocessor constant that is nonzero if 30252 `hard_frame_pointer_rtx' and `frame_pointer_rtx' should be the 30253 same. The default definition is `(HARD_FRAME_POINTER_REGNUM == 30254 FRAME_POINTER_REGNUM)'; you only need to define this macro if that 30255 definition is not suitable for use in preprocessor conditionals. 30256 30257 -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER 30258 Define this to a preprocessor constant that is nonzero if 30259 `hard_frame_pointer_rtx' and `arg_pointer_rtx' should be the same. 30260 The default definition is `(HARD_FRAME_POINTER_REGNUM == 30261 ARG_POINTER_REGNUM)'; you only need to define this macro if that 30262 definition is not suitable for use in preprocessor conditionals. 30263 30264 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 30265 The register number of the return address pointer register, which 30266 is used to access the current function's return address from the 30267 stack. On some machines, the return address is not at a fixed 30268 offset from the frame pointer or stack pointer or argument 30269 pointer. This register can be defined to point to the return 30270 address on the stack, and then be converted by `ELIMINABLE_REGS' 30271 into either the frame pointer or stack pointer. 30272 30273 Do not define this macro unless there is no other way to get the 30274 return address from the stack. 30275 30276 -- Macro: STATIC_CHAIN_REGNUM 30277 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 30278 Register numbers used for passing a function's static chain 30279 pointer. If register windows are used, the register number as 30280 seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM', 30281 while the register number as seen by the calling function is 30282 `STATIC_CHAIN_REGNUM'. If these registers are the same, 30283 `STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 30284 30285 The static chain register need not be a fixed register. 30286 30287 If the static chain is passed in memory, these macros should not be 30288 defined; instead, the `TARGET_STATIC_CHAIN' hook should be used. 30289 30290 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL, bool 30291 INCOMING_P) 30292 This hook replaces the use of `STATIC_CHAIN_REGNUM' et al for 30293 targets that may use different static chain locations for different 30294 nested functions. This may be required if the target has function 30295 attributes that affect the calling conventions of the function and 30296 those calling conventions use different static chain locations. 30297 30298 The default version of this hook uses `STATIC_CHAIN_REGNUM' et al. 30299 30300 If the static chain is passed in memory, this hook should be used 30301 to provide rtx giving `mem' expressions that denote where they are 30302 stored. Often the `mem' expression as seen by the caller will be 30303 at an offset from the stack pointer and the `mem' expression as 30304 seen by the callee will be at an offset from the frame pointer. The 30305 variables `stack_pointer_rtx', `frame_pointer_rtx', and 30306 `arg_pointer_rtx' will have been initialized and should be used to 30307 refer to those items. 30308 30309 -- Macro: DWARF_FRAME_REGISTERS 30310 This macro specifies the maximum number of hard registers that can 30311 be saved in a call frame. This is used to size data structures 30312 used in DWARF2 exception handling. 30313 30314 Prior to GCC 3.0, this macro was needed in order to establish a 30315 stable exception handling ABI in the face of adding new hard 30316 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 30317 insulated from changes in the number of hard registers. 30318 Nevertheless, this macro can still be used to reduce the runtime 30319 memory requirements of the exception handling routines, which can 30320 be substantial if the ISA contains a lot of registers that are not 30321 call-saved. 30322 30323 If this macro is not defined, it defaults to 30324 `FIRST_PSEUDO_REGISTER'. 30325 30326 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 30327 This macro is similar to `DWARF_FRAME_REGISTERS', but is provided 30328 for backward compatibility in pre GCC 3.0 compiled code. 30329 30330 If this macro is not defined, it defaults to 30331 `DWARF_FRAME_REGISTERS'. 30332 30333 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 30334 Define this macro if the target's representation for dwarf 30335 registers is different than the internal representation for unwind 30336 column. Given a dwarf register, this macro should return the 30337 internal unwind column number to use instead. 30338 30339 See the PowerPC's SPE target for an example. 30340 30341 -- Macro: DWARF_FRAME_REGNUM (REGNO) 30342 Define this macro if the target's representation for dwarf 30343 registers used in .eh_frame or .debug_frame is different from that 30344 used in other debug info sections. Given a GCC hard register 30345 number, this macro should return the .eh_frame register number. 30346 The default is `DBX_REGISTER_NUMBER (REGNO)'. 30347 30348 30349 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 30350 Define this macro to map register numbers held in the call frame 30351 info that GCC has collected using `DWARF_FRAME_REGNUM' to those 30352 that should be output in .debug_frame (`FOR_EH' is zero) and 30353 .eh_frame (`FOR_EH' is nonzero). The default is to return `REGNO'. 30354 30355 30356 -- Macro: REG_VALUE_IN_UNWIND_CONTEXT 30357 Define this macro if the target stores register values as 30358 `_Unwind_Word' type in unwind context. It should be defined if 30359 target register size is larger than the size of `void *'. The 30360 default is to store register values as `void *' type. 30361 30362 30363 -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT 30364 Define this macro to be 1 if the target always uses extended unwind 30365 context with version, args_size and by_value fields. If it is 30366 undefined, it will be defined to 1 when 30367 `REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise. 30368 30369 30370 30371 File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 30372 30373 17.10.5 Eliminating Frame Pointer and Arg Pointer 30374 ------------------------------------------------- 30375 30376 This is about eliminating the frame pointer and arg pointer. 30377 30378 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 30379 This target hook should return `true' if a function must have and 30380 use a frame pointer. This target hook is called in the reload 30381 pass. If its return value is `true' the function will have a 30382 frame pointer. 30383 30384 This target hook can in principle examine the current function and 30385 decide according to the facts, but on most machines the constant 30386 `false' or the constant `true' suffices. Use `false' when the 30387 machine allows code to be generated with no frame pointer, and 30388 doing so saves some time or space. Use `true' when there is no 30389 possible advantage to avoiding a frame pointer. 30390 30391 In certain cases, the compiler does not know how to produce valid 30392 code without a frame pointer. The compiler recognizes those cases 30393 and automatically gives the function a frame pointer regardless of 30394 what `TARGET_FRAME_POINTER_REQUIRED' returns. You don't need to 30395 worry about them. 30396 30397 In a function that does not require a frame pointer, the frame 30398 pointer register can be allocated for ordinary usage, unless you 30399 mark it as a fixed register. See `FIXED_REGISTERS' for more 30400 information. 30401 30402 Default return value is `false'. 30403 30404 -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR) 30405 A C statement to store in the variable DEPTH-VAR the difference 30406 between the frame pointer and the stack pointer values immediately 30407 after the function prologue. The value would be computed from 30408 information such as the result of `get_frame_size ()' and the 30409 tables of registers `regs_ever_live' and `call_used_regs'. 30410 30411 If `ELIMINABLE_REGS' is defined, this macro will be not be used and 30412 need not be defined. Otherwise, it must be defined even if 30413 `TARGET_FRAME_POINTER_REQUIRED' always returns true; in that case, 30414 you may set DEPTH-VAR to anything. 30415 30416 -- Macro: ELIMINABLE_REGS 30417 If defined, this macro specifies a table of register pairs used to 30418 eliminate unneeded registers that point into the stack frame. If 30419 it is not defined, the only elimination attempted by the compiler 30420 is to replace references to the frame pointer with references to 30421 the stack pointer. 30422 30423 The definition of this macro is a list of structure 30424 initializations, each of which specifies an original and 30425 replacement register. 30426 30427 On some machines, the position of the argument pointer is not 30428 known until the compilation is completed. In such a case, a 30429 separate hard register must be used for the argument pointer. 30430 This register can be eliminated by replacing it with either the 30431 frame pointer or the argument pointer, depending on whether or not 30432 the frame pointer has been eliminated. 30433 30434 In this case, you might specify: 30435 #define ELIMINABLE_REGS \ 30436 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 30437 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 30438 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 30439 30440 Note that the elimination of the argument pointer with the stack 30441 pointer is specified first since that is the preferred elimination. 30442 30443 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 30444 int TO_REG) 30445 This target hook should returns `true' if the compiler is allowed 30446 to try to replace register number FROM_REG with register number 30447 TO_REG. This target hook need only be defined if `ELIMINABLE_REGS' 30448 is defined, and will usually be `true', since most of the cases 30449 preventing register elimination are things that the compiler 30450 already knows about. 30451 30452 Default return value is `true'. 30453 30454 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 30455 This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It 30456 specifies the initial difference between the specified pair of 30457 registers. This macro must be defined if `ELIMINABLE_REGS' is 30458 defined. 30459 30460 30461 File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 30462 30463 17.10.6 Passing Function Arguments on the Stack 30464 ----------------------------------------------- 30465 30466 The macros in this section control how arguments are passed on the 30467 stack. See the following section for other macros that control passing 30468 certain arguments in registers. 30469 30470 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 30471 This target hook returns `true' if an argument declared in a 30472 prototype as an integral type smaller than `int' should actually be 30473 passed as an `int'. In addition to avoiding errors in certain 30474 cases of mismatch, it also makes for better code on certain 30475 machines. The default is to not promote prototypes. 30476 30477 -- Macro: PUSH_ARGS 30478 A C expression. If nonzero, push insns will be used to pass 30479 outgoing arguments. If the target machine does not have a push 30480 instruction, set it to zero. That directs GCC to use an alternate 30481 strategy: to allocate the entire argument block and then store the 30482 arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING' 30483 must be defined too. 30484 30485 -- Macro: PUSH_ARGS_REVERSED 30486 A C expression. If nonzero, function arguments will be evaluated 30487 from last to first, rather than from first to last. If this macro 30488 is not defined, it defaults to `PUSH_ARGS' on targets where the 30489 stack and args grow in opposite directions, and 0 otherwise. 30490 30491 -- Macro: PUSH_ROUNDING (NPUSHED) 30492 A C expression that is the number of bytes actually pushed onto the 30493 stack when an instruction attempts to push NPUSHED bytes. 30494 30495 On some machines, the definition 30496 30497 #define PUSH_ROUNDING(BYTES) (BYTES) 30498 30499 will suffice. But on other machines, instructions that appear to 30500 push one byte actually push two bytes in an attempt to maintain 30501 alignment. Then the definition should be 30502 30503 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 30504 30505 If the value of this macro has a type, it should be an unsigned 30506 type. 30507 30508 -- Macro: ACCUMULATE_OUTGOING_ARGS 30509 A C expression. If nonzero, the maximum amount of space required 30510 for outgoing arguments will be computed and placed into 30511 `crtl->outgoing_args_size'. No space will be pushed onto the 30512 stack for each call; instead, the function prologue should 30513 increase the stack frame size by this amount. 30514 30515 Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not 30516 proper. 30517 30518 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 30519 Define this macro if functions should assume that stack space has 30520 been allocated for arguments even when their values are passed in 30521 registers. 30522 30523 The value of this macro is the size, in bytes, of the area 30524 reserved for arguments passed in registers for the function 30525 represented by FNDECL, which can be zero if GCC is calling a 30526 library function. The argument FNDECL can be the FUNCTION_DECL, 30527 or the type itself of the function. 30528 30529 This space can be allocated by the caller, or be a part of the 30530 machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says 30531 which. 30532 30533 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 30534 Define this to a nonzero value if it is the responsibility of the 30535 caller to allocate the area reserved for arguments passed in 30536 registers when calling a function of FNTYPE. FNTYPE may be NULL 30537 if the function called is a library function. 30538 30539 If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 30540 whether the space for these arguments counts in the value of 30541 `crtl->outgoing_args_size'. 30542 30543 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 30544 Define this macro if `REG_PARM_STACK_SPACE' is defined, but the 30545 stack parameters don't skip the area specified by it. 30546 30547 Normally, when a parameter is not passed in registers, it is 30548 placed on the stack beyond the `REG_PARM_STACK_SPACE' area. 30549 Defining this macro suppresses this behavior and causes the 30550 parameter to be passed on the stack in its natural location. 30551 30552 -- Target Hook: int TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree 30553 FUNTYPE, int SIZE) 30554 This target hook returns the number of bytes of its own arguments 30555 that a function pops on returning, or 0 if the function pops no 30556 arguments and the caller must therefore pop them all after the 30557 function returns. 30558 30559 FUNDECL is a C variable whose value is a tree node that describes 30560 the function in question. Normally it is a node of type 30561 `FUNCTION_DECL' that describes the declaration of the function. 30562 From this you can obtain the `DECL_ATTRIBUTES' of the function. 30563 30564 FUNTYPE is a C variable whose value is a tree node that describes 30565 the function in question. Normally it is a node of type 30566 `FUNCTION_TYPE' that describes the data type of the function. 30567 From this it is possible to obtain the data types of the value and 30568 arguments (if known). 30569 30570 When a call to a library function is being considered, FUNDECL 30571 will contain an identifier node for the library function. Thus, if 30572 you need to distinguish among various library functions, you can 30573 do so by their names. Note that "library function" in this 30574 context means a function used to perform arithmetic, whose name is 30575 known specially in the compiler and was not mentioned in the C 30576 code being compiled. 30577 30578 SIZE is the number of bytes of arguments passed on the stack. If 30579 a variable number of bytes is passed, it is zero, and argument 30580 popping will always be the responsibility of the calling function. 30581 30582 On the VAX, all functions always pop their arguments, so the 30583 definition of this macro is SIZE. On the 68000, using the standard 30584 calling convention, no functions pop their arguments, so the value 30585 of the macro is always 0 in this case. But an alternative calling 30586 convention is available in which functions that take a fixed 30587 number of arguments pop them but other functions (such as 30588 `printf') pop nothing (the caller pops all). When this convention 30589 is in use, FUNTYPE is examined to determine whether a function 30590 takes a fixed number of arguments. 30591 30592 -- Macro: CALL_POPS_ARGS (CUM) 30593 A C expression that should indicate the number of bytes a call 30594 sequence pops off the stack. It is added to the value of 30595 `RETURN_POPS_ARGS' when compiling a function call. 30596 30597 CUM is the variable in which all arguments to the called function 30598 have been accumulated. 30599 30600 On certain architectures, such as the SH5, a call trampoline is 30601 used that pops certain registers off the stack, depending on the 30602 arguments that have been passed to the function. Since this is a 30603 property of the call site, not of the called function, 30604 `RETURN_POPS_ARGS' is not appropriate. 30605 30606 30607 File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 30608 30609 17.10.7 Passing Arguments in Registers 30610 -------------------------------------- 30611 30612 This section describes the macros which let you control how various 30613 types of arguments are passed in registers or how they are arranged in 30614 the stack. 30615 30616 -- Target Hook: rtx TARGET_FUNCTION_ARG (cumulative_args_t CA, enum 30617 machine_mode MODE, const_tree TYPE, bool NAMED) 30618 Return an RTX indicating whether a function argument is passed in a 30619 register and if so, which register. 30620 30621 The arguments are CA, which summarizes all the previous arguments; 30622 MODE, the machine mode of the argument; TYPE, the data type of the 30623 argument as a tree node or 0 if that is not known (which happens 30624 for C support library functions); and NAMED, which is `true' for 30625 an ordinary argument and `false' for nameless arguments that 30626 correspond to `...' in the called function's prototype. TYPE can 30627 be an incomplete type if a syntax error has previously occurred. 30628 30629 The return value is usually either a `reg' RTX for the hard 30630 register in which to pass the argument, or zero to pass the 30631 argument on the stack. 30632 30633 The value of the expression can also be a `parallel' RTX. This is 30634 used when an argument is passed in multiple locations. The mode 30635 of the `parallel' should be the mode of the entire argument. The 30636 `parallel' holds any number of `expr_list' pairs; each one 30637 describes where part of the argument is passed. In each 30638 `expr_list' the first operand must be a `reg' RTX for the hard 30639 register in which to pass this part of the argument, and the mode 30640 of the register RTX indicates how large this part of the argument 30641 is. The second operand of the `expr_list' is a `const_int' which 30642 gives the offset in bytes into the entire argument of where this 30643 part starts. As a special exception the first `expr_list' in the 30644 `parallel' RTX may have a first operand of zero. This indicates 30645 that the entire argument is also stored on the stack. 30646 30647 The last time this hook is called, it is called with `MODE == 30648 VOIDmode', and its result is passed to the `call' or `call_value' 30649 pattern as operands 2 and 3 respectively. 30650 30651 The usual way to make the ISO library `stdarg.h' work on a machine 30652 where some arguments are usually passed in registers, is to cause 30653 nameless arguments to be passed on the stack instead. This is 30654 done by making `TARGET_FUNCTION_ARG' return 0 whenever NAMED is 30655 `false'. 30656 30657 You may use the hook `targetm.calls.must_pass_in_stack' in the 30658 definition of this macro to determine if this argument is of a 30659 type that must be passed in the stack. If `REG_PARM_STACK_SPACE' 30660 is not defined and `TARGET_FUNCTION_ARG' returns nonzero for such 30661 an argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is 30662 defined, the argument will be computed in the stack and then 30663 loaded into a register. 30664 30665 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (enum machine_mode 30666 MODE, const_tree TYPE) 30667 This target hook should return `true' if we should not pass TYPE 30668 solely in registers. The file `expr.h' defines a definition that 30669 is usually appropriate, refer to `expr.h' for additional 30670 documentation. 30671 30672 -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t 30673 CA, enum machine_mode MODE, const_tree TYPE, bool NAMED) 30674 Define this hook if the target machine has "register windows", so 30675 that the register in which a function sees an arguments is not 30676 necessarily the same as the one in which the caller passed the 30677 argument. 30678 30679 For such machines, `TARGET_FUNCTION_ARG' computes the register in 30680 which the caller passes the value, and 30681 `TARGET_FUNCTION_INCOMING_ARG' should be defined in a similar 30682 fashion to tell the function being called where the arguments will 30683 arrive. 30684 30685 If `TARGET_FUNCTION_INCOMING_ARG' is not defined, 30686 `TARGET_FUNCTION_ARG' serves both purposes. 30687 30688 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (cumulative_args_t CUM, 30689 enum machine_mode MODE, tree TYPE, bool NAMED) 30690 This target hook returns the number of bytes at the beginning of an 30691 argument that must be put in registers. The value must be zero for 30692 arguments that are passed entirely in registers or that are 30693 entirely pushed on the stack. 30694 30695 On some machines, certain arguments must be passed partially in 30696 registers and partially in memory. On these machines, typically 30697 the first few words of arguments are passed in registers, and the 30698 rest on the stack. If a multi-word argument (a `double' or a 30699 structure) crosses that boundary, its first few words must be 30700 passed in registers and the rest must be pushed. This macro tells 30701 the compiler when this occurs, and how many bytes should go in 30702 registers. 30703 30704 `TARGET_FUNCTION_ARG' for these arguments should return the first 30705 register to be used by the caller for this argument; likewise 30706 `TARGET_FUNCTION_INCOMING_ARG', for the called function. 30707 30708 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM, 30709 enum machine_mode MODE, const_tree TYPE, bool NAMED) 30710 This target hook should return `true' if an argument at the 30711 position indicated by CUM should be passed by reference. This 30712 predicate is queried after target independent reasons for being 30713 passed by reference, such as `TREE_ADDRESSABLE (type)'. 30714 30715 If the hook returns true, a copy of that argument is made in 30716 memory and a pointer to the argument is passed instead of the 30717 argument itself. The pointer is passed in whatever way is 30718 appropriate for passing a pointer to that type. 30719 30720 -- Target Hook: bool TARGET_CALLEE_COPIES (cumulative_args_t CUM, enum 30721 machine_mode MODE, const_tree TYPE, bool NAMED) 30722 The function argument described by the parameters to this hook is 30723 known to be passed by reference. The hook should return true if 30724 the function argument should be copied by the callee instead of 30725 copied by the caller. 30726 30727 For any argument for which the hook returns true, if it can be 30728 determined that the argument is not modified, then a copy need not 30729 be generated. 30730 30731 The default version of this hook always returns false. 30732 30733 -- Macro: CUMULATIVE_ARGS 30734 A C type for declaring a variable that is used as the first 30735 argument of `TARGET_FUNCTION_ARG' and other related values. For 30736 some target machines, the type `int' suffices and can hold the 30737 number of bytes of argument so far. 30738 30739 There is no need to record in `CUMULATIVE_ARGS' anything about the 30740 arguments that have been passed on the stack. The compiler has 30741 other variables to keep track of that. For target machines on 30742 which all arguments are passed on the stack, there is no need to 30743 store anything in `CUMULATIVE_ARGS'; however, the data structure 30744 must exist and should not be empty, so use `int'. 30745 30746 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 30747 If defined, this macro is called before generating any code for a 30748 function, but after the CFUN descriptor for the function has been 30749 created. The back end may use this macro to update CFUN to 30750 reflect an ABI other than that which would normally be used by 30751 default. If the compiler is generating code for a 30752 compiler-generated function, FNDECL may be `NULL'. 30753 30754 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 30755 N_NAMED_ARGS) 30756 A C statement (sans semicolon) for initializing the variable CUM 30757 for the state at the beginning of the argument list. The variable 30758 has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 30759 for the data type of the function which will receive the args, or 30760 0 if the args are to a compiler support library function. For 30761 direct calls that are not libcalls, FNDECL contain the declaration 30762 node of the function. FNDECL is also set when 30763 `INIT_CUMULATIVE_ARGS' is used to find arguments for the function 30764 being compiled. N_NAMED_ARGS is set to the number of named 30765 arguments, including a structure return address if it is passed as 30766 a parameter, when making a call. When processing incoming 30767 arguments, N_NAMED_ARGS is set to -1. 30768 30769 When processing a call to a compiler support library function, 30770 LIBNAME identifies which one. It is a `symbol_ref' rtx which 30771 contains the name of the function, as a string. LIBNAME is 0 when 30772 an ordinary C function call is being processed. Thus, each time 30773 this macro is called, either LIBNAME or FNTYPE is nonzero, but 30774 never both of them at once. 30775 30776 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 30777 Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, 30778 it gets a `MODE' argument instead of FNTYPE, that would be `NULL'. 30779 INDIRECT would always be zero, too. If this macro is not defined, 30780 `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 30781 30782 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 30783 Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 30784 finding the arguments for the function being compiled. If this 30785 macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead. 30786 30787 The value passed for LIBNAME is always 0, since library routines 30788 with special calling conventions are never compiled with GCC. The 30789 argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'. 30790 30791 -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t 30792 CA, enum machine_mode MODE, const_tree TYPE, bool NAMED) 30793 This hook updates the summarizer variable pointed to by CA to 30794 advance past an argument in the argument list. The values MODE, 30795 TYPE and NAMED describe that argument. Once this is done, the 30796 variable CUM is suitable for analyzing the _following_ argument 30797 with `TARGET_FUNCTION_ARG', etc. 30798 30799 This hook need not do anything if the argument in question was 30800 passed on the stack. The compiler knows how to track the amount 30801 of stack space used for arguments without any special help. 30802 30803 -- Macro: FUNCTION_ARG_OFFSET (MODE, TYPE) 30804 If defined, a C expression that is the number of bytes to add to 30805 the offset of the argument passed in memory. This is needed for 30806 the SPU, which passes `char' and `short' arguments in the preferred 30807 slot that is in the middle of the quad word instead of starting at 30808 the top. 30809 30810 -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE) 30811 If defined, a C expression which determines whether, and in which 30812 direction, to pad out an argument with extra space. The value 30813 should be of type `enum direction': either `upward' to pad above 30814 the argument, `downward' to pad below, or `none' to inhibit 30815 padding. 30816 30817 The _amount_ of padding is not controlled by this macro, but by the 30818 target hook `TARGET_FUNCTION_ARG_ROUND_BOUNDARY'. It is always 30819 just enough to reach the next multiple of that boundary. 30820 30821 This macro has a default definition which is right for most 30822 systems. For little-endian machines, the default is to pad 30823 upward. For big-endian machines, the default is to pad downward 30824 for an argument of constant size shorter than an `int', and upward 30825 otherwise. 30826 30827 -- Macro: PAD_VARARGS_DOWN 30828 If defined, a C expression which determines whether the default 30829 implementation of va_arg will attempt to pad down before reading 30830 the next argument, if that argument is smaller than its aligned 30831 space as controlled by `PARM_BOUNDARY'. If this macro is not 30832 defined, all such arguments are padded down if `BYTES_BIG_ENDIAN' 30833 is true. 30834 30835 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 30836 Specify padding for the last element of a block move between 30837 registers and memory. FIRST is nonzero if this is the only 30838 element. Defining this macro allows better control of register 30839 function parameters on big-endian machines, without using 30840 `PARALLEL' rtl. In particular, `MUST_PASS_IN_STACK' need not test 30841 padding and mode of types in registers, as there is no longer a 30842 "wrong" part of a register; For example, a three byte aggregate 30843 may be passed in the high part of a register if so required. 30844 30845 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (enum 30846 machine_mode MODE, const_tree TYPE) 30847 This hook returns the alignment boundary, in bits, of an argument 30848 with the specified mode and type. The default hook returns 30849 `PARM_BOUNDARY' for all arguments. 30850 30851 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY (enum 30852 machine_mode MODE, const_tree TYPE) 30853 Normally, the size of an argument is rounded up to `PARM_BOUNDARY', 30854 which is the default value for this hook. You can define this 30855 hook to return a different value if an argument size must be 30856 rounded to a larger value. 30857 30858 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 30859 A C expression that is nonzero if REGNO is the number of a hard 30860 register in which function arguments are sometimes passed. This 30861 does _not_ include implicit arguments such as the static chain and 30862 the structure-value address. On many machines, no registers can be 30863 used for this purpose since all function arguments are pushed on 30864 the stack. 30865 30866 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 30867 This hook should return true if parameter of type TYPE are passed 30868 as two scalar parameters. By default, GCC will attempt to pack 30869 complex arguments into the target's word size. Some ABIs require 30870 complex arguments to be split and treated as their individual 30871 components. For example, on AIX64, complex floats should be 30872 passed in a pair of floating point registers, even though a 30873 complex float would fit in one 64-bit floating point register. 30874 30875 The default value of this hook is `NULL', which is treated as 30876 always false. 30877 30878 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 30879 This hook returns a type node for `va_list' for the target. The 30880 default version of the hook returns `void*'. 30881 30882 -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char 30883 **PNAME, tree *PTREE) 30884 This target hook is used in function `c_common_nodes_and_builtins' 30885 to iterate through the target specific builtin types for va_list. 30886 The variable IDX is used as iterator. PNAME has to be a pointer to 30887 a `const char *' and PTREE a pointer to a `tree' typed variable. 30888 The arguments PNAME and PTREE are used to store the result of this 30889 macro and are set to the name of the va_list builtin type and its 30890 internal type. If the return value of this macro is zero, then 30891 there is no more element. Otherwise the IDX should be increased 30892 for the next call of this macro to iterate through all types. 30893 30894 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 30895 This hook returns the va_list type of the calling convention 30896 specified by FNDECL. The default version of this hook returns 30897 `va_list_type_node'. 30898 30899 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 30900 This hook returns the va_list type of the calling convention 30901 specified by the type of TYPE. If TYPE is not a valid va_list 30902 type, it returns `NULL_TREE'. 30903 30904 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 30905 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 30906 This hook performs target-specific gimplification of 30907 `VA_ARG_EXPR'. The first two parameters correspond to the 30908 arguments to `va_arg'; the latter two are as in 30909 `gimplify.c:gimplify_expr'. 30910 30911 -- Target Hook: bool TARGET_VALID_POINTER_MODE (enum machine_mode MODE) 30912 Define this to return nonzero if the port can handle pointers with 30913 machine mode MODE. The default version of this hook returns true 30914 for both `ptr_mode' and `Pmode'. 30915 30916 -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (struct ao_ref_s *REF) 30917 Define this to return nonzero if the memory reference REF may 30918 alias with the system C library errno location. The default 30919 version of this hook assumes the system C library errno location 30920 is either a declaration of type int or accessed by dereferencing 30921 a pointer to int. 30922 30923 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (enum machine_mode 30924 MODE) 30925 Define this to return nonzero if the port is prepared to handle 30926 insns involving scalar mode MODE. For a scalar mode to be 30927 considered supported, all the basic arithmetic and comparisons 30928 must work. 30929 30930 The default version of this hook returns true for any mode 30931 required to handle the basic C types (as defined by the port). 30932 Included here are the double-word arithmetic supported by the code 30933 in `optabs.c'. 30934 30935 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (enum machine_mode 30936 MODE) 30937 Define this to return nonzero if the port is prepared to handle 30938 insns involving vector mode MODE. At the very least, it must have 30939 move patterns for this mode. 30940 30941 -- Target Hook: bool TARGET_ARRAY_MODE_SUPPORTED_P (enum machine_mode 30942 MODE, unsigned HOST_WIDE_INT NELEMS) 30943 Return true if GCC should try to use a scalar mode to store an 30944 array of NELEMS elements, given that each element has mode MODE. 30945 Returning true here overrides the usual `MAX_FIXED_MODE' limit and 30946 allows GCC to use any defined integer mode. 30947 30948 One use of this hook is to support vector load and store operations 30949 that operate on several homogeneous vectors. For example, ARM NEON 30950 has operations like: 30951 30952 int8x8x3_t vld3_s8 (const int8_t *) 30953 30954 where the return type is defined as: 30955 30956 typedef struct int8x8x3_t 30957 { 30958 int8x8_t val[3]; 30959 } int8x8x3_t; 30960 30961 If this hook allows `val' to have a scalar mode, then `int8x8x3_t' 30962 can have the same mode. GCC can then store `int8x8x3_t's in 30963 registers rather than forcing them onto the stack. 30964 30965 -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P (enum 30966 machine_mode MODE) 30967 Define this to return nonzero for machine modes for which the port 30968 has small register classes. If this target hook returns nonzero 30969 for a given MODE, the compiler will try to minimize the lifetime 30970 of registers in MODE. The hook may be called with `VOIDmode' as 30971 argument. In this case, the hook is expected to return nonzero if 30972 it returns nonzero for any mode. 30973 30974 On some machines, it is risky to let hard registers live across 30975 arbitrary insns. Typically, these machines have instructions that 30976 require values to be in specific registers (like an accumulator), 30977 and reload will fail if the required hard register is used for 30978 another purpose across such an insn. 30979 30980 Passes before reload do not know which hard registers will be used 30981 in an instruction, but the machine modes of the registers set or 30982 used in the instruction are already known. And for some machines, 30983 register classes are small for, say, integer registers but not for 30984 floating point registers. For example, the AMD x86-64 30985 architecture requires specific registers for the legacy x86 30986 integer instructions, but there are many SSE registers for 30987 floating point operations. On such targets, a good strategy may 30988 be to return nonzero from this hook for `INTEGRAL_MODE_P' machine 30989 modes but zero for the SSE register classes. 30990 30991 The default version of this hook returns false for any mode. It 30992 is always safe to redefine this hook to return with a nonzero 30993 value. But if you unnecessarily define it, you will reduce the 30994 amount of optimizations that can be performed in some cases. If 30995 you do not define this hook to return a nonzero value when it is 30996 required, the compiler will run out of spill registers and print a 30997 fatal error message. 30998 30999 -- Target Hook: unsigned int TARGET_FLAGS_REGNUM 31000 If the target has a dedicated flags register, and it needs to use 31001 the post-reload comparison elimination pass, then this value 31002 should be set appropriately. 31003 31004 31005 File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 31006 31007 17.10.8 How Scalar Function Values Are Returned 31008 ----------------------------------------------- 31009 31010 This section discusses the macros that control returning scalars as 31011 values--values that can fit in registers. 31012 31013 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 31014 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 31015 Define this to return an RTX representing the place where a 31016 function returns or receives a value of data type RET_TYPE, a tree 31017 node representing a data type. FN_DECL_OR_TYPE is a tree node 31018 representing `FUNCTION_DECL' or `FUNCTION_TYPE' of a function 31019 being called. If OUTGOING is false, the hook should compute the 31020 register in which the caller will see the return value. 31021 Otherwise, the hook should return an RTX representing the place 31022 where a function returns a value. 31023 31024 On many machines, only `TYPE_MODE (RET_TYPE)' is relevant. 31025 (Actually, on most machines, scalar values are returned in the same 31026 place regardless of mode.) The value of the expression is usually 31027 a `reg' RTX for the hard register where the return value is stored. 31028 The value can also be a `parallel' RTX, if the return value is in 31029 multiple places. See `TARGET_FUNCTION_ARG' for an explanation of 31030 the `parallel' form. Note that the callee will populate every 31031 location specified in the `parallel', but if the first element of 31032 the `parallel' contains the whole return value, callers will use 31033 that element as the canonical location and ignore the others. The 31034 m68k port uses this type of `parallel' to return pointers in both 31035 `%a0' (the canonical location) and `%d0'. 31036 31037 If `TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 31038 the same promotion rules specified in `PROMOTE_MODE' if VALTYPE is 31039 a scalar type. 31040 31041 If the precise function being called is known, FUNC is a tree node 31042 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 31043 makes it possible to use a different value-returning convention 31044 for specific functions when all their calls are known. 31045 31046 Some target machines have "register windows" so that the register 31047 in which a function returns its value is not the same as the one 31048 in which the caller sees the value. For such machines, you should 31049 return different RTX depending on OUTGOING. 31050 31051 `TARGET_FUNCTION_VALUE' is not used for return values with 31052 aggregate data types, because these are returned in another way. 31053 See `TARGET_STRUCT_VALUE_RTX' and related macros, below. 31054 31055 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 31056 This macro has been deprecated. Use `TARGET_FUNCTION_VALUE' for a 31057 new target instead. 31058 31059 -- Macro: LIBCALL_VALUE (MODE) 31060 A C expression to create an RTX representing the place where a 31061 library function returns a value of mode MODE. 31062 31063 Note that "library function" in this context means a compiler 31064 support routine, used to perform arithmetic, whose name is known 31065 specially by the compiler and was not mentioned in the C code being 31066 compiled. 31067 31068 -- Target Hook: rtx TARGET_LIBCALL_VALUE (enum machine_mode MODE, 31069 const_rtx FUN) 31070 Define this hook if the back-end needs to know the name of the 31071 libcall function in order to determine where the result should be 31072 returned. 31073 31074 The mode of the result is given by MODE and the name of the called 31075 library function is given by FUN. The hook should return an RTX 31076 representing the place where the library function result will be 31077 returned. 31078 31079 If this hook is not defined, then LIBCALL_VALUE will be used. 31080 31081 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 31082 A C expression that is nonzero if REGNO is the number of a hard 31083 register in which the values of called function may come back. 31084 31085 A register whose use for returning values is limited to serving as 31086 the second of a pair (for a value of type `double', say) need not 31087 be recognized by this macro. So for most machines, this definition 31088 suffices: 31089 31090 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 31091 31092 If the machine has register windows, so that the caller and the 31093 called function use different registers for the return value, this 31094 macro should recognize only the caller's register numbers. 31095 31096 This macro has been deprecated. Use 31097 `TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead. 31098 31099 -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int 31100 REGNO) 31101 A target hook that return `true' if REGNO is the number of a hard 31102 register in which the values of called function may come back. 31103 31104 A register whose use for returning values is limited to serving as 31105 the second of a pair (for a value of type `double', say) need not 31106 be recognized by this target hook. 31107 31108 If the machine has register windows, so that the caller and the 31109 called function use different registers for the return value, this 31110 target hook should recognize only the caller's register numbers. 31111 31112 If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be 31113 used. 31114 31115 -- Macro: APPLY_RESULT_SIZE 31116 Define this macro if `untyped_call' and `untyped_return' need more 31117 space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and 31118 restoring an arbitrary return value. 31119 31120 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 31121 This hook should return true if values of type TYPE are returned 31122 at the most significant end of a register (in other words, if they 31123 are padded at the least significant end). You can assume that TYPE 31124 is returned in a register; the caller is required to check this. 31125 31126 Note that the register provided by `TARGET_FUNCTION_VALUE' must be 31127 able to hold the complete return value. For example, if a 1-, 2- 31128 or 3-byte structure is returned at the most significant end of a 31129 4-byte register, `TARGET_FUNCTION_VALUE' should provide an 31130 `SImode' rtx. 31131 31132 31133 File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 31134 31135 17.10.9 How Large Values Are Returned 31136 ------------------------------------- 31137 31138 When a function value's mode is `BLKmode' (and in some other cases), 31139 the value is not returned according to `TARGET_FUNCTION_VALUE' (*note 31140 Scalar Return::). Instead, the caller passes the address of a block of 31141 memory in which the value should be stored. This address is called the 31142 "structure value address". 31143 31144 This section describes how to control returning structure values in 31145 memory. 31146 31147 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 31148 const_tree FNTYPE) 31149 This target hook should return a nonzero value to say to return the 31150 function value in memory, just as large structures are always 31151 returned. Here TYPE will be the data type of the value, and FNTYPE 31152 will be the type of the function doing the returning, or `NULL' for 31153 libcalls. 31154 31155 Note that values of mode `BLKmode' must be explicitly handled by 31156 this function. Also, the option `-fpcc-struct-return' takes 31157 effect regardless of this macro. On most systems, it is possible 31158 to leave the hook undefined; this causes a default definition to 31159 be used, whose value is the constant 1 for `BLKmode' values, and 0 31160 otherwise. 31161 31162 Do not use this hook to indicate that structures and unions should 31163 always be returned in memory. You should instead use 31164 `DEFAULT_PCC_STRUCT_RETURN' to indicate this. 31165 31166 -- Macro: DEFAULT_PCC_STRUCT_RETURN 31167 Define this macro to be 1 if all structure and union return values 31168 must be in memory. Since this results in slower code, this should 31169 be defined only if needed for compatibility with other compilers 31170 or with an ABI. If you define this macro to be 0, then the 31171 conventions used for structure and union return values are decided 31172 by the `TARGET_RETURN_IN_MEMORY' target hook. 31173 31174 If not defined, this defaults to the value 1. 31175 31176 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 31177 This target hook should return the location of the structure value 31178 address (normally a `mem' or `reg'), or 0 if the address is passed 31179 as an "invisible" first argument. Note that FNDECL may be `NULL', 31180 for libcalls. You do not need to define this target hook if the 31181 address is always passed as an "invisible" first argument. 31182 31183 On some architectures the place where the structure value address 31184 is found by the called function is not the same place that the 31185 caller put it. This can be due to register windows, or it could 31186 be because the function prologue moves it to a different place. 31187 INCOMING is `1' or `2' when the location is needed in the context 31188 of the called function, and `0' in the context of the caller. 31189 31190 If INCOMING is nonzero and the address is to be found on the 31191 stack, return a `mem' which refers to the frame pointer. If 31192 INCOMING is `2', the result is being used to fetch the structure 31193 value address at the beginning of a function. If you need to emit 31194 adjusting code, you should do it at this point. 31195 31196 -- Macro: PCC_STATIC_STRUCT_RETURN 31197 Define this macro if the usual system convention on the target 31198 machine for returning structures and unions is for the called 31199 function to return the address of a static variable containing the 31200 value. 31201 31202 Do not define this if the usual system convention is for the 31203 caller to pass an address to the subroutine. 31204 31205 This macro has effect in `-fpcc-struct-return' mode, but it does 31206 nothing when you use `-freg-struct-return' mode. 31207 31208 -- Target Hook: enum machine_mode TARGET_GET_RAW_RESULT_MODE (int 31209 REGNO) 31210 This target hook returns the mode to be used when accessing raw 31211 return registers in `__builtin_return'. Define this macro if the 31212 value in REG_RAW_MODE is not correct. 31213 31214 -- Target Hook: enum machine_mode TARGET_GET_RAW_ARG_MODE (int REGNO) 31215 This target hook returns the mode to be used when accessing raw 31216 argument registers in `__builtin_apply_args'. Define this macro 31217 if the value in REG_RAW_MODE is not correct. 31218 31219 31220 File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 31221 31222 17.10.10 Caller-Saves Register Allocation 31223 ----------------------------------------- 31224 31225 If you enable it, GCC can save registers around function calls. This 31226 makes it possible to use call-clobbered registers to hold variables that 31227 must live across calls. 31228 31229 -- Macro: CALLER_SAVE_PROFITABLE (REFS, CALLS) 31230 A C expression to determine whether it is worthwhile to consider 31231 placing a pseudo-register in a call-clobbered hard register and 31232 saving and restoring it around each function call. The expression 31233 should be 1 when this is worth doing, and 0 otherwise. 31234 31235 If you don't define this macro, a default is used which is good on 31236 most machines: `4 * CALLS < REFS'. 31237 31238 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 31239 A C expression specifying which mode is required for saving NREGS 31240 of a pseudo-register in call-clobbered hard register REGNO. If 31241 REGNO is unsuitable for caller save, `VOIDmode' should be 31242 returned. For most machines this macro need not be defined since 31243 GCC will select the smallest suitable mode. 31244 31245 31246 File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 31247 31248 17.10.11 Function Entry and Exit 31249 -------------------------------- 31250 31251 This section describes the macros that output function entry 31252 ("prologue") and exit ("epilogue") code. 31253 31254 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE, 31255 HOST_WIDE_INT SIZE) 31256 If defined, a function that outputs the assembler code for entry 31257 to a function. The prologue is responsible for setting up the 31258 stack frame, initializing the frame pointer register, saving 31259 registers that must be saved, and allocating SIZE additional bytes 31260 of storage for the local variables. SIZE is an integer. FILE is 31261 a stdio stream to which the assembler code should be output. 31262 31263 The label for the beginning of the function need not be output by 31264 this macro. That has already been done when the macro is run. 31265 31266 To determine which registers to save, the macro can refer to the 31267 array `regs_ever_live': element R is nonzero if hard register R is 31268 used anywhere within the function. This implies the function 31269 prologue should save register R, provided it is not one of the 31270 call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must 31271 likewise use `regs_ever_live'.) 31272 31273 On machines that have "register windows", the function entry code 31274 does not save on the stack the registers that are in the windows, 31275 even if they are supposed to be preserved by function calls; 31276 instead it takes appropriate steps to "push" the register stack, 31277 if any non-call-used registers are used in the function. 31278 31279 On machines where functions may or may not have frame-pointers, the 31280 function entry code must vary accordingly; it must set up the frame 31281 pointer if one is wanted, and not otherwise. To determine whether 31282 a frame pointer is in wanted, the macro can refer to the variable 31283 `frame_pointer_needed'. The variable's value will be 1 at run 31284 time in a function that needs a frame pointer. *Note 31285 Elimination::. 31286 31287 The function entry code is responsible for allocating any stack 31288 space required for the function. This stack space consists of the 31289 regions listed below. In most cases, these regions are allocated 31290 in the order listed, with the last listed region closest to the 31291 top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is 31292 defined, and the highest address if it is not defined). You can 31293 use a different order for a machine if doing so is more convenient 31294 or required for compatibility reasons. Except in cases where 31295 required by standard or by a debugger, there is no reason why the 31296 stack layout used by GCC need agree with that used by other 31297 compilers for a machine. 31298 31299 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 31300 If defined, a function that outputs assembler code at the end of a 31301 prologue. This should be used when the function prologue is being 31302 emitted as RTL, and you have some extra assembler that needs to be 31303 emitted. *Note prologue instruction pattern::. 31304 31305 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 31306 If defined, a function that outputs assembler code at the start of 31307 an epilogue. This should be used when the function epilogue is 31308 being emitted as RTL, and you have some extra assembler that needs 31309 to be emitted. *Note epilogue instruction pattern::. 31310 31311 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE, 31312 HOST_WIDE_INT SIZE) 31313 If defined, a function that outputs the assembler code for exit 31314 from a function. The epilogue is responsible for restoring the 31315 saved registers and stack pointer to their values when the 31316 function was called, and returning control to the caller. This 31317 macro takes the same arguments as the macro 31318 `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are 31319 determined from `regs_ever_live' and `CALL_USED_REGISTERS' in the 31320 same way. 31321 31322 On some machines, there is a single instruction that does all the 31323 work of returning from the function. On these machines, give that 31324 instruction the name `return' and do not define the macro 31325 `TARGET_ASM_FUNCTION_EPILOGUE' at all. 31326 31327 Do not define a pattern named `return' if you want the 31328 `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 31329 switches to control whether return instructions or epilogues are 31330 used, define a `return' pattern with a validity condition that 31331 tests the target switches appropriately. If the `return' 31332 pattern's validity condition is false, epilogues will be used. 31333 31334 On machines where functions may or may not have frame-pointers, the 31335 function exit code must vary accordingly. Sometimes the code for 31336 these two cases is completely different. To determine whether a 31337 frame pointer is wanted, the macro can refer to the variable 31338 `frame_pointer_needed'. The variable's value will be 1 when 31339 compiling a function that needs a frame pointer. 31340 31341 Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and 31342 `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 31343 The C variable `current_function_is_leaf' is nonzero for such a 31344 function. *Note Leaf Functions::. 31345 31346 On some machines, some functions pop their arguments on exit while 31347 others leave that for the caller to do. For example, the 68020 31348 when given `-mrtd' pops arguments in functions that take a fixed 31349 number of arguments. 31350 31351 Your definition of the macro `RETURN_POPS_ARGS' decides which 31352 functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE' 31353 needs to know what was decided. The number of bytes of the current 31354 function's arguments that this function should pop is available in 31355 `crtl->args.pops_args'. *Note Scalar Return::. 31356 31357 * A region of `crtl->args.pretend_args_size' bytes of uninitialized 31358 space just underneath the first argument arriving on the stack. 31359 (This may not be at the very start of the allocated stack region 31360 if the calling sequence has pushed anything else since pushing the 31361 stack arguments. But usually, on such machines, nothing else has 31362 been pushed yet, because the function prologue itself does all the 31363 pushing.) This region is used on machines where an argument may 31364 be passed partly in registers and partly in memory, and, in some 31365 cases to support the features in `<stdarg.h>'. 31366 31367 * An area of memory used to save certain registers used by the 31368 function. The size of this area, which may also include space for 31369 such things as the return address and pointers to previous stack 31370 frames, is machine-specific and usually depends on which registers 31371 have been used in the function. Machines with register windows 31372 often do not require a save area. 31373 31374 * A region of at least SIZE bytes, possibly rounded up to an 31375 allocation boundary, to contain the local variables of the 31376 function. On some machines, this region and the save area may 31377 occur in the opposite order, with the save area closer to the top 31378 of the stack. 31379 31380 * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a region of 31381 `crtl->outgoing_args_size' bytes to be used for outgoing argument 31382 lists of the function. *Note Stack Arguments::. 31383 31384 -- Macro: EXIT_IGNORE_STACK 31385 Define this macro as a C expression that is nonzero if the return 31386 instruction or the function epilogue ignores the value of the stack 31387 pointer; in other words, if it is safe to delete an instruction to 31388 adjust the stack pointer before a return from the function. The 31389 default is 0. 31390 31391 Note that this macro's value is relevant only for functions for 31392 which frame pointers are maintained. It is never safe to delete a 31393 final stack adjustment in a function that has no frame pointer, 31394 and the compiler knows this regardless of `EXIT_IGNORE_STACK'. 31395 31396 -- Macro: EPILOGUE_USES (REGNO) 31397 Define this macro as a C expression that is nonzero for registers 31398 that are used by the epilogue or the `return' pattern. The stack 31399 and frame pointer registers are already assumed to be used as 31400 needed. 31401 31402 -- Macro: EH_USES (REGNO) 31403 Define this macro as a C expression that is nonzero for registers 31404 that are used by the exception handling mechanism, and so should 31405 be considered live on entry to an exception edge. 31406 31407 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 31408 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 31409 VCALL_OFFSET, tree FUNCTION) 31410 A function that outputs the assembler code for a thunk function, 31411 used to implement C++ virtual function calls with multiple 31412 inheritance. The thunk acts as a wrapper around a virtual 31413 function, adjusting the implicit object parameter before handing 31414 control off to the real function. 31415 31416 First, emit code to add the integer DELTA to the location that 31417 contains the incoming first argument. Assume that this argument 31418 contains a pointer, and is the one used to pass the `this' pointer 31419 in C++. This is the incoming argument _before_ the function 31420 prologue, e.g. `%o0' on a sparc. The addition must preserve the 31421 values of all other incoming arguments. 31422 31423 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 31424 be made after adding `delta'. In particular, if P is the adjusted 31425 pointer, the following adjustment should be made: 31426 31427 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 31428 31429 After the additions, emit code to jump to FUNCTION, which is a 31430 `FUNCTION_DECL'. This is a direct pure jump, not a call, and does 31431 not touch the return address. Hence returning from FUNCTION will 31432 return to whoever called the current `thunk'. 31433 31434 The effect must be as if FUNCTION had been called directly with 31435 the adjusted first argument. This macro is responsible for 31436 emitting all of the code for a thunk function; 31437 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' 31438 are not invoked. 31439 31440 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 31441 been extracted from it.) It might possibly be useful on some 31442 targets, but probably not. 31443 31444 If you do not define this macro, the target-independent code in 31445 the C++ front end will generate a less efficient heavyweight thunk 31446 that calls FUNCTION instead of jumping to it. The generic 31447 approach does not support varargs. 31448 31449 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 31450 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 31451 VCALL_OFFSET, const_tree FUNCTION) 31452 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would 31453 be able to output the assembler code for the thunk function 31454 specified by the arguments it is passed, and false otherwise. In 31455 the latter case, the generic approach will be used by the C++ 31456 front end, with the limitations previously exposed. 31457 31458 31459 File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 31460 31461 17.10.12 Generating Code for Profiling 31462 -------------------------------------- 31463 31464 These macros will help you generate code for profiling. 31465 31466 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 31467 A C statement or compound statement to output to FILE some 31468 assembler code to call the profiling subroutine `mcount'. 31469 31470 The details of how `mcount' expects to be called are determined by 31471 your operating system environment, not by GCC. To figure them out, 31472 compile a small program for profiling using the system's installed 31473 C compiler and look at the assembler code that results. 31474 31475 Older implementations of `mcount' expect the address of a counter 31476 variable to be loaded into some register. The name of this 31477 variable is `LP' followed by the number LABELNO, so you would 31478 generate the name using `LP%d' in a `fprintf'. 31479 31480 -- Macro: PROFILE_HOOK 31481 A C statement or compound statement to output to FILE some assembly 31482 code to call the profiling subroutine `mcount' even the target does 31483 not support profiling. 31484 31485 -- Macro: NO_PROFILE_COUNTERS 31486 Define this macro to be an expression with a nonzero value if the 31487 `mcount' subroutine on your system does not need a counter variable 31488 allocated for each function. This is true for almost all modern 31489 implementations. If you define this macro, you must not use the 31490 LABELNO argument to `FUNCTION_PROFILER'. 31491 31492 -- Macro: PROFILE_BEFORE_PROLOGUE 31493 Define this macro if the code for function profiling should come 31494 before the function prologue. Normally, the profiling code comes 31495 after. 31496 31497 31498 File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling 31499 31500 17.10.13 Permitting tail calls 31501 ------------------------------ 31502 31503 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 31504 EXP) 31505 True if it is ok to do sibling call optimization for the specified 31506 call expression EXP. DECL will be the called function, or `NULL' 31507 if this is an indirect call. 31508 31509 It is not uncommon for limitations of calling conventions to 31510 prevent tail calls to functions outside the current unit of 31511 translation, or during PIC compilation. The hook is used to 31512 enforce these restrictions, as the `sibcall' md pattern can not 31513 fail, or fall over to a "normal" call. The criteria for 31514 successful sibling call optimization may vary greatly between 31515 different architectures. 31516 31517 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 31518 Add any hard registers to REGS that are live on entry to the 31519 function. This hook only needs to be defined to provide registers 31520 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 31521 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 31522 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, 31523 FRAME_POINTER_REGNUM, EH_USES, FRAME_POINTER_REGNUM, 31524 ARG_POINTER_REGNUM, and the PIC_OFFSET_TABLE_REGNUM. 31525 31526 -- Target Hook: void TARGET_SET_UP_BY_PROLOGUE (struct 31527 hard_reg_set_container *) 31528 This hook should add additional registers that are computed by the 31529 prologue to the hard regset for shrink-wrapping optimization 31530 purposes. 31531 31532 -- Target Hook: bool TARGET_WARN_FUNC_RETURN (tree) 31533 True if a function's return statements should be checked for 31534 matching the function's return type. This includes checking for 31535 falling off the end of a non-void function. Return false if no 31536 such check should be made. 31537 31538 31539 File: gccint.info, Node: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling 31540 31541 17.10.14 Stack smashing protection 31542 ---------------------------------- 31543 31544 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 31545 This hook returns a `DECL' node for the external variable to use 31546 for the stack protection guard. This variable is initialized by 31547 the runtime to some random value and is used to initialize the 31548 guard value that is placed at the top of the local stack frame. 31549 The type of this variable must be `ptr_type_node'. 31550 31551 The default version of this hook creates a variable called 31552 `__stack_chk_guard', which is normally defined in `libgcc2.c'. 31553 31554 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 31555 This hook returns a `CALL_EXPR' that alerts the runtime that the 31556 stack protect guard variable has been modified. This expression 31557 should involve a call to a `noreturn' function. 31558 31559 The default version of this hook invokes a function called 31560 `__stack_chk_fail', taking no arguments. This function is 31561 normally defined in `libgcc2.c'. 31562 31563 -- Common Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, 31564 struct gcc_options *OPTS) 31565 Whether this target supports splitting the stack when the options 31566 described in OPTS have been passed. This is called after options 31567 have been parsed, so the target may reject splitting the stack in 31568 some configurations. The default version of this hook returns 31569 false. If REPORT is true, this function may issue a warning or 31570 error; if REPORT is false, it must simply return a value 31571 31572 31573 File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 31574 31575 17.11 Implementing the Varargs Macros 31576 ===================================== 31577 31578 GCC comes with an implementation of `<varargs.h>' and `<stdarg.h>' that 31579 work without change on machines that pass arguments on the stack. 31580 Other machines require their own implementations of varargs, and the 31581 two machine independent header files must have conditionals to include 31582 it. 31583 31584 ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in the 31585 calling convention for `va_start'. The traditional implementation 31586 takes just one argument, which is the variable in which to store the 31587 argument pointer. The ISO implementation of `va_start' takes an 31588 additional second argument. The user is supposed to write the last 31589 named argument of the function here. 31590 31591 However, `va_start' should not use this argument. The way to find the 31592 end of the named arguments is with the built-in functions described 31593 below. 31594 31595 -- Macro: __builtin_saveregs () 31596 Use this built-in function to save the argument registers in 31597 memory so that the varargs mechanism can access them. Both ISO 31598 and traditional versions of `va_start' must use 31599 `__builtin_saveregs', unless you use 31600 `TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 31601 31602 On some machines, `__builtin_saveregs' is open-coded under the 31603 control of the target hook `TARGET_EXPAND_BUILTIN_SAVEREGS'. On 31604 other machines, it calls a routine written in assembler language, 31605 found in `libgcc2.c'. 31606 31607 Code generated for the call to `__builtin_saveregs' appears at the 31608 beginning of the function, as opposed to where the call to 31609 `__builtin_saveregs' is written, regardless of what the code is. 31610 This is because the registers must be saved before the function 31611 starts to use them for its own purposes. 31612 31613 -- Macro: __builtin_next_arg (LASTARG) 31614 This builtin returns the address of the first anonymous stack 31615 argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns 31616 the address of the location above the first anonymous stack 31617 argument. Use it in `va_start' to initialize the pointer for 31618 fetching arguments from the stack. Also use it in `va_start' to 31619 verify that the second parameter LASTARG is the last named argument 31620 of the current function. 31621 31622 -- Macro: __builtin_classify_type (OBJECT) 31623 Since each machine has its own conventions for which data types are 31624 passed in which kind of register, your implementation of `va_arg' 31625 has to embody these conventions. The easiest way to categorize the 31626 specified data type is to use `__builtin_classify_type' together 31627 with `sizeof' and `__alignof__'. 31628 31629 `__builtin_classify_type' ignores the value of OBJECT, considering 31630 only its data type. It returns an integer describing what kind of 31631 type that is--integer, floating, pointer, structure, and so on. 31632 31633 The file `typeclass.h' defines an enumeration that you can use to 31634 interpret the values of `__builtin_classify_type'. 31635 31636 These machine description macros help implement varargs: 31637 31638 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 31639 If defined, this hook produces the machine-specific code for a 31640 call to `__builtin_saveregs'. This code will be moved to the very 31641 beginning of the function, before any parameter access are made. 31642 The return value of this function should be an RTX that contains 31643 the value to use as the return of `__builtin_saveregs'. 31644 31645 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t 31646 ARGS_SO_FAR, enum machine_mode MODE, tree TYPE, int 31647 *PRETEND_ARGS_SIZE, int SECOND_TIME) 31648 This target hook offers an alternative to using 31649 `__builtin_saveregs' and defining the hook 31650 `TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 31651 register arguments into the stack so that all the arguments appear 31652 to have been passed consecutively on the stack. Once this is 31653 done, you can use the standard implementation of varargs that 31654 works for machines that pass all their arguments on the stack. 31655 31656 The argument ARGS_SO_FAR points to the `CUMULATIVE_ARGS' data 31657 structure, containing the values that are obtained after 31658 processing the named arguments. The arguments MODE and TYPE 31659 describe the last named argument--its machine mode and its data 31660 type as a tree node. 31661 31662 The target hook should do two things: first, push onto the stack 31663 all the argument registers _not_ used for the named arguments, and 31664 second, store the size of the data thus pushed into the 31665 `int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 31666 that you store here will serve as additional offset for setting up 31667 the stack frame. 31668 31669 Because you must generate code to push the anonymous arguments at 31670 compile time without knowing their data types, 31671 `TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 31672 have just a single category of argument register and use it 31673 uniformly for all data types. 31674 31675 If the argument SECOND_TIME is nonzero, it means that the 31676 arguments of the function are being analyzed for the second time. 31677 This happens for an inline function, which is not actually 31678 compiled until the end of the source file. The hook 31679 `TARGET_SETUP_INCOMING_VARARGS' should not generate any 31680 instructions in this case. 31681 31682 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t 31683 CA) 31684 Define this hook to return `true' if the location where a function 31685 argument is passed depends on whether or not it is a named 31686 argument. 31687 31688 This hook controls how the NAMED argument to `TARGET_FUNCTION_ARG' 31689 is set for varargs and stdarg functions. If this hook returns 31690 `true', the NAMED argument is always true for named arguments, and 31691 false for unnamed arguments. If it returns `false', but 31692 `TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns `true', then all 31693 arguments are treated as named. Otherwise, all named arguments 31694 except the last are treated as named. 31695 31696 You need not define this hook if it always returns `false'. 31697 31698 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 31699 (cumulative_args_t CA) 31700 If you need to conditionally change ABIs so that one works with 31701 `TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 31702 `TARGET_SETUP_INCOMING_VARARGS' nor 31703 `TARGET_STRICT_ARGUMENT_NAMING' was defined, then define this hook 31704 to return `true' if `TARGET_SETUP_INCOMING_VARARGS' is used, 31705 `false' otherwise. Otherwise, you should not define this hook. 31706 31707 31708 File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 31709 31710 17.12 Trampolines for Nested Functions 31711 ====================================== 31712 31713 A "trampoline" is a small piece of code that is created at run time 31714 when the address of a nested function is taken. It normally resides on 31715 the stack, in the stack frame of the containing function. These macros 31716 tell GCC how to generate code to allocate and initialize a trampoline. 31717 31718 The instructions in the trampoline must do two things: load a constant 31719 address into the static chain register, and jump to the real address of 31720 the nested function. On CISC machines such as the m68k, this requires 31721 two instructions, a move immediate and a jump. Then the two addresses 31722 exist in the trampoline as word-long immediate operands. On RISC 31723 machines, it is often necessary to load each address into a register in 31724 two parts. Then pieces of each address form separate immediate 31725 operands. 31726 31727 The code generated to initialize the trampoline must store the variable 31728 parts--the static chain value and the function address--into the 31729 immediate operands of the instructions. On a CISC machine, this is 31730 simply a matter of copying each address to a memory reference at the 31731 proper offset from the start of the trampoline. On a RISC machine, it 31732 may be necessary to take out pieces of the address and store them 31733 separately. 31734 31735 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 31736 This hook is called by `assemble_trampoline_template' to output, 31737 on the stream F, assembler code for a block of data that contains 31738 the constant parts of a trampoline. This code should not include a 31739 label--the label is taken care of automatically. 31740 31741 If you do not define this hook, it means no template is needed for 31742 the target. Do not define this hook on systems where the block 31743 move code to copy the trampoline into place would be larger than 31744 the code to generate it on the spot. 31745 31746 -- Macro: TRAMPOLINE_SECTION 31747 Return the section into which the trampoline template is to be 31748 placed (*note Sections::). The default value is 31749 `readonly_data_section'. 31750 31751 -- Macro: TRAMPOLINE_SIZE 31752 A C expression for the size in bytes of the trampoline, as an 31753 integer. 31754 31755 -- Macro: TRAMPOLINE_ALIGNMENT 31756 Alignment required for trampolines, in bits. 31757 31758 If you don't define this macro, the value of `FUNCTION_ALIGNMENT' 31759 is used for aligning trampolines. 31760 31761 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 31762 rtx STATIC_CHAIN) 31763 This hook is called to initialize a trampoline. M_TRAMP is an RTX 31764 for the memory block for the trampoline; FNDECL is the 31765 `FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX 31766 for the static chain value that should be passed to the function 31767 when it is called. 31768 31769 If the target defines `TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 31770 first thing this hook should do is emit a block move into M_TRAMP 31771 from the memory block returned by `assemble_trampoline_template'. 31772 Note that the block move need only cover the constant parts of the 31773 trampoline. If the target isolates the variable parts of the 31774 trampoline to the end, not all `TRAMPOLINE_SIZE' bytes need be 31775 copied. 31776 31777 If the target requires any other actions, such as flushing caches 31778 or enabling stack execution, these actions should be performed 31779 after initializing the trampoline proper. 31780 31781 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 31782 This hook should perform any machine-specific adjustment in the 31783 address of the trampoline. Its argument contains the address of 31784 the memory block that was passed to `TARGET_TRAMPOLINE_INIT'. In 31785 case the address to be used for a function call should be 31786 different from the address at which the template was stored, the 31787 different address should be returned; otherwise ADDR should be 31788 returned unchanged. If this hook is not defined, ADDR will be 31789 used for function calls. 31790 31791 Implementing trampolines is difficult on many machines because they 31792 have separate instruction and data caches. Writing into a stack 31793 location fails to clear the memory in the instruction cache, so when 31794 the program jumps to that location, it executes the old contents. 31795 31796 Here are two possible solutions. One is to clear the relevant parts of 31797 the instruction cache whenever a trampoline is set up. The other is to 31798 make all trampolines identical, by having them jump to a standard 31799 subroutine. The former technique makes trampoline execution faster; the 31800 latter makes initialization faster. 31801 31802 To clear the instruction cache when a trampoline is initialized, define 31803 the following macro. 31804 31805 -- Macro: CLEAR_INSN_CACHE (BEG, END) 31806 If defined, expands to a C expression clearing the _instruction 31807 cache_ in the specified interval. The definition of this macro 31808 would typically be a series of `asm' statements. Both BEG and END 31809 are both pointer expressions. 31810 31811 To use a standard subroutine, define the following macro. In addition, 31812 you must make sure that the instructions in a trampoline fill an entire 31813 cache line with identical instructions, or else ensure that the 31814 beginning of the trampoline code is always aligned at the same point in 31815 its cache line. Look in `m68k.h' as a guide. 31816 31817 -- Macro: TRANSFER_FROM_TRAMPOLINE 31818 Define this macro if trampolines need a special subroutine to do 31819 their work. The macro should expand to a series of `asm' 31820 statements which will be compiled with GCC. They go in a library 31821 function named `__transfer_from_trampoline'. 31822 31823 If you need to avoid executing the ordinary prologue code of a 31824 compiled C function when you jump to the subroutine, you can do so 31825 by placing a special label of your own in the assembler code. Use 31826 one `asm' statement to generate an assembler label, and another to 31827 make the label global. Then trampolines can use that label to 31828 jump directly to your special assembler code. 31829 31830 31831 File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 31832 31833 17.13 Implicit Calls to Library Routines 31834 ======================================== 31835 31836 Here is an explanation of implicit calls to library routines. 31837 31838 -- Macro: DECLARE_LIBRARY_RENAMES 31839 This macro, if defined, should expand to a piece of C code that 31840 will get expanded when compiling functions for libgcc.a. It can 31841 be used to provide alternate names for GCC's internal library 31842 functions if there are ABI-mandated names that the compiler should 31843 provide. 31844 31845 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 31846 This hook should declare additional library routines or rename 31847 existing ones, using the functions `set_optab_libfunc' and 31848 `init_one_libfunc' defined in `optabs.c'. `init_optabs' calls 31849 this macro after initializing all the normal library routines. 31850 31851 The default is to do nothing. Most ports don't need to define 31852 this hook. 31853 31854 -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX 31855 If false (the default), internal library routines start with two 31856 underscores. If set to true, these routines start with `__gnu_' 31857 instead. E.g., `__muldi3' changes to `__gnu_muldi3'. This 31858 currently only affects functions defined in `libgcc2.c'. If this 31859 is set to true, the `tm.h' file must also `#define 31860 LIBGCC2_GNU_PREFIX'. 31861 31862 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 31863 This macro should return `true' if the library routine that 31864 implements the floating point comparison operator COMPARISON in 31865 mode MODE will return a boolean, and FALSE if it will return a 31866 tristate. 31867 31868 GCC's own floating point libraries return tristates from the 31869 comparison operators, so the default returns false always. Most 31870 ports don't need to define this macro. 31871 31872 -- Macro: TARGET_LIB_INT_CMP_BIASED 31873 This macro should evaluate to `true' if the integer comparison 31874 functions (like `__cmpdi2') return 0 to indicate that the first 31875 operand is smaller than the second, 1 to indicate that they are 31876 equal, and 2 to indicate that the first operand is greater than 31877 the second. If this macro evaluates to `false' the comparison 31878 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 31879 target uses the routines in `libgcc.a', you do not need to define 31880 this macro. 31881 31882 -- Macro: TARGET_EDOM 31883 The value of `EDOM' on the target machine, as a C integer constant 31884 expression. If you don't define this macro, GCC does not attempt 31885 to deposit the value of `EDOM' into `errno' directly. Look in 31886 `/usr/include/errno.h' to find the value of `EDOM' on your system. 31887 31888 If you do not define `TARGET_EDOM', then compiled code reports 31889 domain errors by calling the library function and letting it 31890 report the error. If mathematical functions on your system use 31891 `matherr' when there is an error, then you should leave 31892 `TARGET_EDOM' undefined so that `matherr' is used normally. 31893 31894 -- Macro: GEN_ERRNO_RTX 31895 Define this macro as a C expression to create an rtl expression 31896 that refers to the global "variable" `errno'. (On certain systems, 31897 `errno' may not actually be a variable.) If you don't define this 31898 macro, a reasonable default is used. 31899 31900 -- Macro: TARGET_C99_FUNCTIONS 31901 When this macro is nonzero, GCC will implicitly optimize `sin' 31902 calls into `sinf' and similarly for other functions defined by C99 31903 standard. The default is zero because a number of existing 31904 systems lack support for these functions in their runtime so this 31905 macro needs to be redefined to one on systems that do support the 31906 C99 runtime. 31907 31908 -- Macro: TARGET_HAS_SINCOS 31909 When this macro is nonzero, GCC will implicitly optimize calls to 31910 `sin' and `cos' with the same argument to a call to `sincos'. The 31911 default is zero. The target has to provide the following 31912 functions: 31913 void sincos(double x, double *sin, double *cos); 31914 void sincosf(float x, float *sin, float *cos); 31915 void sincosl(long double x, long double *sin, long double *cos); 31916 31917 -- Macro: NEXT_OBJC_RUNTIME 31918 Set this macro to 1 to use the "NeXT" Objective-C message sending 31919 conventions by default. This calling convention involves passing 31920 the object, the selector and the method arguments all at once to 31921 the method-lookup library function. This is the usual setting 31922 when targeting Darwin/Mac OS X systems, which have the NeXT 31923 runtime installed. 31924 31925 If the macro is set to 0, the "GNU" Objective-C message sending 31926 convention will be used by default. This convention passes just 31927 the object and the selector to the method-lookup function, which 31928 returns a pointer to the method. 31929 31930 In either case, it remains possible to select code-generation for 31931 the alternate scheme, by means of compiler command line switches. 31932 31933 31934 File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 31935 31936 17.14 Addressing Modes 31937 ====================== 31938 31939 This is about addressing modes. 31940 31941 -- Macro: HAVE_PRE_INCREMENT 31942 -- Macro: HAVE_PRE_DECREMENT 31943 -- Macro: HAVE_POST_INCREMENT 31944 -- Macro: HAVE_POST_DECREMENT 31945 A C expression that is nonzero if the machine supports 31946 pre-increment, pre-decrement, post-increment, or post-decrement 31947 addressing respectively. 31948 31949 -- Macro: HAVE_PRE_MODIFY_DISP 31950 -- Macro: HAVE_POST_MODIFY_DISP 31951 A C expression that is nonzero if the machine supports pre- or 31952 post-address side-effect generation involving constants other than 31953 the size of the memory operand. 31954 31955 -- Macro: HAVE_PRE_MODIFY_REG 31956 -- Macro: HAVE_POST_MODIFY_REG 31957 A C expression that is nonzero if the machine supports pre- or 31958 post-address side-effect generation involving a register 31959 displacement. 31960 31961 -- Macro: CONSTANT_ADDRESS_P (X) 31962 A C expression that is 1 if the RTX X is a constant which is a 31963 valid address. On most machines the default definition of 31964 `(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 31965 but a few machines are more restrictive as to which constant 31966 addresses are supported. 31967 31968 -- Macro: CONSTANT_P (X) 31969 `CONSTANT_P', which is defined by target-independent code, accepts 31970 integer-values expressions whose values are not explicitly known, 31971 such as `symbol_ref', `label_ref', and `high' expressions and 31972 `const' arithmetic expressions, in addition to `const_int' and 31973 `const_double' expressions. 31974 31975 -- Macro: MAX_REGS_PER_ADDRESS 31976 A number, the maximum number of registers that can appear in a 31977 valid memory address. Note that it is up to you to specify a 31978 value equal to the maximum number that 31979 `TARGET_LEGITIMATE_ADDRESS_P' would ever accept. 31980 31981 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (enum machine_mode 31982 MODE, rtx X, bool STRICT) 31983 A function that returns whether X (an RTX) is a legitimate memory 31984 address on the target machine for a memory operand of mode MODE. 31985 31986 Legitimate addresses are defined in two variants: a strict variant 31987 and a non-strict one. The STRICT parameter chooses which variant 31988 is desired by the caller. 31989 31990 The strict variant is used in the reload pass. It must be defined 31991 so that any pseudo-register that has not been allocated a hard 31992 register is considered a memory reference. This is because in 31993 contexts where some kind of register is required, a 31994 pseudo-register with no hard register must be rejected. For 31995 non-hard registers, the strict variant should look up the 31996 `reg_renumber' array; it should then proceed using the hard 31997 register number in the array, or treat the pseudo as a memory 31998 reference if the array holds `-1'. 31999 32000 The non-strict variant is used in other passes. It must be 32001 defined to accept all pseudo-registers in every context where some 32002 kind of register is required. 32003 32004 Normally, constant addresses which are the sum of a `symbol_ref' 32005 and an integer are stored inside a `const' RTX to mark them as 32006 constant. Therefore, there is no need to recognize such sums 32007 specifically as legitimate addresses. Normally you would simply 32008 recognize any `const' as legitimate. 32009 32010 Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant 32011 sums that are not marked with `const'. It assumes that a naked 32012 `plus' indicates indexing. If so, then you _must_ reject such 32013 naked constant sums as illegitimate addresses, so that none of 32014 them will be given to `PRINT_OPERAND_ADDRESS'. 32015 32016 On some machines, whether a symbolic address is legitimate depends 32017 on the section that the address refers to. On these machines, 32018 define the target hook `TARGET_ENCODE_SECTION_INFO' to store the 32019 information into the `symbol_ref', and then check for it here. 32020 When you see a `const', you will have to look inside it to find the 32021 `symbol_ref' in order to determine the section. *Note Assembler 32022 Format::. 32023 32024 Some ports are still using a deprecated legacy substitute for this 32025 hook, the `GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 32026 syntax: 32027 32028 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 32029 32030 and should `goto LABEL' if the address X is a valid address on the 32031 target machine for a memory operand of mode MODE. 32032 32033 Compiler source files that want to use the strict variant of this 32034 macro define the macro `REG_OK_STRICT'. You should use an `#ifdef 32035 REG_OK_STRICT' conditional to define the strict variant in that 32036 case and the non-strict variant otherwise. 32037 32038 Using the hook is usually simpler because it limits the number of 32039 files that are recompiled when changes are made. 32040 32041 -- Macro: TARGET_MEM_CONSTRAINT 32042 A single character to be used instead of the default `'m'' 32043 character for general memory addresses. This defines the 32044 constraint letter which matches the memory addresses accepted by 32045 `TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 32046 support new address formats in your back end without changing the 32047 semantics of the `'m'' constraint. This is necessary in order to 32048 preserve functionality of inline assembly constructs using the 32049 `'m'' constraint. 32050 32051 -- Macro: FIND_BASE_TERM (X) 32052 A C expression to determine the base term of address X, or to 32053 provide a simplified version of X from which `alias.c' can easily 32054 find the base term. This macro is used in only two places: 32055 `find_base_value' and `find_base_term' in `alias.c'. 32056 32057 It is always safe for this macro to not be defined. It exists so 32058 that alias analysis can understand machine-dependent addresses. 32059 32060 The typical use of this macro is to handle addresses containing a 32061 label_ref or symbol_ref within an UNSPEC. 32062 32063 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, enum 32064 machine_mode MODE) 32065 This hook is given an invalid memory address X for an operand of 32066 mode MODE and should try to return a valid memory address. 32067 32068 X will always be the result of a call to `break_out_memory_refs', 32069 and OLDX will be the operand that was given to that function to 32070 produce X. 32071 32072 The code of the hook should not alter the substructure of X. If 32073 it transforms X into a more legitimate form, it should return the 32074 new X. 32075 32076 It is not necessary for this hook to come up with a legitimate 32077 address, with the exception of native TLS addresses (*note 32078 Emulated TLS::). The compiler has standard ways of doing so in 32079 all cases. In fact, if the target supports only emulated TLS, it 32080 is safe to omit this hook or make it return X if it cannot find a 32081 valid way to legitimize the address. But often a machine-dependent 32082 strategy can generate better code. 32083 32084 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 32085 WIN) 32086 A C compound statement that attempts to replace X, which is an 32087 address that needs reloading, with a valid memory address for an 32088 operand of mode MODE. WIN will be a C statement label elsewhere 32089 in the code. It is not necessary to define this macro, but it 32090 might be useful for performance reasons. 32091 32092 For example, on the i386, it is sometimes possible to use a single 32093 reload register instead of two by reloading a sum of two pseudo 32094 registers into a register. On the other hand, for number of RISC 32095 processors offsets are limited so that often an intermediate 32096 address needs to be generated in order to address a stack slot. 32097 By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 32098 intermediate addresses generated for adjacent some stack slots can 32099 be made identical, and thus be shared. 32100 32101 _Note_: This macro should be used with caution. It is necessary 32102 to know something of how reload works in order to effectively use 32103 this, and it is quite easy to produce macros that build in too 32104 much knowledge of reload internals. 32105 32106 _Note_: This macro must be able to reload an address created by a 32107 previous invocation of this macro. If it fails to handle such 32108 addresses then the compiler may generate incorrect code or abort. 32109 32110 The macro definition should use `push_reload' to indicate parts 32111 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 32112 suitable to be passed unaltered to `push_reload'. 32113 32114 The code generated by this macro must not alter the substructure of 32115 X. If it transforms X into a more legitimate form, it should 32116 assign X (which will always be a C variable) a new value. This 32117 also applies to parts that you change indirectly by calling 32118 `push_reload'. 32119 32120 The macro definition may use `strict_memory_address_p' to test if 32121 the address has become legitimate. 32122 32123 If you want to change only a part of X, one standard way of doing 32124 this is to use `copy_rtx'. Note, however, that it unshares only a 32125 single level of rtl. Thus, if the part to be changed is not at the 32126 top level, you'll need to replace first the top level. It is not 32127 necessary for this macro to come up with a legitimate address; 32128 but often a machine-dependent strategy can generate better code. 32129 32130 -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR, 32131 addr_space_t ADDRSPACE) 32132 This hook returns `true' if memory address ADDR in address space 32133 ADDRSPACE can have different meanings depending on the machine 32134 mode of the memory reference it is used for or if the address is 32135 valid for some modes but not others. 32136 32137 Autoincrement and autodecrement addresses typically have 32138 mode-dependent effects because the amount of the increment or 32139 decrement is the size of the operand being addressed. Some 32140 machines have other mode-dependent addresses. Many RISC machines 32141 have no mode-dependent addresses. 32142 32143 You may assume that ADDR is a valid address for the machine. 32144 32145 The default version of this hook returns `false'. 32146 32147 -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (enum machine_mode 32148 MODE, rtx X) 32149 This hook returns true if X is a legitimate constant for a 32150 MODE-mode immediate operand on the target machine. You can assume 32151 that X satisfies `CONSTANT_P', so you need not check this. 32152 32153 The default definition returns true. 32154 32155 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 32156 This hook is used to undo the possibly obfuscating effects of the 32157 `LEGITIMIZE_ADDRESS' and `LEGITIMIZE_RELOAD_ADDRESS' target 32158 macros. Some backend implementations of these macros wrap symbol 32159 references inside an `UNSPEC' rtx to represent PIC or similar 32160 addressing modes. This target hook allows GCC's optimizers to 32161 understand the semantics of these opaque `UNSPEC's by converting 32162 them back into their original form. 32163 32164 -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X) 32165 This hook should return true if X should not be emitted into debug 32166 sections. 32167 32168 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (enum machine_mode 32169 MODE, rtx X) 32170 This hook should return true if X is of a form that cannot (or 32171 should not) be spilled to the constant pool. MODE is the mode of 32172 X. 32173 32174 The default version of this hook returns false. 32175 32176 The primary reason to define this hook is to prevent reload from 32177 deciding that a non-legitimate constant would be better reloaded 32178 from the constant pool instead of spilling and reloading a register 32179 holding the constant. This restriction is often true of addresses 32180 of TLS symbols for various targets. 32181 32182 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (enum 32183 machine_mode MODE, const_rtx X) 32184 This hook should return true if pool entries for constant X can be 32185 placed in an `object_block' structure. MODE is the mode of X. 32186 32187 The default version returns false for all constants. 32188 32189 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL) 32190 This hook should return true if pool entries for DECL should be 32191 placed in an `object_block' structure. 32192 32193 The default version returns true for all decls. 32194 32195 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (unsigned FN, bool 32196 MD_FN, bool SQRT) 32197 This hook should return the DECL of a function that implements 32198 reciprocal of the builtin function with builtin function code FN, 32199 or `NULL_TREE' if such a function is not available. MD_FN is true 32200 when FN is a code of a machine-dependent builtin function. When 32201 SQRT is true, additional optimizations that apply only to the 32202 reciprocal of a square root function are performed, and only 32203 reciprocals of `sqrt' function are valid. 32204 32205 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 32206 This hook should return the DECL of a function F that given an 32207 address ADDR as an argument returns a mask M that can be used to 32208 extract from two vectors the relevant data that resides in ADDR in 32209 case ADDR is not properly aligned. 32210 32211 The autovectorizer, when vectorizing a load operation from an 32212 address ADDR that may be unaligned, will generate two vector loads 32213 from the two aligned addresses around ADDR. It then generates a 32214 `REALIGN_LOAD' operation to extract the relevant data from the two 32215 loaded vectors. The first two arguments to `REALIGN_LOAD', V1 and 32216 V2, are the two vectors, each of size VS, and the third argument, 32217 OFF, defines how the data will be extracted from these two 32218 vectors: if OFF is 0, then the returned vector is V2; otherwise, 32219 the returned vector is composed from the last VS-OFF elements of 32220 V1 concatenated to the first OFF elements of V2. 32221 32222 If this hook is defined, the autovectorizer will generate a call 32223 to F (using the DECL tree that this hook returns) and will use the 32224 return value of F as the argument OFF to `REALIGN_LOAD'. 32225 Therefore, the mask M returned by F should comply with the 32226 semantics expected by `REALIGN_LOAD' described above. If this 32227 hook is not defined, then ADDR will be used as the argument OFF to 32228 `REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 32229 will be considered. 32230 32231 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum 32232 vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN) 32233 Returns cost of different scalar or vector statements for 32234 vectorization cost model. For vector memory operations the cost 32235 may depend on type (VECTYPE) and misalignment value (MISALIGN). 32236 32237 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 32238 (const_tree TYPE, bool IS_PACKED) 32239 Return true if vector alignment is reachable (by peeling N 32240 iterations) for the given type. 32241 32242 -- Target Hook: bool TARGET_VECTORIZE_VEC_PERM_CONST_OK (enum 32243 MACHINE_MODE, const unsigned char *SEL) 32244 Return true if a vector created for `vec_perm_const' is valid. 32245 32246 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned 32247 CODE, tree DEST_TYPE, tree SRC_TYPE) 32248 This hook should return the DECL of a function that implements 32249 conversion of the input vector of type SRC_TYPE to type DEST_TYPE. 32250 The value of CODE is one of the enumerators in `enum tree_code' and 32251 specifies how the conversion is to be applied (truncation, 32252 rounding, etc.). 32253 32254 If this hook is defined, the autovectorizer will use the 32255 `TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing 32256 conversion. Otherwise, it will return `NULL_TREE'. 32257 32258 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION 32259 (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 32260 This hook should return the decl of a function that implements the 32261 vectorized variant of the builtin function with builtin function 32262 code CODE or `NULL_TREE' if such a function is not available. The 32263 value of FNDECL is the builtin function declaration. The return 32264 type of the vectorized function shall be of vector type 32265 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 32266 32267 -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT 32268 (enum machine_mode MODE, const_tree TYPE, int MISALIGNMENT, 32269 bool IS_PACKED) 32270 This hook should return true if the target supports misaligned 32271 vector store/load of a specific factor denoted in the MISALIGNMENT 32272 parameter. The vector store/load should be of machine mode MODE 32273 and the elements in the vectors should be of type TYPE. IS_PACKED 32274 parameter is true if the memory access is defined in a packed 32275 struct. 32276 32277 -- Target Hook: enum machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE 32278 (enum machine_mode MODE) 32279 This hook should return the preferred mode for vectorizing scalar 32280 mode MODE. The default is equal to `word_mode', because the 32281 vectorizer can do some transformations even in absence of 32282 specialized SIMD hardware. 32283 32284 -- Target Hook: unsigned int 32285 TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES (void) 32286 This hook should return a mask of sizes that should be iterated 32287 over after trying to autovectorize using the vector size derived 32288 from the mode returned by `TARGET_VECTORIZE_PREFERRED_SIMD_MODE'. 32289 The default is zero which means to not iterate over other vector 32290 sizes. 32291 32292 -- Target Hook: void * TARGET_VECTORIZE_INIT_COST (struct loop 32293 *LOOP_INFO) 32294 This hook should initialize target-specific data structures in 32295 preparation for modeling the costs of vectorizing a loop or basic 32296 block. The default allocates three unsigned integers for 32297 accumulating costs for the prologue, body, and epilogue of the 32298 loop or basic block. If LOOP_INFO is non-NULL, it identifies the 32299 loop being vectorized; otherwise a single block is being 32300 vectorized. 32301 32302 -- Target Hook: unsigned TARGET_VECTORIZE_ADD_STMT_COST (void *DATA, 32303 int COUNT, enum vect_cost_for_stmt KIND, struct 32304 _stmt_vec_info *STMT_INFO, int MISALIGN, enum 32305 vect_cost_model_location WHERE) 32306 This hook should update the target-specific DATA in response to 32307 adding COUNT copies of the given KIND of statement to a loop or 32308 basic block. The default adds the builtin vectorizer cost for the 32309 copies of the statement to the accumulator specified by WHERE, 32310 (the prologue, body, or epilogue) and returns the amount added. 32311 The return value should be viewed as a tentative cost that may 32312 later be revised. 32313 32314 -- Target Hook: void TARGET_VECTORIZE_FINISH_COST (void *DATA, 32315 unsigned *PROLOGUE_COST, unsigned *BODY_COST, unsigned 32316 *EPILOGUE_COST) 32317 This hook should complete calculations of the cost of vectorizing 32318 a loop or basic block based on DATA, and return the prologue, 32319 body, and epilogue costs as unsigned integers. The default 32320 returns the value of the three accumulators. 32321 32322 -- Target Hook: void TARGET_VECTORIZE_DESTROY_COST_DATA (void *DATA) 32323 This hook should release DATA and any related data structures 32324 allocated by TARGET_VECTORIZE_INIT_COST. The default releases the 32325 accumulator. 32326 32327 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_TM_LOAD (tree) 32328 This hook should return the built-in decl needed to load a vector 32329 of the given type within a transaction. 32330 32331 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_TM_STORE (tree) 32332 This hook should return the built-in decl needed to store a vector 32333 of the given type within a transaction. 32334 32335 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_GATHER (const_tree 32336 MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE) 32337 Target builtin that implements vector gather operation. 32338 MEM_VECTYPE is the vector type of the load and INDEX_TYPE is 32339 scalar type of the index, scaled by SCALE. The default is 32340 `NULL_TREE' which means to not vectorize gather loads. 32341 32342 32343 File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 32344 32345 17.15 Anchored Addresses 32346 ======================== 32347 32348 GCC usually addresses every static object as a separate entity. For 32349 example, if we have: 32350 32351 static int a, b, c; 32352 int foo (void) { return a + b + c; } 32353 32354 the code for `foo' will usually calculate three separate symbolic 32355 addresses: those of `a', `b' and `c'. On some targets, it would be 32356 better to calculate just one symbolic address and access the three 32357 variables relative to it. The equivalent pseudocode would be something 32358 like: 32359 32360 int foo (void) 32361 { 32362 register int *xr = &x; 32363 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 32364 } 32365 32366 (which isn't valid C). We refer to shared addresses like `x' as 32367 "section anchors". Their use is controlled by `-fsection-anchors'. 32368 32369 The hooks below describe the target properties that GCC needs to know 32370 in order to make effective use of section anchors. It won't use 32371 section anchors at all unless either `TARGET_MIN_ANCHOR_OFFSET' or 32372 `TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 32373 32374 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 32375 The minimum offset that should be applied to a section anchor. On 32376 most targets, it should be the smallest offset that can be applied 32377 to a base register while still giving a legitimate address for 32378 every mode. The default value is 0. 32379 32380 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 32381 Like `TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) 32382 offset that should be applied to section anchors. The default 32383 value is 0. 32384 32385 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 32386 Write the assembly code to define section anchor X, which is a 32387 `SYMBOL_REF' for which `SYMBOL_REF_ANCHOR_P (X)' is true. The 32388 hook is called with the assembly output position set to the 32389 beginning of `SYMBOL_REF_BLOCK (X)'. 32390 32391 If `ASM_OUTPUT_DEF' is available, the hook's default definition 32392 uses it to define the symbol as `. + SYMBOL_REF_BLOCK_OFFSET (X)'. 32393 If `ASM_OUTPUT_DEF' is not available, the hook's default definition 32394 is `NULL', which disables the use of section anchors altogether. 32395 32396 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 32397 Return true if GCC should attempt to use anchors to access 32398 `SYMBOL_REF' X. You can assume `SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 32399 and `!SYMBOL_REF_ANCHOR_P (X)'. 32400 32401 The default version is correct for most targets, but you might 32402 need to intercept this hook to handle things like target-specific 32403 attributes or target-specific sections. 32404 32405 32406 File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 32407 32408 17.16 Condition Code Status 32409 =========================== 32410 32411 The macros in this section can be split in two families, according to 32412 the two ways of representing condition codes in GCC. 32413 32414 The first representation is the so called `(cc0)' representation 32415 (*note Jump Patterns::), where all instructions can have an implicit 32416 clobber of the condition codes. The second is the condition code 32417 register representation, which provides better schedulability for 32418 architectures that do have a condition code register, but on which most 32419 instructions do not affect it. The latter category includes most RISC 32420 machines. 32421 32422 The implicit clobbering poses a strong restriction on the placement of 32423 the definition and use of the condition code, which need to be in 32424 adjacent insns for machines using `(cc0)'. This can prevent important 32425 optimizations on some machines. For example, on the IBM RS/6000, there 32426 is a delay for taken branches unless the condition code register is set 32427 three instructions earlier than the conditional branch. The instruction 32428 scheduler cannot perform this optimization if it is not permitted to 32429 separate the definition and use of the condition code register. 32430 32431 For this reason, it is possible and suggested to use a register to 32432 represent the condition code for new ports. If there is a specific 32433 condition code register in the machine, use a hard register. If the 32434 condition code or comparison result can be placed in any general 32435 register, or if there are multiple condition registers, use a pseudo 32436 register. Registers used to store the condition code value will 32437 usually have a mode that is in class `MODE_CC'. 32438 32439 Alternatively, you can use `BImode' if the comparison operator is 32440 specified already in the compare instruction. In this case, you are not 32441 interested in most macros in this section. 32442 32443 * Menu: 32444 32445 * CC0 Condition Codes:: Old style representation of condition codes. 32446 * MODE_CC Condition Codes:: Modern representation of condition codes. 32447 * Cond Exec Macros:: Macros to control conditional execution. 32448 32449 32450 File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 32451 32452 17.16.1 Representation of condition codes using `(cc0)' 32453 ------------------------------------------------------- 32454 32455 The file `conditions.h' defines a variable `cc_status' to describe how 32456 the condition code was computed (in case the interpretation of the 32457 condition code depends on the instruction that it was set by). This 32458 variable contains the RTL expressions on which the condition code is 32459 currently based, and several standard flags. 32460 32461 Sometimes additional machine-specific flags must be defined in the 32462 machine description header file. It can also add additional 32463 machine-specific information by defining `CC_STATUS_MDEP'. 32464 32465 -- Macro: CC_STATUS_MDEP 32466 C code for a data type which is used for declaring the `mdep' 32467 component of `cc_status'. It defaults to `int'. 32468 32469 This macro is not used on machines that do not use `cc0'. 32470 32471 -- Macro: CC_STATUS_MDEP_INIT 32472 A C expression to initialize the `mdep' field to "empty". The 32473 default definition does nothing, since most machines don't use the 32474 field anyway. If you want to use the field, you should probably 32475 define this macro to initialize it. 32476 32477 This macro is not used on machines that do not use `cc0'. 32478 32479 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 32480 A C compound statement to set the components of `cc_status' 32481 appropriately for an insn INSN whose body is EXP. It is this 32482 macro's responsibility to recognize insns that set the condition 32483 code as a byproduct of other activity as well as those that 32484 explicitly set `(cc0)'. 32485 32486 This macro is not used on machines that do not use `cc0'. 32487 32488 If there are insns that do not set the condition code but do alter 32489 other machine registers, this macro must check to see whether they 32490 invalidate the expressions that the condition code is recorded as 32491 reflecting. For example, on the 68000, insns that store in address 32492 registers do not set the condition code, which means that usually 32493 `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns. 32494 But suppose that the previous insn set the condition code based on 32495 location `a4@(102)' and the current insn stores a new value in 32496 `a4'. Although the condition code is not changed by this, it will 32497 no longer be true that it reflects the contents of `a4@(102)'. 32498 Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case 32499 to say that nothing is known about the condition code value. 32500 32501 The definition of `NOTICE_UPDATE_CC' must be prepared to deal with 32502 the results of peephole optimization: insns whose patterns are 32503 `parallel' RTXs containing various `reg', `mem' or constants which 32504 are just the operands. The RTL structure of these insns is not 32505 sufficient to indicate what the insns actually do. What 32506 `NOTICE_UPDATE_CC' should do when it sees one is just to run 32507 `CC_STATUS_INIT'. 32508 32509 A possible definition of `NOTICE_UPDATE_CC' is to call a function 32510 that looks at an attribute (*note Insn Attributes::) named, for 32511 example, `cc'. This avoids having detailed information about 32512 patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. 32513 32514 32515 File: gccint.info, Node: MODE_CC Condition Codes, Next: Cond Exec Macros, Prev: CC0 Condition Codes, Up: Condition Code 32516 32517 17.16.2 Representation of condition codes using registers 32518 --------------------------------------------------------- 32519 32520 -- Macro: SELECT_CC_MODE (OP, X, Y) 32521 On many machines, the condition code may be produced by other 32522 instructions than compares, for example the branch can use 32523 directly the condition code set by a subtract instruction. 32524 However, on some machines when the condition code is set this way 32525 some bits (such as the overflow bit) are not set in the same way 32526 as a test instruction, so that a different branch instruction must 32527 be used for some conditional branches. When this happens, use the 32528 machine mode of the condition code register to record different 32529 formats of the condition code register. Modes can also be used to 32530 record which compare instruction (e.g. a signed or an unsigned 32531 comparison) produced the condition codes. 32532 32533 If other modes than `CCmode' are required, add them to 32534 `MACHINE-modes.def' and define `SELECT_CC_MODE' to choose a mode 32535 given an operand of a compare. This is needed because the modes 32536 have to be chosen not only during RTL generation but also, for 32537 example, by instruction combination. The result of 32538 `SELECT_CC_MODE' should be consistent with the mode used in the 32539 patterns; for example to support the case of the add on the SPARC 32540 discussed above, we have the pattern 32541 32542 (define_insn "" 32543 [(set (reg:CC_NOOV 0) 32544 (compare:CC_NOOV 32545 (plus:SI (match_operand:SI 0 "register_operand" "%r") 32546 (match_operand:SI 1 "arith_operand" "rI")) 32547 (const_int 0)))] 32548 "" 32549 "...") 32550 32551 together with a `SELECT_CC_MODE' that returns `CC_NOOVmode' for 32552 comparisons whose argument is a `plus': 32553 32554 #define SELECT_CC_MODE(OP,X,Y) \ 32555 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 32556 ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \ 32557 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 32558 || GET_CODE (X) == NEG) \ 32559 ? CC_NOOVmode : CCmode)) 32560 32561 Another reason to use modes is to retain information on which 32562 operands were used by the comparison; see `REVERSIBLE_CC_MODE' 32563 later in this section. 32564 32565 You should define this macro if and only if you define extra CC 32566 modes in `MACHINE-modes.def'. 32567 32568 -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx 32569 *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE) (CODE, OP0, OP1, 32570 OP0_PRESERVE_VALUE) 32571 On some machines not all possible comparisons are defined, but you 32572 can convert an invalid comparison into a valid one. For example, 32573 the Alpha does not have a `GT' comparison, but you can use an `LT' 32574 comparison instead and swap the order of the operands. 32575 32576 On such machines, implement this hook to do any required 32577 conversions. CODE is the initial comparison code and OP0 and OP1 32578 are the left and right operands of the comparison, respectively. 32579 If OP0_PRESERVE_VALUE is `true' the implementation is not allowed 32580 to change the value of OP0 since the value might be used in RTXs 32581 which aren't comparisons. E.g. the implementation is not allowed 32582 to swap operands in that case. 32583 32584 GCC will not assume that the comparison resulting from this macro 32585 is valid but will see if the resulting insn matches a pattern in 32586 the `md' file. 32587 32588 You need not to implement this hook if it would never change the 32589 comparison code or operands. 32590 32591 -- Macro: REVERSIBLE_CC_MODE (MODE) 32592 A C expression whose value is one if it is always safe to reverse a 32593 comparison whose mode is MODE. If `SELECT_CC_MODE' can ever 32594 return MODE for a floating-point inequality comparison, then 32595 `REVERSIBLE_CC_MODE (MODE)' must be zero. 32596 32597 You need not define this macro if it would always returns zero or 32598 if the floating-point format is anything other than 32599 `IEEE_FLOAT_FORMAT'. For example, here is the definition used on 32600 the SPARC, where floating-point inequality comparisons are always 32601 given `CCFPEmode': 32602 32603 #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode) 32604 32605 -- Macro: REVERSE_CONDITION (CODE, MODE) 32606 A C expression whose value is reversed condition code of the CODE 32607 for comparison done in CC_MODE MODE. The macro is used only in 32608 case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 32609 case machine has some non-standard way how to reverse certain 32610 conditionals. For instance in case all floating point conditions 32611 are non-trapping, compiler may freely convert unordered compares 32612 to ordered one. Then definition may look like: 32613 32614 #define REVERSE_CONDITION(CODE, MODE) \ 32615 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 32616 : reverse_condition_maybe_unordered (CODE)) 32617 32618 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 32619 *P1, unsigned int *P2) 32620 On targets which do not use `(cc0)', and which use a hard register 32621 rather than a pseudo-register to hold condition codes, the regular 32622 CSE passes are often not able to identify cases in which the hard 32623 register is set to a common value. Use this hook to enable a 32624 small pass which optimizes such cases. This hook should return 32625 true to enable this pass, and it should set the integers to which 32626 its arguments point to the hard register numbers used for 32627 condition codes. When there is only one such register, as is true 32628 on most systems, the integer pointed to by P2 should be set to 32629 `INVALID_REGNUM'. 32630 32631 The default version of this hook returns false. 32632 32633 -- Target Hook: enum machine_mode TARGET_CC_MODES_COMPATIBLE (enum 32634 machine_mode M1, enum machine_mode M2) 32635 On targets which use multiple condition code modes in class 32636 `MODE_CC', it is sometimes the case that a comparison can be 32637 validly done in more than one mode. On such a system, define this 32638 target hook to take two mode arguments and to return a mode in 32639 which both comparisons may be validly done. If there is no such 32640 mode, return `VOIDmode'. 32641 32642 The default version of this hook checks whether the modes are the 32643 same. If they are, it returns that mode. If they are different, 32644 it returns `VOIDmode'. 32645 32646 32647 File: gccint.info, Node: Cond Exec Macros, Prev: MODE_CC Condition Codes, Up: Condition Code 32648 32649 17.16.3 Macros to control conditional execution 32650 ----------------------------------------------- 32651 32652 There is one macro that may need to be defined for targets supporting 32653 conditional execution, independent of how they represent conditional 32654 branches. 32655 32656 32657 File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 32658 32659 17.17 Describing Relative Costs of Operations 32660 ============================================= 32661 32662 These macros let you describe the relative speed of various operations 32663 on the target machine. 32664 32665 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 32666 A C expression for the cost of moving data of mode MODE from a 32667 register in class FROM to one in class TO. The classes are 32668 expressed using the enumeration values such as `GENERAL_REGS'. A 32669 value of 2 is the default; other values are interpreted relative to 32670 that. 32671 32672 It is not required that the cost always equal 2 when FROM is the 32673 same as TO; on some machines it is expensive to move between 32674 registers if they are not general registers. 32675 32676 If reload sees an insn consisting of a single `set' between two 32677 hard registers, and if `REGISTER_MOVE_COST' applied to their 32678 classes returns a value of 2, reload does not check to ensure that 32679 the constraints of the insn are met. Setting a cost of other than 32680 2 will allow reload to verify that the constraints are met. You 32681 should do this if the `movM' pattern's constraints do not allow 32682 such copying. 32683 32684 These macros are obsolete, new ports should use the target hook 32685 `TARGET_REGISTER_MOVE_COST' instead. 32686 32687 -- Target Hook: int TARGET_REGISTER_MOVE_COST (enum machine_mode MODE, 32688 reg_class_t FROM, reg_class_t TO) 32689 This target hook should return the cost of moving data of mode MODE 32690 from a register in class FROM to one in class TO. The classes are 32691 expressed using the enumeration values such as `GENERAL_REGS'. A 32692 value of 2 is the default; other values are interpreted relative to 32693 that. 32694 32695 It is not required that the cost always equal 2 when FROM is the 32696 same as TO; on some machines it is expensive to move between 32697 registers if they are not general registers. 32698 32699 If reload sees an insn consisting of a single `set' between two 32700 hard registers, and if `TARGET_REGISTER_MOVE_COST' applied to their 32701 classes returns a value of 2, reload does not check to ensure that 32702 the constraints of the insn are met. Setting a cost of other than 32703 2 will allow reload to verify that the constraints are met. You 32704 should do this if the `movM' pattern's constraints do not allow 32705 such copying. 32706 32707 The default version of this function returns 2. 32708 32709 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 32710 A C expression for the cost of moving data of mode MODE between a 32711 register of class CLASS and memory; IN is zero if the value is to 32712 be written to memory, nonzero if it is to be read in. This cost 32713 is relative to those in `REGISTER_MOVE_COST'. If moving between 32714 registers and memory is more expensive than between two registers, 32715 you should define this macro to express the relative cost. 32716 32717 If you do not define this macro, GCC uses a default cost of 4 plus 32718 the cost of copying via a secondary reload register, if one is 32719 needed. If your machine requires a secondary reload register to 32720 copy between memory and a register of CLASS but the reload 32721 mechanism is more complex than copying via an intermediate, define 32722 this macro to reflect the actual cost of the move. 32723 32724 GCC defines the function `memory_move_secondary_cost' if secondary 32725 reloads are needed. It computes the costs due to copying via a 32726 secondary register. If your machine copies from memory using a 32727 secondary register in the conventional way but the default base 32728 value of 4 is not correct for your machine, define this macro to 32729 add some other value to the result of that function. The 32730 arguments to that function are the same as to this macro. 32731 32732 These macros are obsolete, new ports should use the target hook 32733 `TARGET_MEMORY_MOVE_COST' instead. 32734 32735 -- Target Hook: int TARGET_MEMORY_MOVE_COST (enum machine_mode MODE, 32736 reg_class_t RCLASS, bool IN) 32737 This target hook should return the cost of moving data of mode MODE 32738 between a register of class RCLASS and memory; IN is `false' if 32739 the value is to be written to memory, `true' if it is to be read 32740 in. This cost is relative to those in `TARGET_REGISTER_MOVE_COST'. 32741 If moving between registers and memory is more expensive than 32742 between two registers, you should add this target hook to express 32743 the relative cost. 32744 32745 If you do not add this target hook, GCC uses a default cost of 4 32746 plus the cost of copying via a secondary reload register, if one is 32747 needed. If your machine requires a secondary reload register to 32748 copy between memory and a register of RCLASS but the reload 32749 mechanism is more complex than copying via an intermediate, use 32750 this target hook to reflect the actual cost of the move. 32751 32752 GCC defines the function `memory_move_secondary_cost' if secondary 32753 reloads are needed. It computes the costs due to copying via a 32754 secondary register. If your machine copies from memory using a 32755 secondary register in the conventional way but the default base 32756 value of 4 is not correct for your machine, use this target hook 32757 to add some other value to the result of that function. The 32758 arguments to that function are the same as to this target hook. 32759 32760 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 32761 A C expression for the cost of a branch instruction. A value of 1 32762 is the default; other values are interpreted relative to that. 32763 Parameter SPEED_P is true when the branch in question should be 32764 optimized for speed. When it is false, `BRANCH_COST' should 32765 return a value optimal for code size rather than performance. 32766 PREDICTABLE_P is true for well-predicted branches. On many 32767 architectures the `BRANCH_COST' can be reduced then. 32768 32769 Here are additional macros which do not specify precise relative costs, 32770 but only that certain actions are more expensive than GCC would 32771 ordinarily expect. 32772 32773 -- Macro: SLOW_BYTE_ACCESS 32774 Define this macro as a C expression which is nonzero if accessing 32775 less than a word of memory (i.e. a `char' or a `short') is no 32776 faster than accessing a word of memory, i.e., if such access 32777 require more than one instruction or if there is no difference in 32778 cost between byte and (aligned) word loads. 32779 32780 When this macro is not defined, the compiler will access a field by 32781 finding the smallest containing object; when it is defined, a 32782 fullword load will be used if alignment permits. Unless bytes 32783 accesses are faster than word accesses, using word accesses is 32784 preferable since it may eliminate subsequent memory access if 32785 subsequent accesses occur to other fields in the same word of the 32786 structure, but to different bytes. 32787 32788 -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT) 32789 Define this macro to be the value 1 if memory accesses described 32790 by the MODE and ALIGNMENT parameters have a cost many times greater 32791 than aligned accesses, for example if they are emulated in a trap 32792 handler. 32793 32794 When this macro is nonzero, the compiler will act as if 32795 `STRICT_ALIGNMENT' were nonzero when generating code for block 32796 moves. This can cause significantly more instructions to be 32797 produced. Therefore, do not set this macro nonzero if unaligned 32798 accesses only add a cycle or two to the time for a memory access. 32799 32800 If the value of this macro is always zero, it need not be defined. 32801 If this macro is defined, it should produce a nonzero value when 32802 `STRICT_ALIGNMENT' is nonzero. 32803 32804 -- Macro: MOVE_RATIO (SPEED) 32805 The threshold of number of scalar memory-to-memory move insns, 32806 _below_ which a sequence of insns should be generated instead of a 32807 string move insn or a library call. Increasing the value will 32808 always make code faster, but eventually incurs high cost in 32809 increased code size. 32810 32811 Note that on machines where the corresponding move insn is a 32812 `define_expand' that emits a sequence of insns, this macro counts 32813 the number of such sequences. 32814 32815 The parameter SPEED is true if the code is currently being 32816 optimized for speed rather than size. 32817 32818 If you don't define this, a reasonable default is used. 32819 32820 -- Macro: MOVE_BY_PIECES_P (SIZE, ALIGNMENT) 32821 A C expression used to determine whether `move_by_pieces' will be 32822 used to copy a chunk of memory, or whether some other block move 32823 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 32824 returns less than `MOVE_RATIO'. 32825 32826 -- Macro: MOVE_MAX_PIECES 32827 A C expression used by `move_by_pieces' to determine the largest 32828 unit a load or store used to copy memory is. Defaults to 32829 `MOVE_MAX'. 32830 32831 -- Macro: CLEAR_RATIO (SPEED) 32832 The threshold of number of scalar move insns, _below_ which a 32833 sequence of insns should be generated to clear memory instead of a 32834 string clear insn or a library call. Increasing the value will 32835 always make code faster, but eventually incurs high cost in 32836 increased code size. 32837 32838 The parameter SPEED is true if the code is currently being 32839 optimized for speed rather than size. 32840 32841 If you don't define this, a reasonable default is used. 32842 32843 -- Macro: CLEAR_BY_PIECES_P (SIZE, ALIGNMENT) 32844 A C expression used to determine whether `clear_by_pieces' will be 32845 used to clear a chunk of memory, or whether some other block clear 32846 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 32847 returns less than `CLEAR_RATIO'. 32848 32849 -- Macro: SET_RATIO (SPEED) 32850 The threshold of number of scalar move insns, _below_ which a 32851 sequence of insns should be generated to set memory to a constant 32852 value, instead of a block set insn or a library call. Increasing 32853 the value will always make code faster, but eventually incurs high 32854 cost in increased code size. 32855 32856 The parameter SPEED is true if the code is currently being 32857 optimized for speed rather than size. 32858 32859 If you don't define this, it defaults to the value of `MOVE_RATIO'. 32860 32861 -- Macro: SET_BY_PIECES_P (SIZE, ALIGNMENT) 32862 A C expression used to determine whether `store_by_pieces' will be 32863 used to set a chunk of memory to a constant value, or whether some 32864 other mechanism will be used. Used by `__builtin_memset' when 32865 storing values other than constant zero. Defaults to 1 if 32866 `move_by_pieces_ninsns' returns less than `SET_RATIO'. 32867 32868 -- Macro: STORE_BY_PIECES_P (SIZE, ALIGNMENT) 32869 A C expression used to determine whether `store_by_pieces' will be 32870 used to set a chunk of memory to a constant string value, or 32871 whether some other mechanism will be used. Used by 32872 `__builtin_strcpy' when called with a constant source string. 32873 Defaults to 1 if `move_by_pieces_ninsns' returns less than 32874 `MOVE_RATIO'. 32875 32876 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 32877 A C expression used to determine whether a load postincrement is a 32878 good thing to use for a given mode. Defaults to the value of 32879 `HAVE_POST_INCREMENT'. 32880 32881 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 32882 A C expression used to determine whether a load postdecrement is a 32883 good thing to use for a given mode. Defaults to the value of 32884 `HAVE_POST_DECREMENT'. 32885 32886 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 32887 A C expression used to determine whether a load preincrement is a 32888 good thing to use for a given mode. Defaults to the value of 32889 `HAVE_PRE_INCREMENT'. 32890 32891 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 32892 A C expression used to determine whether a load predecrement is a 32893 good thing to use for a given mode. Defaults to the value of 32894 `HAVE_PRE_DECREMENT'. 32895 32896 -- Macro: USE_STORE_POST_INCREMENT (MODE) 32897 A C expression used to determine whether a store postincrement is 32898 a good thing to use for a given mode. Defaults to the value of 32899 `HAVE_POST_INCREMENT'. 32900 32901 -- Macro: USE_STORE_POST_DECREMENT (MODE) 32902 A C expression used to determine whether a store postdecrement is 32903 a good thing to use for a given mode. Defaults to the value of 32904 `HAVE_POST_DECREMENT'. 32905 32906 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 32907 This macro is used to determine whether a store preincrement is a 32908 good thing to use for a given mode. Defaults to the value of 32909 `HAVE_PRE_INCREMENT'. 32910 32911 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 32912 This macro is used to determine whether a store predecrement is a 32913 good thing to use for a given mode. Defaults to the value of 32914 `HAVE_PRE_DECREMENT'. 32915 32916 -- Macro: NO_FUNCTION_CSE 32917 Define this macro if it is as good or better to call a constant 32918 function address than to call an address kept in a register. 32919 32920 -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT 32921 Define this macro if a non-short-circuit operation produced by 32922 `fold_range_test ()' is optimal. This macro defaults to true if 32923 `BRANCH_COST' is greater than or equal to the value 2. 32924 32925 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int 32926 OUTER_CODE, int OPNO, int *TOTAL, bool SPEED) 32927 This target hook describes the relative costs of RTL expressions. 32928 32929 The cost may depend on the precise form of the expression, which is 32930 available for examination in X, and the fact that X appears as 32931 operand OPNO of an expression with rtx code OUTER_CODE. That is, 32932 the hook can assume that there is some rtx Y such that `GET_CODE 32933 (Y) == OUTER_CODE' and such that either (a) `XEXP (Y, OPNO) == X' 32934 or (b) `XVEC (Y, OPNO)' contains X. 32935 32936 CODE is X's expression code--redundant, since it can be obtained 32937 with `GET_CODE (X)'. 32938 32939 In implementing this hook, you can use the construct 32940 `COSTS_N_INSNS (N)' to specify a cost equal to N fast instructions. 32941 32942 On entry to the hook, `*TOTAL' contains a default estimate for the 32943 cost of the expression. The hook should modify this value as 32944 necessary. Traditionally, the default costs are `COSTS_N_INSNS 32945 (5)' for multiplications, `COSTS_N_INSNS (7)' for division and 32946 modulus operations, and `COSTS_N_INSNS (1)' for all other 32947 operations. 32948 32949 When optimizing for code size, i.e. when `speed' is false, this 32950 target hook should be used to estimate the relative size cost of 32951 an expression, again relative to `COSTS_N_INSNS'. 32952 32953 The hook returns true when all subexpressions of X have been 32954 processed, and false when `rtx_cost' should recurse. 32955 32956 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, enum 32957 machine_mode MODE, addr_space_t AS, bool SPEED) 32958 This hook computes the cost of an addressing mode that contains 32959 ADDRESS. If not defined, the cost is computed from the ADDRESS 32960 expression and the `TARGET_RTX_COST' hook. 32961 32962 For most CISC machines, the default cost is a good approximation 32963 of the true cost of the addressing mode. However, on RISC 32964 machines, all instructions normally have the same length and 32965 execution time. Hence all addresses will have equal costs. 32966 32967 In cases where more than one form of an address is known, the form 32968 with the lowest cost will be used. If multiple forms have the 32969 same, lowest, cost, the one that is the most complex will be used. 32970 32971 For example, suppose an address that is equal to the sum of a 32972 register and a constant is used twice in the same basic block. 32973 When this macro is not defined, the address will be computed in a 32974 register and memory references will be indirect through that 32975 register. On machines where the cost of the addressing mode 32976 containing the sum is no higher than that of a simple indirect 32977 reference, this will produce an additional instruction and 32978 possibly require an additional register. Proper specification of 32979 this macro eliminates this overhead for such machines. 32980 32981 This hook is never called with an invalid address. 32982 32983 On machines where an address involving more than one register is as 32984 cheap as an address computation involving only one register, 32985 defining `TARGET_ADDRESS_COST' to reflect this can cause two 32986 registers to be live over a region of code where only one would 32987 have been if `TARGET_ADDRESS_COST' were not defined in that 32988 manner. This effect should be considered in the definition of 32989 this macro. Equivalent costs should probably only be given to 32990 addresses with different numbers of registers on machines with 32991 lots of registers. 32992 32993 32994 File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 32995 32996 17.18 Adjusting the Instruction Scheduler 32997 ========================================= 32998 32999 The instruction scheduler may need a fair amount of machine-specific 33000 adjustment in order to produce good code. GCC provides several target 33001 hooks for this purpose. It is usually enough to define just a few of 33002 them: try the first ones in this list first. 33003 33004 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 33005 This hook returns the maximum number of instructions that can ever 33006 issue at the same time on the target machine. The default is one. 33007 Although the insn scheduler can define itself the possibility of 33008 issue an insn on the same cycle, the value can serve as an 33009 additional constraint to issue insns on the same simulated 33010 processor cycle (see hooks `TARGET_SCHED_REORDER' and 33011 `TARGET_SCHED_REORDER2'). This value must be constant over the 33012 entire compilation. If you need it to vary depending on what the 33013 instructions are, you must use `TARGET_SCHED_VARIABLE_ISSUE'. 33014 33015 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 33016 VERBOSE, rtx INSN, int MORE) 33017 This hook is executed by the scheduler after it has scheduled an 33018 insn from the ready list. It should return the number of insns 33019 which can still be issued in the current cycle. The default is 33020 `MORE - 1' for insns other than `CLOBBER' and `USE', which 33021 normally are not counted against the issue rate. You should 33022 define this hook if some insns take more machine resources than 33023 others, so that fewer insns can follow them in the same cycle. 33024 FILE is either a null pointer, or a stdio stream to write any 33025 debug output to. VERBOSE is the verbose level provided by 33026 `-fsched-verbose-N'. INSN is the instruction that was scheduled. 33027 33028 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx 33029 DEP_INSN, int COST) 33030 This function corrects the value of COST based on the relationship 33031 between INSN and DEP_INSN through the dependence LINK. It should 33032 return the new value. The default is to make no adjustment to 33033 COST. This can be used for example to specify to the scheduler 33034 using the traditional pipeline description that an output- or 33035 anti-dependence does not incur the same cost as a data-dependence. 33036 If the scheduler using the automaton based pipeline description, 33037 the cost of anti-dependence is zero and the cost of 33038 output-dependence is maximum of one and the difference of latency 33039 times of the first and the second insns. If these values are not 33040 acceptable, you could use the hook to modify them too. See also 33041 *note Processor pipeline description::. 33042 33043 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int 33044 PRIORITY) 33045 This hook adjusts the integer scheduling priority PRIORITY of 33046 INSN. It should return the new priority. Increase the priority to 33047 execute INSN earlier, reduce the priority to execute INSN later. 33048 Do not define this hook if you do not need to adjust the 33049 scheduling priorities of insns. 33050 33051 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx 33052 *READY, int *N_READYP, int CLOCK) 33053 This hook is executed by the scheduler after it has scheduled the 33054 ready list, to allow the machine description to reorder it (for 33055 example to combine two small instructions together on `VLIW' 33056 machines). FILE is either a null pointer, or a stdio stream to 33057 write any debug output to. VERBOSE is the verbose level provided 33058 by `-fsched-verbose-N'. READY is a pointer to the ready list of 33059 instructions that are ready to be scheduled. N_READYP is a 33060 pointer to the number of elements in the ready list. The scheduler 33061 reads the ready list in reverse order, starting with 33062 READY[*N_READYP - 1] and going to READY[0]. CLOCK is the timer 33063 tick of the scheduler. You may modify the ready list and the 33064 number of ready insns. The return value is the number of insns 33065 that can issue this cycle; normally this is just `issue_rate'. 33066 See also `TARGET_SCHED_REORDER2'. 33067 33068 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 33069 rtx *READY, int *N_READYP, int CLOCK) 33070 Like `TARGET_SCHED_REORDER', but called at a different time. That 33071 function is called whenever the scheduler starts a new cycle. 33072 This one is called once per iteration over a cycle, immediately 33073 after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list 33074 and return the number of insns to be scheduled in the same cycle. 33075 Defining this hook can be useful if there are frequent situations 33076 where scheduling one insn causes other insns to become ready in 33077 the same cycle. These other insns can then be taken into account 33078 properly. 33079 33080 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx 33081 HEAD, rtx TAIL) 33082 This hook is called after evaluation forward dependencies of insns 33083 in chain given by two parameter values (HEAD and TAIL 33084 correspondingly) but before insns scheduling of the insn chain. 33085 For example, it can be used for better insn classification if it 33086 requires analysis of dependencies. This hook can use backward and 33087 forward dependencies of the insn scheduler because they are already 33088 calculated. 33089 33090 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 33091 MAX_READY) 33092 This hook is executed by the scheduler at the beginning of each 33093 block of instructions that are to be scheduled. FILE is either a 33094 null pointer, or a stdio stream to write any debug output to. 33095 VERBOSE is the verbose level provided by `-fsched-verbose-N'. 33096 MAX_READY is the maximum number of insns in the current scheduling 33097 region that can be live at the same time. This can be used to 33098 allocate scratch space if it is needed, e.g. by 33099 `TARGET_SCHED_REORDER'. 33100 33101 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 33102 This hook is executed by the scheduler at the end of each block of 33103 instructions that are to be scheduled. It can be used to perform 33104 cleanup of any actions done by the other scheduling hooks. FILE 33105 is either a null pointer, or a stdio stream to write any debug 33106 output to. VERBOSE is the verbose level provided by 33107 `-fsched-verbose-N'. 33108 33109 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int 33110 VERBOSE, int OLD_MAX_UID) 33111 This hook is executed by the scheduler after function level 33112 initializations. FILE is either a null pointer, or a stdio stream 33113 to write any debug output to. VERBOSE is the verbose level 33114 provided by `-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 33115 uid when scheduling begins. 33116 33117 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 33118 VERBOSE) 33119 This is the cleanup hook corresponding to 33120 `TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 33121 stdio stream to write any debug output to. VERBOSE is the verbose 33122 level provided by `-fsched-verbose-N'. 33123 33124 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 33125 The hook returns an RTL insn. The automaton state used in the 33126 pipeline hazard recognizer is changed as if the insn were scheduled 33127 when the new simulated processor cycle starts. Usage of the hook 33128 may simplify the automaton pipeline description for some VLIW 33129 processors. If the hook is defined, it is used only for the 33130 automaton based pipeline description. The default is not to 33131 change the state when the new simulated processor cycle starts. 33132 33133 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 33134 The hook can be used to initialize data used by the previous hook. 33135 33136 -- Target Hook: rtx TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 33137 The hook is analogous to `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 33138 to changed the state as if the insn were scheduled when the new 33139 simulated processor cycle finishes. 33140 33141 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 33142 The hook is analogous to `TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 33143 used to initialize data used by the previous hook. 33144 33145 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 33146 The hook to notify target that the current simulated cycle is 33147 about to finish. The hook is analogous to 33148 `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 33149 more complicated situations - e.g., when advancing state on a 33150 single insn is not enough. 33151 33152 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 33153 The hook to notify target that new simulated cycle has just 33154 started. The hook is analogous to 33155 `TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 33156 more complicated situations - e.g., when advancing state on a 33157 single insn is not enough. 33158 33159 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 33160 (void) 33161 This hook controls better choosing an insn from the ready insn 33162 queue for the DFA-based insn scheduler. Usually the scheduler 33163 chooses the first insn from the queue. If the hook returns a 33164 positive value, an additional scheduler code tries all 33165 permutations of `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 33166 ()' subsequent ready insns to choose an insn whose issue will 33167 result in maximal number of issued insns on the same cycle. For 33168 the VLIW processor, the code could actually solve the problem of 33169 packing simple insns into the VLIW insn. Of course, if the rules 33170 of VLIW packing are described in the automaton. 33171 33172 This code also could be used for superscalar RISC processors. Let 33173 us consider a superscalar RISC processor with 3 pipelines. Some 33174 insns can be executed in pipelines A or B, some insns can be 33175 executed only in pipelines B or C, and one insn can be executed in 33176 pipeline B. The processor may issue the 1st insn into A and the 33177 2nd one into B. In this case, the 3rd insn will wait for freeing B 33178 until the next cycle. If the scheduler issues the 3rd insn the 33179 first, the processor could issue all 3 insns per cycle. 33180 33181 Actually this code demonstrates advantages of the automaton based 33182 pipeline hazard recognizer. We try quickly and easy many insn 33183 schedules to choose the best one. 33184 33185 The default is no multipass scheduling. 33186 33187 -- Target Hook: int 33188 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx INSN) 33189 This hook controls what insns from the ready insn queue will be 33190 considered for the multipass insn scheduling. If the hook returns 33191 zero for INSN, the insn will be not chosen to be issued. 33192 33193 The default is that any ready insns can be chosen to be issued. 33194 33195 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void 33196 *DATA, char *READY_TRY, int N_READY, bool FIRST_CYCLE_INSN_P) 33197 This hook prepares the target backend for a new round of multipass 33198 scheduling. 33199 33200 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void 33201 *DATA, char *READY_TRY, int N_READY, rtx INSN, const void 33202 *PREV_DATA) 33203 This hook is called when multipass scheduling evaluates 33204 instruction INSN. 33205 33206 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK 33207 (const void *DATA, char *READY_TRY, int N_READY) 33208 This is called when multipass scheduling backtracks from 33209 evaluation of an instruction. 33210 33211 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const 33212 void *DATA) 33213 This hook notifies the target about the result of the concluded 33214 current round of multipass scheduling. 33215 33216 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void 33217 *DATA) 33218 This hook initializes target-specific data used in multipass 33219 scheduling. 33220 33221 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void 33222 *DATA) 33223 This hook finalizes target-specific data used in multipass 33224 scheduling. 33225 33226 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 33227 VERBOSE, rtx INSN, int LAST_CLOCK, int CLOCK, int *SORT_P) 33228 This hook is called by the insn scheduler before issuing INSN on 33229 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 33230 this processor cycle. Instead, the processor cycle is advanced. 33231 If *SORT_P is zero, the insn ready queue is not sorted on the new 33232 cycle start as usually. DUMP and VERBOSE specify the file and 33233 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 33234 are, respectively, the processor cycle on which the previous insn 33235 has been issued, and the current processor cycle. 33236 33237 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 33238 *_DEP, int COST, int DISTANCE) 33239 This hook is used to define which dependences are considered 33240 costly by the target, so costly that it is not advisable to 33241 schedule the insns that are involved in the dependence too close 33242 to one another. The parameters to this hook are as follows: The 33243 first parameter _DEP is the dependence being evaluated. The 33244 second parameter COST is the cost of the dependence as estimated 33245 by the scheduler, and the third parameter DISTANCE is the distance 33246 in cycles between the two insns. The hook returns `true' if 33247 considering the distance between the two insns the dependence 33248 between them is considered costly by the target, and `false' 33249 otherwise. 33250 33251 Defining this hook can be useful in multiple-issue out-of-order 33252 machines, where (a) it's practically hopeless to predict the 33253 actual data/resource delays, however: (b) there's a better chance 33254 to predict the actual grouping that will be formed, and (c) 33255 correctly emulating the grouping can be very important. In such 33256 targets one may want to allow issuing dependent insns closer to 33257 one another--i.e., closer than the dependence distance; however, 33258 not in cases of "costly dependences", which this hooks allows to 33259 define. 33260 33261 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 33262 This hook is called by the insn scheduler after emitting a new 33263 instruction to the instruction stream. The hook notifies a target 33264 backend to extend its per instruction data structures. 33265 33266 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 33267 Return a pointer to a store large enough to hold target scheduling 33268 context. 33269 33270 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 33271 CLEAN_P) 33272 Initialize store pointed to by TC to hold target scheduling 33273 context. It CLEAN_P is true then initialize TC as if scheduler is 33274 at the beginning of the block. Otherwise, copy the current 33275 context into TC. 33276 33277 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 33278 Copy target scheduling context pointed to by TC to the current 33279 context. 33280 33281 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 33282 Deallocate internal data in target scheduling context pointed to 33283 by TC. 33284 33285 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 33286 Deallocate a store for target scheduling context pointed to by TC. 33287 33288 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx INSN, int 33289 REQUEST, rtx *NEW_PAT) 33290 This hook is called by the insn scheduler when INSN has only 33291 speculative dependencies and therefore can be scheduled 33292 speculatively. The hook is used to check if the pattern of INSN 33293 has a speculative version and, in case of successful check, to 33294 generate that speculative pattern. The hook should return 1, if 33295 the instruction has a speculative form, or -1, if it doesn't. 33296 REQUEST describes the type of requested speculation. If the 33297 return value equals 1 then NEW_PAT is assigned the generated 33298 speculative pattern. 33299 33300 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (int DEP_STATUS) 33301 This hook is called by the insn scheduler during generation of 33302 recovery code for INSN. It should return `true', if the 33303 corresponding check instruction should branch to recovery code, or 33304 `false' otherwise. 33305 33306 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx INSN, rtx LABEL, 33307 int MUTATE_P) 33308 This hook is called by the insn scheduler to generate a pattern 33309 for recovery check instruction. If MUTATE_P is zero, then INSN is 33310 a speculative instruction for which the check should be generated. 33311 LABEL is either a label of a basic block, where recovery code 33312 should be emitted, or a null pointer, when requested check doesn't 33313 branch to recovery code (a simple check). If MUTATE_P is nonzero, 33314 then a pattern for a branchy check corresponding to a simple check 33315 denoted by INSN should be generated. In this case LABEL can't be 33316 null. 33317 33318 -- Target Hook: bool 33319 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC (const_rtx 33320 INSN) 33321 This hook is used as a workaround for 33322 `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD' not being 33323 called on the first instruction of the ready list. The hook is 33324 used to discard speculative instructions that stand first in the 33325 ready list from being scheduled on the current cycle. If the hook 33326 returns `false', INSN will not be chosen to be issued. For 33327 non-speculative instructions, the hook should always return 33328 `true'. For example, in the ia64 backend the hook is used to 33329 cancel data speculative insns when the ALAT table is nearly full. 33330 33331 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct 33332 spec_info_def *SPEC_INFO) 33333 This hook is used by the insn scheduler to find out what features 33334 should be enabled/used. The structure *SPEC_INFO should be filled 33335 in by the target. The structure describes speculation types that 33336 can be used in the scheduler. 33337 33338 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 33339 This hook is called by the swing modulo scheduler to calculate a 33340 resource-based lower bound which is based on the resources 33341 available in the machine and the resources required by each 33342 instruction. The target backend can use G to calculate such 33343 bound. A very simple lower bound will be used in case this hook 33344 is not implemented: the total number of instructions divided by 33345 the issue rate. 33346 33347 -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx INSN, int X) 33348 This hook is called by Haifa Scheduler. It returns true if 33349 dispatch scheduling is supported in hardware and the condition 33350 specified in the parameter is true. 33351 33352 -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx INSN, int X) 33353 This hook is called by Haifa Scheduler. It performs the operation 33354 specified in its second parameter. 33355 33356 -- Target Hook: bool TARGET_SCHED_EXPOSED_PIPELINE 33357 True if the processor has an exposed pipeline, which means that 33358 not just the order of instructions is important for correctness 33359 when scheduling, but also the latencies of operations. 33360 33361 -- Target Hook: int TARGET_SCHED_REASSOCIATION_WIDTH (unsigned int 33362 OPC, enum machine_mode MODE) 33363 This hook is called by tree reassociator to determine a level of 33364 parallelism required in output calculations chain. 33365 33366 33367 File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 33368 33369 17.19 Dividing the Output into Sections (Texts, Data, ...) 33370 ========================================================== 33371 33372 An object file is divided into sections containing different types of 33373 data. In the most common case, there are three sections: the "text 33374 section", which holds instructions and read-only data; the "data 33375 section", which holds initialized writable data; and the "bss section", 33376 which holds uninitialized data. Some systems have other kinds of 33377 sections. 33378 33379 `varasm.c' provides several well-known sections, such as 33380 `text_section', `data_section' and `bss_section'. The normal way of 33381 controlling a `FOO_section' variable is to define the associated 33382 `FOO_SECTION_ASM_OP' macro, as described below. The macros are only 33383 read once, when `varasm.c' initializes itself, so their values must be 33384 run-time constants. They may however depend on command-line flags. 33385 33386 _Note:_ Some run-time files, such `crtstuff.c', also make use of the 33387 `FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 33388 33389 Some assemblers require a different string to be written every time a 33390 section is selected. If your assembler falls into this category, you 33391 should define the `TARGET_ASM_INIT_SECTIONS' hook and use 33392 `get_unnamed_section' to set up the sections. 33393 33394 You must always create a `text_section', either by defining 33395 `TEXT_SECTION_ASM_OP' or by initializing `text_section' in 33396 `TARGET_ASM_INIT_SECTIONS'. The same is true of `data_section' and 33397 `DATA_SECTION_ASM_OP'. If you do not create a distinct 33398 `readonly_data_section', the default is to reuse `text_section'. 33399 33400 All the other `varasm.c' sections are optional, and are null if the 33401 target does not provide them. 33402 33403 -- Macro: TEXT_SECTION_ASM_OP 33404 A C expression whose value is a string, including spacing, 33405 containing the assembler operation that should precede 33406 instructions and read-only data. Normally `"\t.text"' is right. 33407 33408 -- Macro: HOT_TEXT_SECTION_NAME 33409 If defined, a C string constant for the name of the section 33410 containing most frequently executed functions of the program. If 33411 not defined, GCC will provide a default definition if the target 33412 supports named sections. 33413 33414 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 33415 If defined, a C string constant for the name of the section 33416 containing unlikely executed functions in the program. 33417 33418 -- Macro: DATA_SECTION_ASM_OP 33419 A C expression whose value is a string, including spacing, 33420 containing the assembler operation to identify the following data 33421 as writable initialized data. Normally `"\t.data"' is right. 33422 33423 -- Macro: SDATA_SECTION_ASM_OP 33424 If defined, a C expression whose value is a string, including 33425 spacing, containing the assembler operation to identify the 33426 following data as initialized, writable small data. 33427 33428 -- Macro: READONLY_DATA_SECTION_ASM_OP 33429 A C expression whose value is a string, including spacing, 33430 containing the assembler operation to identify the following data 33431 as read-only initialized data. 33432 33433 -- Macro: BSS_SECTION_ASM_OP 33434 If defined, a C expression whose value is a string, including 33435 spacing, containing the assembler operation to identify the 33436 following data as uninitialized global data. If not defined, and 33437 `ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data 33438 will be output in the data section if `-fno-common' is passed, 33439 otherwise `ASM_OUTPUT_COMMON' will be used. 33440 33441 -- Macro: SBSS_SECTION_ASM_OP 33442 If defined, a C expression whose value is a string, including 33443 spacing, containing the assembler operation to identify the 33444 following data as uninitialized, writable small data. 33445 33446 -- Macro: TLS_COMMON_ASM_OP 33447 If defined, a C expression whose value is a string containing the 33448 assembler operation to identify the following data as thread-local 33449 common data. The default is `".tls_common"'. 33450 33451 -- Macro: TLS_SECTION_ASM_FLAG 33452 If defined, a C expression whose value is a character constant 33453 containing the flag used to mark a section as a TLS section. The 33454 default is `'T''. 33455 33456 -- Macro: INIT_SECTION_ASM_OP 33457 If defined, a C expression whose value is a string, including 33458 spacing, containing the assembler operation to identify the 33459 following data as initialization code. If not defined, GCC will 33460 assume such a section does not exist. This section has no 33461 corresponding `init_section' variable; it is used entirely in 33462 runtime code. 33463 33464 -- Macro: FINI_SECTION_ASM_OP 33465 If defined, a C expression whose value is a string, including 33466 spacing, containing the assembler operation to identify the 33467 following data as finalization code. If not defined, GCC will 33468 assume such a section does not exist. This section has no 33469 corresponding `fini_section' variable; it is used entirely in 33470 runtime code. 33471 33472 -- Macro: INIT_ARRAY_SECTION_ASM_OP 33473 If defined, a C expression whose value is a string, including 33474 spacing, containing the assembler operation to identify the 33475 following data as part of the `.init_array' (or equivalent) 33476 section. If not defined, GCC will assume such a section does not 33477 exist. Do not define both this macro and `INIT_SECTION_ASM_OP'. 33478 33479 -- Macro: FINI_ARRAY_SECTION_ASM_OP 33480 If defined, a C expression whose value is a string, including 33481 spacing, containing the assembler operation to identify the 33482 following data as part of the `.fini_array' (or equivalent) 33483 section. If not defined, GCC will assume such a section does not 33484 exist. Do not define both this macro and `FINI_SECTION_ASM_OP'. 33485 33486 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 33487 If defined, an ASM statement that switches to a different section 33488 via SECTION_OP, calls FUNCTION, and switches back to the text 33489 section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or 33490 `FINI_SECTION_ASM_OP' to calls to initialization and finalization 33491 functions from the init and fini sections. By default, this macro 33492 uses a simple function call. Some ports need hand-crafted 33493 assembly code to avoid dependencies on registers initialized in 33494 the function prologue or to ensure that constant pools don't end 33495 up too far way in the text section. 33496 33497 -- Macro: TARGET_LIBGCC_SDATA_SECTION 33498 If defined, a string which names the section into which small 33499 variables defined in crtstuff and libgcc should go. This is useful 33500 when the target has options for optimizing access to small data, 33501 and you want the crtstuff and libgcc routines to be conservative 33502 in what they expect of your application yet liberal in what your 33503 application expects. For example, for targets with a `.sdata' 33504 section (like MIPS), you could compile crtstuff with `-G 0' so 33505 that it doesn't require small data support from your application, 33506 but use this macro to put small data into `.sdata' so that your 33507 application can access these variables whether it uses small data 33508 or not. 33509 33510 -- Macro: FORCE_CODE_SECTION_ALIGN 33511 If defined, an ASM statement that aligns a code section to some 33512 arbitrary boundary. This is used to force all fragments of the 33513 `.init' and `.fini' sections to have to same alignment and thus 33514 prevent the linker from having to add any padding. 33515 33516 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 33517 Define this macro to be an expression with a nonzero value if jump 33518 tables (for `tablejump' insns) should be output in the text 33519 section, along with the assembler instructions. Otherwise, the 33520 readonly data section is used. 33521 33522 This macro is irrelevant if there is no separate readonly data 33523 section. 33524 33525 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 33526 Define this hook if you need to do something special to set up the 33527 `varasm.c' sections, or if your target has some special sections 33528 of its own that you need to create. 33529 33530 GCC calls this hook after processing the command line, but before 33531 writing any assembly code, and before calling any of the 33532 section-returning hooks described below. 33533 33534 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 33535 Return a mask describing how relocations should be treated when 33536 selecting sections. Bit 1 should be set if global relocations 33537 should be placed in a read-write section; bit 0 should be set if 33538 local relocations should be placed in a read-write section. 33539 33540 The default version of this function returns 3 when `-fpic' is in 33541 effect, and 0 otherwise. The hook is typically redefined when the 33542 target cannot support (some kinds of) dynamic relocations in 33543 read-only sections even in executables. 33544 33545 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 33546 RELOC, unsigned HOST_WIDE_INT ALIGN) 33547 Return the section into which EXP should be placed. You can 33548 assume that EXP is either a `VAR_DECL' node or a constant of some 33549 sort. RELOC indicates whether the initial value of EXP requires 33550 link-time relocations. Bit 0 is set when variable contains local 33551 relocations only, while bit 1 is set for global relocations. 33552 ALIGN is the constant alignment in bits. 33553 33554 The default version of this function takes care of putting 33555 read-only variables in `readonly_data_section'. 33556 33557 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 33558 33559 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 33560 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 33561 called for `FUNCTION_DECL's as well as for variables and constants. 33562 33563 In the case of a `FUNCTION_DECL', RELOC will be zero if the 33564 function has been determined to be likely to be called, and 33565 nonzero if it is unlikely to be called. 33566 33567 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 33568 Build up a unique section name, expressed as a `STRING_CST' node, 33569 and assign it to `DECL_SECTION_NAME (DECL)'. As with 33570 `TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 33571 value of EXP requires link-time relocations. 33572 33573 The default version of this function appends the symbol name to the 33574 ELF section name that would normally be used for the symbol. For 33575 example, the function `foo' would be placed in `.text.foo'. 33576 Whatever the actual target object format, this is often good 33577 enough. 33578 33579 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 33580 DECL) 33581 Return the readonly data section associated with 33582 `DECL_SECTION_NAME (DECL)'. The default version of this function 33583 selects `.gnu.linkonce.r.name' if the function's section is 33584 `.gnu.linkonce.t.name', `.rodata.name' if function is in 33585 `.text.name', and the normal readonly-data section otherwise. 33586 33587 -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX 33588 Usually, the compiler uses the prefix `".rodata"' to construct 33589 section names for mergeable constant data. Define this macro to 33590 override the string if a different section name should be used. 33591 33592 -- Target Hook: section * TARGET_ASM_TM_CLONE_TABLE_SECTION (void) 33593 Return the section that should be used for transactional memory 33594 clone tables. 33595 33596 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (enum 33597 machine_mode MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 33598 Return the section into which a constant X, of mode MODE, should 33599 be placed. You can assume that X is some kind of constant in RTL. 33600 The argument MODE is redundant except in the case of a `const_int' 33601 rtx. ALIGN is the constant alignment in bits. 33602 33603 The default version of this function takes care of putting symbolic 33604 constants in `flag_pic' mode in `data_section' and everything else 33605 in `readonly_data_section'. 33606 33607 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, 33608 tree ID) 33609 Define this hook if you need to postprocess the assembler name 33610 generated by target-independent code. The ID provided to this 33611 hook will be the computed name (e.g., the macro `DECL_NAME' of the 33612 DECL in C, or the mangled name of the DECL in C++). The return 33613 value of the hook is an `IDENTIFIER_NODE' for the appropriate 33614 mangled name on your target system. The default implementation of 33615 this hook just returns the ID provided. 33616 33617 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 33618 int NEW_DECL_P) 33619 Define this hook if references to a symbol or a constant must be 33620 treated differently depending on something about the variable or 33621 function named by the symbol (such as what section it is in). 33622 33623 The hook is executed immediately after rtl has been created for 33624 DECL, which may be a variable or function declaration or an entry 33625 in the constant pool. In either case, RTL is the rtl in question. 33626 Do _not_ use `DECL_RTL (DECL)' in this hook; that field may not 33627 have been initialized yet. 33628 33629 In the case of a constant, it is safe to assume that the rtl is a 33630 `mem' whose address is a `symbol_ref'. Most decls will also have 33631 this form, but that is not guaranteed. Global register variables, 33632 for instance, will have a `reg' for their rtl. (Normally the 33633 right thing to do with such unusual rtl is leave it alone.) 33634 33635 The NEW_DECL_P argument will be true if this is the first time 33636 that `TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. 33637 It will be false for subsequent invocations, which will happen for 33638 duplicate declarations. Whether or not anything must be done for 33639 the duplicate declaration depends on whether the hook examines 33640 `DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 33641 called for a constant. 33642 33643 The usual thing for this hook to do is to record flags in the 33644 `symbol_ref', using `SYMBOL_REF_FLAG' or `SYMBOL_REF_FLAGS'. 33645 Historically, the name string was modified if it was necessary to 33646 encode more than one bit of information, but this practice is now 33647 discouraged; use `SYMBOL_REF_FLAGS'. 33648 33649 The default definition of this hook, `default_encode_section_info' 33650 in `varasm.c', sets a number of commonly-useful bits in 33651 `SYMBOL_REF_FLAGS'. Check whether the default does what you need 33652 before overriding it. 33653 33654 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 33655 *NAME) 33656 Decode NAME and return the real name part, sans the characters 33657 that `TARGET_ENCODE_SECTION_INFO' may have added. 33658 33659 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 33660 Returns true if EXP should be placed into a "small data" section. 33661 The default version of this hook always returns false. 33662 33663 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 33664 Contains the value true if the target places read-only "small 33665 data" into a separate section. The default value is false. 33666 33667 -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void) 33668 It returns true if target wants profile code emitted before 33669 prologue. 33670 33671 The default version of this hook use the target macro 33672 `PROFILE_BEFORE_PROLOGUE'. 33673 33674 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 33675 Returns true if EXP names an object for which name resolution 33676 rules must resolve to the current "module" (dynamic shared library 33677 or executable image). 33678 33679 The default version of this hook implements the name resolution 33680 rules for ELF, which has a looser model of global name binding 33681 than other currently supported object file formats. 33682 33683 -- Target Hook: bool TARGET_HAVE_TLS 33684 Contains the value true if the target supports thread-local 33685 storage. The default value is false. 33686 33687 33688 File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 33689 33690 17.20 Position Independent Code 33691 =============================== 33692 33693 This section describes macros that help implement generation of position 33694 independent code. Simply defining these macros is not enough to 33695 generate valid PIC; you must also add support to the hook 33696 `TARGET_LEGITIMATE_ADDRESS_P' and to the macro `PRINT_OPERAND_ADDRESS', 33697 as well as `LEGITIMIZE_ADDRESS'. You must modify the definition of 33698 `movsi' to do something appropriate when the source operand contains a 33699 symbolic address. You may also need to alter the handling of switch 33700 statements so that they use relative addresses. 33701 33702 -- Macro: PIC_OFFSET_TABLE_REGNUM 33703 The register number of the register used to address a table of 33704 static data addresses in memory. In some cases this register is 33705 defined by a processor's "application binary interface" (ABI). 33706 When this macro is defined, RTL is generated for this register 33707 once, as with the stack pointer and frame pointer registers. If 33708 this macro is not defined, it is up to the machine-dependent files 33709 to allocate such a register (if necessary). Note that this 33710 register must be fixed when in use (e.g. when `flag_pic' is true). 33711 33712 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 33713 A C expression that is nonzero if the register defined by 33714 `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined, 33715 the default is zero. Do not define this macro if 33716 `PIC_OFFSET_TABLE_REGNUM' is not defined. 33717 33718 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 33719 A C expression that is nonzero if X is a legitimate immediate 33720 operand on the target machine when generating position independent 33721 code. You can assume that X satisfies `CONSTANT_P', so you need 33722 not check this. You can also assume FLAG_PIC is true, so you need 33723 not check it either. You need not define this macro if all 33724 constants (including `SYMBOL_REF') can be immediate operands when 33725 generating position independent code. 33726 33727 33728 File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 33729 33730 17.21 Defining the Output Assembler Language 33731 ============================================ 33732 33733 This section describes macros whose principal purpose is to describe how 33734 to write instructions in assembler language--rather than what the 33735 instructions do. 33736 33737 * Menu: 33738 33739 * File Framework:: Structural information for the assembler file. 33740 * Data Output:: Output of constants (numbers, strings, addresses). 33741 * Uninitialized Data:: Output of uninitialized variables. 33742 * Label Output:: Output and generation of labels. 33743 * Initialization:: General principles of initialization 33744 and termination routines. 33745 * Macros for Initialization:: 33746 Specific macros that control the handling of 33747 initialization and termination routines. 33748 * Instruction Output:: Output of actual instructions. 33749 * Dispatch Tables:: Output of jump tables. 33750 * Exception Region Output:: Output of exception region code. 33751 * Alignment Output:: Pseudo ops for alignment and skipping data. 33752 33753 33754 File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 33755 33756 17.21.1 The Overall Framework of an Assembler File 33757 -------------------------------------------------- 33758 33759 This describes the overall framework of an assembly file. 33760 33761 -- Target Hook: void TARGET_ASM_FILE_START (void) 33762 Output to `asm_out_file' any text which the assembler expects to 33763 find at the beginning of a file. The default behavior is 33764 controlled by two flags, documented below. Unless your target's 33765 assembler is quite unusual, if you override the default, you 33766 should call `default_file_start' at some point in your target 33767 hook. This lets other target files rely on these variables. 33768 33769 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 33770 If this flag is true, the text of the macro `ASM_APP_OFF' will be 33771 printed as the very first line in the assembly file, unless 33772 `-fverbose-asm' is in effect. (If that macro has been defined to 33773 the empty string, this variable has no effect.) With the normal 33774 definition of `ASM_APP_OFF', the effect is to notify the GNU 33775 assembler that it need not bother stripping comments or extra 33776 whitespace from its input. This allows it to work a bit faster. 33777 33778 The default is false. You should not set it to true unless you 33779 have verified that your port does not generate any extra 33780 whitespace or comments that will cause GAS to issue errors in 33781 NO_APP mode. 33782 33783 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 33784 If this flag is true, `output_file_directive' will be called for 33785 the primary source file, immediately after printing `ASM_APP_OFF' 33786 (if that is enabled). Most ELF assemblers expect this to be done. 33787 The default is false. 33788 33789 -- Target Hook: void TARGET_ASM_FILE_END (void) 33790 Output to `asm_out_file' any text which the assembler expects to 33791 find at the end of a file. The default is to output nothing. 33792 33793 -- Function: void file_end_indicate_exec_stack () 33794 Some systems use a common convention, the `.note.GNU-stack' 33795 special section, to indicate whether or not an object file relies 33796 on the stack being executable. If your system uses this 33797 convention, you should define `TARGET_ASM_FILE_END' to this 33798 function. If you need to do other things in that hook, have your 33799 hook function call this function. 33800 33801 -- Target Hook: void TARGET_ASM_LTO_START (void) 33802 Output to `asm_out_file' any text which the assembler expects to 33803 find at the start of an LTO section. The default is to output 33804 nothing. 33805 33806 -- Target Hook: void TARGET_ASM_LTO_END (void) 33807 Output to `asm_out_file' any text which the assembler expects to 33808 find at the end of an LTO section. The default is to output 33809 nothing. 33810 33811 -- Target Hook: void TARGET_ASM_CODE_END (void) 33812 Output to `asm_out_file' any text which is needed before emitting 33813 unwind info and debug info at the end of a file. Some targets emit 33814 here PIC setup thunks that cannot be emitted at the end of file, 33815 because they couldn't have unwind info then. The default is to 33816 output nothing. 33817 33818 -- Macro: ASM_COMMENT_START 33819 A C string constant describing how to begin a comment in the target 33820 assembler language. The compiler assumes that the comment will 33821 end at the end of the line. 33822 33823 -- Macro: ASM_APP_ON 33824 A C string constant for text to be output before each `asm' 33825 statement or group of consecutive ones. Normally this is 33826 `"#APP"', which is a comment that has no effect on most assemblers 33827 but tells the GNU assembler that it must check the lines that 33828 follow for all valid assembler constructs. 33829 33830 -- Macro: ASM_APP_OFF 33831 A C string constant for text to be output after each `asm' 33832 statement or group of consecutive ones. Normally this is 33833 `"#NO_APP"', which tells the GNU assembler to resume making the 33834 time-saving assumptions that are valid for ordinary compiler 33835 output. 33836 33837 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 33838 A C statement to output COFF information or DWARF debugging 33839 information which indicates that filename NAME is the current 33840 source file to the stdio stream STREAM. 33841 33842 This macro need not be defined if the standard form of output for 33843 the file format in use is appropriate. 33844 33845 -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE, 33846 const char *NAME) 33847 Output COFF information or DWARF debugging information which 33848 indicates that filename NAME is the current source file to the 33849 stdio stream FILE. 33850 33851 This target hook need not be defined if the standard form of 33852 output for the file format in use is appropriate. 33853 33854 -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME) 33855 Output a string based on NAME, suitable for the `#ident' 33856 directive, or the equivalent directive or pragma in non-C-family 33857 languages. If this hook is not defined, nothing is output for the 33858 `#ident' directive. 33859 33860 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 33861 A C statement to output the string STRING to the stdio stream 33862 STREAM. If you do not call the function `output_quoted_string' in 33863 your config files, GCC will only call it to output filenames to 33864 the assembler source. So you can use it to canonicalize the format 33865 of the filename using this macro. 33866 33867 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 33868 unsigned int FLAGS, tree DECL) 33869 Output assembly directives to switch to section NAME. The section 33870 should have attributes as specified by FLAGS, which is a bit mask 33871 of the `SECTION_*' flags defined in `output.h'. If DECL is 33872 non-NULL, it is the `VAR_DECL' or `FUNCTION_DECL' with which this 33873 section is associated. 33874 33875 -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum 33876 node_frequency FREQ, bool STARTUP, bool EXIT) 33877 Return preferred text (sub)section for function DECL. Main 33878 purpose of this function is to separate cold, normal and hot 33879 functions. STARTUP is true when function is known to be used only 33880 at startup (from static constructors or it is `main()'). EXIT is 33881 true when function is known to be used only at exit (from static 33882 destructors). Return NULL if function should go to default text 33883 section. 33884 33885 -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE 33886 *FILE, tree DECL, bool NEW_IS_COLD) 33887 Used by the target to emit any assembler directives or additional 33888 labels needed when a function is partitioned between different 33889 sections. Output should be written to FILE. The function decl 33890 is available as DECL and the new section is `cold' if NEW_IS_COLD 33891 is `true'. 33892 33893 -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 33894 This flag is true if the target supports 33895 `TARGET_ASM_NAMED_SECTION'. It must not be modified by 33896 command-line option processing. 33897 33898 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 33899 This flag is true if we can create zeroed data by switching to a 33900 BSS section and then using `ASM_OUTPUT_SKIP' to allocate the space. 33901 This is true on most ELF targets. 33902 33903 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 33904 const char *NAME, int RELOC) 33905 Choose a set of section attributes for use by 33906 `TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 33907 section name, and whether or not the declaration's initializer may 33908 contain runtime relocations. DECL may be null, in which case 33909 read-write data should be assumed. 33910 33911 The default version of this function handles choosing code vs data, 33912 read-only vs read-write data, and `flag_pic'. You should only 33913 need to override this if your target has special flags that might 33914 be set via `__attribute__'. 33915 33916 -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type 33917 TYPE, const char *TEXT) 33918 Provides the target with the ability to record the gcc command line 33919 switches that have been passed to the compiler, and options that 33920 are enabled. The TYPE argument specifies what is being recorded. 33921 It can take the following values: 33922 33923 `SWITCH_TYPE_PASSED' 33924 TEXT is a command line switch that has been set by the user. 33925 33926 `SWITCH_TYPE_ENABLED' 33927 TEXT is an option which has been enabled. This might be as a 33928 direct result of a command line switch, or because it is 33929 enabled by default or because it has been enabled as a side 33930 effect of a different command line switch. For example, the 33931 `-O2' switch enables various different individual 33932 optimization passes. 33933 33934 `SWITCH_TYPE_DESCRIPTIVE' 33935 TEXT is either NULL or some descriptive text which should be 33936 ignored. If TEXT is NULL then it is being used to warn the 33937 target hook that either recording is starting or ending. The 33938 first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL, 33939 the warning is for start up and the second time the warning 33940 is for wind down. This feature is to allow the target hook 33941 to make any necessary preparations before it starts to record 33942 switches and to perform any necessary tidying up after it has 33943 finished recording switches. 33944 33945 `SWITCH_TYPE_LINE_START' 33946 This option can be ignored by this target hook. 33947 33948 `SWITCH_TYPE_LINE_END' 33949 This option can be ignored by this target hook. 33950 33951 The hook's return value must be zero. Other return values may be 33952 supported in the future. 33953 33954 By default this hook is set to NULL, but an example implementation 33955 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 33956 it records the switches as ASCII text inside a new, string 33957 mergeable section in the assembler output file. The name of the 33958 new section is provided by the 33959 `TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 33960 33961 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 33962 This is the name of the section that will be created by the example 33963 ELF implementation of the `TARGET_ASM_RECORD_GCC_SWITCHES' target 33964 hook. 33965 33966 33967 File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 33968 33969 17.21.2 Output of Data 33970 ---------------------- 33971 33972 -- Target Hook: const char * TARGET_ASM_BYTE_OP 33973 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 33974 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 33975 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 33976 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 33977 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 33978 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 33979 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 33980 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 33981 These hooks specify assembly directives for creating certain kinds 33982 of integer object. The `TARGET_ASM_BYTE_OP' directive creates a 33983 byte-sized object, the `TARGET_ASM_ALIGNED_HI_OP' one creates an 33984 aligned two-byte object, and so on. Any of the hooks may be 33985 `NULL', indicating that no suitable directive is available. 33986 33987 The compiler will print these strings at the start of a new line, 33988 followed immediately by the object's initial value. In most cases, 33989 the string should contain a tab, a pseudo-op, and then another tab. 33990 33991 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 33992 ALIGNED_P) 33993 The `assemble_integer' function uses this hook to output an 33994 integer object. X is the object's value, SIZE is its size in 33995 bytes and ALIGNED_P indicates whether it is aligned. The function 33996 should return `true' if it was able to output the object. If it 33997 returns false, `assemble_integer' will try to split the object 33998 into smaller parts. 33999 34000 The default implementation of this hook will use the 34001 `TARGET_ASM_BYTE_OP' family of strings, returning `false' when the 34002 relevant string is `NULL'. 34003 34004 -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE, 34005 rtx X) 34006 A target hook to recognize RTX patterns that `output_addr_const' 34007 can't deal with, and output assembly code to FILE corresponding to 34008 the pattern X. This may be used to allow machine-dependent 34009 `UNSPEC's to appear within constants. 34010 34011 If target hook fails to recognize a pattern, it must return 34012 `false', so that a standard error message is printed. If it 34013 prints an error message itself, by calling, for example, 34014 `output_operand_lossage', it may just return `true'. 34015 34016 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 34017 A C statement to output to the stdio stream STREAM an assembler 34018 instruction to assemble a string constant containing the LEN bytes 34019 at PTR. PTR will be a C expression of type `char *' and LEN a C 34020 expression of type `int'. 34021 34022 If the assembler has a `.ascii' pseudo-op as found in the Berkeley 34023 Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'. 34024 34025 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 34026 A C statement to output word N of a function descriptor for DECL. 34027 This must be defined if `TARGET_VTABLE_USES_DESCRIPTORS' is 34028 defined, and is otherwise unused. 34029 34030 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 34031 You may define this macro as a C expression. You should define the 34032 expression to have a nonzero value if GCC should output the 34033 constant pool for a function before the code for the function, or 34034 a zero value if GCC should output the constant pool after the 34035 function. If you do not define this macro, the usual case, GCC 34036 will output the constant pool before the function. 34037 34038 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 34039 A C statement to output assembler commands to define the start of 34040 the constant pool for a function. FUNNAME is a string giving the 34041 name of the function. Should the return type of the function be 34042 required, it can be obtained via FUNDECL. SIZE is the size, in 34043 bytes, of the constant pool that will be written immediately after 34044 this call. 34045 34046 If no constant-pool prefix is required, the usual case, this macro 34047 need not be defined. 34048 34049 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, 34050 LABELNO, JUMPTO) 34051 A C statement (with or without semicolon) to output a constant in 34052 the constant pool, if it needs special treatment. (This macro 34053 need not do anything for RTL expressions that can be output 34054 normally.) 34055 34056 The argument FILE is the standard I/O stream to output the 34057 assembler code on. X is the RTL expression for the constant to 34058 output, and MODE is the machine mode (in case X is a `const_int'). 34059 ALIGN is the required alignment for the value X; you should output 34060 an assembler directive to force this much alignment. 34061 34062 The argument LABELNO is a number to use in an internal label for 34063 the address of this pool entry. The definition of this macro is 34064 responsible for outputting the label definition at the proper 34065 place. Here is how to do this: 34066 34067 `(*targetm.asm_out.internal_label)' (FILE, "LC", LABELNO); 34068 34069 When you output a pool entry specially, you should end with a 34070 `goto' to the label JUMPTO. This will prevent the same pool entry 34071 from being output a second time in the usual manner. 34072 34073 You need not define this macro if it would do nothing. 34074 34075 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 34076 A C statement to output assembler commands to at the end of the 34077 constant pool for a function. FUNNAME is a string giving the name 34078 of the function. Should the return type of the function be 34079 required, you can obtain it via FUNDECL. SIZE is the size, in 34080 bytes, of the constant pool that GCC wrote immediately before this 34081 call. 34082 34083 If no constant-pool epilogue is required, the usual case, you need 34084 not define this macro. 34085 34086 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 34087 Define this macro as a C expression which is nonzero if C is used 34088 as a logical line separator by the assembler. STR points to the 34089 position in the string where C was found; this can be used if a 34090 line separator uses multiple characters. 34091 34092 If you do not define this macro, the default is that only the 34093 character `;' is treated as a logical line separator. 34094 34095 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 34096 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 34097 These target hooks are C string constants, describing the syntax 34098 in the assembler for grouping arithmetic expressions. If not 34099 overridden, they default to normal parentheses, which is correct 34100 for most assemblers. 34101 34102 These macros are provided by `real.h' for writing the definitions of 34103 `ASM_OUTPUT_DOUBLE' and the like: 34104 34105 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 34106 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 34107 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 34108 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 34109 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 34110 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 34111 These translate X, of type `REAL_VALUE_TYPE', to the target's 34112 floating point representation, and store its bit pattern in the 34113 variable L. For `REAL_VALUE_TO_TARGET_SINGLE' and 34114 `REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 34115 `long int'. For the others, it should be an array of `long int'. 34116 The number of elements in this array is determined by the size of 34117 the desired target floating point data type: 32 bits of it go in 34118 each `long int' array element. Each array element holds 32 bits 34119 of the result, even if `long int' is wider than 32 bits on the 34120 host machine. 34121 34122 The array element values are designed so that you can print them 34123 out using `fprintf' in the order they should appear in the target 34124 machine's memory. 34125 34126 34127 File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 34128 34129 17.21.3 Output of Uninitialized Variables 34130 ----------------------------------------- 34131 34132 Each of the macros in this section is used to do the whole job of 34133 outputting a single uninitialized variable. 34134 34135 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 34136 A C statement (sans semicolon) to output to the stdio stream 34137 STREAM the assembler definition of a common-label named NAME whose 34138 size is SIZE bytes. The variable ROUNDED is the size rounded up 34139 to whatever alignment the caller wants. It is possible that SIZE 34140 may be zero, for instance if a struct with no other member than a 34141 zero-length array is defined. In this case, the backend must 34142 output a symbol definition that allocates at least one byte, both 34143 so that the address of the resulting object does not compare equal 34144 to any other, and because some object formats cannot even express 34145 the concept of a zero-sized common symbol, as that is how they 34146 represent an ordinary undefined external. 34147 34148 Use the expression `assemble_name (STREAM, NAME)' to output the 34149 name itself; before and after that, output the additional 34150 assembler syntax for defining the name, and a newline. 34151 34152 This macro controls how the assembler definitions of uninitialized 34153 common global variables are output. 34154 34155 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 34156 Like `ASM_OUTPUT_COMMON' except takes the required alignment as a 34157 separate, explicit argument. If you define this macro, it is used 34158 in place of `ASM_OUTPUT_COMMON', and gives you more flexibility in 34159 handling the required alignment of the variable. The alignment is 34160 specified as the number of bits. 34161 34162 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 34163 ALIGNMENT) 34164 Like `ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 34165 to be output, if there is one, or `NULL_TREE' if there is no 34166 corresponding variable. If you define this macro, GCC will use it 34167 in place of both `ASM_OUTPUT_COMMON' and 34168 `ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 34169 see the variable's decl in order to chose what to output. 34170 34171 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 34172 A C statement (sans semicolon) to output to the stdio stream 34173 STREAM the assembler definition of uninitialized global DECL named 34174 NAME whose size is SIZE bytes. The variable ALIGNMENT is the 34175 alignment specified as the number of bits. 34176 34177 Try to use function `asm_output_aligned_bss' defined in file 34178 `varasm.c' when defining this macro. If unable, use the expression 34179 `assemble_name (STREAM, NAME)' to output the name itself; before 34180 and after that, output the additional assembler syntax for defining 34181 the name, and a newline. 34182 34183 There are two ways of handling global BSS. One is to define this 34184 macro. The other is to have `TARGET_ASM_SELECT_SECTION' return a 34185 switchable BSS section (*note 34186 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 34187 both. 34188 34189 Some languages do not have `common' data, and require a non-common 34190 form of global BSS in order to handle uninitialized globals 34191 efficiently. C++ is one example of this. However, if the target 34192 does not support global BSS, the front end may choose to make 34193 globals common in order to save space in the object file. 34194 34195 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 34196 A C statement (sans semicolon) to output to the stdio stream 34197 STREAM the assembler definition of a local-common-label named NAME 34198 whose size is SIZE bytes. The variable ROUNDED is the size 34199 rounded up to whatever alignment the caller wants. 34200 34201 Use the expression `assemble_name (STREAM, NAME)' to output the 34202 name itself; before and after that, output the additional 34203 assembler syntax for defining the name, and a newline. 34204 34205 This macro controls how the assembler definitions of uninitialized 34206 static variables are output. 34207 34208 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 34209 Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a 34210 separate, explicit argument. If you define this macro, it is used 34211 in place of `ASM_OUTPUT_LOCAL', and gives you more flexibility in 34212 handling the required alignment of the variable. The alignment is 34213 specified as the number of bits. 34214 34215 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 34216 ALIGNMENT) 34217 Like `ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to 34218 be output, if there is one, or `NULL_TREE' if there is no 34219 corresponding variable. If you define this macro, GCC will use it 34220 in place of both `ASM_OUTPUT_DECL' and `ASM_OUTPUT_ALIGNED_DECL'. 34221 Define this macro when you need to see the variable's decl in 34222 order to chose what to output. 34223 34224 34225 File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 34226 34227 17.21.4 Output and Generation of Labels 34228 --------------------------------------- 34229 34230 This is about outputting labels. 34231 34232 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 34233 A C statement (sans semicolon) to output to the stdio stream 34234 STREAM the assembler definition of a label named NAME. Use the 34235 expression `assemble_name (STREAM, NAME)' to output the name 34236 itself; before and after that, output the additional assembler 34237 syntax for defining the name, and a newline. A default definition 34238 of this macro is provided which is correct for most systems. 34239 34240 -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL) 34241 A C statement (sans semicolon) to output to the stdio stream 34242 STREAM the assembler definition of a label named NAME of a 34243 function. Use the expression `assemble_name (STREAM, NAME)' to 34244 output the name itself; before and after that, output the 34245 additional assembler syntax for defining the name, and a newline. 34246 A default definition of this macro is provided which is correct 34247 for most systems. 34248 34249 If this macro is not defined, then the function name is defined in 34250 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 34251 34252 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 34253 Identical to `ASM_OUTPUT_LABEL', except that NAME is known to 34254 refer to a compiler-generated label. The default definition uses 34255 `assemble_name_raw', which is like `assemble_name' except that it 34256 is more efficient. 34257 34258 -- Macro: SIZE_ASM_OP 34259 A C string containing the appropriate assembler directive to 34260 specify the size of a symbol, without any arguments. On systems 34261 that use ELF, the default (in `config/elfos.h') is `"\t.size\t"'; 34262 on other systems, the default is not to define this macro. 34263 34264 Define this macro only if it is correct to use the default 34265 definitions of `ASM_OUTPUT_SIZE_DIRECTIVE' and 34266 `ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 34267 custom definitions of those macros, or if you do not need explicit 34268 symbol sizes at all, do not define this macro. 34269 34270 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 34271 A C statement (sans semicolon) to output to the stdio stream 34272 STREAM a directive telling the assembler that the size of the 34273 symbol NAME is SIZE. SIZE is a `HOST_WIDE_INT'. If you define 34274 `SIZE_ASM_OP', a default definition of this macro is provided. 34275 34276 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 34277 A C statement (sans semicolon) to output to the stdio stream 34278 STREAM a directive telling the assembler to calculate the size of 34279 the symbol NAME by subtracting its address from the current 34280 address. 34281 34282 If you define `SIZE_ASM_OP', a default definition of this macro is 34283 provided. The default assumes that the assembler recognizes a 34284 special `.' symbol as referring to the current address, and can 34285 calculate the difference between this and another symbol. If your 34286 assembler does not recognize `.' or cannot do calculations with 34287 it, you will need to redefine `ASM_OUTPUT_MEASURED_SIZE' to use 34288 some other technique. 34289 34290 -- Macro: NO_DOLLAR_IN_LABEL 34291 Define this macro if the assembler does not accept the character 34292 `$' in label names. By default constructors and destructors in 34293 G++ have `$' in the identifiers. If this macro is defined, `.' is 34294 used instead. 34295 34296 -- Macro: NO_DOT_IN_LABEL 34297 Define this macro if the assembler does not accept the character 34298 `.' in label names. By default constructors and destructors in G++ 34299 have names that use `.'. If this macro is defined, these names 34300 are rewritten to avoid `.'. 34301 34302 -- Macro: TYPE_ASM_OP 34303 A C string containing the appropriate assembler directive to 34304 specify the type of a symbol, without any arguments. On systems 34305 that use ELF, the default (in `config/elfos.h') is `"\t.type\t"'; 34306 on other systems, the default is not to define this macro. 34307 34308 Define this macro only if it is correct to use the default 34309 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 34310 need your own custom definition of this macro, or if you do not 34311 need explicit symbol types at all, do not define this macro. 34312 34313 -- Macro: TYPE_OPERAND_FMT 34314 A C string which specifies (using `printf' syntax) the format of 34315 the second operand to `TYPE_ASM_OP'. On systems that use ELF, the 34316 default (in `config/elfos.h') is `"@%s"'; on other systems, the 34317 default is not to define this macro. 34318 34319 Define this macro only if it is correct to use the default 34320 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 34321 need your own custom definition of this macro, or if you do not 34322 need explicit symbol types at all, do not define this macro. 34323 34324 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 34325 A C statement (sans semicolon) to output to the stdio stream 34326 STREAM a directive telling the assembler that the type of the 34327 symbol NAME is TYPE. TYPE is a C string; currently, that string 34328 is always either `"function"' or `"object"', but you should not 34329 count on this. 34330 34331 If you define `TYPE_ASM_OP' and `TYPE_OPERAND_FMT', a default 34332 definition of this macro is provided. 34333 34334 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 34335 A C statement (sans semicolon) to output to the stdio stream 34336 STREAM any text necessary for declaring the name NAME of a 34337 function which is being defined. This macro is responsible for 34338 outputting the label definition (perhaps using 34339 `ASM_OUTPUT_FUNCTION_LABEL'). The argument DECL is the 34340 `FUNCTION_DECL' tree node representing the function. 34341 34342 If this macro is not defined, then the function name is defined in 34343 the usual manner as a label (by means of 34344 `ASM_OUTPUT_FUNCTION_LABEL'). 34345 34346 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 34347 of this macro. 34348 34349 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 34350 A C statement (sans semicolon) to output to the stdio stream 34351 STREAM any text necessary for declaring the size of a function 34352 which is being defined. The argument NAME is the name of the 34353 function. The argument DECL is the `FUNCTION_DECL' tree node 34354 representing the function. 34355 34356 If this macro is not defined, then the function size is not 34357 defined. 34358 34359 You may wish to use `ASM_OUTPUT_MEASURED_SIZE' in the definition 34360 of this macro. 34361 34362 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 34363 A C statement (sans semicolon) to output to the stdio stream 34364 STREAM any text necessary for declaring the name NAME of an 34365 initialized variable which is being defined. This macro must 34366 output the label definition (perhaps using `ASM_OUTPUT_LABEL'). 34367 The argument DECL is the `VAR_DECL' tree node representing the 34368 variable. 34369 34370 If this macro is not defined, then the variable name is defined in 34371 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 34372 34373 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' and/or 34374 `ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 34375 34376 -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE, 34377 const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE) 34378 A target hook to output to the stdio stream FILE any text necessary 34379 for declaring the name NAME of a constant which is being defined. 34380 This target hook is responsible for outputting the label 34381 definition (perhaps using `assemble_label'). The argument EXP is 34382 the value of the constant, and SIZE is the size of the constant in 34383 bytes. The NAME will be an internal label. 34384 34385 The default version of this target hook, define the NAME in the 34386 usual manner as a label (by means of `assemble_label'). 34387 34388 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in this target 34389 hook. 34390 34391 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 34392 A C statement (sans semicolon) to output to the stdio stream 34393 STREAM any text necessary for claiming a register REGNO for a 34394 global variable DECL with name NAME. 34395 34396 If you don't define this macro, that is equivalent to defining it 34397 to do nothing. 34398 34399 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 34400 A C statement (sans semicolon) to finish up declaring a variable 34401 name once the compiler has processed its initializer fully and 34402 thus has had a chance to determine the size of an array when 34403 controlled by an initializer. This is used on systems where it's 34404 necessary to declare something about the size of the object. 34405 34406 If you don't define this macro, that is equivalent to defining it 34407 to do nothing. 34408 34409 You may wish to use `ASM_OUTPUT_SIZE_DIRECTIVE' and/or 34410 `ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 34411 34412 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 34413 char *NAME) 34414 This target hook is a function to output to the stdio stream 34415 STREAM some commands that will make the label NAME global; that 34416 is, available for reference from other files. 34417 34418 The default implementation relies on a proper definition of 34419 `GLOBAL_ASM_OP'. 34420 34421 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, 34422 tree DECL) 34423 This target hook is a function to output to the stdio stream 34424 STREAM some commands that will make the name associated with DECL 34425 global; that is, available for reference from other files. 34426 34427 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 34428 target hook. 34429 34430 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 34431 A C statement (sans semicolon) to output to the stdio stream 34432 STREAM some commands that will make the label NAME weak; that is, 34433 available for reference from other files but only used if no other 34434 definition is available. Use the expression `assemble_name 34435 (STREAM, NAME)' to output the name itself; before and after that, 34436 output the additional assembler syntax for making that name weak, 34437 and a newline. 34438 34439 If you don't define this macro or `ASM_WEAKEN_DECL', GCC will not 34440 support weak symbols and you should not define the `SUPPORTS_WEAK' 34441 macro. 34442 34443 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 34444 Combines (and replaces) the function of `ASM_WEAKEN_LABEL' and 34445 `ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 34446 or variable decl. If VALUE is not `NULL', this C statement should 34447 output to the stdio stream STREAM assembler code which defines 34448 (equates) the weak symbol NAME to have the value VALUE. If VALUE 34449 is `NULL', it should output commands to make NAME weak. 34450 34451 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 34452 Outputs a directive that enables NAME to be used to refer to 34453 symbol VALUE with weak-symbol semantics. `decl' is the 34454 declaration of `name'. 34455 34456 -- Macro: SUPPORTS_WEAK 34457 A preprocessor constant expression which evaluates to true if the 34458 target supports weak symbols. 34459 34460 If you don't define this macro, `defaults.h' provides a default 34461 definition. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is 34462 defined, the default definition is `1'; otherwise, it is `0'. 34463 34464 -- Macro: TARGET_SUPPORTS_WEAK 34465 A C expression which evaluates to true if the target supports weak 34466 symbols. 34467 34468 If you don't define this macro, `defaults.h' provides a default 34469 definition. The default definition is `(SUPPORTS_WEAK)'. Define 34470 this macro if you want to control weak symbol support with a 34471 compiler flag such as `-melf'. 34472 34473 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 34474 A C statement (sans semicolon) to mark DECL to be emitted as a 34475 public symbol such that extra copies in multiple translation units 34476 will be discarded by the linker. Define this macro if your object 34477 file format provides support for this concept, such as the `COMDAT' 34478 section flags in the Microsoft Windows PE/COFF format, and this 34479 support requires changes to DECL, such as putting it in a separate 34480 section. 34481 34482 -- Macro: SUPPORTS_ONE_ONLY 34483 A C expression which evaluates to true if the target supports 34484 one-only semantics. 34485 34486 If you don't define this macro, `varasm.c' provides a default 34487 definition. If `MAKE_DECL_ONE_ONLY' is defined, the default 34488 definition is `1'; otherwise, it is `0'. Define this macro if you 34489 want to control one-only symbol support with a compiler flag, or if 34490 setting the `DECL_ONE_ONLY' flag is enough to mark a declaration to 34491 be emitted as one-only. 34492 34493 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 34494 VISIBILITY) 34495 This target hook is a function to output to ASM_OUT_FILE some 34496 commands that will make the symbol(s) associated with DECL have 34497 hidden, protected or internal visibility as specified by 34498 VISIBILITY. 34499 34500 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 34501 A C expression that evaluates to true if the target's linker 34502 expects that weak symbols do not appear in a static archive's 34503 table of contents. The default is `0'. 34504 34505 Leaving weak symbols out of an archive's table of contents means 34506 that, if a symbol will only have a definition in one translation 34507 unit and will have undefined references from other translation 34508 units, that symbol should not be weak. Defining this macro to be 34509 nonzero will thus have the effect that certain symbols that would 34510 normally be weak (explicit template instantiations, and vtables 34511 for polymorphic classes with noninline key methods) will instead 34512 be nonweak. 34513 34514 The C++ ABI requires this macro to be zero. Define this macro for 34515 targets where full C++ ABI compliance is impossible and where 34516 linker restrictions require weak symbols to be left out of a 34517 static archive's table of contents. 34518 34519 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 34520 A C statement (sans semicolon) to output to the stdio stream 34521 STREAM any text necessary for declaring the name of an external 34522 symbol named NAME which is referenced in this compilation but not 34523 defined. The value of DECL is the tree node for the declaration. 34524 34525 This macro need not be defined if it does not need to output 34526 anything. The GNU assembler and most Unix assemblers don't 34527 require anything. 34528 34529 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 34530 This target hook is a function to output to ASM_OUT_FILE an 34531 assembler pseudo-op to declare a library function name external. 34532 The name of the library function is given by SYMREF, which is a 34533 `symbol_ref'. 34534 34535 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 34536 *SYMBOL) 34537 This target hook is a function to output to ASM_OUT_FILE an 34538 assembler directive to annotate SYMBOL as used. The Darwin target 34539 uses the .no_dead_code_strip directive. 34540 34541 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 34542 A C statement (sans semicolon) to output to the stdio stream 34543 STREAM a reference in assembler syntax to a label named NAME. 34544 This should add `_' to the front of the name, if that is customary 34545 on your operating system, as it is in most Berkeley Unix systems. 34546 This macro is used in `assemble_name'. 34547 34548 -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME) 34549 Given a symbol NAME, perform same mangling as `varasm.c''s 34550 `assemble_name', but in memory rather than to a file stream, 34551 returning result as an `IDENTIFIER_NODE'. Required for correct 34552 LTO symtabs. The default implementation calls the 34553 `TARGET_STRIP_NAME_ENCODING' hook and then prepends the 34554 `USER_LABEL_PREFIX', if any. 34555 34556 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 34557 A C statement (sans semicolon) to output a reference to 34558 `SYMBOL_REF' SYM. If not defined, `assemble_name' will be used to 34559 output the name of the symbol. This macro may be used to modify 34560 the way a symbol is referenced depending on information encoded by 34561 `TARGET_ENCODE_SECTION_INFO'. 34562 34563 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 34564 A C statement (sans semicolon) to output a reference to BUF, the 34565 result of `ASM_GENERATE_INTERNAL_LABEL'. If not defined, 34566 `assemble_name' will be used to output the name of the symbol. 34567 This macro is not used by `output_asm_label', or the `%l' 34568 specifier that calls it; the intention is that this macro should 34569 be set when it is necessary to output a label differently when its 34570 address is being taken. 34571 34572 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 34573 char *PREFIX, unsigned long LABELNO) 34574 A function to output to the stdio stream STREAM a label whose name 34575 is made from the string PREFIX and the number LABELNO. 34576 34577 It is absolutely essential that these labels be distinct from the 34578 labels used for user-level functions and variables. Otherwise, 34579 certain programs will have name conflicts with internal labels. 34580 34581 It is desirable to exclude internal labels from the symbol table 34582 of the object file. Most assemblers have a naming convention for 34583 labels that should be excluded; on many systems, the letter `L' at 34584 the beginning of a label has this effect. You should find out what 34585 convention your system uses, and follow it. 34586 34587 The default version of this function utilizes 34588 `ASM_GENERATE_INTERNAL_LABEL'. 34589 34590 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 34591 A C statement to output to the stdio stream STREAM a debug info 34592 label whose name is made from the string PREFIX and the number 34593 NUM. This is useful for VLIW targets, where debug info labels may 34594 need to be treated differently than branch target labels. On some 34595 systems, branch target labels must be at the beginning of 34596 instruction bundles, but debug info labels can occur in the middle 34597 of instruction bundles. 34598 34599 If this macro is not defined, then 34600 `(*targetm.asm_out.internal_label)' will be used. 34601 34602 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 34603 A C statement to store into the string STRING a label whose name 34604 is made from the string PREFIX and the number NUM. 34605 34606 This string, when output subsequently by `assemble_name', should 34607 produce the output that `(*targetm.asm_out.internal_label)' would 34608 produce with the same PREFIX and NUM. 34609 34610 If the string begins with `*', then `assemble_name' will output 34611 the rest of the string unchanged. It is often convenient for 34612 `ASM_GENERATE_INTERNAL_LABEL' to use `*' in this way. If the 34613 string doesn't start with `*', then `ASM_OUTPUT_LABELREF' gets to 34614 output the string, and may change it. (Of course, 34615 `ASM_OUTPUT_LABELREF' is also part of your machine description, so 34616 you should know what it does on your machine.) 34617 34618 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 34619 A C expression to assign to OUTVAR (which is a variable of type 34620 `char *') a newly allocated string made from the string NAME and 34621 the number NUMBER, with some suitable punctuation added. Use 34622 `alloca' to get space for the string. 34623 34624 The string will be used as an argument to `ASM_OUTPUT_LABELREF' to 34625 produce an assembler label for an internal static variable whose 34626 name is NAME. Therefore, the string must be such as to result in 34627 valid assembler code. The argument NUMBER is different each time 34628 this macro is executed; it prevents conflicts between 34629 similarly-named internal static variables in different scopes. 34630 34631 Ideally this string should not be a valid C identifier, to prevent 34632 any conflict with the user's own symbols. Most assemblers allow 34633 periods or percent signs in assembler symbols; putting at least 34634 one of these between the name and the number will suffice. 34635 34636 If this macro is not defined, a default definition will be provided 34637 which is correct for most systems. 34638 34639 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 34640 A C statement to output to the stdio stream STREAM assembler code 34641 which defines (equates) the symbol NAME to have the value VALUE. 34642 34643 If `SET_ASM_OP' is defined, a default definition is provided which 34644 is correct for most systems. 34645 34646 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 34647 DECL_OF_VALUE) 34648 A C statement to output to the stdio stream STREAM assembler code 34649 which defines (equates) the symbol whose tree node is DECL_OF_NAME 34650 to have the value of the tree node DECL_OF_VALUE. This macro will 34651 be used in preference to `ASM_OUTPUT_DEF' if it is defined and if 34652 the tree nodes are available. 34653 34654 If `SET_ASM_OP' is defined, a default definition is provided which 34655 is correct for most systems. 34656 34657 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 34658 A C statement that evaluates to true if the assembler code which 34659 defines (equates) the symbol whose tree node is DECL_OF_NAME to 34660 have the value of the tree node DECL_OF_VALUE should be emitted 34661 near the end of the current compilation unit. The default is to 34662 not defer output of defines. This macro affects defines output by 34663 `ASM_OUTPUT_DEF' and `ASM_OUTPUT_DEF_FROM_DECLS'. 34664 34665 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 34666 A C statement to output to the stdio stream STREAM assembler code 34667 which defines (equates) the weak symbol NAME to have the value 34668 VALUE. If VALUE is `NULL', it defines NAME as an undefined weak 34669 symbol. 34670 34671 Define this macro if the target only supports weak aliases; define 34672 `ASM_OUTPUT_DEF' instead if possible. 34673 34674 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 34675 SEL_NAME) 34676 Define this macro to override the default assembler names used for 34677 Objective-C methods. 34678 34679 The default name is a unique method number followed by the name of 34680 the class (e.g. `_1_Foo'). For methods in categories, the name of 34681 the category is also included in the assembler name (e.g. 34682 `_1_Foo_Bar'). 34683 34684 These names are safe on most systems, but make debugging difficult 34685 since the method's selector is not present in the name. 34686 Therefore, particular systems define other ways of computing names. 34687 34688 BUF is an expression of type `char *' which gives you a buffer in 34689 which to store the name; its length is as long as CLASS_NAME, 34690 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 34691 34692 The argument IS_INST specifies whether the method is an instance 34693 method or a class method; CLASS_NAME is the name of the class; 34694 CAT_NAME is the name of the category (or `NULL' if the method is 34695 not in a category); and SEL_NAME is the name of the selector. 34696 34697 On systems where the assembler can handle quoted names, you can 34698 use this macro to provide more human-readable names. 34699 34700 34701 File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 34702 34703 17.21.5 How Initialization Functions Are Handled 34704 ------------------------------------------------ 34705 34706 The compiled code for certain languages includes "constructors" (also 34707 called "initialization routines")--functions to initialize data in the 34708 program when the program is started. These functions need to be called 34709 before the program is "started"--that is to say, before `main' is 34710 called. 34711 34712 Compiling some languages generates "destructors" (also called 34713 "termination routines") that should be called when the program 34714 terminates. 34715 34716 To make the initialization and termination functions work, the compiler 34717 must output something in the assembler code to cause those functions to 34718 be called at the appropriate time. When you port the compiler to a new 34719 system, you need to specify how to do this. 34720 34721 There are two major ways that GCC currently supports the execution of 34722 initialization and termination functions. Each way has two variants. 34723 Much of the structure is common to all four variations. 34724 34725 The linker must build two lists of these functions--a list of 34726 initialization functions, called `__CTOR_LIST__', and a list of 34727 termination functions, called `__DTOR_LIST__'. 34728 34729 Each list always begins with an ignored function pointer (which may 34730 hold 0, -1, or a count of the function pointers after it, depending on 34731 the environment). This is followed by a series of zero or more function 34732 pointers to constructors (or destructors), followed by a function 34733 pointer containing zero. 34734 34735 Depending on the operating system and its executable file format, 34736 either `crtstuff.c' or `libgcc2.c' traverses these lists at startup 34737 time and exit time. Constructors are called in reverse order of the 34738 list; destructors in forward order. 34739 34740 The best way to handle static constructors works only for object file 34741 formats which provide arbitrarily-named sections. A section is set 34742 aside for a list of constructors, and another for a list of destructors. 34743 Traditionally these are called `.ctors' and `.dtors'. Each object file 34744 that defines an initialization function also puts a word in the 34745 constructor section to point to that function. The linker accumulates 34746 all these words into one contiguous `.ctors' section. Termination 34747 functions are handled similarly. 34748 34749 This method will be chosen as the default by `target-def.h' if 34750 `TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 34751 arbitrary sections, but does support special designated constructor and 34752 destructor sections may define `CTORS_SECTION_ASM_OP' and 34753 `DTORS_SECTION_ASM_OP' to achieve the same effect. 34754 34755 When arbitrary sections are available, there are two variants, 34756 depending upon how the code in `crtstuff.c' is called. On systems that 34757 support a ".init" section which is executed at program startup, parts 34758 of `crtstuff.c' are compiled into that section. The program is linked 34759 by the `gcc' driver like this: 34760 34761 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 34762 34763 The prologue of a function (`__init') appears in the `.init' section 34764 of `crti.o'; the epilogue appears in `crtn.o'. Likewise for the 34765 function `__fini' in the ".fini" section. Normally these files are 34766 provided by the operating system or by the GNU C library, but are 34767 provided by GCC for a few targets. 34768 34769 The objects `crtbegin.o' and `crtend.o' are (for most targets) 34770 compiled from `crtstuff.c'. They contain, among other things, code 34771 fragments within the `.init' and `.fini' sections that branch to 34772 routines in the `.text' section. The linker will pull all parts of a 34773 section together, which results in a complete `__init' function that 34774 invokes the routines we need at startup. 34775 34776 To use this variant, you must define the `INIT_SECTION_ASM_OP' macro 34777 properly. 34778 34779 If no init section is available, when GCC compiles any function called 34780 `main' (or more accurately, any function designated as a program entry 34781 point by the language front end calling `expand_main_function'), it 34782 inserts a procedure call to `__main' as the first executable code after 34783 the function prologue. The `__main' function is defined in `libgcc2.c' 34784 and runs the global constructors. 34785 34786 In file formats that don't support arbitrary sections, there are again 34787 two variants. In the simplest variant, the GNU linker (GNU `ld') and 34788 an `a.out' format must be used. In this case, `TARGET_ASM_CONSTRUCTOR' 34789 is defined to produce a `.stabs' entry of type `N_SETT', referencing 34790 the name `__CTOR_LIST__', and with the address of the void function 34791 containing the initialization code as its value. The GNU linker 34792 recognizes this as a request to add the value to a "set"; the values 34793 are accumulated, and are eventually placed in the executable as a 34794 vector in the format described above, with a leading (ignored) count 34795 and a trailing zero element. `TARGET_ASM_DESTRUCTOR' is handled 34796 similarly. Since no init section is available, the absence of 34797 `INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main' 34798 as above, starting the initialization process. 34799 34800 The last variant uses neither arbitrary sections nor the GNU linker. 34801 This is preferable when you want to do dynamic linking and when using 34802 file formats which the GNU linker does not support, such as `ECOFF'. In 34803 this case, `TARGET_HAVE_CTORS_DTORS' is false, initialization and 34804 termination functions are recognized simply by their names. This 34805 requires an extra program in the linkage step, called `collect2'. This 34806 program pretends to be the linker, for use with GCC; it does its job by 34807 running the ordinary linker, but also arranges to include the vectors of 34808 initialization and termination functions. These functions are called 34809 via `__main' as described above. In order to use this method, 34810 `use_collect2' must be defined in the target in `config.gcc'. 34811 34812 The following section describes the specific macros that control and 34813 customize the handling of initialization and termination functions. 34814 34815 34816 File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 34817 34818 17.21.6 Macros Controlling Initialization Routines 34819 -------------------------------------------------- 34820 34821 Here are the macros that control how the compiler handles initialization 34822 and termination functions: 34823 34824 -- Macro: INIT_SECTION_ASM_OP 34825 If defined, a C string constant, including spacing, for the 34826 assembler operation to identify the following data as 34827 initialization code. If not defined, GCC will assume such a 34828 section does not exist. When you are using special sections for 34829 initialization and termination functions, this macro also controls 34830 how `crtstuff.c' and `libgcc2.c' arrange to run the initialization 34831 functions. 34832 34833 -- Macro: HAS_INIT_SECTION 34834 If defined, `main' will not call `__main' as described above. 34835 This macro should be defined for systems that control start-up code 34836 on a symbol-by-symbol basis, such as OSF/1, and should not be 34837 defined explicitly for systems that support `INIT_SECTION_ASM_OP'. 34838 34839 -- Macro: LD_INIT_SWITCH 34840 If defined, a C string constant for a switch that tells the linker 34841 that the following symbol is an initialization routine. 34842 34843 -- Macro: LD_FINI_SWITCH 34844 If defined, a C string constant for a switch that tells the linker 34845 that the following symbol is a finalization routine. 34846 34847 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 34848 If defined, a C statement that will write a function that can be 34849 automatically called when a shared library is loaded. The function 34850 should call FUNC, which takes no arguments. If not defined, and 34851 the object format requires an explicit initialization function, 34852 then a function called `_GLOBAL__DI' will be generated. 34853 34854 This function and the following one are used by collect2 when 34855 linking a shared library that needs constructors or destructors, 34856 or has DWARF2 exception tables embedded in the code. 34857 34858 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 34859 If defined, a C statement that will write a function that can be 34860 automatically called when a shared library is unloaded. The 34861 function should call FUNC, which takes no arguments. If not 34862 defined, and the object format requires an explicit finalization 34863 function, then a function called `_GLOBAL__DD' will be generated. 34864 34865 -- Macro: INVOKE__main 34866 If defined, `main' will call `__main' despite the presence of 34867 `INIT_SECTION_ASM_OP'. This macro should be defined for systems 34868 where the init section is not actually run automatically, but is 34869 still useful for collecting the lists of constructors and 34870 destructors. 34871 34872 -- Macro: SUPPORTS_INIT_PRIORITY 34873 If nonzero, the C++ `init_priority' attribute is supported and the 34874 compiler should emit instructions to control the order of 34875 initialization of objects. If zero, the compiler will issue an 34876 error message upon encountering an `init_priority' attribute. 34877 34878 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 34879 This value is true if the target supports some "native" method of 34880 collecting constructors and destructors to be run at startup and 34881 exit. It is false if we must use `collect2'. 34882 34883 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 34884 If defined, a function that outputs assembler code to arrange to 34885 call the function referenced by SYMBOL at initialization time. 34886 34887 Assume that SYMBOL is a `SYMBOL_REF' for a function taking no 34888 arguments and with no return value. If the target supports 34889 initialization priorities, PRIORITY is a value between 0 and 34890 `MAX_INIT_PRIORITY'; otherwise it must be `DEFAULT_INIT_PRIORITY'. 34891 34892 If this macro is not defined by the target, a suitable default will 34893 be chosen if (1) the target supports arbitrary section names, (2) 34894 the target defines `CTORS_SECTION_ASM_OP', or (3) `USE_COLLECT2' 34895 is not defined. 34896 34897 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 34898 This is like `TARGET_ASM_CONSTRUCTOR' but used for termination 34899 functions rather than initialization functions. 34900 34901 If `TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 34902 generated for the generated object file will have static linkage. 34903 34904 If your system uses `collect2' as the means of processing 34905 constructors, then that program normally uses `nm' to scan an object 34906 file for constructor functions to be called. 34907 34908 On certain kinds of systems, you can define this macro to make 34909 `collect2' work faster (and, in some cases, make it work at all): 34910 34911 -- Macro: OBJECT_FORMAT_COFF 34912 Define this macro if the system uses COFF (Common Object File 34913 Format) object files, so that `collect2' can assume this format 34914 and scan object files directly for dynamic constructor/destructor 34915 functions. 34916 34917 This macro is effective only in a native compiler; `collect2' as 34918 part of a cross compiler always uses `nm' for the target machine. 34919 34920 -- Macro: REAL_NM_FILE_NAME 34921 Define this macro as a C string constant containing the file name 34922 to use to execute `nm'. The default is to search the path 34923 normally for `nm'. 34924 34925 -- Macro: NM_FLAGS 34926 `collect2' calls `nm' to scan object files for static constructors 34927 and destructors and LTO info. By default, `-n' is passed. Define 34928 `NM_FLAGS' to a C string constant if other options are needed to 34929 get the same output format as GNU `nm -n' produces. 34930 34931 If your system supports shared libraries and has a program to list the 34932 dynamic dependencies of a given library or executable, you can define 34933 these macros to enable support for running initialization and 34934 termination functions in shared libraries: 34935 34936 -- Macro: LDD_SUFFIX 34937 Define this macro to a C string constant containing the name of 34938 the program which lists dynamic dependencies, like `ldd' under 34939 SunOS 4. 34940 34941 -- Macro: PARSE_LDD_OUTPUT (PTR) 34942 Define this macro to be C code that extracts filenames from the 34943 output of the program denoted by `LDD_SUFFIX'. PTR is a variable 34944 of type `char *' that points to the beginning of a line of output 34945 from `LDD_SUFFIX'. If the line lists a dynamic dependency, the 34946 code must advance PTR to the beginning of the filename on that 34947 line. Otherwise, it must set PTR to `NULL'. 34948 34949 -- Macro: SHLIB_SUFFIX 34950 Define this macro to a C string constant containing the default 34951 shared library extension of the target (e.g., `".so"'). `collect2' 34952 strips version information after this suffix when generating global 34953 constructor and destructor names. This define is only needed on 34954 targets that use `collect2' to process constructors and 34955 destructors. 34956 34957 34958 File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 34959 34960 17.21.7 Output of Assembler Instructions 34961 ---------------------------------------- 34962 34963 This describes assembler instruction output. 34964 34965 -- Macro: REGISTER_NAMES 34966 A C initializer containing the assembler's names for the machine 34967 registers, each one as a C string constant. This is what 34968 translates register numbers in the compiler into assembler 34969 language. 34970 34971 -- Macro: ADDITIONAL_REGISTER_NAMES 34972 If defined, a C initializer for an array of structures containing 34973 a name and a register number. This macro defines additional names 34974 for hard registers, thus allowing the `asm' option in declarations 34975 to refer to registers using alternate names. 34976 34977 -- Macro: OVERLAPPING_REGISTER_NAMES 34978 If defined, a C initializer for an array of structures containing a 34979 name, a register number and a count of the number of consecutive 34980 machine registers the name overlaps. This macro defines additional 34981 names for hard registers, thus allowing the `asm' option in 34982 declarations to refer to registers using alternate names. Unlike 34983 `ADDITIONAL_REGISTER_NAMES', this macro should be used when the 34984 register name implies multiple underlying registers. 34985 34986 This macro should be used when it is important that a clobber in an 34987 `asm' statement clobbers all the underlying values implied by the 34988 register name. For example, on ARM, clobbering the 34989 double-precision VFP register "d0" implies clobbering both 34990 single-precision registers "s0" and "s1". 34991 34992 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 34993 Define this macro if you are using an unusual assembler that 34994 requires different names for the machine instructions. 34995 34996 The definition is a C statement or statements which output an 34997 assembler instruction opcode to the stdio stream STREAM. The 34998 macro-operand PTR is a variable of type `char *' which points to 34999 the opcode name in its "internal" form--the form that is written 35000 in the machine description. The definition should output the 35001 opcode name to STREAM, performing any translation you desire, and 35002 increment the variable PTR to point at the end of the opcode so 35003 that it will not be output twice. 35004 35005 In fact, your macro definition may process less than the entire 35006 opcode name, or more than the opcode name; but if you want to 35007 process text that includes `%'-sequences to substitute operands, 35008 you must take care of the substitution yourself. Just be sure to 35009 increment PTR over whatever text should not be output normally. 35010 35011 If you need to look at the operand values, they can be found as the 35012 elements of `recog_data.operand'. 35013 35014 If the macro definition does nothing, the instruction is output in 35015 the usual way. 35016 35017 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 35018 If defined, a C statement to be executed just prior to the output 35019 of assembler code for INSN, to modify the extracted operands so 35020 they will be output differently. 35021 35022 Here the argument OPVEC is the vector containing the operands 35023 extracted from INSN, and NOPERANDS is the number of elements of 35024 the vector which contain meaningful data for this insn. The 35025 contents of this vector are what will be used to convert the insn 35026 template into assembler code, so you can change the assembler 35027 output by changing the contents of the vector. 35028 35029 This macro is useful when various assembler syntaxes share a single 35030 file of instruction patterns; by defining this macro differently, 35031 you can cause a large class of instructions to be output 35032 differently (such as with rearranged operands). Naturally, 35033 variations in assembler syntax affecting individual insn patterns 35034 ought to be handled by writing conditional output routines in 35035 those patterns. 35036 35037 If this macro is not defined, it is equivalent to a null statement. 35038 35039 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, rtx 35040 INSN, rtx *OPVEC, int NOPERANDS) 35041 If defined, this target hook is a function which is executed just 35042 after the output of assembler code for INSN, to change the mode of 35043 the assembler if necessary. 35044 35045 Here the argument OPVEC is the vector containing the operands 35046 extracted from INSN, and NOPERANDS is the number of elements of 35047 the vector which contain meaningful data for this insn. The 35048 contents of this vector are what was used to convert the insn 35049 template into assembler code, so you can change the assembler mode 35050 by checking the contents of the vector. 35051 35052 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 35053 A C compound statement to output to stdio stream STREAM the 35054 assembler syntax for an instruction operand X. X is an RTL 35055 expression. 35056 35057 CODE is a value that can be used to specify one of several ways of 35058 printing the operand. It is used when identical operands must be 35059 printed differently depending on the context. CODE comes from the 35060 `%' specification that was used to request printing of the 35061 operand. If the specification was just `%DIGIT' then CODE is 0; 35062 if the specification was `%LTR DIGIT' then CODE is the ASCII code 35063 for LTR. 35064 35065 If X is a register, this macro should print the register's name. 35066 The names can be found in an array `reg_names' whose type is `char 35067 *[]'. `reg_names' is initialized from `REGISTER_NAMES'. 35068 35069 When the machine description has a specification `%PUNCT' (a `%' 35070 followed by a punctuation character), this macro is called with a 35071 null pointer for X and the punctuation character for CODE. 35072 35073 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 35074 A C expression which evaluates to true if CODE is a valid 35075 punctuation character for use in the `PRINT_OPERAND' macro. If 35076 `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 35077 punctuation characters (except for the standard one, `%') are used 35078 in this way. 35079 35080 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 35081 A C compound statement to output to stdio stream STREAM the 35082 assembler syntax for an instruction operand that is a memory 35083 reference whose address is X. X is an RTL expression. 35084 35085 On some machines, the syntax for a symbolic address depends on the 35086 section that the address refers to. On these machines, define the 35087 hook `TARGET_ENCODE_SECTION_INFO' to store the information into the 35088 `symbol_ref', and then check for it here. *Note Assembler 35089 Format::. 35090 35091 -- Macro: DBR_OUTPUT_SEQEND (FILE) 35092 A C statement, to be executed after all slot-filler instructions 35093 have been output. If necessary, call `dbr_sequence_length' to 35094 determine the number of slots filled in a sequence (zero if not 35095 currently outputting a sequence), to decide how many no-ops to 35096 output, or whatever. 35097 35098 Don't define this macro if it has nothing to do, but it is helpful 35099 in reading assembly output if the extent of the delay sequence is 35100 made explicit (e.g. with white space). 35101 35102 Note that output routines for instructions with delay slots must be 35103 prepared to deal with not being output as part of a sequence (i.e. when 35104 the scheduling pass is not run, or when no slot fillers could be 35105 found.) The variable `final_sequence' is null when not processing a 35106 sequence, otherwise it contains the `sequence' rtx being output. 35107 35108 -- Macro: REGISTER_PREFIX 35109 -- Macro: LOCAL_LABEL_PREFIX 35110 -- Macro: USER_LABEL_PREFIX 35111 -- Macro: IMMEDIATE_PREFIX 35112 If defined, C string expressions to be used for the `%R', `%L', 35113 `%U', and `%I' options of `asm_fprintf' (see `final.c'). These 35114 are useful when a single `md' file must support multiple assembler 35115 formats. In that case, the various `tm.h' files can define these 35116 macros differently. 35117 35118 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 35119 If defined this macro should expand to a series of `case' 35120 statements which will be parsed inside the `switch' statement of 35121 the `asm_fprintf' function. This allows targets to define extra 35122 printf formats which may useful when generating their assembler 35123 statements. Note that uppercase letters are reserved for future 35124 generic extensions to asm_fprintf, and so are not available to 35125 target specific code. The output file is given by the parameter 35126 FILE. The varargs input pointer is ARGPTR and the rest of the 35127 format string, starting the character after the one that is being 35128 switched upon, is pointed to by FORMAT. 35129 35130 -- Macro: ASSEMBLER_DIALECT 35131 If your target supports multiple dialects of assembler language 35132 (such as different opcodes), define this macro as a C expression 35133 that gives the numeric index of the assembler language dialect to 35134 use, with zero as the first variant. 35135 35136 If this macro is defined, you may use constructs of the form 35137 `{option0|option1|option2...}' 35138 in the output templates of patterns (*note Output Template::) or 35139 in the first argument of `asm_fprintf'. This construct outputs 35140 `option0', `option1', `option2', etc., if the value of 35141 `ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 35142 within these strings retain their usual meaning. If there are 35143 fewer alternatives within the braces than the value of 35144 `ASSEMBLER_DIALECT', the construct outputs nothing. 35145 35146 If you do not define this macro, the characters `{', `|' and `}' 35147 do not have any special meaning when used in templates or operands 35148 to `asm_fprintf'. 35149 35150 Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX', 35151 `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the 35152 variations in assembler language syntax with that mechanism. 35153 Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax 35154 if the syntax variant are larger and involve such things as 35155 different opcodes or operand order. 35156 35157 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 35158 A C expression to output to STREAM some assembler code which will 35159 push hard register number REGNO onto the stack. The code need not 35160 be optimal, since this macro is used only when profiling. 35161 35162 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 35163 A C expression to output to STREAM some assembler code which will 35164 pop hard register number REGNO off of the stack. The code need 35165 not be optimal, since this macro is used only when profiling. 35166 35167 35168 File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 35169 35170 17.21.8 Output of Dispatch Tables 35171 --------------------------------- 35172 35173 This concerns dispatch tables. 35174 35175 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 35176 A C statement to output to the stdio stream STREAM an assembler 35177 pseudo-instruction to generate a difference between two labels. 35178 VALUE and REL are the numbers of two internal labels. The 35179 definitions of these labels are output using 35180 `(*targetm.asm_out.internal_label)', and they must be printed in 35181 the same way here. For example, 35182 35183 fprintf (STREAM, "\t.word L%d-L%d\n", 35184 VALUE, REL) 35185 35186 You must provide this macro on machines where the addresses in a 35187 dispatch table are relative to the table's own address. If 35188 defined, GCC will also use this macro on all machines when 35189 producing PIC. BODY is the body of the `ADDR_DIFF_VEC'; it is 35190 provided so that the mode and flags can be read. 35191 35192 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 35193 This macro should be provided on machines where the addresses in a 35194 dispatch table are absolute. 35195 35196 The definition should be a C statement to output to the stdio 35197 stream STREAM an assembler pseudo-instruction to generate a 35198 reference to a label. VALUE is the number of an internal label 35199 whose definition is output using 35200 `(*targetm.asm_out.internal_label)'. For example, 35201 35202 fprintf (STREAM, "\t.word L%d\n", VALUE) 35203 35204 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 35205 Define this if the label before a jump-table needs to be output 35206 specially. The first three arguments are the same as for 35207 `(*targetm.asm_out.internal_label)'; the fourth argument is the 35208 jump-table which follows (a `jump_insn' containing an `addr_vec' 35209 or `addr_diff_vec'). 35210 35211 This feature is used on system V to output a `swbeg' statement for 35212 the table. 35213 35214 If this macro is not defined, these labels are output with 35215 `(*targetm.asm_out.internal_label)'. 35216 35217 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 35218 Define this if something special must be output at the end of a 35219 jump-table. The definition should be a C statement to be executed 35220 after the assembler code for the table is written. It should write 35221 the appropriate code to stdio stream STREAM. The argument TABLE 35222 is the jump-table insn, and NUM is the label-number of the 35223 preceding label. 35224 35225 If this macro is not defined, nothing special is output at the end 35226 of the jump-table. 35227 35228 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 35229 DECL, int FOR_EH, int EMPTY) 35230 This target hook emits a label at the beginning of each FDE. It 35231 should be defined on targets where FDEs need special labels, and it 35232 should write the appropriate label, for the FDE associated with the 35233 function declaration DECL, to the stdio stream STREAM. The third 35234 argument, FOR_EH, is a boolean: true if this is for an exception 35235 table. The fourth argument, EMPTY, is a boolean: true if this is 35236 a placeholder label for an omitted FDE. 35237 35238 The default is that FDEs are not given nonlocal labels. 35239 35240 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 35241 This target hook emits a label at the beginning of the exception 35242 table. It should be defined on targets where it is desirable for 35243 the table to be broken up according to function. 35244 35245 The default is that no label is emitted. 35246 35247 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx 35248 PERSONALITY) 35249 If the target implements `TARGET_ASM_UNWIND_EMIT', this hook may 35250 be used to emit a directive to install a personality hook into the 35251 unwind info. This hook should not be used if dwarf2 unwind info 35252 is used. 35253 35254 -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx INSN) 35255 This target hook emits assembly directives required to unwind the 35256 given instruction. This is only used when 35257 `TARGET_EXCEPT_UNWIND_INFO' returns `UI_TARGET'. 35258 35259 -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN 35260 True if the `TARGET_ASM_UNWIND_EMIT' hook should be called before 35261 the assembly for INSN has been emitted, false if the hook should 35262 be called afterward. 35263 35264 35265 File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 35266 35267 17.21.9 Assembler Commands for Exception Regions 35268 ------------------------------------------------ 35269 35270 This describes commands marking the start and the end of an exception 35271 region. 35272 35273 -- Macro: EH_FRAME_SECTION_NAME 35274 If defined, a C string constant for the name of the section 35275 containing exception handling frame unwind information. If not 35276 defined, GCC will provide a default definition if the target 35277 supports named sections. `crtstuff.c' uses this macro to switch 35278 to the appropriate section. 35279 35280 You should define this symbol if your target supports DWARF 2 frame 35281 unwind information and the default definition does not work. 35282 35283 -- Macro: EH_FRAME_IN_DATA_SECTION 35284 If defined, DWARF 2 frame unwind information will be placed in the 35285 data section even though the target supports named sections. This 35286 might be necessary, for instance, if the system linker does garbage 35287 collection and sections cannot be marked as not to be collected. 35288 35289 Do not define this macro unless `TARGET_ASM_NAMED_SECTION' is also 35290 defined. 35291 35292 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 35293 Define this macro to 1 if your target is such that no frame unwind 35294 information encoding used with non-PIC code will ever require a 35295 runtime relocation, but the linker may not support merging 35296 read-only and read-write sections into a single read-write section. 35297 35298 -- Macro: MASK_RETURN_ADDR 35299 An rtx used to mask the return address found via 35300 `RETURN_ADDR_RTX', so that it does not contain any extraneous set 35301 bits in it. 35302 35303 -- Macro: DWARF2_UNWIND_INFO 35304 Define this macro to 0 if your target supports DWARF 2 frame unwind 35305 information, but it does not yet work with exception handling. 35306 Otherwise, if your target supports this information (if it defines 35307 `INCOMING_RETURN_ADDR_RTX' and `OBJECT_FORMAT_ELF'), GCC will 35308 provide a default definition of 1. 35309 35310 -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO 35311 (struct gcc_options *OPTS) 35312 This hook defines the mechanism that will be used for exception 35313 handling by the target. If the target has ABI specified unwind 35314 tables, the hook should return `UI_TARGET'. If the target is to 35315 use the `setjmp'/`longjmp'-based exception handling scheme, the 35316 hook should return `UI_SJLJ'. If the target supports DWARF 2 35317 frame unwind information, the hook should return `UI_DWARF2'. 35318 35319 A target may, if exceptions are disabled, choose to return 35320 `UI_NONE'. This may end up simplifying other parts of 35321 target-specific code. The default implementation of this hook 35322 never returns `UI_NONE'. 35323 35324 Note that the value returned by this hook should be constant. It 35325 should not depend on anything except the command-line switches 35326 described by OPTS. In particular, the setting `UI_SJLJ' must be 35327 fixed at compiler start-up as C pre-processor macros and builtin 35328 functions related to exception handling are set up depending on 35329 this setting. 35330 35331 The default implementation of the hook first honors the 35332 `--enable-sjlj-exceptions' configure option, then 35333 `DWARF2_UNWIND_INFO', and finally defaults to `UI_SJLJ'. If 35334 `DWARF2_UNWIND_INFO' depends on command-line options, the target 35335 must define this hook so that OPTS is used correctly. 35336 35337 -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 35338 This variable should be set to `true' if the target ABI requires 35339 unwinding tables even when exceptions are not used. It must not 35340 be modified by command-line option processing. 35341 35342 -- Macro: DONT_USE_BUILTIN_SETJMP 35343 Define this macro to 1 if the `setjmp'/`longjmp'-based scheme 35344 should use the `setjmp'/`longjmp' functions from the C library 35345 instead of the `__builtin_setjmp'/`__builtin_longjmp' machinery. 35346 35347 -- Macro: JMP_BUF_SIZE 35348 This macro has no effect unless `DONT_USE_BUILTIN_SETJMP' is also 35349 defined. Define this macro if the default size of `jmp_buf' buffer 35350 for the `setjmp'/`longjmp'-based exception handling mechanism is 35351 not large enough, or if it is much too large. The default size is 35352 `FIRST_PSEUDO_REGISTER * sizeof(void *)'. 35353 35354 -- Macro: DWARF_CIE_DATA_ALIGNMENT 35355 This macro need only be defined if the target might save registers 35356 in the function prologue at an offset to the stack pointer that is 35357 not aligned to `UNITS_PER_WORD'. The definition should be the 35358 negative minimum alignment if `STACK_GROWS_DOWNWARD' is defined, 35359 and the positive minimum alignment otherwise. *Note SDB and 35360 DWARF::. Only applicable if the target supports DWARF 2 frame 35361 unwind information. 35362 35363 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 35364 Contains the value true if the target should add a zero word onto 35365 the end of a Dwarf-2 frame info section when used for exception 35366 handling. Default value is false if `EH_FRAME_SECTION_NAME' is 35367 defined, and true otherwise. 35368 35369 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 35370 Given a register, this hook should return a parallel of registers 35371 to represent where to find the register pieces. Define this hook 35372 if the register and its mode are represented in Dwarf in 35373 non-contiguous locations, or if the register should be represented 35374 in more than one register in Dwarf. Otherwise, this hook should 35375 return `NULL_RTX'. If not defined, the default is to return 35376 `NULL_RTX'. 35377 35378 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 35379 If some registers are represented in Dwarf-2 unwind information in 35380 multiple pieces, define this hook to fill in information about the 35381 sizes of those pieces in the table used by the unwinder at runtime. 35382 It will be called by `expand_builtin_init_dwarf_reg_sizes' after 35383 filling in a single size corresponding to each hard register; 35384 ADDRESS is the address of the table. 35385 35386 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 35387 This hook is used to output a reference from a frame unwinding 35388 table to the type_info object identified by SYM. It should return 35389 `true' if the reference was output. Returning `false' will cause 35390 the reference to be output using the normal Dwarf2 routines. 35391 35392 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 35393 This flag should be set to `true' on targets that use an ARM EABI 35394 based unwinding library, and `false' on other targets. This 35395 effects the format of unwinding tables, and how the unwinder in 35396 entered after running a cleanup. The default is `false'. 35397 35398 35399 File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 35400 35401 17.21.10 Assembler Commands for Alignment 35402 ----------------------------------------- 35403 35404 This describes commands for alignment. 35405 35406 -- Macro: JUMP_ALIGN (LABEL) 35407 The alignment (log base 2) to put in front of LABEL, which is a 35408 common destination of jumps and has no fallthru incoming edge. 35409 35410 This macro need not be defined if you don't want any special 35411 alignment to be done at such a time. Most machine descriptions do 35412 not currently define the macro. 35413 35414 Unless it's necessary to inspect the LABEL parameter, it is better 35415 to set the variable ALIGN_JUMPS in the target's 35416 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 35417 user's selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation. 35418 35419 -- Target Hook: int TARGET_ASM_JUMP_ALIGN_MAX_SKIP (rtx LABEL) 35420 The maximum number of bytes to skip before LABEL when applying 35421 `JUMP_ALIGN'. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is 35422 defined. 35423 35424 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 35425 The alignment (log base 2) to put in front of LABEL, which follows 35426 a `BARRIER'. 35427 35428 This macro need not be defined if you don't want any special 35429 alignment to be done at such a time. Most machine descriptions do 35430 not currently define the macro. 35431 35432 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP (rtx 35433 LABEL) 35434 The maximum number of bytes to skip before LABEL when applying 35435 `LABEL_ALIGN_AFTER_BARRIER'. This works only if 35436 `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 35437 35438 -- Macro: LOOP_ALIGN (LABEL) 35439 The alignment (log base 2) to put in front of LABEL, which follows 35440 a `NOTE_INSN_LOOP_BEG' note. 35441 35442 This macro need not be defined if you don't want any special 35443 alignment to be done at such a time. Most machine descriptions do 35444 not currently define the macro. 35445 35446 Unless it's necessary to inspect the LABEL parameter, it is better 35447 to set the variable `align_loops' in the target's 35448 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 35449 user's selection in `align_loops' in a `LOOP_ALIGN' implementation. 35450 35451 -- Target Hook: int TARGET_ASM_LOOP_ALIGN_MAX_SKIP (rtx LABEL) 35452 The maximum number of bytes to skip when applying `LOOP_ALIGN' to 35453 LABEL. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 35454 35455 -- Macro: LABEL_ALIGN (LABEL) 35456 The alignment (log base 2) to put in front of LABEL. If 35457 `LABEL_ALIGN_AFTER_BARRIER' / `LOOP_ALIGN' specify a different 35458 alignment, the maximum of the specified values is used. 35459 35460 Unless it's necessary to inspect the LABEL parameter, it is better 35461 to set the variable `align_labels' in the target's 35462 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 35463 user's selection in `align_labels' in a `LABEL_ALIGN' 35464 implementation. 35465 35466 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_MAX_SKIP (rtx LABEL) 35467 The maximum number of bytes to skip when applying `LABEL_ALIGN' to 35468 LABEL. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 35469 35470 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 35471 A C statement to output to the stdio stream STREAM an assembler 35472 instruction to advance the location counter by NBYTES bytes. 35473 Those bytes should be zero when loaded. NBYTES will be a C 35474 expression of type `unsigned HOST_WIDE_INT'. 35475 35476 -- Macro: ASM_NO_SKIP_IN_TEXT 35477 Define this macro if `ASM_OUTPUT_SKIP' should not be used in the 35478 text section because it fails to put zeros in the bytes that are 35479 skipped. This is true on many Unix systems, where the pseudo-op 35480 to skip bytes produces no-op instructions rather than zeros when 35481 used in the text section. 35482 35483 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 35484 A C statement to output to the stdio stream STREAM an assembler 35485 command to advance the location counter to a multiple of 2 to the 35486 POWER bytes. POWER will be a C expression of type `int'. 35487 35488 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 35489 Like `ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 35490 for padding, if necessary. 35491 35492 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 35493 A C statement to output to the stdio stream STREAM an assembler 35494 command to advance the location counter to a multiple of 2 to the 35495 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 35496 satisfy the alignment request. POWER and MAX_SKIP will be a C 35497 expression of type `int'. 35498 35499 35500 File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 35501 35502 17.22 Controlling Debugging Information Format 35503 ============================================== 35504 35505 This describes how to specify debugging information. 35506 35507 * Menu: 35508 35509 * All Debuggers:: Macros that affect all debugging formats uniformly. 35510 * DBX Options:: Macros enabling specific options in DBX format. 35511 * DBX Hooks:: Hook macros for varying DBX format. 35512 * File Names and DBX:: Macros controlling output of file names in DBX format. 35513 * SDB and DWARF:: Macros for SDB (COFF) and DWARF formats. 35514 * VMS Debug:: Macros for VMS debug format. 35515 35516 35517 File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 35518 35519 17.22.1 Macros Affecting All Debugging Formats 35520 ---------------------------------------------- 35521 35522 These macros affect all debugging formats. 35523 35524 -- Macro: DBX_REGISTER_NUMBER (REGNO) 35525 A C expression that returns the DBX register number for the 35526 compiler register number REGNO. In the default macro provided, 35527 the value of this expression will be REGNO itself. But sometimes 35528 there are some registers that the compiler knows about and DBX 35529 does not, or vice versa. In such cases, some register may need to 35530 have one number in the compiler and another for DBX. 35531 35532 If two registers have consecutive numbers inside GCC, and they can 35533 be used as a pair to hold a multiword value, then they _must_ have 35534 consecutive numbers after renumbering with `DBX_REGISTER_NUMBER'. 35535 Otherwise, debuggers will be unable to access such a pair, because 35536 they expect register pairs to be consecutive in their own 35537 numbering scheme. 35538 35539 If you find yourself defining `DBX_REGISTER_NUMBER' in way that 35540 does not preserve register pairs, then what you must do instead is 35541 redefine the actual register numbering scheme. 35542 35543 -- Macro: DEBUGGER_AUTO_OFFSET (X) 35544 A C expression that returns the integer offset value for an 35545 automatic variable having address X (an RTL expression). The 35546 default computation assumes that X is based on the frame-pointer 35547 and gives the offset from the frame-pointer. This is required for 35548 targets that produce debugging output for DBX or COFF-style 35549 debugging output for SDB and allow the frame-pointer to be 35550 eliminated when the `-g' options is used. 35551 35552 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 35553 A C expression that returns the integer offset value for an 35554 argument having address X (an RTL expression). The nominal offset 35555 is OFFSET. 35556 35557 -- Macro: PREFERRED_DEBUGGING_TYPE 35558 A C expression that returns the type of debugging output GCC should 35559 produce when the user specifies just `-g'. Define this if you 35560 have arranged for GCC to support more than one format of debugging 35561 output. Currently, the allowable values are `DBX_DEBUG', 35562 `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', `XCOFF_DEBUG', 35563 `VMS_DEBUG', and `VMS_AND_DWARF2_DEBUG'. 35564 35565 When the user specifies `-ggdb', GCC normally also uses the value 35566 of this macro to select the debugging output format, but with two 35567 exceptions. If `DWARF2_DEBUGGING_INFO' is defined, GCC uses the 35568 value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is 35569 defined, GCC uses `DBX_DEBUG'. 35570 35571 The value of this macro only affects the default debugging output; 35572 the user can always get a specific type of output by using 35573 `-gstabs', `-gcoff', `-gdwarf-2', `-gxcoff', or `-gvms'. 35574 35575 35576 File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 35577 35578 17.22.2 Specific Options for DBX Output 35579 --------------------------------------- 35580 35581 These are specific options for DBX output. 35582 35583 -- Macro: DBX_DEBUGGING_INFO 35584 Define this macro if GCC should produce debugging output for DBX 35585 in response to the `-g' option. 35586 35587 -- Macro: XCOFF_DEBUGGING_INFO 35588 Define this macro if GCC should produce XCOFF format debugging 35589 output in response to the `-g' option. This is a variant of DBX 35590 format. 35591 35592 -- Macro: DEFAULT_GDB_EXTENSIONS 35593 Define this macro to control whether GCC should by default generate 35594 GDB's extended version of DBX debugging information (assuming 35595 DBX-format debugging information is enabled at all). If you don't 35596 define the macro, the default is 1: always generate the extended 35597 information if there is any occasion to. 35598 35599 -- Macro: DEBUG_SYMS_TEXT 35600 Define this macro if all `.stabs' commands should be output while 35601 in the text section. 35602 35603 -- Macro: ASM_STABS_OP 35604 A C string constant, including spacing, naming the assembler 35605 pseudo op to use instead of `"\t.stabs\t"' to define an ordinary 35606 debugging symbol. If you don't define this macro, `"\t.stabs\t"' 35607 is used. This macro applies only to DBX debugging information 35608 format. 35609 35610 -- Macro: ASM_STABD_OP 35611 A C string constant, including spacing, naming the assembler 35612 pseudo op to use instead of `"\t.stabd\t"' to define a debugging 35613 symbol whose value is the current location. If you don't define 35614 this macro, `"\t.stabd\t"' is used. This macro applies only to 35615 DBX debugging information format. 35616 35617 -- Macro: ASM_STABN_OP 35618 A C string constant, including spacing, naming the assembler 35619 pseudo op to use instead of `"\t.stabn\t"' to define a debugging 35620 symbol with no name. If you don't define this macro, 35621 `"\t.stabn\t"' is used. This macro applies only to DBX debugging 35622 information format. 35623 35624 -- Macro: DBX_NO_XREFS 35625 Define this macro if DBX on your system does not support the 35626 construct `xsTAGNAME'. On some systems, this construct is used to 35627 describe a forward reference to a structure named TAGNAME. On 35628 other systems, this construct is not supported at all. 35629 35630 -- Macro: DBX_CONTIN_LENGTH 35631 A symbol name in DBX-format debugging information is normally 35632 continued (split into two separate `.stabs' directives) when it 35633 exceeds a certain length (by default, 80 characters). On some 35634 operating systems, DBX requires this splitting; on others, 35635 splitting must not be done. You can inhibit splitting by defining 35636 this macro with the value zero. You can override the default 35637 splitting-length by defining this macro as an expression for the 35638 length you desire. 35639 35640 -- Macro: DBX_CONTIN_CHAR 35641 Normally continuation is indicated by adding a `\' character to 35642 the end of a `.stabs' string when a continuation follows. To use 35643 a different character instead, define this macro as a character 35644 constant for the character you want to use. Do not define this 35645 macro if backslash is correct for your system. 35646 35647 -- Macro: DBX_STATIC_STAB_DATA_SECTION 35648 Define this macro if it is necessary to go to the data section 35649 before outputting the `.stabs' pseudo-op for a non-global static 35650 variable. 35651 35652 -- Macro: DBX_TYPE_DECL_STABS_CODE 35653 The value to use in the "code" field of the `.stabs' directive for 35654 a typedef. The default is `N_LSYM'. 35655 35656 -- Macro: DBX_STATIC_CONST_VAR_CODE 35657 The value to use in the "code" field of the `.stabs' directive for 35658 a static variable located in the text section. DBX format does not 35659 provide any "right" way to do this. The default is `N_FUN'. 35660 35661 -- Macro: DBX_REGPARM_STABS_CODE 35662 The value to use in the "code" field of the `.stabs' directive for 35663 a parameter passed in registers. DBX format does not provide any 35664 "right" way to do this. The default is `N_RSYM'. 35665 35666 -- Macro: DBX_REGPARM_STABS_LETTER 35667 The letter to use in DBX symbol data to identify a symbol as a 35668 parameter passed in registers. DBX format does not customarily 35669 provide any way to do this. The default is `'P''. 35670 35671 -- Macro: DBX_FUNCTION_FIRST 35672 Define this macro if the DBX information for a function and its 35673 arguments should precede the assembler code for the function. 35674 Normally, in DBX format, the debugging information entirely 35675 follows the assembler code. 35676 35677 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 35678 Define this macro, with value 1, if the value of a symbol 35679 describing the scope of a block (`N_LBRAC' or `N_RBRAC') should be 35680 relative to the start of the enclosing function. Normally, GCC 35681 uses an absolute address. 35682 35683 -- Macro: DBX_LINES_FUNCTION_RELATIVE 35684 Define this macro, with value 1, if the value of a symbol 35685 indicating the current line number (`N_SLINE') should be relative 35686 to the start of the enclosing function. Normally, GCC uses an 35687 absolute address. 35688 35689 -- Macro: DBX_USE_BINCL 35690 Define this macro if GCC should generate `N_BINCL' and `N_EINCL' 35691 stabs for included header files, as on Sun systems. This macro 35692 also directs GCC to output a type number as a pair of a file 35693 number and a type number within the file. Normally, GCC does not 35694 generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single 35695 number for a type number. 35696 35697 35698 File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 35699 35700 17.22.3 Open-Ended Hooks for DBX Format 35701 --------------------------------------- 35702 35703 These are hooks for DBX format. 35704 35705 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 35706 A C statement to output DBX debugging information before code for 35707 line number LINE of the current source file to the stdio stream 35708 STREAM. COUNTER is the number of time the macro was invoked, 35709 including the current invocation; it is intended to generate 35710 unique labels in the assembly output. 35711 35712 This macro should not be defined if the default output is correct, 35713 or if it can be made correct by defining 35714 `DBX_LINES_FUNCTION_RELATIVE'. 35715 35716 -- Macro: NO_DBX_FUNCTION_END 35717 Some stabs encapsulation formats (in particular ECOFF), cannot 35718 handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 35719 extension construct. On those machines, define this macro to turn 35720 this feature off without disturbing the rest of the gdb extensions. 35721 35722 -- Macro: NO_DBX_BNSYM_ENSYM 35723 Some assemblers cannot handle the `.stabd BNSYM/ENSYM,0,0' gdb dbx 35724 extension construct. On those machines, define this macro to turn 35725 this feature off without disturbing the rest of the gdb extensions. 35726 35727 35728 File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info 35729 35730 17.22.4 File Names in DBX Format 35731 -------------------------------- 35732 35733 This describes file names in DBX format. 35734 35735 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 35736 A C statement to output DBX debugging information to the stdio 35737 stream STREAM, which indicates that file NAME is the main source 35738 file--the file specified as the input file for compilation. This 35739 macro is called only once, at the beginning of compilation. 35740 35741 This macro need not be defined if the standard form of output for 35742 DBX debugging information is appropriate. 35743 35744 It may be necessary to refer to a label equal to the beginning of 35745 the text section. You can use `assemble_name (stream, 35746 ltext_label_name)' to do so. If you do this, you must also set 35747 the variable USED_LTEXT_LABEL_NAME to `true'. 35748 35749 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 35750 Define this macro, with value 1, if GCC should not emit an 35751 indication of the current directory for compilation and current 35752 source language at the beginning of the file. 35753 35754 -- Macro: NO_DBX_GCC_MARKER 35755 Define this macro, with value 1, if GCC should not emit an 35756 indication that this object file was compiled by GCC. The default 35757 is to emit an `N_OPT' stab at the beginning of every source file, 35758 with `gcc2_compiled.' for the string and value 0. 35759 35760 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 35761 A C statement to output DBX debugging information at the end of 35762 compilation of the main source file NAME. Output should be 35763 written to the stdio stream STREAM. 35764 35765 If you don't define this macro, nothing special is output at the 35766 end of compilation, which is correct for most machines. 35767 35768 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 35769 Define this macro _instead of_ defining 35770 `DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 35771 the end of compilation is an `N_SO' stab with an empty string, 35772 whose value is the highest absolute text address in the file. 35773 35774 35775 File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 35776 35777 17.22.5 Macros for SDB and DWARF Output 35778 --------------------------------------- 35779 35780 Here are macros for SDB and DWARF output. 35781 35782 -- Macro: SDB_DEBUGGING_INFO 35783 Define this macro if GCC should produce COFF-style debugging output 35784 for SDB in response to the `-g' option. 35785 35786 -- Macro: DWARF2_DEBUGGING_INFO 35787 Define this macro if GCC should produce dwarf version 2 format 35788 debugging output in response to the `-g' option. 35789 35790 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 35791 FUNCTION) 35792 Define this to enable the dwarf attribute 35793 `DW_AT_calling_convention' to be emitted for each function. 35794 Instead of an integer return the enum value for the `DW_CC_' 35795 tag. 35796 35797 To support optional call frame debugging information, you must also 35798 define `INCOMING_RETURN_ADDR_RTX' and either set 35799 `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 35800 prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as 35801 appropriate from `TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 35802 35803 -- Macro: DWARF2_FRAME_INFO 35804 Define this macro to a nonzero value if GCC should always output 35805 Dwarf 2 frame information. If `TARGET_EXCEPT_UNWIND_INFO' (*note 35806 Exception Region Output::) returns `UI_DWARF2', and exceptions are 35807 enabled, GCC will output this information not matter how you 35808 define `DWARF2_FRAME_INFO'. 35809 35810 -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void) 35811 This hook defines the mechanism that will be used for describing 35812 frame unwind information to the debugger. Normally the hook will 35813 return `UI_DWARF2' if DWARF 2 debug information is enabled, and 35814 return `UI_NONE' otherwise. 35815 35816 A target may return `UI_DWARF2' even when DWARF 2 debug information 35817 is disabled in order to always output DWARF 2 frame information. 35818 35819 A target may return `UI_TARGET' if it has ABI specified unwind 35820 tables. This will suppress generation of the normal debug frame 35821 unwind information. 35822 35823 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 35824 Define this macro to be a nonzero value if the assembler can 35825 generate Dwarf 2 line debug info sections. This will result in 35826 much more compact line number tables, and hence is desirable if it 35827 works. 35828 35829 -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS 35830 True if the `.debug_pubtypes' and `.debug_pubnames' sections 35831 should be emitted. These sections are not used on most platforms, 35832 and in particular GDB does not use them. 35833 35834 -- Target Hook: bool TARGET_FORCE_AT_COMP_DIR 35835 True if the `DW_AT_comp_dir' attribute should be emitted for each 35836 compilation unit. This attribute is required for the darwin 35837 linker to emit debug information. 35838 35839 -- Target Hook: bool TARGET_DELAY_SCHED2 35840 True if sched2 is not to be run at its normal place. This usually 35841 means it will be run as part of machine-specific reorg. 35842 35843 -- Target Hook: bool TARGET_DELAY_VARTRACK 35844 True if vartrack is not to be run at its normal place. This 35845 usually means it will be run as part of machine-specific reorg. 35846 35847 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 35848 A C statement to issue assembly directives that create a difference 35849 LAB1 minus LAB2, using an integer of the given SIZE. 35850 35851 -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2) 35852 A C statement to issue assembly directives that create a difference 35853 between the two given labels in system defined units, e.g. 35854 instruction slots on IA64 VMS, using an integer of the given size. 35855 35856 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, SECTION) 35857 A C statement to issue assembly directives that create a 35858 section-relative reference to the given LABEL, using an integer of 35859 the given SIZE. The label is known to be defined in the given 35860 SECTION. 35861 35862 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 35863 A C statement to issue assembly directives that create a 35864 self-relative reference to the given LABEL, using an integer of 35865 the given SIZE. 35866 35867 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 35868 A C statement to issue assembly directives that create a reference 35869 to the DWARF table identifier LABEL from the current section. This 35870 is used on some systems to avoid garbage collecting a DWARF table 35871 which is referenced by a function. 35872 35873 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 35874 SIZE, rtx X) 35875 If defined, this target hook is a function which outputs a 35876 DTP-relative reference to the given TLS symbol of the specified 35877 size. 35878 35879 -- Macro: PUT_SDB_... 35880 Define these macros to override the assembler syntax for the 35881 special SDB assembler directives. See `sdbout.c' for a list of 35882 these macros and their arguments. If the standard syntax is used, 35883 you need not define them yourself. 35884 35885 -- Macro: SDB_DELIM 35886 Some assemblers do not support a semicolon as a delimiter, even 35887 between SDB assembler directives. In that case, define this macro 35888 to be the delimiter to use (usually `\n'). It is not necessary to 35889 define a new set of `PUT_SDB_OP' macros if this is the only change 35890 required. 35891 35892 -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES 35893 Define this macro to allow references to unknown structure, union, 35894 or enumeration tags to be emitted. Standard COFF does not allow 35895 handling of unknown references, MIPS ECOFF has support for it. 35896 35897 -- Macro: SDB_ALLOW_FORWARD_REFERENCES 35898 Define this macro to allow references to structure, union, or 35899 enumeration tags that have not yet been seen to be handled. Some 35900 assemblers choke if forward tags are used, while some require it. 35901 35902 -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE) 35903 A C statement to output SDB debugging information before code for 35904 line number LINE of the current source file to the stdio stream 35905 STREAM. The default is to emit an `.ln' directive. 35906 35907 35908 File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info 35909 35910 17.22.6 Macros for VMS Debug Format 35911 ----------------------------------- 35912 35913 Here are macros for VMS debug format. 35914 35915 -- Macro: VMS_DEBUGGING_INFO 35916 Define this macro if GCC should produce debugging output for VMS 35917 in response to the `-g' option. The default behavior for VMS is 35918 to generate minimal debug info for a traceback in the absence of 35919 `-g' unless explicitly overridden with `-g0'. This behavior is 35920 controlled by `TARGET_OPTION_OPTIMIZATION' and 35921 `TARGET_OPTION_OVERRIDE'. 35922 35923 35924 File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 35925 35926 17.23 Cross Compilation and Floating Point 35927 ========================================== 35928 35929 While all modern machines use twos-complement representation for 35930 integers, there are a variety of representations for floating point 35931 numbers. This means that in a cross-compiler the representation of 35932 floating point numbers in the compiled program may be different from 35933 that used in the machine doing the compilation. 35934 35935 Because different representation systems may offer different amounts of 35936 range and precision, all floating point constants must be represented in 35937 the target machine's format. Therefore, the cross compiler cannot 35938 safely use the host machine's floating point arithmetic; it must emulate 35939 the target's arithmetic. To ensure consistency, GCC always uses 35940 emulation to work with floating point values, even when the host and 35941 target floating point formats are identical. 35942 35943 The following macros are provided by `real.h' for the compiler to use. 35944 All parts of the compiler which generate or optimize floating-point 35945 calculations must use these macros. They may evaluate their operands 35946 more than once, so operands must not have side effects. 35947 35948 -- Macro: REAL_VALUE_TYPE 35949 The C data type to be used to hold a floating point value in the 35950 target machine's format. Typically this is a `struct' containing 35951 an array of `HOST_WIDE_INT', but all code should treat it as an 35952 opaque quantity. 35953 35954 -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 35955 Compares for equality the two values, X and Y. If the target 35956 floating point format supports negative zeroes and/or NaNs, 35957 `REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and `REAL_VALUES_EQUAL 35958 (NaN, NaN)' is false. 35959 35960 -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 35961 Tests whether X is less than Y. 35962 35963 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 35964 Truncates X to a signed integer, rounding toward zero. 35965 35966 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 35967 (REAL_VALUE_TYPE X) 35968 Truncates X to an unsigned integer, rounding toward zero. If X is 35969 negative, returns zero. 35970 35971 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum 35972 machine_mode MODE) 35973 Converts STRING into a floating point number in the target 35974 machine's representation for mode MODE. This routine can handle 35975 both decimal and hexadecimal floating point constants, using the 35976 syntax defined by the C language for both. 35977 35978 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 35979 Returns 1 if X is negative (including negative zero), 0 otherwise. 35980 35981 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 35982 Determines whether X represents infinity (positive or negative). 35983 35984 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 35985 Determines whether X represents a "NaN" (not-a-number). 35986 35987 -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code 35988 CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 35989 Calculates an arithmetic operation on the two floating point values 35990 X and Y, storing the result in OUTPUT (which must be a variable). 35991 35992 The operation to be performed is specified by CODE. Only the 35993 following codes are supported: `PLUS_EXPR', `MINUS_EXPR', 35994 `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'. 35995 35996 If `REAL_ARITHMETIC' is asked to evaluate division by zero and the 35997 target's floating point format cannot represent infinity, it will 35998 call `abort'. Callers should check for this situation first, using 35999 `MODE_HAS_INFINITIES'. *Note Storage Layout::. 36000 36001 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 36002 Returns the negative of the floating point value X. 36003 36004 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 36005 Returns the absolute value of X. 36006 36007 -- Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT 36008 HIGH, REAL_VALUE_TYPE X) 36009 Converts a floating point value X into a double-precision integer 36010 which is then stored into LOW and HIGH. If the value is not 36011 integral, it is truncated. 36012 36013 -- Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT 36014 LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE) 36015 Converts a double-precision integer found in LOW and HIGH, into a 36016 floating point value which is then stored into X. The value is 36017 truncated to fit in mode MODE. 36018 36019 36020 File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 36021 36022 17.24 Mode Switching Instructions 36023 ================================= 36024 36025 The following macros control mode switching optimizations: 36026 36027 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 36028 Define this macro if the port needs extra instructions inserted 36029 for mode switching in an optimizing compilation. 36030 36031 For an example, the SH4 can perform both single and double 36032 precision floating point operations, but to perform a single 36033 precision operation, the FPSCR PR bit has to be cleared, while for 36034 a double precision operation, this bit has to be set. Changing 36035 the PR bit requires a general purpose register as a scratch 36036 register, hence these FPSCR sets have to be inserted before 36037 reload, i.e. you can't put this into instruction emitting or 36038 `TARGET_MACHINE_DEPENDENT_REORG'. 36039 36040 You can have multiple entities that are mode-switched, and select 36041 at run time which entities actually need it. 36042 `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY 36043 that needs mode-switching. If you define this macro, you also 36044 have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED', 36045 `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'. `MODE_AFTER', 36046 `MODE_ENTRY', and `MODE_EXIT' are optional. 36047 36048 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 36049 If you define `OPTIMIZE_MODE_SWITCHING', you have to define this as 36050 initializer for an array of integers. Each initializer element N 36051 refers to an entity that needs mode switching, and specifies the 36052 number of different modes that might need to be set for this 36053 entity. The position of the initializer in the 36054 initializer--starting counting at zero--determines the integer 36055 that is used to refer to the mode-switched entity in question. In 36056 macros that take mode arguments / yield a mode result, modes are 36057 represented as numbers 0 ... N - 1. N is used to specify that no 36058 mode switch is needed / supplied. 36059 36060 -- Macro: MODE_NEEDED (ENTITY, INSN) 36061 ENTITY is an integer specifying a mode-switched entity. If 36062 `OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 36063 return an integer value not larger than the corresponding element 36064 in `NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 36065 must be switched into prior to the execution of INSN. 36066 36067 -- Macro: MODE_AFTER (ENTITY, MODE, INSN) 36068 ENTITY is an integer specifying a mode-switched entity. If this 36069 macro is defined, it is evaluated for every INSN during mode 36070 switching. It determines the mode that an insn results in (if 36071 different from the incoming mode). 36072 36073 -- Macro: MODE_ENTRY (ENTITY) 36074 If this macro is defined, it is evaluated for every ENTITY that 36075 needs mode switching. It should evaluate to an integer, which is 36076 a mode that ENTITY is assumed to be switched to at function entry. 36077 If `MODE_ENTRY' is defined then `MODE_EXIT' must be defined. 36078 36079 -- Macro: MODE_EXIT (ENTITY) 36080 If this macro is defined, it is evaluated for every ENTITY that 36081 needs mode switching. It should evaluate to an integer, which is 36082 a mode that ENTITY is assumed to be switched to at function exit. 36083 If `MODE_EXIT' is defined then `MODE_ENTRY' must be defined. 36084 36085 -- Macro: MODE_PRIORITY_TO_MODE (ENTITY, N) 36086 This macro specifies the order in which modes for ENTITY are 36087 processed. 0 is the highest priority, 36088 `NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 36089 of the macro should be an integer designating a mode for ENTITY. 36090 For any fixed ENTITY, `mode_priority_to_mode' (ENTITY, N) shall be 36091 a bijection in 0 ... `num_modes_for_mode_switching[ENTITY] - 1'. 36092 36093 -- Macro: EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE) 36094 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE 36095 is the set of hard registers live at the point where the insn(s) 36096 are to be inserted. 36097 36098 36099 File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 36100 36101 17.25 Defining target-specific uses of `__attribute__' 36102 ====================================================== 36103 36104 Target-specific attributes may be defined for functions, data and types. 36105 These are described using the following target hooks; they also need to 36106 be documented in `extend.texi'. 36107 36108 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 36109 If defined, this target hook points to an array of `struct 36110 attribute_spec' (defined in `tree.h') specifying the machine 36111 specific attributes for this target and some of the restrictions 36112 on the entities to which these attributes are applied and the 36113 arguments they take. 36114 36115 -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree 36116 NAME) 36117 If defined, this target hook is a function which returns true if 36118 the machine-specific attribute named NAME expects an identifier 36119 given as its first argument to be passed on as a plain identifier, 36120 not subjected to name lookup. If this is not defined, the default 36121 is false for all machine-specific attributes. 36122 36123 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 36124 const_tree TYPE2) 36125 If defined, this target hook is a function which returns zero if 36126 the attributes on TYPE1 and TYPE2 are incompatible, one if they 36127 are compatible, and two if they are nearly compatible (which 36128 causes a warning to be generated). If this is not defined, 36129 machine-specific attributes are supposed always to be compatible. 36130 36131 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 36132 If defined, this target hook is a function which assigns default 36133 attributes to the newly defined TYPE. 36134 36135 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 36136 TYPE2) 36137 Define this target hook if the merging of type attributes needs 36138 special handling. If defined, the result is a list of the combined 36139 `TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 36140 `comptypes' has already been called and returned 1. This function 36141 may call `merge_attributes' to handle machine-independent merging. 36142 36143 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 36144 NEWDECL) 36145 Define this target hook if the merging of decl attributes needs 36146 special handling. If defined, the result is a list of the combined 36147 `DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 36148 declaration of OLDDECL. Examples of when this is needed are when 36149 one attribute overrides another, or when an attribute is nullified 36150 by a subsequent definition. This function may call 36151 `merge_attributes' to handle machine-independent merging. 36152 36153 If the only target-specific handling you require is `dllimport' 36154 for Microsoft Windows targets, you should define the macro 36155 `TARGET_DLLIMPORT_DECL_ATTRIBUTES' to `1'. The compiler will then 36156 define a function called `merge_dllimport_decl_attributes' which 36157 can then be defined as the expansion of 36158 `TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 36159 `handle_dll_attribute' in the attribute table for your port to 36160 perform initial processing of the `dllimport' and `dllexport' 36161 attributes. This is done in `i386/cygwin.h' and `i386/i386.c', 36162 for example. 36163 36164 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 36165 DECL) 36166 DECL is a variable or function with `__attribute__((dllimport))' 36167 specified. Use this hook if the target needs to add extra 36168 validation checks to `handle_dll_attribute'. 36169 36170 -- Macro: TARGET_DECLSPEC 36171 Define this macro to a nonzero value if you want to treat 36172 `__declspec(X)' as equivalent to `__attribute((X))'. By default, 36173 this behavior is enabled only for targets that define 36174 `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 36175 `__declspec' is via a built-in macro, but you should not rely on 36176 this implementation detail. 36177 36178 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 36179 *ATTR_PTR) 36180 Define this target hook if you want to be able to add attributes 36181 to a decl when it is being created. This is normally useful for 36182 back ends which wish to implement a pragma by using the attributes 36183 which correspond to the pragma's effect. The NODE argument is the 36184 decl which is being created. The ATTR_PTR argument is a pointer 36185 to the attribute list for this decl. The list itself should not 36186 be modified, since it may be shared with other decls, but 36187 attributes may be chained on the head of the list and `*ATTR_PTR' 36188 modified to point to the new attributes, or a copy of the list may 36189 be made if further changes are needed. 36190 36191 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 36192 FNDECL) 36193 This target hook returns `true' if it is ok to inline FNDECL into 36194 the current function, despite its having target-specific 36195 attributes, `false' otherwise. By default, if a function has a 36196 target specific attribute attached to it, it will not be inlined. 36197 36198 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, 36199 tree NAME, tree ARGS, int FLAGS) 36200 This hook is called to parse `attribute(target("..."))', which 36201 allows setting target-specific options on individual functions. 36202 These function-specific options may differ from the options 36203 specified on the command line. The hook should return `true' if 36204 the options are valid. 36205 36206 The hook should set the `DECL_FUNCTION_SPECIFIC_TARGET' field in 36207 the function declaration to hold a pointer to a target-specific 36208 `struct cl_target_option' structure. 36209 36210 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR) 36211 This hook is called to save any additional target-specific 36212 information in the `struct cl_target_option' structure for 36213 function-specific options. *Note Option file format::. 36214 36215 -- Target Hook: void TARGET_OPTION_RESTORE (struct cl_target_option 36216 *PTR) 36217 This hook is called to restore any additional target-specific 36218 information in the `struct cl_target_option' structure for 36219 function-specific options. 36220 36221 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 36222 struct cl_target_option *PTR) 36223 This hook is called to print any additional target-specific 36224 information in the `struct cl_target_option' structure for 36225 function-specific options. 36226 36227 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree 36228 POP_TARGET) 36229 This target hook parses the options for `#pragma GCC target', which 36230 sets the target-specific options for functions that occur later in 36231 the input stream. The options accepted should be the same as 36232 those handled by the `TARGET_OPTION_VALID_ATTRIBUTE_P' hook. 36233 36234 -- Target Hook: void TARGET_OPTION_OVERRIDE (void) 36235 Sometimes certain combinations of command options do not make 36236 sense on a particular target machine. You can override the hook 36237 `TARGET_OPTION_OVERRIDE' to take account of this. This hooks is 36238 called once just after all the command options have been parsed. 36239 36240 Don't use this hook to turn on various extra optimizations for 36241 `-O'. That is what `TARGET_OPTION_OPTIMIZATION' is for. 36242 36243 If you need to do something whenever the optimization level is 36244 changed via the optimize attribute or pragma, see 36245 `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 36246 36247 -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree 36248 DECL2) 36249 This target hook returns `true' if DECL1 and DECL2 are versions of 36250 the same function. DECL1 and DECL2 are function versions if and 36251 only if they have the same function signature and different target 36252 specific attributes, that is, they are compiled for different 36253 target machines. 36254 36255 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 36256 This target hook returns `false' if the CALLER function cannot 36257 inline CALLEE, based on target specific information. By default, 36258 inlining is not allowed if the callee function has function 36259 specific target options and the caller does not use the same 36260 options. 36261 36262 36263 File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 36264 36265 17.26 Emulating TLS 36266 =================== 36267 36268 For targets whose psABI does not provide Thread Local Storage via 36269 specific relocations and instruction sequences, an emulation layer is 36270 used. A set of target hooks allows this emulation layer to be 36271 configured for the requirements of a particular target. For instance 36272 the psABI may in fact specify TLS support in terms of an emulation 36273 layer. 36274 36275 The emulation layer works by creating a control object for every TLS 36276 object. To access the TLS object, a lookup function is provided which, 36277 when given the address of the control object, will return the address 36278 of the current thread's instance of the TLS object. 36279 36280 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 36281 Contains the name of the helper function that uses a TLS control 36282 object to locate a TLS instance. The default causes libgcc's 36283 emulated TLS helper function to be used. 36284 36285 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 36286 Contains the name of the helper function that should be used at 36287 program startup to register TLS objects that are implicitly 36288 initialized to zero. If this is `NULL', all TLS objects will have 36289 explicit initializers. The default causes libgcc's emulated TLS 36290 registration function to be used. 36291 36292 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 36293 Contains the name of the section in which TLS control variables 36294 should be placed. The default of `NULL' allows these to be placed 36295 in any section. 36296 36297 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 36298 Contains the name of the section in which TLS initializers should 36299 be placed. The default of `NULL' allows these to be placed in any 36300 section. 36301 36302 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 36303 Contains the prefix to be prepended to TLS control variable names. 36304 The default of `NULL' uses a target-specific prefix. 36305 36306 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 36307 Contains the prefix to be prepended to TLS initializer objects. 36308 The default of `NULL' uses a target-specific prefix. 36309 36310 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 36311 Specifies a function that generates the FIELD_DECLs for a TLS 36312 control object type. TYPE is the RECORD_TYPE the fields are for 36313 and NAME should be filled with the structure tag, if the default of 36314 `__emutls_object' is unsuitable. The default creates a type 36315 suitable for libgcc's emulated TLS function. 36316 36317 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 36318 TMPL_ADDR) 36319 Specifies a function that generates the CONSTRUCTOR to initialize a 36320 TLS control object. VAR is the TLS control object, DECL is the 36321 TLS object and TMPL_ADDR is the address of the initializer. The 36322 default initializes libgcc's emulated TLS control object. 36323 36324 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 36325 Specifies whether the alignment of TLS control variable objects is 36326 fixed and should not be increased as some backends may do to 36327 optimize single objects. The default is false. 36328 36329 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 36330 Specifies whether a DWARF `DW_OP_form_tls_address' location 36331 descriptor may be used to describe emulated TLS control objects. 36332 36333 36334 File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 36335 36336 17.27 Defining coprocessor specifics for MIPS targets. 36337 ====================================================== 36338 36339 The MIPS specification allows MIPS implementations to have as many as 4 36340 coprocessors, each with as many as 32 private registers. GCC supports 36341 accessing these registers and transferring values between the registers 36342 and memory using asm-ized variables. For example: 36343 36344 register unsigned int cp0count asm ("c0r1"); 36345 unsigned int d; 36346 36347 d = cp0count + 3; 36348 36349 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 36350 names may be added as described below, or the default names may be 36351 overridden entirely in `SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 36352 36353 Coprocessor registers are assumed to be epilogue-used; sets to them 36354 will be preserved even if it does not appear that the register is used 36355 again later in the function. 36356 36357 Another note: according to the MIPS spec, coprocessor 1 (if present) is 36358 the FPU. One accesses COP1 registers through standard mips 36359 floating-point support; they are not included in this mechanism. 36360 36361 There is one macro used in defining the MIPS coprocessor interface 36362 which you may want to override in subtargets; it is described below. 36363 36364 36365 File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 36366 36367 17.28 Parameters for Precompiled Header Validity Checking 36368 ========================================================= 36369 36370 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 36371 This hook returns a pointer to the data needed by 36372 `TARGET_PCH_VALID_P' and sets `*SZ' to the size of the data in 36373 bytes. 36374 36375 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 36376 size_t SZ) 36377 This hook checks whether the options used to create a PCH file are 36378 compatible with the current settings. It returns `NULL' if so and 36379 a suitable error message if not. Error messages will be presented 36380 to the user and must be localized using `_(MSG)'. 36381 36382 DATA is the data that was returned by `TARGET_GET_PCH_VALIDITY' 36383 when the PCH file was created and SZ is the size of that data in 36384 bytes. It's safe to assume that the data was created by the same 36385 version of the compiler, so no format checking is needed. 36386 36387 The default definition of `default_pch_valid_p' should be suitable 36388 for most targets. 36389 36390 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 36391 PCH_FLAGS) 36392 If this hook is nonnull, the default implementation of 36393 `TARGET_PCH_VALID_P' will use it to check for compatible values of 36394 `target_flags'. PCH_FLAGS specifies the value that `target_flags' 36395 had when the PCH file was created. The return value is the same 36396 as for `TARGET_PCH_VALID_P'. 36397 36398 -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void) 36399 Called before writing out a PCH file. If the target has some 36400 garbage-collected data that needs to be in a particular state on 36401 PCH loads, it can use this hook to enforce that state. Very few 36402 targets need to do anything here. 36403 36404 36405 File: gccint.info, Node: C++ ABI, Next: Named Address Spaces, Prev: PCH Target, Up: Target Macros 36406 36407 17.29 C++ ABI parameters 36408 ======================== 36409 36410 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 36411 Define this hook to override the integer type used for guard 36412 variables. These are used to implement one-time construction of 36413 static objects. The default is long_long_integer_type_node. 36414 36415 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 36416 This hook determines how guard variables are used. It should 36417 return `false' (the default) if the first byte should be used. A 36418 return value of `true' indicates that only the least significant 36419 bit should be used. 36420 36421 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 36422 This hook returns the size of the cookie to use when allocating an 36423 array whose elements have the indicated TYPE. Assumes that it is 36424 already known that a cookie is needed. The default is `max(sizeof 36425 (size_t), alignof(type))', as defined in section 2.7 of the 36426 IA64/Generic C++ ABI. 36427 36428 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 36429 This hook should return `true' if the element size should be 36430 stored in array cookies. The default is to return `false'. 36431 36432 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 36433 IMPORT_EXPORT) 36434 If defined by a backend this hook allows the decision made to 36435 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 36436 contain 1 if the class is going to be exported, -1 if it is going 36437 to be imported and 0 otherwise. This function should return the 36438 modified value and perform any other actions necessary to support 36439 the backend's targeted operating system. 36440 36441 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 36442 This hook should return `true' if constructors and destructors 36443 return the address of the object created/destroyed. The default 36444 is to return `false'. 36445 36446 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 36447 This hook returns true if the key method for a class (i.e., the 36448 method which, if defined in the current translation unit, causes 36449 the virtual table to be emitted) may be an inline function. Under 36450 the standard Itanium C++ ABI the key method may be an inline 36451 function so long as the function is not declared inline in the 36452 class definition. Under some variants of the ABI, an inline 36453 function can never be the key method. The default is to return 36454 `true'. 36455 36456 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 36457 DECL) 36458 DECL is a virtual table, virtual table table, typeinfo object, or 36459 other similar implicit class data object that will be emitted with 36460 external linkage in this translation unit. No ELF visibility has 36461 been explicitly specified. If the target needs to specify a 36462 visibility other than that of the containing class, use this hook 36463 to set `DECL_VISIBILITY' and `DECL_VISIBILITY_SPECIFIED'. 36464 36465 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 36466 This hook returns true (the default) if virtual tables and other 36467 similar implicit class data objects are always COMDAT if they have 36468 external linkage. If this hook returns false, then class data for 36469 classes whose virtual table will be emitted in only one translation 36470 unit will not be COMDAT. 36471 36472 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 36473 This hook returns true (the default) if the RTTI information for 36474 the basic types which is defined in the C++ runtime should always 36475 be COMDAT, false if it should not be COMDAT. 36476 36477 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 36478 This hook returns true if `__aeabi_atexit' (as defined by the ARM 36479 EABI) should be used to register static destructors when 36480 `-fuse-cxa-atexit' is in effect. The default is to return false 36481 to use `__cxa_atexit'. 36482 36483 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 36484 This hook returns true if the target `atexit' function can be used 36485 in the same manner as `__cxa_atexit' to register C++ static 36486 destructors. This requires that `atexit'-registered functions in 36487 shared libraries are run in the correct order when the libraries 36488 are unloaded. The default is to return false. 36489 36490 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 36491 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has 36492 just been defined. Use this hook to make adjustments to the class 36493 (eg, tweak visibility or perform any other required target 36494 modifications). 36495 36496 -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL) 36497 Return target-specific mangling context of DECL or `NULL_TREE'. 36498 36499 36500 File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: C++ ABI, Up: Target Macros 36501 36502 17.30 Adding support for named address spaces 36503 ============================================= 36504 36505 The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 36506 committee, `Programming Languages - C - Extensions to support embedded 36507 processors', specifies a syntax for embedded processors to specify 36508 alternate address spaces. You can configure a GCC port to support 36509 section 5.1 of the draft report to add support for address spaces other 36510 than the default address space. These address spaces are new keywords 36511 that are similar to the `volatile' and `const' type attributes. 36512 36513 Pointers to named address spaces can have a different size than 36514 pointers to the generic address space. 36515 36516 For example, the SPU port uses the `__ea' address space to refer to 36517 memory in the host processor, rather than memory local to the SPU 36518 processor. Access to memory in the `__ea' address space involves 36519 issuing DMA operations to move data between the host processor and the 36520 local processor memory address space. Pointers in the `__ea' address 36521 space are either 32 bits or 64 bits based on the `-mea32' or `-mea64' 36522 switches (native SPU pointers are always 32 bits). 36523 36524 Internally, address spaces are represented as a small integer in the 36525 range 0 to 15 with address space 0 being reserved for the generic 36526 address space. 36527 36528 To register a named address space qualifier keyword with the C front 36529 end, the target may call the `c_register_addr_space' routine. For 36530 example, the SPU port uses the following to declare `__ea' as the 36531 keyword for named address space #1: 36532 #define ADDR_SPACE_EA 1 36533 c_register_addr_space ("__ea", ADDR_SPACE_EA); 36534 36535 -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_POINTER_MODE 36536 (addr_space_t ADDRESS_SPACE) 36537 Define this to return the machine mode to use for pointers to 36538 ADDRESS_SPACE if the target supports named address spaces. The 36539 default version of this hook returns `ptr_mode' for the generic 36540 address space only. 36541 36542 -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_ADDRESS_MODE 36543 (addr_space_t ADDRESS_SPACE) 36544 Define this to return the machine mode to use for addresses in 36545 ADDRESS_SPACE if the target supports named address spaces. The 36546 default version of this hook returns `Pmode' for the generic 36547 address space only. 36548 36549 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE (enum 36550 machine_mode MODE, addr_space_t AS) 36551 Define this to return nonzero if the port can handle pointers with 36552 machine mode MODE to address space AS. This target hook is the 36553 same as the `TARGET_VALID_POINTER_MODE' target hook, except that 36554 it includes explicit named address space support. The default 36555 version of this hook returns true for the modes returned by either 36556 the `TARGET_ADDR_SPACE_POINTER_MODE' or 36557 `TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given 36558 address space. 36559 36560 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P (enum 36561 machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 36562 Define this to return true if EXP is a valid address for mode MODE 36563 in the named address space AS. The STRICT parameter says whether 36564 strict addressing is in effect after reload has finished. This 36565 target hook is the same as the `TARGET_LEGITIMATE_ADDRESS_P' 36566 target hook, except that it includes explicit named address space 36567 support. 36568 36569 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 36570 OLDX, enum machine_mode MODE, addr_space_t AS) 36571 Define this to modify an invalid address X to be a valid address 36572 with mode MODE in the named address space AS. This target hook is 36573 the same as the `TARGET_LEGITIMIZE_ADDRESS' target hook, except 36574 that it includes explicit named address space support. 36575 36576 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET, 36577 addr_space_t SUPERSET) 36578 Define this to return whether the SUBSET named address space is 36579 contained within the SUPERSET named address space. Pointers to a 36580 named address space that is a subset of another named address space 36581 will be converted automatically without a cast if used together in 36582 arithmetic operations. Pointers to a superset address space can be 36583 converted to pointers to a subset address space via explicit casts. 36584 36585 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 36586 tree TO_TYPE) 36587 Define this to convert the pointer expression represented by the 36588 RTL OP with type FROM_TYPE that points to a named address space to 36589 a new pointer expression with type TO_TYPE that points to a 36590 different named address space. When this hook it called, it is 36591 guaranteed that one of the two address spaces is a subset of the 36592 other, as determined by the `TARGET_ADDR_SPACE_SUBSET_P' target 36593 hook. 36594 36595 36596 File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 36597 36598 17.31 Miscellaneous Parameters 36599 ============================== 36600 36601 Here are several miscellaneous parameters. 36602 36603 -- Macro: HAS_LONG_COND_BRANCH 36604 Define this boolean macro to indicate whether or not your 36605 architecture has conditional branches that can span all of memory. 36606 It is used in conjunction with an optimization that partitions hot 36607 and cold basic blocks into separate sections of the executable. 36608 If this macro is set to false, gcc will convert any conditional 36609 branches that attempt to cross between sections into unconditional 36610 branches or indirect jumps. 36611 36612 -- Macro: HAS_LONG_UNCOND_BRANCH 36613 Define this boolean macro to indicate whether or not your 36614 architecture has unconditional branches that can span all of 36615 memory. It is used in conjunction with an optimization that 36616 partitions hot and cold basic blocks into separate sections of the 36617 executable. If this macro is set to false, gcc will convert any 36618 unconditional branches that attempt to cross between sections into 36619 indirect jumps. 36620 36621 -- Macro: CASE_VECTOR_MODE 36622 An alias for a machine mode name. This is the machine mode that 36623 elements of a jump-table should have. 36624 36625 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 36626 Optional: return the preferred mode for an `addr_diff_vec' when 36627 the minimum and maximum offset are known. If you define this, it 36628 enables extra code in branch shortening to deal with 36629 `addr_diff_vec'. To make this work, you also have to define 36630 `INSN_ALIGN' and make the alignment for `addr_diff_vec' explicit. 36631 The BODY argument is provided so that the offset_unsigned and scale 36632 flags can be updated. 36633 36634 -- Macro: CASE_VECTOR_PC_RELATIVE 36635 Define this macro to be a C expression to indicate when jump-tables 36636 should contain relative addresses. You need not define this macro 36637 if jump-tables never contain relative addresses, or jump-tables 36638 should contain relative addresses only when `-fPIC' or `-fPIC' is 36639 in effect. 36640 36641 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 36642 This function return the smallest number of different values for 36643 which it is best to use a jump-table instead of a tree of 36644 conditional branches. The default is four for machines with a 36645 `casesi' instruction and five otherwise. This is best for most 36646 machines. 36647 36648 -- Macro: WORD_REGISTER_OPERATIONS 36649 Define this macro if operations between registers with integral 36650 mode smaller than a word are always performed on the entire 36651 register. Most RISC machines have this property and most CISC 36652 machines do not. 36653 36654 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 36655 Define this macro to be a C expression indicating when insns that 36656 read memory in MEM_MODE, an integral mode narrower than a word, 36657 set the bits outside of MEM_MODE to be either the sign-extension 36658 or the zero-extension of the data read. Return `SIGN_EXTEND' for 36659 values of MEM_MODE for which the insn sign-extends, `ZERO_EXTEND' 36660 for which it zero-extends, and `UNKNOWN' for other modes. 36661 36662 This macro is not called with MEM_MODE non-integral or with a width 36663 greater than or equal to `BITS_PER_WORD', so you may return any 36664 value in this case. Do not define this macro if it would always 36665 return `UNKNOWN'. On machines where this macro is defined, you 36666 will normally define it as the constant `SIGN_EXTEND' or 36667 `ZERO_EXTEND'. 36668 36669 You may return a non-`UNKNOWN' value even if for some hard 36670 registers the sign extension is not performed, if for the 36671 `REGNO_REG_CLASS' of these hard registers 36672 `CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is 36673 MEM_MODE and the TO mode is any integral mode larger than this but 36674 not larger than `word_mode'. 36675 36676 You must return `UNKNOWN' if for some hard registers that allow 36677 this mode, `CANNOT_CHANGE_MODE_CLASS' says that they cannot change 36678 to `word_mode', but that they can change to another integral mode 36679 that is larger then MEM_MODE but still smaller than `word_mode'. 36680 36681 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 36682 Define this macro if loading short immediate values into registers 36683 sign extends. 36684 36685 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL (enum 36686 machine_mode MODE) 36687 When `-ffast-math' is in effect, GCC tries to optimize divisions 36688 by the same divisor, by turning them into multiplications by the 36689 reciprocal. This target hook specifies the minimum number of 36690 divisions that should be there for GCC to perform the optimization 36691 for a variable of mode MODE. The default implementation returns 3 36692 if the machine has an instruction for the division, and 2 if it 36693 does not. 36694 36695 -- Macro: MOVE_MAX 36696 The maximum number of bytes that a single instruction can move 36697 quickly between memory and registers or between two memory 36698 locations. 36699 36700 -- Macro: MAX_MOVE_MAX 36701 The maximum number of bytes that a single instruction can move 36702 quickly between memory and registers or between two memory 36703 locations. If this is undefined, the default is `MOVE_MAX'. 36704 Otherwise, it is the constant value that is the largest value that 36705 `MOVE_MAX' can have at run-time. 36706 36707 -- Macro: SHIFT_COUNT_TRUNCATED 36708 A C expression that is nonzero if on this machine the number of 36709 bits actually used for the count of a shift operation is equal to 36710 the number of bits needed to represent the size of the object 36711 being shifted. When this macro is nonzero, the compiler will 36712 assume that it is safe to omit a sign-extend, zero-extend, and 36713 certain bitwise `and' instructions that truncates the count of a 36714 shift operation. On machines that have instructions that act on 36715 bit-fields at variable positions, which may include `bit test' 36716 instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables 36717 deletion of truncations of the values that serve as arguments to 36718 bit-field instructions. 36719 36720 If both types of instructions truncate the count (for shifts) and 36721 position (for bit-field operations), or if no variable-position 36722 bit-field instructions exist, you should define this macro. 36723 36724 However, on some machines, such as the 80386 and the 680x0, 36725 truncation only applies to shift operations and not the (real or 36726 pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED' 36727 to be zero on such machines. Instead, add patterns to the `md' 36728 file that include the implied truncation of the shift instructions. 36729 36730 You need not define this macro if it would always have the value 36731 of zero. 36732 36733 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 36734 (enum machine_mode MODE) 36735 This function describes how the standard shift patterns for MODE 36736 deal with shifts by negative amounts or by more than the width of 36737 the mode. *Note shift patterns::. 36738 36739 On many machines, the shift patterns will apply a mask M to the 36740 shift count, meaning that a fixed-width shift of X by Y is 36741 equivalent to an arbitrary-width shift of X by Y & M. If this is 36742 true for mode MODE, the function should return M, otherwise it 36743 should return 0. A return value of 0 indicates that no particular 36744 behavior is guaranteed. 36745 36746 Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does 36747 _not_ apply to general shift rtxes; it applies only to instructions 36748 that are generated by the named shift patterns. 36749 36750 The default implementation of this function returns 36751 `GET_MODE_BITSIZE (MODE) - 1' if `SHIFT_COUNT_TRUNCATED' and 0 36752 otherwise. This definition is always safe, but if 36753 `SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 36754 nevertheless truncate the shift count, you may get better code by 36755 overriding it. 36756 36757 -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC) 36758 A C expression which is nonzero if on this machine it is safe to 36759 "convert" an integer of INPREC bits to one of OUTPREC bits (where 36760 OUTPREC is smaller than INPREC) by merely operating on it as if it 36761 had only OUTPREC bits. 36762 36763 On many machines, this expression can be 1. 36764 36765 When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for 36766 modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result. 36767 If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in 36768 such cases may improve things. 36769 36770 -- Target Hook: int TARGET_MODE_REP_EXTENDED (enum machine_mode MODE, 36771 enum machine_mode REP_MODE) 36772 The representation of an integral mode can be such that the values 36773 are always extended to a wider integral mode. Return 36774 `SIGN_EXTEND' if values of MODE are represented in sign-extended 36775 form to REP_MODE. Return `UNKNOWN' otherwise. (Currently, none 36776 of the targets use zero-extended representation this way so unlike 36777 `LOAD_EXTEND_OP', `TARGET_MODE_REP_EXTENDED' is expected to return 36778 either `SIGN_EXTEND' or `UNKNOWN'. Also no target extends MODE to 36779 REP_MODE so that REP_MODE is not the next widest integral mode and 36780 currently we take advantage of this fact.) 36781 36782 Similarly to `LOAD_EXTEND_OP' you may return a non-`UNKNOWN' value 36783 even if the extension is not performed on certain hard registers 36784 as long as for the `REGNO_REG_CLASS' of these hard registers 36785 `CANNOT_CHANGE_MODE_CLASS' returns nonzero. 36786 36787 Note that `TARGET_MODE_REP_EXTENDED' and `LOAD_EXTEND_OP' describe 36788 two related properties. If you define `TARGET_MODE_REP_EXTENDED 36789 (mode, word_mode)' you probably also want to define 36790 `LOAD_EXTEND_OP (mode)' to return the same type of extension. 36791 36792 In order to enforce the representation of `mode', 36793 `TRULY_NOOP_TRUNCATION' should return false when truncating to 36794 `mode'. 36795 36796 -- Macro: STORE_FLAG_VALUE 36797 A C expression describing the value returned by a comparison 36798 operator with an integral mode and stored by a store-flag 36799 instruction (`cstoreMODE4') when the condition is true. This 36800 description must apply to _all_ the `cstoreMODE4' patterns and all 36801 the comparison operators whose results have a `MODE_INT' mode. 36802 36803 A value of 1 or -1 means that the instruction implementing the 36804 comparison operator returns exactly 1 or -1 when the comparison is 36805 true and 0 when the comparison is false. Otherwise, the value 36806 indicates which bits of the result are guaranteed to be 1 when the 36807 comparison is true. This value is interpreted in the mode of the 36808 comparison operation, which is given by the mode of the first 36809 operand in the `cstoreMODE4' pattern. Either the low bit or the 36810 sign bit of `STORE_FLAG_VALUE' be on. Presently, only those bits 36811 are used by the compiler. 36812 36813 If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 36814 generate code that depends only on the specified bits. It can also 36815 replace comparison operators with equivalent operations if they 36816 cause the required bits to be set, even if the remaining bits are 36817 undefined. For example, on a machine whose comparison operators 36818 return an `SImode' value and where `STORE_FLAG_VALUE' is defined as 36819 `0x80000000', saying that just the sign bit is relevant, the 36820 expression 36821 36822 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 36823 36824 can be converted to 36825 36826 (ashift:SI X (const_int N)) 36827 36828 where N is the appropriate shift count to move the bit being 36829 tested into the sign bit. 36830 36831 There is no way to describe a machine that always sets the 36832 low-order bit for a true value, but does not guarantee the value 36833 of any other bits, but we do not know of any machine that has such 36834 an instruction. If you are trying to port GCC to such a machine, 36835 include an instruction to perform a logical-and of the result with 36836 1 in the pattern for the comparison operators and let us know at 36837 <gcc (a] gcc.gnu.org>. 36838 36839 Often, a machine will have multiple instructions that obtain a 36840 value from a comparison (or the condition codes). Here are rules 36841 to guide the choice of value for `STORE_FLAG_VALUE', and hence the 36842 instructions to be used: 36843 36844 * Use the shortest sequence that yields a valid definition for 36845 `STORE_FLAG_VALUE'. It is more efficient for the compiler to 36846 "normalize" the value (convert it to, e.g., 1 or 0) than for 36847 the comparison operators to do so because there may be 36848 opportunities to combine the normalization with other 36849 operations. 36850 36851 * For equal-length sequences, use a value of 1 or -1, with -1 36852 being slightly preferred on machines with expensive jumps and 36853 1 preferred on other machines. 36854 36855 * As a second choice, choose a value of `0x80000001' if 36856 instructions exist that set both the sign and low-order bits 36857 but do not define the others. 36858 36859 * Otherwise, use a value of `0x80000000'. 36860 36861 Many machines can produce both the value chosen for 36862 `STORE_FLAG_VALUE' and its negation in the same number of 36863 instructions. On those machines, you should also define a pattern 36864 for those cases, e.g., one matching 36865 36866 (set A (neg:M (ne:M B C))) 36867 36868 Some machines can also perform `and' or `plus' operations on 36869 condition code values with less instructions than the corresponding 36870 `cstoreMODE4' insn followed by `and' or `plus'. On those 36871 machines, define the appropriate patterns. Use the names `incscc' 36872 and `decscc', respectively, for the patterns which perform `plus' 36873 or `minus' operations on condition code values. See `rs6000.md' 36874 for some examples. The GNU Superoptimizer can be used to find 36875 such instruction sequences on other machines. 36876 36877 If this macro is not defined, the default value, 1, is used. You 36878 need not define `STORE_FLAG_VALUE' if the machine has no store-flag 36879 instructions, or if the value generated by these instructions is 1. 36880 36881 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 36882 A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is 36883 returned when comparison operators with floating-point results are 36884 true. Define this macro on machines that have comparison 36885 operations that return floating-point values. If there are no 36886 such operations, do not define this macro. 36887 36888 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 36889 A C expression that gives a rtx representing the nonzero true 36890 element for vector comparisons. The returned rtx should be valid 36891 for the inner mode of MODE which is guaranteed to be a vector 36892 mode. Define this macro on machines that have vector comparison 36893 operations that return a vector result. If there are no such 36894 operations, do not define this macro. Typically, this macro is 36895 defined as `const1_rtx' or `constm1_rtx'. This macro may return 36896 `NULL_RTX' to prevent the compiler optimizing such vector 36897 comparison operations for the given mode. 36898 36899 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 36900 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 36901 A C expression that indicates whether the architecture defines a 36902 value for `clz' or `ctz' with a zero operand. A result of `0' 36903 indicates the value is undefined. If the value is defined for 36904 only the RTL expression, the macro should evaluate to `1'; if the 36905 value applies also to the corresponding optab entry (which is 36906 normally the case if it expands directly into the corresponding 36907 RTL), then the macro should evaluate to `2'. In the cases where 36908 the value is defined, VALUE should be set to this value. 36909 36910 If this macro is not defined, the value of `clz' or `ctz' at zero 36911 is assumed to be undefined. 36912 36913 This macro must be defined if the target's expansion for `ffs' 36914 relies on a particular value to get correct results. Otherwise it 36915 is not necessary, though it may be used to optimize some corner 36916 cases, and to provide a default expansion for the `ffs' optab. 36917 36918 Note that regardless of this macro the "definedness" of `clz' and 36919 `ctz' at zero do _not_ extend to the builtin functions visible to 36920 the user. Thus one may be free to adjust the value at will to 36921 match the target expansion of these operations without fear of 36922 breaking the API. 36923 36924 -- Macro: Pmode 36925 An alias for the machine mode for pointers. On most machines, 36926 define this to be the integer mode corresponding to the width of a 36927 hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit 36928 machines. On some machines you must define this to be one of the 36929 partial integer modes, such as `PSImode'. 36930 36931 The width of `Pmode' must be at least as large as the value of 36932 `POINTER_SIZE'. If it is not equal, you must define the macro 36933 `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 36934 `Pmode'. 36935 36936 -- Macro: FUNCTION_MODE 36937 An alias for the machine mode used for memory references to 36938 functions being called, in `call' RTL expressions. On most CISC 36939 machines, where an instruction can begin at any byte address, this 36940 should be `QImode'. On most RISC machines, where all instructions 36941 have fixed size and alignment, this should be a mode with the same 36942 size and alignment as the machine instruction words - typically 36943 `SImode' or `HImode'. 36944 36945 -- Macro: STDC_0_IN_SYSTEM_HEADERS 36946 In normal operation, the preprocessor expands `__STDC__' to the 36947 constant 1, to signify that GCC conforms to ISO Standard C. On 36948 some hosts, like Solaris, the system compiler uses a different 36949 convention, where `__STDC__' is normally 0, but is 1 if the user 36950 specifies strict conformance to the C Standard. 36951 36952 Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 36953 convention when processing system header files, but when 36954 processing user files `__STDC__' will always expand to 1. 36955 36956 -- C Target Hook: const char * TARGET_C_PREINCLUDE (void) 36957 Define this hook to return the name of a header file to be 36958 included at the start of all compilations, as if it had been 36959 included with `#include <FILE>'. If this hook returns `NULL', or 36960 is not defined, or the header is not found, or if the user 36961 specifies `-ffreestanding' or `-nostdinc', no header is included. 36962 36963 This hook can be used together with a header provided by the 36964 system C library to implement ISO C requirements for certain 36965 macros to be predefined that describe properties of the whole 36966 implementation rather than just the compiler. 36967 36968 -- Macro: NO_IMPLICIT_EXTERN_C 36969 Define this macro if the system header files support C++ as well 36970 as C. This macro inhibits the usual method of using system header 36971 files in C++, which is to pretend that the file's contents are 36972 enclosed in `extern "C" {...}'. 36973 36974 -- Macro: REGISTER_TARGET_PRAGMAS () 36975 Define this macro if you want to implement any target-specific 36976 pragmas. If defined, it is a C expression which makes a series of 36977 calls to `c_register_pragma' or `c_register_pragma_with_expansion' 36978 for each pragma. The macro may also do any setup required for the 36979 pragmas. 36980 36981 The primary reason to define this macro is to provide 36982 compatibility with other compilers for the same target. In 36983 general, we discourage definition of target-specific pragmas for 36984 GCC. 36985 36986 If the pragma can be implemented by attributes then you should 36987 consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as 36988 well. 36989 36990 Preprocessor macros that appear on pragma lines are not expanded. 36991 All `#pragma' directives that do not match any registered pragma 36992 are silently ignored, unless the user specifies 36993 `-Wunknown-pragmas'. 36994 36995 -- Function: void c_register_pragma (const char *SPACE, const char 36996 *NAME, void (*CALLBACK) (struct cpp_reader *)) 36997 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 36998 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 36999 Each call to `c_register_pragma' or 37000 `c_register_pragma_with_expansion' establishes one pragma. The 37001 CALLBACK routine will be called when the preprocessor encounters a 37002 pragma of the form 37003 37004 #pragma [SPACE] NAME ... 37005 37006 SPACE is the case-sensitive namespace of the pragma, or `NULL' to 37007 put the pragma in the global namespace. The callback routine 37008 receives PFILE as its first argument, which can be passed on to 37009 cpplib's functions if necessary. You can lex tokens after the 37010 NAME by calling `pragma_lex'. Tokens that are not read by the 37011 callback will be silently ignored. The end of the line is 37012 indicated by a token of type `CPP_EOF'. Macro expansion occurs on 37013 the arguments of pragmas registered with 37014 `c_register_pragma_with_expansion' but not on the arguments of 37015 pragmas registered with `c_register_pragma'. 37016 37017 Note that the use of `pragma_lex' is specific to the C and C++ 37018 compilers. It will not work in the Java or Fortran compilers, or 37019 any other language compilers for that matter. Thus if 37020 `pragma_lex' is going to be called from target-specific code, it 37021 must only be done so when building the C and C++ compilers. This 37022 can be done by defining the variables `c_target_objs' and 37023 `cxx_target_objs' in the target entry in the `config.gcc' file. 37024 These variables should name the target-specific, language-specific 37025 object file which contains the code that uses `pragma_lex'. Note 37026 it will also be necessary to add a rule to the makefile fragment 37027 pointed to by `tmake_file' that shows how to build this object 37028 file. 37029 37030 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 37031 Define this macro if macros should be expanded in the arguments of 37032 `#pragma pack'. 37033 37034 -- Macro: TARGET_DEFAULT_PACK_STRUCT 37035 If your target requires a structure packing default other than 0 37036 (meaning the machine default), define this macro to the necessary 37037 value (in bytes). This must be a value that would also be valid 37038 to use with `#pragma pack()' (that is, a small power of two). 37039 37040 -- Macro: DOLLARS_IN_IDENTIFIERS 37041 Define this macro to control use of the character `$' in 37042 identifier names for the C family of languages. 0 means `$' is 37043 not allowed by default; 1 means it is allowed. 1 is the default; 37044 there is no need to define this macro in that case. 37045 37046 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 37047 Define this macro as a C expression that is nonzero if it is safe 37048 for the delay slot scheduler to place instructions in the delay 37049 slot of INSN, even if they appear to use a resource set or 37050 clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC 37051 knows that every `call_insn' has this behavior. On machines where 37052 some `insn' or `jump_insn' is really a function call and hence has 37053 this behavior, you should define this macro. 37054 37055 You need not define this macro if it would always return zero. 37056 37057 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 37058 Define this macro as a C expression that is nonzero if it is safe 37059 for the delay slot scheduler to place instructions in the delay 37060 slot of INSN, even if they appear to set or clobber a resource 37061 referenced in INSN. INSN is always a `jump_insn' or an `insn'. 37062 On machines where some `insn' or `jump_insn' is really a function 37063 call and its operands are registers whose use is actually in the 37064 subroutine it calls, you should define this macro. Doing so 37065 allows the delay slot scheduler to move instructions which copy 37066 arguments into the argument registers into the delay slot of INSN. 37067 37068 You need not define this macro if it would always return zero. 37069 37070 -- Macro: MULTIPLE_SYMBOL_SPACES 37071 Define this macro as a C expression that is nonzero if, in some 37072 cases, global symbols from one translation unit may not be bound 37073 to undefined symbols in another translation unit without user 37074 intervention. For instance, under Microsoft Windows symbols must 37075 be explicitly imported from shared libraries (DLLs). 37076 37077 You need not define this macro if it would always evaluate to zero. 37078 37079 -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree 37080 INPUTS, tree CLOBBERS) 37081 This target hook should add to CLOBBERS `STRING_CST' trees for any 37082 hard regs the port wishes to automatically clobber for an asm. It 37083 should return the result of the last `tree_cons' used to add a 37084 clobber. The OUTPUTS, INPUTS and CLOBBER lists are the 37085 corresponding parameters to the asm and may be inspected to avoid 37086 clobbering a register that is an input or output of the asm. You 37087 can use `tree_overlaps_hard_reg_set', declared in `tree.h', to test 37088 for overlap with regards to asm-declared registers. 37089 37090 -- Macro: MATH_LIBRARY 37091 Define this macro as a C string constant for the linker argument 37092 to link in the system math library, minus the initial `"-l"', or 37093 `""' if the target does not have a separate math library. 37094 37095 You need only define this macro if the default of `"m"' is wrong. 37096 37097 -- Macro: LIBRARY_PATH_ENV 37098 Define this macro as a C string constant for the environment 37099 variable that specifies where the linker should look for libraries. 37100 37101 You need only define this macro if the default of `"LIBRARY_PATH"' 37102 is wrong. 37103 37104 -- Macro: TARGET_POSIX_IO 37105 Define this macro if the target supports the following POSIX file 37106 functions, access, mkdir and file locking with fcntl / F_SETLKW. 37107 Defining `TARGET_POSIX_IO' will enable the test coverage code to 37108 use file locking when exiting a program, which avoids race 37109 conditions if the program has forked. It will also create 37110 directories at run-time for cross-profiling. 37111 37112 -- Macro: MAX_CONDITIONAL_EXECUTE 37113 A C expression for the maximum number of instructions to execute 37114 via conditional execution instructions instead of a branch. A 37115 value of `BRANCH_COST'+1 is the default if the machine does not 37116 use cc0, and 1 if it does use cc0. 37117 37118 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 37119 Used if the target needs to perform machine-dependent 37120 modifications on the conditionals used for turning basic blocks 37121 into conditionally executed code. CE_INFO points to a data 37122 structure, `struct ce_if_block', which contains information about 37123 the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the 37124 tests that are used for converting the then-block and the 37125 else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a 37126 null pointer if the tests cannot be converted. 37127 37128 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 37129 FALSE_EXPR) 37130 Like `IFCVT_MODIFY_TESTS', but used when converting more 37131 complicated if-statements into conditions combined by `and' and 37132 `or' operations. BB contains the basic block that contains the 37133 test that is currently being processed and about to be turned into 37134 a condition. 37135 37136 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 37137 A C expression to modify the PATTERN of an INSN that is to be 37138 converted to conditional execution format. CE_INFO points to a 37139 data structure, `struct ce_if_block', which contains information 37140 about the currently processed blocks. 37141 37142 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 37143 A C expression to perform any final machine dependent 37144 modifications in converting code to conditional execution. The 37145 involved basic blocks can be found in the `struct ce_if_block' 37146 structure that is pointed to by CE_INFO. 37147 37148 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 37149 A C expression to cancel any machine dependent modifications in 37150 converting code to conditional execution. The involved basic 37151 blocks can be found in the `struct ce_if_block' structure that is 37152 pointed to by CE_INFO. 37153 37154 -- Macro: IFCVT_MACHDEP_INIT (CE_INFO) 37155 A C expression to initialize any machine specific data for 37156 if-conversion of the if-block in the `struct ce_if_block' 37157 structure that is pointed to by CE_INFO. 37158 37159 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 37160 If non-null, this hook performs a target-specific pass over the 37161 instruction stream. The compiler will run it at all optimization 37162 levels, just before the point at which it normally does 37163 delayed-branch scheduling. 37164 37165 The exact purpose of the hook varies from target to target. Some 37166 use it to do transformations that are necessary for correctness, 37167 such as laying out in-function constant pools or avoiding hardware 37168 hazards. Others use it as an opportunity to do some 37169 machine-dependent optimizations. 37170 37171 You need not implement the hook if it has nothing to do. The 37172 default definition is null. 37173 37174 -- Target Hook: void TARGET_INIT_BUILTINS (void) 37175 Define this hook if you have any machine-specific built-in 37176 functions that need to be defined. It should be a function that 37177 performs the necessary setup. 37178 37179 Machine specific built-in functions can be useful to expand 37180 special machine instructions that would otherwise not normally be 37181 generated because they have no equivalent in the source language 37182 (for example, SIMD vector instructions or prefetch instructions). 37183 37184 To create a built-in function, call the function 37185 `lang_hooks.builtin_function' which is defined by the language 37186 front end. You can use any type nodes set up by 37187 `build_common_tree_nodes'; only language front ends that use those 37188 two functions will call `TARGET_INIT_BUILTINS'. 37189 37190 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 37191 INITIALIZE_P) 37192 Define this hook if you have any machine-specific built-in 37193 functions that need to be defined. It should be a function that 37194 returns the builtin function declaration for the builtin function 37195 code CODE. If there is no such builtin and it cannot be 37196 initialized at this time if INITIALIZE_P is true the function 37197 should return `NULL_TREE'. If CODE is out of range the function 37198 should return `error_mark_node'. 37199 37200 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 37201 SUBTARGET, enum machine_mode MODE, int IGNORE) 37202 Expand a call to a machine specific built-in function that was set 37203 up by `TARGET_INIT_BUILTINS'. EXP is the expression for the 37204 function call; the result should go to TARGET if that is 37205 convenient, and have mode MODE if that is convenient. SUBTARGET 37206 may be used as the target for computing one of EXP's operands. 37207 IGNORE is nonzero if the value is to be ignored. This function 37208 should return the result of the call to the built-in function. 37209 37210 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 37211 LOC, tree FNDECL, void *ARGLIST) 37212 Select a replacement for a machine specific built-in function that 37213 was set up by `TARGET_INIT_BUILTINS'. This is done _before_ 37214 regular type checking, and so allows the target to implement a 37215 crude form of function overloading. FNDECL is the declaration of 37216 the built-in function. ARGLIST is the list of arguments passed to 37217 the built-in function. The result is a complete expression that 37218 implements the operation, usually another `CALL_EXPR'. ARGLIST 37219 really has type `VEC(tree,gc)*' 37220 37221 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, 37222 tree *ARGP, bool IGNORE) 37223 Fold a call to a machine specific built-in function that was set 37224 up by `TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 37225 built-in function. N_ARGS is the number of arguments passed to 37226 the function; the arguments themselves are pointed to by ARGP. 37227 The result is another tree containing a simplified expression for 37228 the call's result. If IGNORE is true the value will be ignored. 37229 37230 -- Target Hook: int TARGET_COMPARE_VERSION_PRIORITY (tree DECL1, tree 37231 DECL2) 37232 This hook is used to compare the target attributes in two 37233 functions to determine which function's features get higher 37234 priority. This is used during function multi-versioning to figure 37235 out the order in which two versions must be dispatched. A 37236 function version with a higher priority is checked for dispatching 37237 earlier. DECL1 and DECL2 are the two function decls that will be 37238 compared. 37239 37240 -- Target Hook: tree TARGET_GET_FUNCTION_VERSIONS_DISPATCHER (void 37241 *DECL) 37242 This hook is used to get the dispatcher function for a set of 37243 function versions. The dispatcher function is called to invoke 37244 the right function version at run-time. DECL is one version from a 37245 set of semantically identical versions. 37246 37247 -- Target Hook: tree TARGET_GENERATE_VERSION_DISPATCHER_BODY (void 37248 *ARG) 37249 This hook is used to generate the dispatcher logic to invoke the 37250 right function version at run-time for a given set of function 37251 versions. ARG points to the callgraph node of the dispatcher 37252 function whose body must be generated. 37253 37254 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const_rtx 37255 INSN) 37256 Take an instruction in INSN and return NULL if it is valid within a 37257 low-overhead loop, otherwise return a string explaining why doloop 37258 could not be applied. 37259 37260 Many targets use special registers for low-overhead looping. For 37261 any instruction that clobbers these this function should return a 37262 string indicating the reason why the doloop could not be applied. 37263 By default, the RTL loop optimizer does not use a present doloop 37264 pattern for loops containing function calls or branch on table 37265 instructions. 37266 37267 -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx INSN) 37268 Take an instruction in INSN and return `false' if the instruction 37269 is not appropriate as a combination of two or more instructions. 37270 The default is to accept all instructions. 37271 37272 -- Macro: MD_CAN_REDIRECT_BRANCH (BRANCH1, BRANCH2) 37273 Take a branch insn in BRANCH1 and another in BRANCH2. Return true 37274 if redirecting BRANCH1 to the destination of BRANCH2 is possible. 37275 37276 On some targets, branches may have a limited range. Optimizing the 37277 filling of delay slots can result in branches being redirected, 37278 and this may in turn cause a branch offset to overflow. 37279 37280 -- Target Hook: bool TARGET_CAN_FOLLOW_JUMP (const_rtx FOLLOWER, 37281 const_rtx FOLLOWEE) 37282 FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if 37283 FOLLOWER may be modified to follow FOLLOWEE; false, if it can't. 37284 For example, on some targets, certain kinds of branches can't be 37285 made to follow through a hot/cold partitioning. 37286 37287 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 37288 This target hook returns `true' if X is considered to be 37289 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 37290 PA doesn't consider PLUS to be commutative inside a MEM. 37291 OUTER_CODE is the rtx code of the enclosing rtl, if known, 37292 otherwise it is UNKNOWN. 37293 37294 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 37295 When the initial value of a hard register has been copied in a 37296 pseudo register, it is often not necessary to actually allocate 37297 another register to this pseudo register, because the original 37298 hard register or a stack slot it has been saved into can be used. 37299 `TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 37300 allocation once for each hard register that had its initial value 37301 copied by using `get_func_hard_reg_initial_val' or 37302 `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if 37303 you don't want to do any special allocation, a `REG' rtx--that 37304 would typically be the hard register itself, if it is known not to 37305 be clobbered--or a `MEM'. If you are returning a `MEM', this is 37306 only a hint for the allocator; it might decide to use another 37307 register anyways. You may use `current_function_is_leaf' or 37308 `REG_N_SETS' in the hook to determine if the hard register in 37309 question will not be clobbered. The default value of this hook is 37310 `NULL', which disables any special allocation. 37311 37312 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 37313 FLAGS) 37314 This target hook returns nonzero if X, an `unspec' or 37315 `unspec_volatile' operation, might cause a trap. Targets can use 37316 this hook to enhance precision of analysis for `unspec' and 37317 `unspec_volatile' operations. You may call `may_trap_p_1' to 37318 analyze inner elements of X in which case FLAGS should be passed 37319 along. 37320 37321 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 37322 The compiler invokes this hook whenever it changes its current 37323 function context (`cfun'). You can define this function if the 37324 back end needs to perform any initialization or reset actions on a 37325 per-function basis. For example, it may be used to implement 37326 function attributes that affect register usage or code generation 37327 patterns. The argument DECL is the declaration for the new 37328 function context, and may be null to indicate that the compiler 37329 has left a function context and is returning to processing at the 37330 top level. The default hook function does nothing. 37331 37332 GCC sets `cfun' to a dummy function context during initialization 37333 of some parts of the back end. The hook function is not invoked 37334 in this situation; you need not worry about the hook being invoked 37335 recursively, or when the back end is in a partially-initialized 37336 state. `cfun' might be `NULL' to indicate processing at top level, 37337 outside of any function scope. 37338 37339 -- Macro: TARGET_OBJECT_SUFFIX 37340 Define this macro to be a C string representing the suffix for 37341 object files on your target machine. If you do not define this 37342 macro, GCC will use `.o' as the suffix for object files. 37343 37344 -- Macro: TARGET_EXECUTABLE_SUFFIX 37345 Define this macro to be a C string representing the suffix to be 37346 automatically added to executable files on your target machine. 37347 If you do not define this macro, GCC will use the null string as 37348 the suffix for executable files. 37349 37350 -- Macro: COLLECT_EXPORT_LIST 37351 If defined, `collect2' will scan the individual object files 37352 specified on its command line and create an export list for the 37353 linker. Define this macro for systems like AIX, where the linker 37354 discards object files that are not referenced from `main' and uses 37355 export lists. 37356 37357 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 37358 Define this macro to a C expression representing a variant of the 37359 method call MDECL, if Java Native Interface (JNI) methods must be 37360 invoked differently from other methods on your target. For 37361 example, on 32-bit Microsoft Windows, JNI methods must be invoked 37362 using the `stdcall' calling convention and this macro is then 37363 defined as this expression: 37364 37365 build_type_attribute_variant (MDECL, 37366 build_tree_list 37367 (get_identifier ("stdcall"), 37368 NULL)) 37369 37370 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 37371 This target hook returns `true' past the point in which new jump 37372 instructions could be created. On machines that require a 37373 register for every jump such as the SHmedia ISA of SH5, this point 37374 would typically be reload, so this target hook should be defined 37375 to a function such as: 37376 37377 static bool 37378 cannot_modify_jumps_past_reload_p () 37379 { 37380 return (reload_completed || reload_in_progress); 37381 } 37382 37383 -- Target Hook: reg_class_t TARGET_BRANCH_TARGET_REGISTER_CLASS (void) 37384 This target hook returns a register class for which branch target 37385 register optimizations should be applied. All registers in this 37386 class should be usable interchangeably. After reload, registers 37387 in this class will be re-allocated and loads will be hoisted out 37388 of loops and be subjected to inter-block scheduling. 37389 37390 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 37391 AFTER_PROLOGUE_EPILOGUE_GEN) 37392 Branch target register optimization will by default exclude 37393 callee-saved registers that are not already live during the 37394 current function; if this target hook returns true, they will be 37395 included. The target code must than make sure that all target 37396 registers in the class returned by 37397 `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are 37398 saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and 37399 epilogues have already been generated. Note, even if you only 37400 return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still 37401 are likely to have to make special provisions in 37402 `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 37403 target registers. 37404 37405 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 37406 This target hook returns true if the target supports conditional 37407 execution. This target hook is required only when the target has 37408 several different modes and they have different conditional 37409 execution capability, such as ARM. 37410 37411 -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL, 37412 struct loop *LOOP) 37413 This target hook returns a new value for the number of times LOOP 37414 should be unrolled. The parameter NUNROLL is the number of times 37415 the loop is to be unrolled. The parameter LOOP is a pointer to the 37416 loop, which is going to be checked for unrolling. This target hook 37417 is required only when the target has special constraints like 37418 maximum number of memory accesses. 37419 37420 -- Macro: POWI_MAX_MULTS 37421 If defined, this macro is interpreted as a signed integer C 37422 expression that specifies the maximum number of floating point 37423 multiplications that should be emitted when expanding 37424 exponentiation by an integer constant inline. When this value is 37425 defined, exponentiation requiring more than this number of 37426 multiplications is implemented by calling the system library's 37427 `pow', `powf' or `powl' routines. The default value places no 37428 upper bound on the multiplication count. 37429 37430 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 37431 *IPREFIX, int STDINC) 37432 This target hook should register any extra include files for the 37433 target. The parameter STDINC indicates if normal include files 37434 are present. The parameter SYSROOT is the system root directory. 37435 The parameter IPREFIX is the prefix for the gcc directory. 37436 37437 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 37438 char *IPREFIX, int STDINC) 37439 This target hook should register any extra include files for the 37440 target before any standard headers. The parameter STDINC 37441 indicates if normal include files are present. The parameter 37442 SYSROOT is the system root directory. The parameter IPREFIX is 37443 the prefix for the gcc directory. 37444 37445 -- Macro: void TARGET_OPTF (char *PATH) 37446 This target hook should register special include paths for the 37447 target. The parameter PATH is the include to register. On Darwin 37448 systems, this is used for Framework includes, which have semantics 37449 that are different from `-I'. 37450 37451 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 37452 This target macro returns `true' if it is safe to use a local alias 37453 for a virtual function FNDECL when constructing thunks, `false' 37454 otherwise. By default, the macro returns `true' for all 37455 functions, if a target supports aliases (i.e. defines 37456 `ASM_OUTPUT_DEF'), `false' otherwise, 37457 37458 -- Macro: TARGET_FORMAT_TYPES 37459 If defined, this macro is the name of a global variable containing 37460 target-specific format checking information for the `-Wformat' 37461 option. The default is to have no target-specific format checks. 37462 37463 -- Macro: TARGET_N_FORMAT_TYPES 37464 If defined, this macro is the number of entries in 37465 `TARGET_FORMAT_TYPES'. 37466 37467 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 37468 If defined, this macro is the name of a global variable containing 37469 target-specific format overrides for the `-Wformat' option. The 37470 default is to have no target-specific format overrides. If defined, 37471 `TARGET_FORMAT_TYPES' must be defined, too. 37472 37473 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 37474 If defined, this macro specifies the number of entries in 37475 `TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 37476 37477 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 37478 If defined, this macro specifies the optional initialization 37479 routine for target specific customizations of the system printf 37480 and scanf formatter settings. 37481 37482 -- Target Hook: bool TARGET_RELAXED_ORDERING 37483 If set to `true', means that the target's memory model does not 37484 guarantee that loads which do not depend on one another will access 37485 main memory in the order of the instruction stream; if ordering is 37486 important, an explicit memory barrier must be used. This is true 37487 of many recent processors which implement a policy of "relaxed," 37488 "weak," or "release" memory consistency, such as Alpha, PowerPC, 37489 and ia64. The default is `false'. 37490 37491 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 37492 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 37493 If defined, this macro returns the diagnostic message when it is 37494 illegal to pass argument VAL to function FUNCDECL with prototype 37495 TYPELIST. 37496 37497 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 37498 FROMTYPE, const_tree TOTYPE) 37499 If defined, this macro returns the diagnostic message when it is 37500 invalid to convert from FROMTYPE to TOTYPE, or `NULL' if validity 37501 should be determined by the front end. 37502 37503 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 37504 const_tree TYPE) 37505 If defined, this macro returns the diagnostic message when it is 37506 invalid to apply operation OP (where unary plus is denoted by 37507 `CONVERT_EXPR') to an operand of type TYPE, or `NULL' if validity 37508 should be determined by the front end. 37509 37510 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 37511 const_tree TYPE1, const_tree TYPE2) 37512 If defined, this macro returns the diagnostic message when it is 37513 invalid to apply operation OP to operands of types TYPE1 and 37514 TYPE2, or `NULL' if validity should be determined by the front end. 37515 37516 -- Target Hook: const char * TARGET_INVALID_PARAMETER_TYPE (const_tree 37517 TYPE) 37518 If defined, this macro returns the diagnostic message when it is 37519 invalid for functions to include parameters of type TYPE, or 37520 `NULL' if validity should be determined by the front end. This is 37521 currently used only by the C and C++ front ends. 37522 37523 -- Target Hook: const char * TARGET_INVALID_RETURN_TYPE (const_tree 37524 TYPE) 37525 If defined, this macro returns the diagnostic message when it is 37526 invalid for functions to have return type TYPE, or `NULL' if 37527 validity should be determined by the front end. This is currently 37528 used only by the C and C++ front ends. 37529 37530 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 37531 If defined, this target hook returns the type to which values of 37532 TYPE should be promoted when they appear in expressions, analogous 37533 to the integer promotions, or `NULL_TREE' to use the front end's 37534 normal promotion rules. This hook is useful when there are 37535 target-specific types with special promotion rules. This is 37536 currently used only by the C and C++ front ends. 37537 37538 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 37539 If defined, this hook returns the result of converting EXPR to 37540 TYPE. It should return the converted expression, or `NULL_TREE' 37541 to apply the front end's normal conversion rules. This hook is 37542 useful when there are target-specific types with special 37543 conversion rules. This is currently used only by the C and C++ 37544 front ends. 37545 37546 -- Macro: TARGET_USE_JCR_SECTION 37547 This macro determines whether to use the JCR section to register 37548 Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1 37549 if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true, 37550 else 0. 37551 37552 -- Macro: OBJC_JBLEN 37553 This macro determines the size of the objective C jump buffer for 37554 the NeXT runtime. By default, OBJC_JBLEN is defined to an 37555 innocuous value. 37556 37557 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 37558 Define this macro if any target-specific attributes need to be 37559 attached to the functions in `libgcc' that provide low-level 37560 support for call stack unwinding. It is used in declarations in 37561 `unwind-generic.h' and the associated definitions of those 37562 functions. 37563 37564 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 37565 Define this macro to update the current function stack boundary if 37566 necessary. 37567 37568 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 37569 This hook should return an rtx for Dynamic Realign Argument 37570 Pointer (DRAP) if a different argument pointer register is needed 37571 to access the function's argument list due to stack realignment. 37572 Return `NULL' if no DRAP is needed. 37573 37574 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 37575 When optimization is disabled, this hook indicates whether or not 37576 arguments should be allocated to stack slots. Normally, GCC 37577 allocates stacks slots for arguments when not optimizing in order 37578 to make debugging easier. However, when a function is declared 37579 with `__attribute__((naked))', there is no stack frame, and the 37580 compiler cannot safely move arguments from the registers in which 37581 they are passed to the stack. Therefore, this hook should return 37582 true in general, but false for naked functions. The default 37583 implementation always returns true. 37584 37585 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 37586 On some architectures it can take multiple instructions to 37587 synthesize a constant. If there is another constant already in a 37588 register that is close enough in value then it is preferable that 37589 the new constant is computed from this register using immediate 37590 addition or subtraction. We accomplish this through CSE. Besides 37591 the value of the constant we also add a lower and an upper 37592 constant anchor to the available expressions. These are then 37593 queried when encountering new constants. The anchors are computed 37594 by rounding the constant up and down to a multiple of the value of 37595 `TARGET_CONST_ANCHOR'. `TARGET_CONST_ANCHOR' should be the 37596 maximum positive value accepted by immediate-add plus one. We 37597 currently assume that the value of `TARGET_CONST_ANCHOR' is a 37598 power of 2. For example, on MIPS, where add-immediate takes a 37599 16-bit signed value, `TARGET_CONST_ANCHOR' is set to `0x8000'. 37600 The default value is zero, which disables this optimization. 37601 37602 -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void) 37603 Return the offset bitwise ored into shifted address to get 37604 corresponding Address Sanitizer shadow memory address. NULL if 37605 Address Sanitizer is not supported by the target. 37606 37607 -- Target Hook: unsigned HOST_WIDE_INT TARGET_MEMMODEL_CHECK (unsigned 37608 HOST_WIDE_INT VAL) 37609 Validate target specific memory model mask bits. When NULL no 37610 target specific memory model bits are allowed. 37611 37612 -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 37613 This value should be set if the result written by 37614 `atomic_test_and_set' is not exactly 1, i.e. the `bool' `true'. 37615 37616 37617 File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 37618 37619 18 Host Configuration 37620 ********************* 37621 37622 Most details about the machine and system on which the compiler is 37623 actually running are detected by the `configure' script. Some things 37624 are impossible for `configure' to detect; these are described in two 37625 ways, either by macros defined in a file named `xm-MACHINE.h' or by 37626 hook functions in the file specified by the OUT_HOST_HOOK_OBJ variable 37627 in `config.gcc'. (The intention is that very few hosts will need a 37628 header file but nearly every fully supported host will need to override 37629 some hooks.) 37630 37631 If you need to define only a few macros, and they have simple 37632 definitions, consider using the `xm_defines' variable in your 37633 `config.gcc' entry instead of creating a host configuration header. 37634 *Note System Config::. 37635 37636 * Menu: 37637 37638 * Host Common:: Things every host probably needs implemented. 37639 * Filesystem:: Your host can't have the letter `a' in filenames? 37640 * Host Misc:: Rare configuration options for hosts. 37641 37642 37643 File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 37644 37645 18.1 Host Common 37646 ================ 37647 37648 Some things are just not portable, even between similar operating 37649 systems, and are too difficult for autoconf to detect. They get 37650 implemented using hook functions in the file specified by the 37651 HOST_HOOK_OBJ variable in `config.gcc'. 37652 37653 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 37654 This host hook is used to set up handling for extra signals. The 37655 most common thing to do in this hook is to detect stack overflow. 37656 37657 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 37658 FD) 37659 This host hook returns the address of some space that is likely to 37660 be free in some subsequent invocation of the compiler. We intend 37661 to load the PCH data at this address such that the data need not 37662 be relocated. The area should be able to hold SIZE bytes. If the 37663 host uses `mmap', FD is an open file descriptor that can be used 37664 for probing. 37665 37666 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, 37667 size_t SIZE, int FD, size_t OFFSET) 37668 This host hook is called when a PCH file is about to be loaded. 37669 We want to load SIZE bytes from FD at OFFSET into memory at 37670 ADDRESS. The given address will be the result of a previous 37671 invocation of `HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we 37672 couldn't allocate SIZE bytes at ADDRESS. Return 0 if the memory 37673 is allocated but the data is not loaded. Return 1 if the hook has 37674 performed everything. 37675 37676 If the implementation uses reserved address space, free any 37677 reserved space beyond SIZE, regardless of the return value. If no 37678 PCH will be loaded, this hook may be called with SIZE zero, in 37679 which case all reserved address space should be freed. 37680 37681 Do not try to handle values of ADDRESS that could not have been 37682 returned by this executable; just return -1. Such values usually 37683 indicate an out-of-date PCH file (built by some other GCC 37684 executable), and such a PCH file won't work. 37685 37686 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 37687 This host hook returns the alignment required for allocating 37688 virtual memory. Usually this is the same as getpagesize, but on 37689 some hosts the alignment for reserving memory differs from the 37690 pagesize for committing memory. 37691 37692 37693 File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 37694 37695 18.2 Host Filesystem 37696 ==================== 37697 37698 GCC needs to know a number of things about the semantics of the host 37699 machine's filesystem. Filesystems with Unix and MS-DOS semantics are 37700 automatically detected. For other systems, you can define the 37701 following macros in `xm-MACHINE.h'. 37702 37703 `HAVE_DOS_BASED_FILE_SYSTEM' 37704 This macro is automatically defined by `system.h' if the host file 37705 system obeys the semantics defined by MS-DOS instead of Unix. DOS 37706 file systems are case insensitive, file specifications may begin 37707 with a drive letter, and both forward slash and backslash (`/' and 37708 `\') are directory separators. 37709 37710 `DIR_SEPARATOR' 37711 `DIR_SEPARATOR_2' 37712 If defined, these macros expand to character constants specifying 37713 separators for directory names within a file specification. 37714 `system.h' will automatically give them appropriate values on Unix 37715 and MS-DOS file systems. If your file system is neither of these, 37716 define one or both appropriately in `xm-MACHINE.h'. 37717 37718 However, operating systems like VMS, where constructing a pathname 37719 is more complicated than just stringing together directory names 37720 separated by a special character, should not define either of these 37721 macros. 37722 37723 `PATH_SEPARATOR' 37724 If defined, this macro should expand to a character constant 37725 specifying the separator for elements of search paths. The default 37726 value is a colon (`:'). DOS-based systems usually, but not 37727 always, use semicolon (`;'). 37728 37729 `VMS' 37730 Define this macro if the host system is VMS. 37731 37732 `HOST_OBJECT_SUFFIX' 37733 Define this macro to be a C string representing the suffix for 37734 object files on your host machine. If you do not define this 37735 macro, GCC will use `.o' as the suffix for object files. 37736 37737 `HOST_EXECUTABLE_SUFFIX' 37738 Define this macro to be a C string representing the suffix for 37739 executable files on your host machine. If you do not define this 37740 macro, GCC will use the null string as the suffix for executable 37741 files. 37742 37743 `HOST_BIT_BUCKET' 37744 A pathname defined by the host operating system, which can be 37745 opened as a file and written to, but all the information written 37746 is discarded. This is commonly known as a "bit bucket" or "null 37747 device". If you do not define this macro, GCC will use 37748 `/dev/null' as the bit bucket. If the host does not support a bit 37749 bucket, define this macro to an invalid filename. 37750 37751 `UPDATE_PATH_HOST_CANONICALIZE (PATH)' 37752 If defined, a C statement (sans semicolon) that performs 37753 host-dependent canonicalization when a path used in a compilation 37754 driver or preprocessor is canonicalized. PATH is a malloc-ed path 37755 to be canonicalized. If the C statement does canonicalize PATH 37756 into a different buffer, the old path should be freed and the new 37757 buffer should have been allocated with malloc. 37758 37759 `DUMPFILE_FORMAT' 37760 Define this macro to be a C string representing the format to use 37761 for constructing the index part of debugging dump file names. The 37762 resultant string must fit in fifteen bytes. The full filename 37763 will be the concatenation of: the prefix of the assembler file 37764 name, the string resulting from applying this format to an index 37765 number, and a string unique to each dump file kind, e.g. `rtl'. 37766 37767 If you do not define this macro, GCC will use `.%02d.'. You should 37768 define this macro if using the default will create an invalid file 37769 name. 37770 37771 `DELETE_IF_ORDINARY' 37772 Define this macro to be a C statement (sans semicolon) that 37773 performs host-dependent removal of ordinary temp files in the 37774 compilation driver. 37775 37776 If you do not define this macro, GCC will use the default version. 37777 You should define this macro if the default version does not 37778 reliably remove the temp file as, for example, on VMS which allows 37779 multiple versions of a file. 37780 37781 `HOST_LACKS_INODE_NUMBERS' 37782 Define this macro if the host filesystem does not report 37783 meaningful inode numbers in struct stat. 37784 37785 37786 File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 37787 37788 18.3 Host Misc 37789 ============== 37790 37791 `FATAL_EXIT_CODE' 37792 A C expression for the status code to be returned when the compiler 37793 exits after serious errors. The default is the system-provided 37794 macro `EXIT_FAILURE', or `1' if the system doesn't define that 37795 macro. Define this macro only if these defaults are incorrect. 37796 37797 `SUCCESS_EXIT_CODE' 37798 A C expression for the status code to be returned when the compiler 37799 exits without serious errors. (Warnings are not serious errors.) 37800 The default is the system-provided macro `EXIT_SUCCESS', or `0' if 37801 the system doesn't define that macro. Define this macro only if 37802 these defaults are incorrect. 37803 37804 `USE_C_ALLOCA' 37805 Define this macro if GCC should use the C implementation of 37806 `alloca' provided by `libiberty.a'. This only affects how some 37807 parts of the compiler itself allocate memory. It does not change 37808 code generation. 37809 37810 When GCC is built with a compiler other than itself, the C `alloca' 37811 is always used. This is because most other implementations have 37812 serious bugs. You should define this macro only on a system where 37813 no stack-based `alloca' can possibly work. For instance, if a 37814 system has a small limit on the size of the stack, GCC's builtin 37815 `alloca' will not work reliably. 37816 37817 `COLLECT2_HOST_INITIALIZATION' 37818 If defined, a C statement (sans semicolon) that performs 37819 host-dependent initialization when `collect2' is being initialized. 37820 37821 `GCC_DRIVER_HOST_INITIALIZATION' 37822 If defined, a C statement (sans semicolon) that performs 37823 host-dependent initialization when a compilation driver is being 37824 initialized. 37825 37826 `HOST_LONG_LONG_FORMAT' 37827 If defined, the string used to indicate an argument of type `long 37828 long' to functions like `printf'. The default value is `"ll"'. 37829 37830 `HOST_LONG_FORMAT' 37831 If defined, the string used to indicate an argument of type `long' 37832 to functions like `printf'. The default value is `"l"'. 37833 37834 `HOST_PTR_PRINTF' 37835 If defined, the string used to indicate an argument of type `void 37836 *' to functions like `printf'. The default value is `"%p"'. 37837 37838 In addition, if `configure' generates an incorrect definition of any 37839 of the macros in `auto-host.h', you can override that definition in a 37840 host configuration header. If you need to do this, first see if it is 37841 possible to fix `configure'. 37842 37843 37844 File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 37845 37846 19 Makefile Fragments 37847 ********************* 37848 37849 When you configure GCC using the `configure' script, it will construct 37850 the file `Makefile' from the template file `Makefile.in'. When it does 37851 this, it can incorporate makefile fragments from the `config' 37852 directory. These are used to set Makefile parameters that are not 37853 amenable to being calculated by autoconf. The list of fragments to 37854 incorporate is set by `config.gcc' (and occasionally `config.build' and 37855 `config.host'); *Note System Config::. 37856 37857 Fragments are named either `t-TARGET' or `x-HOST', depending on 37858 whether they are relevant to configuring GCC to produce code for a 37859 particular target, or to configuring GCC to run on a particular host. 37860 Here TARGET and HOST are mnemonics which usually have some relationship 37861 to the canonical system name, but no formal connection. 37862 37863 If these files do not exist, it means nothing needs to be added for a 37864 given target or host. Most targets need a few `t-TARGET' fragments, 37865 but needing `x-HOST' fragments is rare. 37866 37867 * Menu: 37868 37869 * Target Fragment:: Writing `t-TARGET' files. 37870 * Host Fragment:: Writing `x-HOST' files. 37871 37872 37873 File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 37874 37875 19.1 Target Makefile Fragments 37876 ============================== 37877 37878 Target makefile fragments can set these Makefile variables. 37879 37880 `LIBGCC2_CFLAGS' 37881 Compiler flags to use when compiling `libgcc2.c'. 37882 37883 `LIB2FUNCS_EXTRA' 37884 A list of source file names to be compiled or assembled and 37885 inserted into `libgcc.a'. 37886 37887 `CRTSTUFF_T_CFLAGS' 37888 Special flags used when compiling `crtstuff.c'. *Note 37889 Initialization::. 37890 37891 `CRTSTUFF_T_CFLAGS_S' 37892 Special flags used when compiling `crtstuff.c' for shared linking. 37893 Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'. 37894 *Note Initialization::. 37895 37896 `MULTILIB_OPTIONS' 37897 For some targets, invoking GCC in different ways produces objects 37898 that can not be linked together. For example, for some targets GCC 37899 produces both big and little endian code. For these targets, you 37900 must arrange for multiple versions of `libgcc.a' to be compiled, 37901 one for each set of incompatible options. When GCC invokes the 37902 linker, it arranges to link in the right version of `libgcc.a', 37903 based on the command line options used. 37904 37905 The `MULTILIB_OPTIONS' macro lists the set of options for which 37906 special versions of `libgcc.a' must be built. Write options that 37907 are mutually incompatible side by side, separated by a slash. 37908 Write options that may be used together separated by a space. The 37909 build procedure will build all combinations of compatible options. 37910 37911 For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020 37912 msoft-float', `Makefile' will build special versions of `libgcc.a' 37913 using the following sets of options: `-m68000', `-m68020', 37914 `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'. 37915 37916 `MULTILIB_DIRNAMES' 37917 If `MULTILIB_OPTIONS' is used, this variable specifies the 37918 directory names that should be used to hold the various libraries. 37919 Write one element in `MULTILIB_DIRNAMES' for each element in 37920 `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the 37921 default value will be `MULTILIB_OPTIONS', with all slashes treated 37922 as spaces. 37923 37924 `MULTILIB_DIRNAMES' describes the multilib directories using GCC 37925 conventions and is applied to directories that are part of the GCC 37926 installation. When multilib-enabled, the compiler will add a 37927 subdirectory of the form PREFIX/MULTILIB before each directory in 37928 the search path for libraries and crt files. 37929 37930 For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020 37931 msoft-float', then the default value of `MULTILIB_DIRNAMES' is 37932 `m68000 m68020 msoft-float'. You may specify a different value if 37933 you desire a different set of directory names. 37934 37935 `MULTILIB_MATCHES' 37936 Sometimes the same option may be written in two different ways. 37937 If an option is listed in `MULTILIB_OPTIONS', GCC needs to know 37938 about any synonyms. In that case, set `MULTILIB_MATCHES' to a 37939 list of items of the form `option=option' to describe all relevant 37940 synonyms. For example, `m68000=mc68000 m68020=mc68020'. 37941 37942 `MULTILIB_EXCEPTIONS' 37943 Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being 37944 specified, there are combinations that should not be built. In 37945 that case, set `MULTILIB_EXCEPTIONS' to be all of the switch 37946 exceptions in shell case syntax that should not be built. 37947 37948 For example the ARM processor cannot execute both hardware floating 37949 point instructions and the reduced size THUMB instructions at the 37950 same time, so there is no need to build libraries with both of 37951 these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to: 37952 *mthumb/*mhard-float* 37953 37954 `MULTILIB_REQUIRED' 37955 Sometimes when there are only a few combinations are required, it 37956 would be a big effort to come up with a `MULTILIB_EXCEPTIONS' list 37957 to cover all undesired ones. In such a case, just listing all the 37958 required combinations in `MULTILIB_REQUIRED' would be more 37959 straightforward. 37960 37961 The way to specify the entries in `MULTILIB_REQUIRED' is same with 37962 the way used for `MULTILIB_EXCEPTIONS', only this time what are 37963 required will be specified. Suppose there are multiple sets of 37964 `MULTILIB_OPTIONS' and only two combinations are required, one for 37965 ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU, 37966 the `MULTILIB_REQUIRED' can be set to: 37967 `MULTILIB_REQUIRED' = mthumb/march=armv7-m 37968 `MULTILIB_REQUIRED' += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16 37969 37970 The `MULTILIB_REQUIRED' can be used together with 37971 `MULTILIB_EXCEPTIONS'. The option combinations generated from 37972 `MULTILIB_OPTIONS' will be filtered by `MULTILIB_EXCEPTIONS' and 37973 then by `MULTILIB_REQUIRED'. 37974 37975 `MULTILIB_REUSE' 37976 Sometimes it is desirable to reuse one existing multilib for 37977 different sets of options. Such kind of reuse can minimize the 37978 number of multilib variants. And for some targets it is better to 37979 reuse an existing multilib than to fall back to default multilib 37980 when there is no corresponding multilib. This can be done by 37981 adding reuse rules to `MULTILIB_REUSE'. 37982 37983 A reuse rule is comprised of two parts connected by equality sign. 37984 The left part is option set used to build multilib and the right 37985 part is option set that will reuse this multilib. The order of 37986 options in the left part matters and should be same with those 37987 specified in `MULTILIB_REQUIRED' or aligned with order in 37988 `MULTILIB_OPTIONS'. There is no such limitation for options in 37989 right part as we don't build multilib from them. But the equality 37990 sign in both parts should be replaced with period. 37991 37992 The `MULTILIB_REUSE' is different from `MULTILIB_MATCHES' in that 37993 it sets up relations between two option sets rather than two 37994 options. Here is an example to demo how we reuse libraries built 37995 in Thumb mode for applications built in ARM mode: 37996 `MULTILIB_REUSE' = mthumb/march.armv7-r=marm/march.armv7-r 37997 37998 Before the advent of `MULTILIB_REUSE', GCC select multilib by 37999 comparing command line options with options used to build 38000 multilib. The `MULTILIB_REUSE' is complementary to that way. 38001 Only when the original comparison matches nothing it will work to 38002 see if it is OK to reuse some existing multilib. 38003 38004 `MULTILIB_EXTRA_OPTS' 38005 Sometimes it is desirable that when building multiple versions of 38006 `libgcc.a' certain options should always be passed on to the 38007 compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list 38008 of options to be used for all builds. If you set this, you should 38009 probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it. 38010 38011 `MULTILIB_OSDIRNAMES' 38012 If `MULTILIB_OPTIONS' is used, this variable specifies a list of 38013 subdirectory names, that are used to modify the search path 38014 depending on the chosen multilib. Unlike `MULTILIB_DIRNAMES', 38015 `MULTILIB_OSDIRNAMES' describes the multilib directories using 38016 operating systems conventions, and is applied to the directories 38017 such as `lib' or those in the `LIBRARY_PATH' environment variable. 38018 The format is either the same as of `MULTILIB_DIRNAMES', or a set 38019 of mappings. When it is the same as `MULTILIB_DIRNAMES', it 38020 describes the multilib directories using operating system 38021 conventions, rather than GCC conventions. When it is a set of 38022 mappings of the form GCCDIR=OSDIR, the left side gives the GCC 38023 convention and the right gives the equivalent OS defined location. 38024 If the OSDIR part begins with a `!', GCC will not search in the 38025 non-multilib directory and use exclusively the multilib directory. 38026 Otherwise, the compiler will examine the search path for libraries 38027 and crt files twice; the first time it will add MULTILIB to each 38028 directory in the search path, the second it will not. 38029 38030 For configurations that support both multilib and multiarch, 38031 `MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus 38032 subsuming `MULTIARCH_DIRNAME'. The multiarch name is appended to 38033 each directory name, separated by a colon (e.g. 38034 `../lib32:i386-linux-gnu'). 38035 38036 Each multiarch subdirectory will be searched before the 38037 corresponding OS multilib directory, for example 38038 `/lib/i386-linux-gnu' before `/lib/../lib32'. The multiarch name 38039 will also be used to modify the system header search path, as 38040 explained for `MULTIARCH_DIRNAME'. 38041 38042 `MULTIARCH_DIRNAME' 38043 This variable specifies the multiarch name for configurations that 38044 are multiarch-enabled but not multilibbed configurations. 38045 38046 The multiarch name is used to augment the search path for 38047 libraries, crt files and system header files with additional 38048 locations. The compiler will add a multiarch subdirectory of the 38049 form PREFIX/MULTIARCH before each directory in the library and crt 38050 search path. It will also add two directories 38051 `LOCAL_INCLUDE_DIR'/MULTIARCH and 38052 `NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search 38053 path, respectively before `LOCAL_INCLUDE_DIR' and 38054 `NATIVE_SYSTEM_HEADER_DIR'. 38055 38056 `MULTIARCH_DIRNAME' is not used for configurations that support 38057 both multilib and multiarch. In that case, multiarch names are 38058 encoded in `MULTILIB_OSDIRNAMES' instead. 38059 38060 More documentation about multiarch can be found at 38061 `http://wiki.debian.org/Multiarch'. 38062 38063 `SPECS' 38064 Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since 38065 it does not affect the build of target libraries, at least not the 38066 build of the default multilib. One possible work-around is to use 38067 `DRIVER_SELF_SPECS' to bring options from the `specs' file as if 38068 they had been passed in the compiler driver command line. 38069 However, you don't want to be adding these options after the 38070 toolchain is installed, so you can instead tweak the `specs' file 38071 that will be used during the toolchain build, while you still 38072 install the original, built-in `specs'. The trick is to set 38073 `SPECS' to some other filename (say `specs.install'), that will 38074 then be created out of the built-in specs, and introduce a 38075 `Makefile' rule to generate the `specs' file that's going to be 38076 used at build time out of your `specs.install'. 38077 38078 `T_CFLAGS' 38079 These are extra flags to pass to the C compiler. They are used 38080 both when building GCC, and when compiling things with the 38081 just-built GCC. This variable is deprecated and should not be 38082 used. 38083 38084 38085 File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 38086 38087 19.2 Host Makefile Fragments 38088 ============================ 38089 38090 The use of `x-HOST' fragments is discouraged. You should only use it 38091 for makefile dependencies. 38092 38093 38094 File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 38095 38096 20 `collect2' 38097 ************* 38098 38099 GCC uses a utility called `collect2' on nearly all systems to arrange 38100 to call various initialization functions at start time. 38101 38102 The program `collect2' works by linking the program once and looking 38103 through the linker output file for symbols with particular names 38104 indicating they are constructor functions. If it finds any, it creates 38105 a new temporary `.c' file containing a table of them, compiles it, and 38106 links the program a second time including that file. 38107 38108 The actual calls to the constructors are carried out by a subroutine 38109 called `__main', which is called (automatically) at the beginning of 38110 the body of `main' (provided `main' was compiled with GNU CC). Calling 38111 `__main' is necessary, even when compiling C code, to allow linking C 38112 and C++ object code together. (If you use `-nostdlib', you get an 38113 unresolved reference to `__main', since it's defined in the standard 38114 GCC library. Include `-lgcc' at the end of your compiler command line 38115 to resolve this reference.) 38116 38117 The program `collect2' is installed as `ld' in the directory where the 38118 passes of the compiler are installed. When `collect2' needs to find 38119 the _real_ `ld', it tries the following file names: 38120 38121 * a hard coded linker file name, if GCC was configured with the 38122 `--with-ld' option. 38123 38124 * `real-ld' in the directories listed in the compiler's search 38125 directories. 38126 38127 * `real-ld' in the directories listed in the environment variable 38128 `PATH'. 38129 38130 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 38131 if specified. 38132 38133 * `ld' in the compiler's search directories, except that `collect2' 38134 will not execute itself recursively. 38135 38136 * `ld' in `PATH'. 38137 38138 "The compiler's search directories" means all the directories where 38139 `gcc' searches for passes of the compiler. This includes directories 38140 that you specify with `-B'. 38141 38142 Cross-compilers search a little differently: 38143 38144 * `real-ld' in the compiler's search directories. 38145 38146 * `TARGET-real-ld' in `PATH'. 38147 38148 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 38149 if specified. 38150 38151 * `ld' in the compiler's search directories. 38152 38153 * `TARGET-ld' in `PATH'. 38154 38155 `collect2' explicitly avoids running `ld' using the file name under 38156 which `collect2' itself was invoked. In fact, it remembers up a list 38157 of such names--in case one copy of `collect2' finds another copy (or 38158 version) of `collect2' installed as `ld' in a second place in the 38159 search path. 38160 38161 `collect2' searches for the utilities `nm' and `strip' using the same 38162 algorithm as above for `ld'. 38163 38164 38165 File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 38166 38167 21 Standard Header File Directories 38168 *********************************** 38169 38170 `GCC_INCLUDE_DIR' means the same thing for native and cross. It is 38171 where GCC stores its private include files, and also where GCC stores 38172 the fixed include files. A cross compiled GCC runs `fixincludes' on 38173 the header files in `$(tooldir)/include'. (If the cross compilation 38174 header files need to be fixed, they must be installed before GCC is 38175 built. If the cross compilation header files are already suitable for 38176 GCC, nothing special need be done). 38177 38178 `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 38179 is where `g++' looks first for header files. The C++ library installs 38180 only target independent header files in that directory. 38181 38182 `LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 38183 install anything there. It is normally `/usr/local/include'. This is 38184 where local additions to a packaged system should place header files. 38185 38186 `CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 38187 install anything there. 38188 38189 `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 38190 the place for other packages to install header files that GCC will use. 38191 For a cross-compiler, this is the equivalent of `/usr/include'. When 38192 you build a cross-compiler, `fixincludes' processes any header files in 38193 this directory. 38194 38195 38196 File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 38197 38198 22 Memory Management and Type Information 38199 ***************************************** 38200 38201 GCC uses some fairly sophisticated memory management techniques, which 38202 involve determining information about GCC's data structures from GCC's 38203 source code and using this information to perform garbage collection and 38204 implement precompiled headers. 38205 38206 A full C++ parser would be too complicated for this task, so a limited 38207 subset of C++ is interpreted and special markers are used to determine 38208 what parts of the source to look at. All `struct', `union' and 38209 `template' structure declarations that define data structures that are 38210 allocated under control of the garbage collector must be marked. All 38211 global variables that hold pointers to garbage-collected memory must 38212 also be marked. Finally, all global variables that need to be saved 38213 and restored by a precompiled header must be marked. (The precompiled 38214 header mechanism can only save static variables if they're scalar. 38215 Complex data structures must be allocated in garbage-collected memory 38216 to be saved in a precompiled header.) 38217 38218 The full format of a marker is 38219 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 38220 but in most cases no options are needed. The outer double parentheses 38221 are still necessary, though: `GTY(())'. Markers can appear: 38222 38223 * In a structure definition, before the open brace; 38224 38225 * In a global variable declaration, after the keyword `static' or 38226 `extern'; and 38227 38228 * In a structure field definition, before the name of the field. 38229 38230 Here are some examples of marking simple data structures and globals. 38231 38232 struct GTY(()) TAG 38233 { 38234 FIELDS... 38235 }; 38236 38237 typedef struct GTY(()) TAG 38238 { 38239 FIELDS... 38240 } *TYPENAME; 38241 38242 static GTY(()) struct TAG *LIST; /* points to GC memory */ 38243 static GTY(()) int COUNTER; /* save counter in a PCH */ 38244 38245 The parser understands simple typedefs such as `typedef struct TAG 38246 *NAME;' and `typedef int NAME;'. These don't need to be marked. 38247 38248 Since `gengtype''s understanding of C++ is limited, there are several 38249 constructs and declarations that are not supported inside 38250 classes/structures marked for automatic GC code generation. The 38251 following C++ constructs produce a `gengtype' error on 38252 structures/classes marked for automatic GC code generation: 38253 38254 * Type definitions inside classes/structures are not supported. 38255 38256 * Enumerations inside classes/structures are not supported. 38257 38258 If you have a class or structure using any of the above constructs, 38259 you need to mark that class as `GTY ((user))' and provide your own 38260 marking routines (see section *note User GC:: for details). 38261 38262 It is always valid to include function definitions inside classes. 38263 Those are always ignored by `gengtype', as it only cares about data 38264 members. 38265 38266 * Menu: 38267 38268 * GTY Options:: What goes inside a `GTY(())'. 38269 * User GC:: Adding user-provided GC marking routines. 38270 * GGC Roots:: Making global variables GGC roots. 38271 * Files:: How the generated files work. 38272 * Invoking the garbage collector:: How to invoke the garbage collector. 38273 * Troubleshooting:: When something does not work as expected. 38274 38275 38276 File: gccint.info, Node: GTY Options, Next: User GC, Up: Type Information 38277 38278 22.1 The Inside of a `GTY(())' 38279 ============================== 38280 38281 Sometimes the C code is not enough to fully describe the type 38282 structure. Extra information can be provided with `GTY' options and 38283 additional markers. Some options take a parameter, which may be either 38284 a string or a type name, depending on the parameter. If an option 38285 takes no parameter, it is acceptable either to omit the parameter 38286 entirely, or to provide an empty string as a parameter. For example, 38287 `GTY ((skip))' and `GTY ((skip ("")))' are equivalent. 38288 38289 When the parameter is a string, often it is a fragment of C code. Four 38290 special escapes may be used in these strings, to refer to pieces of the 38291 data structure being marked: 38292 38293 `%h' 38294 The current structure. 38295 38296 `%1' 38297 The structure that immediately contains the current structure. 38298 38299 `%0' 38300 The outermost structure that contains the current structure. 38301 38302 `%a' 38303 A partial expression of the form `[i1][i2]...' that indexes the 38304 array item currently being marked. 38305 38306 For instance, suppose that you have a structure of the form 38307 struct A { 38308 ... 38309 }; 38310 struct B { 38311 struct A foo[12]; 38312 }; 38313 and `b' is a variable of type `struct B'. When marking `b.foo[11]', 38314 `%h' would expand to `b.foo[11]', `%0' and `%1' would both expand to 38315 `b', and `%a' would expand to `[11]'. 38316 38317 As in ordinary C, adjacent strings will be concatenated; this is 38318 helpful when you have a complicated expression. 38319 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 38320 " ? TYPE_NEXT_VARIANT (&%h.generic)" 38321 " : TREE_CHAIN (&%h.generic)"))) 38322 38323 The available options are: 38324 38325 `length ("EXPRESSION")' 38326 There are two places the type machinery will need to be explicitly 38327 told the length of an array of non-atomic objects. The first case 38328 is when a structure ends in a variable-length array, like this: 38329 struct GTY(()) rtvec_def { 38330 int num_elem; /* number of elements */ 38331 rtx GTY ((length ("%h.num_elem"))) elem[1]; 38332 }; 38333 38334 In this case, the `length' option is used to override the specified 38335 array length (which should usually be `1'). The parameter of the 38336 option is a fragment of C code that calculates the length. 38337 38338 The second case is when a structure or a global variable contains a 38339 pointer to an array, like this: 38340 struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter; 38341 In this case, `iter' has been allocated by writing something like 38342 x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse); 38343 and the `collapse' provides the length of the field. 38344 38345 This second use of `length' also works on global variables, like: static GTY((length("reg_known_value_size"))) rtx *reg_known_value; 38346 38347 Note that the `length' option is only meant for use with arrays of 38348 non-atomic objects, that is, objects that contain pointers 38349 pointing to other GTY-managed objects. For other GC-allocated 38350 arrays and strings you should use `atomic'. 38351 38352 `skip' 38353 If `skip' is applied to a field, the type machinery will ignore it. 38354 This is somewhat dangerous; the only safe use is in a union when 38355 one field really isn't ever used. 38356 38357 `desc ("EXPRESSION")' 38358 `tag ("CONSTANT")' 38359 `default' 38360 The type machinery needs to be told which field of a `union' is 38361 currently active. This is done by giving each field a constant 38362 `tag' value, and then specifying a discriminator using `desc'. 38363 The value of the expression given by `desc' is compared against 38364 each `tag' value, each of which should be different. If no `tag' 38365 is matched, the field marked with `default' is used if there is 38366 one, otherwise no field in the union will be marked. 38367 38368 In the `desc' option, the "current structure" is the union that it 38369 discriminates. Use `%1' to mean the structure containing it. 38370 There are no escapes available to the `tag' option, since it is a 38371 constant. 38372 38373 For example, 38374 struct GTY(()) tree_binding 38375 { 38376 struct tree_common common; 38377 union tree_binding_u { 38378 tree GTY ((tag ("0"))) scope; 38379 struct cp_binding_level * GTY ((tag ("1"))) level; 38380 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 38381 tree value; 38382 }; 38383 38384 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 38385 `struct tree_binding *' is presumed to be 0 or 1. If 1, the type 38386 mechanism will treat the field `level' as being present and if 0, 38387 will treat the field `scope' as being present. 38388 38389 `param_is (TYPE)' 38390 `use_param' 38391 Sometimes it's convenient to define some data structure to work on 38392 generic pointers (that is, `PTR') and then use it with a specific 38393 type. `param_is' specifies the real type pointed to, and 38394 `use_param' says where in the generic data structure that type 38395 should be put. 38396 38397 For instance, to have a `htab_t' that points to trees, one would 38398 write the definition of `htab_t' like this: 38399 typedef struct GTY(()) { 38400 ... 38401 void ** GTY ((use_param, ...)) entries; 38402 ... 38403 } htab_t; 38404 and then declare variables like this: 38405 static htab_t GTY ((param_is (union tree_node))) ict; 38406 38407 `paramN_is (TYPE)' 38408 `use_paramN' 38409 In more complicated cases, the data structure might need to work on 38410 several different types, which might not necessarily all be 38411 pointers. For this, `param1_is' through `param9_is' may be used to 38412 specify the real type of a field identified by `use_param1' through 38413 `use_param9'. 38414 38415 `use_params' 38416 When a structure contains another structure that is parameterized, 38417 there's no need to do anything special, the inner structure 38418 inherits the parameters of the outer one. When a structure 38419 contains a pointer to a parameterized structure, the type 38420 machinery won't automatically detect this (it could, it just 38421 doesn't yet), so it's necessary to tell it that the pointed-to 38422 structure should use the same parameters as the outer structure. 38423 This is done by marking the pointer with the `use_params' option. 38424 38425 `deletable' 38426 `deletable', when applied to a global variable, indicates that when 38427 garbage collection runs, there's no need to mark anything pointed 38428 to by this variable, it can just be set to `NULL' instead. This 38429 is used to keep a list of free structures around for re-use. 38430 38431 `if_marked ("EXPRESSION")' 38432 Suppose you want some kinds of object to be unique, and so you put 38433 them in a hash table. If garbage collection marks the hash table, 38434 these objects will never be freed, even if the last other 38435 reference to them goes away. GGC has special handling to deal 38436 with this: if you use the `if_marked' option on a global hash 38437 table, GGC will call the routine whose name is the parameter to 38438 the option on each hash table entry. If the routine returns 38439 nonzero, the hash table entry will be marked as usual. If the 38440 routine returns zero, the hash table entry will be deleted. 38441 38442 The routine `ggc_marked_p' can be used to determine if an element 38443 has been marked already; in fact, the usual case is to use 38444 `if_marked ("ggc_marked_p")'. 38445 38446 `mark_hook ("HOOK-ROUTINE-NAME")' 38447 If provided for a structure or union type, the given 38448 HOOK-ROUTINE-NAME (between double-quotes) is the name of a routine 38449 called when the garbage collector has just marked the data as 38450 reachable. This routine should not change the data, or call any ggc 38451 routine. Its only argument is a pointer to the just marked (const) 38452 structure or union. 38453 38454 `maybe_undef' 38455 When applied to a field, `maybe_undef' indicates that it's OK if 38456 the structure that this fields points to is never defined, so long 38457 as this field is always `NULL'. This is used to avoid requiring 38458 backends to define certain optional structures. It doesn't work 38459 with language frontends. 38460 38461 `nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 38462 The type machinery expects all pointers to point to the start of an 38463 object. Sometimes for abstraction purposes it's convenient to have 38464 a pointer which points inside an object. So long as it's possible 38465 to convert the original object to and from the pointer, such 38466 pointers can still be used. TYPE is the type of the original 38467 object, the TO EXPRESSION returns the pointer given the original 38468 object, and the FROM EXPRESSION returns the original object given 38469 the pointer. The pointer will be available using the `%h' escape. 38470 38471 `chain_next ("EXPRESSION")' 38472 `chain_prev ("EXPRESSION")' 38473 `chain_circular ("EXPRESSION")' 38474 It's helpful for the type machinery to know if objects are often 38475 chained together in long lists; this lets it generate code that 38476 uses less stack space by iterating along the list instead of 38477 recursing down it. `chain_next' is an expression for the next 38478 item in the list, `chain_prev' is an expression for the previous 38479 item. For singly linked lists, use only `chain_next'; for doubly 38480 linked lists, use both. The machinery requires that taking the 38481 next item of the previous item gives the original item. 38482 `chain_circular' is similar to `chain_next', but can be used for 38483 circular single linked lists. 38484 38485 `reorder ("FUNCTION NAME")' 38486 Some data structures depend on the relative ordering of pointers. 38487 If the precompiled header machinery needs to change that ordering, 38488 it will call the function referenced by the `reorder' option, 38489 before changing the pointers in the object that's pointed to by 38490 the field the option applies to. The function must take four 38491 arguments, with the signature 38492 `void *, void *, gt_pointer_operator, void *'. The first 38493 parameter is a pointer to the structure that contains the object 38494 being updated, or the object itself if there is no containing 38495 structure. The second parameter is a cookie that should be 38496 ignored. The third parameter is a routine that, given a pointer, 38497 will update it to its correct new value. The fourth parameter is 38498 a cookie that must be passed to the second parameter. 38499 38500 PCH cannot handle data structures that depend on the absolute 38501 values of pointers. `reorder' functions can be expensive. When 38502 possible, it is better to depend on properties of the data, like 38503 an ID number or the hash of a string instead. 38504 38505 `variable_size' 38506 The type machinery expects the types to be of constant size. When 38507 this is not true, for example, with structs that have array fields 38508 or unions, the type machinery cannot tell how many bytes need to 38509 be allocated at each allocation. The `variable_size' is used to 38510 mark such types. The type machinery then provides allocators that 38511 take a parameter indicating an exact size of object being 38512 allocated. Note that the size must be provided in bytes whereas 38513 the `length' option works with array lengths in number of elements. 38514 38515 For example, 38516 struct GTY((variable_size)) sorted_fields_type { 38517 int len; 38518 tree GTY((length ("%h.len"))) elts[1]; 38519 }; 38520 38521 Then the objects of `struct sorted_fields_type' are allocated in GC 38522 memory as follows: 38523 field_vec = ggc_alloc_sorted_fields_type (size); 38524 38525 If FIELD_VEC->ELTS stores N elements, then SIZE could be 38526 calculated as follows: 38527 size_t size = sizeof (struct sorted_fields_type) + n * sizeof (tree); 38528 38529 `atomic' 38530 The `atomic' option can only be used with pointers. It informs 38531 the GC machinery that the memory that the pointer points to does 38532 not contain any pointers, and hence it should be treated by the GC 38533 and PCH machinery as an "atomic" block of memory that does not 38534 need to be examined when scanning memory for pointers. In 38535 particular, the machinery will not scan that memory for pointers 38536 to mark them as reachable (when marking pointers for GC) or to 38537 relocate them (when writing a PCH file). 38538 38539 The `atomic' option differs from the `skip' option. `atomic' 38540 keeps the memory under Garbage Collection, but makes the GC ignore 38541 the contents of the memory. `skip' is more drastic in that it 38542 causes the pointer and the memory to be completely ignored by the 38543 Garbage Collector. So, memory marked as `atomic' is automatically 38544 freed when no longer reachable, while memory marked as `skip' is 38545 not. 38546 38547 The `atomic' option must be used with great care, because all 38548 sorts of problem can occur if used incorrectly, that is, if the 38549 memory the pointer points to does actually contain a pointer. 38550 38551 Here is an example of how to use it: 38552 struct GTY(()) my_struct { 38553 int number_of_elements; 38554 unsigned int * GTY ((atomic)) elements; 38555 }; 38556 In this case, `elements' is a pointer under GC, and the memory it 38557 points to needs to be allocated using the Garbage Collector, and 38558 will be freed automatically by the Garbage Collector when it is no 38559 longer referenced. But the memory that the pointer points to is 38560 an array of `unsigned int' elements, and the GC must not try to 38561 scan it to find pointers to mark or relocate, which is why it is 38562 marked with the `atomic' option. 38563 38564 Note that, currently, global variables can not be marked with 38565 `atomic'; only fields of a struct can. This is a known 38566 limitation. It would be useful to be able to mark global pointers 38567 with `atomic' to make the PCH machinery aware of them so that they 38568 are saved and restored correctly to PCH files. 38569 38570 `special ("NAME")' 38571 The `special' option is used to mark types that have to be dealt 38572 with by special case machinery. The parameter is the name of the 38573 special case. See `gengtype.c' for further details. Avoid adding 38574 new special cases unless there is no other alternative. 38575 38576 `user' 38577 The `user' option indicates that the code to mark structure fields 38578 is completely handled by user-provided routines. See section 38579 *note User GC:: for details on what functions need to be provided. 38580 38581 38582 File: gccint.info, Node: User GC, Next: GGC Roots, Prev: GTY Options, Up: Type Information 38583 38584 22.2 Support for user-provided GC marking routines 38585 ================================================== 38586 38587 The garbage collector supports types for which no automatic marking 38588 code is generated. For these types, the user is required to provide 38589 three functions: one to act as a marker for garbage collection, and two 38590 functions to act as marker and pointer walker for pre-compiled headers. 38591 38592 Given a structure `struct GTY((user)) my_struct', the following 38593 functions should be defined to mark `my_struct': 38594 38595 void gt_ggc_mx (my_struct *p) 38596 { 38597 /* This marks field 'fld'. */ 38598 gt_ggc_mx (p->fld); 38599 } 38600 38601 void gt_pch_nx (my_struct *p) 38602 { 38603 /* This marks field 'fld'. */ 38604 gt_pch_nx (tp->fld); 38605 } 38606 38607 void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie) 38608 { 38609 /* For every field 'fld', call the given pointer operator. */ 38610 op (&(tp->fld), cookie); 38611 } 38612 38613 In general, each marker `M' should call `M' for every pointer field in 38614 the structure. Fields that are not allocated in GC or are not pointers 38615 must be ignored. 38616 38617 For embedded lists (e.g., structures with a `next' or `prev' pointer), 38618 the marker must follow the chain and mark every element in it. 38619 38620 Note that the rules for the pointer walker `gt_pch_nx (my_struct *, 38621 gt_pointer_operator, void *)' are slightly different. In this case, 38622 the operation `op' must be applied to the _address_ of every pointer 38623 field. 38624 38625 22.2.1 User-provided marking routines for template types 38626 -------------------------------------------------------- 38627 38628 When a template type `TP' is marked with `GTY', all instances of that 38629 type are considered user-provided types. This means that the 38630 individual instances of `TP' do not need to be marked with `GTY'. The 38631 user needs to provide template functions to mark all the fields of the 38632 type. 38633 38634 The following code snippets represent all the functions that need to 38635 be provided. Note that type `TP' may reference to more than one type. 38636 In these snippets, there is only one type `T', but there could be more. 38637 38638 template<typename T> 38639 void gt_ggc_mx (TP<T> *tp) 38640 { 38641 extern void gt_ggc_mx (T&); 38642 38643 /* This marks field 'fld' of type 'T'. */ 38644 gt_ggc_mx (tp->fld); 38645 } 38646 38647 template<typename T> 38648 void gt_pch_nx (TP<T> *tp) 38649 { 38650 extern void gt_pch_nx (T&); 38651 38652 /* This marks field 'fld' of type 'T'. */ 38653 gt_pch_nx (tp->fld); 38654 } 38655 38656 template<typename T> 38657 void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie) 38658 { 38659 /* For every field 'fld' of 'tp' with type 'T *', call the given 38660 pointer operator. */ 38661 op (&(tp->fld), cookie); 38662 } 38663 38664 template<typename T> 38665 void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie) 38666 { 38667 extern void gt_pch_nx (T *, gt_pointer_operator, void *); 38668 38669 /* For every field 'fld' of 'tp' with type 'T', call the pointer 38670 walker for all the fields of T. */ 38671 gt_pch_nx (&(tp->fld), op, cookie); 38672 } 38673 38674 Support for user-defined types is currently limited. The following 38675 restrictions apply: 38676 38677 1. Type `TP' and all the argument types `T' must be marked with `GTY'. 38678 38679 2. Type `TP' can only have type names in its argument list. 38680 38681 3. The pointer walker functions are different for `TP<T>' and `TP<T 38682 *>'. In the case of `TP<T>', references to `T' must be handled by 38683 calling `gt_pch_nx' (which will, in turn, walk all the pointers 38684 inside fields of `T'). In the case of `TP<T *>', references to `T 38685 *' must be handled by calling the `op' function on the address of 38686 the pointer (see the code snippets above). 38687 38688 38689 File: gccint.info, Node: GGC Roots, Next: Files, Prev: User GC, Up: Type Information 38690 38691 22.3 Marking Roots for the Garbage Collector 38692 ============================================ 38693 38694 In addition to keeping track of types, the type machinery also locates 38695 the global variables ("roots") that the garbage collector starts at. 38696 Roots must be declared using one of the following syntaxes: 38697 38698 * `extern GTY(([OPTIONS])) TYPE NAME;' 38699 38700 * `static GTY(([OPTIONS])) TYPE NAME;' 38701 The syntax 38702 * `GTY(([OPTIONS])) TYPE NAME;' 38703 is _not_ accepted. There should be an `extern' declaration of such a 38704 variable in a header somewhere--mark that, not the definition. Or, if 38705 the variable is only used in one file, make it `static'. 38706 38707 38708 File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 38709 38710 22.4 Source Files Containing Type Information 38711 ============================================= 38712 38713 Whenever you add `GTY' markers to a source file that previously had 38714 none, or create a new source file containing `GTY' markers, there are 38715 three things you need to do: 38716 38717 1. You need to add the file to the list of source files the type 38718 machinery scans. There are four cases: 38719 38720 a. For a back-end file, this is usually done automatically; if 38721 not, you should add it to `target_gtfiles' in the appropriate 38722 port's entries in `config.gcc'. 38723 38724 b. For files shared by all front ends, add the filename to the 38725 `GTFILES' variable in `Makefile.in'. 38726 38727 c. For files that are part of one front end, add the filename to 38728 the `gtfiles' variable defined in the appropriate 38729 `config-lang.in'. Headers should appear before non-headers 38730 in this list. 38731 38732 d. For files that are part of some but not all front ends, add 38733 the filename to the `gtfiles' variable of _all_ the front ends 38734 that use it. 38735 38736 2. If the file was a header file, you'll need to check that it's 38737 included in the right place to be visible to the generated files. 38738 For a back-end header file, this should be done automatically. 38739 For a front-end header file, it needs to be included by the same 38740 file that includes `gtype-LANG.h'. For other header files, it 38741 needs to be included in `gtype-desc.c', which is a generated file, 38742 so add it to `ifiles' in `open_base_file' in `gengtype.c'. 38743 38744 For source files that aren't header files, the machinery will 38745 generate a header file that should be included in the source file 38746 you just changed. The file will be called `gt-PATH.h' where PATH 38747 is the pathname relative to the `gcc' directory with slashes 38748 replaced by -, so for example the header file to be included in 38749 `cp/parser.c' is called `gt-cp-parser.c'. The generated header 38750 file should be included after everything else in the source file. 38751 Don't forget to mention this file as a dependency in the 38752 `Makefile'! 38753 38754 38755 For language frontends, there is another file that needs to be included 38756 somewhere. It will be called `gtype-LANG.h', where LANG is the name of 38757 the subdirectory the language is contained in. 38758 38759 Plugins can add additional root tables. Run the `gengtype' utility in 38760 plugin mode as `gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 38761 with your plugin files PLUGIN*.C using `GTY' to generate the 38762 PLUGINOUT.H file. The GCC build tree is needed to be present in that 38763 mode. 38764 38765 38766 File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information 38767 38768 22.5 How to invoke the garbage collector 38769 ======================================== 38770 38771 The GCC garbage collector GGC is only invoked explicitly. In contrast 38772 with many other garbage collectors, it is not implicitly invoked by 38773 allocation routines when a lot of memory has been consumed. So the only 38774 way to have GGC reclaim storage is to call the `ggc_collect' function 38775 explicitly. This call is an expensive operation, as it may have to 38776 scan the entire heap. Beware that local variables (on the GCC call 38777 stack) are not followed by such an invocation (as many other garbage 38778 collectors do): you should reference all your data from static or 38779 external `GTY'-ed variables, and it is advised to call `ggc_collect' 38780 with a shallow call stack. The GGC is an exact mark and sweep garbage 38781 collector (so it does not scan the call stack for pointers). In 38782 practice GCC passes don't often call `ggc_collect' themselves, because 38783 it is called by the pass manager between passes. 38784 38785 At the time of the `ggc_collect' call all pointers in the GC-marked 38786 structures must be valid or `NULL'. In practice this means that there 38787 should not be uninitialized pointer fields in the structures even if 38788 your code never reads or writes those fields at a particular instance. 38789 One way to ensure this is to use cleared versions of allocators unless 38790 all the fields are initialized manually immediately after allocation. 38791 38792 38793 File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information 38794 38795 22.6 Troubleshooting the garbage collector 38796 ========================================== 38797 38798 With the current garbage collector implementation, most issues should 38799 show up as GCC compilation errors. Some of the most commonly 38800 encountered issues are described below. 38801 38802 * Gengtype does not produce allocators for a `GTY'-marked type. 38803 Gengtype checks if there is at least one possible path from GC 38804 roots to at least one instance of each type before outputting 38805 allocators. If there is no such path, the `GTY' markers will be 38806 ignored and no allocators will be output. Solve this by making 38807 sure that there exists at least one such path. If creating it is 38808 unfeasible or raises a "code smell", consider if you really must 38809 use GC for allocating such type. 38810 38811 * Link-time errors about undefined `gt_ggc_r_foo_bar' and 38812 similarly-named symbols. Check if your `foo_bar' source file has 38813 `#include "gt-foo_bar.h"' as its very last line. 38814 38815 38816 38817 File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top 38818 38819 23 Plugins 38820 ********** 38821 38822 GCC plugin is a loadable module that provides extra features to the 38823 compiler, which they can further pass around as a shareable module. 38824 38825 GCC plugins provide developers with a rich subset of the GCC API to 38826 allow them to extend GCC as they see fit. Whether it is writing an 38827 additional optimization pass, transforming code, or analyzing 38828 information, plugins can be quite useful. 38829 38830 * Menu: 38831 38832 * Plugins loading:: How can we load plugins. 38833 * Plugin API:: The APIs for plugins. 38834 * Plugins pass:: How a plugin interact with the pass manager. 38835 * Plugins GC:: How a plugin Interact with GCC Garbage Collector. 38836 * Plugins description:: Giving information about a plugin itself. 38837 * Plugins attr:: Registering custom attributes or pragmas. 38838 * Plugins recording:: Recording information about pass execution. 38839 * Plugins gate:: Controlling which passes are being run. 38840 * Plugins tracking:: Keeping track of available passes. 38841 * Plugins building:: How can we build a plugin. 38842 38843 38844 File: gccint.info, Node: Plugins loading, Next: Plugin API, Up: Plugins 38845 38846 23.1 Loading Plugins 38847 ==================== 38848 38849 Plugins are supported on platforms that support `-ldl -rdynamic'. They 38850 are loaded by the compiler using `dlopen' and invoked at pre-determined 38851 locations in the compilation process. 38852 38853 Plugins are loaded with 38854 38855 `-fplugin=/path/to/NAME.so' `-fplugin-arg-NAME-KEY1[=VALUE1]' 38856 38857 The plugin arguments are parsed by GCC and passed to respective 38858 plugins as key-value pairs. Multiple plugins can be invoked by 38859 specifying multiple `-fplugin' arguments. 38860 38861 A plugin can be simply given by its short name (no dots or slashes). 38862 When simply passing `-fplugin=NAME', the plugin is loaded from the 38863 `plugin' directory, so `-fplugin=NAME' is the same as `-fplugin=`gcc 38864 -print-file-name=plugin`/NAME.so', using backquote shell syntax to 38865 query the `plugin' directory. 38866 38867 38868 File: gccint.info, Node: Plugin API, Next: Plugins pass, Prev: Plugins loading, Up: Plugins 38869 38870 23.2 Plugin API 38871 =============== 38872 38873 Plugins are activated by the compiler at specific events as defined in 38874 `gcc-plugin.h'. For each event of interest, the plugin should call 38875 `register_callback' specifying the name of the event and address of the 38876 callback function that will handle that event. 38877 38878 The header `gcc-plugin.h' must be the first gcc header to be included. 38879 38880 23.2.1 Plugin license check 38881 --------------------------- 38882 38883 Every plugin should define the global symbol `plugin_is_GPL_compatible' 38884 to assert that it has been licensed under a GPL-compatible license. If 38885 this symbol does not exist, the compiler will emit a fatal error and 38886 exit with the error message: 38887 38888 fatal error: plugin NAME is not licensed under a GPL-compatible license 38889 NAME: undefined symbol: plugin_is_GPL_compatible 38890 compilation terminated 38891 38892 The declared type of the symbol should be int, to match a forward 38893 declaration in `gcc-plugin.h' that suppresses C++ mangling. It does 38894 not need to be in any allocated section, though. The compiler merely 38895 asserts that the symbol exists in the global scope. Something like 38896 this is enough: 38897 38898 int plugin_is_GPL_compatible; 38899 38900 23.2.2 Plugin initialization 38901 ---------------------------- 38902 38903 Every plugin should export a function called `plugin_init' that is 38904 called right after the plugin is loaded. This function is responsible 38905 for registering all the callbacks required by the plugin and do any 38906 other required initialization. 38907 38908 This function is called from `compile_file' right before invoking the 38909 parser. The arguments to `plugin_init' are: 38910 38911 * `plugin_info': Plugin invocation information. 38912 38913 * `version': GCC version. 38914 38915 The `plugin_info' struct is defined as follows: 38916 38917 struct plugin_name_args 38918 { 38919 char *base_name; /* Short name of the plugin 38920 (filename without .so suffix). */ 38921 const char *full_name; /* Path to the plugin as specified with 38922 -fplugin=. */ 38923 int argc; /* Number of arguments specified with 38924 -fplugin-arg-.... */ 38925 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 38926 const char *version; /* Version string provided by plugin. */ 38927 const char *help; /* Help string provided by plugin. */ 38928 } 38929 38930 If initialization fails, `plugin_init' must return a non-zero value. 38931 Otherwise, it should return 0. 38932 38933 The version of the GCC compiler loading the plugin is described by the 38934 following structure: 38935 38936 struct plugin_gcc_version 38937 { 38938 const char *basever; 38939 const char *datestamp; 38940 const char *devphase; 38941 const char *revision; 38942 const char *configuration_arguments; 38943 }; 38944 38945 The function `plugin_default_version_check' takes two pointers to such 38946 structure and compare them field by field. It can be used by the 38947 plugin's `plugin_init' function. 38948 38949 The version of GCC used to compile the plugin can be found in the 38950 symbol `gcc_version' defined in the header `plugin-version.h'. The 38951 recommended version check to perform looks like 38952 38953 #include "plugin-version.h" 38954 ... 38955 38956 int 38957 plugin_init (struct plugin_name_args *plugin_info, 38958 struct plugin_gcc_version *version) 38959 { 38960 if (!plugin_default_version_check (version, &gcc_version)) 38961 return 1; 38962 38963 } 38964 38965 but you can also check the individual fields if you want a less strict 38966 check. 38967 38968 23.2.3 Plugin callbacks 38969 ----------------------- 38970 38971 Callback functions have the following prototype: 38972 38973 /* The prototype for a plugin callback function. 38974 gcc_data - event-specific data provided by GCC 38975 user_data - plugin-specific data provided by the plug-in. */ 38976 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 38977 38978 Callbacks can be invoked at the following pre-determined events: 38979 38980 enum plugin_event 38981 { 38982 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 38983 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 38984 PLUGIN_FINISH_DECL, /* After finishing parsing a declaration. */ 38985 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 38986 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 38987 PLUGIN_FINISH, /* Called before GCC exits. */ 38988 PLUGIN_INFO, /* Information about the plugin. */ 38989 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 38990 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 38991 PLUGIN_GGC_END, /* Called at end of GGC. */ 38992 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 38993 PLUGIN_REGISTER_GGC_CACHES, /* Register an extra GGC cache table. */ 38994 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 38995 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 38996 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 38997 /* Called before first pass from all_passes. */ 38998 PLUGIN_ALL_PASSES_START, 38999 /* Called after last pass from all_passes. */ 39000 PLUGIN_ALL_PASSES_END, 39001 /* Called before first ipa pass. */ 39002 PLUGIN_ALL_IPA_PASSES_START, 39003 /* Called after last ipa pass. */ 39004 PLUGIN_ALL_IPA_PASSES_END, 39005 /* Allows to override pass gate decision for current_pass. */ 39006 PLUGIN_OVERRIDE_GATE, 39007 /* Called before executing a pass. */ 39008 PLUGIN_PASS_EXECUTION, 39009 /* Called before executing subpasses of a GIMPLE_PASS in 39010 execute_ipa_pass_list. */ 39011 PLUGIN_EARLY_GIMPLE_PASSES_START, 39012 /* Called after executing subpasses of a GIMPLE_PASS in 39013 execute_ipa_pass_list. */ 39014 PLUGIN_EARLY_GIMPLE_PASSES_END, 39015 /* Called when a pass is first instantiated. */ 39016 PLUGIN_NEW_PASS, 39017 39018 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 39019 array. */ 39020 }; 39021 39022 In addition, plugins can also look up the enumerator of a named event, 39023 and / or generate new events dynamically, by calling the function 39024 `get_named_event_id'. 39025 39026 To register a callback, the plugin calls `register_callback' with the 39027 arguments: 39028 39029 * `char *name': Plugin name. 39030 39031 * `int event': The event code. 39032 39033 * `plugin_callback_func callback': The function that handles `event'. 39034 39035 * `void *user_data': Pointer to plugin-specific data. 39036 39037 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, 39038 PLUGIN_REGISTER_GGC_ROOTS and PLUGIN_REGISTER_GGC_CACHES pseudo-events 39039 the `callback' should be null, and the `user_data' is specific. 39040 39041 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as 39042 data from GCC), plugins may register their own pragmas using functions 39043 like `c_register_pragma' or `c_register_pragma_with_expansion'. 39044 39045 39046 File: gccint.info, Node: Plugins pass, Next: Plugins GC, Prev: Plugin API, Up: Plugins 39047 39048 23.3 Interacting with the pass manager 39049 ====================================== 39050 39051 There needs to be a way to add/reorder/remove passes dynamically. This 39052 is useful for both analysis plugins (plugging in after a certain pass 39053 such as CFG or an IPA pass) and optimization plugins. 39054 39055 Basic support for inserting new passes or replacing existing passes is 39056 provided. A plugin registers a new pass with GCC by calling 39057 `register_callback' with the `PLUGIN_PASS_MANAGER_SETUP' event and a 39058 pointer to a `struct register_pass_info' object defined as follows 39059 39060 enum pass_positioning_ops 39061 { 39062 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 39063 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 39064 PASS_POS_REPLACE // Replace the reference pass. 39065 }; 39066 39067 struct register_pass_info 39068 { 39069 struct opt_pass *pass; /* New pass provided by the plugin. */ 39070 const char *reference_pass_name; /* Name of the reference pass for hooking 39071 up the new pass. */ 39072 int ref_pass_instance_number; /* Insert the pass at the specified 39073 instance number of the reference pass. */ 39074 /* Do it for every instance if it is 0. */ 39075 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 39076 }; 39077 39078 39079 /* Sample plugin code that registers a new pass. */ 39080 int 39081 plugin_init (struct plugin_name_args *plugin_info, 39082 struct plugin_gcc_version *version) 39083 { 39084 struct register_pass_info pass_info; 39085 39086 ... 39087 39088 /* Code to fill in the pass_info object with new pass information. */ 39089 39090 ... 39091 39092 /* Register the new pass. */ 39093 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 39094 39095 ... 39096 } 39097 39098 39099 File: gccint.info, Node: Plugins GC, Next: Plugins description, Prev: Plugins pass, Up: Plugins 39100 39101 23.4 Interacting with the GCC Garbage Collector 39102 =============================================== 39103 39104 Some plugins may want to be informed when GGC (the GCC Garbage 39105 Collector) is running. They can register callbacks for the 39106 `PLUGIN_GGC_START' and `PLUGIN_GGC_END' events (for which the callback 39107 is called with a null `gcc_data') to be notified of the start or end of 39108 the GCC garbage collection. 39109 39110 Some plugins may need to have GGC mark additional data. This can be 39111 done by registering a callback (called with a null `gcc_data') for the 39112 `PLUGIN_GGC_MARKING' event. Such callbacks can call the `ggc_set_mark' 39113 routine, preferably through the `ggc_mark' macro (and conversely, these 39114 routines should usually not be used in plugins outside of the 39115 `PLUGIN_GGC_MARKING' event). 39116 39117 Some plugins may need to add extra GGC root tables, e.g. to handle 39118 their own `GTY'-ed data. This can be done with the 39119 `PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 39120 extra root table (of type `struct ggc_root_tab*') as `user_data'. 39121 Plugins that want to use the `if_marked' hash table option can add the 39122 extra GGC cache tables generated by `gengtype' using the 39123 `PLUGIN_REGISTER_GGC_CACHES' pseudo-event with a null callback and the 39124 extra cache table (of type `struct ggc_cache_tab*') as `user_data'. 39125 Running the `gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 39126 generates these extra root tables. 39127 39128 You should understand the details of memory management inside GCC 39129 before using `PLUGIN_GGC_MARKING', `PLUGIN_REGISTER_GGC_ROOTS' or 39130 `PLUGIN_REGISTER_GGC_CACHES'. 39131 39132 39133 File: gccint.info, Node: Plugins description, Next: Plugins attr, Prev: Plugins GC, Up: Plugins 39134 39135 23.5 Giving information about a plugin 39136 ====================================== 39137 39138 A plugin should give some information to the user about itself. This 39139 uses the following structure: 39140 39141 struct plugin_info 39142 { 39143 const char *version; 39144 const char *help; 39145 }; 39146 39147 Such a structure is passed as the `user_data' by the plugin's init 39148 routine using `register_callback' with the `PLUGIN_INFO' pseudo-event 39149 and a null callback. 39150 39151 39152 File: gccint.info, Node: Plugins attr, Next: Plugins recording, Prev: Plugins description, Up: Plugins 39153 39154 23.6 Registering custom attributes or pragmas 39155 ============================================= 39156 39157 For analysis (or other) purposes it is useful to be able to add custom 39158 attributes or pragmas. 39159 39160 The `PLUGIN_ATTRIBUTES' callback is called during attribute 39161 registration. Use the `register_attribute' function to register custom 39162 attributes. 39163 39164 /* Attribute handler callback */ 39165 static tree 39166 handle_user_attribute (tree *node, tree name, tree args, 39167 int flags, bool *no_add_attrs) 39168 { 39169 return NULL_TREE; 39170 } 39171 39172 /* Attribute definition */ 39173 static struct attribute_spec user_attr = 39174 { "user", 1, 1, false, false, false, handle_user_attribute, false }; 39175 39176 /* Plugin callback called during attribute registration. 39177 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 39178 */ 39179 static void 39180 register_attributes (void *event_data, void *data) 39181 { 39182 warning (0, G_("Callback to register attributes")); 39183 register_attribute (&user_attr); 39184 } 39185 39186 The `PLUGIN_PRAGMAS' callback is called during pragmas registration. 39187 Use the `c_register_pragma' or `c_register_pragma_with_expansion' 39188 functions to register custom pragmas. 39189 39190 /* Plugin callback called during pragmas registration. Registered with 39191 register_callback (plugin_name, PLUGIN_PRAGMAS, 39192 register_my_pragma, NULL); 39193 */ 39194 static void 39195 register_my_pragma (void *event_data, void *data) 39196 { 39197 warning (0, G_("Callback to register pragmas")); 39198 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 39199 } 39200 39201 It is suggested to pass `"GCCPLUGIN"' (or a short name identifying 39202 your plugin) as the "space" argument of your pragma. 39203 39204 39205 File: gccint.info, Node: Plugins recording, Next: Plugins gate, Prev: Plugins attr, Up: Plugins 39206 39207 23.7 Recording information about pass execution 39208 =============================================== 39209 39210 The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 39211 (the same as current_pass) as `gcc_data' to the callback. You can also 39212 inspect cfun to find out about which function this pass is executed for. 39213 Note that this event will only be invoked if the gate check (if 39214 applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 39215 other hooks, like `PLUGIN_ALL_PASSES_START', `PLUGIN_ALL_PASSES_END', 39216 `PLUGIN_ALL_IPA_PASSES_START', `PLUGIN_ALL_IPA_PASSES_END', 39217 `PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 39218 `PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 39219 plugin(s) in order to get context for the pass execution. 39220 39221 39222 File: gccint.info, Node: Plugins gate, Next: Plugins tracking, Prev: Plugins recording, Up: Plugins 39223 39224 23.8 Controlling which passes are being run 39225 =========================================== 39226 39227 After the original gate function for a pass is called, its result - the 39228 gate status - is stored as an integer. Then the event 39229 `PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 39230 the `gcc_data' parameter to the callback function. A nonzero value of 39231 the gate status means that the pass is to be executed. You can both 39232 read and write the gate status via the passed pointer. 39233 39234 39235 File: gccint.info, Node: Plugins tracking, Next: Plugins building, Prev: Plugins gate, Up: Plugins 39236 39237 23.9 Keeping track of available passes 39238 ====================================== 39239 39240 When your plugin is loaded, you can inspect the various pass lists to 39241 determine what passes are available. However, other plugins might add 39242 new passes. Also, future changes to GCC might cause generic passes to 39243 be added after plugin loading. When a pass is first added to one of 39244 the pass lists, the event `PLUGIN_NEW_PASS' is invoked, with the 39245 callback parameter `gcc_data' pointing to the new pass. 39246 39247 39248 File: gccint.info, Node: Plugins building, Prev: Plugins tracking, Up: Plugins 39249 39250 23.10 Building GCC plugins 39251 ========================== 39252 39253 If plugins are enabled, GCC installs the headers needed to build a 39254 plugin (somewhere in the installation tree, e.g. under `/usr/local'). 39255 In particular a `plugin/include' directory is installed, containing all 39256 the header files needed to build plugins. 39257 39258 On most systems, you can query this `plugin' directory by invoking 39259 `gcc -print-file-name=plugin' (replace if needed `gcc' with the 39260 appropriate program path). 39261 39262 Inside plugins, this `plugin' directory name can be queried by calling 39263 `default_plugin_dir_name ()'. 39264 39265 Plugins may know, when they are compiled, the GCC version for which 39266 `plugin-version.h' is provided. The constant macros 39267 `GCCPLUGIN_VERSION_MAJOR', `GCCPLUGIN_VERSION_MINOR', 39268 `GCCPLUGIN_VERSION_PATCHLEVEL', `GCCPLUGIN_VERSION' are integer 39269 numbers, so a plugin could ensure it is built for GCC 4.7 with 39270 #if GCCPLUGIN_VERSION != 4007 39271 #error this GCC plugin is for GCC 4.7 39272 #endif 39273 39274 The following GNU Makefile excerpt shows how to build a simple plugin: 39275 39276 GCC=gcc 39277 PLUGIN_SOURCE_FILES= plugin1.c plugin2.c 39278 PLUGIN_OBJECT_FILES= $(patsubst %.c,%.o,$(PLUGIN_SOURCE_FILES)) 39279 GCCPLUGINS_DIR:= $(shell $(GCC) -print-file-name=plugin) 39280 CFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -O2 39281 39282 plugin.so: $(PLUGIN_OBJECT_FILES) 39283 $(GCC) -shared $^ -o $@ 39284 39285 A single source file plugin may be built with `gcc -I`gcc 39286 -print-file-name=plugin`/include -fPIC -shared -O2 plugin.c -o 39287 plugin.so', using backquote shell syntax to query the `plugin' 39288 directory. 39289 39290 When a plugin needs to use `gengtype', be sure that both `gengtype' 39291 and `gtype.state' have the same version as the GCC for which the plugin 39292 is built. 39293 39294 39295 File: gccint.info, Node: LTO, Next: Funding, Prev: Plugins, Up: Top 39296 39297 24 Link Time Optimization 39298 ************************* 39299 39300 Link Time Optimization (LTO) gives GCC the capability of dumping its 39301 internal representation (GIMPLE) to disk, so that all the different 39302 compilation units that make up a single executable can be optimized as 39303 a single module. This expands the scope of inter-procedural 39304 optimizations to encompass the whole program (or, rather, everything 39305 that is visible at link time). 39306 39307 * Menu: 39308 39309 * LTO Overview:: Overview of LTO. 39310 * LTO object file layout:: LTO file sections in ELF. 39311 * IPA:: Using summary information in IPA passes. 39312 * WHOPR:: Whole program assumptions, 39313 linker plugin and symbol visibilities. 39314 * Internal flags:: Internal flags controlling `lto1'. 39315 39316 39317 File: gccint.info, Node: LTO Overview, Next: LTO object file layout, Up: LTO 39318 39319 24.1 Design Overview 39320 ==================== 39321 39322 Link time optimization is implemented as a GCC front end for a bytecode 39323 representation of GIMPLE that is emitted in special sections of `.o' 39324 files. Currently, LTO support is enabled in most ELF-based systems, as 39325 well as darwin, cygwin and mingw systems. 39326 39327 Since GIMPLE bytecode is saved alongside final object code, object 39328 files generated with LTO support are larger than regular object files. 39329 This "fat" object format makes it easy to integrate LTO into existing 39330 build systems, as one can, for instance, produce archives of the files. 39331 Additionally, one might be able to ship one set of fat objects which 39332 could be used both for development and the production of optimized 39333 builds. A, perhaps surprising, side effect of this feature is that any 39334 mistake in the toolchain that leads to LTO information not being used 39335 (e.g. an older `libtool' calling `ld' directly). This is both an 39336 advantage, as the system is more robust, and a disadvantage, as the 39337 user is not informed that the optimization has been disabled. 39338 39339 The current implementation only produces "fat" objects, effectively 39340 doubling compilation time and increasing file sizes up to 5x the 39341 original size. This hides the problem that some tools, such as `ar' 39342 and `nm', need to understand symbol tables of LTO sections. These 39343 tools were extended to use the plugin infrastructure, and with these 39344 problems solved, GCC will also support "slim" objects consisting of the 39345 intermediate code alone. 39346 39347 At the highest level, LTO splits the compiler in two. The first half 39348 (the "writer") produces a streaming representation of all the internal 39349 data structures needed to optimize and generate code. This includes 39350 declarations, types, the callgraph and the GIMPLE representation of 39351 function bodies. 39352 39353 When `-flto' is given during compilation of a source file, the pass 39354 manager executes all the passes in `all_lto_gen_passes'. Currently, 39355 this phase is composed of two IPA passes: 39356 39357 * `pass_ipa_lto_gimple_out' This pass executes the function 39358 `lto_output' in `lto-streamer-out.c', which traverses the call 39359 graph encoding every reachable declaration, type and function. 39360 This generates a memory representation of all the file sections 39361 described below. 39362 39363 * `pass_ipa_lto_finish_out' This pass executes the function 39364 `produce_asm_for_decls' in `lto-streamer-out.c', which takes the 39365 memory image built in the previous pass and encodes it in the 39366 corresponding ELF file sections. 39367 39368 The second half of LTO support is the "reader". This is implemented 39369 as the GCC front end `lto1' in `lto/lto.c'. When `collect2' detects a 39370 link set of `.o'/`.a' files with LTO information and the `-flto' is 39371 enabled, it invokes `lto1' which reads the set of files and aggregates 39372 them into a single translation unit for optimization. The main entry 39373 point for the reader is `lto/lto.c':`lto_main'. 39374 39375 24.1.1 LTO modes of operation 39376 ----------------------------- 39377 39378 One of the main goals of the GCC link-time infrastructure was to allow 39379 effective compilation of large programs. For this reason GCC 39380 implements two link-time compilation modes. 39381 39382 1. _LTO mode_, in which the whole program is read into the compiler 39383 at link-time and optimized in a similar way as if it were a single 39384 source-level compilation unit. 39385 39386 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs 39387 and/or a distributed compilation environment to quickly link large 39388 applications. WHOPR stands for WHOle Program optimizeR (not to be 39389 confused with the semantics of `-fwhole-program'). It partitions 39390 the aggregated callgraph from many different `.o' files and 39391 distributes the compilation of the sub-graphs to different CPUs. 39392 39393 Note that distributed compilation is not implemented yet, but since 39394 the parallelism is facilitated via generating a `Makefile', it 39395 would be easy to implement. 39396 39397 WHOPR splits LTO into three main stages: 39398 1. Local generation (LGEN) This stage executes in parallel. Every 39399 file in the program is compiled into the intermediate language and 39400 packaged together with the local call-graph and summary 39401 information. This stage is the same for both the LTO and WHOPR 39402 compilation mode. 39403 39404 2. Whole Program Analysis (WPA) WPA is performed sequentially. The 39405 global call-graph is generated, and a global analysis procedure 39406 makes transformation decisions. The global call-graph is 39407 partitioned to facilitate parallel optimization during phase 3. 39408 The results of the WPA stage are stored into new object files 39409 which contain the partitions of program expressed in the 39410 intermediate language and the optimization decisions. 39411 39412 3. Local transformations (LTRANS) This stage executes in parallel. 39413 All the decisions made during phase 2 are implemented locally in 39414 each partitioned object file, and the final object code is 39415 generated. Optimizations which cannot be decided efficiently 39416 during the phase 2 may be performed on the local call-graph 39417 partitions. 39418 39419 WHOPR can be seen as an extension of the usual LTO mode of 39420 compilation. In LTO, WPA and LTRANS are executed within a single 39421 execution of the compiler, after the whole program has been read into 39422 memory. 39423 39424 When compiling in WHOPR mode, the callgraph is partitioned during the 39425 WPA stage. The whole program is split into a given number of 39426 partitions of roughly the same size. The compiler tries to minimize 39427 the number of references which cross partition boundaries. The main 39428 advantage of WHOPR is to allow the parallel execution of LTRANS stages, 39429 which are the most time-consuming part of the compilation process. 39430 Additionally, it avoids the need to load the whole program into memory. 39431 39432 39433 File: gccint.info, Node: LTO object file layout, Next: IPA, Prev: LTO Overview, Up: LTO 39434 39435 24.2 LTO file sections 39436 ====================== 39437 39438 LTO information is stored in several ELF sections inside object files. 39439 Data structures and enum codes for sections are defined in 39440 `lto-streamer.h'. 39441 39442 These sections are emitted from `lto-streamer-out.c' and mapped in all 39443 at once from `lto/lto.c':`lto_file_read'. The individual functions 39444 dealing with the reading/writing of each section are described below. 39445 39446 * Command line options (`.gnu.lto_.opts') 39447 39448 This section contains the command line options used to generate the 39449 object files. This is used at link time to determine the 39450 optimization level and other settings when they are not explicitly 39451 specified at the linker command line. 39452 39453 Currently, GCC does not support combining LTO object files compiled 39454 with different set of the command line options into a single 39455 binary. At link time, the options given on the command line and 39456 the options saved on all the files in a link-time set are applied 39457 globally. No attempt is made at validating the combination of 39458 flags (other than the usual validation done by option processing). 39459 This is implemented in `lto/lto.c':`lto_read_all_file_options'. 39460 39461 * Symbol table (`.gnu.lto_.symtab') 39462 39463 This table replaces the ELF symbol table for functions and 39464 variables represented in the LTO IL. Symbols used and exported by 39465 the optimized assembly code of "fat" objects might not match the 39466 ones used and exported by the intermediate code. This table is 39467 necessary because the intermediate code is less optimized and thus 39468 requires a separate symbol table. 39469 39470 Additionally, the binary code in the "fat" object will lack a call 39471 to a function, since the call was optimized out at compilation time 39472 after the intermediate language was streamed out. In some special 39473 cases, the same optimization may not happen during link-time 39474 optimization. This would lead to an undefined symbol if only one 39475 symbol table was used. 39476 39477 The symbol table is emitted in 39478 `lto-streamer-out.c':`produce_symtab'. 39479 39480 * Global declarations and types (`.gnu.lto_.decls') 39481 39482 This section contains an intermediate language dump of all 39483 declarations and types required to represent the callgraph, static 39484 variables and top-level debug info. 39485 39486 The contents of this section are emitted in 39487 `lto-streamer-out.c':`produce_asm_for_decls'. Types and symbols 39488 are emitted in a topological order that preserves the sharing of 39489 pointers when the file is read back in 39490 (`lto.c':`read_cgraph_and_symbols'). 39491 39492 * The callgraph (`.gnu.lto_.cgraph') 39493 39494 This section contains the basic data structure used by the GCC 39495 inter-procedural optimization infrastructure. This section stores 39496 an annotated multi-graph which represents the functions and call 39497 sites as well as the variables, aliases and top-level `asm' 39498 statements. 39499 39500 This section is emitted in `lto-streamer-out.c':`output_cgraph' 39501 and read in `lto-cgraph.c':`input_cgraph'. 39502 39503 * IPA references (`.gnu.lto_.refs') 39504 39505 This section contains references between function and static 39506 variables. It is emitted by `lto-cgraph.c':`output_refs' and read 39507 by `lto-cgraph.c':`input_refs'. 39508 39509 * Function bodies (`.gnu.lto_.function_body.<name>') 39510 39511 This section contains function bodies in the intermediate language 39512 representation. Every function body is in a separate section to 39513 allow copying of the section independently to different object 39514 files or reading the function on demand. 39515 39516 Functions are emitted in `lto-streamer-out.c':`output_function' 39517 and read in `lto-streamer-in.c':`input_function'. 39518 39519 * Static variable initializers (`.gnu.lto_.vars') 39520 39521 This section contains all the symbols in the global variable pool. 39522 It is emitted by `lto-cgraph.c':`output_varpool' and read in 39523 `lto-cgraph.c':`input_cgraph'. 39524 39525 * Summaries and optimization summaries used by IPA passes 39526 (`.gnu.lto_.<xxx>', where `<xxx>' is one of `jmpfuncs', 39527 `pureconst' or `reference') 39528 39529 These sections are used by IPA passes that need to emit summary 39530 information during LTO generation to be read and aggregated at 39531 link time. Each pass is responsible for implementing two pass 39532 manager hooks: one for writing the summary and another for reading 39533 it in. The format of these sections is entirely up to each 39534 individual pass. The only requirement is that the writer and 39535 reader hooks agree on the format. 39536 39537 39538 File: gccint.info, Node: IPA, Next: WHOPR, Prev: LTO object file layout, Up: LTO 39539 39540 24.3 Using summary information in IPA passes 39541 ============================================ 39542 39543 Programs are represented internally as a _callgraph_ (a multi-graph 39544 where nodes are functions and edges are call sites) and a _varpool_ (a 39545 list of static and external variables in the program). 39546 39547 The inter-procedural optimization is organized as a sequence of 39548 individual passes, which operate on the callgraph and the varpool. To 39549 make the implementation of WHOPR possible, every inter-procedural 39550 optimization pass is split into several stages that are executed at 39551 different times during WHOPR compilation: 39552 39553 * LGEN time 39554 1. _Generate summary_ (`generate_summary' in `struct 39555 ipa_opt_pass_d'). This stage analyzes every function body 39556 and variable initializer is examined and stores relevant 39557 information into a pass-specific data structure. 39558 39559 2. _Write summary_ (`write_summary' in `struct ipa_opt_pass_d'). 39560 This stage writes all the pass-specific information generated 39561 by `generate_summary'. Summaries go into their own 39562 `LTO_section_*' sections that have to be declared in 39563 `lto-streamer.h':`enum lto_section_type'. A new section is 39564 created by calling `create_output_block' and data can be 39565 written using the `lto_output_*' routines. 39566 39567 * WPA time 39568 1. _Read summary_ (`read_summary' in `struct ipa_opt_pass_d'). 39569 This stage reads all the pass-specific information in exactly 39570 the same order that it was written by `write_summary'. 39571 39572 2. _Execute_ (`execute' in `struct opt_pass'). This performs 39573 inter-procedural propagation. This must be done without 39574 actual access to the individual function bodies or variable 39575 initializers. Typically, this results in a transitive 39576 closure operation over the summary information of all the 39577 nodes in the callgraph. 39578 39579 3. _Write optimization summary_ (`write_optimization_summary' in 39580 `struct ipa_opt_pass_d'). This writes the result of the 39581 inter-procedural propagation into the object file. This can 39582 use the same data structures and helper routines used in 39583 `write_summary'. 39584 39585 * LTRANS time 39586 1. _Read optimization summary_ (`read_optimization_summary' in 39587 `struct ipa_opt_pass_d'). The counterpart to 39588 `write_optimization_summary'. This reads the interprocedural 39589 optimization decisions in exactly the same format emitted by 39590 `write_optimization_summary'. 39591 39592 2. _Transform_ (`function_transform' and `variable_transform' in 39593 `struct ipa_opt_pass_d'). The actual function bodies and 39594 variable initializers are updated based on the information 39595 passed down from the _Execute_ stage. 39596 39597 The implementation of the inter-procedural passes are shared between 39598 LTO, WHOPR and classic non-LTO compilation. 39599 39600 * During the traditional file-by-file mode every pass executes its 39601 own _Generate summary_, _Execute_, and _Transform_ stages within 39602 the single execution context of the compiler. 39603 39604 * In LTO compilation mode, every pass uses _Generate summary_ and 39605 _Write summary_ stages at compilation time, while the _Read 39606 summary_, _Execute_, and _Transform_ stages are executed at link 39607 time. 39608 39609 * In WHOPR mode all stages are used. 39610 39611 To simplify development, the GCC pass manager differentiates between 39612 normal inter-procedural passes and small inter-procedural passes. A 39613 _small inter-procedural pass_ (`SIMPLE_IPA_PASS') is a pass that does 39614 everything at once and thus it can not be executed during WPA in WHOPR 39615 mode. It defines only the _Execute_ stage and during this stage it 39616 accesses and modifies the function bodies. Such passes are useful for 39617 optimization at LGEN or LTRANS time and are used, for example, to 39618 implement early optimization before writing object files. The simple 39619 inter-procedural passes can also be used for easier prototyping and 39620 development of a new inter-procedural pass. 39621 39622 24.3.1 Virtual clones 39623 --------------------- 39624 39625 One of the main challenges of introducing the WHOPR compilation mode 39626 was addressing the interactions between optimization passes. In LTO 39627 compilation mode, the passes are executed in a sequence, each of which 39628 consists of analysis (or _Generate summary_), propagation (or 39629 _Execute_) and _Transform_ stages. Once the work of one pass is 39630 finished, the next pass sees the updated program representation and can 39631 execute. This makes the individual passes dependent on each other. 39632 39633 In WHOPR mode all passes first execute their _Generate summary_ stage. 39634 Then summary writing marks the end of the LGEN stage. At WPA time, the 39635 summaries are read back into memory and all passes run the _Execute_ 39636 stage. Optimization summaries are streamed and sent to LTRANS, where 39637 all the passes execute the _Transform_ stage. 39638 39639 Most optimization passes split naturally into analysis, propagation 39640 and transformation stages. But some do not. The main problem arises 39641 when one pass performs changes and the following pass gets confused by 39642 seeing different callgraphs between the _Transform_ stage and the 39643 _Generate summary_ or _Execute_ stage. This means that the passes are 39644 required to communicate their decisions with each other. 39645 39646 To facilitate this communication, the GCC callgraph infrastructure 39647 implements _virtual clones_, a method of representing the changes 39648 performed by the optimization passes in the callgraph without needing 39649 to update function bodies. 39650 39651 A _virtual clone_ in the callgraph is a function that has no 39652 associated body, just a description of how to create its body based on 39653 a different function (which itself may be a virtual clone). 39654 39655 The description of function modifications includes adjustments to the 39656 function's signature (which allows, for example, removing or adding 39657 function arguments), substitutions to perform on the function body, 39658 and, for inlined functions, a pointer to the function that it will be 39659 inlined into. 39660 39661 It is also possible to redirect any edge of the callgraph from a 39662 function to its virtual clone. This implies updating of the call site 39663 to adjust for the new function signature. 39664 39665 Most of the transformations performed by inter-procedural 39666 optimizations can be represented via virtual clones. For instance, a 39667 constant propagation pass can produce a virtual clone of the function 39668 which replaces one of its arguments by a constant. The inliner can 39669 represent its decisions by producing a clone of a function whose body 39670 will be later integrated into a given function. 39671 39672 Using _virtual clones_, the program can be easily updated during the 39673 _Execute_ stage, solving most of pass interactions problems that would 39674 otherwise occur during _Transform_. 39675 39676 Virtual clones are later materialized in the LTRANS stage and turned 39677 into real functions. Passes executed after the virtual clone were 39678 introduced also perform their _Transform_ stage on new functions, so 39679 for a pass there is no significant difference between operating on a 39680 real function or a virtual clone introduced before its _Execute_ stage. 39681 39682 Optimization passes then work on virtual clones introduced before 39683 their _Execute_ stage as if they were real functions. The only 39684 difference is that clones are not visible during the _Generate Summary_ 39685 stage. 39686 39687 To keep function summaries updated, the callgraph interface allows an 39688 optimizer to register a callback that is called every time a new clone 39689 is introduced as well as when the actual function or variable is 39690 generated or when a function or variable is removed. These hooks are 39691 registered in the _Generate summary_ stage and allow the pass to keep 39692 its information intact until the _Execute_ stage. The same hooks can 39693 also be registered during the _Execute_ stage to keep the optimization 39694 summaries updated for the _Transform_ stage. 39695 39696 24.3.2 IPA references 39697 --------------------- 39698 39699 GCC represents IPA references in the callgraph. For a function or 39700 variable `A', the _IPA reference_ is a list of all locations where the 39701 address of `A' is taken and, when `A' is a variable, a list of all 39702 direct stores and reads to/from `A'. References represent an oriented 39703 multi-graph on the union of nodes of the callgraph and the varpool. See 39704 `ipa-reference.c':`ipa_reference_write_optimization_summary' and 39705 `ipa-reference.c':`ipa_reference_read_optimization_summary' for details. 39706 39707 24.3.3 Jump functions 39708 --------------------- 39709 39710 Suppose that an optimization pass sees a function `A' and it knows the 39711 values of (some of) its arguments. The _jump function_ describes the 39712 value of a parameter of a given function call in function `A' based on 39713 this knowledge. 39714 39715 Jump functions are used by several optimizations, such as the 39716 inter-procedural constant propagation pass and the devirtualization 39717 pass. The inliner also uses jump functions to perform inlining of 39718 callbacks. 39719 39720 39721 File: gccint.info, Node: WHOPR, Next: Internal flags, Prev: IPA, Up: LTO 39722 39723 24.4 Whole program assumptions, linker plugin and symbol visibilities 39724 ===================================================================== 39725 39726 Link-time optimization gives relatively minor benefits when used alone. 39727 The problem is that propagation of inter-procedural information does 39728 not work well across functions and variables that are called or 39729 referenced by other compilation units (such as from a dynamically 39730 linked library). We say that such functions and variables are 39731 _externally visible_. 39732 39733 To make the situation even more difficult, many applications organize 39734 themselves as a set of shared libraries, and the default ELF visibility 39735 rules allow one to overwrite any externally visible symbol with a 39736 different symbol at runtime. This basically disables any optimizations 39737 across such functions and variables, because the compiler cannot be 39738 sure that the function body it is seeing is the same function body that 39739 will be used at runtime. Any function or variable not declared 39740 `static' in the sources degrades the quality of inter-procedural 39741 optimization. 39742 39743 To avoid this problem the compiler must assume that it sees the whole 39744 program when doing link-time optimization. Strictly speaking, the 39745 whole program is rarely visible even at link-time. Standard system 39746 libraries are usually linked dynamically or not provided with the 39747 link-time information. In GCC, the whole program option 39748 (`-fwhole-program') asserts that every function and variable defined in 39749 the current compilation unit is static, except for function `main' 39750 (note: at link time, the current unit is the union of all objects 39751 compiled with LTO). Since some functions and variables need to be 39752 referenced externally, for example by another DSO or from an assembler 39753 file, GCC also provides the function and variable attribute 39754 `externally_visible' which can be used to disable the effect of 39755 `-fwhole-program' on a specific symbol. 39756 39757 The whole program mode assumptions are slightly more complex in C++, 39758 where inline functions in headers are put into _COMDAT_ sections. 39759 COMDAT function and variables can be defined by multiple object files 39760 and their bodies are unified at link-time and dynamic link-time. 39761 COMDAT functions are changed to local only when their address is not 39762 taken and thus un-sharing them with a library is not harmful. COMDAT 39763 variables always remain externally visible, however for readonly 39764 variables it is assumed that their initializers cannot be overwritten 39765 by a different value. 39766 39767 GCC provides the function and variable attribute `visibility' that can 39768 be used to specify the visibility of externally visible symbols (or 39769 alternatively an `-fdefault-visibility' command line option). ELF 39770 defines the `default', `protected', `hidden' and `internal' 39771 visibilities. 39772 39773 The most commonly used is visibility is `hidden'. It specifies that 39774 the symbol cannot be referenced from outside of the current shared 39775 library. Unfortunately, this information cannot be used directly by 39776 the link-time optimization in the compiler since the whole shared 39777 library also might contain non-LTO objects and those are not visible to 39778 the compiler. 39779 39780 GCC solves this problem using linker plugins. A _linker plugin_ is an 39781 interface to the linker that allows an external program to claim the 39782 ownership of a given object file. The linker then performs the linking 39783 procedure by querying the plugin about the symbol table of the claimed 39784 objects and once the linking decisions are complete, the plugin is 39785 allowed to provide the final object file before the actual linking is 39786 made. The linker plugin obtains the symbol resolution information 39787 which specifies which symbols provided by the claimed objects are bound 39788 from the rest of a binary being linked. 39789 39790 Currently, the linker plugin works only in combination with the Gold 39791 linker, but a GNU ld implementation is under development. 39792 39793 GCC is designed to be independent of the rest of the toolchain and 39794 aims to support linkers without plugin support. For this reason it 39795 does not use the linker plugin by default. Instead, the object files 39796 are examined by `collect2' before being passed to the linker and 39797 objects found to have LTO sections are passed to `lto1' first. This 39798 mode does not work for library archives. The decision on what object 39799 files from the archive are needed depends on the actual linking and 39800 thus GCC would have to implement the linker itself. The resolution 39801 information is missing too and thus GCC needs to make an educated guess 39802 based on `-fwhole-program'. Without the linker plugin GCC also assumes 39803 that symbols are declared `hidden' and not referred by non-LTO code by 39804 default. 39805 39806 39807 File: gccint.info, Node: Internal flags, Prev: WHOPR, Up: LTO 39808 39809 24.5 Internal flags controlling `lto1' 39810 ====================================== 39811 39812 The following flags are passed into `lto1' and are not meant to be used 39813 directly from the command line. 39814 39815 * -fwpa This option runs the serial part of the link-time optimizer 39816 performing the inter-procedural propagation (WPA mode). The 39817 compiler reads in summary information from all inputs and performs 39818 an analysis based on summary information only. It generates 39819 object files for subsequent runs of the link-time optimizer where 39820 individual object files are optimized using both summary 39821 information from the WPA mode and the actual function bodies. It 39822 then drives the LTRANS phase. 39823 39824 * -fltrans This option runs the link-time optimizer in the 39825 local-transformation (LTRANS) mode, which reads in output from a 39826 previous run of the LTO in WPA mode. In the LTRANS mode, LTO 39827 optimizes an object and produces the final assembly. 39828 39829 * -fltrans-output-list=FILE This option specifies a file to which 39830 the names of LTRANS output files are written. This option is only 39831 meaningful in conjunction with `-fwpa'. 39832 39833 39834 File: gccint.info, Node: Funding, Next: GNU Project, Prev: LTO, Up: Top 39835 39836 Funding Free Software 39837 ********************* 39838 39839 If you want to have more free software a few years from now, it makes 39840 sense for you to help encourage people to contribute funds for its 39841 development. The most effective approach known is to encourage 39842 commercial redistributors to donate. 39843 39844 Users of free software systems can boost the pace of development by 39845 encouraging for-a-fee distributors to donate part of their selling price 39846 to free software developers--the Free Software Foundation, and others. 39847 39848 The way to convince distributors to do this is to demand it and expect 39849 it from them. So when you compare distributors, judge them partly by 39850 how much they give to free software development. Show distributors 39851 they must compete to be the one who gives the most. 39852 39853 To make this approach work, you must insist on numbers that you can 39854 compare, such as, "We will donate ten dollars to the Frobnitz project 39855 for each disk sold." Don't be satisfied with a vague promise, such as 39856 "A portion of the profits are donated," since it doesn't give a basis 39857 for comparison. 39858 39859 Even a precise fraction "of the profits from this disk" is not very 39860 meaningful, since creative accounting and unrelated business decisions 39861 can greatly alter what fraction of the sales price counts as profit. 39862 If the price you pay is $50, ten percent of the profit is probably less 39863 than a dollar; it might be a few cents, or nothing at all. 39864 39865 Some redistributors do development work themselves. This is useful 39866 too; but to keep everyone honest, you need to inquire how much they do, 39867 and what kind. Some kinds of development make much more long-term 39868 difference than others. For example, maintaining a separate version of 39869 a program contributes very little; maintaining the standard version of a 39870 program for the whole community contributes much. Easy new ports 39871 contribute little, since someone else would surely do them; difficult 39872 ports such as adding a new CPU to the GNU Compiler Collection 39873 contribute more; major new features or packages contribute the most. 39874 39875 By establishing the idea that supporting further development is "the 39876 proper thing to do" when distributing free software for a fee, we can 39877 assure a steady flow of resources into making more free software. 39878 39879 Copyright (C) 1994 Free Software Foundation, Inc. 39880 Verbatim copying and redistribution of this section is permitted 39881 without royalty; alteration is not permitted. 39882 39883 39884 File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 39885 39886 The GNU Project and GNU/Linux 39887 ***************************** 39888 39889 The GNU Project was launched in 1984 to develop a complete Unix-like 39890 operating system which is free software: the GNU system. (GNU is a 39891 recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 39892 Variants of the GNU operating system, which use the kernel Linux, are 39893 now widely used; though these systems are often referred to as "Linux", 39894 they are more accurately called GNU/Linux systems. 39895 39896 For more information, see: 39897 `http://www.gnu.org/' 39898 `http://www.gnu.org/gnu/linux-and-gnu.html' 39899 39900 39901 File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 39902 39903 GNU General Public License 39904 ************************** 39905 39906 Version 3, 29 June 2007 39907 39908 Copyright (C) 2007 Free Software Foundation, Inc. `http://fsf.org/' 39909 39910 Everyone is permitted to copy and distribute verbatim copies of this 39911 license document, but changing it is not allowed. 39912 39913 Preamble 39914 ======== 39915 39916 The GNU General Public License is a free, copyleft license for software 39917 and other kinds of works. 39918 39919 The licenses for most software and other practical works are designed 39920 to take away your freedom to share and change the works. By contrast, 39921 the GNU General Public License is intended to guarantee your freedom to 39922 share and change all versions of a program-to make sure it remains free 39923 software for all its users. We, the Free Software Foundation, use the 39924 GNU General Public License for most of our software; it applies also to 39925 any other work released this way by its authors. You can apply it to 39926 your programs, too. 39927 39928 When we speak of free software, we are referring to freedom, not 39929 price. Our General Public Licenses are designed to make sure that you 39930 have the freedom to distribute copies of free software (and charge for 39931 them if you wish), that you receive source code or can get it if you 39932 want it, that you can change the software or use pieces of it in new 39933 free programs, and that you know you can do these things. 39934 39935 To protect your rights, we need to prevent others from denying you 39936 these rights or asking you to surrender the rights. Therefore, you 39937 have certain responsibilities if you distribute copies of the software, 39938 or if you modify it: responsibilities to respect the freedom of others. 39939 39940 For example, if you distribute copies of such a program, whether 39941 gratis or for a fee, you must pass on to the recipients the same 39942 freedoms that you received. You must make sure that they, too, receive 39943 or can get the source code. And you must show them these terms so they 39944 know their rights. 39945 39946 Developers that use the GNU GPL protect your rights with two steps: 39947 (1) assert copyright on the software, and (2) offer you this License 39948 giving you legal permission to copy, distribute and/or modify it. 39949 39950 For the developers' and authors' protection, the GPL clearly explains 39951 that there is no warranty for this free software. For both users' and 39952 authors' sake, the GPL requires that modified versions be marked as 39953 changed, so that their problems will not be attributed erroneously to 39954 authors of previous versions. 39955 39956 Some devices are designed to deny users access to install or run 39957 modified versions of the software inside them, although the 39958 manufacturer can do so. This is fundamentally incompatible with the 39959 aim of protecting users' freedom to change the software. The 39960 systematic pattern of such abuse occurs in the area of products for 39961 individuals to use, which is precisely where it is most unacceptable. 39962 Therefore, we have designed this version of the GPL to prohibit the 39963 practice for those products. If such problems arise substantially in 39964 other domains, we stand ready to extend this provision to those domains 39965 in future versions of the GPL, as needed to protect the freedom of 39966 users. 39967 39968 Finally, every program is threatened constantly by software patents. 39969 States should not allow patents to restrict development and use of 39970 software on general-purpose computers, but in those that do, we wish to 39971 avoid the special danger that patents applied to a free program could 39972 make it effectively proprietary. To prevent this, the GPL assures that 39973 patents cannot be used to render the program non-free. 39974 39975 The precise terms and conditions for copying, distribution and 39976 modification follow. 39977 39978 TERMS AND CONDITIONS 39979 ==================== 39980 39981 0. Definitions. 39982 39983 "This License" refers to version 3 of the GNU General Public 39984 License. 39985 39986 "Copyright" also means copyright-like laws that apply to other 39987 kinds of works, such as semiconductor masks. 39988 39989 "The Program" refers to any copyrightable work licensed under this 39990 License. Each licensee is addressed as "you". "Licensees" and 39991 "recipients" may be individuals or organizations. 39992 39993 To "modify" a work means to copy from or adapt all or part of the 39994 work in a fashion requiring copyright permission, other than the 39995 making of an exact copy. The resulting work is called a "modified 39996 version" of the earlier work or a work "based on" the earlier work. 39997 39998 A "covered work" means either the unmodified Program or a work 39999 based on the Program. 40000 40001 To "propagate" a work means to do anything with it that, without 40002 permission, would make you directly or secondarily liable for 40003 infringement under applicable copyright law, except executing it 40004 on a computer or modifying a private copy. Propagation includes 40005 copying, distribution (with or without modification), making 40006 available to the public, and in some countries other activities as 40007 well. 40008 40009 To "convey" a work means any kind of propagation that enables other 40010 parties to make or receive copies. Mere interaction with a user 40011 through a computer network, with no transfer of a copy, is not 40012 conveying. 40013 40014 An interactive user interface displays "Appropriate Legal Notices" 40015 to the extent that it includes a convenient and prominently visible 40016 feature that (1) displays an appropriate copyright notice, and (2) 40017 tells the user that there is no warranty for the work (except to 40018 the extent that warranties are provided), that licensees may 40019 convey the work under this License, and how to view a copy of this 40020 License. If the interface presents a list of user commands or 40021 options, such as a menu, a prominent item in the list meets this 40022 criterion. 40023 40024 1. Source Code. 40025 40026 The "source code" for a work means the preferred form of the work 40027 for making modifications to it. "Object code" means any 40028 non-source form of a work. 40029 40030 A "Standard Interface" means an interface that either is an 40031 official standard defined by a recognized standards body, or, in 40032 the case of interfaces specified for a particular programming 40033 language, one that is widely used among developers working in that 40034 language. 40035 40036 The "System Libraries" of an executable work include anything, 40037 other than the work as a whole, that (a) is included in the normal 40038 form of packaging a Major Component, but which is not part of that 40039 Major Component, and (b) serves only to enable use of the work 40040 with that Major Component, or to implement a Standard Interface 40041 for which an implementation is available to the public in source 40042 code form. A "Major Component", in this context, means a major 40043 essential component (kernel, window system, and so on) of the 40044 specific operating system (if any) on which the executable work 40045 runs, or a compiler used to produce the work, or an object code 40046 interpreter used to run it. 40047 40048 The "Corresponding Source" for a work in object code form means all 40049 the source code needed to generate, install, and (for an executable 40050 work) run the object code and to modify the work, including 40051 scripts to control those activities. However, it does not include 40052 the work's System Libraries, or general-purpose tools or generally 40053 available free programs which are used unmodified in performing 40054 those activities but which are not part of the work. For example, 40055 Corresponding Source includes interface definition files 40056 associated with source files for the work, and the source code for 40057 shared libraries and dynamically linked subprograms that the work 40058 is specifically designed to require, such as by intimate data 40059 communication or control flow between those subprograms and other 40060 parts of the work. 40061 40062 The Corresponding Source need not include anything that users can 40063 regenerate automatically from other parts of the Corresponding 40064 Source. 40065 40066 The Corresponding Source for a work in source code form is that 40067 same work. 40068 40069 2. Basic Permissions. 40070 40071 All rights granted under this License are granted for the term of 40072 copyright on the Program, and are irrevocable provided the stated 40073 conditions are met. This License explicitly affirms your unlimited 40074 permission to run the unmodified Program. The output from running 40075 a covered work is covered by this License only if the output, 40076 given its content, constitutes a covered work. This License 40077 acknowledges your rights of fair use or other equivalent, as 40078 provided by copyright law. 40079 40080 You may make, run and propagate covered works that you do not 40081 convey, without conditions so long as your license otherwise 40082 remains in force. You may convey covered works to others for the 40083 sole purpose of having them make modifications exclusively for 40084 you, or provide you with facilities for running those works, 40085 provided that you comply with the terms of this License in 40086 conveying all material for which you do not control copyright. 40087 Those thus making or running the covered works for you must do so 40088 exclusively on your behalf, under your direction and control, on 40089 terms that prohibit them from making any copies of your 40090 copyrighted material outside their relationship with you. 40091 40092 Conveying under any other circumstances is permitted solely under 40093 the conditions stated below. Sublicensing is not allowed; section 40094 10 makes it unnecessary. 40095 40096 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 40097 40098 No covered work shall be deemed part of an effective technological 40099 measure under any applicable law fulfilling obligations under 40100 article 11 of the WIPO copyright treaty adopted on 20 December 40101 1996, or similar laws prohibiting or restricting circumvention of 40102 such measures. 40103 40104 When you convey a covered work, you waive any legal power to forbid 40105 circumvention of technological measures to the extent such 40106 circumvention is effected by exercising rights under this License 40107 with respect to the covered work, and you disclaim any intention 40108 to limit operation or modification of the work as a means of 40109 enforcing, against the work's users, your or third parties' legal 40110 rights to forbid circumvention of technological measures. 40111 40112 4. Conveying Verbatim Copies. 40113 40114 You may convey verbatim copies of the Program's source code as you 40115 receive it, in any medium, provided that you conspicuously and 40116 appropriately publish on each copy an appropriate copyright notice; 40117 keep intact all notices stating that this License and any 40118 non-permissive terms added in accord with section 7 apply to the 40119 code; keep intact all notices of the absence of any warranty; and 40120 give all recipients a copy of this License along with the Program. 40121 40122 You may charge any price or no price for each copy that you convey, 40123 and you may offer support or warranty protection for a fee. 40124 40125 5. Conveying Modified Source Versions. 40126 40127 You may convey a work based on the Program, or the modifications to 40128 produce it from the Program, in the form of source code under the 40129 terms of section 4, provided that you also meet all of these 40130 conditions: 40131 40132 a. The work must carry prominent notices stating that you 40133 modified it, and giving a relevant date. 40134 40135 b. The work must carry prominent notices stating that it is 40136 released under this License and any conditions added under 40137 section 7. This requirement modifies the requirement in 40138 section 4 to "keep intact all notices". 40139 40140 c. You must license the entire work, as a whole, under this 40141 License to anyone who comes into possession of a copy. This 40142 License will therefore apply, along with any applicable 40143 section 7 additional terms, to the whole of the work, and all 40144 its parts, regardless of how they are packaged. This License 40145 gives no permission to license the work in any other way, but 40146 it does not invalidate such permission if you have separately 40147 received it. 40148 40149 d. If the work has interactive user interfaces, each must display 40150 Appropriate Legal Notices; however, if the Program has 40151 interactive interfaces that do not display Appropriate Legal 40152 Notices, your work need not make them do so. 40153 40154 A compilation of a covered work with other separate and independent 40155 works, which are not by their nature extensions of the covered 40156 work, and which are not combined with it such as to form a larger 40157 program, in or on a volume of a storage or distribution medium, is 40158 called an "aggregate" if the compilation and its resulting 40159 copyright are not used to limit the access or legal rights of the 40160 compilation's users beyond what the individual works permit. 40161 Inclusion of a covered work in an aggregate does not cause this 40162 License to apply to the other parts of the aggregate. 40163 40164 6. Conveying Non-Source Forms. 40165 40166 You may convey a covered work in object code form under the terms 40167 of sections 4 and 5, provided that you also convey the 40168 machine-readable Corresponding Source under the terms of this 40169 License, in one of these ways: 40170 40171 a. Convey the object code in, or embodied in, a physical product 40172 (including a physical distribution medium), accompanied by the 40173 Corresponding Source fixed on a durable physical medium 40174 customarily used for software interchange. 40175 40176 b. Convey the object code in, or embodied in, a physical product 40177 (including a physical distribution medium), accompanied by a 40178 written offer, valid for at least three years and valid for 40179 as long as you offer spare parts or customer support for that 40180 product model, to give anyone who possesses the object code 40181 either (1) a copy of the Corresponding Source for all the 40182 software in the product that is covered by this License, on a 40183 durable physical medium customarily used for software 40184 interchange, for a price no more than your reasonable cost of 40185 physically performing this conveying of source, or (2) access 40186 to copy the Corresponding Source from a network server at no 40187 charge. 40188 40189 c. Convey individual copies of the object code with a copy of 40190 the written offer to provide the Corresponding Source. This 40191 alternative is allowed only occasionally and noncommercially, 40192 and only if you received the object code with such an offer, 40193 in accord with subsection 6b. 40194 40195 d. Convey the object code by offering access from a designated 40196 place (gratis or for a charge), and offer equivalent access 40197 to the Corresponding Source in the same way through the same 40198 place at no further charge. You need not require recipients 40199 to copy the Corresponding Source along with the object code. 40200 If the place to copy the object code is a network server, the 40201 Corresponding Source may be on a different server (operated 40202 by you or a third party) that supports equivalent copying 40203 facilities, provided you maintain clear directions next to 40204 the object code saying where to find the Corresponding Source. 40205 Regardless of what server hosts the Corresponding Source, you 40206 remain obligated to ensure that it is available for as long 40207 as needed to satisfy these requirements. 40208 40209 e. Convey the object code using peer-to-peer transmission, 40210 provided you inform other peers where the object code and 40211 Corresponding Source of the work are being offered to the 40212 general public at no charge under subsection 6d. 40213 40214 40215 A separable portion of the object code, whose source code is 40216 excluded from the Corresponding Source as a System Library, need 40217 not be included in conveying the object code work. 40218 40219 A "User Product" is either (1) a "consumer product", which means 40220 any tangible personal property which is normally used for personal, 40221 family, or household purposes, or (2) anything designed or sold for 40222 incorporation into a dwelling. In determining whether a product 40223 is a consumer product, doubtful cases shall be resolved in favor of 40224 coverage. For a particular product received by a particular user, 40225 "normally used" refers to a typical or common use of that class of 40226 product, regardless of the status of the particular user or of the 40227 way in which the particular user actually uses, or expects or is 40228 expected to use, the product. A product is a consumer product 40229 regardless of whether the product has substantial commercial, 40230 industrial or non-consumer uses, unless such uses represent the 40231 only significant mode of use of the product. 40232 40233 "Installation Information" for a User Product means any methods, 40234 procedures, authorization keys, or other information required to 40235 install and execute modified versions of a covered work in that 40236 User Product from a modified version of its Corresponding Source. 40237 The information must suffice to ensure that the continued 40238 functioning of the modified object code is in no case prevented or 40239 interfered with solely because modification has been made. 40240 40241 If you convey an object code work under this section in, or with, 40242 or specifically for use in, a User Product, and the conveying 40243 occurs as part of a transaction in which the right of possession 40244 and use of the User Product is transferred to the recipient in 40245 perpetuity or for a fixed term (regardless of how the transaction 40246 is characterized), the Corresponding Source conveyed under this 40247 section must be accompanied by the Installation Information. But 40248 this requirement does not apply if neither you nor any third party 40249 retains the ability to install modified object code on the User 40250 Product (for example, the work has been installed in ROM). 40251 40252 The requirement to provide Installation Information does not 40253 include a requirement to continue to provide support service, 40254 warranty, or updates for a work that has been modified or 40255 installed by the recipient, or for the User Product in which it 40256 has been modified or installed. Access to a network may be denied 40257 when the modification itself materially and adversely affects the 40258 operation of the network or violates the rules and protocols for 40259 communication across the network. 40260 40261 Corresponding Source conveyed, and Installation Information 40262 provided, in accord with this section must be in a format that is 40263 publicly documented (and with an implementation available to the 40264 public in source code form), and must require no special password 40265 or key for unpacking, reading or copying. 40266 40267 7. Additional Terms. 40268 40269 "Additional permissions" are terms that supplement the terms of 40270 this License by making exceptions from one or more of its 40271 conditions. Additional permissions that are applicable to the 40272 entire Program shall be treated as though they were included in 40273 this License, to the extent that they are valid under applicable 40274 law. If additional permissions apply only to part of the Program, 40275 that part may be used separately under those permissions, but the 40276 entire Program remains governed by this License without regard to 40277 the additional permissions. 40278 40279 When you convey a copy of a covered work, you may at your option 40280 remove any additional permissions from that copy, or from any part 40281 of it. (Additional permissions may be written to require their own 40282 removal in certain cases when you modify the work.) You may place 40283 additional permissions on material, added by you to a covered work, 40284 for which you have or can give appropriate copyright permission. 40285 40286 Notwithstanding any other provision of this License, for material 40287 you add to a covered work, you may (if authorized by the copyright 40288 holders of that material) supplement the terms of this License 40289 with terms: 40290 40291 a. Disclaiming warranty or limiting liability differently from 40292 the terms of sections 15 and 16 of this License; or 40293 40294 b. Requiring preservation of specified reasonable legal notices 40295 or author attributions in that material or in the Appropriate 40296 Legal Notices displayed by works containing it; or 40297 40298 c. Prohibiting misrepresentation of the origin of that material, 40299 or requiring that modified versions of such material be 40300 marked in reasonable ways as different from the original 40301 version; or 40302 40303 d. Limiting the use for publicity purposes of names of licensors 40304 or authors of the material; or 40305 40306 e. Declining to grant rights under trademark law for use of some 40307 trade names, trademarks, or service marks; or 40308 40309 f. Requiring indemnification of licensors and authors of that 40310 material by anyone who conveys the material (or modified 40311 versions of it) with contractual assumptions of liability to 40312 the recipient, for any liability that these contractual 40313 assumptions directly impose on those licensors and authors. 40314 40315 All other non-permissive additional terms are considered "further 40316 restrictions" within the meaning of section 10. If the Program as 40317 you received it, or any part of it, contains a notice stating that 40318 it is governed by this License along with a term that is a further 40319 restriction, you may remove that term. If a license document 40320 contains a further restriction but permits relicensing or 40321 conveying under this License, you may add to a covered work 40322 material governed by the terms of that license document, provided 40323 that the further restriction does not survive such relicensing or 40324 conveying. 40325 40326 If you add terms to a covered work in accord with this section, you 40327 must place, in the relevant source files, a statement of the 40328 additional terms that apply to those files, or a notice indicating 40329 where to find the applicable terms. 40330 40331 Additional terms, permissive or non-permissive, may be stated in 40332 the form of a separately written license, or stated as exceptions; 40333 the above requirements apply either way. 40334 40335 8. Termination. 40336 40337 You may not propagate or modify a covered work except as expressly 40338 provided under this License. Any attempt otherwise to propagate or 40339 modify it is void, and will automatically terminate your rights 40340 under this License (including any patent licenses granted under 40341 the third paragraph of section 11). 40342 40343 However, if you cease all violation of this License, then your 40344 license from a particular copyright holder is reinstated (a) 40345 provisionally, unless and until the copyright holder explicitly 40346 and finally terminates your license, and (b) permanently, if the 40347 copyright holder fails to notify you of the violation by some 40348 reasonable means prior to 60 days after the cessation. 40349 40350 Moreover, your license from a particular copyright holder is 40351 reinstated permanently if the copyright holder notifies you of the 40352 violation by some reasonable means, this is the first time you have 40353 received notice of violation of this License (for any work) from 40354 that copyright holder, and you cure the violation prior to 30 days 40355 after your receipt of the notice. 40356 40357 Termination of your rights under this section does not terminate 40358 the licenses of parties who have received copies or rights from 40359 you under this License. If your rights have been terminated and 40360 not permanently reinstated, you do not qualify to receive new 40361 licenses for the same material under section 10. 40362 40363 9. Acceptance Not Required for Having Copies. 40364 40365 You are not required to accept this License in order to receive or 40366 run a copy of the Program. Ancillary propagation of a covered work 40367 occurring solely as a consequence of using peer-to-peer 40368 transmission to receive a copy likewise does not require 40369 acceptance. However, nothing other than this License grants you 40370 permission to propagate or modify any covered work. These actions 40371 infringe copyright if you do not accept this License. Therefore, 40372 by modifying or propagating a covered work, you indicate your 40373 acceptance of this License to do so. 40374 40375 10. Automatic Licensing of Downstream Recipients. 40376 40377 Each time you convey a covered work, the recipient automatically 40378 receives a license from the original licensors, to run, modify and 40379 propagate that work, subject to this License. You are not 40380 responsible for enforcing compliance by third parties with this 40381 License. 40382 40383 An "entity transaction" is a transaction transferring control of an 40384 organization, or substantially all assets of one, or subdividing an 40385 organization, or merging organizations. If propagation of a 40386 covered work results from an entity transaction, each party to that 40387 transaction who receives a copy of the work also receives whatever 40388 licenses to the work the party's predecessor in interest had or 40389 could give under the previous paragraph, plus a right to 40390 possession of the Corresponding Source of the work from the 40391 predecessor in interest, if the predecessor has it or can get it 40392 with reasonable efforts. 40393 40394 You may not impose any further restrictions on the exercise of the 40395 rights granted or affirmed under this License. For example, you 40396 may not impose a license fee, royalty, or other charge for 40397 exercise of rights granted under this License, and you may not 40398 initiate litigation (including a cross-claim or counterclaim in a 40399 lawsuit) alleging that any patent claim is infringed by making, 40400 using, selling, offering for sale, or importing the Program or any 40401 portion of it. 40402 40403 11. Patents. 40404 40405 A "contributor" is a copyright holder who authorizes use under this 40406 License of the Program or a work on which the Program is based. 40407 The work thus licensed is called the contributor's "contributor 40408 version". 40409 40410 A contributor's "essential patent claims" are all patent claims 40411 owned or controlled by the contributor, whether already acquired or 40412 hereafter acquired, that would be infringed by some manner, 40413 permitted by this License, of making, using, or selling its 40414 contributor version, but do not include claims that would be 40415 infringed only as a consequence of further modification of the 40416 contributor version. For purposes of this definition, "control" 40417 includes the right to grant patent sublicenses in a manner 40418 consistent with the requirements of this License. 40419 40420 Each contributor grants you a non-exclusive, worldwide, 40421 royalty-free patent license under the contributor's essential 40422 patent claims, to make, use, sell, offer for sale, import and 40423 otherwise run, modify and propagate the contents of its 40424 contributor version. 40425 40426 In the following three paragraphs, a "patent license" is any 40427 express agreement or commitment, however denominated, not to 40428 enforce a patent (such as an express permission to practice a 40429 patent or covenant not to sue for patent infringement). To 40430 "grant" such a patent license to a party means to make such an 40431 agreement or commitment not to enforce a patent against the party. 40432 40433 If you convey a covered work, knowingly relying on a patent 40434 license, and the Corresponding Source of the work is not available 40435 for anyone to copy, free of charge and under the terms of this 40436 License, through a publicly available network server or other 40437 readily accessible means, then you must either (1) cause the 40438 Corresponding Source to be so available, or (2) arrange to deprive 40439 yourself of the benefit of the patent license for this particular 40440 work, or (3) arrange, in a manner consistent with the requirements 40441 of this License, to extend the patent license to downstream 40442 recipients. "Knowingly relying" means you have actual knowledge 40443 that, but for the patent license, your conveying the covered work 40444 in a country, or your recipient's use of the covered work in a 40445 country, would infringe one or more identifiable patents in that 40446 country that you have reason to believe are valid. 40447 40448 If, pursuant to or in connection with a single transaction or 40449 arrangement, you convey, or propagate by procuring conveyance of, a 40450 covered work, and grant a patent license to some of the parties 40451 receiving the covered work authorizing them to use, propagate, 40452 modify or convey a specific copy of the covered work, then the 40453 patent license you grant is automatically extended to all 40454 recipients of the covered work and works based on it. 40455 40456 A patent license is "discriminatory" if it does not include within 40457 the scope of its coverage, prohibits the exercise of, or is 40458 conditioned on the non-exercise of one or more of the rights that 40459 are specifically granted under this License. You may not convey a 40460 covered work if you are a party to an arrangement with a third 40461 party that is in the business of distributing software, under 40462 which you make payment to the third party based on the extent of 40463 your activity of conveying the work, and under which the third 40464 party grants, to any of the parties who would receive the covered 40465 work from you, a discriminatory patent license (a) in connection 40466 with copies of the covered work conveyed by you (or copies made 40467 from those copies), or (b) primarily for and in connection with 40468 specific products or compilations that contain the covered work, 40469 unless you entered into that arrangement, or that patent license 40470 was granted, prior to 28 March 2007. 40471 40472 Nothing in this License shall be construed as excluding or limiting 40473 any implied license or other defenses to infringement that may 40474 otherwise be available to you under applicable patent law. 40475 40476 12. No Surrender of Others' Freedom. 40477 40478 If conditions are imposed on you (whether by court order, 40479 agreement or otherwise) that contradict the conditions of this 40480 License, they do not excuse you from the conditions of this 40481 License. If you cannot convey a covered work so as to satisfy 40482 simultaneously your obligations under this License and any other 40483 pertinent obligations, then as a consequence you may not convey it 40484 at all. For example, if you agree to terms that obligate you to 40485 collect a royalty for further conveying from those to whom you 40486 convey the Program, the only way you could satisfy both those 40487 terms and this License would be to refrain entirely from conveying 40488 the Program. 40489 40490 13. Use with the GNU Affero General Public License. 40491 40492 Notwithstanding any other provision of this License, you have 40493 permission to link or combine any covered work with a work licensed 40494 under version 3 of the GNU Affero General Public License into a 40495 single combined work, and to convey the resulting work. The terms 40496 of this License will continue to apply to the part which is the 40497 covered work, but the special requirements of the GNU Affero 40498 General Public License, section 13, concerning interaction through 40499 a network will apply to the combination as such. 40500 40501 14. Revised Versions of this License. 40502 40503 The Free Software Foundation may publish revised and/or new 40504 versions of the GNU General Public License from time to time. 40505 Such new versions will be similar in spirit to the present 40506 version, but may differ in detail to address new problems or 40507 concerns. 40508 40509 Each version is given a distinguishing version number. If the 40510 Program specifies that a certain numbered version of the GNU 40511 General Public License "or any later version" applies to it, you 40512 have the option of following the terms and conditions either of 40513 that numbered version or of any later version published by the 40514 Free Software Foundation. If the Program does not specify a 40515 version number of the GNU General Public License, you may choose 40516 any version ever published by the Free Software Foundation. 40517 40518 If the Program specifies that a proxy can decide which future 40519 versions of the GNU General Public License can be used, that 40520 proxy's public statement of acceptance of a version permanently 40521 authorizes you to choose that version for the Program. 40522 40523 Later license versions may give you additional or different 40524 permissions. However, no additional obligations are imposed on any 40525 author or copyright holder as a result of your choosing to follow a 40526 later version. 40527 40528 15. Disclaimer of Warranty. 40529 40530 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 40531 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 40532 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 40533 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 40534 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 40535 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 40536 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 40537 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 40538 NECESSARY SERVICING, REPAIR OR CORRECTION. 40539 40540 16. Limitation of Liability. 40541 40542 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 40543 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 40544 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU 40545 FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 40546 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 40547 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 40548 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 40549 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 40550 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 40551 THE POSSIBILITY OF SUCH DAMAGES. 40552 40553 17. Interpretation of Sections 15 and 16. 40554 40555 If the disclaimer of warranty and limitation of liability provided 40556 above cannot be given local legal effect according to their terms, 40557 reviewing courts shall apply local law that most closely 40558 approximates an absolute waiver of all civil liability in 40559 connection with the Program, unless a warranty or assumption of 40560 liability accompanies a copy of the Program in return for a fee. 40561 40562 40563 END OF TERMS AND CONDITIONS 40564 =========================== 40565 40566 How to Apply These Terms to Your New Programs 40567 ============================================= 40568 40569 If you develop a new program, and you want it to be of the greatest 40570 possible use to the public, the best way to achieve this is to make it 40571 free software which everyone can redistribute and change under these 40572 terms. 40573 40574 To do so, attach the following notices to the program. It is safest 40575 to attach them to the start of each source file to most effectively 40576 state the exclusion of warranty; and each file should have at least the 40577 "copyright" line and a pointer to where the full notice is found. 40578 40579 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 40580 Copyright (C) YEAR NAME OF AUTHOR 40581 40582 This program is free software: you can redistribute it and/or modify 40583 it under the terms of the GNU General Public License as published by 40584 the Free Software Foundation, either version 3 of the License, or (at 40585 your option) any later version. 40586 40587 This program is distributed in the hope that it will be useful, but 40588 WITHOUT ANY WARRANTY; without even the implied warranty of 40589 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 40590 General Public License for more details. 40591 40592 You should have received a copy of the GNU General Public License 40593 along with this program. If not, see `http://www.gnu.org/licenses/'. 40594 40595 Also add information on how to contact you by electronic and paper 40596 mail. 40597 40598 If the program does terminal interaction, make it output a short 40599 notice like this when it starts in an interactive mode: 40600 40601 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 40602 This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. 40603 This is free software, and you are welcome to redistribute it 40604 under certain conditions; type `show c' for details. 40605 40606 The hypothetical commands `show w' and `show c' should show the 40607 appropriate parts of the General Public License. Of course, your 40608 program's commands might be different; for a GUI interface, you would 40609 use an "about box". 40610 40611 You should also get your employer (if you work as a programmer) or 40612 school, if any, to sign a "copyright disclaimer" for the program, if 40613 necessary. For more information on this, and how to apply and follow 40614 the GNU GPL, see `http://www.gnu.org/licenses/'. 40615 40616 The GNU General Public License does not permit incorporating your 40617 program into proprietary programs. If your program is a subroutine 40618 library, you may consider it more useful to permit linking proprietary 40619 applications with the library. If this is what you want to do, use the 40620 GNU Lesser General Public License instead of this License. But first, 40621 please read `http://www.gnu.org/philosophy/why-not-lgpl.html'. 40622 40623 40624 File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 40625 40626 GNU Free Documentation License 40627 ****************************** 40628 40629 Version 1.3, 3 November 2008 40630 40631 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 40632 `http://fsf.org/' 40633 40634 Everyone is permitted to copy and distribute verbatim copies 40635 of this license document, but changing it is not allowed. 40636 40637 0. PREAMBLE 40638 40639 The purpose of this License is to make a manual, textbook, or other 40640 functional and useful document "free" in the sense of freedom: to 40641 assure everyone the effective freedom to copy and redistribute it, 40642 with or without modifying it, either commercially or 40643 noncommercially. Secondarily, this License preserves for the 40644 author and publisher a way to get credit for their work, while not 40645 being considered responsible for modifications made by others. 40646 40647 This License is a kind of "copyleft", which means that derivative 40648 works of the document must themselves be free in the same sense. 40649 It complements the GNU General Public License, which is a copyleft 40650 license designed for free software. 40651 40652 We have designed this License in order to use it for manuals for 40653 free software, because free software needs free documentation: a 40654 free program should come with manuals providing the same freedoms 40655 that the software does. But this License is not limited to 40656 software manuals; it can be used for any textual work, regardless 40657 of subject matter or whether it is published as a printed book. 40658 We recommend this License principally for works whose purpose is 40659 instruction or reference. 40660 40661 1. APPLICABILITY AND DEFINITIONS 40662 40663 This License applies to any manual or other work, in any medium, 40664 that contains a notice placed by the copyright holder saying it 40665 can be distributed under the terms of this License. Such a notice 40666 grants a world-wide, royalty-free license, unlimited in duration, 40667 to use that work under the conditions stated herein. The 40668 "Document", below, refers to any such manual or work. Any member 40669 of the public is a licensee, and is addressed as "you". You 40670 accept the license if you copy, modify or distribute the work in a 40671 way requiring permission under copyright law. 40672 40673 A "Modified Version" of the Document means any work containing the 40674 Document or a portion of it, either copied verbatim, or with 40675 modifications and/or translated into another language. 40676 40677 A "Secondary Section" is a named appendix or a front-matter section 40678 of the Document that deals exclusively with the relationship of the 40679 publishers or authors of the Document to the Document's overall 40680 subject (or to related matters) and contains nothing that could 40681 fall directly within that overall subject. (Thus, if the Document 40682 is in part a textbook of mathematics, a Secondary Section may not 40683 explain any mathematics.) The relationship could be a matter of 40684 historical connection with the subject or with related matters, or 40685 of legal, commercial, philosophical, ethical or political position 40686 regarding them. 40687 40688 The "Invariant Sections" are certain Secondary Sections whose 40689 titles are designated, as being those of Invariant Sections, in 40690 the notice that says that the Document is released under this 40691 License. If a section does not fit the above definition of 40692 Secondary then it is not allowed to be designated as Invariant. 40693 The Document may contain zero Invariant Sections. If the Document 40694 does not identify any Invariant Sections then there are none. 40695 40696 The "Cover Texts" are certain short passages of text that are 40697 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 40698 that says that the Document is released under this License. A 40699 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 40700 be at most 25 words. 40701 40702 A "Transparent" copy of the Document means a machine-readable copy, 40703 represented in a format whose specification is available to the 40704 general public, that is suitable for revising the document 40705 straightforwardly with generic text editors or (for images 40706 composed of pixels) generic paint programs or (for drawings) some 40707 widely available drawing editor, and that is suitable for input to 40708 text formatters or for automatic translation to a variety of 40709 formats suitable for input to text formatters. A copy made in an 40710 otherwise Transparent file format whose markup, or absence of 40711 markup, has been arranged to thwart or discourage subsequent 40712 modification by readers is not Transparent. An image format is 40713 not Transparent if used for any substantial amount of text. A 40714 copy that is not "Transparent" is called "Opaque". 40715 40716 Examples of suitable formats for Transparent copies include plain 40717 ASCII without markup, Texinfo input format, LaTeX input format, 40718 SGML or XML using a publicly available DTD, and 40719 standard-conforming simple HTML, PostScript or PDF designed for 40720 human modification. Examples of transparent image formats include 40721 PNG, XCF and JPG. Opaque formats include proprietary formats that 40722 can be read and edited only by proprietary word processors, SGML or 40723 XML for which the DTD and/or processing tools are not generally 40724 available, and the machine-generated HTML, PostScript or PDF 40725 produced by some word processors for output purposes only. 40726 40727 The "Title Page" means, for a printed book, the title page itself, 40728 plus such following pages as are needed to hold, legibly, the 40729 material this License requires to appear in the title page. For 40730 works in formats which do not have any title page as such, "Title 40731 Page" means the text near the most prominent appearance of the 40732 work's title, preceding the beginning of the body of the text. 40733 40734 The "publisher" means any person or entity that distributes copies 40735 of the Document to the public. 40736 40737 A section "Entitled XYZ" means a named subunit of the Document 40738 whose title either is precisely XYZ or contains XYZ in parentheses 40739 following text that translates XYZ in another language. (Here XYZ 40740 stands for a specific section name mentioned below, such as 40741 "Acknowledgements", "Dedications", "Endorsements", or "History".) 40742 To "Preserve the Title" of such a section when you modify the 40743 Document means that it remains a section "Entitled XYZ" according 40744 to this definition. 40745 40746 The Document may include Warranty Disclaimers next to the notice 40747 which states that this License applies to the Document. These 40748 Warranty Disclaimers are considered to be included by reference in 40749 this License, but only as regards disclaiming warranties: any other 40750 implication that these Warranty Disclaimers may have is void and 40751 has no effect on the meaning of this License. 40752 40753 2. VERBATIM COPYING 40754 40755 You may copy and distribute the Document in any medium, either 40756 commercially or noncommercially, provided that this License, the 40757 copyright notices, and the license notice saying this License 40758 applies to the Document are reproduced in all copies, and that you 40759 add no other conditions whatsoever to those of this License. You 40760 may not use technical measures to obstruct or control the reading 40761 or further copying of the copies you make or distribute. However, 40762 you may accept compensation in exchange for copies. If you 40763 distribute a large enough number of copies you must also follow 40764 the conditions in section 3. 40765 40766 You may also lend copies, under the same conditions stated above, 40767 and you may publicly display copies. 40768 40769 3. COPYING IN QUANTITY 40770 40771 If you publish printed copies (or copies in media that commonly 40772 have printed covers) of the Document, numbering more than 100, and 40773 the Document's license notice requires Cover Texts, you must 40774 enclose the copies in covers that carry, clearly and legibly, all 40775 these Cover Texts: Front-Cover Texts on the front cover, and 40776 Back-Cover Texts on the back cover. Both covers must also clearly 40777 and legibly identify you as the publisher of these copies. The 40778 front cover must present the full title with all words of the 40779 title equally prominent and visible. You may add other material 40780 on the covers in addition. Copying with changes limited to the 40781 covers, as long as they preserve the title of the Document and 40782 satisfy these conditions, can be treated as verbatim copying in 40783 other respects. 40784 40785 If the required texts for either cover are too voluminous to fit 40786 legibly, you should put the first ones listed (as many as fit 40787 reasonably) on the actual cover, and continue the rest onto 40788 adjacent pages. 40789 40790 If you publish or distribute Opaque copies of the Document 40791 numbering more than 100, you must either include a 40792 machine-readable Transparent copy along with each Opaque copy, or 40793 state in or with each Opaque copy a computer-network location from 40794 which the general network-using public has access to download 40795 using public-standard network protocols a complete Transparent 40796 copy of the Document, free of added material. If you use the 40797 latter option, you must take reasonably prudent steps, when you 40798 begin distribution of Opaque copies in quantity, to ensure that 40799 this Transparent copy will remain thus accessible at the stated 40800 location until at least one year after the last time you 40801 distribute an Opaque copy (directly or through your agents or 40802 retailers) of that edition to the public. 40803 40804 It is requested, but not required, that you contact the authors of 40805 the Document well before redistributing any large number of 40806 copies, to give them a chance to provide you with an updated 40807 version of the Document. 40808 40809 4. MODIFICATIONS 40810 40811 You may copy and distribute a Modified Version of the Document 40812 under the conditions of sections 2 and 3 above, provided that you 40813 release the Modified Version under precisely this License, with 40814 the Modified Version filling the role of the Document, thus 40815 licensing distribution and modification of the Modified Version to 40816 whoever possesses a copy of it. In addition, you must do these 40817 things in the Modified Version: 40818 40819 A. Use in the Title Page (and on the covers, if any) a title 40820 distinct from that of the Document, and from those of 40821 previous versions (which should, if there were any, be listed 40822 in the History section of the Document). You may use the 40823 same title as a previous version if the original publisher of 40824 that version gives permission. 40825 40826 B. List on the Title Page, as authors, one or more persons or 40827 entities responsible for authorship of the modifications in 40828 the Modified Version, together with at least five of the 40829 principal authors of the Document (all of its principal 40830 authors, if it has fewer than five), unless they release you 40831 from this requirement. 40832 40833 C. State on the Title page the name of the publisher of the 40834 Modified Version, as the publisher. 40835 40836 D. Preserve all the copyright notices of the Document. 40837 40838 E. Add an appropriate copyright notice for your modifications 40839 adjacent to the other copyright notices. 40840 40841 F. Include, immediately after the copyright notices, a license 40842 notice giving the public permission to use the Modified 40843 Version under the terms of this License, in the form shown in 40844 the Addendum below. 40845 40846 G. Preserve in that license notice the full lists of Invariant 40847 Sections and required Cover Texts given in the Document's 40848 license notice. 40849 40850 H. Include an unaltered copy of this License. 40851 40852 I. Preserve the section Entitled "History", Preserve its Title, 40853 and add to it an item stating at least the title, year, new 40854 authors, and publisher of the Modified Version as given on 40855 the Title Page. If there is no section Entitled "History" in 40856 the Document, create one stating the title, year, authors, 40857 and publisher of the Document as given on its Title Page, 40858 then add an item describing the Modified Version as stated in 40859 the previous sentence. 40860 40861 J. Preserve the network location, if any, given in the Document 40862 for public access to a Transparent copy of the Document, and 40863 likewise the network locations given in the Document for 40864 previous versions it was based on. These may be placed in 40865 the "History" section. You may omit a network location for a 40866 work that was published at least four years before the 40867 Document itself, or if the original publisher of the version 40868 it refers to gives permission. 40869 40870 K. For any section Entitled "Acknowledgements" or "Dedications", 40871 Preserve the Title of the section, and preserve in the 40872 section all the substance and tone of each of the contributor 40873 acknowledgements and/or dedications given therein. 40874 40875 L. Preserve all the Invariant Sections of the Document, 40876 unaltered in their text and in their titles. Section numbers 40877 or the equivalent are not considered part of the section 40878 titles. 40879 40880 M. Delete any section Entitled "Endorsements". Such a section 40881 may not be included in the Modified Version. 40882 40883 N. Do not retitle any existing section to be Entitled 40884 "Endorsements" or to conflict in title with any Invariant 40885 Section. 40886 40887 O. Preserve any Warranty Disclaimers. 40888 40889 If the Modified Version includes new front-matter sections or 40890 appendices that qualify as Secondary Sections and contain no 40891 material copied from the Document, you may at your option 40892 designate some or all of these sections as invariant. To do this, 40893 add their titles to the list of Invariant Sections in the Modified 40894 Version's license notice. These titles must be distinct from any 40895 other section titles. 40896 40897 You may add a section Entitled "Endorsements", provided it contains 40898 nothing but endorsements of your Modified Version by various 40899 parties--for example, statements of peer review or that the text 40900 has been approved by an organization as the authoritative 40901 definition of a standard. 40902 40903 You may add a passage of up to five words as a Front-Cover Text, 40904 and a passage of up to 25 words as a Back-Cover Text, to the end 40905 of the list of Cover Texts in the Modified Version. Only one 40906 passage of Front-Cover Text and one of Back-Cover Text may be 40907 added by (or through arrangements made by) any one entity. If the 40908 Document already includes a cover text for the same cover, 40909 previously added by you or by arrangement made by the same entity 40910 you are acting on behalf of, you may not add another; but you may 40911 replace the old one, on explicit permission from the previous 40912 publisher that added the old one. 40913 40914 The author(s) and publisher(s) of the Document do not by this 40915 License give permission to use their names for publicity for or to 40916 assert or imply endorsement of any Modified Version. 40917 40918 5. COMBINING DOCUMENTS 40919 40920 You may combine the Document with other documents released under 40921 this License, under the terms defined in section 4 above for 40922 modified versions, provided that you include in the combination 40923 all of the Invariant Sections of all of the original documents, 40924 unmodified, and list them all as Invariant Sections of your 40925 combined work in its license notice, and that you preserve all 40926 their Warranty Disclaimers. 40927 40928 The combined work need only contain one copy of this License, and 40929 multiple identical Invariant Sections may be replaced with a single 40930 copy. If there are multiple Invariant Sections with the same name 40931 but different contents, make the title of each such section unique 40932 by adding at the end of it, in parentheses, the name of the 40933 original author or publisher of that section if known, or else a 40934 unique number. Make the same adjustment to the section titles in 40935 the list of Invariant Sections in the license notice of the 40936 combined work. 40937 40938 In the combination, you must combine any sections Entitled 40939 "History" in the various original documents, forming one section 40940 Entitled "History"; likewise combine any sections Entitled 40941 "Acknowledgements", and any sections Entitled "Dedications". You 40942 must delete all sections Entitled "Endorsements." 40943 40944 6. COLLECTIONS OF DOCUMENTS 40945 40946 You may make a collection consisting of the Document and other 40947 documents released under this License, and replace the individual 40948 copies of this License in the various documents with a single copy 40949 that is included in the collection, provided that you follow the 40950 rules of this License for verbatim copying of each of the 40951 documents in all other respects. 40952 40953 You may extract a single document from such a collection, and 40954 distribute it individually under this License, provided you insert 40955 a copy of this License into the extracted document, and follow 40956 this License in all other respects regarding verbatim copying of 40957 that document. 40958 40959 7. AGGREGATION WITH INDEPENDENT WORKS 40960 40961 A compilation of the Document or its derivatives with other 40962 separate and independent documents or works, in or on a volume of 40963 a storage or distribution medium, is called an "aggregate" if the 40964 copyright resulting from the compilation is not used to limit the 40965 legal rights of the compilation's users beyond what the individual 40966 works permit. When the Document is included in an aggregate, this 40967 License does not apply to the other works in the aggregate which 40968 are not themselves derivative works of the Document. 40969 40970 If the Cover Text requirement of section 3 is applicable to these 40971 copies of the Document, then if the Document is less than one half 40972 of the entire aggregate, the Document's Cover Texts may be placed 40973 on covers that bracket the Document within the aggregate, or the 40974 electronic equivalent of covers if the Document is in electronic 40975 form. Otherwise they must appear on printed covers that bracket 40976 the whole aggregate. 40977 40978 8. TRANSLATION 40979 40980 Translation is considered a kind of modification, so you may 40981 distribute translations of the Document under the terms of section 40982 4. Replacing Invariant Sections with translations requires special 40983 permission from their copyright holders, but you may include 40984 translations of some or all Invariant Sections in addition to the 40985 original versions of these Invariant Sections. You may include a 40986 translation of this License, and all the license notices in the 40987 Document, and any Warranty Disclaimers, provided that you also 40988 include the original English version of this License and the 40989 original versions of those notices and disclaimers. In case of a 40990 disagreement between the translation and the original version of 40991 this License or a notice or disclaimer, the original version will 40992 prevail. 40993 40994 If a section in the Document is Entitled "Acknowledgements", 40995 "Dedications", or "History", the requirement (section 4) to 40996 Preserve its Title (section 1) will typically require changing the 40997 actual title. 40998 40999 9. TERMINATION 41000 41001 You may not copy, modify, sublicense, or distribute the Document 41002 except as expressly provided under this License. Any attempt 41003 otherwise to copy, modify, sublicense, or distribute it is void, 41004 and will automatically terminate your rights under this License. 41005 41006 However, if you cease all violation of this License, then your 41007 license from a particular copyright holder is reinstated (a) 41008 provisionally, unless and until the copyright holder explicitly 41009 and finally terminates your license, and (b) permanently, if the 41010 copyright holder fails to notify you of the violation by some 41011 reasonable means prior to 60 days after the cessation. 41012 41013 Moreover, your license from a particular copyright holder is 41014 reinstated permanently if the copyright holder notifies you of the 41015 violation by some reasonable means, this is the first time you have 41016 received notice of violation of this License (for any work) from 41017 that copyright holder, and you cure the violation prior to 30 days 41018 after your receipt of the notice. 41019 41020 Termination of your rights under this section does not terminate 41021 the licenses of parties who have received copies or rights from 41022 you under this License. If your rights have been terminated and 41023 not permanently reinstated, receipt of a copy of some or all of 41024 the same material does not give you any rights to use it. 41025 41026 10. FUTURE REVISIONS OF THIS LICENSE 41027 41028 The Free Software Foundation may publish new, revised versions of 41029 the GNU Free Documentation License from time to time. Such new 41030 versions will be similar in spirit to the present version, but may 41031 differ in detail to address new problems or concerns. See 41032 `http://www.gnu.org/copyleft/'. 41033 41034 Each version of the License is given a distinguishing version 41035 number. If the Document specifies that a particular numbered 41036 version of this License "or any later version" applies to it, you 41037 have the option of following the terms and conditions either of 41038 that specified version or of any later version that has been 41039 published (not as a draft) by the Free Software Foundation. If 41040 the Document does not specify a version number of this License, 41041 you may choose any version ever published (not as a draft) by the 41042 Free Software Foundation. If the Document specifies that a proxy 41043 can decide which future versions of this License can be used, that 41044 proxy's public statement of acceptance of a version permanently 41045 authorizes you to choose that version for the Document. 41046 41047 11. RELICENSING 41048 41049 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 41050 World Wide Web server that publishes copyrightable works and also 41051 provides prominent facilities for anybody to edit those works. A 41052 public wiki that anybody can edit is an example of such a server. 41053 A "Massive Multiauthor Collaboration" (or "MMC") contained in the 41054 site means any set of copyrightable works thus published on the MMC 41055 site. 41056 41057 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 41058 license published by Creative Commons Corporation, a not-for-profit 41059 corporation with a principal place of business in San Francisco, 41060 California, as well as future copyleft versions of that license 41061 published by that same organization. 41062 41063 "Incorporate" means to publish or republish a Document, in whole or 41064 in part, as part of another Document. 41065 41066 An MMC is "eligible for relicensing" if it is licensed under this 41067 License, and if all works that were first published under this 41068 License somewhere other than this MMC, and subsequently 41069 incorporated in whole or in part into the MMC, (1) had no cover 41070 texts or invariant sections, and (2) were thus incorporated prior 41071 to November 1, 2008. 41072 41073 The operator of an MMC Site may republish an MMC contained in the 41074 site under CC-BY-SA on the same site at any time before August 1, 41075 2009, provided the MMC is eligible for relicensing. 41076 41077 41078 ADDENDUM: How to use this License for your documents 41079 ==================================================== 41080 41081 To use this License in a document you have written, include a copy of 41082 the License in the document and put the following copyright and license 41083 notices just after the title page: 41084 41085 Copyright (C) YEAR YOUR NAME. 41086 Permission is granted to copy, distribute and/or modify this document 41087 under the terms of the GNU Free Documentation License, Version 1.3 41088 or any later version published by the Free Software Foundation; 41089 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 41090 Texts. A copy of the license is included in the section entitled ``GNU 41091 Free Documentation License''. 41092 41093 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 41094 replace the "with...Texts." line with this: 41095 41096 with the Invariant Sections being LIST THEIR TITLES, with 41097 the Front-Cover Texts being LIST, and with the Back-Cover Texts 41098 being LIST. 41099 41100 If you have Invariant Sections without Cover Texts, or some other 41101 combination of the three, merge those two alternatives to suit the 41102 situation. 41103 41104 If your document contains nontrivial examples of program code, we 41105 recommend releasing these examples in parallel under your choice of 41106 free software license, such as the GNU General Public License, to 41107 permit their use in free software. 41108 41109 41110 File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 41111 41112 Contributors to GCC 41113 ******************* 41114 41115 The GCC project would like to thank its many contributors. Without 41116 them the project would not have been nearly as successful as it has 41117 been. Any omissions in this list are accidental. Feel free to contact 41118 <law (a] redhat.com> or <gerald (a] pfeifer.com> if you have been left out or 41119 some of your contributions are not listed. Please keep this list in 41120 alphabetical order. 41121 41122 * Analog Devices helped implement the support for complex data types 41123 and iterators. 41124 41125 * John David Anglin for threading-related fixes and improvements to 41126 libstdc++-v3, and the HP-UX port. 41127 41128 * James van Artsdalen wrote the code that makes efficient use of the 41129 Intel 80387 register stack. 41130 41131 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 41132 Series port. 41133 41134 * Alasdair Baird for various bug fixes. 41135 41136 * Giovanni Bajo for analyzing lots of complicated C++ problem 41137 reports. 41138 41139 * Peter Barada for his work to improve code generation for new 41140 ColdFire cores. 41141 41142 * Gerald Baumgartner added the signature extension to the C++ front 41143 end. 41144 41145 * Godmar Back for his Java improvements and encouragement. 41146 41147 * Scott Bambrough for help porting the Java compiler. 41148 41149 * Wolfgang Bangerth for processing tons of bug reports. 41150 41151 * Jon Beniston for his Microsoft Windows port of Java and port to 41152 Lattice Mico32. 41153 41154 * Daniel Berlin for better DWARF2 support, faster/better 41155 optimizations, improved alias analysis, plus migrating GCC to 41156 Bugzilla. 41157 41158 * Geoff Berry for his Java object serialization work and various 41159 patches. 41160 41161 * David Binderman tests weekly snapshots of GCC trunk against Fedora 41162 Rawhide for several architectures. 41163 41164 * Uros Bizjak for the implementation of x87 math built-in functions 41165 and for various middle end and i386 back end improvements and bug 41166 fixes. 41167 41168 * Eric Blake for helping to make GCJ and libgcj conform to the 41169 specifications. 41170 41171 * Janne Blomqvist for contributions to GNU Fortran. 41172 41173 * Segher Boessenkool for various fixes. 41174 41175 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 41176 other Java work. 41177 41178 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 41179 miscellaneous clean-ups. 41180 41181 * Steven Bosscher for integrating the GNU Fortran front end into GCC 41182 and for contributing to the tree-ssa branch. 41183 41184 * Eric Botcazou for fixing middle- and backend bugs left and right. 41185 41186 * Per Bothner for his direction via the steering committee and 41187 various improvements to the infrastructure for supporting new 41188 languages. Chill front end implementation. Initial 41189 implementations of cpplib, fix-header, config.guess, libio, and 41190 past C++ library (libg++) maintainer. Dreaming up, designing and 41191 implementing much of GCJ. 41192 41193 * Devon Bowen helped port GCC to the Tahoe. 41194 41195 * Don Bowman for mips-vxworks contributions. 41196 41197 * Dave Brolley for work on cpplib and Chill. 41198 41199 * Paul Brook for work on the ARM architecture and maintaining GNU 41200 Fortran. 41201 41202 * Robert Brown implemented the support for Encore 32000 systems. 41203 41204 * Christian Bruel for improvements to local store elimination. 41205 41206 * Herman A.J. ten Brugge for various fixes. 41207 41208 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 41209 FAQ. 41210 41211 * Joe Buck for his direction via the steering committee. 41212 41213 * Craig Burley for leadership of the G77 Fortran effort. 41214 41215 * Stephan Buys for contributing Doxygen notes for libstdc++. 41216 41217 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 41218 to the C++ strings, streambufs and formatted I/O, hard detective 41219 work on the frustrating localization issues, and keeping up with 41220 the problem reports. 41221 41222 * John Carr for his alias work, SPARC hacking, infrastructure 41223 improvements, previous contributions to the steering committee, 41224 loop optimizations, etc. 41225 41226 * Stephane Carrez for 68HC11 and 68HC12 ports. 41227 41228 * Steve Chamberlain for support for the Renesas SH and H8 processors 41229 and the PicoJava processor, and for GCJ config fixes. 41230 41231 * Glenn Chambers for help with the GCJ FAQ. 41232 41233 * John-Marc Chandonia for various libgcj patches. 41234 41235 * Denis Chertykov for contributing and maintaining the AVR port, the 41236 first GCC port for an 8-bit architecture. 41237 41238 * Scott Christley for his Objective-C contributions. 41239 41240 * Eric Christopher for his Java porting help and clean-ups. 41241 41242 * Branko Cibej for more warning contributions. 41243 41244 * The GNU Classpath project for all of their merged runtime code. 41245 41246 * Nick Clifton for arm, mcore, fr30, v850, m32r, rx work, `--help', 41247 and other random hacking. 41248 41249 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 41250 41251 * R. Kelley Cook for making GCC buildable from a read-only directory 41252 as well as other miscellaneous build process and documentation 41253 clean-ups. 41254 41255 * Ralf Corsepius for SH testing and minor bug fixing. 41256 41257 * Stan Cox for care and feeding of the x86 port and lots of behind 41258 the scenes hacking. 41259 41260 * Alex Crain provided changes for the 3b1. 41261 41262 * Ian Dall for major improvements to the NS32k port. 41263 41264 * Paul Dale for his work to add uClinux platform support to the m68k 41265 backend. 41266 41267 * Dario Dariol contributed the four varieties of sample programs 41268 that print a copy of their source. 41269 41270 * Russell Davidson for fstream and stringstream fixes in libstdc++. 41271 41272 * Bud Davis for work on the G77 and GNU Fortran compilers. 41273 41274 * Mo DeJong for GCJ and libgcj bug fixes. 41275 41276 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 41277 various bug fixes, and the M32C, MeP, and RL78 ports. 41278 41279 * Arnaud Desitter for helping to debug GNU Fortran. 41280 41281 * Gabriel Dos Reis for contributions to G++, contributions and 41282 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 41283 including `valarray<>', `complex<>', maintaining the numerics 41284 library (including that pesky `<limits>' :-) and keeping 41285 up-to-date anything to do with numbers. 41286 41287 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 41288 ISO C99 support, CFG dumping support, etc., plus support of the 41289 C++ runtime libraries including for all kinds of C interface 41290 issues, contributing and maintaining `complex<>', sanity checking 41291 and disbursement, configuration architecture, libio maintenance, 41292 and early math work. 41293 41294 * Zdenek Dvorak for a new loop unroller and various fixes. 41295 41296 * Michael Eager for his work on the Xilinx MicroBlaze port. 41297 41298 * Richard Earnshaw for his ongoing work with the ARM. 41299 41300 * David Edelsohn for his direction via the steering committee, 41301 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 41302 loop changes, doing the entire AIX port of libstdc++ with his bare 41303 hands, and for ensuring GCC properly keeps working on AIX. 41304 41305 * Kevin Ediger for the floating point formatting of num_put::do_put 41306 in libstdc++. 41307 41308 * Phil Edwards for libstdc++ work including configuration hackery, 41309 documentation maintainer, chief breaker of the web pages, the 41310 occasional iostream bug fix, and work on shared library symbol 41311 versioning. 41312 41313 * Paul Eggert for random hacking all over GCC. 41314 41315 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 41316 configuration support for locales and fstream-related fixes. 41317 41318 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 41319 iostreams. 41320 41321 * Christian Ehrhardt for dealing with bug reports. 41322 41323 * Ben Elliston for his work to move the Objective-C runtime into its 41324 own subdirectory and for his work on autoconf. 41325 41326 * Revital Eres for work on the PowerPC 750CL port. 41327 41328 * Marc Espie for OpenBSD support. 41329 41330 * Doug Evans for much of the global optimization framework, arc, 41331 m32r, and SPARC work. 41332 41333 * Christopher Faylor for his work on the Cygwin port and for caring 41334 and feeding the gcc.gnu.org box and saving its users tons of spam. 41335 41336 * Fred Fish for BeOS support and Ada fixes. 41337 41338 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 41339 41340 * Peter Gerwinski for various bug fixes and the Pascal front end. 41341 41342 * Kaveh R. Ghazi for his direction via the steering committee, 41343 amazing work to make `-W -Wall -W* -Werror' useful, and testing 41344 GCC on a plethora of platforms. Kaveh extends his gratitude to 41345 the CAIP Center at Rutgers University for providing him with 41346 computing resources to work on Free Software from the late 1980s 41347 to 2010. 41348 41349 * John Gilmore for a donation to the FSF earmarked improving GNU 41350 Java. 41351 41352 * Judy Goldberg for c++ contributions. 41353 41354 * Torbjorn Granlund for various fixes and the c-torture testsuite, 41355 multiply- and divide-by-constant optimization, improved long long 41356 support, improved leaf function register allocation, and his 41357 direction via the steering committee. 41358 41359 * Anthony Green for his `-Os' contributions, the moxie port, and 41360 Java front end work. 41361 41362 * Stu Grossman for gdb hacking, allowing GCJ developers to debug 41363 Java code. 41364 41365 * Michael K. Gschwind contributed the port to the PDP-11. 41366 41367 * Richard Guenther for his ongoing middle-end contributions and bug 41368 fixes and for release management. 41369 41370 * Ron Guilmette implemented the `protoize' and `unprotoize' tools, 41371 the support for Dwarf symbolic debugging information, and much of 41372 the support for System V Release 4. He has also worked heavily on 41373 the Intel 386 and 860 support. 41374 41375 * Sumanth Gundapaneni for contributing the CR16 port. 41376 41377 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 41378 GCSE. 41379 41380 * Bruno Haible for improvements in the runtime overhead for EH, new 41381 warnings and assorted bug fixes. 41382 41383 * Andrew Haley for his amazing Java compiler and library efforts. 41384 41385 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 41386 series 300. 41387 41388 * Michael Hayes for various thankless work he's done trying to get 41389 the c30/c40 ports functional. Lots of loop and unroll 41390 improvements and fixes. 41391 41392 * Dara Hazeghi for wading through myriads of target-specific bug 41393 reports. 41394 41395 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 41396 41397 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 41398 work, loop opts, and generally fixing lots of old problems we've 41399 ignored for years, flow rewrite and lots of further stuff, 41400 including reviewing tons of patches. 41401 41402 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 41403 various fixes. 41404 41405 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 41406 contributed the support for the Sony NEWS machine. 41407 41408 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 41409 various fixes. 41410 41411 * Katherine Holcomb for work on GNU Fortran. 41412 41413 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 41414 of testing and bug fixing, particularly of GCC configury code. 41415 41416 * Steve Holmgren for MachTen patches. 41417 41418 * Mat Hostetter for work on the TILE-Gx and TILEPro ports. 41419 41420 * Jan Hubicka for his x86 port improvements. 41421 41422 * Falk Hueffner for working on C and optimization bug reports. 41423 41424 * Bernardo Innocenti for his m68k work, including merging of 41425 ColdFire improvements and uClinux support. 41426 41427 * Christian Iseli for various bug fixes. 41428 41429 * Kamil Iskra for general m68k hacking. 41430 41431 * Lee Iverson for random fixes and MIPS testing. 41432 41433 * Andreas Jaeger for testing and benchmarking of GCC and various bug 41434 fixes. 41435 41436 * Jakub Jelinek for his SPARC work and sibling call optimizations as 41437 well as lots of bug fixes and test cases, and for improving the 41438 Java build system. 41439 41440 * Janis Johnson for ia64 testing and fixes, her quality improvement 41441 sidetracks, and web page maintenance. 41442 41443 * Kean Johnston for SCO OpenServer support and various fixes. 41444 41445 * Tim Josling for the sample language treelang based originally on 41446 Richard Kenner's "toy" language. 41447 41448 * Nicolai Josuttis for additional libstdc++ documentation. 41449 41450 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 41451 target. 41452 41453 * Steven G. Kargl for work on GNU Fortran. 41454 41455 * David Kashtan of SRI adapted GCC to VMS. 41456 41457 * Ryszard Kabatek for many, many libstdc++ bug fixes and 41458 optimizations of strings, especially member functions, and for 41459 auto_ptr fixes. 41460 41461 * Geoffrey Keating for his ongoing work to make the PPC work for 41462 GNU/Linux and his automatic regression tester. 41463 41464 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 41465 work in just about every part of libstdc++. 41466 41467 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 41468 MIL-STD-1750A. 41469 41470 * Richard Kenner of the New York University Ultracomputer Research 41471 Laboratory wrote the machine descriptions for the AMD 29000, the 41472 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 41473 support for instruction attributes. He also made changes to 41474 better support RISC processors including changes to common 41475 subexpression elimination, strength reduction, function calling 41476 sequence handling, and condition code support, in addition to 41477 generalizing the code for frame pointer elimination and delay slot 41478 scheduling. Richard Kenner was also the head maintainer of GCC 41479 for several years. 41480 41481 * Mumit Khan for various contributions to the Cygwin and Mingw32 41482 ports and maintaining binary releases for Microsoft Windows hosts, 41483 and for massive libstdc++ porting work to Cygwin/Mingw32. 41484 41485 * Robin Kirkham for cpu32 support. 41486 41487 * Mark Klein for PA improvements. 41488 41489 * Thomas Koenig for various bug fixes. 41490 41491 * Bruce Korb for the new and improved fixincludes code. 41492 41493 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 41494 effort. 41495 41496 * Charles LaBrec contributed the support for the Integrated Solutions 41497 68020 system. 41498 41499 * Asher Langton and Mike Kumbera for contributing Cray pointer 41500 support to GNU Fortran, and for other GNU Fortran improvements. 41501 41502 * Jeff Law for his direction via the steering committee, 41503 coordinating the entire egcs project and GCC 2.95, rolling out 41504 snapshots and releases, handling merges from GCC2, reviewing tons 41505 of patches that might have fallen through the cracks else, and 41506 random but extensive hacking. 41507 41508 * Walter Lee for work on the TILE-Gx and TILEPro ports. 41509 41510 * Marc Lehmann for his direction via the steering committee and 41511 helping with analysis and improvements of x86 performance. 41512 41513 * Victor Leikehman for work on GNU Fortran. 41514 41515 * Ted Lemon wrote parts of the RTL reader and printer. 41516 41517 * Kriang Lerdsuwanakij for C++ improvements including template as 41518 template parameter support, and many C++ fixes. 41519 41520 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 41521 and random work on the Java front end. 41522 41523 * Alain Lichnewsky ported GCC to the MIPS CPU. 41524 41525 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 41526 and patches. 41527 41528 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 41529 41530 * Chen Liqin for various S+core related fixes/improvement, and for 41531 maintaining the S+core port. 41532 41533 * Weiwen Liu for testing and various bug fixes. 41534 41535 * Manuel Lo'pez-Iba'n~ez for improving `-Wconversion' and many other 41536 diagnostics fixes and improvements. 41537 41538 * Dave Love for his ongoing work with the Fortran front end and 41539 runtime libraries. 41540 41541 * Martin von Lo"wis for internal consistency checking infrastructure, 41542 various C++ improvements including namespace support, and tons of 41543 assistance with libstdc++/compiler merges. 41544 41545 * H.J. Lu for his previous contributions to the steering committee, 41546 many x86 bug reports, prototype patches, and keeping the GNU/Linux 41547 ports working. 41548 41549 * Greg McGary for random fixes and (someday) bounded pointers. 41550 41551 * Andrew MacLeod for his ongoing work in building a real EH system, 41552 various code generation improvements, work on the global 41553 optimizer, etc. 41554 41555 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 41556 hacking improvements to compile-time performance, overall 41557 knowledge and direction in the area of instruction scheduling, and 41558 design and implementation of the automaton based instruction 41559 scheduler. 41560 41561 * Bob Manson for his behind the scenes work on dejagnu. 41562 41563 * Philip Martin for lots of libstdc++ string and vector iterator 41564 fixes and improvements, and string clean up and testsuites. 41565 41566 * All of the Mauve project contributors, for Java test code. 41567 41568 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 41569 41570 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 41571 41572 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 41573 powerpc, haifa, ECOFF debug support, and other assorted hacking. 41574 41575 * Jason Merrill for his direction via the steering committee and 41576 leading the G++ effort. 41577 41578 * Martin Michlmayr for testing GCC on several architectures using the 41579 entire Debian archive. 41580 41581 * David Miller for his direction via the steering committee, lots of 41582 SPARC work, improvements in jump.c and interfacing with the Linux 41583 kernel developers. 41584 41585 * Gary Miller ported GCC to Charles River Data Systems machines. 41586 41587 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 41588 the entire libstdc++ testsuite namespace-compatible. 41589 41590 * Mark Mitchell for his direction via the steering committee, 41591 mountains of C++ work, load/store hoisting out of loops, alias 41592 analysis improvements, ISO C `restrict' support, and serving as 41593 release manager from 2000 to 2011. 41594 41595 * Alan Modra for various GNU/Linux bits and testing. 41596 41597 * Toon Moene for his direction via the steering committee, Fortran 41598 maintenance, and his ongoing work to make us make Fortran run fast. 41599 41600 * Jason Molenda for major help in the care and feeding of all the 41601 services on the gcc.gnu.org (formerly egcs.cygnus.com) 41602 machine--mail, web services, ftp services, etc etc. Doing all 41603 this work on scrap paper and the backs of envelopes would have 41604 been... difficult. 41605 41606 * Catherine Moore for fixing various ugly problems we have sent her 41607 way, including the haifa bug which was killing the Alpha & PowerPC 41608 Linux kernels. 41609 41610 * Mike Moreton for his various Java patches. 41611 41612 * David Mosberger-Tang for various Alpha improvements, and for the 41613 initial IA-64 port. 41614 41615 * Stephen Moshier contributed the floating point emulator that 41616 assists in cross-compilation and permits support for floating 41617 point numbers wider than 64 bits and for ISO C99 support. 41618 41619 * Bill Moyer for his behind the scenes work on various issues. 41620 41621 * Philippe De Muyter for his work on the m68k port. 41622 41623 * Joseph S. Myers for his work on the PDP-11 port, format checking 41624 and ISO C99 support, and continuous emphasis on (and contributions 41625 to) documentation. 41626 41627 * Nathan Myers for his work on libstdc++-v3: architecture and 41628 authorship through the first three snapshots, including 41629 implementation of locale infrastructure, string, shadow C headers, 41630 and the initial project documentation (DESIGN, CHECKLIST, and so 41631 forth). Later, more work on MT-safe string and shadow headers. 41632 41633 * Felix Natter for documentation on porting libstdc++. 41634 41635 * Nathanael Nerode for cleaning up the configuration/build process. 41636 41637 * NeXT, Inc. donated the front end that supports the Objective-C 41638 language. 41639 41640 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to 41641 the search engine setup, various documentation fixes and other 41642 small fixes. 41643 41644 * Geoff Noer for his work on getting cygwin native builds working. 41645 41646 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 41647 tracking web pages, GIMPLE tuples, and assorted fixes. 41648 41649 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 41650 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and 41651 related infrastructure improvements. 41652 41653 * Alexandre Oliva for various build infrastructure improvements, 41654 scripts and amazing testing work, including keeping libtool issues 41655 sane and happy. 41656 41657 * Stefan Olsson for work on mt_alloc. 41658 41659 * Melissa O'Neill for various NeXT fixes. 41660 41661 * Rainer Orth for random MIPS work, including improvements to GCC's 41662 o32 ABI support, improvements to dejagnu's MIPS support, Java 41663 configuration clean-ups and porting work, and maintaining the 41664 IRIX, Solaris 2, and Tru64 UNIX ports. 41665 41666 * Hartmut Penner for work on the s390 port. 41667 41668 * Paul Petersen wrote the machine description for the Alliant FX/8. 41669 41670 * Alexandre Petit-Bianco for implementing much of the Java compiler 41671 and continued Java maintainership. 41672 41673 * Matthias Pfaller for major improvements to the NS32k port. 41674 41675 * Gerald Pfeifer for his direction via the steering committee, 41676 pointing out lots of problems we need to solve, maintenance of the 41677 web pages, and taking care of documentation maintenance in general. 41678 41679 * Andrew Pinski for processing bug reports by the dozen. 41680 41681 * Ovidiu Predescu for his work on the Objective-C front end and 41682 runtime libraries. 41683 41684 * Jerry Quinn for major performance improvements in C++ formatted 41685 I/O. 41686 41687 * Ken Raeburn for various improvements to checker, MIPS ports and 41688 various cleanups in the compiler. 41689 41690 * Rolf W. Rasmussen for hacking on AWT. 41691 41692 * David Reese of Sun Microsystems contributed to the Solaris on 41693 PowerPC port. 41694 41695 * Volker Reichelt for keeping up with the problem reports. 41696 41697 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 41698 hacking and developing and maintaining the Epiphany port. 41699 41700 * Loren J. Rittle for improvements to libstdc++-v3 including the 41701 FreeBSD port, threading fixes, thread-related configury changes, 41702 critical threading documentation, and solutions to really tricky 41703 I/O problems, as well as keeping GCC properly working on FreeBSD 41704 and continuous testing. 41705 41706 * Craig Rodrigues for processing tons of bug reports. 41707 41708 * Ola Ro"nnerup for work on mt_alloc. 41709 41710 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 41711 41712 * David Ronis inspired and encouraged Craig to rewrite the G77 41713 documentation in texinfo format by contributing a first pass at a 41714 translation of the old `g77-0.5.16/f/DOC' file. 41715 41716 * Ken Rose for fixes to GCC's delay slot filling code. 41717 41718 * Paul Rubin wrote most of the preprocessor. 41719 41720 * Pe'tur Runo'lfsson for major performance improvements in C++ 41721 formatted I/O and large file support in C++ filebuf. 41722 41723 * Chip Salzenberg for libstdc++ patches and improvements to locales, 41724 traits, Makefiles, libio, libtool hackery, and "long long" support. 41725 41726 * Juha Sarlin for improvements to the H8 code generator. 41727 41728 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 41729 300. 41730 41731 * Roger Sayle for improvements to constant folding and GCC's RTL 41732 optimizers as well as for fixing numerous bugs. 41733 41734 * Bradley Schatz for his work on the GCJ FAQ. 41735 41736 * Peter Schauer wrote the code to allow debugging to work on the 41737 Alpha. 41738 41739 * William Schelter did most of the work on the Intel 80386 support. 41740 41741 * Tobias Schlu"ter for work on GNU Fortran. 41742 41743 * Bernd Schmidt for various code generation improvements and major 41744 work in the reload pass, serving as release manager for GCC 41745 2.95.3, and work on the Blackfin and C6X ports. 41746 41747 * Peter Schmid for constant testing of libstdc++--especially 41748 application testing, going above and beyond what was requested for 41749 the release criteria--and libstdc++ header file tweaks. 41750 41751 * Jason Schroeder for jcf-dump patches. 41752 41753 * Andreas Schwab for his work on the m68k port. 41754 41755 * Lars Segerlund for work on GNU Fortran. 41756 41757 * Dodji Seketeli for numerous C++ bug fixes and debug info 41758 improvements. 41759 41760 * Joel Sherrill for his direction via the steering committee, RTEMS 41761 contributions and RTEMS testing. 41762 41763 * Nathan Sidwell for many C++ fixes/improvements. 41764 41765 * Jeffrey Siegal for helping RMS with the original design of GCC, 41766 some code which handles the parse tree and RTL data structures, 41767 constant folding and help with the original VAX & m68k ports. 41768 41769 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 41770 from the LWG (thereby keeping GCC in line with updates from the 41771 ISO). 41772 41773 * Franz Sirl for his ongoing work with making the PPC port stable 41774 for GNU/Linux. 41775 41776 * Andrey Slepuhin for assorted AIX hacking. 41777 41778 * Trevor Smigiel for contributing the SPU port. 41779 41780 * Christopher Smith did the port for Convex machines. 41781 41782 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 41783 41784 * Randy Smith finished the Sun FPA support. 41785 41786 * Scott Snyder for queue, iterator, istream, and string fixes and 41787 libstdc++ testsuite entries. Also for providing the patch to G77 41788 to add rudimentary support for `INTEGER*1', `INTEGER*2', and 41789 `LOGICAL*1'. 41790 41791 * Zdenek Sojka for running automated regression testing of GCC and 41792 reporting numerous bugs. 41793 41794 * Jayant Sonar for contributing the CR16 port. 41795 41796 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 41797 41798 * Richard Stallman, for writing the original GCC and launching the 41799 GNU project. 41800 41801 * Jan Stein of the Chalmers Computer Society provided support for 41802 Genix, as well as part of the 32000 machine description. 41803 41804 * Nigel Stephens for various mips16 related fixes/improvements. 41805 41806 * Jonathan Stone wrote the machine description for the Pyramid 41807 computer. 41808 41809 * Graham Stott for various infrastructure improvements. 41810 41811 * John Stracke for his Java HTTP protocol fixes. 41812 41813 * Mike Stump for his Elxsi port, G++ contributions over the years 41814 and more recently his vxworks contributions 41815 41816 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 41817 41818 * Shigeya Suzuki for this fixes for the bsdi platforms. 41819 41820 * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64 41821 support, general configury hacking, fixincludes, etc. 41822 41823 * Holger Teutsch provided the support for the Clipper CPU. 41824 41825 * Gary Thomas for his ongoing work to make the PPC work for 41826 GNU/Linux. 41827 41828 * Philipp Thomas for random bug fixes throughout the compiler 41829 41830 * Jason Thorpe for thread support in libstdc++ on NetBSD. 41831 41832 * Kresten Krab Thorup wrote the run time support for the Objective-C 41833 language and the fantastic Java bytecode interpreter. 41834 41835 * Michael Tiemann for random bug fixes, the first instruction 41836 scheduler, initial C++ support, function integration, NS32k, SPARC 41837 and M88k machine description work, delay slot scheduling. 41838 41839 * Andreas Tobler for his work porting libgcj to Darwin. 41840 41841 * Teemu Torma for thread safe exception handling support. 41842 41843 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 41844 definitions, and of the VAX machine description. 41845 41846 * Daniel Towner and Hariharan Sandanagobalane contributed and 41847 maintain the picoChip port. 41848 41849 * Tom Tromey for internationalization support and for his many Java 41850 contributions and libgcj maintainership. 41851 41852 * Lassi Tuura for improvements to config.guess to determine HP 41853 processor types. 41854 41855 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 41856 41857 * Andy Vaught for the design and initial implementation of the GNU 41858 Fortran front end. 41859 41860 * Brent Verner for work with the libstdc++ cshadow files and their 41861 associated configure steps. 41862 41863 * Todd Vierling for contributions for NetBSD ports. 41864 41865 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 41866 guidance. 41867 41868 * Dean Wakerley for converting the install documentation from HTML 41869 to texinfo in time for GCC 3.0. 41870 41871 * Krister Walfridsson for random bug fixes. 41872 41873 * Feng Wang for contributions to GNU Fortran. 41874 41875 * Stephen M. Webb for time and effort on making libstdc++ shadow 41876 files work with the tricky Solaris 8+ headers, and for pushing the 41877 build-time header tree. 41878 41879 * John Wehle for various improvements for the x86 code generator, 41880 related infrastructure improvements to help x86 code generation, 41881 value range propagation and other work, WE32k port. 41882 41883 * Ulrich Weigand for work on the s390 port. 41884 41885 * Zack Weinberg for major work on cpplib and various other bug fixes. 41886 41887 * Matt Welsh for help with Linux Threads support in GCJ. 41888 41889 * Urban Widmark for help fixing java.io. 41890 41891 * Mark Wielaard for new Java library code and his work integrating 41892 with Classpath. 41893 41894 * Dale Wiles helped port GCC to the Tahoe. 41895 41896 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 41897 41898 * Jim Wilson for his direction via the steering committee, tackling 41899 hard problems in various places that nobody else wanted to work 41900 on, strength reduction and other loop optimizations. 41901 41902 * Paul Woegerer and Tal Agmon for the CRX port. 41903 41904 * Carlo Wood for various fixes. 41905 41906 * Tom Wood for work on the m88k port. 41907 41908 * Canqun Yang for work on GNU Fortran. 41909 41910 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 41911 description for the Tron architecture (specifically, the Gmicro). 41912 41913 * Kevin Zachmann helped port GCC to the Tahoe. 41914 41915 * Ayal Zaks for Swing Modulo Scheduling (SMS). 41916 41917 * Xiaoqiang Zhang for work on GNU Fortran. 41918 41919 * Gilles Zunino for help porting Java to Irix. 41920 41921 41922 The following people are recognized for their contributions to GNAT, 41923 the Ada front end of GCC: 41924 * Bernard Banner 41925 41926 * Romain Berrendonner 41927 41928 * Geert Bosch 41929 41930 * Emmanuel Briot 41931 41932 * Joel Brobecker 41933 41934 * Ben Brosgol 41935 41936 * Vincent Celier 41937 41938 * Arnaud Charlet 41939 41940 * Chien Chieng 41941 41942 * Cyrille Comar 41943 41944 * Cyrille Crozes 41945 41946 * Robert Dewar 41947 41948 * Gary Dismukes 41949 41950 * Robert Duff 41951 41952 * Ed Falis 41953 41954 * Ramon Fernandez 41955 41956 * Sam Figueroa 41957 41958 * Vasiliy Fofanov 41959 41960 * Michael Friess 41961 41962 * Franco Gasperoni 41963 41964 * Ted Giering 41965 41966 * Matthew Gingell 41967 41968 * Laurent Guerby 41969 41970 * Jerome Guitton 41971 41972 * Olivier Hainque 41973 41974 * Jerome Hugues 41975 41976 * Hristian Kirtchev 41977 41978 * Jerome Lambourg 41979 41980 * Bruno Leclerc 41981 41982 * Albert Lee 41983 41984 * Sean McNeil 41985 41986 * Javier Miranda 41987 41988 * Laurent Nana 41989 41990 * Pascal Obry 41991 41992 * Dong-Ik Oh 41993 41994 * Laurent Pautet 41995 41996 * Brett Porter 41997 41998 * Thomas Quinot 41999 42000 * Nicolas Roche 42001 42002 * Pat Rogers 42003 42004 * Jose Ruiz 42005 42006 * Douglas Rupp 42007 42008 * Sergey Rybin 42009 42010 * Gail Schenker 42011 42012 * Ed Schonberg 42013 42014 * Nicolas Setton 42015 42016 * Samuel Tardieu 42017 42018 42019 The following people are recognized for their contributions of new 42020 features, bug reports, testing and integration of classpath/libgcj for 42021 GCC version 4.1: 42022 * Lillian Angel for `JTree' implementation and lots Free Swing 42023 additions and bug fixes. 42024 42025 * Wolfgang Baer for `GapContent' bug fixes. 42026 42027 * Anthony Balkissoon for `JList', Free Swing 1.5 updates and mouse 42028 event fixes, lots of Free Swing work including `JTable' editing. 42029 42030 * Stuart Ballard for RMI constant fixes. 42031 42032 * Goffredo Baroncelli for `HTTPURLConnection' fixes. 42033 42034 * Gary Benson for `MessageFormat' fixes. 42035 42036 * Daniel Bonniot for `Serialization' fixes. 42037 42038 * Chris Burdess for lots of gnu.xml and http protocol fixes, `StAX' 42039 and `DOM xml:id' support. 42040 42041 * Ka-Hing Cheung for `TreePath' and `TreeSelection' fixes. 42042 42043 * Archie Cobbs for build fixes, VM interface updates, 42044 `URLClassLoader' updates. 42045 42046 * Kelley Cook for build fixes. 42047 42048 * Martin Cordova for Suggestions for better `SocketTimeoutException'. 42049 42050 * David Daney for `BitSet' bug fixes, `HttpURLConnection' rewrite 42051 and improvements. 42052 42053 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 42054 2D support. Lots of imageio framework additions, lots of AWT and 42055 Free Swing bug fixes. 42056 42057 * Jeroen Frijters for `ClassLoader' and nio cleanups, serialization 42058 fixes, better `Proxy' support, bug fixes and IKVM integration. 42059 42060 * Santiago Gala for `AccessControlContext' fixes. 42061 42062 * Nicolas Geoffray for `VMClassLoader' and `AccessController' 42063 improvements. 42064 42065 * David Gilbert for `basic' and `metal' icon and plaf support and 42066 lots of documenting, Lots of Free Swing and metal theme additions. 42067 `MetalIconFactory' implementation. 42068 42069 * Anthony Green for `MIDI' framework, `ALSA' and `DSSI' providers. 42070 42071 * Andrew Haley for `Serialization' and `URLClassLoader' fixes, gcj 42072 build speedups. 42073 42074 * Kim Ho for `JFileChooser' implementation. 42075 42076 * Andrew John Hughes for `Locale' and net fixes, URI RFC2986 42077 updates, `Serialization' fixes, `Properties' XML support and 42078 generic branch work, VMIntegration guide update. 42079 42080 * Bastiaan Huisman for `TimeZone' bug fixing. 42081 42082 * Andreas Jaeger for mprec updates. 42083 42084 * Paul Jenner for better `-Werror' support. 42085 42086 * Ito Kazumitsu for `NetworkInterface' implementation and updates. 42087 42088 * Roman Kennke for `BoxLayout', `GrayFilter' and `SplitPane', plus 42089 bug fixes all over. Lots of Free Swing work including styled text. 42090 42091 * Simon Kitching for `String' cleanups and optimization suggestions. 42092 42093 * Michael Koch for configuration fixes, `Locale' updates, bug and 42094 build fixes. 42095 42096 * Guilhem Lavaux for configuration, thread and channel fixes and 42097 Kaffe integration. JCL native `Pointer' updates. Logger bug fixes. 42098 42099 * David Lichteblau for JCL support library global/local reference 42100 cleanups. 42101 42102 * Aaron Luchko for JDWP updates and documentation fixes. 42103 42104 * Ziga Mahkovec for `Graphics2D' upgraded to Cairo 0.5 and new regex 42105 features. 42106 42107 * Sven de Marothy for BMP imageio support, CSS and `TextLayout' 42108 fixes. `GtkImage' rewrite, 2D, awt, free swing and date/time fixes 42109 and implementing the Qt4 peers. 42110 42111 * Casey Marshall for crypto algorithm fixes, `FileChannel' lock, 42112 `SystemLogger' and `FileHandler' rotate implementations, NIO 42113 `FileChannel.map' support, security and policy updates. 42114 42115 * Bryce McKinlay for RMI work. 42116 42117 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 42118 testing and documenting. 42119 42120 * Kalle Olavi Niemitalo for build fixes. 42121 42122 * Rainer Orth for build fixes. 42123 42124 * Andrew Overholt for `File' locking fixes. 42125 42126 * Ingo Proetel for `Image', `Logger' and `URLClassLoader' updates. 42127 42128 * Olga Rodimina for `MenuSelectionManager' implementation. 42129 42130 * Jan Roehrich for `BasicTreeUI' and `JTree' fixes. 42131 42132 * Julian Scheid for documentation updates and gjdoc support. 42133 42134 * Christian Schlichtherle for zip fixes and cleanups. 42135 42136 * Robert Schuster for documentation updates and beans fixes, 42137 `TreeNode' enumerations and `ActionCommand' and various fixes, XML 42138 and URL, AWT and Free Swing bug fixes. 42139 42140 * Keith Seitz for lots of JDWP work. 42141 42142 * Christian Thalinger for 64-bit cleanups, Configuration and VM 42143 interface fixes and `CACAO' integration, `fdlibm' updates. 42144 42145 * Gael Thomas for `VMClassLoader' boot packages support suggestions. 42146 42147 * Andreas Tobler for Darwin and Solaris testing and fixing, `Qt4' 42148 support for Darwin/OS X, `Graphics2D' support, `gtk+' updates. 42149 42150 * Dalibor Topic for better `DEBUG' support, build cleanups and Kaffe 42151 integration. `Qt4' build infrastructure, `SHA1PRNG' and 42152 `GdkPixbugDecoder' updates. 42153 42154 * Tom Tromey for Eclipse integration, generics work, lots of bug 42155 fixes and gcj integration including coordinating The Big Merge. 42156 42157 * Mark Wielaard for bug fixes, packaging and release management, 42158 `Clipboard' implementation, system call interrupts and network 42159 timeouts and `GdkPixpufDecoder' fixes. 42160 42161 42162 In addition to the above, all of which also contributed time and 42163 energy in testing GCC, we would like to thank the following for their 42164 contributions to testing: 42165 42166 * Michael Abd-El-Malek 42167 42168 * Thomas Arend 42169 42170 * Bonzo Armstrong 42171 42172 * Steven Ashe 42173 42174 * Chris Baldwin 42175 42176 * David Billinghurst 42177 42178 * Jim Blandy 42179 42180 * Stephane Bortzmeyer 42181 42182 * Horst von Brand 42183 42184 * Frank Braun 42185 42186 * Rodney Brown 42187 42188 * Sidney Cadot 42189 42190 * Bradford Castalia 42191 42192 * Robert Clark 42193 42194 * Jonathan Corbet 42195 42196 * Ralph Doncaster 42197 42198 * Richard Emberson 42199 42200 * Levente Farkas 42201 42202 * Graham Fawcett 42203 42204 * Mark Fernyhough 42205 42206 * Robert A. French 42207 42208 * Jo"rgen Freyh 42209 42210 * Mark K. Gardner 42211 42212 * Charles-Antoine Gauthier 42213 42214 * Yung Shing Gene 42215 42216 * David Gilbert 42217 42218 * Simon Gornall 42219 42220 * Fred Gray 42221 42222 * John Griffin 42223 42224 * Patrik Hagglund 42225 42226 * Phil Hargett 42227 42228 * Amancio Hasty 42229 42230 * Takafumi Hayashi 42231 42232 * Bryan W. Headley 42233 42234 * Kevin B. Hendricks 42235 42236 * Joep Jansen 42237 42238 * Christian Joensson 42239 42240 * Michel Kern 42241 42242 * David Kidd 42243 42244 * Tobias Kuipers 42245 42246 * Anand Krishnaswamy 42247 42248 * A. O. V. Le Blanc 42249 42250 * llewelly 42251 42252 * Damon Love 42253 42254 * Brad Lucier 42255 42256 * Matthias Klose 42257 42258 * Martin Knoblauch 42259 42260 * Rick Lutowski 42261 42262 * Jesse Macnish 42263 42264 * Stefan Morrell 42265 42266 * Anon A. Mous 42267 42268 * Matthias Mueller 42269 42270 * Pekka Nikander 42271 42272 * Rick Niles 42273 42274 * Jon Olson 42275 42276 * Magnus Persson 42277 42278 * Chris Pollard 42279 42280 * Richard Polton 42281 42282 * Derk Reefman 42283 42284 * David Rees 42285 42286 * Paul Reilly 42287 42288 * Tom Reilly 42289 42290 * Torsten Rueger 42291 42292 * Danny Sadinoff 42293 42294 * Marc Schifer 42295 42296 * Erik Schnetter 42297 42298 * Wayne K. Schroll 42299 42300 * David Schuler 42301 42302 * Vin Shelton 42303 42304 * Tim Souder 42305 42306 * Adam Sulmicki 42307 42308 * Bill Thorson 42309 42310 * George Talbot 42311 42312 * Pedro A. M. Vazquez 42313 42314 * Gregory Warnes 42315 42316 * Ian Watson 42317 42318 * David E. Young 42319 42320 * And many others 42321 42322 And finally we'd like to thank everyone who uses the compiler, provides 42323 feedback and generally reminds us why we're doing this work in the first 42324 place. 42325 42326 42327 File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 42328 42329 Option Index 42330 ************ 42331 42332 GCC's command line options are indexed here without any initial `-' or 42333 `--'. Where an option has both positive and negative forms (such as 42334 `-fOPTION' and `-fno-OPTION'), relevant entries in the manual are 42335 indexed under the most appropriate form; it may sometimes be useful to 42336 look up both forms. 42337 42338 [index] 42339 * Menu: 42340 42341 * fltrans: Internal flags. (line 18) 42342 * fltrans-output-list: Internal flags. (line 23) 42343 * fwpa: Internal flags. (line 9) 42344 * msoft-float: Soft float library routines. 42345 (line 6) 42346 42347 42348 File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 42349 42350 Concept Index 42351 ************* 42352 42353 [index] 42354 * Menu: 42355 42356 * ! in constraint: Multi-Alternative. (line 47) 42357 * # in constraint: Modifiers. (line 67) 42358 * # in template: Output Template. (line 66) 42359 * #pragma: Misc. (line 379) 42360 * % in constraint: Modifiers. (line 45) 42361 * % in GTY option: GTY Options. (line 18) 42362 * % in template: Output Template. (line 6) 42363 * & in constraint: Modifiers. (line 25) 42364 * (nil): RTL Objects. (line 73) 42365 * * in constraint: Modifiers. (line 72) 42366 * * in template: Output Statement. (line 29) 42367 * + in constraint: Modifiers. (line 12) 42368 * -fsection-anchors <1>: Anchored Addresses. (line 6) 42369 * -fsection-anchors: Special Accessors. (line 120) 42370 * /c in RTL dump: Flags. (line 221) 42371 * /f in RTL dump: Flags. (line 229) 42372 * /i in RTL dump: Flags. (line 274) 42373 * /j in RTL dump: Flags. (line 286) 42374 * /s in RTL dump: Flags. (line 245) 42375 * /u in RTL dump: Flags. (line 296) 42376 * /v in RTL dump: Flags. (line 328) 42377 * 0 in constraint: Simple Constraints. (line 130) 42378 * < in constraint: Simple Constraints. (line 48) 42379 * = in constraint: Modifiers. (line 8) 42380 * > in constraint: Simple Constraints. (line 61) 42381 * ? in constraint: Multi-Alternative. (line 41) 42382 * \: Output Template. (line 46) 42383 * __absvdi2: Integer library routines. 42384 (line 107) 42385 * __absvsi2: Integer library routines. 42386 (line 106) 42387 * __addda3: Fixed-point fractional library routines. 42388 (line 45) 42389 * __adddf3: Soft float library routines. 42390 (line 23) 42391 * __adddq3: Fixed-point fractional library routines. 42392 (line 33) 42393 * __addha3: Fixed-point fractional library routines. 42394 (line 43) 42395 * __addhq3: Fixed-point fractional library routines. 42396 (line 30) 42397 * __addqq3: Fixed-point fractional library routines. 42398 (line 29) 42399 * __addsa3: Fixed-point fractional library routines. 42400 (line 44) 42401 * __addsf3: Soft float library routines. 42402 (line 22) 42403 * __addsq3: Fixed-point fractional library routines. 42404 (line 31) 42405 * __addta3: Fixed-point fractional library routines. 42406 (line 47) 42407 * __addtf3: Soft float library routines. 42408 (line 25) 42409 * __adduda3: Fixed-point fractional library routines. 42410 (line 53) 42411 * __addudq3: Fixed-point fractional library routines. 42412 (line 41) 42413 * __adduha3: Fixed-point fractional library routines. 42414 (line 49) 42415 * __adduhq3: Fixed-point fractional library routines. 42416 (line 37) 42417 * __adduqq3: Fixed-point fractional library routines. 42418 (line 35) 42419 * __addusa3: Fixed-point fractional library routines. 42420 (line 51) 42421 * __addusq3: Fixed-point fractional library routines. 42422 (line 39) 42423 * __adduta3: Fixed-point fractional library routines. 42424 (line 55) 42425 * __addvdi3: Integer library routines. 42426 (line 111) 42427 * __addvsi3: Integer library routines. 42428 (line 110) 42429 * __addxf3: Soft float library routines. 42430 (line 27) 42431 * __ashlda3: Fixed-point fractional library routines. 42432 (line 351) 42433 * __ashldi3: Integer library routines. 42434 (line 14) 42435 * __ashldq3: Fixed-point fractional library routines. 42436 (line 340) 42437 * __ashlha3: Fixed-point fractional library routines. 42438 (line 349) 42439 * __ashlhq3: Fixed-point fractional library routines. 42440 (line 337) 42441 * __ashlqq3: Fixed-point fractional library routines. 42442 (line 336) 42443 * __ashlsa3: Fixed-point fractional library routines. 42444 (line 350) 42445 * __ashlsi3: Integer library routines. 42446 (line 13) 42447 * __ashlsq3: Fixed-point fractional library routines. 42448 (line 338) 42449 * __ashlta3: Fixed-point fractional library routines. 42450 (line 353) 42451 * __ashlti3: Integer library routines. 42452 (line 15) 42453 * __ashluda3: Fixed-point fractional library routines. 42454 (line 359) 42455 * __ashludq3: Fixed-point fractional library routines. 42456 (line 348) 42457 * __ashluha3: Fixed-point fractional library routines. 42458 (line 355) 42459 * __ashluhq3: Fixed-point fractional library routines. 42460 (line 344) 42461 * __ashluqq3: Fixed-point fractional library routines. 42462 (line 342) 42463 * __ashlusa3: Fixed-point fractional library routines. 42464 (line 357) 42465 * __ashlusq3: Fixed-point fractional library routines. 42466 (line 346) 42467 * __ashluta3: Fixed-point fractional library routines. 42468 (line 361) 42469 * __ashrda3: Fixed-point fractional library routines. 42470 (line 371) 42471 * __ashrdi3: Integer library routines. 42472 (line 19) 42473 * __ashrdq3: Fixed-point fractional library routines. 42474 (line 368) 42475 * __ashrha3: Fixed-point fractional library routines. 42476 (line 369) 42477 * __ashrhq3: Fixed-point fractional library routines. 42478 (line 365) 42479 * __ashrqq3: Fixed-point fractional library routines. 42480 (line 364) 42481 * __ashrsa3: Fixed-point fractional library routines. 42482 (line 370) 42483 * __ashrsi3: Integer library routines. 42484 (line 18) 42485 * __ashrsq3: Fixed-point fractional library routines. 42486 (line 366) 42487 * __ashrta3: Fixed-point fractional library routines. 42488 (line 373) 42489 * __ashrti3: Integer library routines. 42490 (line 20) 42491 * __bid_adddd3: Decimal float library routines. 42492 (line 25) 42493 * __bid_addsd3: Decimal float library routines. 42494 (line 21) 42495 * __bid_addtd3: Decimal float library routines. 42496 (line 29) 42497 * __bid_divdd3: Decimal float library routines. 42498 (line 68) 42499 * __bid_divsd3: Decimal float library routines. 42500 (line 64) 42501 * __bid_divtd3: Decimal float library routines. 42502 (line 72) 42503 * __bid_eqdd2: Decimal float library routines. 42504 (line 259) 42505 * __bid_eqsd2: Decimal float library routines. 42506 (line 257) 42507 * __bid_eqtd2: Decimal float library routines. 42508 (line 261) 42509 * __bid_extendddtd2: Decimal float library routines. 42510 (line 92) 42511 * __bid_extendddtf: Decimal float library routines. 42512 (line 140) 42513 * __bid_extendddxf: Decimal float library routines. 42514 (line 134) 42515 * __bid_extenddfdd: Decimal float library routines. 42516 (line 147) 42517 * __bid_extenddftd: Decimal float library routines. 42518 (line 107) 42519 * __bid_extendsddd2: Decimal float library routines. 42520 (line 88) 42521 * __bid_extendsddf: Decimal float library routines. 42522 (line 128) 42523 * __bid_extendsdtd2: Decimal float library routines. 42524 (line 90) 42525 * __bid_extendsdtf: Decimal float library routines. 42526 (line 138) 42527 * __bid_extendsdxf: Decimal float library routines. 42528 (line 132) 42529 * __bid_extendsfdd: Decimal float library routines. 42530 (line 103) 42531 * __bid_extendsfsd: Decimal float library routines. 42532 (line 145) 42533 * __bid_extendsftd: Decimal float library routines. 42534 (line 105) 42535 * __bid_extendtftd: Decimal float library routines. 42536 (line 149) 42537 * __bid_extendxftd: Decimal float library routines. 42538 (line 109) 42539 * __bid_fixdddi: Decimal float library routines. 42540 (line 170) 42541 * __bid_fixddsi: Decimal float library routines. 42542 (line 162) 42543 * __bid_fixsddi: Decimal float library routines. 42544 (line 168) 42545 * __bid_fixsdsi: Decimal float library routines. 42546 (line 160) 42547 * __bid_fixtddi: Decimal float library routines. 42548 (line 172) 42549 * __bid_fixtdsi: Decimal float library routines. 42550 (line 164) 42551 * __bid_fixunsdddi: Decimal float library routines. 42552 (line 187) 42553 * __bid_fixunsddsi: Decimal float library routines. 42554 (line 178) 42555 * __bid_fixunssddi: Decimal float library routines. 42556 (line 185) 42557 * __bid_fixunssdsi: Decimal float library routines. 42558 (line 176) 42559 * __bid_fixunstddi: Decimal float library routines. 42560 (line 189) 42561 * __bid_fixunstdsi: Decimal float library routines. 42562 (line 180) 42563 * __bid_floatdidd: Decimal float library routines. 42564 (line 205) 42565 * __bid_floatdisd: Decimal float library routines. 42566 (line 203) 42567 * __bid_floatditd: Decimal float library routines. 42568 (line 207) 42569 * __bid_floatsidd: Decimal float library routines. 42570 (line 196) 42571 * __bid_floatsisd: Decimal float library routines. 42572 (line 194) 42573 * __bid_floatsitd: Decimal float library routines. 42574 (line 198) 42575 * __bid_floatunsdidd: Decimal float library routines. 42576 (line 223) 42577 * __bid_floatunsdisd: Decimal float library routines. 42578 (line 221) 42579 * __bid_floatunsditd: Decimal float library routines. 42580 (line 225) 42581 * __bid_floatunssidd: Decimal float library routines. 42582 (line 214) 42583 * __bid_floatunssisd: Decimal float library routines. 42584 (line 212) 42585 * __bid_floatunssitd: Decimal float library routines. 42586 (line 216) 42587 * __bid_gedd2: Decimal float library routines. 42588 (line 277) 42589 * __bid_gesd2: Decimal float library routines. 42590 (line 275) 42591 * __bid_getd2: Decimal float library routines. 42592 (line 279) 42593 * __bid_gtdd2: Decimal float library routines. 42594 (line 304) 42595 * __bid_gtsd2: Decimal float library routines. 42596 (line 302) 42597 * __bid_gttd2: Decimal float library routines. 42598 (line 306) 42599 * __bid_ledd2: Decimal float library routines. 42600 (line 295) 42601 * __bid_lesd2: Decimal float library routines. 42602 (line 293) 42603 * __bid_letd2: Decimal float library routines. 42604 (line 297) 42605 * __bid_ltdd2: Decimal float library routines. 42606 (line 286) 42607 * __bid_ltsd2: Decimal float library routines. 42608 (line 284) 42609 * __bid_lttd2: Decimal float library routines. 42610 (line 288) 42611 * __bid_muldd3: Decimal float library routines. 42612 (line 54) 42613 * __bid_mulsd3: Decimal float library routines. 42614 (line 50) 42615 * __bid_multd3: Decimal float library routines. 42616 (line 58) 42617 * __bid_nedd2: Decimal float library routines. 42618 (line 268) 42619 * __bid_negdd2: Decimal float library routines. 42620 (line 78) 42621 * __bid_negsd2: Decimal float library routines. 42622 (line 76) 42623 * __bid_negtd2: Decimal float library routines. 42624 (line 80) 42625 * __bid_nesd2: Decimal float library routines. 42626 (line 266) 42627 * __bid_netd2: Decimal float library routines. 42628 (line 270) 42629 * __bid_subdd3: Decimal float library routines. 42630 (line 39) 42631 * __bid_subsd3: Decimal float library routines. 42632 (line 35) 42633 * __bid_subtd3: Decimal float library routines. 42634 (line 43) 42635 * __bid_truncdddf: Decimal float library routines. 42636 (line 153) 42637 * __bid_truncddsd2: Decimal float library routines. 42638 (line 94) 42639 * __bid_truncddsf: Decimal float library routines. 42640 (line 124) 42641 * __bid_truncdfsd: Decimal float library routines. 42642 (line 111) 42643 * __bid_truncsdsf: Decimal float library routines. 42644 (line 151) 42645 * __bid_trunctddd2: Decimal float library routines. 42646 (line 98) 42647 * __bid_trunctddf: Decimal float library routines. 42648 (line 130) 42649 * __bid_trunctdsd2: Decimal float library routines. 42650 (line 96) 42651 * __bid_trunctdsf: Decimal float library routines. 42652 (line 126) 42653 * __bid_trunctdtf: Decimal float library routines. 42654 (line 155) 42655 * __bid_trunctdxf: Decimal float library routines. 42656 (line 136) 42657 * __bid_trunctfdd: Decimal float library routines. 42658 (line 119) 42659 * __bid_trunctfsd: Decimal float library routines. 42660 (line 115) 42661 * __bid_truncxfdd: Decimal float library routines. 42662 (line 117) 42663 * __bid_truncxfsd: Decimal float library routines. 42664 (line 113) 42665 * __bid_unorddd2: Decimal float library routines. 42666 (line 235) 42667 * __bid_unordsd2: Decimal float library routines. 42668 (line 233) 42669 * __bid_unordtd2: Decimal float library routines. 42670 (line 237) 42671 * __bswapdi2: Integer library routines. 42672 (line 162) 42673 * __bswapsi2: Integer library routines. 42674 (line 161) 42675 * __builtin_classify_type: Varargs. (line 51) 42676 * __builtin_next_arg: Varargs. (line 42) 42677 * __builtin_saveregs: Varargs. (line 24) 42678 * __clear_cache: Miscellaneous routines. 42679 (line 10) 42680 * __clzdi2: Integer library routines. 42681 (line 131) 42682 * __clzsi2: Integer library routines. 42683 (line 130) 42684 * __clzti2: Integer library routines. 42685 (line 132) 42686 * __cmpda2: Fixed-point fractional library routines. 42687 (line 451) 42688 * __cmpdf2: Soft float library routines. 42689 (line 164) 42690 * __cmpdi2: Integer library routines. 42691 (line 87) 42692 * __cmpdq2: Fixed-point fractional library routines. 42693 (line 441) 42694 * __cmpha2: Fixed-point fractional library routines. 42695 (line 449) 42696 * __cmphq2: Fixed-point fractional library routines. 42697 (line 438) 42698 * __cmpqq2: Fixed-point fractional library routines. 42699 (line 437) 42700 * __cmpsa2: Fixed-point fractional library routines. 42701 (line 450) 42702 * __cmpsf2: Soft float library routines. 42703 (line 163) 42704 * __cmpsq2: Fixed-point fractional library routines. 42705 (line 439) 42706 * __cmpta2: Fixed-point fractional library routines. 42707 (line 453) 42708 * __cmptf2: Soft float library routines. 42709 (line 165) 42710 * __cmpti2: Integer library routines. 42711 (line 88) 42712 * __cmpuda2: Fixed-point fractional library routines. 42713 (line 458) 42714 * __cmpudq2: Fixed-point fractional library routines. 42715 (line 448) 42716 * __cmpuha2: Fixed-point fractional library routines. 42717 (line 455) 42718 * __cmpuhq2: Fixed-point fractional library routines. 42719 (line 444) 42720 * __cmpuqq2: Fixed-point fractional library routines. 42721 (line 443) 42722 * __cmpusa2: Fixed-point fractional library routines. 42723 (line 456) 42724 * __cmpusq2: Fixed-point fractional library routines. 42725 (line 446) 42726 * __cmputa2: Fixed-point fractional library routines. 42727 (line 460) 42728 * __CTOR_LIST__: Initialization. (line 25) 42729 * __ctzdi2: Integer library routines. 42730 (line 138) 42731 * __ctzsi2: Integer library routines. 42732 (line 137) 42733 * __ctzti2: Integer library routines. 42734 (line 139) 42735 * __divda3: Fixed-point fractional library routines. 42736 (line 227) 42737 * __divdc3: Soft float library routines. 42738 (line 252) 42739 * __divdf3: Soft float library routines. 42740 (line 48) 42741 * __divdi3: Integer library routines. 42742 (line 25) 42743 * __divdq3: Fixed-point fractional library routines. 42744 (line 223) 42745 * __divha3: Fixed-point fractional library routines. 42746 (line 225) 42747 * __divhq3: Fixed-point fractional library routines. 42748 (line 220) 42749 * __divqq3: Fixed-point fractional library routines. 42750 (line 219) 42751 * __divsa3: Fixed-point fractional library routines. 42752 (line 226) 42753 * __divsc3: Soft float library routines. 42754 (line 250) 42755 * __divsf3: Soft float library routines. 42756 (line 47) 42757 * __divsi3: Integer library routines. 42758 (line 24) 42759 * __divsq3: Fixed-point fractional library routines. 42760 (line 221) 42761 * __divta3: Fixed-point fractional library routines. 42762 (line 229) 42763 * __divtc3: Soft float library routines. 42764 (line 254) 42765 * __divtf3: Soft float library routines. 42766 (line 50) 42767 * __divti3: Integer library routines. 42768 (line 26) 42769 * __divxc3: Soft float library routines. 42770 (line 256) 42771 * __divxf3: Soft float library routines. 42772 (line 52) 42773 * __dpd_adddd3: Decimal float library routines. 42774 (line 23) 42775 * __dpd_addsd3: Decimal float library routines. 42776 (line 19) 42777 * __dpd_addtd3: Decimal float library routines. 42778 (line 27) 42779 * __dpd_divdd3: Decimal float library routines. 42780 (line 66) 42781 * __dpd_divsd3: Decimal float library routines. 42782 (line 62) 42783 * __dpd_divtd3: Decimal float library routines. 42784 (line 70) 42785 * __dpd_eqdd2: Decimal float library routines. 42786 (line 258) 42787 * __dpd_eqsd2: Decimal float library routines. 42788 (line 256) 42789 * __dpd_eqtd2: Decimal float library routines. 42790 (line 260) 42791 * __dpd_extendddtd2: Decimal float library routines. 42792 (line 91) 42793 * __dpd_extendddtf: Decimal float library routines. 42794 (line 139) 42795 * __dpd_extendddxf: Decimal float library routines. 42796 (line 133) 42797 * __dpd_extenddfdd: Decimal float library routines. 42798 (line 146) 42799 * __dpd_extenddftd: Decimal float library routines. 42800 (line 106) 42801 * __dpd_extendsddd2: Decimal float library routines. 42802 (line 87) 42803 * __dpd_extendsddf: Decimal float library routines. 42804 (line 127) 42805 * __dpd_extendsdtd2: Decimal float library routines. 42806 (line 89) 42807 * __dpd_extendsdtf: Decimal float library routines. 42808 (line 137) 42809 * __dpd_extendsdxf: Decimal float library routines. 42810 (line 131) 42811 * __dpd_extendsfdd: Decimal float library routines. 42812 (line 102) 42813 * __dpd_extendsfsd: Decimal float library routines. 42814 (line 144) 42815 * __dpd_extendsftd: Decimal float library routines. 42816 (line 104) 42817 * __dpd_extendtftd: Decimal float library routines. 42818 (line 148) 42819 * __dpd_extendxftd: Decimal float library routines. 42820 (line 108) 42821 * __dpd_fixdddi: Decimal float library routines. 42822 (line 169) 42823 * __dpd_fixddsi: Decimal float library routines. 42824 (line 161) 42825 * __dpd_fixsddi: Decimal float library routines. 42826 (line 167) 42827 * __dpd_fixsdsi: Decimal float library routines. 42828 (line 159) 42829 * __dpd_fixtddi: Decimal float library routines. 42830 (line 171) 42831 * __dpd_fixtdsi: Decimal float library routines. 42832 (line 163) 42833 * __dpd_fixunsdddi: Decimal float library routines. 42834 (line 186) 42835 * __dpd_fixunsddsi: Decimal float library routines. 42836 (line 177) 42837 * __dpd_fixunssddi: Decimal float library routines. 42838 (line 184) 42839 * __dpd_fixunssdsi: Decimal float library routines. 42840 (line 175) 42841 * __dpd_fixunstddi: Decimal float library routines. 42842 (line 188) 42843 * __dpd_fixunstdsi: Decimal float library routines. 42844 (line 179) 42845 * __dpd_floatdidd: Decimal float library routines. 42846 (line 204) 42847 * __dpd_floatdisd: Decimal float library routines. 42848 (line 202) 42849 * __dpd_floatditd: Decimal float library routines. 42850 (line 206) 42851 * __dpd_floatsidd: Decimal float library routines. 42852 (line 195) 42853 * __dpd_floatsisd: Decimal float library routines. 42854 (line 193) 42855 * __dpd_floatsitd: Decimal float library routines. 42856 (line 197) 42857 * __dpd_floatunsdidd: Decimal float library routines. 42858 (line 222) 42859 * __dpd_floatunsdisd: Decimal float library routines. 42860 (line 220) 42861 * __dpd_floatunsditd: Decimal float library routines. 42862 (line 224) 42863 * __dpd_floatunssidd: Decimal float library routines. 42864 (line 213) 42865 * __dpd_floatunssisd: Decimal float library routines. 42866 (line 211) 42867 * __dpd_floatunssitd: Decimal float library routines. 42868 (line 215) 42869 * __dpd_gedd2: Decimal float library routines. 42870 (line 276) 42871 * __dpd_gesd2: Decimal float library routines. 42872 (line 274) 42873 * __dpd_getd2: Decimal float library routines. 42874 (line 278) 42875 * __dpd_gtdd2: Decimal float library routines. 42876 (line 303) 42877 * __dpd_gtsd2: Decimal float library routines. 42878 (line 301) 42879 * __dpd_gttd2: Decimal float library routines. 42880 (line 305) 42881 * __dpd_ledd2: Decimal float library routines. 42882 (line 294) 42883 * __dpd_lesd2: Decimal float library routines. 42884 (line 292) 42885 * __dpd_letd2: Decimal float library routines. 42886 (line 296) 42887 * __dpd_ltdd2: Decimal float library routines. 42888 (line 285) 42889 * __dpd_ltsd2: Decimal float library routines. 42890 (line 283) 42891 * __dpd_lttd2: Decimal float library routines. 42892 (line 287) 42893 * __dpd_muldd3: Decimal float library routines. 42894 (line 52) 42895 * __dpd_mulsd3: Decimal float library routines. 42896 (line 48) 42897 * __dpd_multd3: Decimal float library routines. 42898 (line 56) 42899 * __dpd_nedd2: Decimal float library routines. 42900 (line 267) 42901 * __dpd_negdd2: Decimal float library routines. 42902 (line 77) 42903 * __dpd_negsd2: Decimal float library routines. 42904 (line 75) 42905 * __dpd_negtd2: Decimal float library routines. 42906 (line 79) 42907 * __dpd_nesd2: Decimal float library routines. 42908 (line 265) 42909 * __dpd_netd2: Decimal float library routines. 42910 (line 269) 42911 * __dpd_subdd3: Decimal float library routines. 42912 (line 37) 42913 * __dpd_subsd3: Decimal float library routines. 42914 (line 33) 42915 * __dpd_subtd3: Decimal float library routines. 42916 (line 41) 42917 * __dpd_truncdddf: Decimal float library routines. 42918 (line 152) 42919 * __dpd_truncddsd2: Decimal float library routines. 42920 (line 93) 42921 * __dpd_truncddsf: Decimal float library routines. 42922 (line 123) 42923 * __dpd_truncdfsd: Decimal float library routines. 42924 (line 110) 42925 * __dpd_truncsdsf: Decimal float library routines. 42926 (line 150) 42927 * __dpd_trunctddd2: Decimal float library routines. 42928 (line 97) 42929 * __dpd_trunctddf: Decimal float library routines. 42930 (line 129) 42931 * __dpd_trunctdsd2: Decimal float library routines. 42932 (line 95) 42933 * __dpd_trunctdsf: Decimal float library routines. 42934 (line 125) 42935 * __dpd_trunctdtf: Decimal float library routines. 42936 (line 154) 42937 * __dpd_trunctdxf: Decimal float library routines. 42938 (line 135) 42939 * __dpd_trunctfdd: Decimal float library routines. 42940 (line 118) 42941 * __dpd_trunctfsd: Decimal float library routines. 42942 (line 114) 42943 * __dpd_truncxfdd: Decimal float library routines. 42944 (line 116) 42945 * __dpd_truncxfsd: Decimal float library routines. 42946 (line 112) 42947 * __dpd_unorddd2: Decimal float library routines. 42948 (line 234) 42949 * __dpd_unordsd2: Decimal float library routines. 42950 (line 232) 42951 * __dpd_unordtd2: Decimal float library routines. 42952 (line 236) 42953 * __DTOR_LIST__: Initialization. (line 25) 42954 * __eqdf2: Soft float library routines. 42955 (line 194) 42956 * __eqsf2: Soft float library routines. 42957 (line 193) 42958 * __eqtf2: Soft float library routines. 42959 (line 195) 42960 * __extenddftf2: Soft float library routines. 42961 (line 68) 42962 * __extenddfxf2: Soft float library routines. 42963 (line 69) 42964 * __extendsfdf2: Soft float library routines. 42965 (line 65) 42966 * __extendsftf2: Soft float library routines. 42967 (line 66) 42968 * __extendsfxf2: Soft float library routines. 42969 (line 67) 42970 * __ffsdi2: Integer library routines. 42971 (line 144) 42972 * __ffsti2: Integer library routines. 42973 (line 145) 42974 * __fixdfdi: Soft float library routines. 42975 (line 88) 42976 * __fixdfsi: Soft float library routines. 42977 (line 81) 42978 * __fixdfti: Soft float library routines. 42979 (line 94) 42980 * __fixsfdi: Soft float library routines. 42981 (line 87) 42982 * __fixsfsi: Soft float library routines. 42983 (line 80) 42984 * __fixsfti: Soft float library routines. 42985 (line 93) 42986 * __fixtfdi: Soft float library routines. 42987 (line 89) 42988 * __fixtfsi: Soft float library routines. 42989 (line 82) 42990 * __fixtfti: Soft float library routines. 42991 (line 95) 42992 * __fixunsdfdi: Soft float library routines. 42993 (line 108) 42994 * __fixunsdfsi: Soft float library routines. 42995 (line 101) 42996 * __fixunsdfti: Soft float library routines. 42997 (line 115) 42998 * __fixunssfdi: Soft float library routines. 42999 (line 107) 43000 * __fixunssfsi: Soft float library routines. 43001 (line 100) 43002 * __fixunssfti: Soft float library routines. 43003 (line 114) 43004 * __fixunstfdi: Soft float library routines. 43005 (line 109) 43006 * __fixunstfsi: Soft float library routines. 43007 (line 102) 43008 * __fixunstfti: Soft float library routines. 43009 (line 116) 43010 * __fixunsxfdi: Soft float library routines. 43011 (line 110) 43012 * __fixunsxfsi: Soft float library routines. 43013 (line 103) 43014 * __fixunsxfti: Soft float library routines. 43015 (line 117) 43016 * __fixxfdi: Soft float library routines. 43017 (line 90) 43018 * __fixxfsi: Soft float library routines. 43019 (line 83) 43020 * __fixxfti: Soft float library routines. 43021 (line 96) 43022 * __floatdidf: Soft float library routines. 43023 (line 128) 43024 * __floatdisf: Soft float library routines. 43025 (line 127) 43026 * __floatditf: Soft float library routines. 43027 (line 129) 43028 * __floatdixf: Soft float library routines. 43029 (line 130) 43030 * __floatsidf: Soft float library routines. 43031 (line 122) 43032 * __floatsisf: Soft float library routines. 43033 (line 121) 43034 * __floatsitf: Soft float library routines. 43035 (line 123) 43036 * __floatsixf: Soft float library routines. 43037 (line 124) 43038 * __floattidf: Soft float library routines. 43039 (line 134) 43040 * __floattisf: Soft float library routines. 43041 (line 133) 43042 * __floattitf: Soft float library routines. 43043 (line 135) 43044 * __floattixf: Soft float library routines. 43045 (line 136) 43046 * __floatundidf: Soft float library routines. 43047 (line 146) 43048 * __floatundisf: Soft float library routines. 43049 (line 145) 43050 * __floatunditf: Soft float library routines. 43051 (line 147) 43052 * __floatundixf: Soft float library routines. 43053 (line 148) 43054 * __floatunsidf: Soft float library routines. 43055 (line 140) 43056 * __floatunsisf: Soft float library routines. 43057 (line 139) 43058 * __floatunsitf: Soft float library routines. 43059 (line 141) 43060 * __floatunsixf: Soft float library routines. 43061 (line 142) 43062 * __floatuntidf: Soft float library routines. 43063 (line 152) 43064 * __floatuntisf: Soft float library routines. 43065 (line 151) 43066 * __floatuntitf: Soft float library routines. 43067 (line 153) 43068 * __floatuntixf: Soft float library routines. 43069 (line 154) 43070 * __fractdadf: Fixed-point fractional library routines. 43071 (line 636) 43072 * __fractdadi: Fixed-point fractional library routines. 43073 (line 633) 43074 * __fractdadq: Fixed-point fractional library routines. 43075 (line 616) 43076 * __fractdaha2: Fixed-point fractional library routines. 43077 (line 617) 43078 * __fractdahi: Fixed-point fractional library routines. 43079 (line 631) 43080 * __fractdahq: Fixed-point fractional library routines. 43081 (line 614) 43082 * __fractdaqi: Fixed-point fractional library routines. 43083 (line 630) 43084 * __fractdaqq: Fixed-point fractional library routines. 43085 (line 613) 43086 * __fractdasa2: Fixed-point fractional library routines. 43087 (line 618) 43088 * __fractdasf: Fixed-point fractional library routines. 43089 (line 635) 43090 * __fractdasi: Fixed-point fractional library routines. 43091 (line 632) 43092 * __fractdasq: Fixed-point fractional library routines. 43093 (line 615) 43094 * __fractdata2: Fixed-point fractional library routines. 43095 (line 619) 43096 * __fractdati: Fixed-point fractional library routines. 43097 (line 634) 43098 * __fractdauda: Fixed-point fractional library routines. 43099 (line 627) 43100 * __fractdaudq: Fixed-point fractional library routines. 43101 (line 624) 43102 * __fractdauha: Fixed-point fractional library routines. 43103 (line 625) 43104 * __fractdauhq: Fixed-point fractional library routines. 43105 (line 621) 43106 * __fractdauqq: Fixed-point fractional library routines. 43107 (line 620) 43108 * __fractdausa: Fixed-point fractional library routines. 43109 (line 626) 43110 * __fractdausq: Fixed-point fractional library routines. 43111 (line 622) 43112 * __fractdauta: Fixed-point fractional library routines. 43113 (line 629) 43114 * __fractdfda: Fixed-point fractional library routines. 43115 (line 1025) 43116 * __fractdfdq: Fixed-point fractional library routines. 43117 (line 1022) 43118 * __fractdfha: Fixed-point fractional library routines. 43119 (line 1023) 43120 * __fractdfhq: Fixed-point fractional library routines. 43121 (line 1020) 43122 * __fractdfqq: Fixed-point fractional library routines. 43123 (line 1019) 43124 * __fractdfsa: Fixed-point fractional library routines. 43125 (line 1024) 43126 * __fractdfsq: Fixed-point fractional library routines. 43127 (line 1021) 43128 * __fractdfta: Fixed-point fractional library routines. 43129 (line 1026) 43130 * __fractdfuda: Fixed-point fractional library routines. 43131 (line 1033) 43132 * __fractdfudq: Fixed-point fractional library routines. 43133 (line 1030) 43134 * __fractdfuha: Fixed-point fractional library routines. 43135 (line 1031) 43136 * __fractdfuhq: Fixed-point fractional library routines. 43137 (line 1028) 43138 * __fractdfuqq: Fixed-point fractional library routines. 43139 (line 1027) 43140 * __fractdfusa: Fixed-point fractional library routines. 43141 (line 1032) 43142 * __fractdfusq: Fixed-point fractional library routines. 43143 (line 1029) 43144 * __fractdfuta: Fixed-point fractional library routines. 43145 (line 1034) 43146 * __fractdida: Fixed-point fractional library routines. 43147 (line 975) 43148 * __fractdidq: Fixed-point fractional library routines. 43149 (line 972) 43150 * __fractdiha: Fixed-point fractional library routines. 43151 (line 973) 43152 * __fractdihq: Fixed-point fractional library routines. 43153 (line 970) 43154 * __fractdiqq: Fixed-point fractional library routines. 43155 (line 969) 43156 * __fractdisa: Fixed-point fractional library routines. 43157 (line 974) 43158 * __fractdisq: Fixed-point fractional library routines. 43159 (line 971) 43160 * __fractdita: Fixed-point fractional library routines. 43161 (line 976) 43162 * __fractdiuda: Fixed-point fractional library routines. 43163 (line 983) 43164 * __fractdiudq: Fixed-point fractional library routines. 43165 (line 980) 43166 * __fractdiuha: Fixed-point fractional library routines. 43167 (line 981) 43168 * __fractdiuhq: Fixed-point fractional library routines. 43169 (line 978) 43170 * __fractdiuqq: Fixed-point fractional library routines. 43171 (line 977) 43172 * __fractdiusa: Fixed-point fractional library routines. 43173 (line 982) 43174 * __fractdiusq: Fixed-point fractional library routines. 43175 (line 979) 43176 * __fractdiuta: Fixed-point fractional library routines. 43177 (line 984) 43178 * __fractdqda: Fixed-point fractional library routines. 43179 (line 544) 43180 * __fractdqdf: Fixed-point fractional library routines. 43181 (line 566) 43182 * __fractdqdi: Fixed-point fractional library routines. 43183 (line 563) 43184 * __fractdqha: Fixed-point fractional library routines. 43185 (line 542) 43186 * __fractdqhi: Fixed-point fractional library routines. 43187 (line 561) 43188 * __fractdqhq2: Fixed-point fractional library routines. 43189 (line 540) 43190 * __fractdqqi: Fixed-point fractional library routines. 43191 (line 560) 43192 * __fractdqqq2: Fixed-point fractional library routines. 43193 (line 539) 43194 * __fractdqsa: Fixed-point fractional library routines. 43195 (line 543) 43196 * __fractdqsf: Fixed-point fractional library routines. 43197 (line 565) 43198 * __fractdqsi: Fixed-point fractional library routines. 43199 (line 562) 43200 * __fractdqsq2: Fixed-point fractional library routines. 43201 (line 541) 43202 * __fractdqta: Fixed-point fractional library routines. 43203 (line 545) 43204 * __fractdqti: Fixed-point fractional library routines. 43205 (line 564) 43206 * __fractdquda: Fixed-point fractional library routines. 43207 (line 557) 43208 * __fractdqudq: Fixed-point fractional library routines. 43209 (line 552) 43210 * __fractdquha: Fixed-point fractional library routines. 43211 (line 554) 43212 * __fractdquhq: Fixed-point fractional library routines. 43213 (line 548) 43214 * __fractdquqq: Fixed-point fractional library routines. 43215 (line 547) 43216 * __fractdqusa: Fixed-point fractional library routines. 43217 (line 555) 43218 * __fractdqusq: Fixed-point fractional library routines. 43219 (line 550) 43220 * __fractdquta: Fixed-point fractional library routines. 43221 (line 559) 43222 * __fracthada2: Fixed-point fractional library routines. 43223 (line 572) 43224 * __fracthadf: Fixed-point fractional library routines. 43225 (line 590) 43226 * __fracthadi: Fixed-point fractional library routines. 43227 (line 587) 43228 * __fracthadq: Fixed-point fractional library routines. 43229 (line 570) 43230 * __fracthahi: Fixed-point fractional library routines. 43231 (line 585) 43232 * __fracthahq: Fixed-point fractional library routines. 43233 (line 568) 43234 * __fracthaqi: Fixed-point fractional library routines. 43235 (line 584) 43236 * __fracthaqq: Fixed-point fractional library routines. 43237 (line 567) 43238 * __fracthasa2: Fixed-point fractional library routines. 43239 (line 571) 43240 * __fracthasf: Fixed-point fractional library routines. 43241 (line 589) 43242 * __fracthasi: Fixed-point fractional library routines. 43243 (line 586) 43244 * __fracthasq: Fixed-point fractional library routines. 43245 (line 569) 43246 * __fracthata2: Fixed-point fractional library routines. 43247 (line 573) 43248 * __fracthati: Fixed-point fractional library routines. 43249 (line 588) 43250 * __fracthauda: Fixed-point fractional library routines. 43251 (line 581) 43252 * __fracthaudq: Fixed-point fractional library routines. 43253 (line 578) 43254 * __fracthauha: Fixed-point fractional library routines. 43255 (line 579) 43256 * __fracthauhq: Fixed-point fractional library routines. 43257 (line 575) 43258 * __fracthauqq: Fixed-point fractional library routines. 43259 (line 574) 43260 * __fracthausa: Fixed-point fractional library routines. 43261 (line 580) 43262 * __fracthausq: Fixed-point fractional library routines. 43263 (line 576) 43264 * __fracthauta: Fixed-point fractional library routines. 43265 (line 583) 43266 * __fracthida: Fixed-point fractional library routines. 43267 (line 943) 43268 * __fracthidq: Fixed-point fractional library routines. 43269 (line 940) 43270 * __fracthiha: Fixed-point fractional library routines. 43271 (line 941) 43272 * __fracthihq: Fixed-point fractional library routines. 43273 (line 938) 43274 * __fracthiqq: Fixed-point fractional library routines. 43275 (line 937) 43276 * __fracthisa: Fixed-point fractional library routines. 43277 (line 942) 43278 * __fracthisq: Fixed-point fractional library routines. 43279 (line 939) 43280 * __fracthita: Fixed-point fractional library routines. 43281 (line 944) 43282 * __fracthiuda: Fixed-point fractional library routines. 43283 (line 951) 43284 * __fracthiudq: Fixed-point fractional library routines. 43285 (line 948) 43286 * __fracthiuha: Fixed-point fractional library routines. 43287 (line 949) 43288 * __fracthiuhq: Fixed-point fractional library routines. 43289 (line 946) 43290 * __fracthiuqq: Fixed-point fractional library routines. 43291 (line 945) 43292 * __fracthiusa: Fixed-point fractional library routines. 43293 (line 950) 43294 * __fracthiusq: Fixed-point fractional library routines. 43295 (line 947) 43296 * __fracthiuta: Fixed-point fractional library routines. 43297 (line 952) 43298 * __fracthqda: Fixed-point fractional library routines. 43299 (line 498) 43300 * __fracthqdf: Fixed-point fractional library routines. 43301 (line 514) 43302 * __fracthqdi: Fixed-point fractional library routines. 43303 (line 511) 43304 * __fracthqdq2: Fixed-point fractional library routines. 43305 (line 495) 43306 * __fracthqha: Fixed-point fractional library routines. 43307 (line 496) 43308 * __fracthqhi: Fixed-point fractional library routines. 43309 (line 509) 43310 * __fracthqqi: Fixed-point fractional library routines. 43311 (line 508) 43312 * __fracthqqq2: Fixed-point fractional library routines. 43313 (line 493) 43314 * __fracthqsa: Fixed-point fractional library routines. 43315 (line 497) 43316 * __fracthqsf: Fixed-point fractional library routines. 43317 (line 513) 43318 * __fracthqsi: Fixed-point fractional library routines. 43319 (line 510) 43320 * __fracthqsq2: Fixed-point fractional library routines. 43321 (line 494) 43322 * __fracthqta: Fixed-point fractional library routines. 43323 (line 499) 43324 * __fracthqti: Fixed-point fractional library routines. 43325 (line 512) 43326 * __fracthquda: Fixed-point fractional library routines. 43327 (line 506) 43328 * __fracthqudq: Fixed-point fractional library routines. 43329 (line 503) 43330 * __fracthquha: Fixed-point fractional library routines. 43331 (line 504) 43332 * __fracthquhq: Fixed-point fractional library routines. 43333 (line 501) 43334 * __fracthquqq: Fixed-point fractional library routines. 43335 (line 500) 43336 * __fracthqusa: Fixed-point fractional library routines. 43337 (line 505) 43338 * __fracthqusq: Fixed-point fractional library routines. 43339 (line 502) 43340 * __fracthquta: Fixed-point fractional library routines. 43341 (line 507) 43342 * __fractqida: Fixed-point fractional library routines. 43343 (line 925) 43344 * __fractqidq: Fixed-point fractional library routines. 43345 (line 922) 43346 * __fractqiha: Fixed-point fractional library routines. 43347 (line 923) 43348 * __fractqihq: Fixed-point fractional library routines. 43349 (line 920) 43350 * __fractqiqq: Fixed-point fractional library routines. 43351 (line 919) 43352 * __fractqisa: Fixed-point fractional library routines. 43353 (line 924) 43354 * __fractqisq: Fixed-point fractional library routines. 43355 (line 921) 43356 * __fractqita: Fixed-point fractional library routines. 43357 (line 926) 43358 * __fractqiuda: Fixed-point fractional library routines. 43359 (line 934) 43360 * __fractqiudq: Fixed-point fractional library routines. 43361 (line 931) 43362 * __fractqiuha: Fixed-point fractional library routines. 43363 (line 932) 43364 * __fractqiuhq: Fixed-point fractional library routines. 43365 (line 928) 43366 * __fractqiuqq: Fixed-point fractional library routines. 43367 (line 927) 43368 * __fractqiusa: Fixed-point fractional library routines. 43369 (line 933) 43370 * __fractqiusq: Fixed-point fractional library routines. 43371 (line 929) 43372 * __fractqiuta: Fixed-point fractional library routines. 43373 (line 936) 43374 * __fractqqda: Fixed-point fractional library routines. 43375 (line 474) 43376 * __fractqqdf: Fixed-point fractional library routines. 43377 (line 492) 43378 * __fractqqdi: Fixed-point fractional library routines. 43379 (line 489) 43380 * __fractqqdq2: Fixed-point fractional library routines. 43381 (line 471) 43382 * __fractqqha: Fixed-point fractional library routines. 43383 (line 472) 43384 * __fractqqhi: Fixed-point fractional library routines. 43385 (line 487) 43386 * __fractqqhq2: Fixed-point fractional library routines. 43387 (line 469) 43388 * __fractqqqi: Fixed-point fractional library routines. 43389 (line 486) 43390 * __fractqqsa: Fixed-point fractional library routines. 43391 (line 473) 43392 * __fractqqsf: Fixed-point fractional library routines. 43393 (line 491) 43394 * __fractqqsi: Fixed-point fractional library routines. 43395 (line 488) 43396 * __fractqqsq2: Fixed-point fractional library routines. 43397 (line 470) 43398 * __fractqqta: Fixed-point fractional library routines. 43399 (line 475) 43400 * __fractqqti: Fixed-point fractional library routines. 43401 (line 490) 43402 * __fractqquda: Fixed-point fractional library routines. 43403 (line 483) 43404 * __fractqqudq: Fixed-point fractional library routines. 43405 (line 480) 43406 * __fractqquha: Fixed-point fractional library routines. 43407 (line 481) 43408 * __fractqquhq: Fixed-point fractional library routines. 43409 (line 477) 43410 * __fractqquqq: Fixed-point fractional library routines. 43411 (line 476) 43412 * __fractqqusa: Fixed-point fractional library routines. 43413 (line 482) 43414 * __fractqqusq: Fixed-point fractional library routines. 43415 (line 478) 43416 * __fractqquta: Fixed-point fractional library routines. 43417 (line 485) 43418 * __fractsada2: Fixed-point fractional library routines. 43419 (line 596) 43420 * __fractsadf: Fixed-point fractional library routines. 43421 (line 612) 43422 * __fractsadi: Fixed-point fractional library routines. 43423 (line 609) 43424 * __fractsadq: Fixed-point fractional library routines. 43425 (line 594) 43426 * __fractsaha2: Fixed-point fractional library routines. 43427 (line 595) 43428 * __fractsahi: Fixed-point fractional library routines. 43429 (line 607) 43430 * __fractsahq: Fixed-point fractional library routines. 43431 (line 592) 43432 * __fractsaqi: Fixed-point fractional library routines. 43433 (line 606) 43434 * __fractsaqq: Fixed-point fractional library routines. 43435 (line 591) 43436 * __fractsasf: Fixed-point fractional library routines. 43437 (line 611) 43438 * __fractsasi: Fixed-point fractional library routines. 43439 (line 608) 43440 * __fractsasq: Fixed-point fractional library routines. 43441 (line 593) 43442 * __fractsata2: Fixed-point fractional library routines. 43443 (line 597) 43444 * __fractsati: Fixed-point fractional library routines. 43445 (line 610) 43446 * __fractsauda: Fixed-point fractional library routines. 43447 (line 604) 43448 * __fractsaudq: Fixed-point fractional library routines. 43449 (line 601) 43450 * __fractsauha: Fixed-point fractional library routines. 43451 (line 602) 43452 * __fractsauhq: Fixed-point fractional library routines. 43453 (line 599) 43454 * __fractsauqq: Fixed-point fractional library routines. 43455 (line 598) 43456 * __fractsausa: Fixed-point fractional library routines. 43457 (line 603) 43458 * __fractsausq: Fixed-point fractional library routines. 43459 (line 600) 43460 * __fractsauta: Fixed-point fractional library routines. 43461 (line 605) 43462 * __fractsfda: Fixed-point fractional library routines. 43463 (line 1009) 43464 * __fractsfdq: Fixed-point fractional library routines. 43465 (line 1006) 43466 * __fractsfha: Fixed-point fractional library routines. 43467 (line 1007) 43468 * __fractsfhq: Fixed-point fractional library routines. 43469 (line 1004) 43470 * __fractsfqq: Fixed-point fractional library routines. 43471 (line 1003) 43472 * __fractsfsa: Fixed-point fractional library routines. 43473 (line 1008) 43474 * __fractsfsq: Fixed-point fractional library routines. 43475 (line 1005) 43476 * __fractsfta: Fixed-point fractional library routines. 43477 (line 1010) 43478 * __fractsfuda: Fixed-point fractional library routines. 43479 (line 1017) 43480 * __fractsfudq: Fixed-point fractional library routines. 43481 (line 1014) 43482 * __fractsfuha: Fixed-point fractional library routines. 43483 (line 1015) 43484 * __fractsfuhq: Fixed-point fractional library routines. 43485 (line 1012) 43486 * __fractsfuqq: Fixed-point fractional library routines. 43487 (line 1011) 43488 * __fractsfusa: Fixed-point fractional library routines. 43489 (line 1016) 43490 * __fractsfusq: Fixed-point fractional library routines. 43491 (line 1013) 43492 * __fractsfuta: Fixed-point fractional library routines. 43493 (line 1018) 43494 * __fractsida: Fixed-point fractional library routines. 43495 (line 959) 43496 * __fractsidq: Fixed-point fractional library routines. 43497 (line 956) 43498 * __fractsiha: Fixed-point fractional library routines. 43499 (line 957) 43500 * __fractsihq: Fixed-point fractional library routines. 43501 (line 954) 43502 * __fractsiqq: Fixed-point fractional library routines. 43503 (line 953) 43504 * __fractsisa: Fixed-point fractional library routines. 43505 (line 958) 43506 * __fractsisq: Fixed-point fractional library routines. 43507 (line 955) 43508 * __fractsita: Fixed-point fractional library routines. 43509 (line 960) 43510 * __fractsiuda: Fixed-point fractional library routines. 43511 (line 967) 43512 * __fractsiudq: Fixed-point fractional library routines. 43513 (line 964) 43514 * __fractsiuha: Fixed-point fractional library routines. 43515 (line 965) 43516 * __fractsiuhq: Fixed-point fractional library routines. 43517 (line 962) 43518 * __fractsiuqq: Fixed-point fractional library routines. 43519 (line 961) 43520 * __fractsiusa: Fixed-point fractional library routines. 43521 (line 966) 43522 * __fractsiusq: Fixed-point fractional library routines. 43523 (line 963) 43524 * __fractsiuta: Fixed-point fractional library routines. 43525 (line 968) 43526 * __fractsqda: Fixed-point fractional library routines. 43527 (line 520) 43528 * __fractsqdf: Fixed-point fractional library routines. 43529 (line 538) 43530 * __fractsqdi: Fixed-point fractional library routines. 43531 (line 535) 43532 * __fractsqdq2: Fixed-point fractional library routines. 43533 (line 517) 43534 * __fractsqha: Fixed-point fractional library routines. 43535 (line 518) 43536 * __fractsqhi: Fixed-point fractional library routines. 43537 (line 533) 43538 * __fractsqhq2: Fixed-point fractional library routines. 43539 (line 516) 43540 * __fractsqqi: Fixed-point fractional library routines. 43541 (line 532) 43542 * __fractsqqq2: Fixed-point fractional library routines. 43543 (line 515) 43544 * __fractsqsa: Fixed-point fractional library routines. 43545 (line 519) 43546 * __fractsqsf: Fixed-point fractional library routines. 43547 (line 537) 43548 * __fractsqsi: Fixed-point fractional library routines. 43549 (line 534) 43550 * __fractsqta: Fixed-point fractional library routines. 43551 (line 521) 43552 * __fractsqti: Fixed-point fractional library routines. 43553 (line 536) 43554 * __fractsquda: Fixed-point fractional library routines. 43555 (line 529) 43556 * __fractsqudq: Fixed-point fractional library routines. 43557 (line 526) 43558 * __fractsquha: Fixed-point fractional library routines. 43559 (line 527) 43560 * __fractsquhq: Fixed-point fractional library routines. 43561 (line 523) 43562 * __fractsquqq: Fixed-point fractional library routines. 43563 (line 522) 43564 * __fractsqusa: Fixed-point fractional library routines. 43565 (line 528) 43566 * __fractsqusq: Fixed-point fractional library routines. 43567 (line 524) 43568 * __fractsquta: Fixed-point fractional library routines. 43569 (line 531) 43570 * __fracttada2: Fixed-point fractional library routines. 43571 (line 643) 43572 * __fracttadf: Fixed-point fractional library routines. 43573 (line 664) 43574 * __fracttadi: Fixed-point fractional library routines. 43575 (line 661) 43576 * __fracttadq: Fixed-point fractional library routines. 43577 (line 640) 43578 * __fracttaha2: Fixed-point fractional library routines. 43579 (line 641) 43580 * __fracttahi: Fixed-point fractional library routines. 43581 (line 659) 43582 * __fracttahq: Fixed-point fractional library routines. 43583 (line 638) 43584 * __fracttaqi: Fixed-point fractional library routines. 43585 (line 658) 43586 * __fracttaqq: Fixed-point fractional library routines. 43587 (line 637) 43588 * __fracttasa2: Fixed-point fractional library routines. 43589 (line 642) 43590 * __fracttasf: Fixed-point fractional library routines. 43591 (line 663) 43592 * __fracttasi: Fixed-point fractional library routines. 43593 (line 660) 43594 * __fracttasq: Fixed-point fractional library routines. 43595 (line 639) 43596 * __fracttati: Fixed-point fractional library routines. 43597 (line 662) 43598 * __fracttauda: Fixed-point fractional library routines. 43599 (line 655) 43600 * __fracttaudq: Fixed-point fractional library routines. 43601 (line 650) 43602 * __fracttauha: Fixed-point fractional library routines. 43603 (line 652) 43604 * __fracttauhq: Fixed-point fractional library routines. 43605 (line 646) 43606 * __fracttauqq: Fixed-point fractional library routines. 43607 (line 645) 43608 * __fracttausa: Fixed-point fractional library routines. 43609 (line 653) 43610 * __fracttausq: Fixed-point fractional library routines. 43611 (line 648) 43612 * __fracttauta: Fixed-point fractional library routines. 43613 (line 657) 43614 * __fracttida: Fixed-point fractional library routines. 43615 (line 991) 43616 * __fracttidq: Fixed-point fractional library routines. 43617 (line 988) 43618 * __fracttiha: Fixed-point fractional library routines. 43619 (line 989) 43620 * __fracttihq: Fixed-point fractional library routines. 43621 (line 986) 43622 * __fracttiqq: Fixed-point fractional library routines. 43623 (line 985) 43624 * __fracttisa: Fixed-point fractional library routines. 43625 (line 990) 43626 * __fracttisq: Fixed-point fractional library routines. 43627 (line 987) 43628 * __fracttita: Fixed-point fractional library routines. 43629 (line 992) 43630 * __fracttiuda: Fixed-point fractional library routines. 43631 (line 1000) 43632 * __fracttiudq: Fixed-point fractional library routines. 43633 (line 997) 43634 * __fracttiuha: Fixed-point fractional library routines. 43635 (line 998) 43636 * __fracttiuhq: Fixed-point fractional library routines. 43637 (line 994) 43638 * __fracttiuqq: Fixed-point fractional library routines. 43639 (line 993) 43640 * __fracttiusa: Fixed-point fractional library routines. 43641 (line 999) 43642 * __fracttiusq: Fixed-point fractional library routines. 43643 (line 995) 43644 * __fracttiuta: Fixed-point fractional library routines. 43645 (line 1002) 43646 * __fractudada: Fixed-point fractional library routines. 43647 (line 858) 43648 * __fractudadf: Fixed-point fractional library routines. 43649 (line 881) 43650 * __fractudadi: Fixed-point fractional library routines. 43651 (line 878) 43652 * __fractudadq: Fixed-point fractional library routines. 43653 (line 855) 43654 * __fractudaha: Fixed-point fractional library routines. 43655 (line 856) 43656 * __fractudahi: Fixed-point fractional library routines. 43657 (line 876) 43658 * __fractudahq: Fixed-point fractional library routines. 43659 (line 852) 43660 * __fractudaqi: Fixed-point fractional library routines. 43661 (line 875) 43662 * __fractudaqq: Fixed-point fractional library routines. 43663 (line 851) 43664 * __fractudasa: Fixed-point fractional library routines. 43665 (line 857) 43666 * __fractudasf: Fixed-point fractional library routines. 43667 (line 880) 43668 * __fractudasi: Fixed-point fractional library routines. 43669 (line 877) 43670 * __fractudasq: Fixed-point fractional library routines. 43671 (line 853) 43672 * __fractudata: Fixed-point fractional library routines. 43673 (line 860) 43674 * __fractudati: Fixed-point fractional library routines. 43675 (line 879) 43676 * __fractudaudq: Fixed-point fractional library routines. 43677 (line 868) 43678 * __fractudauha2: Fixed-point fractional library routines. 43679 (line 870) 43680 * __fractudauhq: Fixed-point fractional library routines. 43681 (line 864) 43682 * __fractudauqq: Fixed-point fractional library routines. 43683 (line 862) 43684 * __fractudausa2: Fixed-point fractional library routines. 43685 (line 872) 43686 * __fractudausq: Fixed-point fractional library routines. 43687 (line 866) 43688 * __fractudauta2: Fixed-point fractional library routines. 43689 (line 874) 43690 * __fractudqda: Fixed-point fractional library routines. 43691 (line 766) 43692 * __fractudqdf: Fixed-point fractional library routines. 43693 (line 791) 43694 * __fractudqdi: Fixed-point fractional library routines. 43695 (line 787) 43696 * __fractudqdq: Fixed-point fractional library routines. 43697 (line 761) 43698 * __fractudqha: Fixed-point fractional library routines. 43699 (line 763) 43700 * __fractudqhi: Fixed-point fractional library routines. 43701 (line 785) 43702 * __fractudqhq: Fixed-point fractional library routines. 43703 (line 757) 43704 * __fractudqqi: Fixed-point fractional library routines. 43705 (line 784) 43706 * __fractudqqq: Fixed-point fractional library routines. 43707 (line 756) 43708 * __fractudqsa: Fixed-point fractional library routines. 43709 (line 764) 43710 * __fractudqsf: Fixed-point fractional library routines. 43711 (line 790) 43712 * __fractudqsi: Fixed-point fractional library routines. 43713 (line 786) 43714 * __fractudqsq: Fixed-point fractional library routines. 43715 (line 759) 43716 * __fractudqta: Fixed-point fractional library routines. 43717 (line 768) 43718 * __fractudqti: Fixed-point fractional library routines. 43719 (line 789) 43720 * __fractudquda: Fixed-point fractional library routines. 43721 (line 780) 43722 * __fractudquha: Fixed-point fractional library routines. 43723 (line 776) 43724 * __fractudquhq2: Fixed-point fractional library routines. 43725 (line 772) 43726 * __fractudquqq2: Fixed-point fractional library routines. 43727 (line 770) 43728 * __fractudqusa: Fixed-point fractional library routines. 43729 (line 778) 43730 * __fractudqusq2: Fixed-point fractional library routines. 43731 (line 774) 43732 * __fractudquta: Fixed-point fractional library routines. 43733 (line 782) 43734 * __fractuhada: Fixed-point fractional library routines. 43735 (line 799) 43736 * __fractuhadf: Fixed-point fractional library routines. 43737 (line 822) 43738 * __fractuhadi: Fixed-point fractional library routines. 43739 (line 819) 43740 * __fractuhadq: Fixed-point fractional library routines. 43741 (line 796) 43742 * __fractuhaha: Fixed-point fractional library routines. 43743 (line 797) 43744 * __fractuhahi: Fixed-point fractional library routines. 43745 (line 817) 43746 * __fractuhahq: Fixed-point fractional library routines. 43747 (line 793) 43748 * __fractuhaqi: Fixed-point fractional library routines. 43749 (line 816) 43750 * __fractuhaqq: Fixed-point fractional library routines. 43751 (line 792) 43752 * __fractuhasa: Fixed-point fractional library routines. 43753 (line 798) 43754 * __fractuhasf: Fixed-point fractional library routines. 43755 (line 821) 43756 * __fractuhasi: Fixed-point fractional library routines. 43757 (line 818) 43758 * __fractuhasq: Fixed-point fractional library routines. 43759 (line 794) 43760 * __fractuhata: Fixed-point fractional library routines. 43761 (line 801) 43762 * __fractuhati: Fixed-point fractional library routines. 43763 (line 820) 43764 * __fractuhauda2: Fixed-point fractional library routines. 43765 (line 813) 43766 * __fractuhaudq: Fixed-point fractional library routines. 43767 (line 809) 43768 * __fractuhauhq: Fixed-point fractional library routines. 43769 (line 805) 43770 * __fractuhauqq: Fixed-point fractional library routines. 43771 (line 803) 43772 * __fractuhausa2: Fixed-point fractional library routines. 43773 (line 811) 43774 * __fractuhausq: Fixed-point fractional library routines. 43775 (line 807) 43776 * __fractuhauta2: Fixed-point fractional library routines. 43777 (line 815) 43778 * __fractuhqda: Fixed-point fractional library routines. 43779 (line 702) 43780 * __fractuhqdf: Fixed-point fractional library routines. 43781 (line 723) 43782 * __fractuhqdi: Fixed-point fractional library routines. 43783 (line 720) 43784 * __fractuhqdq: Fixed-point fractional library routines. 43785 (line 699) 43786 * __fractuhqha: Fixed-point fractional library routines. 43787 (line 700) 43788 * __fractuhqhi: Fixed-point fractional library routines. 43789 (line 718) 43790 * __fractuhqhq: Fixed-point fractional library routines. 43791 (line 697) 43792 * __fractuhqqi: Fixed-point fractional library routines. 43793 (line 717) 43794 * __fractuhqqq: Fixed-point fractional library routines. 43795 (line 696) 43796 * __fractuhqsa: Fixed-point fractional library routines. 43797 (line 701) 43798 * __fractuhqsf: Fixed-point fractional library routines. 43799 (line 722) 43800 * __fractuhqsi: Fixed-point fractional library routines. 43801 (line 719) 43802 * __fractuhqsq: Fixed-point fractional library routines. 43803 (line 698) 43804 * __fractuhqta: Fixed-point fractional library routines. 43805 (line 703) 43806 * __fractuhqti: Fixed-point fractional library routines. 43807 (line 721) 43808 * __fractuhquda: Fixed-point fractional library routines. 43809 (line 714) 43810 * __fractuhqudq2: Fixed-point fractional library routines. 43811 (line 709) 43812 * __fractuhquha: Fixed-point fractional library routines. 43813 (line 711) 43814 * __fractuhquqq2: Fixed-point fractional library routines. 43815 (line 705) 43816 * __fractuhqusa: Fixed-point fractional library routines. 43817 (line 712) 43818 * __fractuhqusq2: Fixed-point fractional library routines. 43819 (line 707) 43820 * __fractuhquta: Fixed-point fractional library routines. 43821 (line 716) 43822 * __fractunsdadi: Fixed-point fractional library routines. 43823 (line 1555) 43824 * __fractunsdahi: Fixed-point fractional library routines. 43825 (line 1553) 43826 * __fractunsdaqi: Fixed-point fractional library routines. 43827 (line 1552) 43828 * __fractunsdasi: Fixed-point fractional library routines. 43829 (line 1554) 43830 * __fractunsdati: Fixed-point fractional library routines. 43831 (line 1556) 43832 * __fractunsdida: Fixed-point fractional library routines. 43833 (line 1707) 43834 * __fractunsdidq: Fixed-point fractional library routines. 43835 (line 1704) 43836 * __fractunsdiha: Fixed-point fractional library routines. 43837 (line 1705) 43838 * __fractunsdihq: Fixed-point fractional library routines. 43839 (line 1702) 43840 * __fractunsdiqq: Fixed-point fractional library routines. 43841 (line 1701) 43842 * __fractunsdisa: Fixed-point fractional library routines. 43843 (line 1706) 43844 * __fractunsdisq: Fixed-point fractional library routines. 43845 (line 1703) 43846 * __fractunsdita: Fixed-point fractional library routines. 43847 (line 1708) 43848 * __fractunsdiuda: Fixed-point fractional library routines. 43849 (line 1720) 43850 * __fractunsdiudq: Fixed-point fractional library routines. 43851 (line 1715) 43852 * __fractunsdiuha: Fixed-point fractional library routines. 43853 (line 1717) 43854 * __fractunsdiuhq: Fixed-point fractional library routines. 43855 (line 1711) 43856 * __fractunsdiuqq: Fixed-point fractional library routines. 43857 (line 1710) 43858 * __fractunsdiusa: Fixed-point fractional library routines. 43859 (line 1718) 43860 * __fractunsdiusq: Fixed-point fractional library routines. 43861 (line 1713) 43862 * __fractunsdiuta: Fixed-point fractional library routines. 43863 (line 1722) 43864 * __fractunsdqdi: Fixed-point fractional library routines. 43865 (line 1539) 43866 * __fractunsdqhi: Fixed-point fractional library routines. 43867 (line 1537) 43868 * __fractunsdqqi: Fixed-point fractional library routines. 43869 (line 1536) 43870 * __fractunsdqsi: Fixed-point fractional library routines. 43871 (line 1538) 43872 * __fractunsdqti: Fixed-point fractional library routines. 43873 (line 1541) 43874 * __fractunshadi: Fixed-point fractional library routines. 43875 (line 1545) 43876 * __fractunshahi: Fixed-point fractional library routines. 43877 (line 1543) 43878 * __fractunshaqi: Fixed-point fractional library routines. 43879 (line 1542) 43880 * __fractunshasi: Fixed-point fractional library routines. 43881 (line 1544) 43882 * __fractunshati: Fixed-point fractional library routines. 43883 (line 1546) 43884 * __fractunshida: Fixed-point fractional library routines. 43885 (line 1663) 43886 * __fractunshidq: Fixed-point fractional library routines. 43887 (line 1660) 43888 * __fractunshiha: Fixed-point fractional library routines. 43889 (line 1661) 43890 * __fractunshihq: Fixed-point fractional library routines. 43891 (line 1658) 43892 * __fractunshiqq: Fixed-point fractional library routines. 43893 (line 1657) 43894 * __fractunshisa: Fixed-point fractional library routines. 43895 (line 1662) 43896 * __fractunshisq: Fixed-point fractional library routines. 43897 (line 1659) 43898 * __fractunshita: Fixed-point fractional library routines. 43899 (line 1664) 43900 * __fractunshiuda: Fixed-point fractional library routines. 43901 (line 1676) 43902 * __fractunshiudq: Fixed-point fractional library routines. 43903 (line 1671) 43904 * __fractunshiuha: Fixed-point fractional library routines. 43905 (line 1673) 43906 * __fractunshiuhq: Fixed-point fractional library routines. 43907 (line 1667) 43908 * __fractunshiuqq: Fixed-point fractional library routines. 43909 (line 1666) 43910 * __fractunshiusa: Fixed-point fractional library routines. 43911 (line 1674) 43912 * __fractunshiusq: Fixed-point fractional library routines. 43913 (line 1669) 43914 * __fractunshiuta: Fixed-point fractional library routines. 43915 (line 1678) 43916 * __fractunshqdi: Fixed-point fractional library routines. 43917 (line 1529) 43918 * __fractunshqhi: Fixed-point fractional library routines. 43919 (line 1527) 43920 * __fractunshqqi: Fixed-point fractional library routines. 43921 (line 1526) 43922 * __fractunshqsi: Fixed-point fractional library routines. 43923 (line 1528) 43924 * __fractunshqti: Fixed-point fractional library routines. 43925 (line 1530) 43926 * __fractunsqida: Fixed-point fractional library routines. 43927 (line 1641) 43928 * __fractunsqidq: Fixed-point fractional library routines. 43929 (line 1638) 43930 * __fractunsqiha: Fixed-point fractional library routines. 43931 (line 1639) 43932 * __fractunsqihq: Fixed-point fractional library routines. 43933 (line 1636) 43934 * __fractunsqiqq: Fixed-point fractional library routines. 43935 (line 1635) 43936 * __fractunsqisa: Fixed-point fractional library routines. 43937 (line 1640) 43938 * __fractunsqisq: Fixed-point fractional library routines. 43939 (line 1637) 43940 * __fractunsqita: Fixed-point fractional library routines. 43941 (line 1642) 43942 * __fractunsqiuda: Fixed-point fractional library routines. 43943 (line 1654) 43944 * __fractunsqiudq: Fixed-point fractional library routines. 43945 (line 1649) 43946 * __fractunsqiuha: Fixed-point fractional library routines. 43947 (line 1651) 43948 * __fractunsqiuhq: Fixed-point fractional library routines. 43949 (line 1645) 43950 * __fractunsqiuqq: Fixed-point fractional library routines. 43951 (line 1644) 43952 * __fractunsqiusa: Fixed-point fractional library routines. 43953 (line 1652) 43954 * __fractunsqiusq: Fixed-point fractional library routines. 43955 (line 1647) 43956 * __fractunsqiuta: Fixed-point fractional library routines. 43957 (line 1656) 43958 * __fractunsqqdi: Fixed-point fractional library routines. 43959 (line 1524) 43960 * __fractunsqqhi: Fixed-point fractional library routines. 43961 (line 1522) 43962 * __fractunsqqqi: Fixed-point fractional library routines. 43963 (line 1521) 43964 * __fractunsqqsi: Fixed-point fractional library routines. 43965 (line 1523) 43966 * __fractunsqqti: Fixed-point fractional library routines. 43967 (line 1525) 43968 * __fractunssadi: Fixed-point fractional library routines. 43969 (line 1550) 43970 * __fractunssahi: Fixed-point fractional library routines. 43971 (line 1548) 43972 * __fractunssaqi: Fixed-point fractional library routines. 43973 (line 1547) 43974 * __fractunssasi: Fixed-point fractional library routines. 43975 (line 1549) 43976 * __fractunssati: Fixed-point fractional library routines. 43977 (line 1551) 43978 * __fractunssida: Fixed-point fractional library routines. 43979 (line 1685) 43980 * __fractunssidq: Fixed-point fractional library routines. 43981 (line 1682) 43982 * __fractunssiha: Fixed-point fractional library routines. 43983 (line 1683) 43984 * __fractunssihq: Fixed-point fractional library routines. 43985 (line 1680) 43986 * __fractunssiqq: Fixed-point fractional library routines. 43987 (line 1679) 43988 * __fractunssisa: Fixed-point fractional library routines. 43989 (line 1684) 43990 * __fractunssisq: Fixed-point fractional library routines. 43991 (line 1681) 43992 * __fractunssita: Fixed-point fractional library routines. 43993 (line 1686) 43994 * __fractunssiuda: Fixed-point fractional library routines. 43995 (line 1698) 43996 * __fractunssiudq: Fixed-point fractional library routines. 43997 (line 1693) 43998 * __fractunssiuha: Fixed-point fractional library routines. 43999 (line 1695) 44000 * __fractunssiuhq: Fixed-point fractional library routines. 44001 (line 1689) 44002 * __fractunssiuqq: Fixed-point fractional library routines. 44003 (line 1688) 44004 * __fractunssiusa: Fixed-point fractional library routines. 44005 (line 1696) 44006 * __fractunssiusq: Fixed-point fractional library routines. 44007 (line 1691) 44008 * __fractunssiuta: Fixed-point fractional library routines. 44009 (line 1700) 44010 * __fractunssqdi: Fixed-point fractional library routines. 44011 (line 1534) 44012 * __fractunssqhi: Fixed-point fractional library routines. 44013 (line 1532) 44014 * __fractunssqqi: Fixed-point fractional library routines. 44015 (line 1531) 44016 * __fractunssqsi: Fixed-point fractional library routines. 44017 (line 1533) 44018 * __fractunssqti: Fixed-point fractional library routines. 44019 (line 1535) 44020 * __fractunstadi: Fixed-point fractional library routines. 44021 (line 1560) 44022 * __fractunstahi: Fixed-point fractional library routines. 44023 (line 1558) 44024 * __fractunstaqi: Fixed-point fractional library routines. 44025 (line 1557) 44026 * __fractunstasi: Fixed-point fractional library routines. 44027 (line 1559) 44028 * __fractunstati: Fixed-point fractional library routines. 44029 (line 1562) 44030 * __fractunstida: Fixed-point fractional library routines. 44031 (line 1730) 44032 * __fractunstidq: Fixed-point fractional library routines. 44033 (line 1727) 44034 * __fractunstiha: Fixed-point fractional library routines. 44035 (line 1728) 44036 * __fractunstihq: Fixed-point fractional library routines. 44037 (line 1724) 44038 * __fractunstiqq: Fixed-point fractional library routines. 44039 (line 1723) 44040 * __fractunstisa: Fixed-point fractional library routines. 44041 (line 1729) 44042 * __fractunstisq: Fixed-point fractional library routines. 44043 (line 1725) 44044 * __fractunstita: Fixed-point fractional library routines. 44045 (line 1732) 44046 * __fractunstiuda: Fixed-point fractional library routines. 44047 (line 1746) 44048 * __fractunstiudq: Fixed-point fractional library routines. 44049 (line 1740) 44050 * __fractunstiuha: Fixed-point fractional library routines. 44051 (line 1742) 44052 * __fractunstiuhq: Fixed-point fractional library routines. 44053 (line 1736) 44054 * __fractunstiuqq: Fixed-point fractional library routines. 44055 (line 1734) 44056 * __fractunstiusa: Fixed-point fractional library routines. 44057 (line 1744) 44058 * __fractunstiusq: Fixed-point fractional library routines. 44059 (line 1738) 44060 * __fractunstiuta: Fixed-point fractional library routines. 44061 (line 1748) 44062 * __fractunsudadi: Fixed-point fractional library routines. 44063 (line 1622) 44064 * __fractunsudahi: Fixed-point fractional library routines. 44065 (line 1618) 44066 * __fractunsudaqi: Fixed-point fractional library routines. 44067 (line 1616) 44068 * __fractunsudasi: Fixed-point fractional library routines. 44069 (line 1620) 44070 * __fractunsudati: Fixed-point fractional library routines. 44071 (line 1624) 44072 * __fractunsudqdi: Fixed-point fractional library routines. 44073 (line 1596) 44074 * __fractunsudqhi: Fixed-point fractional library routines. 44075 (line 1592) 44076 * __fractunsudqqi: Fixed-point fractional library routines. 44077 (line 1590) 44078 * __fractunsudqsi: Fixed-point fractional library routines. 44079 (line 1594) 44080 * __fractunsudqti: Fixed-point fractional library routines. 44081 (line 1598) 44082 * __fractunsuhadi: Fixed-point fractional library routines. 44083 (line 1606) 44084 * __fractunsuhahi: Fixed-point fractional library routines. 44085 (line 1602) 44086 * __fractunsuhaqi: Fixed-point fractional library routines. 44087 (line 1600) 44088 * __fractunsuhasi: Fixed-point fractional library routines. 44089 (line 1604) 44090 * __fractunsuhati: Fixed-point fractional library routines. 44091 (line 1608) 44092 * __fractunsuhqdi: Fixed-point fractional library routines. 44093 (line 1576) 44094 * __fractunsuhqhi: Fixed-point fractional library routines. 44095 (line 1574) 44096 * __fractunsuhqqi: Fixed-point fractional library routines. 44097 (line 1573) 44098 * __fractunsuhqsi: Fixed-point fractional library routines. 44099 (line 1575) 44100 * __fractunsuhqti: Fixed-point fractional library routines. 44101 (line 1578) 44102 * __fractunsuqqdi: Fixed-point fractional library routines. 44103 (line 1570) 44104 * __fractunsuqqhi: Fixed-point fractional library routines. 44105 (line 1566) 44106 * __fractunsuqqqi: Fixed-point fractional library routines. 44107 (line 1564) 44108 * __fractunsuqqsi: Fixed-point fractional library routines. 44109 (line 1568) 44110 * __fractunsuqqti: Fixed-point fractional library routines. 44111 (line 1572) 44112 * __fractunsusadi: Fixed-point fractional library routines. 44113 (line 1612) 44114 * __fractunsusahi: Fixed-point fractional library routines. 44115 (line 1610) 44116 * __fractunsusaqi: Fixed-point fractional library routines. 44117 (line 1609) 44118 * __fractunsusasi: Fixed-point fractional library routines. 44119 (line 1611) 44120 * __fractunsusati: Fixed-point fractional library routines. 44121 (line 1614) 44122 * __fractunsusqdi: Fixed-point fractional library routines. 44123 (line 1586) 44124 * __fractunsusqhi: Fixed-point fractional library routines. 44125 (line 1582) 44126 * __fractunsusqqi: Fixed-point fractional library routines. 44127 (line 1580) 44128 * __fractunsusqsi: Fixed-point fractional library routines. 44129 (line 1584) 44130 * __fractunsusqti: Fixed-point fractional library routines. 44131 (line 1588) 44132 * __fractunsutadi: Fixed-point fractional library routines. 44133 (line 1632) 44134 * __fractunsutahi: Fixed-point fractional library routines. 44135 (line 1628) 44136 * __fractunsutaqi: Fixed-point fractional library routines. 44137 (line 1626) 44138 * __fractunsutasi: Fixed-point fractional library routines. 44139 (line 1630) 44140 * __fractunsutati: Fixed-point fractional library routines. 44141 (line 1634) 44142 * __fractuqqda: Fixed-point fractional library routines. 44143 (line 672) 44144 * __fractuqqdf: Fixed-point fractional library routines. 44145 (line 695) 44146 * __fractuqqdi: Fixed-point fractional library routines. 44147 (line 692) 44148 * __fractuqqdq: Fixed-point fractional library routines. 44149 (line 669) 44150 * __fractuqqha: Fixed-point fractional library routines. 44151 (line 670) 44152 * __fractuqqhi: Fixed-point fractional library routines. 44153 (line 690) 44154 * __fractuqqhq: Fixed-point fractional library routines. 44155 (line 666) 44156 * __fractuqqqi: Fixed-point fractional library routines. 44157 (line 689) 44158 * __fractuqqqq: Fixed-point fractional library routines. 44159 (line 665) 44160 * __fractuqqsa: Fixed-point fractional library routines. 44161 (line 671) 44162 * __fractuqqsf: Fixed-point fractional library routines. 44163 (line 694) 44164 * __fractuqqsi: Fixed-point fractional library routines. 44165 (line 691) 44166 * __fractuqqsq: Fixed-point fractional library routines. 44167 (line 667) 44168 * __fractuqqta: Fixed-point fractional library routines. 44169 (line 674) 44170 * __fractuqqti: Fixed-point fractional library routines. 44171 (line 693) 44172 * __fractuqquda: Fixed-point fractional library routines. 44173 (line 686) 44174 * __fractuqqudq2: Fixed-point fractional library routines. 44175 (line 680) 44176 * __fractuqquha: Fixed-point fractional library routines. 44177 (line 682) 44178 * __fractuqquhq2: Fixed-point fractional library routines. 44179 (line 676) 44180 * __fractuqqusa: Fixed-point fractional library routines. 44181 (line 684) 44182 * __fractuqqusq2: Fixed-point fractional library routines. 44183 (line 678) 44184 * __fractuqquta: Fixed-point fractional library routines. 44185 (line 688) 44186 * __fractusada: Fixed-point fractional library routines. 44187 (line 829) 44188 * __fractusadf: Fixed-point fractional library routines. 44189 (line 850) 44190 * __fractusadi: Fixed-point fractional library routines. 44191 (line 847) 44192 * __fractusadq: Fixed-point fractional library routines. 44193 (line 826) 44194 * __fractusaha: Fixed-point fractional library routines. 44195 (line 827) 44196 * __fractusahi: Fixed-point fractional library routines. 44197 (line 845) 44198 * __fractusahq: Fixed-point fractional library routines. 44199 (line 824) 44200 * __fractusaqi: Fixed-point fractional library routines. 44201 (line 844) 44202 * __fractusaqq: Fixed-point fractional library routines. 44203 (line 823) 44204 * __fractusasa: Fixed-point fractional library routines. 44205 (line 828) 44206 * __fractusasf: Fixed-point fractional library routines. 44207 (line 849) 44208 * __fractusasi: Fixed-point fractional library routines. 44209 (line 846) 44210 * __fractusasq: Fixed-point fractional library routines. 44211 (line 825) 44212 * __fractusata: Fixed-point fractional library routines. 44213 (line 830) 44214 * __fractusati: Fixed-point fractional library routines. 44215 (line 848) 44216 * __fractusauda2: Fixed-point fractional library routines. 44217 (line 841) 44218 * __fractusaudq: Fixed-point fractional library routines. 44219 (line 837) 44220 * __fractusauha2: Fixed-point fractional library routines. 44221 (line 839) 44222 * __fractusauhq: Fixed-point fractional library routines. 44223 (line 833) 44224 * __fractusauqq: Fixed-point fractional library routines. 44225 (line 832) 44226 * __fractusausq: Fixed-point fractional library routines. 44227 (line 835) 44228 * __fractusauta2: Fixed-point fractional library routines. 44229 (line 843) 44230 * __fractusqda: Fixed-point fractional library routines. 44231 (line 731) 44232 * __fractusqdf: Fixed-point fractional library routines. 44233 (line 754) 44234 * __fractusqdi: Fixed-point fractional library routines. 44235 (line 751) 44236 * __fractusqdq: Fixed-point fractional library routines. 44237 (line 728) 44238 * __fractusqha: Fixed-point fractional library routines. 44239 (line 729) 44240 * __fractusqhi: Fixed-point fractional library routines. 44241 (line 749) 44242 * __fractusqhq: Fixed-point fractional library routines. 44243 (line 725) 44244 * __fractusqqi: Fixed-point fractional library routines. 44245 (line 748) 44246 * __fractusqqq: Fixed-point fractional library routines. 44247 (line 724) 44248 * __fractusqsa: Fixed-point fractional library routines. 44249 (line 730) 44250 * __fractusqsf: Fixed-point fractional library routines. 44251 (line 753) 44252 * __fractusqsi: Fixed-point fractional library routines. 44253 (line 750) 44254 * __fractusqsq: Fixed-point fractional library routines. 44255 (line 726) 44256 * __fractusqta: Fixed-point fractional library routines. 44257 (line 733) 44258 * __fractusqti: Fixed-point fractional library routines. 44259 (line 752) 44260 * __fractusquda: Fixed-point fractional library routines. 44261 (line 745) 44262 * __fractusqudq2: Fixed-point fractional library routines. 44263 (line 739) 44264 * __fractusquha: Fixed-point fractional library routines. 44265 (line 741) 44266 * __fractusquhq2: Fixed-point fractional library routines. 44267 (line 737) 44268 * __fractusquqq2: Fixed-point fractional library routines. 44269 (line 735) 44270 * __fractusqusa: Fixed-point fractional library routines. 44271 (line 743) 44272 * __fractusquta: Fixed-point fractional library routines. 44273 (line 747) 44274 * __fractutada: Fixed-point fractional library routines. 44275 (line 893) 44276 * __fractutadf: Fixed-point fractional library routines. 44277 (line 918) 44278 * __fractutadi: Fixed-point fractional library routines. 44279 (line 914) 44280 * __fractutadq: Fixed-point fractional library routines. 44281 (line 888) 44282 * __fractutaha: Fixed-point fractional library routines. 44283 (line 890) 44284 * __fractutahi: Fixed-point fractional library routines. 44285 (line 912) 44286 * __fractutahq: Fixed-point fractional library routines. 44287 (line 884) 44288 * __fractutaqi: Fixed-point fractional library routines. 44289 (line 911) 44290 * __fractutaqq: Fixed-point fractional library routines. 44291 (line 883) 44292 * __fractutasa: Fixed-point fractional library routines. 44293 (line 891) 44294 * __fractutasf: Fixed-point fractional library routines. 44295 (line 917) 44296 * __fractutasi: Fixed-point fractional library routines. 44297 (line 913) 44298 * __fractutasq: Fixed-point fractional library routines. 44299 (line 886) 44300 * __fractutata: Fixed-point fractional library routines. 44301 (line 895) 44302 * __fractutati: Fixed-point fractional library routines. 44303 (line 916) 44304 * __fractutauda2: Fixed-point fractional library routines. 44305 (line 909) 44306 * __fractutaudq: Fixed-point fractional library routines. 44307 (line 903) 44308 * __fractutauha2: Fixed-point fractional library routines. 44309 (line 905) 44310 * __fractutauhq: Fixed-point fractional library routines. 44311 (line 899) 44312 * __fractutauqq: Fixed-point fractional library routines. 44313 (line 897) 44314 * __fractutausa2: Fixed-point fractional library routines. 44315 (line 907) 44316 * __fractutausq: Fixed-point fractional library routines. 44317 (line 901) 44318 * __gedf2: Soft float library routines. 44319 (line 206) 44320 * __gesf2: Soft float library routines. 44321 (line 205) 44322 * __getf2: Soft float library routines. 44323 (line 207) 44324 * __gtdf2: Soft float library routines. 44325 (line 224) 44326 * __gtsf2: Soft float library routines. 44327 (line 223) 44328 * __gttf2: Soft float library routines. 44329 (line 225) 44330 * __ledf2: Soft float library routines. 44331 (line 218) 44332 * __lesf2: Soft float library routines. 44333 (line 217) 44334 * __letf2: Soft float library routines. 44335 (line 219) 44336 * __lshrdi3: Integer library routines. 44337 (line 31) 44338 * __lshrsi3: Integer library routines. 44339 (line 30) 44340 * __lshrti3: Integer library routines. 44341 (line 32) 44342 * __lshruda3: Fixed-point fractional library routines. 44343 (line 390) 44344 * __lshrudq3: Fixed-point fractional library routines. 44345 (line 384) 44346 * __lshruha3: Fixed-point fractional library routines. 44347 (line 386) 44348 * __lshruhq3: Fixed-point fractional library routines. 44349 (line 380) 44350 * __lshruqq3: Fixed-point fractional library routines. 44351 (line 378) 44352 * __lshrusa3: Fixed-point fractional library routines. 44353 (line 388) 44354 * __lshrusq3: Fixed-point fractional library routines. 44355 (line 382) 44356 * __lshruta3: Fixed-point fractional library routines. 44357 (line 392) 44358 * __ltdf2: Soft float library routines. 44359 (line 212) 44360 * __ltsf2: Soft float library routines. 44361 (line 211) 44362 * __lttf2: Soft float library routines. 44363 (line 213) 44364 * __main: Collect2. (line 15) 44365 * __moddi3: Integer library routines. 44366 (line 37) 44367 * __modsi3: Integer library routines. 44368 (line 36) 44369 * __modti3: Integer library routines. 44370 (line 38) 44371 * __morestack_current_segment: Miscellaneous routines. 44372 (line 46) 44373 * __morestack_initial_sp: Miscellaneous routines. 44374 (line 47) 44375 * __morestack_segments: Miscellaneous routines. 44376 (line 45) 44377 * __mulda3: Fixed-point fractional library routines. 44378 (line 171) 44379 * __muldc3: Soft float library routines. 44380 (line 241) 44381 * __muldf3: Soft float library routines. 44382 (line 40) 44383 * __muldi3: Integer library routines. 44384 (line 43) 44385 * __muldq3: Fixed-point fractional library routines. 44386 (line 159) 44387 * __mulha3: Fixed-point fractional library routines. 44388 (line 169) 44389 * __mulhq3: Fixed-point fractional library routines. 44390 (line 156) 44391 * __mulqq3: Fixed-point fractional library routines. 44392 (line 155) 44393 * __mulsa3: Fixed-point fractional library routines. 44394 (line 170) 44395 * __mulsc3: Soft float library routines. 44396 (line 239) 44397 * __mulsf3: Soft float library routines. 44398 (line 39) 44399 * __mulsi3: Integer library routines. 44400 (line 42) 44401 * __mulsq3: Fixed-point fractional library routines. 44402 (line 157) 44403 * __multa3: Fixed-point fractional library routines. 44404 (line 173) 44405 * __multc3: Soft float library routines. 44406 (line 243) 44407 * __multf3: Soft float library routines. 44408 (line 42) 44409 * __multi3: Integer library routines. 44410 (line 44) 44411 * __muluda3: Fixed-point fractional library routines. 44412 (line 179) 44413 * __muludq3: Fixed-point fractional library routines. 44414 (line 167) 44415 * __muluha3: Fixed-point fractional library routines. 44416 (line 175) 44417 * __muluhq3: Fixed-point fractional library routines. 44418 (line 163) 44419 * __muluqq3: Fixed-point fractional library routines. 44420 (line 161) 44421 * __mulusa3: Fixed-point fractional library routines. 44422 (line 177) 44423 * __mulusq3: Fixed-point fractional library routines. 44424 (line 165) 44425 * __muluta3: Fixed-point fractional library routines. 44426 (line 181) 44427 * __mulvdi3: Integer library routines. 44428 (line 115) 44429 * __mulvsi3: Integer library routines. 44430 (line 114) 44431 * __mulxc3: Soft float library routines. 44432 (line 245) 44433 * __mulxf3: Soft float library routines. 44434 (line 44) 44435 * __nedf2: Soft float library routines. 44436 (line 200) 44437 * __negda2: Fixed-point fractional library routines. 44438 (line 299) 44439 * __negdf2: Soft float library routines. 44440 (line 56) 44441 * __negdi2: Integer library routines. 44442 (line 47) 44443 * __negdq2: Fixed-point fractional library routines. 44444 (line 289) 44445 * __negha2: Fixed-point fractional library routines. 44446 (line 297) 44447 * __neghq2: Fixed-point fractional library routines. 44448 (line 287) 44449 * __negqq2: Fixed-point fractional library routines. 44450 (line 286) 44451 * __negsa2: Fixed-point fractional library routines. 44452 (line 298) 44453 * __negsf2: Soft float library routines. 44454 (line 55) 44455 * __negsq2: Fixed-point fractional library routines. 44456 (line 288) 44457 * __negta2: Fixed-point fractional library routines. 44458 (line 300) 44459 * __negtf2: Soft float library routines. 44460 (line 57) 44461 * __negti2: Integer library routines. 44462 (line 48) 44463 * __neguda2: Fixed-point fractional library routines. 44464 (line 305) 44465 * __negudq2: Fixed-point fractional library routines. 44466 (line 296) 44467 * __neguha2: Fixed-point fractional library routines. 44468 (line 302) 44469 * __neguhq2: Fixed-point fractional library routines. 44470 (line 292) 44471 * __neguqq2: Fixed-point fractional library routines. 44472 (line 291) 44473 * __negusa2: Fixed-point fractional library routines. 44474 (line 303) 44475 * __negusq2: Fixed-point fractional library routines. 44476 (line 294) 44477 * __neguta2: Fixed-point fractional library routines. 44478 (line 307) 44479 * __negvdi2: Integer library routines. 44480 (line 119) 44481 * __negvsi2: Integer library routines. 44482 (line 118) 44483 * __negxf2: Soft float library routines. 44484 (line 58) 44485 * __nesf2: Soft float library routines. 44486 (line 199) 44487 * __netf2: Soft float library routines. 44488 (line 201) 44489 * __paritydi2: Integer library routines. 44490 (line 151) 44491 * __paritysi2: Integer library routines. 44492 (line 150) 44493 * __parityti2: Integer library routines. 44494 (line 152) 44495 * __popcountdi2: Integer library routines. 44496 (line 157) 44497 * __popcountsi2: Integer library routines. 44498 (line 156) 44499 * __popcountti2: Integer library routines. 44500 (line 158) 44501 * __powidf2: Soft float library routines. 44502 (line 233) 44503 * __powisf2: Soft float library routines. 44504 (line 232) 44505 * __powitf2: Soft float library routines. 44506 (line 234) 44507 * __powixf2: Soft float library routines. 44508 (line 235) 44509 * __satfractdadq: Fixed-point fractional library routines. 44510 (line 1153) 44511 * __satfractdaha2: Fixed-point fractional library routines. 44512 (line 1154) 44513 * __satfractdahq: Fixed-point fractional library routines. 44514 (line 1151) 44515 * __satfractdaqq: Fixed-point fractional library routines. 44516 (line 1150) 44517 * __satfractdasa2: Fixed-point fractional library routines. 44518 (line 1155) 44519 * __satfractdasq: Fixed-point fractional library routines. 44520 (line 1152) 44521 * __satfractdata2: Fixed-point fractional library routines. 44522 (line 1156) 44523 * __satfractdauda: Fixed-point fractional library routines. 44524 (line 1166) 44525 * __satfractdaudq: Fixed-point fractional library routines. 44526 (line 1162) 44527 * __satfractdauha: Fixed-point fractional library routines. 44528 (line 1164) 44529 * __satfractdauhq: Fixed-point fractional library routines. 44530 (line 1159) 44531 * __satfractdauqq: Fixed-point fractional library routines. 44532 (line 1158) 44533 * __satfractdausa: Fixed-point fractional library routines. 44534 (line 1165) 44535 * __satfractdausq: Fixed-point fractional library routines. 44536 (line 1160) 44537 * __satfractdauta: Fixed-point fractional library routines. 44538 (line 1168) 44539 * __satfractdfda: Fixed-point fractional library routines. 44540 (line 1506) 44541 * __satfractdfdq: Fixed-point fractional library routines. 44542 (line 1503) 44543 * __satfractdfha: Fixed-point fractional library routines. 44544 (line 1504) 44545 * __satfractdfhq: Fixed-point fractional library routines. 44546 (line 1501) 44547 * __satfractdfqq: Fixed-point fractional library routines. 44548 (line 1500) 44549 * __satfractdfsa: Fixed-point fractional library routines. 44550 (line 1505) 44551 * __satfractdfsq: Fixed-point fractional library routines. 44552 (line 1502) 44553 * __satfractdfta: Fixed-point fractional library routines. 44554 (line 1507) 44555 * __satfractdfuda: Fixed-point fractional library routines. 44556 (line 1515) 44557 * __satfractdfudq: Fixed-point fractional library routines. 44558 (line 1512) 44559 * __satfractdfuha: Fixed-point fractional library routines. 44560 (line 1513) 44561 * __satfractdfuhq: Fixed-point fractional library routines. 44562 (line 1509) 44563 * __satfractdfuqq: Fixed-point fractional library routines. 44564 (line 1508) 44565 * __satfractdfusa: Fixed-point fractional library routines. 44566 (line 1514) 44567 * __satfractdfusq: Fixed-point fractional library routines. 44568 (line 1510) 44569 * __satfractdfuta: Fixed-point fractional library routines. 44570 (line 1517) 44571 * __satfractdida: Fixed-point fractional library routines. 44572 (line 1456) 44573 * __satfractdidq: Fixed-point fractional library routines. 44574 (line 1453) 44575 * __satfractdiha: Fixed-point fractional library routines. 44576 (line 1454) 44577 * __satfractdihq: Fixed-point fractional library routines. 44578 (line 1451) 44579 * __satfractdiqq: Fixed-point fractional library routines. 44580 (line 1450) 44581 * __satfractdisa: Fixed-point fractional library routines. 44582 (line 1455) 44583 * __satfractdisq: Fixed-point fractional library routines. 44584 (line 1452) 44585 * __satfractdita: Fixed-point fractional library routines. 44586 (line 1457) 44587 * __satfractdiuda: Fixed-point fractional library routines. 44588 (line 1464) 44589 * __satfractdiudq: Fixed-point fractional library routines. 44590 (line 1461) 44591 * __satfractdiuha: Fixed-point fractional library routines. 44592 (line 1462) 44593 * __satfractdiuhq: Fixed-point fractional library routines. 44594 (line 1459) 44595 * __satfractdiuqq: Fixed-point fractional library routines. 44596 (line 1458) 44597 * __satfractdiusa: Fixed-point fractional library routines. 44598 (line 1463) 44599 * __satfractdiusq: Fixed-point fractional library routines. 44600 (line 1460) 44601 * __satfractdiuta: Fixed-point fractional library routines. 44602 (line 1465) 44603 * __satfractdqda: Fixed-point fractional library routines. 44604 (line 1098) 44605 * __satfractdqha: Fixed-point fractional library routines. 44606 (line 1096) 44607 * __satfractdqhq2: Fixed-point fractional library routines. 44608 (line 1094) 44609 * __satfractdqqq2: Fixed-point fractional library routines. 44610 (line 1093) 44611 * __satfractdqsa: Fixed-point fractional library routines. 44612 (line 1097) 44613 * __satfractdqsq2: Fixed-point fractional library routines. 44614 (line 1095) 44615 * __satfractdqta: Fixed-point fractional library routines. 44616 (line 1099) 44617 * __satfractdquda: Fixed-point fractional library routines. 44618 (line 1111) 44619 * __satfractdqudq: Fixed-point fractional library routines. 44620 (line 1106) 44621 * __satfractdquha: Fixed-point fractional library routines. 44622 (line 1108) 44623 * __satfractdquhq: Fixed-point fractional library routines. 44624 (line 1102) 44625 * __satfractdquqq: Fixed-point fractional library routines. 44626 (line 1101) 44627 * __satfractdqusa: Fixed-point fractional library routines. 44628 (line 1109) 44629 * __satfractdqusq: Fixed-point fractional library routines. 44630 (line 1104) 44631 * __satfractdquta: Fixed-point fractional library routines. 44632 (line 1113) 44633 * __satfracthada2: Fixed-point fractional library routines. 44634 (line 1119) 44635 * __satfracthadq: Fixed-point fractional library routines. 44636 (line 1117) 44637 * __satfracthahq: Fixed-point fractional library routines. 44638 (line 1115) 44639 * __satfracthaqq: Fixed-point fractional library routines. 44640 (line 1114) 44641 * __satfracthasa2: Fixed-point fractional library routines. 44642 (line 1118) 44643 * __satfracthasq: Fixed-point fractional library routines. 44644 (line 1116) 44645 * __satfracthata2: Fixed-point fractional library routines. 44646 (line 1120) 44647 * __satfracthauda: Fixed-point fractional library routines. 44648 (line 1132) 44649 * __satfracthaudq: Fixed-point fractional library routines. 44650 (line 1127) 44651 * __satfracthauha: Fixed-point fractional library routines. 44652 (line 1129) 44653 * __satfracthauhq: Fixed-point fractional library routines. 44654 (line 1123) 44655 * __satfracthauqq: Fixed-point fractional library routines. 44656 (line 1122) 44657 * __satfracthausa: Fixed-point fractional library routines. 44658 (line 1130) 44659 * __satfracthausq: Fixed-point fractional library routines. 44660 (line 1125) 44661 * __satfracthauta: Fixed-point fractional library routines. 44662 (line 1134) 44663 * __satfracthida: Fixed-point fractional library routines. 44664 (line 1424) 44665 * __satfracthidq: Fixed-point fractional library routines. 44666 (line 1421) 44667 * __satfracthiha: Fixed-point fractional library routines. 44668 (line 1422) 44669 * __satfracthihq: Fixed-point fractional library routines. 44670 (line 1419) 44671 * __satfracthiqq: Fixed-point fractional library routines. 44672 (line 1418) 44673 * __satfracthisa: Fixed-point fractional library routines. 44674 (line 1423) 44675 * __satfracthisq: Fixed-point fractional library routines. 44676 (line 1420) 44677 * __satfracthita: Fixed-point fractional library routines. 44678 (line 1425) 44679 * __satfracthiuda: Fixed-point fractional library routines. 44680 (line 1432) 44681 * __satfracthiudq: Fixed-point fractional library routines. 44682 (line 1429) 44683 * __satfracthiuha: Fixed-point fractional library routines. 44684 (line 1430) 44685 * __satfracthiuhq: Fixed-point fractional library routines. 44686 (line 1427) 44687 * __satfracthiuqq: Fixed-point fractional library routines. 44688 (line 1426) 44689 * __satfracthiusa: Fixed-point fractional library routines. 44690 (line 1431) 44691 * __satfracthiusq: Fixed-point fractional library routines. 44692 (line 1428) 44693 * __satfracthiuta: Fixed-point fractional library routines. 44694 (line 1433) 44695 * __satfracthqda: Fixed-point fractional library routines. 44696 (line 1064) 44697 * __satfracthqdq2: Fixed-point fractional library routines. 44698 (line 1061) 44699 * __satfracthqha: Fixed-point fractional library routines. 44700 (line 1062) 44701 * __satfracthqqq2: Fixed-point fractional library routines. 44702 (line 1059) 44703 * __satfracthqsa: Fixed-point fractional library routines. 44704 (line 1063) 44705 * __satfracthqsq2: Fixed-point fractional library routines. 44706 (line 1060) 44707 * __satfracthqta: Fixed-point fractional library routines. 44708 (line 1065) 44709 * __satfracthquda: Fixed-point fractional library routines. 44710 (line 1072) 44711 * __satfracthqudq: Fixed-point fractional library routines. 44712 (line 1069) 44713 * __satfracthquha: Fixed-point fractional library routines. 44714 (line 1070) 44715 * __satfracthquhq: Fixed-point fractional library routines. 44716 (line 1067) 44717 * __satfracthquqq: Fixed-point fractional library routines. 44718 (line 1066) 44719 * __satfracthqusa: Fixed-point fractional library routines. 44720 (line 1071) 44721 * __satfracthqusq: Fixed-point fractional library routines. 44722 (line 1068) 44723 * __satfracthquta: Fixed-point fractional library routines. 44724 (line 1073) 44725 * __satfractqida: Fixed-point fractional library routines. 44726 (line 1402) 44727 * __satfractqidq: Fixed-point fractional library routines. 44728 (line 1399) 44729 * __satfractqiha: Fixed-point fractional library routines. 44730 (line 1400) 44731 * __satfractqihq: Fixed-point fractional library routines. 44732 (line 1397) 44733 * __satfractqiqq: Fixed-point fractional library routines. 44734 (line 1396) 44735 * __satfractqisa: Fixed-point fractional library routines. 44736 (line 1401) 44737 * __satfractqisq: Fixed-point fractional library routines. 44738 (line 1398) 44739 * __satfractqita: Fixed-point fractional library routines. 44740 (line 1403) 44741 * __satfractqiuda: Fixed-point fractional library routines. 44742 (line 1415) 44743 * __satfractqiudq: Fixed-point fractional library routines. 44744 (line 1410) 44745 * __satfractqiuha: Fixed-point fractional library routines. 44746 (line 1412) 44747 * __satfractqiuhq: Fixed-point fractional library routines. 44748 (line 1406) 44749 * __satfractqiuqq: Fixed-point fractional library routines. 44750 (line 1405) 44751 * __satfractqiusa: Fixed-point fractional library routines. 44752 (line 1413) 44753 * __satfractqiusq: Fixed-point fractional library routines. 44754 (line 1408) 44755 * __satfractqiuta: Fixed-point fractional library routines. 44756 (line 1417) 44757 * __satfractqqda: Fixed-point fractional library routines. 44758 (line 1043) 44759 * __satfractqqdq2: Fixed-point fractional library routines. 44760 (line 1040) 44761 * __satfractqqha: Fixed-point fractional library routines. 44762 (line 1041) 44763 * __satfractqqhq2: Fixed-point fractional library routines. 44764 (line 1038) 44765 * __satfractqqsa: Fixed-point fractional library routines. 44766 (line 1042) 44767 * __satfractqqsq2: Fixed-point fractional library routines. 44768 (line 1039) 44769 * __satfractqqta: Fixed-point fractional library routines. 44770 (line 1044) 44771 * __satfractqquda: Fixed-point fractional library routines. 44772 (line 1056) 44773 * __satfractqqudq: Fixed-point fractional library routines. 44774 (line 1051) 44775 * __satfractqquha: Fixed-point fractional library routines. 44776 (line 1053) 44777 * __satfractqquhq: Fixed-point fractional library routines. 44778 (line 1047) 44779 * __satfractqquqq: Fixed-point fractional library routines. 44780 (line 1046) 44781 * __satfractqqusa: Fixed-point fractional library routines. 44782 (line 1054) 44783 * __satfractqqusq: Fixed-point fractional library routines. 44784 (line 1049) 44785 * __satfractqquta: Fixed-point fractional library routines. 44786 (line 1058) 44787 * __satfractsada2: Fixed-point fractional library routines. 44788 (line 1140) 44789 * __satfractsadq: Fixed-point fractional library routines. 44790 (line 1138) 44791 * __satfractsaha2: Fixed-point fractional library routines. 44792 (line 1139) 44793 * __satfractsahq: Fixed-point fractional library routines. 44794 (line 1136) 44795 * __satfractsaqq: Fixed-point fractional library routines. 44796 (line 1135) 44797 * __satfractsasq: Fixed-point fractional library routines. 44798 (line 1137) 44799 * __satfractsata2: Fixed-point fractional library routines. 44800 (line 1141) 44801 * __satfractsauda: Fixed-point fractional library routines. 44802 (line 1148) 44803 * __satfractsaudq: Fixed-point fractional library routines. 44804 (line 1145) 44805 * __satfractsauha: Fixed-point fractional library routines. 44806 (line 1146) 44807 * __satfractsauhq: Fixed-point fractional library routines. 44808 (line 1143) 44809 * __satfractsauqq: Fixed-point fractional library routines. 44810 (line 1142) 44811 * __satfractsausa: Fixed-point fractional library routines. 44812 (line 1147) 44813 * __satfractsausq: Fixed-point fractional library routines. 44814 (line 1144) 44815 * __satfractsauta: Fixed-point fractional library routines. 44816 (line 1149) 44817 * __satfractsfda: Fixed-point fractional library routines. 44818 (line 1490) 44819 * __satfractsfdq: Fixed-point fractional library routines. 44820 (line 1487) 44821 * __satfractsfha: Fixed-point fractional library routines. 44822 (line 1488) 44823 * __satfractsfhq: Fixed-point fractional library routines. 44824 (line 1485) 44825 * __satfractsfqq: Fixed-point fractional library routines. 44826 (line 1484) 44827 * __satfractsfsa: Fixed-point fractional library routines. 44828 (line 1489) 44829 * __satfractsfsq: Fixed-point fractional library routines. 44830 (line 1486) 44831 * __satfractsfta: Fixed-point fractional library routines. 44832 (line 1491) 44833 * __satfractsfuda: Fixed-point fractional library routines. 44834 (line 1498) 44835 * __satfractsfudq: Fixed-point fractional library routines. 44836 (line 1495) 44837 * __satfractsfuha: Fixed-point fractional library routines. 44838 (line 1496) 44839 * __satfractsfuhq: Fixed-point fractional library routines. 44840 (line 1493) 44841 * __satfractsfuqq: Fixed-point fractional library routines. 44842 (line 1492) 44843 * __satfractsfusa: Fixed-point fractional library routines. 44844 (line 1497) 44845 * __satfractsfusq: Fixed-point fractional library routines. 44846 (line 1494) 44847 * __satfractsfuta: Fixed-point fractional library routines. 44848 (line 1499) 44849 * __satfractsida: Fixed-point fractional library routines. 44850 (line 1440) 44851 * __satfractsidq: Fixed-point fractional library routines. 44852 (line 1437) 44853 * __satfractsiha: Fixed-point fractional library routines. 44854 (line 1438) 44855 * __satfractsihq: Fixed-point fractional library routines. 44856 (line 1435) 44857 * __satfractsiqq: Fixed-point fractional library routines. 44858 (line 1434) 44859 * __satfractsisa: Fixed-point fractional library routines. 44860 (line 1439) 44861 * __satfractsisq: Fixed-point fractional library routines. 44862 (line 1436) 44863 * __satfractsita: Fixed-point fractional library routines. 44864 (line 1441) 44865 * __satfractsiuda: Fixed-point fractional library routines. 44866 (line 1448) 44867 * __satfractsiudq: Fixed-point fractional library routines. 44868 (line 1445) 44869 * __satfractsiuha: Fixed-point fractional library routines. 44870 (line 1446) 44871 * __satfractsiuhq: Fixed-point fractional library routines. 44872 (line 1443) 44873 * __satfractsiuqq: Fixed-point fractional library routines. 44874 (line 1442) 44875 * __satfractsiusa: Fixed-point fractional library routines. 44876 (line 1447) 44877 * __satfractsiusq: Fixed-point fractional library routines. 44878 (line 1444) 44879 * __satfractsiuta: Fixed-point fractional library routines. 44880 (line 1449) 44881 * __satfractsqda: Fixed-point fractional library routines. 44882 (line 1079) 44883 * __satfractsqdq2: Fixed-point fractional library routines. 44884 (line 1076) 44885 * __satfractsqha: Fixed-point fractional library routines. 44886 (line 1077) 44887 * __satfractsqhq2: Fixed-point fractional library routines. 44888 (line 1075) 44889 * __satfractsqqq2: Fixed-point fractional library routines. 44890 (line 1074) 44891 * __satfractsqsa: Fixed-point fractional library routines. 44892 (line 1078) 44893 * __satfractsqta: Fixed-point fractional library routines. 44894 (line 1080) 44895 * __satfractsquda: Fixed-point fractional library routines. 44896 (line 1090) 44897 * __satfractsqudq: Fixed-point fractional library routines. 44898 (line 1086) 44899 * __satfractsquha: Fixed-point fractional library routines. 44900 (line 1088) 44901 * __satfractsquhq: Fixed-point fractional library routines. 44902 (line 1083) 44903 * __satfractsquqq: Fixed-point fractional library routines. 44904 (line 1082) 44905 * __satfractsqusa: Fixed-point fractional library routines. 44906 (line 1089) 44907 * __satfractsqusq: Fixed-point fractional library routines. 44908 (line 1084) 44909 * __satfractsquta: Fixed-point fractional library routines. 44910 (line 1092) 44911 * __satfracttada2: Fixed-point fractional library routines. 44912 (line 1175) 44913 * __satfracttadq: Fixed-point fractional library routines. 44914 (line 1172) 44915 * __satfracttaha2: Fixed-point fractional library routines. 44916 (line 1173) 44917 * __satfracttahq: Fixed-point fractional library routines. 44918 (line 1170) 44919 * __satfracttaqq: Fixed-point fractional library routines. 44920 (line 1169) 44921 * __satfracttasa2: Fixed-point fractional library routines. 44922 (line 1174) 44923 * __satfracttasq: Fixed-point fractional library routines. 44924 (line 1171) 44925 * __satfracttauda: Fixed-point fractional library routines. 44926 (line 1187) 44927 * __satfracttaudq: Fixed-point fractional library routines. 44928 (line 1182) 44929 * __satfracttauha: Fixed-point fractional library routines. 44930 (line 1184) 44931 * __satfracttauhq: Fixed-point fractional library routines. 44932 (line 1178) 44933 * __satfracttauqq: Fixed-point fractional library routines. 44934 (line 1177) 44935 * __satfracttausa: Fixed-point fractional library routines. 44936 (line 1185) 44937 * __satfracttausq: Fixed-point fractional library routines. 44938 (line 1180) 44939 * __satfracttauta: Fixed-point fractional library routines. 44940 (line 1189) 44941 * __satfracttida: Fixed-point fractional library routines. 44942 (line 1472) 44943 * __satfracttidq: Fixed-point fractional library routines. 44944 (line 1469) 44945 * __satfracttiha: Fixed-point fractional library routines. 44946 (line 1470) 44947 * __satfracttihq: Fixed-point fractional library routines. 44948 (line 1467) 44949 * __satfracttiqq: Fixed-point fractional library routines. 44950 (line 1466) 44951 * __satfracttisa: Fixed-point fractional library routines. 44952 (line 1471) 44953 * __satfracttisq: Fixed-point fractional library routines. 44954 (line 1468) 44955 * __satfracttita: Fixed-point fractional library routines. 44956 (line 1473) 44957 * __satfracttiuda: Fixed-point fractional library routines. 44958 (line 1481) 44959 * __satfracttiudq: Fixed-point fractional library routines. 44960 (line 1478) 44961 * __satfracttiuha: Fixed-point fractional library routines. 44962 (line 1479) 44963 * __satfracttiuhq: Fixed-point fractional library routines. 44964 (line 1475) 44965 * __satfracttiuqq: Fixed-point fractional library routines. 44966 (line 1474) 44967 * __satfracttiusa: Fixed-point fractional library routines. 44968 (line 1480) 44969 * __satfracttiusq: Fixed-point fractional library routines. 44970 (line 1476) 44971 * __satfracttiuta: Fixed-point fractional library routines. 44972 (line 1483) 44973 * __satfractudada: Fixed-point fractional library routines. 44974 (line 1351) 44975 * __satfractudadq: Fixed-point fractional library routines. 44976 (line 1347) 44977 * __satfractudaha: Fixed-point fractional library routines. 44978 (line 1349) 44979 * __satfractudahq: Fixed-point fractional library routines. 44980 (line 1344) 44981 * __satfractudaqq: Fixed-point fractional library routines. 44982 (line 1343) 44983 * __satfractudasa: Fixed-point fractional library routines. 44984 (line 1350) 44985 * __satfractudasq: Fixed-point fractional library routines. 44986 (line 1345) 44987 * __satfractudata: Fixed-point fractional library routines. 44988 (line 1353) 44989 * __satfractudaudq: Fixed-point fractional library routines. 44990 (line 1361) 44991 * __satfractudauha2: Fixed-point fractional library routines. 44992 (line 1363) 44993 * __satfractudauhq: Fixed-point fractional library routines. 44994 (line 1357) 44995 * __satfractudauqq: Fixed-point fractional library routines. 44996 (line 1355) 44997 * __satfractudausa2: Fixed-point fractional library routines. 44998 (line 1365) 44999 * __satfractudausq: Fixed-point fractional library routines. 45000 (line 1359) 45001 * __satfractudauta2: Fixed-point fractional library routines. 45002 (line 1367) 45003 * __satfractudqda: Fixed-point fractional library routines. 45004 (line 1276) 45005 * __satfractudqdq: Fixed-point fractional library routines. 45006 (line 1271) 45007 * __satfractudqha: Fixed-point fractional library routines. 45008 (line 1273) 45009 * __satfractudqhq: Fixed-point fractional library routines. 45010 (line 1267) 45011 * __satfractudqqq: Fixed-point fractional library routines. 45012 (line 1266) 45013 * __satfractudqsa: Fixed-point fractional library routines. 45014 (line 1274) 45015 * __satfractudqsq: Fixed-point fractional library routines. 45016 (line 1269) 45017 * __satfractudqta: Fixed-point fractional library routines. 45018 (line 1278) 45019 * __satfractudquda: Fixed-point fractional library routines. 45020 (line 1290) 45021 * __satfractudquha: Fixed-point fractional library routines. 45022 (line 1286) 45023 * __satfractudquhq2: Fixed-point fractional library routines. 45024 (line 1282) 45025 * __satfractudquqq2: Fixed-point fractional library routines. 45026 (line 1280) 45027 * __satfractudqusa: Fixed-point fractional library routines. 45028 (line 1288) 45029 * __satfractudqusq2: Fixed-point fractional library routines. 45030 (line 1284) 45031 * __satfractudquta: Fixed-point fractional library routines. 45032 (line 1292) 45033 * __satfractuhada: Fixed-point fractional library routines. 45034 (line 1304) 45035 * __satfractuhadq: Fixed-point fractional library routines. 45036 (line 1299) 45037 * __satfractuhaha: Fixed-point fractional library routines. 45038 (line 1301) 45039 * __satfractuhahq: Fixed-point fractional library routines. 45040 (line 1295) 45041 * __satfractuhaqq: Fixed-point fractional library routines. 45042 (line 1294) 45043 * __satfractuhasa: Fixed-point fractional library routines. 45044 (line 1302) 45045 * __satfractuhasq: Fixed-point fractional library routines. 45046 (line 1297) 45047 * __satfractuhata: Fixed-point fractional library routines. 45048 (line 1306) 45049 * __satfractuhauda2: Fixed-point fractional library routines. 45050 (line 1318) 45051 * __satfractuhaudq: Fixed-point fractional library routines. 45052 (line 1314) 45053 * __satfractuhauhq: Fixed-point fractional library routines. 45054 (line 1310) 45055 * __satfractuhauqq: Fixed-point fractional library routines. 45056 (line 1308) 45057 * __satfractuhausa2: Fixed-point fractional library routines. 45058 (line 1316) 45059 * __satfractuhausq: Fixed-point fractional library routines. 45060 (line 1312) 45061 * __satfractuhauta2: Fixed-point fractional library routines. 45062 (line 1320) 45063 * __satfractuhqda: Fixed-point fractional library routines. 45064 (line 1224) 45065 * __satfractuhqdq: Fixed-point fractional library routines. 45066 (line 1221) 45067 * __satfractuhqha: Fixed-point fractional library routines. 45068 (line 1222) 45069 * __satfractuhqhq: Fixed-point fractional library routines. 45070 (line 1219) 45071 * __satfractuhqqq: Fixed-point fractional library routines. 45072 (line 1218) 45073 * __satfractuhqsa: Fixed-point fractional library routines. 45074 (line 1223) 45075 * __satfractuhqsq: Fixed-point fractional library routines. 45076 (line 1220) 45077 * __satfractuhqta: Fixed-point fractional library routines. 45078 (line 1225) 45079 * __satfractuhquda: Fixed-point fractional library routines. 45080 (line 1236) 45081 * __satfractuhqudq2: Fixed-point fractional library routines. 45082 (line 1231) 45083 * __satfractuhquha: Fixed-point fractional library routines. 45084 (line 1233) 45085 * __satfractuhquqq2: Fixed-point fractional library routines. 45086 (line 1227) 45087 * __satfractuhqusa: Fixed-point fractional library routines. 45088 (line 1234) 45089 * __satfractuhqusq2: Fixed-point fractional library routines. 45090 (line 1229) 45091 * __satfractuhquta: Fixed-point fractional library routines. 45092 (line 1238) 45093 * __satfractunsdida: Fixed-point fractional library routines. 45094 (line 1834) 45095 * __satfractunsdidq: Fixed-point fractional library routines. 45096 (line 1831) 45097 * __satfractunsdiha: Fixed-point fractional library routines. 45098 (line 1832) 45099 * __satfractunsdihq: Fixed-point fractional library routines. 45100 (line 1828) 45101 * __satfractunsdiqq: Fixed-point fractional library routines. 45102 (line 1827) 45103 * __satfractunsdisa: Fixed-point fractional library routines. 45104 (line 1833) 45105 * __satfractunsdisq: Fixed-point fractional library routines. 45106 (line 1829) 45107 * __satfractunsdita: Fixed-point fractional library routines. 45108 (line 1836) 45109 * __satfractunsdiuda: Fixed-point fractional library routines. 45110 (line 1850) 45111 * __satfractunsdiudq: Fixed-point fractional library routines. 45112 (line 1844) 45113 * __satfractunsdiuha: Fixed-point fractional library routines. 45114 (line 1846) 45115 * __satfractunsdiuhq: Fixed-point fractional library routines. 45116 (line 1840) 45117 * __satfractunsdiuqq: Fixed-point fractional library routines. 45118 (line 1838) 45119 * __satfractunsdiusa: Fixed-point fractional library routines. 45120 (line 1848) 45121 * __satfractunsdiusq: Fixed-point fractional library routines. 45122 (line 1842) 45123 * __satfractunsdiuta: Fixed-point fractional library routines. 45124 (line 1852) 45125 * __satfractunshida: Fixed-point fractional library routines. 45126 (line 1786) 45127 * __satfractunshidq: Fixed-point fractional library routines. 45128 (line 1783) 45129 * __satfractunshiha: Fixed-point fractional library routines. 45130 (line 1784) 45131 * __satfractunshihq: Fixed-point fractional library routines. 45132 (line 1780) 45133 * __satfractunshiqq: Fixed-point fractional library routines. 45134 (line 1779) 45135 * __satfractunshisa: Fixed-point fractional library routines. 45136 (line 1785) 45137 * __satfractunshisq: Fixed-point fractional library routines. 45138 (line 1781) 45139 * __satfractunshita: Fixed-point fractional library routines. 45140 (line 1788) 45141 * __satfractunshiuda: Fixed-point fractional library routines. 45142 (line 1802) 45143 * __satfractunshiudq: Fixed-point fractional library routines. 45144 (line 1796) 45145 * __satfractunshiuha: Fixed-point fractional library routines. 45146 (line 1798) 45147 * __satfractunshiuhq: Fixed-point fractional library routines. 45148 (line 1792) 45149 * __satfractunshiuqq: Fixed-point fractional library routines. 45150 (line 1790) 45151 * __satfractunshiusa: Fixed-point fractional library routines. 45152 (line 1800) 45153 * __satfractunshiusq: Fixed-point fractional library routines. 45154 (line 1794) 45155 * __satfractunshiuta: Fixed-point fractional library routines. 45156 (line 1804) 45157 * __satfractunsqida: Fixed-point fractional library routines. 45158 (line 1760) 45159 * __satfractunsqidq: Fixed-point fractional library routines. 45160 (line 1757) 45161 * __satfractunsqiha: Fixed-point fractional library routines. 45162 (line 1758) 45163 * __satfractunsqihq: Fixed-point fractional library routines. 45164 (line 1754) 45165 * __satfractunsqiqq: Fixed-point fractional library routines. 45166 (line 1753) 45167 * __satfractunsqisa: Fixed-point fractional library routines. 45168 (line 1759) 45169 * __satfractunsqisq: Fixed-point fractional library routines. 45170 (line 1755) 45171 * __satfractunsqita: Fixed-point fractional library routines. 45172 (line 1762) 45173 * __satfractunsqiuda: Fixed-point fractional library routines. 45174 (line 1776) 45175 * __satfractunsqiudq: Fixed-point fractional library routines. 45176 (line 1770) 45177 * __satfractunsqiuha: Fixed-point fractional library routines. 45178 (line 1772) 45179 * __satfractunsqiuhq: Fixed-point fractional library routines. 45180 (line 1766) 45181 * __satfractunsqiuqq: Fixed-point fractional library routines. 45182 (line 1764) 45183 * __satfractunsqiusa: Fixed-point fractional library routines. 45184 (line 1774) 45185 * __satfractunsqiusq: Fixed-point fractional library routines. 45186 (line 1768) 45187 * __satfractunsqiuta: Fixed-point fractional library routines. 45188 (line 1778) 45189 * __satfractunssida: Fixed-point fractional library routines. 45190 (line 1811) 45191 * __satfractunssidq: Fixed-point fractional library routines. 45192 (line 1808) 45193 * __satfractunssiha: Fixed-point fractional library routines. 45194 (line 1809) 45195 * __satfractunssihq: Fixed-point fractional library routines. 45196 (line 1806) 45197 * __satfractunssiqq: Fixed-point fractional library routines. 45198 (line 1805) 45199 * __satfractunssisa: Fixed-point fractional library routines. 45200 (line 1810) 45201 * __satfractunssisq: Fixed-point fractional library routines. 45202 (line 1807) 45203 * __satfractunssita: Fixed-point fractional library routines. 45204 (line 1812) 45205 * __satfractunssiuda: Fixed-point fractional library routines. 45206 (line 1824) 45207 * __satfractunssiudq: Fixed-point fractional library routines. 45208 (line 1819) 45209 * __satfractunssiuha: Fixed-point fractional library routines. 45210 (line 1821) 45211 * __satfractunssiuhq: Fixed-point fractional library routines. 45212 (line 1815) 45213 * __satfractunssiuqq: Fixed-point fractional library routines. 45214 (line 1814) 45215 * __satfractunssiusa: Fixed-point fractional library routines. 45216 (line 1822) 45217 * __satfractunssiusq: Fixed-point fractional library routines. 45218 (line 1817) 45219 * __satfractunssiuta: Fixed-point fractional library routines. 45220 (line 1826) 45221 * __satfractunstida: Fixed-point fractional library routines. 45222 (line 1864) 45223 * __satfractunstidq: Fixed-point fractional library routines. 45224 (line 1859) 45225 * __satfractunstiha: Fixed-point fractional library routines. 45226 (line 1861) 45227 * __satfractunstihq: Fixed-point fractional library routines. 45228 (line 1855) 45229 * __satfractunstiqq: Fixed-point fractional library routines. 45230 (line 1854) 45231 * __satfractunstisa: Fixed-point fractional library routines. 45232 (line 1862) 45233 * __satfractunstisq: Fixed-point fractional library routines. 45234 (line 1857) 45235 * __satfractunstita: Fixed-point fractional library routines. 45236 (line 1866) 45237 * __satfractunstiuda: Fixed-point fractional library routines. 45238 (line 1880) 45239 * __satfractunstiudq: Fixed-point fractional library routines. 45240 (line 1874) 45241 * __satfractunstiuha: Fixed-point fractional library routines. 45242 (line 1876) 45243 * __satfractunstiuhq: Fixed-point fractional library routines. 45244 (line 1870) 45245 * __satfractunstiuqq: Fixed-point fractional library routines. 45246 (line 1868) 45247 * __satfractunstiusa: Fixed-point fractional library routines. 45248 (line 1878) 45249 * __satfractunstiusq: Fixed-point fractional library routines. 45250 (line 1872) 45251 * __satfractunstiuta: Fixed-point fractional library routines. 45252 (line 1882) 45253 * __satfractuqqda: Fixed-point fractional library routines. 45254 (line 1201) 45255 * __satfractuqqdq: Fixed-point fractional library routines. 45256 (line 1196) 45257 * __satfractuqqha: Fixed-point fractional library routines. 45258 (line 1198) 45259 * __satfractuqqhq: Fixed-point fractional library routines. 45260 (line 1192) 45261 * __satfractuqqqq: Fixed-point fractional library routines. 45262 (line 1191) 45263 * __satfractuqqsa: Fixed-point fractional library routines. 45264 (line 1199) 45265 * __satfractuqqsq: Fixed-point fractional library routines. 45266 (line 1194) 45267 * __satfractuqqta: Fixed-point fractional library routines. 45268 (line 1203) 45269 * __satfractuqquda: Fixed-point fractional library routines. 45270 (line 1215) 45271 * __satfractuqqudq2: Fixed-point fractional library routines. 45272 (line 1209) 45273 * __satfractuqquha: Fixed-point fractional library routines. 45274 (line 1211) 45275 * __satfractuqquhq2: Fixed-point fractional library routines. 45276 (line 1205) 45277 * __satfractuqqusa: Fixed-point fractional library routines. 45278 (line 1213) 45279 * __satfractuqqusq2: Fixed-point fractional library routines. 45280 (line 1207) 45281 * __satfractuqquta: Fixed-point fractional library routines. 45282 (line 1217) 45283 * __satfractusada: Fixed-point fractional library routines. 45284 (line 1327) 45285 * __satfractusadq: Fixed-point fractional library routines. 45286 (line 1324) 45287 * __satfractusaha: Fixed-point fractional library routines. 45288 (line 1325) 45289 * __satfractusahq: Fixed-point fractional library routines. 45290 (line 1322) 45291 * __satfractusaqq: Fixed-point fractional library routines. 45292 (line 1321) 45293 * __satfractusasa: Fixed-point fractional library routines. 45294 (line 1326) 45295 * __satfractusasq: Fixed-point fractional library routines. 45296 (line 1323) 45297 * __satfractusata: Fixed-point fractional library routines. 45298 (line 1328) 45299 * __satfractusauda2: Fixed-point fractional library routines. 45300 (line 1339) 45301 * __satfractusaudq: Fixed-point fractional library routines. 45302 (line 1335) 45303 * __satfractusauha2: Fixed-point fractional library routines. 45304 (line 1337) 45305 * __satfractusauhq: Fixed-point fractional library routines. 45306 (line 1331) 45307 * __satfractusauqq: Fixed-point fractional library routines. 45308 (line 1330) 45309 * __satfractusausq: Fixed-point fractional library routines. 45310 (line 1333) 45311 * __satfractusauta2: Fixed-point fractional library routines. 45312 (line 1341) 45313 * __satfractusqda: Fixed-point fractional library routines. 45314 (line 1248) 45315 * __satfractusqdq: Fixed-point fractional library routines. 45316 (line 1244) 45317 * __satfractusqha: Fixed-point fractional library routines. 45318 (line 1246) 45319 * __satfractusqhq: Fixed-point fractional library routines. 45320 (line 1241) 45321 * __satfractusqqq: Fixed-point fractional library routines. 45322 (line 1240) 45323 * __satfractusqsa: Fixed-point fractional library routines. 45324 (line 1247) 45325 * __satfractusqsq: Fixed-point fractional library routines. 45326 (line 1242) 45327 * __satfractusqta: Fixed-point fractional library routines. 45328 (line 1250) 45329 * __satfractusquda: Fixed-point fractional library routines. 45330 (line 1262) 45331 * __satfractusqudq2: Fixed-point fractional library routines. 45332 (line 1256) 45333 * __satfractusquha: Fixed-point fractional library routines. 45334 (line 1258) 45335 * __satfractusquhq2: Fixed-point fractional library routines. 45336 (line 1254) 45337 * __satfractusquqq2: Fixed-point fractional library routines. 45338 (line 1252) 45339 * __satfractusqusa: Fixed-point fractional library routines. 45340 (line 1260) 45341 * __satfractusquta: Fixed-point fractional library routines. 45342 (line 1264) 45343 * __satfractutada: Fixed-point fractional library routines. 45344 (line 1379) 45345 * __satfractutadq: Fixed-point fractional library routines. 45346 (line 1374) 45347 * __satfractutaha: Fixed-point fractional library routines. 45348 (line 1376) 45349 * __satfractutahq: Fixed-point fractional library routines. 45350 (line 1370) 45351 * __satfractutaqq: Fixed-point fractional library routines. 45352 (line 1369) 45353 * __satfractutasa: Fixed-point fractional library routines. 45354 (line 1377) 45355 * __satfractutasq: Fixed-point fractional library routines. 45356 (line 1372) 45357 * __satfractutata: Fixed-point fractional library routines. 45358 (line 1381) 45359 * __satfractutauda2: Fixed-point fractional library routines. 45360 (line 1395) 45361 * __satfractutaudq: Fixed-point fractional library routines. 45362 (line 1389) 45363 * __satfractutauha2: Fixed-point fractional library routines. 45364 (line 1391) 45365 * __satfractutauhq: Fixed-point fractional library routines. 45366 (line 1385) 45367 * __satfractutauqq: Fixed-point fractional library routines. 45368 (line 1383) 45369 * __satfractutausa2: Fixed-point fractional library routines. 45370 (line 1393) 45371 * __satfractutausq: Fixed-point fractional library routines. 45372 (line 1387) 45373 * __splitstack_find: Miscellaneous routines. 45374 (line 18) 45375 * __ssaddda3: Fixed-point fractional library routines. 45376 (line 67) 45377 * __ssadddq3: Fixed-point fractional library routines. 45378 (line 63) 45379 * __ssaddha3: Fixed-point fractional library routines. 45380 (line 65) 45381 * __ssaddhq3: Fixed-point fractional library routines. 45382 (line 60) 45383 * __ssaddqq3: Fixed-point fractional library routines. 45384 (line 59) 45385 * __ssaddsa3: Fixed-point fractional library routines. 45386 (line 66) 45387 * __ssaddsq3: Fixed-point fractional library routines. 45388 (line 61) 45389 * __ssaddta3: Fixed-point fractional library routines. 45390 (line 69) 45391 * __ssashlda3: Fixed-point fractional library routines. 45392 (line 402) 45393 * __ssashldq3: Fixed-point fractional library routines. 45394 (line 399) 45395 * __ssashlha3: Fixed-point fractional library routines. 45396 (line 400) 45397 * __ssashlhq3: Fixed-point fractional library routines. 45398 (line 396) 45399 * __ssashlsa3: Fixed-point fractional library routines. 45400 (line 401) 45401 * __ssashlsq3: Fixed-point fractional library routines. 45402 (line 397) 45403 * __ssashlta3: Fixed-point fractional library routines. 45404 (line 404) 45405 * __ssdivda3: Fixed-point fractional library routines. 45406 (line 261) 45407 * __ssdivdq3: Fixed-point fractional library routines. 45408 (line 257) 45409 * __ssdivha3: Fixed-point fractional library routines. 45410 (line 259) 45411 * __ssdivhq3: Fixed-point fractional library routines. 45412 (line 254) 45413 * __ssdivqq3: Fixed-point fractional library routines. 45414 (line 253) 45415 * __ssdivsa3: Fixed-point fractional library routines. 45416 (line 260) 45417 * __ssdivsq3: Fixed-point fractional library routines. 45418 (line 255) 45419 * __ssdivta3: Fixed-point fractional library routines. 45420 (line 263) 45421 * __ssmulda3: Fixed-point fractional library routines. 45422 (line 193) 45423 * __ssmuldq3: Fixed-point fractional library routines. 45424 (line 189) 45425 * __ssmulha3: Fixed-point fractional library routines. 45426 (line 191) 45427 * __ssmulhq3: Fixed-point fractional library routines. 45428 (line 186) 45429 * __ssmulqq3: Fixed-point fractional library routines. 45430 (line 185) 45431 * __ssmulsa3: Fixed-point fractional library routines. 45432 (line 192) 45433 * __ssmulsq3: Fixed-point fractional library routines. 45434 (line 187) 45435 * __ssmulta3: Fixed-point fractional library routines. 45436 (line 195) 45437 * __ssnegda2: Fixed-point fractional library routines. 45438 (line 316) 45439 * __ssnegdq2: Fixed-point fractional library routines. 45440 (line 313) 45441 * __ssnegha2: Fixed-point fractional library routines. 45442 (line 314) 45443 * __ssneghq2: Fixed-point fractional library routines. 45444 (line 311) 45445 * __ssnegqq2: Fixed-point fractional library routines. 45446 (line 310) 45447 * __ssnegsa2: Fixed-point fractional library routines. 45448 (line 315) 45449 * __ssnegsq2: Fixed-point fractional library routines. 45450 (line 312) 45451 * __ssnegta2: Fixed-point fractional library routines. 45452 (line 317) 45453 * __sssubda3: Fixed-point fractional library routines. 45454 (line 129) 45455 * __sssubdq3: Fixed-point fractional library routines. 45456 (line 125) 45457 * __sssubha3: Fixed-point fractional library routines. 45458 (line 127) 45459 * __sssubhq3: Fixed-point fractional library routines. 45460 (line 122) 45461 * __sssubqq3: Fixed-point fractional library routines. 45462 (line 121) 45463 * __sssubsa3: Fixed-point fractional library routines. 45464 (line 128) 45465 * __sssubsq3: Fixed-point fractional library routines. 45466 (line 123) 45467 * __sssubta3: Fixed-point fractional library routines. 45468 (line 131) 45469 * __subda3: Fixed-point fractional library routines. 45470 (line 107) 45471 * __subdf3: Soft float library routines. 45472 (line 31) 45473 * __subdq3: Fixed-point fractional library routines. 45474 (line 95) 45475 * __subha3: Fixed-point fractional library routines. 45476 (line 105) 45477 * __subhq3: Fixed-point fractional library routines. 45478 (line 92) 45479 * __subqq3: Fixed-point fractional library routines. 45480 (line 91) 45481 * __subsa3: Fixed-point fractional library routines. 45482 (line 106) 45483 * __subsf3: Soft float library routines. 45484 (line 30) 45485 * __subsq3: Fixed-point fractional library routines. 45486 (line 93) 45487 * __subta3: Fixed-point fractional library routines. 45488 (line 109) 45489 * __subtf3: Soft float library routines. 45490 (line 33) 45491 * __subuda3: Fixed-point fractional library routines. 45492 (line 115) 45493 * __subudq3: Fixed-point fractional library routines. 45494 (line 103) 45495 * __subuha3: Fixed-point fractional library routines. 45496 (line 111) 45497 * __subuhq3: Fixed-point fractional library routines. 45498 (line 99) 45499 * __subuqq3: Fixed-point fractional library routines. 45500 (line 97) 45501 * __subusa3: Fixed-point fractional library routines. 45502 (line 113) 45503 * __subusq3: Fixed-point fractional library routines. 45504 (line 101) 45505 * __subuta3: Fixed-point fractional library routines. 45506 (line 117) 45507 * __subvdi3: Integer library routines. 45508 (line 123) 45509 * __subvsi3: Integer library routines. 45510 (line 122) 45511 * __subxf3: Soft float library routines. 45512 (line 35) 45513 * __truncdfsf2: Soft float library routines. 45514 (line 76) 45515 * __trunctfdf2: Soft float library routines. 45516 (line 73) 45517 * __trunctfsf2: Soft float library routines. 45518 (line 75) 45519 * __truncxfdf2: Soft float library routines. 45520 (line 72) 45521 * __truncxfsf2: Soft float library routines. 45522 (line 74) 45523 * __ucmpdi2: Integer library routines. 45524 (line 93) 45525 * __ucmpti2: Integer library routines. 45526 (line 95) 45527 * __udivdi3: Integer library routines. 45528 (line 54) 45529 * __udivmoddi4: Integer library routines. 45530 (line 61) 45531 * __udivmodti4: Integer library routines. 45532 (line 63) 45533 * __udivsi3: Integer library routines. 45534 (line 52) 45535 * __udivti3: Integer library routines. 45536 (line 56) 45537 * __udivuda3: Fixed-point fractional library routines. 45538 (line 246) 45539 * __udivudq3: Fixed-point fractional library routines. 45540 (line 240) 45541 * __udivuha3: Fixed-point fractional library routines. 45542 (line 242) 45543 * __udivuhq3: Fixed-point fractional library routines. 45544 (line 236) 45545 * __udivuqq3: Fixed-point fractional library routines. 45546 (line 234) 45547 * __udivusa3: Fixed-point fractional library routines. 45548 (line 244) 45549 * __udivusq3: Fixed-point fractional library routines. 45550 (line 238) 45551 * __udivuta3: Fixed-point fractional library routines. 45552 (line 248) 45553 * __umoddi3: Integer library routines. 45554 (line 71) 45555 * __umodsi3: Integer library routines. 45556 (line 69) 45557 * __umodti3: Integer library routines. 45558 (line 73) 45559 * __unorddf2: Soft float library routines. 45560 (line 173) 45561 * __unordsf2: Soft float library routines. 45562 (line 172) 45563 * __unordtf2: Soft float library routines. 45564 (line 174) 45565 * __usadduda3: Fixed-point fractional library routines. 45566 (line 85) 45567 * __usaddudq3: Fixed-point fractional library routines. 45568 (line 79) 45569 * __usadduha3: Fixed-point fractional library routines. 45570 (line 81) 45571 * __usadduhq3: Fixed-point fractional library routines. 45572 (line 75) 45573 * __usadduqq3: Fixed-point fractional library routines. 45574 (line 73) 45575 * __usaddusa3: Fixed-point fractional library routines. 45576 (line 83) 45577 * __usaddusq3: Fixed-point fractional library routines. 45578 (line 77) 45579 * __usadduta3: Fixed-point fractional library routines. 45580 (line 87) 45581 * __usashluda3: Fixed-point fractional library routines. 45582 (line 421) 45583 * __usashludq3: Fixed-point fractional library routines. 45584 (line 415) 45585 * __usashluha3: Fixed-point fractional library routines. 45586 (line 417) 45587 * __usashluhq3: Fixed-point fractional library routines. 45588 (line 411) 45589 * __usashluqq3: Fixed-point fractional library routines. 45590 (line 409) 45591 * __usashlusa3: Fixed-point fractional library routines. 45592 (line 419) 45593 * __usashlusq3: Fixed-point fractional library routines. 45594 (line 413) 45595 * __usashluta3: Fixed-point fractional library routines. 45596 (line 423) 45597 * __usdivuda3: Fixed-point fractional library routines. 45598 (line 280) 45599 * __usdivudq3: Fixed-point fractional library routines. 45600 (line 274) 45601 * __usdivuha3: Fixed-point fractional library routines. 45602 (line 276) 45603 * __usdivuhq3: Fixed-point fractional library routines. 45604 (line 270) 45605 * __usdivuqq3: Fixed-point fractional library routines. 45606 (line 268) 45607 * __usdivusa3: Fixed-point fractional library routines. 45608 (line 278) 45609 * __usdivusq3: Fixed-point fractional library routines. 45610 (line 272) 45611 * __usdivuta3: Fixed-point fractional library routines. 45612 (line 282) 45613 * __usmuluda3: Fixed-point fractional library routines. 45614 (line 212) 45615 * __usmuludq3: Fixed-point fractional library routines. 45616 (line 206) 45617 * __usmuluha3: Fixed-point fractional library routines. 45618 (line 208) 45619 * __usmuluhq3: Fixed-point fractional library routines. 45620 (line 202) 45621 * __usmuluqq3: Fixed-point fractional library routines. 45622 (line 200) 45623 * __usmulusa3: Fixed-point fractional library routines. 45624 (line 210) 45625 * __usmulusq3: Fixed-point fractional library routines. 45626 (line 204) 45627 * __usmuluta3: Fixed-point fractional library routines. 45628 (line 214) 45629 * __usneguda2: Fixed-point fractional library routines. 45630 (line 331) 45631 * __usnegudq2: Fixed-point fractional library routines. 45632 (line 326) 45633 * __usneguha2: Fixed-point fractional library routines. 45634 (line 328) 45635 * __usneguhq2: Fixed-point fractional library routines. 45636 (line 322) 45637 * __usneguqq2: Fixed-point fractional library routines. 45638 (line 321) 45639 * __usnegusa2: Fixed-point fractional library routines. 45640 (line 329) 45641 * __usnegusq2: Fixed-point fractional library routines. 45642 (line 324) 45643 * __usneguta2: Fixed-point fractional library routines. 45644 (line 333) 45645 * __ussubuda3: Fixed-point fractional library routines. 45646 (line 148) 45647 * __ussubudq3: Fixed-point fractional library routines. 45648 (line 142) 45649 * __ussubuha3: Fixed-point fractional library routines. 45650 (line 144) 45651 * __ussubuhq3: Fixed-point fractional library routines. 45652 (line 138) 45653 * __ussubuqq3: Fixed-point fractional library routines. 45654 (line 136) 45655 * __ussubusa3: Fixed-point fractional library routines. 45656 (line 146) 45657 * __ussubusq3: Fixed-point fractional library routines. 45658 (line 140) 45659 * __ussubuta3: Fixed-point fractional library routines. 45660 (line 150) 45661 * abort: Portability. (line 21) 45662 * abs: Arithmetic. (line 200) 45663 * abs and attributes: Expressions. (line 85) 45664 * ABS_EXPR: Unary and Binary Expressions. 45665 (line 6) 45666 * absence_set: Processor pipeline description. 45667 (line 224) 45668 * absM2 instruction pattern: Standard Names. (line 535) 45669 * absolute value: Arithmetic. (line 200) 45670 * access to operands: Accessors. (line 6) 45671 * access to special operands: Special Accessors. (line 6) 45672 * accessors: Accessors. (line 6) 45673 * ACCUM_TYPE_SIZE: Type Layout. (line 88) 45674 * ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 49) 45675 * ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135) 45676 * ADA_LONG_TYPE_SIZE: Type Layout. (line 26) 45677 * Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 45678 (line 6) 45679 * ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15) 45680 * addM3 instruction pattern: Standard Names. (line 263) 45681 * addMODEcc instruction pattern: Standard Names. (line 1050) 45682 * addr_diff_vec: Side Effects. (line 308) 45683 * addr_diff_vec, length of: Insn Lengths. (line 26) 45684 * ADDR_EXPR: Storage References. (line 6) 45685 * addr_vec: Side Effects. (line 303) 45686 * addr_vec, length of: Insn Lengths. (line 26) 45687 * address constraints: Simple Constraints. (line 164) 45688 * address_operand <1>: Simple Constraints. (line 168) 45689 * address_operand: Machine-Independent Predicates. 45690 (line 63) 45691 * addressing modes: Addressing Modes. (line 6) 45692 * ADJUST_FIELD_ALIGN: Storage Layout. (line 197) 45693 * ADJUST_INSN_LENGTH: Insn Lengths. (line 35) 45694 * ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 23) 45695 * aggregates as return values: Aggregate Return. (line 6) 45696 * alias: Alias analysis. (line 6) 45697 * ALL_REGS: Register Classes. (line 17) 45698 * allocate_stack instruction pattern: Standard Names. (line 1375) 45699 * alternate entry points: Insns. (line 146) 45700 * anchored addresses: Anchored Addresses. (line 6) 45701 * and: Arithmetic. (line 158) 45702 * and and attributes: Expressions. (line 50) 45703 * and, canonicalization of: Insn Canonicalizations. 45704 (line 52) 45705 * andM3 instruction pattern: Standard Names. (line 269) 45706 * annotations: Annotations. (line 6) 45707 * APPLY_RESULT_SIZE: Scalar Return. (line 112) 45708 * ARG_POINTER_CFA_OFFSET: Frame Layout. (line 194) 45709 * ARG_POINTER_REGNUM: Frame Registers. (line 41) 45710 * ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 45711 * arg_pointer_rtx: Frame Registers. (line 104) 45712 * ARGS_GROW_DOWNWARD: Frame Layout. (line 35) 45713 * argument passing: Interface. (line 36) 45714 * arguments in registers: Register Arguments. (line 6) 45715 * arguments on stack: Stack Arguments. (line 6) 45716 * arithmetic library: Soft float library routines. 45717 (line 6) 45718 * arithmetic shift: Arithmetic. (line 173) 45719 * arithmetic shift with signed saturation: Arithmetic. (line 173) 45720 * arithmetic shift with unsigned saturation: Arithmetic. (line 173) 45721 * arithmetic, in RTL: Arithmetic. (line 6) 45722 * ARITHMETIC_TYPE_P: Types for C++. (line 61) 45723 * array: Types. (line 6) 45724 * ARRAY_RANGE_REF: Storage References. (line 6) 45725 * ARRAY_REF: Storage References. (line 6) 45726 * ARRAY_TYPE: Types. (line 6) 45727 * AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 89) 45728 * ashift: Arithmetic. (line 173) 45729 * ashift and attributes: Expressions. (line 85) 45730 * ashiftrt: Arithmetic. (line 190) 45731 * ashiftrt and attributes: Expressions. (line 85) 45732 * ashlM3 instruction pattern: Standard Names. (line 510) 45733 * ashrM3 instruction pattern: Standard Names. (line 520) 45734 * ASM_APP_OFF: File Framework. (line 78) 45735 * ASM_APP_ON: File Framework. (line 71) 45736 * ASM_COMMENT_START: File Framework. (line 66) 45737 * ASM_DECLARE_FUNCTION_NAME: Label Output. (line 111) 45738 * ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 126) 45739 * ASM_DECLARE_OBJECT_NAME: Label Output. (line 139) 45740 * ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 168) 45741 * ASM_FINAL_SPEC: Driver. (line 82) 45742 * ASM_FINISH_DECLARE_OBJECT: Label Output. (line 176) 45743 * ASM_FORMAT_PRIVATE_NAME: Label Output. (line 395) 45744 * asm_fprintf: Instruction Output. (line 151) 45745 * ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 162) 45746 * ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 379) 45747 * asm_input: Side Effects. (line 290) 45748 * asm_input and /v: Flags. (line 76) 45749 * ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82) 45750 * ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 79) 45751 * asm_noperands: Insns. (line 314) 45752 * asm_operands and /v: Flags. (line 76) 45753 * asm_operands, RTL sharing: Sharing. (line 45) 45754 * asm_operands, usage: Assembler. (line 6) 45755 * ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9) 45756 * ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26) 45757 * ASM_OUTPUT_ALIGN: Alignment Output. (line 86) 45758 * ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 91) 45759 * ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 46) 45760 * ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 30) 45761 * ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 38) 45762 * ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 91) 45763 * ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 83) 45764 * ASM_OUTPUT_ASCII: Data Output. (line 51) 45765 * ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51) 45766 * ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38) 45767 * ASM_OUTPUT_COMMON: Uninitialized Data. (line 10) 45768 * ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 367) 45769 * ASM_OUTPUT_DEF: Label Output. (line 416) 45770 * ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 424) 45771 * ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 74) 45772 * ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 83) 45773 * ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 89) 45774 * ASM_OUTPUT_DWARF_TABLE_REF: SDB and DWARF. (line 94) 45775 * ASM_OUTPUT_DWARF_VMS_DELTA: SDB and DWARF. (line 78) 45776 * ASM_OUTPUT_EXTERNAL: Label Output. (line 296) 45777 * ASM_OUTPUT_FDESC: Data Output. (line 60) 45778 * ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 17) 45779 * ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 29) 45780 * ASM_OUTPUT_LABEL: Label Output. (line 9) 45781 * ASM_OUTPUT_LABEL_REF: Label Output. (line 340) 45782 * ASM_OUTPUT_LABELREF: Label Output. (line 318) 45783 * ASM_OUTPUT_LOCAL: Uninitialized Data. (line 70) 45784 * ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 95) 45785 * ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 53) 45786 * ASM_OUTPUT_OPCODE: Instruction Output. (line 36) 45787 * ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 110) 45788 * ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 73) 45789 * ASM_OUTPUT_REG_POP: Instruction Output. (line 206) 45790 * ASM_OUTPUT_REG_PUSH: Instruction Output. (line 201) 45791 * ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 47) 45792 * ASM_OUTPUT_SKIP: Alignment Output. (line 73) 45793 * ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 85) 45794 * ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 85) 45795 * ASM_OUTPUT_SYMBOL_REF: Label Output. (line 333) 45796 * ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 101) 45797 * ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 442) 45798 * ASM_OUTPUT_WEAKREF: Label Output. (line 228) 45799 * ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67) 45800 * ASM_SPEC: Driver. (line 74) 45801 * ASM_STABD_OP: DBX Options. (line 36) 45802 * ASM_STABN_OP: DBX Options. (line 43) 45803 * ASM_STABS_OP: DBX Options. (line 29) 45804 * ASM_WEAKEN_DECL: Label Output. (line 220) 45805 * ASM_WEAKEN_LABEL: Label Output. (line 207) 45806 * assemble_name: Label Output. (line 8) 45807 * assemble_name_raw: Label Output. (line 28) 45808 * assembler format: File Framework. (line 6) 45809 * assembler instructions in RTL: Assembler. (line 6) 45810 * ASSEMBLER_DIALECT: Instruction Output. (line 174) 45811 * assigning attribute values to insns: Tagging Insns. (line 6) 45812 * ASSUME_EXTENDED_UNWIND_CONTEXT: Frame Registers. (line 164) 45813 * asterisk in template: Output Statement. (line 29) 45814 * atan2M3 instruction pattern: Standard Names. (line 618) 45815 * atomic: GTY Options. (line 254) 45816 * atomic_add_fetchMODE instruction pattern: Standard Names. (line 1808) 45817 * atomic_addMODE instruction pattern: Standard Names. (line 1779) 45818 * atomic_and_fetchMODE instruction pattern: Standard Names. (line 1808) 45819 * atomic_andMODE instruction pattern: Standard Names. (line 1779) 45820 * atomic_compare_and_swapMODE instruction pattern: Standard Names. 45821 (line 1715) 45822 * atomic_exchangeMODE instruction pattern: Standard Names. (line 1767) 45823 * atomic_fetch_addMODE instruction pattern: Standard Names. (line 1793) 45824 * atomic_fetch_andMODE instruction pattern: Standard Names. (line 1793) 45825 * atomic_fetch_nandMODE instruction pattern: Standard Names. (line 1793) 45826 * atomic_fetch_orMODE instruction pattern: Standard Names. (line 1793) 45827 * atomic_fetch_subMODE instruction pattern: Standard Names. (line 1793) 45828 * atomic_fetch_xorMODE instruction pattern: Standard Names. (line 1793) 45829 * atomic_loadMODE instruction pattern: Standard Names. (line 1746) 45830 * atomic_nand_fetchMODE instruction pattern: Standard Names. (line 1808) 45831 * atomic_nandMODE instruction pattern: Standard Names. (line 1779) 45832 * atomic_or_fetchMODE instruction pattern: Standard Names. (line 1808) 45833 * atomic_orMODE instruction pattern: Standard Names. (line 1779) 45834 * atomic_storeMODE instruction pattern: Standard Names. (line 1756) 45835 * atomic_sub_fetchMODE instruction pattern: Standard Names. (line 1808) 45836 * atomic_subMODE instruction pattern: Standard Names. (line 1779) 45837 * atomic_test_and_set instruction pattern: Standard Names. (line 1825) 45838 * atomic_xor_fetchMODE instruction pattern: Standard Names. (line 1808) 45839 * atomic_xorMODE instruction pattern: Standard Names. (line 1779) 45840 * attr <1>: Tagging Insns. (line 54) 45841 * attr: Expressions. (line 165) 45842 * attr_flag: Expressions. (line 140) 45843 * attribute expressions: Expressions. (line 6) 45844 * attribute specifications: Attr Example. (line 6) 45845 * attribute specifications example: Attr Example. (line 6) 45846 * ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 179) 45847 * attributes: Attributes. (line 6) 45848 * attributes, defining: Defining Attributes. 45849 (line 6) 45850 * attributes, target-specific: Target Attributes. (line 6) 45851 * autoincrement addressing, availability: Portability. (line 21) 45852 * autoincrement/decrement addressing: Simple Constraints. (line 30) 45853 * automata_option: Processor pipeline description. 45854 (line 305) 45855 * automaton based pipeline description: Processor pipeline description. 45856 (line 6) 45857 * automaton based scheduler: Processor pipeline description. 45858 (line 6) 45859 * AVOID_CCMODE_COPIES: Values in Registers. 45860 (line 153) 45861 * backslash: Output Template. (line 46) 45862 * barrier: Insns. (line 166) 45863 * barrier and /f: Flags. (line 107) 45864 * barrier and /v: Flags. (line 44) 45865 * BASE_REG_CLASS: Register Classes. (line 114) 45866 * basic block: Basic Blocks. (line 6) 45867 * Basic Statements: Basic Statements. (line 6) 45868 * basic-block.h: Control Flow. (line 6) 45869 * BASIC_BLOCK: Basic Blocks. (line 14) 45870 * basic_block: Basic Blocks. (line 6) 45871 * BB_HEAD, BB_END: Maintaining the CFG. 45872 (line 77) 45873 * bb_seq: GIMPLE sequences. (line 73) 45874 * BIGGEST_ALIGNMENT: Storage Layout. (line 169) 45875 * BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 190) 45876 * BImode: Machine Modes. (line 22) 45877 * BIND_EXPR: Unary and Binary Expressions. 45878 (line 6) 45879 * BINFO_TYPE: Classes. (line 6) 45880 * bit-fields: Bit-Fields. (line 6) 45881 * BIT_AND_EXPR: Unary and Binary Expressions. 45882 (line 6) 45883 * BIT_IOR_EXPR: Unary and Binary Expressions. 45884 (line 6) 45885 * BIT_NOT_EXPR: Unary and Binary Expressions. 45886 (line 6) 45887 * BIT_XOR_EXPR: Unary and Binary Expressions. 45888 (line 6) 45889 * BITFIELD_NBYTES_LIMITED: Storage Layout. (line 394) 45890 * BITS_BIG_ENDIAN: Storage Layout. (line 12) 45891 * BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 45892 * BITS_PER_UNIT: Storage Layout. (line 51) 45893 * BITS_PER_WORD: Storage Layout. (line 56) 45894 * bitwise complement: Arithmetic. (line 154) 45895 * bitwise exclusive-or: Arithmetic. (line 168) 45896 * bitwise inclusive-or: Arithmetic. (line 163) 45897 * bitwise logical-and: Arithmetic. (line 158) 45898 * BLKmode: Machine Modes. (line 183) 45899 * BLKmode, and function return values: Calls. (line 23) 45900 * BLOCK_FOR_INSN, gimple_bb: Maintaining the CFG. 45901 (line 29) 45902 * BLOCK_REG_PADDING: Register Arguments. (line 230) 45903 * blockage instruction pattern: Standard Names. (line 1578) 45904 * Blocks: Blocks. (line 6) 45905 * bool: Misc. (line 857) 45906 * BOOL_TYPE_SIZE: Type Layout. (line 44) 45907 * BOOLEAN_TYPE: Types. (line 6) 45908 * branch prediction: Profile information. 45909 (line 24) 45910 * BRANCH_COST: Costs. (line 105) 45911 * break_out_memory_refs: Addressing Modes. (line 135) 45912 * BREAK_STMT: Statements for C++. (line 6) 45913 * BSS_SECTION_ASM_OP: Sections. (line 68) 45914 * bswap: Arithmetic. (line 247) 45915 * bswapM2 instruction pattern: Standard Names. (line 528) 45916 * btruncM2 instruction pattern: Standard Names. (line 636) 45917 * build0: Macros and Functions. 45918 (line 16) 45919 * build1: Macros and Functions. 45920 (line 17) 45921 * build2: Macros and Functions. 45922 (line 18) 45923 * build3: Macros and Functions. 45924 (line 19) 45925 * build4: Macros and Functions. 45926 (line 20) 45927 * build5: Macros and Functions. 45928 (line 21) 45929 * build6: Macros and Functions. 45930 (line 22) 45931 * builtin_longjmp instruction pattern: Standard Names. (line 1475) 45932 * builtin_setjmp_receiver instruction pattern: Standard Names. 45933 (line 1465) 45934 * builtin_setjmp_setup instruction pattern: Standard Names. (line 1454) 45935 * byte_mode: Machine Modes. (line 336) 45936 * BYTES_BIG_ENDIAN: Storage Layout. (line 24) 45937 * BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 221) 45938 * C statements for assembler output: Output Statement. (line 6) 45939 * C99 math functions, implicit usage: Library Calls. (line 70) 45940 * C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 137) 45941 * c_register_pragma: Misc. (line 402) 45942 * c_register_pragma_with_expansion: Misc. (line 404) 45943 * call <1>: Side Effects. (line 92) 45944 * call: Flags. (line 221) 45945 * call instruction pattern: Standard Names. (line 1107) 45946 * call usage: Calls. (line 10) 45947 * call, in call_insn: Flags. (line 33) 45948 * call, in mem: Flags. (line 81) 45949 * call-clobbered register: Register Basics. (line 35) 45950 * call-saved register: Register Basics. (line 35) 45951 * call-used register: Register Basics. (line 35) 45952 * CALL_EXPR: Unary and Binary Expressions. 45953 (line 6) 45954 * call_insn: Insns. (line 95) 45955 * call_insn and /c: Flags. (line 33) 45956 * call_insn and /f: Flags. (line 107) 45957 * call_insn and /i: Flags. (line 24) 45958 * call_insn and /j: Flags. (line 161) 45959 * call_insn and /s: Flags. (line 49) 45960 * call_insn and /u: Flags. (line 19) 45961 * call_insn and /u or /i: Flags. (line 29) 45962 * call_insn and /v: Flags. (line 44) 45963 * CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 45964 * call_pop instruction pattern: Standard Names. (line 1135) 45965 * CALL_POPS_ARGS: Stack Arguments. (line 133) 45966 * CALL_REALLY_USED_REGISTERS: Register Basics. (line 46) 45967 * CALL_USED_REGISTERS: Register Basics. (line 35) 45968 * call_used_regs: Register Basics. (line 59) 45969 * call_value instruction pattern: Standard Names. (line 1127) 45970 * call_value_pop instruction pattern: Standard Names. (line 1135) 45971 * CALLER_SAVE_PROFITABLE: Caller Saves. (line 11) 45972 * calling conventions: Stack and Calling. (line 6) 45973 * calling functions in RTL: Calls. (line 6) 45974 * can_create_pseudo_p: Standard Names. (line 75) 45975 * can_fallthru: Basic Blocks. (line 67) 45976 * canadian: Configure Terms. (line 6) 45977 * CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 538) 45978 * CANNOT_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 45979 (line 280) 45980 * canonicalization of instructions: Insn Canonicalizations. 45981 (line 6) 45982 * canonicalize_funcptr_for_compare instruction pattern: Standard Names. 45983 (line 1306) 45984 * CASE_VECTOR_MODE: Misc. (line 27) 45985 * CASE_VECTOR_PC_RELATIVE: Misc. (line 40) 45986 * CASE_VECTOR_SHORTEN_MODE: Misc. (line 31) 45987 * casesi instruction pattern: Standard Names. (line 1229) 45988 * cbranchMODE4 instruction pattern: Standard Names. (line 1096) 45989 * cc0 <1>: CC0 Condition Codes. 45990 (line 6) 45991 * cc0: Regs and Memory. (line 307) 45992 * cc0, RTL sharing: Sharing. (line 27) 45993 * cc0_rtx: Regs and Memory. (line 333) 45994 * CC1_SPEC: Driver. (line 56) 45995 * CC1PLUS_SPEC: Driver. (line 64) 45996 * cc_status: CC0 Condition Codes. 45997 (line 6) 45998 * CC_STATUS_MDEP: CC0 Condition Codes. 45999 (line 17) 46000 * CC_STATUS_MDEP_INIT: CC0 Condition Codes. 46001 (line 23) 46002 * CCmode <1>: MODE_CC Condition Codes. 46003 (line 6) 46004 * CCmode: Machine Modes. (line 176) 46005 * CDImode: Machine Modes. (line 202) 46006 * CEIL_DIV_EXPR: Unary and Binary Expressions. 46007 (line 6) 46008 * CEIL_MOD_EXPR: Unary and Binary Expressions. 46009 (line 6) 46010 * ceilM2 instruction pattern: Standard Names. (line 652) 46011 * CFA_FRAME_BASE_OFFSET: Frame Layout. (line 226) 46012 * CFG verification: Maintaining the CFG. 46013 (line 119) 46014 * CFG, Control Flow Graph: Control Flow. (line 6) 46015 * cfghooks.h: Maintaining the CFG. 46016 (line 6) 46017 * cgraph_finalize_function: Parsing pass. (line 52) 46018 * chain_circular: GTY Options. (line 196) 46019 * chain_next: GTY Options. (line 196) 46020 * chain_prev: GTY Options. (line 196) 46021 * change_address: Standard Names. (line 47) 46022 * CHAR_TYPE_SIZE: Type Layout. (line 39) 46023 * check_stack instruction pattern: Standard Names. (line 1393) 46024 * CHImode: Machine Modes. (line 202) 46025 * class definitions, register: Register Classes. (line 6) 46026 * class preference constraints: Class Preferences. (line 6) 46027 * class, scope: Classes. (line 6) 46028 * CLASS_MAX_NREGS: Register Classes. (line 526) 46029 * CLASS_TYPE_P: Types for C++. (line 65) 46030 * classes of RTX codes: RTL Classes. (line 6) 46031 * CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 46032 * CLASSTYPE_HAS_MUTABLE: Classes. (line 85) 46033 * CLASSTYPE_NON_POD_P: Classes. (line 90) 46034 * CLEANUP_DECL: Statements for C++. (line 6) 46035 * CLEANUP_EXPR: Statements for C++. (line 6) 46036 * CLEANUP_POINT_EXPR: Unary and Binary Expressions. 46037 (line 6) 46038 * CLEANUP_STMT: Statements for C++. (line 6) 46039 * Cleanups: Cleanups. (line 6) 46040 * CLEAR_BY_PIECES_P: Costs. (line 188) 46041 * clear_cache instruction pattern: Standard Names. (line 1885) 46042 * CLEAR_INSN_CACHE: Trampolines. (line 99) 46043 * CLEAR_RATIO: Costs. (line 176) 46044 * clobber: Side Effects. (line 106) 46045 * clrsb: Arithmetic. (line 216) 46046 * clz: Arithmetic. (line 223) 46047 * CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 305) 46048 * clzM2 instruction pattern: Standard Names. (line 717) 46049 * cmpmemM instruction pattern: Standard Names. (line 850) 46050 * cmpstrM instruction pattern: Standard Names. (line 829) 46051 * cmpstrnM instruction pattern: Standard Names. (line 816) 46052 * code generation RTL sequences: Expander Definitions. 46053 (line 6) 46054 * code iterators in .md files: Code Iterators. (line 6) 46055 * CODE_LABEL: Basic Blocks. (line 50) 46056 * code_label: Insns. (line 125) 46057 * code_label and /i: Flags. (line 59) 46058 * code_label and /v: Flags. (line 44) 46059 * CODE_LABEL_NUMBER: Insns. (line 125) 46060 * codes, RTL expression: RTL Objects. (line 47) 46061 * COImode: Machine Modes. (line 202) 46062 * COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 46063 * COLLECT_EXPORT_LIST: Misc. (line 756) 46064 * COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 46065 (line 44) 46066 * COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 46067 (line 33) 46068 * commit_edge_insertions: Maintaining the CFG. 46069 (line 107) 46070 * compare: Arithmetic. (line 43) 46071 * compare, canonicalization of: Insn Canonicalizations. 46072 (line 37) 46073 * comparison_operator: Machine-Independent Predicates. 46074 (line 111) 46075 * compiler passes and files: Passes. (line 6) 46076 * complement, bitwise: Arithmetic. (line 154) 46077 * COMPLEX_CST: Constant expressions. 46078 (line 6) 46079 * COMPLEX_EXPR: Unary and Binary Expressions. 46080 (line 6) 46081 * COMPLEX_TYPE: Types. (line 6) 46082 * COMPONENT_REF: Storage References. (line 6) 46083 * Compound Expressions: Compound Expressions. 46084 (line 6) 46085 * Compound Lvalues: Compound Lvalues. (line 6) 46086 * COMPOUND_EXPR: Unary and Binary Expressions. 46087 (line 6) 46088 * COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 46089 (line 6) 46090 * COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 46091 (line 375) 46092 * COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 46093 (line 375) 46094 * computed jump: Edges. (line 128) 46095 * computing the length of an insn: Insn Lengths. (line 6) 46096 * concat: Regs and Memory. (line 385) 46097 * concatn: Regs and Memory. (line 391) 46098 * cond: Comparisons. (line 90) 46099 * cond and attributes: Expressions. (line 37) 46100 * cond_exec: Side Effects. (line 254) 46101 * COND_EXPR: Unary and Binary Expressions. 46102 (line 6) 46103 * condition code register: Regs and Memory. (line 307) 46104 * condition code status: Condition Code. (line 6) 46105 * condition codes: Comparisons. (line 20) 46106 * conditional execution <1>: Cond Exec Macros. (line 6) 46107 * conditional execution: Conditional Execution. 46108 (line 6) 46109 * Conditional Expressions: Conditional Expressions. 46110 (line 6) 46111 * conditions, in patterns: Patterns. (line 43) 46112 * configuration file <1>: Host Misc. (line 6) 46113 * configuration file: Filesystem. (line 6) 46114 * configure terms: Configure Terms. (line 6) 46115 * CONJ_EXPR: Unary and Binary Expressions. 46116 (line 6) 46117 * const: Constants. (line 110) 46118 * CONST0_RTX: Constants. (line 130) 46119 * const0_rtx: Constants. (line 21) 46120 * CONST1_RTX: Constants. (line 130) 46121 * const1_rtx: Constants. (line 21) 46122 * CONST2_RTX: Constants. (line 130) 46123 * const2_rtx: Constants. (line 21) 46124 * CONST_DECL: Declarations. (line 6) 46125 * const_double: Constants. (line 37) 46126 * const_double, RTL sharing: Sharing. (line 29) 46127 * CONST_DOUBLE_LOW: Constants. (line 50) 46128 * CONST_DOUBLE_OK_FOR_CONSTRAINT_P: Old Constraints. (line 69) 46129 * CONST_DOUBLE_OK_FOR_LETTER_P: Old Constraints. (line 54) 46130 * const_double_operand: Machine-Independent Predicates. 46131 (line 21) 46132 * const_fixed: Constants. (line 63) 46133 * const_int: Constants. (line 8) 46134 * const_int and attribute tests: Expressions. (line 47) 46135 * const_int and attributes: Expressions. (line 10) 46136 * const_int, RTL sharing: Sharing. (line 23) 46137 * const_int_operand: Machine-Independent Predicates. 46138 (line 16) 46139 * CONST_OK_FOR_CONSTRAINT_P: Old Constraints. (line 49) 46140 * CONST_OK_FOR_LETTER_P: Old Constraints. (line 40) 46141 * const_string: Constants. (line 82) 46142 * const_string and attributes: Expressions. (line 20) 46143 * const_true_rtx: Constants. (line 31) 46144 * const_vector: Constants. (line 70) 46145 * const_vector, RTL sharing: Sharing. (line 32) 46146 * constant attributes: Constant Attributes. 46147 (line 6) 46148 * constant definitions: Constant Definitions. 46149 (line 6) 46150 * CONSTANT_ADDRESS_P: Addressing Modes. (line 29) 46151 * CONSTANT_ALIGNMENT: Storage Layout. (line 237) 46152 * CONSTANT_P: Addressing Modes. (line 36) 46153 * CONSTANT_POOL_ADDRESS_P: Flags. (line 10) 46154 * CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 65) 46155 * constants in constraints: Simple Constraints. (line 70) 46156 * constm1_rtx: Constants. (line 21) 46157 * constraint modifier characters: Modifiers. (line 6) 46158 * constraint, matching: Simple Constraints. (line 142) 46159 * CONSTRAINT_LEN: Old Constraints. (line 12) 46160 * constraint_num: C Constraint Interface. 46161 (line 38) 46162 * constraint_satisfied_p: C Constraint Interface. 46163 (line 54) 46164 * constraints: Constraints. (line 6) 46165 * constraints, defining: Define Constraints. (line 6) 46166 * constraints, defining, obsolete method: Old Constraints. (line 6) 46167 * constraints, machine specific: Machine Constraints. 46168 (line 6) 46169 * constraints, testing: C Constraint Interface. 46170 (line 6) 46171 * CONSTRUCTOR: Unary and Binary Expressions. 46172 (line 6) 46173 * constructors, automatic calls: Collect2. (line 15) 46174 * constructors, output of: Initialization. (line 6) 46175 * container: Containers. (line 6) 46176 * CONTINUE_STMT: Statements for C++. (line 6) 46177 * contributors: Contributors. (line 6) 46178 * controlling register usage: Register Basics. (line 73) 46179 * controlling the compilation driver: Driver. (line 6) 46180 * conventions, run-time: Interface. (line 6) 46181 * conversions: Conversions. (line 6) 46182 * CONVERT_EXPR: Unary and Binary Expressions. 46183 (line 6) 46184 * copy_rtx: Addressing Modes. (line 190) 46185 * copy_rtx_if_shared: Sharing. (line 64) 46186 * copysignM3 instruction pattern: Standard Names. (line 698) 46187 * cosM2 instruction pattern: Standard Names. (line 564) 46188 * costs of instructions: Costs. (line 6) 46189 * CP_INTEGRAL_TYPE: Types for C++. (line 57) 46190 * cp_namespace_decls: Namespaces. (line 49) 46191 * CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 46192 * CP_TYPE_CONST_P: Types for C++. (line 24) 46193 * cp_type_quals: Types for C++. (line 6) 46194 * CP_TYPE_RESTRICT_P: Types for C++. (line 30) 46195 * CP_TYPE_VOLATILE_P: Types for C++. (line 27) 46196 * CPLUSPLUS_CPP_SPEC: Driver. (line 51) 46197 * CPP_SPEC: Driver. (line 44) 46198 * CQImode: Machine Modes. (line 202) 46199 * cross compilation and floating point: Floating Point. (line 6) 46200 * CRT_CALL_STATIC_FUNCTION: Sections. (line 121) 46201 * crtl->args.pops_args: Function Entry. (line 106) 46202 * crtl->args.pretend_args_size: Function Entry. (line 112) 46203 * crtl->outgoing_args_size: Stack Arguments. (line 48) 46204 * CRTSTUFF_T_CFLAGS: Target Fragment. (line 15) 46205 * CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 19) 46206 * CSImode: Machine Modes. (line 202) 46207 * cstoreMODE4 instruction pattern: Standard Names. (line 1057) 46208 * CTImode: Machine Modes. (line 202) 46209 * ctrapMM4 instruction pattern: Standard Names. (line 1547) 46210 * ctz: Arithmetic. (line 231) 46211 * CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 306) 46212 * ctzM2 instruction pattern: Standard Names. (line 726) 46213 * CUMULATIVE_ARGS: Register Arguments. (line 128) 46214 * current_function_is_leaf: Leaf Functions. (line 51) 46215 * current_function_uses_only_leaf_regs: Leaf Functions. (line 51) 46216 * current_insn_predicate: Conditional Execution. 46217 (line 26) 46218 * DAmode: Machine Modes. (line 152) 46219 * data bypass: Processor pipeline description. 46220 (line 106) 46221 * data dependence delays: Processor pipeline description. 46222 (line 6) 46223 * Data Dependency Analysis: Dependency analysis. 46224 (line 6) 46225 * data structures: Per-Function Data. (line 6) 46226 * DATA_ALIGNMENT: Storage Layout. (line 224) 46227 * DATA_SECTION_ASM_OP: Sections. (line 53) 46228 * DBR_OUTPUT_SEQEND: Instruction Output. (line 135) 46229 * dbr_sequence_length: Instruction Output. (line 134) 46230 * DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 103) 46231 * DBX_CONTIN_CHAR: DBX Options. (line 66) 46232 * DBX_CONTIN_LENGTH: DBX Options. (line 56) 46233 * DBX_DEBUGGING_INFO: DBX Options. (line 9) 46234 * DBX_FUNCTION_FIRST: DBX Options. (line 97) 46235 * DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 109) 46236 * DBX_NO_XREFS: DBX Options. (line 50) 46237 * DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 34) 46238 * DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9) 46239 * DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 46240 (line 42) 46241 * DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 9) 46242 * DBX_REGISTER_NUMBER: All Debuggers. (line 9) 46243 * DBX_REGPARM_STABS_CODE: DBX Options. (line 87) 46244 * DBX_REGPARM_STABS_LETTER: DBX Options. (line 92) 46245 * DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82) 46246 * DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73) 46247 * DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78) 46248 * DBX_USE_BINCL: DBX Options. (line 115) 46249 * DCmode: Machine Modes. (line 197) 46250 * DDmode: Machine Modes. (line 90) 46251 * De Morgan's law: Insn Canonicalizations. 46252 (line 52) 46253 * dead_or_set_p: define_peephole. (line 65) 46254 * debug_expr: Debug Information. (line 22) 46255 * DEBUG_EXPR_DECL: Declarations. (line 6) 46256 * debug_insn: Insns. (line 245) 46257 * DEBUG_SYMS_TEXT: DBX Options. (line 25) 46258 * DEBUGGER_ARG_OFFSET: All Debuggers. (line 37) 46259 * DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28) 46260 * decimal float library: Decimal float library routines. 46261 (line 6) 46262 * DECL_ALIGN: Declarations. (line 6) 46263 * DECL_ANTICIPATED: Functions for C++. (line 42) 46264 * DECL_ARGUMENTS: Function Basics. (line 36) 46265 * DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 46266 * DECL_ARTIFICIAL <1>: Function Properties. 46267 (line 47) 46268 * DECL_ARTIFICIAL <2>: Function Basics. (line 6) 46269 * DECL_ARTIFICIAL: Working with declarations. 46270 (line 24) 46271 * DECL_ASSEMBLER_NAME: Function Basics. (line 6) 46272 * DECL_ATTRIBUTES: Attributes. (line 22) 46273 * DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 46274 * DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 46275 * DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 46276 * DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 46277 * DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 46278 * DECL_CONTEXT: Namespaces. (line 31) 46279 * DECL_CONV_FN_P: Functions for C++. (line 105) 46280 * DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 46281 * DECL_DESTRUCTOR_P: Functions for C++. (line 95) 46282 * DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 46283 * DECL_EXTERNAL <1>: Function Properties. 46284 (line 25) 46285 * DECL_EXTERNAL: Declarations. (line 6) 46286 * DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 46287 * DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties. 46288 (line 61) 46289 * DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6) 46290 * DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Properties. 46291 (line 55) 46292 * DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6) 46293 * DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 46294 * DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 46295 * DECL_INITIAL <1>: Function Basics. (line 51) 46296 * DECL_INITIAL: Declarations. (line 6) 46297 * DECL_LINKONCE_P: Functions for C++. (line 50) 46298 * DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 46299 * DECL_MAIN_P: Functions for C++. (line 34) 46300 * DECL_NAME <1>: Namespaces. (line 20) 46301 * DECL_NAME <2>: Function Basics. (line 6) 46302 * DECL_NAME: Working with declarations. 46303 (line 7) 46304 * DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 46305 * DECL_NAMESPACE_STD_P: Namespaces. (line 45) 46306 * DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 46307 * DECL_NONCONVERTING_P: Functions for C++. (line 80) 46308 * DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 46309 * DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 46310 * DECL_PURE_P: Function Properties. 46311 (line 40) 46312 * DECL_RESULT: Function Basics. (line 41) 46313 * DECL_SAVED_TREE: Function Basics. (line 44) 46314 * DECL_SIZE: Declarations. (line 6) 46315 * DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 46316 * DECL_STMT: Statements for C++. (line 6) 46317 * DECL_STMT_DECL: Statements for C++. (line 6) 46318 * DECL_THUNK_P: Functions for C++. (line 116) 46319 * DECL_VIRTUAL_P: Function Properties. 46320 (line 44) 46321 * DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 46322 * declaration: Declarations. (line 6) 46323 * declarations, RTL: RTL Declarations. (line 6) 46324 * DECLARE_LIBRARY_RENAMES: Library Calls. (line 9) 46325 * decrement_and_branch_until_zero instruction pattern: Standard Names. 46326 (line 1267) 46327 * default: GTY Options. (line 82) 46328 * default_file_start: File Framework. (line 8) 46329 * DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18) 46330 * DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 35) 46331 * DEFAULT_SIGNED_CHAR: Type Layout. (line 161) 46332 * define_address_constraint: Define Constraints. (line 107) 46333 * define_asm_attributes: Tagging Insns. (line 73) 46334 * define_attr: Defining Attributes. 46335 (line 6) 46336 * define_automaton: Processor pipeline description. 46337 (line 53) 46338 * define_bypass: Processor pipeline description. 46339 (line 197) 46340 * define_c_enum: Constant Definitions. 46341 (line 49) 46342 * define_code_attr: Code Iterators. (line 6) 46343 * define_code_iterator: Code Iterators. (line 6) 46344 * define_cond_exec: Conditional Execution. 46345 (line 13) 46346 * define_constants: Constant Definitions. 46347 (line 6) 46348 * define_constraint: Define Constraints. (line 48) 46349 * define_cpu_unit: Processor pipeline description. 46350 (line 68) 46351 * define_delay: Delay Slots. (line 25) 46352 * define_enum: Constant Definitions. 46353 (line 118) 46354 * define_enum_attr <1>: Constant Definitions. 46355 (line 136) 46356 * define_enum_attr: Defining Attributes. 46357 (line 76) 46358 * define_expand: Expander Definitions. 46359 (line 11) 46360 * define_insn: Patterns. (line 6) 46361 * define_insn example: Example. (line 6) 46362 * define_insn_and_split: Insn Splitting. (line 170) 46363 * define_insn_reservation: Processor pipeline description. 46364 (line 106) 46365 * define_int_attr: Int Iterators. (line 6) 46366 * define_int_iterator: Int Iterators. (line 6) 46367 * define_memory_constraint: Define Constraints. (line 88) 46368 * define_mode_attr: Substitutions. (line 6) 46369 * define_mode_iterator: Defining Mode Iterators. 46370 (line 6) 46371 * define_peephole: define_peephole. (line 6) 46372 * define_peephole2: define_peephole2. (line 6) 46373 * define_predicate: Defining Predicates. 46374 (line 6) 46375 * define_query_cpu_unit: Processor pipeline description. 46376 (line 90) 46377 * define_register_constraint: Define Constraints. (line 28) 46378 * define_reservation: Processor pipeline description. 46379 (line 186) 46380 * define_special_predicate: Defining Predicates. 46381 (line 6) 46382 * define_split: Insn Splitting. (line 32) 46383 * define_subst <1>: Subst Iterators. (line 6) 46384 * define_subst <2>: Define Subst Output Template. 46385 (line 6) 46386 * define_subst <3>: Define Subst Pattern Matching. 46387 (line 6) 46388 * define_subst <4>: Define Subst Example. 46389 (line 6) 46390 * define_subst: Define Subst. (line 6) 46391 * define_subst_attr: Subst Iterators. (line 6) 46392 * defining attributes and their values: Defining Attributes. 46393 (line 6) 46394 * defining constraints: Define Constraints. (line 6) 46395 * defining constraints, obsolete method: Old Constraints. (line 6) 46396 * defining jump instruction patterns: Jump Patterns. (line 6) 46397 * defining looping instruction patterns: Looping Patterns. (line 6) 46398 * defining peephole optimizers: Peephole Definitions. 46399 (line 6) 46400 * defining predicates: Defining Predicates. 46401 (line 6) 46402 * defining RTL sequences for code generation: Expander Definitions. 46403 (line 6) 46404 * delay slots, defining: Delay Slots. (line 6) 46405 * deletable: GTY Options. (line 150) 46406 * DELETE_IF_ORDINARY: Filesystem. (line 79) 46407 * Dependent Patterns: Dependent Patterns. (line 6) 46408 * desc: GTY Options. (line 82) 46409 * destructors, output of: Initialization. (line 6) 46410 * deterministic finite state automaton: Processor pipeline description. 46411 (line 6) 46412 * DF_SIZE: Type Layout. (line 137) 46413 * DFmode: Machine Modes. (line 73) 46414 * digits in constraint: Simple Constraints. (line 130) 46415 * DImode: Machine Modes. (line 45) 46416 * DIR_SEPARATOR: Filesystem. (line 18) 46417 * DIR_SEPARATOR_2: Filesystem. (line 19) 46418 * directory options .md: Including Patterns. (line 44) 46419 * disabling certain registers: Register Basics. (line 73) 46420 * dispatch table: Dispatch Tables. (line 8) 46421 * div: Arithmetic. (line 116) 46422 * div and attributes: Expressions. (line 85) 46423 * division: Arithmetic. (line 116) 46424 * divM3 instruction pattern: Standard Names. (line 269) 46425 * divmodM4 instruction pattern: Standard Names. (line 490) 46426 * DO_BODY: Statements for C++. (line 6) 46427 * DO_COND: Statements for C++. (line 6) 46428 * DO_STMT: Statements for C++. (line 6) 46429 * DOLLARS_IN_IDENTIFIERS: Misc. (line 446) 46430 * doloop_begin instruction pattern: Standard Names. (line 1299) 46431 * doloop_end instruction pattern: Standard Names. (line 1277) 46432 * DONE: Expander Definitions. 46433 (line 77) 46434 * DONT_USE_BUILTIN_SETJMP: Exception Region Output. 46435 (line 79) 46436 * DOUBLE_TYPE_SIZE: Type Layout. (line 53) 46437 * DQmode: Machine Modes. (line 115) 46438 * driver: Driver. (line 6) 46439 * DRIVER_SELF_SPECS: Driver. (line 9) 46440 * DUMPFILE_FORMAT: Filesystem. (line 67) 46441 * DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 50) 46442 * DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13) 46443 * DWARF2_FRAME_INFO: SDB and DWARF. (line 30) 46444 * DWARF2_FRAME_REG_OUT: Frame Registers. (line 150) 46445 * DWARF2_UNWIND_INFO: Exception Region Output. 46446 (line 40) 46447 * DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 152) 46448 * DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 46449 (line 91) 46450 * DWARF_FRAME_REGISTERS: Frame Registers. (line 110) 46451 * DWARF_FRAME_REGNUM: Frame Registers. (line 142) 46452 * DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134) 46453 * DWARF_ZERO_REG: Frame Layout. (line 163) 46454 * DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 92) 46455 * E in constraint: Simple Constraints. (line 89) 46456 * earlyclobber operand: Modifiers. (line 25) 46457 * edge: Edges. (line 6) 46458 * edge in the flow graph: Edges. (line 6) 46459 * edge iterators: Edges. (line 15) 46460 * edge splitting: Maintaining the CFG. 46461 (line 107) 46462 * EDGE_ABNORMAL: Edges. (line 128) 46463 * EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 172) 46464 * EDGE_ABNORMAL, EDGE_EH: Edges. (line 96) 46465 * EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 122) 46466 * EDGE_FALLTHRU, force_nonfallthru: Edges. (line 86) 46467 * EDOM, implicit usage: Library Calls. (line 52) 46468 * EH_FRAME_IN_DATA_SECTION: Exception Region Output. 46469 (line 20) 46470 * EH_FRAME_SECTION_NAME: Exception Region Output. 46471 (line 10) 46472 * eh_return instruction pattern: Standard Names. (line 1481) 46473 * EH_RETURN_DATA_REGNO: Exception Handling. (line 7) 46474 * EH_RETURN_HANDLER_RTX: Exception Handling. (line 39) 46475 * EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22) 46476 * EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 46477 (line 29) 46478 * EH_USES: Function Entry. (line 158) 46479 * ei_edge: Edges. (line 43) 46480 * ei_end_p: Edges. (line 27) 46481 * ei_last: Edges. (line 23) 46482 * ei_next: Edges. (line 35) 46483 * ei_one_before_end_p: Edges. (line 31) 46484 * ei_prev: Edges. (line 39) 46485 * ei_safe_safe: Edges. (line 47) 46486 * ei_start: Edges. (line 19) 46487 * ELIMINABLE_REGS: Elimination. (line 47) 46488 * ELSE_CLAUSE: Statements for C++. (line 6) 46489 * Embedded C: Fixed-point fractional library routines. 46490 (line 6) 46491 * EMIT_MODE_SET: Mode Switching. (line 75) 46492 * Empty Statements: Empty Statements. (line 6) 46493 * EMPTY_CLASS_EXPR: Statements for C++. (line 6) 46494 * EMPTY_FIELD_BOUNDARY: Storage Layout. (line 307) 46495 * Emulated TLS: Emulated TLS. (line 6) 46496 * enabled: Disable Insn Alternatives. 46497 (line 6) 46498 * ENDFILE_SPEC: Driver. (line 156) 46499 * endianness: Portability. (line 21) 46500 * ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 10) 46501 * enum machine_mode: Machine Modes. (line 6) 46502 * enum reg_class: Register Classes. (line 72) 46503 * ENUMERAL_TYPE: Types. (line 6) 46504 * enumerations: Constant Definitions. 46505 (line 49) 46506 * epilogue: Function Entry. (line 6) 46507 * epilogue instruction pattern: Standard Names. (line 1519) 46508 * EPILOGUE_USES: Function Entry. (line 152) 46509 * eq: Comparisons. (line 52) 46510 * eq and attributes: Expressions. (line 85) 46511 * eq_attr: Expressions. (line 106) 46512 * EQ_EXPR: Unary and Binary Expressions. 46513 (line 6) 46514 * equal: Comparisons. (line 52) 46515 * errno, implicit usage: Library Calls. (line 64) 46516 * EXACT_DIV_EXPR: Unary and Binary Expressions. 46517 (line 6) 46518 * examining SSA_NAMEs: SSA. (line 216) 46519 * exception handling <1>: Exception Handling. (line 6) 46520 * exception handling: Edges. (line 96) 46521 * exception_receiver instruction pattern: Standard Names. (line 1445) 46522 * exclamation point: Multi-Alternative. (line 47) 46523 * exclusion_set: Processor pipeline description. 46524 (line 224) 46525 * exclusive-or, bitwise: Arithmetic. (line 168) 46526 * EXIT_EXPR: Unary and Binary Expressions. 46527 (line 6) 46528 * EXIT_IGNORE_STACK: Function Entry. (line 140) 46529 * expander definitions: Expander Definitions. 46530 (line 6) 46531 * expM2 instruction pattern: Standard Names. (line 593) 46532 * EXPR_FILENAME: Working with declarations. 46533 (line 14) 46534 * EXPR_LINENO: Working with declarations. 46535 (line 20) 46536 * expr_list: Insns. (line 552) 46537 * EXPR_STMT: Statements for C++. (line 6) 46538 * EXPR_STMT_EXPR: Statements for C++. (line 6) 46539 * expression: Expression trees. (line 6) 46540 * expression codes: RTL Objects. (line 47) 46541 * extendMN2 instruction pattern: Standard Names. (line 908) 46542 * extensible constraints: Simple Constraints. (line 173) 46543 * EXTRA_ADDRESS_CONSTRAINT: Old Constraints. (line 123) 46544 * EXTRA_CONSTRAINT: Old Constraints. (line 74) 46545 * EXTRA_CONSTRAINT_STR: Old Constraints. (line 95) 46546 * EXTRA_MEMORY_CONSTRAINT: Old Constraints. (line 100) 46547 * EXTRA_SPECS: Driver. (line 183) 46548 * extv instruction pattern: Standard Names. (line 999) 46549 * extvM instruction pattern: Standard Names. (line 944) 46550 * extvmisalignM instruction pattern: Standard Names. (line 954) 46551 * extzv instruction pattern: Standard Names. (line 1017) 46552 * extzvM instruction pattern: Standard Names. (line 968) 46553 * extzvmisalignM instruction pattern: Standard Names. (line 971) 46554 * F in constraint: Simple Constraints. (line 94) 46555 * FAIL: Expander Definitions. 46556 (line 83) 46557 * fall-thru: Edges. (line 69) 46558 * FATAL_EXIT_CODE: Host Misc. (line 6) 46559 * FDL, GNU Free Documentation License: GNU Free Documentation License. 46560 (line 6) 46561 * features, optional, in system conventions: Run-time Target. 46562 (line 59) 46563 * ffs: Arithmetic. (line 211) 46564 * ffsM2 instruction pattern: Standard Names. (line 707) 46565 * FIELD_DECL: Declarations. (line 6) 46566 * file_end_indicate_exec_stack: File Framework. (line 41) 46567 * files and passes of the compiler: Passes. (line 6) 46568 * files, generated: Files. (line 6) 46569 * final_absence_set: Processor pipeline description. 46570 (line 224) 46571 * FINAL_PRESCAN_INSN: Instruction Output. (line 61) 46572 * final_presence_set: Processor pipeline description. 46573 (line 224) 46574 * final_sequence: Instruction Output. (line 145) 46575 * FIND_BASE_TERM: Addressing Modes. (line 119) 46576 * FINI_ARRAY_SECTION_ASM_OP: Sections. (line 114) 46577 * FINI_SECTION_ASM_OP: Sections. (line 99) 46578 * finite state automaton minimization: Processor pipeline description. 46579 (line 305) 46580 * FIRST_PARM_OFFSET: Frame Layout. (line 67) 46581 * FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 46582 * FIRST_PSEUDO_REGISTER: Register Basics. (line 9) 46583 * FIRST_STACK_REG: Stack Registers. (line 27) 46584 * FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 46585 * fix: Conversions. (line 66) 46586 * FIX_TRUNC_EXPR: Unary and Binary Expressions. 46587 (line 6) 46588 * fix_truncMN2 instruction pattern: Standard Names. (line 895) 46589 * fixed register: Register Basics. (line 15) 46590 * fixed-point fractional library: Fixed-point fractional library routines. 46591 (line 6) 46592 * FIXED_CONVERT_EXPR: Unary and Binary Expressions. 46593 (line 6) 46594 * FIXED_CST: Constant expressions. 46595 (line 6) 46596 * FIXED_POINT_TYPE: Types. (line 6) 46597 * FIXED_REGISTERS: Register Basics. (line 15) 46598 * fixed_regs: Register Basics. (line 59) 46599 * fixMN2 instruction pattern: Standard Names. (line 875) 46600 * fixuns_truncMN2 instruction pattern: Standard Names. (line 899) 46601 * fixunsMN2 instruction pattern: Standard Names. (line 884) 46602 * flags in RTL expression: Flags. (line 6) 46603 * float: Conversions. (line 58) 46604 * FLOAT_EXPR: Unary and Binary Expressions. 46605 (line 6) 46606 * float_extend: Conversions. (line 33) 46607 * FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 33) 46608 * FLOAT_STORE_FLAG_VALUE: Misc. (line 287) 46609 * float_truncate: Conversions. (line 53) 46610 * FLOAT_TYPE_SIZE: Type Layout. (line 49) 46611 * FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 42) 46612 * FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 46613 (line 226) 46614 * floating point and cross compilation: Floating Point. (line 6) 46615 * floatMN2 instruction pattern: Standard Names. (line 867) 46616 * floatunsMN2 instruction pattern: Standard Names. (line 871) 46617 * FLOOR_DIV_EXPR: Unary and Binary Expressions. 46618 (line 6) 46619 * FLOOR_MOD_EXPR: Unary and Binary Expressions. 46620 (line 6) 46621 * floorM2 instruction pattern: Standard Names. (line 628) 46622 * flow-insensitive alias analysis: Alias analysis. (line 6) 46623 * flow-sensitive alias analysis: Alias analysis. (line 6) 46624 * fma: Arithmetic. (line 111) 46625 * fmaM4 instruction pattern: Standard Names. (line 279) 46626 * fmodM3 instruction pattern: Standard Names. (line 546) 46627 * fmsM4 instruction pattern: Standard Names. (line 286) 46628 * fnmaM4 instruction pattern: Standard Names. (line 292) 46629 * fnmsM4 instruction pattern: Standard Names. (line 298) 46630 * FOR_BODY: Statements for C++. (line 6) 46631 * FOR_COND: Statements for C++. (line 6) 46632 * FOR_EXPR: Statements for C++. (line 6) 46633 * FOR_INIT_STMT: Statements for C++. (line 6) 46634 * FOR_STMT: Statements for C++. (line 6) 46635 * FORCE_CODE_SECTION_ALIGN: Sections. (line 145) 46636 * force_reg: Standard Names. (line 36) 46637 * fract_convert: Conversions. (line 82) 46638 * FRACT_TYPE_SIZE: Type Layout. (line 68) 46639 * fractional types: Fixed-point fractional library routines. 46640 (line 6) 46641 * fractMN2 instruction pattern: Standard Names. (line 917) 46642 * fractunsMN2 instruction pattern: Standard Names. (line 932) 46643 * frame layout: Frame Layout. (line 6) 46644 * FRAME_ADDR_RTX: Frame Layout. (line 116) 46645 * FRAME_GROWS_DOWNWARD: Frame Layout. (line 31) 46646 * FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 46647 (line 69) 46648 * FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 212) 46649 * frame_pointer_needed: Function Entry. (line 34) 46650 * FRAME_POINTER_REGNUM: Frame Registers. (line 14) 46651 * FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 46652 (line 74) 46653 * frame_pointer_rtx: Frame Registers. (line 104) 46654 * frame_related: Flags. (line 229) 46655 * frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 46656 (line 107) 46657 * frame_related, in mem: Flags. (line 85) 46658 * frame_related, in reg: Flags. (line 94) 46659 * frame_related, in symbol_ref: Flags. (line 165) 46660 * frequency, count, BB_FREQ_BASE: Profile information. 46661 (line 30) 46662 * ftruncM2 instruction pattern: Standard Names. (line 890) 46663 * function <1>: Functions for C++. (line 6) 46664 * function: Functions. (line 6) 46665 * function call conventions: Interface. (line 6) 46666 * function entry and exit: Function Entry. (line 6) 46667 * function entry point, alternate function entry point: Edges. 46668 (line 181) 46669 * function properties: Function Properties. 46670 (line 6) 46671 * function-call insns: Calls. (line 6) 46672 * FUNCTION_ARG_OFFSET: Register Arguments. (line 198) 46673 * FUNCTION_ARG_PADDING: Register Arguments. (line 205) 46674 * FUNCTION_ARG_REGNO_P: Register Arguments. (line 253) 46675 * FUNCTION_BOUNDARY: Storage Layout. (line 166) 46676 * FUNCTION_DECL <1>: Functions for C++. (line 6) 46677 * FUNCTION_DECL: Functions. (line 6) 46678 * FUNCTION_MODE: Misc. (line 342) 46679 * FUNCTION_PROFILER: Profiling. (line 9) 46680 * FUNCTION_TYPE: Types. (line 6) 46681 * FUNCTION_VALUE: Scalar Return. (line 52) 46682 * FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78) 46683 * functions, leaf: Leaf Functions. (line 6) 46684 * fundamental type: Types. (line 6) 46685 * g in constraint: Simple Constraints. (line 120) 46686 * G in constraint: Simple Constraints. (line 98) 46687 * garbage collector, invocation: Invoking the garbage collector. 46688 (line 6) 46689 * garbage collector, troubleshooting: Troubleshooting. (line 6) 46690 * GCC and portability: Portability. (line 6) 46691 * GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 46692 * gcov_type: Profile information. 46693 (line 41) 46694 * ge: Comparisons. (line 72) 46695 * ge and attributes: Expressions. (line 85) 46696 * GE_EXPR: Unary and Binary Expressions. 46697 (line 6) 46698 * GEN_ERRNO_RTX: Library Calls. (line 65) 46699 * gencodes: RTL passes. (line 18) 46700 * general_operand: Machine-Independent Predicates. 46701 (line 105) 46702 * GENERAL_REGS: Register Classes. (line 23) 46703 * generated files: Files. (line 6) 46704 * generating assembler output: Output Statement. (line 6) 46705 * generating insns: RTL Template. (line 6) 46706 * GENERIC <1>: GENERIC. (line 6) 46707 * GENERIC: Parsing pass. (line 6) 46708 * generic predicates: Machine-Independent Predicates. 46709 (line 6) 46710 * genflags: RTL passes. (line 18) 46711 * get_attr: Expressions. (line 101) 46712 * get_attr_length: Insn Lengths. (line 46) 46713 * GET_CLASS_NARROWEST_MODE: Machine Modes. (line 333) 46714 * GET_CODE: RTL Objects. (line 47) 46715 * get_frame_size: Elimination. (line 34) 46716 * get_insns: Insns. (line 34) 46717 * get_last_insn: Insns. (line 34) 46718 * GET_MODE: Machine Modes. (line 280) 46719 * GET_MODE_ALIGNMENT: Machine Modes. (line 320) 46720 * GET_MODE_BITSIZE: Machine Modes. (line 304) 46721 * GET_MODE_CLASS: Machine Modes. (line 294) 46722 * GET_MODE_FBIT: Machine Modes. (line 311) 46723 * GET_MODE_IBIT: Machine Modes. (line 307) 46724 * GET_MODE_MASK: Machine Modes. (line 315) 46725 * GET_MODE_NAME: Machine Modes. (line 291) 46726 * GET_MODE_NUNITS: Machine Modes. (line 329) 46727 * GET_MODE_SIZE: Machine Modes. (line 301) 46728 * GET_MODE_UNIT_SIZE: Machine Modes. (line 323) 46729 * GET_MODE_WIDER_MODE: Machine Modes. (line 297) 46730 * GET_RTX_CLASS: RTL Classes. (line 6) 46731 * GET_RTX_FORMAT: RTL Classes. (line 131) 46732 * GET_RTX_LENGTH: RTL Classes. (line 128) 46733 * get_thread_pointerMODE instruction pattern: Standard Names. 46734 (line 1856) 46735 * geu: Comparisons. (line 72) 46736 * geu and attributes: Expressions. (line 85) 46737 * GGC: Type Information. (line 6) 46738 * ggc_collect: Invoking the garbage collector. 46739 (line 6) 46740 * GIMPLE <1>: GIMPLE. (line 6) 46741 * GIMPLE <2>: Gimplification pass. 46742 (line 6) 46743 * GIMPLE: Parsing pass. (line 14) 46744 * GIMPLE Exception Handling: GIMPLE Exception Handling. 46745 (line 6) 46746 * GIMPLE instruction set: GIMPLE instruction set. 46747 (line 6) 46748 * GIMPLE sequences: GIMPLE sequences. (line 6) 46749 * GIMPLE statement iterators <1>: Maintaining the CFG. 46750 (line 34) 46751 * GIMPLE statement iterators: Basic Blocks. (line 78) 46752 * gimple_addresses_taken: Manipulating GIMPLE statements. 46753 (line 90) 46754 * GIMPLE_ASM: GIMPLE_ASM. (line 6) 46755 * gimple_asm_clear_volatile: GIMPLE_ASM. (line 63) 46756 * gimple_asm_clobber_op: GIMPLE_ASM. (line 46) 46757 * gimple_asm_input_op: GIMPLE_ASM. (line 30) 46758 * gimple_asm_nclobbers: GIMPLE_ASM. (line 27) 46759 * gimple_asm_ninputs: GIMPLE_ASM. (line 21) 46760 * gimple_asm_noutputs: GIMPLE_ASM. (line 24) 46761 * gimple_asm_output_op: GIMPLE_ASM. (line 38) 46762 * gimple_asm_set_clobber_op: GIMPLE_ASM. (line 50) 46763 * gimple_asm_set_input_op: GIMPLE_ASM. (line 34) 46764 * gimple_asm_set_output_op: GIMPLE_ASM. (line 42) 46765 * gimple_asm_set_volatile: GIMPLE_ASM. (line 60) 46766 * gimple_asm_string: GIMPLE_ASM. (line 53) 46767 * gimple_asm_volatile_p: GIMPLE_ASM. (line 57) 46768 * GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 46769 * gimple_assign_cast_p <1>: GIMPLE_ASSIGN. (line 93) 46770 * gimple_assign_cast_p: Logical Operators. (line 160) 46771 * gimple_assign_lhs: GIMPLE_ASSIGN. (line 51) 46772 * gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 54) 46773 * gimple_assign_rhs1: GIMPLE_ASSIGN. (line 57) 46774 * gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 60) 46775 * gimple_assign_rhs2: GIMPLE_ASSIGN. (line 64) 46776 * gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 67) 46777 * gimple_assign_rhs3: GIMPLE_ASSIGN. (line 71) 46778 * gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 74) 46779 * gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 46) 46780 * gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 41) 46781 * gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 78) 46782 * gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 81) 46783 * gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 85) 46784 * gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 89) 46785 * gimple_bb: Manipulating GIMPLE statements. 46786 (line 18) 46787 * GIMPLE_BIND: GIMPLE_BIND. (line 6) 46788 * gimple_bind_add_seq: GIMPLE_BIND. (line 36) 46789 * gimple_bind_add_stmt: GIMPLE_BIND. (line 32) 46790 * gimple_bind_append_vars: GIMPLE_BIND. (line 19) 46791 * gimple_bind_block: GIMPLE_BIND. (line 40) 46792 * gimple_bind_body: GIMPLE_BIND. (line 23) 46793 * gimple_bind_set_block: GIMPLE_BIND. (line 45) 46794 * gimple_bind_set_body: GIMPLE_BIND. (line 28) 46795 * gimple_bind_set_vars: GIMPLE_BIND. (line 15) 46796 * gimple_bind_vars: GIMPLE_BIND. (line 12) 46797 * gimple_block: Manipulating GIMPLE statements. 46798 (line 21) 46799 * gimple_build_asm: GIMPLE_ASM. (line 8) 46800 * gimple_build_asm_vec: GIMPLE_ASM. (line 17) 46801 * gimple_build_assign: GIMPLE_ASSIGN. (line 7) 46802 * gimple_build_assign_with_ops: GIMPLE_ASSIGN. (line 30) 46803 * gimple_build_bind: GIMPLE_BIND. (line 8) 46804 * gimple_build_call: GIMPLE_CALL. (line 8) 46805 * gimple_build_call_from_tree: GIMPLE_CALL. (line 16) 46806 * gimple_build_call_vec: GIMPLE_CALL. (line 25) 46807 * gimple_build_catch: GIMPLE_CATCH. (line 8) 46808 * gimple_build_cond: GIMPLE_COND. (line 8) 46809 * gimple_build_cond_from_tree: GIMPLE_COND. (line 16) 46810 * gimple_build_debug_bind: GIMPLE_DEBUG. (line 8) 46811 * gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 8) 46812 * gimple_build_goto: GIMPLE_LABEL. (line 18) 46813 * gimple_build_label: GIMPLE_LABEL. (line 7) 46814 * gimple_build_nop: GIMPLE_NOP. (line 7) 46815 * gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 46816 (line 8) 46817 * gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 46818 (line 7) 46819 * gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 46820 (line 8) 46821 * gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 46822 (line 8) 46823 * gimple_build_omp_for: GIMPLE_OMP_FOR. (line 9) 46824 * gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 7) 46825 * gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 7) 46826 * gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 46827 (line 8) 46828 * gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 7) 46829 * gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 7) 46830 * gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 46831 (line 8) 46832 * gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 46833 (line 14) 46834 * gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 8) 46835 * gimple_build_resx: GIMPLE_RESX. (line 7) 46836 * gimple_build_return: GIMPLE_RETURN. (line 7) 46837 * gimple_build_switch: GIMPLE_SWITCH. (line 8) 46838 * gimple_build_try: GIMPLE_TRY. (line 8) 46839 * gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 46840 (line 7) 46841 * GIMPLE_CALL: GIMPLE_CALL. (line 6) 46842 * gimple_call_arg: GIMPLE_CALL. (line 66) 46843 * gimple_call_arg_ptr: GIMPLE_CALL. (line 71) 46844 * gimple_call_cannot_inline_p: GIMPLE_CALL. (line 91) 46845 * gimple_call_chain: GIMPLE_CALL. (line 57) 46846 * gimple_call_copy_skip_args: GIMPLE_CALL. (line 98) 46847 * gimple_call_fn: GIMPLE_CALL. (line 38) 46848 * gimple_call_fndecl: GIMPLE_CALL. (line 46) 46849 * gimple_call_lhs: GIMPLE_CALL. (line 29) 46850 * gimple_call_lhs_ptr: GIMPLE_CALL. (line 32) 46851 * gimple_call_mark_uninlinable: GIMPLE_CALL. (line 88) 46852 * gimple_call_noreturn_p: GIMPLE_CALL. (line 94) 46853 * gimple_call_num_args: GIMPLE_CALL. (line 63) 46854 * gimple_call_return_type: GIMPLE_CALL. (line 54) 46855 * gimple_call_set_arg: GIMPLE_CALL. (line 76) 46856 * gimple_call_set_chain: GIMPLE_CALL. (line 60) 46857 * gimple_call_set_fn: GIMPLE_CALL. (line 42) 46858 * gimple_call_set_fndecl: GIMPLE_CALL. (line 51) 46859 * gimple_call_set_lhs: GIMPLE_CALL. (line 35) 46860 * gimple_call_set_tail: GIMPLE_CALL. (line 80) 46861 * gimple_call_tail_p: GIMPLE_CALL. (line 85) 46862 * GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 46863 * gimple_catch_handler: GIMPLE_CATCH. (line 20) 46864 * gimple_catch_set_handler: GIMPLE_CATCH. (line 28) 46865 * gimple_catch_set_types: GIMPLE_CATCH. (line 24) 46866 * gimple_catch_types: GIMPLE_CATCH. (line 13) 46867 * gimple_catch_types_ptr: GIMPLE_CATCH. (line 16) 46868 * gimple_code: Manipulating GIMPLE statements. 46869 (line 15) 46870 * GIMPLE_COND: GIMPLE_COND. (line 6) 46871 * gimple_cond_code: GIMPLE_COND. (line 21) 46872 * gimple_cond_false_label: GIMPLE_COND. (line 60) 46873 * gimple_cond_lhs: GIMPLE_COND. (line 30) 46874 * gimple_cond_make_false: GIMPLE_COND. (line 64) 46875 * gimple_cond_make_true: GIMPLE_COND. (line 67) 46876 * gimple_cond_rhs: GIMPLE_COND. (line 38) 46877 * gimple_cond_set_code: GIMPLE_COND. (line 26) 46878 * gimple_cond_set_false_label: GIMPLE_COND. (line 56) 46879 * gimple_cond_set_lhs: GIMPLE_COND. (line 34) 46880 * gimple_cond_set_rhs: GIMPLE_COND. (line 42) 46881 * gimple_cond_set_true_label: GIMPLE_COND. (line 51) 46882 * gimple_cond_true_label: GIMPLE_COND. (line 46) 46883 * gimple_copy: Manipulating GIMPLE statements. 46884 (line 147) 46885 * GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 46886 * GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 46887 * gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 48) 46888 * gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 53) 46889 * gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 45) 46890 * gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 70) 46891 * gimple_debug_bind_p: Logical Operators. (line 164) 46892 * gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 66) 46893 * gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 62) 46894 * gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 58) 46895 * gimple_def_ops: Manipulating GIMPLE statements. 46896 (line 94) 46897 * GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 46898 * gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 19) 46899 * gimple_eh_filter_must_not_throw: GIMPLE_EH_FILTER. (line 33) 46900 * gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 29) 46901 * gimple_eh_filter_set_must_not_throw: GIMPLE_EH_FILTER. (line 37) 46902 * gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 24) 46903 * gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 12) 46904 * gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 15) 46905 * gimple_expr_code: Manipulating GIMPLE statements. 46906 (line 31) 46907 * gimple_expr_type: Manipulating GIMPLE statements. 46908 (line 24) 46909 * gimple_goto_dest: GIMPLE_LABEL. (line 21) 46910 * gimple_goto_set_dest: GIMPLE_LABEL. (line 24) 46911 * gimple_has_mem_ops: Manipulating GIMPLE statements. 46912 (line 72) 46913 * gimple_has_ops: Manipulating GIMPLE statements. 46914 (line 69) 46915 * gimple_has_volatile_ops: Manipulating GIMPLE statements. 46916 (line 134) 46917 * GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 46918 * gimple_label_label: GIMPLE_LABEL. (line 11) 46919 * gimple_label_set_label: GIMPLE_LABEL. (line 14) 46920 * gimple_loaded_syms: Manipulating GIMPLE statements. 46921 (line 122) 46922 * gimple_locus: Manipulating GIMPLE statements. 46923 (line 42) 46924 * gimple_locus_empty_p: Manipulating GIMPLE statements. 46925 (line 48) 46926 * gimple_modified_p: Manipulating GIMPLE statements. 46927 (line 130) 46928 * gimple_no_warning_p: Manipulating GIMPLE statements. 46929 (line 51) 46930 * GIMPLE_NOP: GIMPLE_NOP. (line 6) 46931 * gimple_nop_p: GIMPLE_NOP. (line 10) 46932 * gimple_num_ops <1>: Manipulating GIMPLE statements. 46933 (line 75) 46934 * gimple_num_ops: Logical Operators. (line 78) 46935 * GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 46936 (line 6) 46937 * gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 46938 (line 17) 46939 * gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 46940 (line 24) 46941 * gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 46942 (line 14) 46943 * gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 46944 (line 21) 46945 * GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 46946 (line 6) 46947 * gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 46948 (line 12) 46949 * gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 46950 (line 15) 46951 * gimple_omp_body: GIMPLE_OMP_PARALLEL. 46952 (line 24) 46953 * GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 46954 (line 6) 46955 * gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 46956 (line 13) 46957 * gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 46958 (line 17) 46959 * gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 46960 (line 24) 46961 * gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 46962 (line 28) 46963 * gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 46964 (line 20) 46965 * gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 46966 (line 31) 46967 * GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 46968 (line 6) 46969 * gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 46970 (line 13) 46971 * gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 46972 (line 16) 46973 * gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 46974 (line 21) 46975 * GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 46976 * gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 20) 46977 * gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 23) 46978 * gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 83) 46979 * gimple_omp_for_final: GIMPLE_OMP_FOR. (line 51) 46980 * gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 54) 46981 * gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 61) 46982 * gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 64) 46983 * gimple_omp_for_index: GIMPLE_OMP_FOR. (line 31) 46984 * gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 34) 46985 * gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 41) 46986 * gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 44) 46987 * gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 70) 46988 * gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 27) 46989 * gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 80) 46990 * gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 58) 46991 * gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 67) 46992 * gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 38) 46993 * gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 48) 46994 * gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 75) 46995 * GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 46996 * GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 46997 * GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 46998 (line 6) 46999 * gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 47000 (line 42) 47001 * gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 47002 (line 46) 47003 * gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 47004 (line 31) 47005 * gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 47006 (line 34) 47007 * gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 47008 (line 16) 47009 * gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 47010 (line 54) 47011 * gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 47012 (line 58) 47013 * gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 47014 (line 51) 47015 * gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 47016 (line 38) 47017 * gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 47018 (line 20) 47019 * gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 47020 (line 62) 47021 * GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 47022 * gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 14) 47023 * gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 11) 47024 * GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 47025 * gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 12) 47026 * gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 16) 47027 * GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 47028 (line 6) 47029 * gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 47030 (line 30) 47031 * gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 47032 (line 33) 47033 * gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 47034 (line 17) 47035 * gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 47036 (line 21) 47037 * gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 47038 (line 37) 47039 * gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 47040 (line 26) 47041 * gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 47042 (line 28) 47043 * GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 47044 * gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 14) 47045 * gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 17) 47046 * gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 21) 47047 * gimple_op <1>: Manipulating GIMPLE statements. 47048 (line 81) 47049 * gimple_op: Logical Operators. (line 81) 47050 * gimple_op_ptr: Manipulating GIMPLE statements. 47051 (line 84) 47052 * gimple_ops <1>: Manipulating GIMPLE statements. 47053 (line 78) 47054 * gimple_ops: Logical Operators. (line 84) 47055 * GIMPLE_PHI: GIMPLE_PHI. (line 6) 47056 * gimple_phi_arg: GIMPLE_PHI. (line 25) 47057 * gimple_phi_capacity: GIMPLE_PHI. (line 7) 47058 * gimple_phi_num_args: GIMPLE_PHI. (line 11) 47059 * gimple_phi_result: GIMPLE_PHI. (line 16) 47060 * gimple_phi_result_ptr: GIMPLE_PHI. (line 19) 47061 * gimple_phi_set_arg: GIMPLE_PHI. (line 30) 47062 * gimple_phi_set_result: GIMPLE_PHI. (line 22) 47063 * gimple_plf: Manipulating GIMPLE statements. 47064 (line 66) 47065 * GIMPLE_RESX: GIMPLE_RESX. (line 6) 47066 * gimple_resx_region: GIMPLE_RESX. (line 13) 47067 * gimple_resx_set_region: GIMPLE_RESX. (line 16) 47068 * GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 47069 * gimple_return_retval: GIMPLE_RETURN. (line 10) 47070 * gimple_return_set_retval: GIMPLE_RETURN. (line 14) 47071 * gimple_seq_add_seq: GIMPLE sequences. (line 32) 47072 * gimple_seq_add_stmt: GIMPLE sequences. (line 26) 47073 * gimple_seq_alloc: GIMPLE sequences. (line 62) 47074 * gimple_seq_copy: GIMPLE sequences. (line 67) 47075 * gimple_seq_deep_copy: GIMPLE sequences. (line 37) 47076 * gimple_seq_empty_p: GIMPLE sequences. (line 70) 47077 * gimple_seq_first: GIMPLE sequences. (line 44) 47078 * gimple_seq_init: GIMPLE sequences. (line 59) 47079 * gimple_seq_last: GIMPLE sequences. (line 47) 47080 * gimple_seq_reverse: GIMPLE sequences. (line 40) 47081 * gimple_seq_set_first: GIMPLE sequences. (line 55) 47082 * gimple_seq_set_last: GIMPLE sequences. (line 51) 47083 * gimple_seq_singleton_p: GIMPLE sequences. (line 79) 47084 * gimple_set_block: Manipulating GIMPLE statements. 47085 (line 39) 47086 * gimple_set_def_ops: Manipulating GIMPLE statements. 47087 (line 98) 47088 * gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 47089 (line 138) 47090 * gimple_set_locus: Manipulating GIMPLE statements. 47091 (line 45) 47092 * gimple_set_op: Manipulating GIMPLE statements. 47093 (line 87) 47094 * gimple_set_plf: Manipulating GIMPLE statements. 47095 (line 62) 47096 * gimple_set_use_ops: Manipulating GIMPLE statements. 47097 (line 105) 47098 * gimple_set_vdef_ops: Manipulating GIMPLE statements. 47099 (line 119) 47100 * gimple_set_visited: Manipulating GIMPLE statements. 47101 (line 55) 47102 * gimple_set_vuse_ops: Manipulating GIMPLE statements. 47103 (line 112) 47104 * gimple_statement_base: Tuple representation. 47105 (line 14) 47106 * gimple_statement_with_ops: Tuple representation. 47107 (line 96) 47108 * gimple_stored_syms: Manipulating GIMPLE statements. 47109 (line 126) 47110 * GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 47111 * gimple_switch_default_label: GIMPLE_SWITCH. (line 39) 47112 * gimple_switch_index: GIMPLE_SWITCH. (line 24) 47113 * gimple_switch_label: GIMPLE_SWITCH. (line 30) 47114 * gimple_switch_num_labels: GIMPLE_SWITCH. (line 15) 47115 * gimple_switch_set_default_label: GIMPLE_SWITCH. (line 43) 47116 * gimple_switch_set_index: GIMPLE_SWITCH. (line 27) 47117 * gimple_switch_set_label: GIMPLE_SWITCH. (line 35) 47118 * gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 20) 47119 * GIMPLE_TRY: GIMPLE_TRY. (line 6) 47120 * gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 20) 47121 * gimple_try_cleanup: GIMPLE_TRY. (line 27) 47122 * gimple_try_eval: GIMPLE_TRY. (line 23) 47123 * gimple_try_kind: GIMPLE_TRY. (line 16) 47124 * gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 32) 47125 * gimple_try_set_cleanup: GIMPLE_TRY. (line 41) 47126 * gimple_try_set_eval: GIMPLE_TRY. (line 36) 47127 * gimple_use_ops: Manipulating GIMPLE statements. 47128 (line 101) 47129 * gimple_vdef_ops: Manipulating GIMPLE statements. 47130 (line 115) 47131 * gimple_visited_p: Manipulating GIMPLE statements. 47132 (line 58) 47133 * gimple_vuse_ops: Manipulating GIMPLE statements. 47134 (line 108) 47135 * gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 47136 (line 11) 47137 * gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 47138 (line 18) 47139 * gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 47140 (line 15) 47141 * gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 47142 (line 22) 47143 * GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 47144 (line 6) 47145 * gimplification <1>: Gimplification pass. 47146 (line 6) 47147 * gimplification: Parsing pass. (line 14) 47148 * gimplifier: Parsing pass. (line 14) 47149 * gimplify_assign: GIMPLE_ASSIGN. (line 19) 47150 * gimplify_expr: Gimplification pass. 47151 (line 18) 47152 * gimplify_function_tree: Gimplification pass. 47153 (line 18) 47154 * GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 47155 * global_regs: Register Basics. (line 59) 47156 * GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 91) 47157 * greater than: Comparisons. (line 60) 47158 * gsi_after_labels: Sequence iterators. (line 76) 47159 * gsi_bb: Sequence iterators. (line 83) 47160 * gsi_commit_edge_inserts <1>: Maintaining the CFG. 47161 (line 107) 47162 * gsi_commit_edge_inserts: Sequence iterators. (line 194) 47163 * gsi_commit_one_edge_insert: Sequence iterators. (line 190) 47164 * gsi_end_p <1>: Maintaining the CFG. 47165 (line 49) 47166 * gsi_end_p: Sequence iterators. (line 60) 47167 * gsi_for_stmt: Sequence iterators. (line 157) 47168 * gsi_insert_after <1>: Maintaining the CFG. 47169 (line 61) 47170 * gsi_insert_after: Sequence iterators. (line 147) 47171 * gsi_insert_before <1>: Maintaining the CFG. 47172 (line 67) 47173 * gsi_insert_before: Sequence iterators. (line 136) 47174 * gsi_insert_on_edge <1>: Maintaining the CFG. 47175 (line 107) 47176 * gsi_insert_on_edge: Sequence iterators. (line 174) 47177 * gsi_insert_on_edge_immediate: Sequence iterators. (line 185) 47178 * gsi_insert_seq_after: Sequence iterators. (line 154) 47179 * gsi_insert_seq_before: Sequence iterators. (line 143) 47180 * gsi_insert_seq_on_edge: Sequence iterators. (line 179) 47181 * gsi_last <1>: Maintaining the CFG. 47182 (line 45) 47183 * gsi_last: Sequence iterators. (line 50) 47184 * gsi_last_bb: Sequence iterators. (line 56) 47185 * gsi_link_after: Sequence iterators. (line 115) 47186 * gsi_link_before: Sequence iterators. (line 105) 47187 * gsi_link_seq_after: Sequence iterators. (line 110) 47188 * gsi_link_seq_before: Sequence iterators. (line 99) 47189 * gsi_move_after: Sequence iterators. (line 161) 47190 * gsi_move_before: Sequence iterators. (line 166) 47191 * gsi_move_to_bb_end: Sequence iterators. (line 171) 47192 * gsi_next <1>: Maintaining the CFG. 47193 (line 53) 47194 * gsi_next: Sequence iterators. (line 66) 47195 * gsi_one_before_end_p: Sequence iterators. (line 63) 47196 * gsi_prev <1>: Maintaining the CFG. 47197 (line 57) 47198 * gsi_prev: Sequence iterators. (line 69) 47199 * gsi_remove <1>: Maintaining the CFG. 47200 (line 73) 47201 * gsi_remove: Sequence iterators. (line 90) 47202 * gsi_replace: Sequence iterators. (line 130) 47203 * gsi_seq: Sequence iterators. (line 86) 47204 * gsi_split_seq_after: Sequence iterators. (line 120) 47205 * gsi_split_seq_before: Sequence iterators. (line 125) 47206 * gsi_start <1>: Maintaining the CFG. 47207 (line 41) 47208 * gsi_start: Sequence iterators. (line 40) 47209 * gsi_start_bb: Sequence iterators. (line 46) 47210 * gsi_stmt: Sequence iterators. (line 72) 47211 * gsi_stmt_ptr: Sequence iterators. (line 80) 47212 * gt: Comparisons. (line 60) 47213 * gt and attributes: Expressions. (line 85) 47214 * GT_EXPR: Unary and Binary Expressions. 47215 (line 6) 47216 * gtu: Comparisons. (line 64) 47217 * gtu and attributes: Expressions. (line 85) 47218 * GTY: Type Information. (line 6) 47219 * H in constraint: Simple Constraints. (line 98) 47220 * HAmode: Machine Modes. (line 144) 47221 * HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 436) 47222 * HANDLER: Statements for C++. (line 6) 47223 * HANDLER_BODY: Statements for C++. (line 6) 47224 * HANDLER_PARMS: Statements for C++. (line 6) 47225 * hard registers: Regs and Memory. (line 9) 47226 * HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 58) 47227 * HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 51) 47228 * HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20) 47229 * HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53) 47230 * HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 20) 47231 * HARD_REGNO_MODE_OK: Values in Registers. 47232 (line 58) 47233 * HARD_REGNO_NREGS: Values in Registers. 47234 (line 11) 47235 * HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 47236 (line 25) 47237 * HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 47238 (line 43) 47239 * HARD_REGNO_RENAME_OK: Values in Registers. 47240 (line 119) 47241 * HAS_INIT_SECTION: Macros for Initialization. 47242 (line 19) 47243 * HAS_LONG_COND_BRANCH: Misc. (line 9) 47244 * HAS_LONG_UNCOND_BRANCH: Misc. (line 18) 47245 * HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 47246 * HAVE_POST_DECREMENT: Addressing Modes. (line 12) 47247 * HAVE_POST_INCREMENT: Addressing Modes. (line 11) 47248 * HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18) 47249 * HAVE_POST_MODIFY_REG: Addressing Modes. (line 24) 47250 * HAVE_PRE_DECREMENT: Addressing Modes. (line 10) 47251 * HAVE_PRE_INCREMENT: Addressing Modes. (line 9) 47252 * HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17) 47253 * HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23) 47254 * HCmode: Machine Modes. (line 197) 47255 * HFmode: Machine Modes. (line 58) 47256 * high: Constants. (line 120) 47257 * HImode: Machine Modes. (line 29) 47258 * HImode, in insn: Insns. (line 278) 47259 * HONOR_REG_ALLOC_ORDER: Allocation Order. (line 37) 47260 * host configuration: Host Config. (line 6) 47261 * host functions: Host Common. (line 6) 47262 * host hooks: Host Common. (line 6) 47263 * host makefile fragment: Host Fragment. (line 6) 47264 * HOST_BIT_BUCKET: Filesystem. (line 51) 47265 * HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 47266 * HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 12) 47267 * HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 45) 47268 * HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 17) 47269 * HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 26) 47270 * HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 47271 * HOST_LONG_FORMAT: Host Misc. (line 45) 47272 * HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 47273 * HOST_OBJECT_SUFFIX: Filesystem. (line 40) 47274 * HOST_PTR_PRINTF: Host Misc. (line 49) 47275 * HOT_TEXT_SECTION_NAME: Sections. (line 43) 47276 * HQmode: Machine Modes. (line 107) 47277 * I in constraint: Simple Constraints. (line 81) 47278 * i in constraint: Simple Constraints. (line 70) 47279 * identifier: Identifiers. (line 6) 47280 * IDENTIFIER_LENGTH: Identifiers. (line 22) 47281 * IDENTIFIER_NODE: Identifiers. (line 6) 47282 * IDENTIFIER_OPNAME_P: Identifiers. (line 27) 47283 * IDENTIFIER_POINTER: Identifiers. (line 17) 47284 * IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 47285 * IEEE 754-2008: Decimal float library routines. 47286 (line 6) 47287 * IF_COND: Statements for C++. (line 6) 47288 * if_marked: GTY Options. (line 156) 47289 * IF_STMT: Statements for C++. (line 6) 47290 * if_then_else: Comparisons. (line 80) 47291 * if_then_else and attributes: Expressions. (line 32) 47292 * if_then_else usage: Side Effects. (line 56) 47293 * IFCVT_MACHDEP_INIT: Misc. (line 560) 47294 * IFCVT_MODIFY_CANCEL: Misc. (line 554) 47295 * IFCVT_MODIFY_FINAL: Misc. (line 548) 47296 * IFCVT_MODIFY_INSN: Misc. (line 542) 47297 * IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 535) 47298 * IFCVT_MODIFY_TESTS: Misc. (line 524) 47299 * IMAGPART_EXPR: Unary and Binary Expressions. 47300 (line 6) 47301 * Immediate Uses: SSA Operands. (line 274) 47302 * immediate_operand: Machine-Independent Predicates. 47303 (line 11) 47304 * IMMEDIATE_PREFIX: Instruction Output. (line 155) 47305 * in_struct: Flags. (line 245) 47306 * in_struct, in code_label and note: Flags. (line 59) 47307 * in_struct, in insn and jump_insn and call_insn: Flags. (line 49) 47308 * in_struct, in insn, jump_insn and call_insn: Flags. (line 148) 47309 * in_struct, in subreg: Flags. (line 187) 47310 * include: Including Patterns. (line 6) 47311 * INCLUDE_DEFAULTS: Driver. (line 328) 47312 * inclusive-or, bitwise: Arithmetic. (line 163) 47313 * INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 183) 47314 * INCOMING_REGNO: Register Basics. (line 88) 47315 * INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 139) 47316 * INCOMING_STACK_BOUNDARY: Storage Layout. (line 161) 47317 * INDEX_REG_CLASS: Register Classes. (line 143) 47318 * indirect_jump instruction pattern: Standard Names. (line 1225) 47319 * indirect_operand: Machine-Independent Predicates. 47320 (line 71) 47321 * INDIRECT_REF: Storage References. (line 6) 47322 * INIT_ARRAY_SECTION_ASM_OP: Sections. (line 107) 47323 * INIT_CUMULATIVE_ARGS: Register Arguments. (line 150) 47324 * INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 177) 47325 * INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 171) 47326 * INIT_ENVIRONMENT: Driver. (line 306) 47327 * INIT_EXPANDERS: Per-Function Data. (line 39) 47328 * INIT_EXPR: Unary and Binary Expressions. 47329 (line 6) 47330 * init_machine_status: Per-Function Data. (line 45) 47331 * init_one_libfunc: Library Calls. (line 15) 47332 * INIT_SECTION_ASM_OP <1>: Macros for Initialization. 47333 (line 10) 47334 * INIT_SECTION_ASM_OP: Sections. (line 91) 47335 * INITIAL_ELIMINATION_OFFSET: Elimination. (line 85) 47336 * INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 83) 47337 * INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 35) 47338 * initialization routines: Initialization. (line 6) 47339 * inlining: Target Attributes. (line 95) 47340 * insert_insn_on_edge: Maintaining the CFG. 47341 (line 107) 47342 * insn: Insns. (line 63) 47343 * insn and /f: Flags. (line 107) 47344 * insn and /j: Flags. (line 157) 47345 * insn and /s: Flags. (line 49) 47346 * insn and /u: Flags. (line 39) 47347 * insn and /v: Flags. (line 44) 47348 * insn attributes: Insn Attributes. (line 6) 47349 * insn canonicalization: Insn Canonicalizations. 47350 (line 6) 47351 * insn includes: Including Patterns. (line 6) 47352 * insn lengths, computing: Insn Lengths. (line 6) 47353 * insn notes, notes: Basic Blocks. (line 52) 47354 * insn splitting: Insn Splitting. (line 6) 47355 * insn-attr.h: Defining Attributes. 47356 (line 32) 47357 * INSN_ANNULLED_BRANCH_P: Flags. (line 39) 47358 * INSN_CODE: Insns. (line 305) 47359 * INSN_DELETED_P: Flags. (line 44) 47360 * INSN_FROM_TARGET_P: Flags. (line 49) 47361 * insn_list: Insns. (line 552) 47362 * INSN_REFERENCES_ARE_DELAYED: Misc. (line 463) 47363 * INSN_SETS_ARE_DELAYED: Misc. (line 452) 47364 * INSN_UID: Insns. (line 23) 47365 * INSN_VAR_LOCATION: Insns. (line 245) 47366 * insns: Insns. (line 6) 47367 * insns, generating: RTL Template. (line 6) 47368 * insns, recognizing: RTL Template. (line 6) 47369 * instruction attributes: Insn Attributes. (line 6) 47370 * instruction latency time: Processor pipeline description. 47371 (line 6) 47372 * instruction patterns: Patterns. (line 6) 47373 * instruction splitting: Insn Splitting. (line 6) 47374 * insv instruction pattern: Standard Names. (line 1023) 47375 * insvM instruction pattern: Standard Names. (line 975) 47376 * insvmisalignM instruction pattern: Standard Names. (line 985) 47377 * int iterators in .md files: Int Iterators. (line 6) 47378 * INT16_TYPE: Type Layout. (line 254) 47379 * INT32_TYPE: Type Layout. (line 255) 47380 * INT64_TYPE: Type Layout. (line 256) 47381 * INT8_TYPE: Type Layout. (line 253) 47382 * INT_FAST16_TYPE: Type Layout. (line 270) 47383 * INT_FAST32_TYPE: Type Layout. (line 271) 47384 * INT_FAST64_TYPE: Type Layout. (line 272) 47385 * INT_FAST8_TYPE: Type Layout. (line 269) 47386 * INT_LEAST16_TYPE: Type Layout. (line 262) 47387 * INT_LEAST32_TYPE: Type Layout. (line 263) 47388 * INT_LEAST64_TYPE: Type Layout. (line 264) 47389 * INT_LEAST8_TYPE: Type Layout. (line 261) 47390 * INT_TYPE_SIZE: Type Layout. (line 12) 47391 * INTEGER_CST: Constant expressions. 47392 (line 6) 47393 * INTEGER_TYPE: Types. (line 6) 47394 * Interdependence of Patterns: Dependent Patterns. (line 6) 47395 * interfacing to GCC output: Interface. (line 6) 47396 * interlock delays: Processor pipeline description. 47397 (line 6) 47398 * intermediate representation lowering: Parsing pass. (line 14) 47399 * INTMAX_TYPE: Type Layout. (line 230) 47400 * INTPTR_TYPE: Type Layout. (line 277) 47401 * introduction: Top. (line 6) 47402 * INVOKE__main: Macros for Initialization. 47403 (line 51) 47404 * ior: Arithmetic. (line 163) 47405 * ior and attributes: Expressions. (line 50) 47406 * ior, canonicalization of: Insn Canonicalizations. 47407 (line 52) 47408 * iorM3 instruction pattern: Standard Names. (line 269) 47409 * IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 45) 47410 * IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 121) 47411 * is_gimple_addressable: Logical Operators. (line 115) 47412 * is_gimple_asm_val: Logical Operators. (line 119) 47413 * is_gimple_assign: Logical Operators. (line 151) 47414 * is_gimple_call: Logical Operators. (line 154) 47415 * is_gimple_call_addr: Logical Operators. (line 122) 47416 * is_gimple_constant: Logical Operators. (line 130) 47417 * is_gimple_debug: Logical Operators. (line 157) 47418 * is_gimple_ip_invariant: Logical Operators. (line 139) 47419 * is_gimple_ip_invariant_address: Logical Operators. (line 144) 47420 * is_gimple_mem_ref_addr: Logical Operators. (line 126) 47421 * is_gimple_min_invariant: Logical Operators. (line 133) 47422 * is_gimple_omp: GIMPLE_OMP_PARALLEL. 47423 (line 65) 47424 * is_gimple_val: Logical Operators. (line 109) 47425 * iterators in .md files: Iterators. (line 6) 47426 * IV analysis on GIMPLE: Scalar evolutions. (line 6) 47427 * IV analysis on RTL: loop-iv. (line 6) 47428 * JMP_BUF_SIZE: Exception Region Output. 47429 (line 84) 47430 * jump: Flags. (line 286) 47431 * jump instruction pattern: Standard Names. (line 1102) 47432 * jump instruction patterns: Jump Patterns. (line 6) 47433 * jump instructions and set: Side Effects. (line 56) 47434 * jump, in call_insn: Flags. (line 161) 47435 * jump, in insn: Flags. (line 157) 47436 * jump, in mem: Flags. (line 70) 47437 * JUMP_ALIGN: Alignment Output. (line 9) 47438 * jump_insn: Insns. (line 73) 47439 * jump_insn and /f: Flags. (line 107) 47440 * jump_insn and /s: Flags. (line 49) 47441 * jump_insn and /u: Flags. (line 39) 47442 * jump_insn and /v: Flags. (line 44) 47443 * JUMP_LABEL: Insns. (line 80) 47444 * JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 151) 47445 * Jumps: Jumps. (line 6) 47446 * LABEL_ALIGN: Alignment Output. (line 58) 47447 * LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 27) 47448 * LABEL_ALT_ENTRY_P: Insns. (line 146) 47449 * LABEL_ALTERNATE_NAME: Edges. (line 181) 47450 * LABEL_DECL: Declarations. (line 6) 47451 * LABEL_KIND: Insns. (line 146) 47452 * LABEL_NUSES: Insns. (line 142) 47453 * LABEL_PRESERVE_P: Flags. (line 59) 47454 * label_ref: Constants. (line 97) 47455 * label_ref and /v: Flags. (line 65) 47456 * label_ref, RTL sharing: Sharing. (line 35) 47457 * LABEL_REF_NONLOCAL_P: Flags. (line 65) 47458 * lang_hooks.gimplify_expr: Gimplification pass. 47459 (line 18) 47460 * lang_hooks.parse_file: Parsing pass. (line 6) 47461 * language-dependent trees: Language-dependent trees. 47462 (line 6) 47463 * language-independent intermediate representation: Parsing pass. 47464 (line 14) 47465 * large return values: Aggregate Return. (line 6) 47466 * LARGEST_EXPONENT_IS_NORMAL: Storage Layout. (line 486) 47467 * LAST_STACK_REG: Stack Registers. (line 31) 47468 * LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 47469 * lceilMN2: Standard Names. (line 693) 47470 * LCSSA: LCSSA. (line 6) 47471 * LD_FINI_SWITCH: Macros for Initialization. 47472 (line 29) 47473 * LD_INIT_SWITCH: Macros for Initialization. 47474 (line 25) 47475 * LDD_SUFFIX: Macros for Initialization. 47476 (line 122) 47477 * le: Comparisons. (line 76) 47478 * le and attributes: Expressions. (line 85) 47479 * LE_EXPR: Unary and Binary Expressions. 47480 (line 6) 47481 * leaf functions: Leaf Functions. (line 6) 47482 * leaf_function_p: Standard Names. (line 1187) 47483 * LEAF_REG_REMAP: Leaf Functions. (line 39) 47484 * LEAF_REGISTERS: Leaf Functions. (line 25) 47485 * left rotate: Arithmetic. (line 195) 47486 * left shift: Arithmetic. (line 173) 47487 * LEGITIMATE_PIC_OPERAND_P: PIC. (line 32) 47488 * LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 153) 47489 * length: GTY Options. (line 50) 47490 * less than: Comparisons. (line 68) 47491 * less than or equal: Comparisons. (line 76) 47492 * leu: Comparisons. (line 76) 47493 * leu and attributes: Expressions. (line 85) 47494 * lfloorMN2: Standard Names. (line 688) 47495 * LIB2FUNCS_EXTRA: Target Fragment. (line 11) 47496 * LIB_SPEC: Driver. (line 108) 47497 * LIBCALL_VALUE: Scalar Return. (line 56) 47498 * libgcc.a: Library Calls. (line 6) 47499 * LIBGCC2_CFLAGS: Target Fragment. (line 8) 47500 * LIBGCC2_GNU_PREFIX: Type Layout. (line 128) 47501 * LIBGCC2_HAS_DF_MODE: Type Layout. (line 109) 47502 * LIBGCC2_HAS_TF_MODE: Type Layout. (line 122) 47503 * LIBGCC2_HAS_XF_MODE: Type Layout. (line 116) 47504 * LIBGCC2_LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 103) 47505 * LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 963) 47506 * LIBGCC_SPEC: Driver. (line 116) 47507 * library subroutine names: Library Calls. (line 6) 47508 * LIBRARY_PATH_ENV: Misc. (line 503) 47509 * LIMIT_RELOAD_CLASS: Register Classes. (line 300) 47510 * Linear loop transformations framework: Lambda. (line 6) 47511 * LINK_COMMAND_SPEC: Driver. (line 237) 47512 * LINK_EH_SPEC: Driver. (line 143) 47513 * LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 233) 47514 * LINK_LIBGCC_SPECIAL_1: Driver. (line 228) 47515 * LINK_SPEC: Driver. (line 101) 47516 * list: Containers. (line 6) 47517 * Liveness representation: Liveness information. 47518 (line 6) 47519 * lo_sum: Arithmetic. (line 24) 47520 * load address instruction: Simple Constraints. (line 164) 47521 * LOAD_EXTEND_OP: Misc. (line 60) 47522 * load_multiple instruction pattern: Standard Names. (line 137) 47523 * Local Register Allocator (LRA): RTL passes. (line 200) 47524 * LOCAL_ALIGNMENT: Storage Layout. (line 250) 47525 * LOCAL_CLASS_P: Classes. (line 73) 47526 * LOCAL_DECL_ALIGNMENT: Storage Layout. (line 287) 47527 * LOCAL_INCLUDE_DIR: Driver. (line 313) 47528 * LOCAL_LABEL_PREFIX: Instruction Output. (line 153) 47529 * LOCAL_REGNO: Register Basics. (line 102) 47530 * LOG_LINKS: Insns. (line 324) 47531 * Logical Operators: Logical Operators. (line 6) 47532 * logical-and, bitwise: Arithmetic. (line 158) 47533 * LOGICAL_OP_NON_SHORT_CIRCUIT: Costs. (line 265) 47534 * logM2 instruction pattern: Standard Names. (line 601) 47535 * LONG_ACCUM_TYPE_SIZE: Type Layout. (line 93) 47536 * LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 58) 47537 * LONG_FRACT_TYPE_SIZE: Type Layout. (line 73) 47538 * LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 98) 47539 * LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 78) 47540 * LONG_LONG_TYPE_SIZE: Type Layout. (line 33) 47541 * LONG_TYPE_SIZE: Type Layout. (line 22) 47542 * longjmp and automatic variables: Interface. (line 52) 47543 * Loop analysis: Loop representation. 47544 (line 6) 47545 * Loop manipulation: Loop manipulation. (line 6) 47546 * Loop querying: Loop querying. (line 6) 47547 * Loop representation: Loop representation. 47548 (line 6) 47549 * Loop-closed SSA form: LCSSA. (line 6) 47550 * LOOP_ALIGN: Alignment Output. (line 41) 47551 * LOOP_EXPR: Unary and Binary Expressions. 47552 (line 6) 47553 * looping instruction patterns: Looping Patterns. (line 6) 47554 * lowering, language-dependent intermediate representation: Parsing pass. 47555 (line 14) 47556 * lrintMN2: Standard Names. (line 678) 47557 * lroundMN2: Standard Names. (line 683) 47558 * LSHIFT_EXPR: Unary and Binary Expressions. 47559 (line 6) 47560 * lshiftrt: Arithmetic. (line 190) 47561 * lshiftrt and attributes: Expressions. (line 85) 47562 * lshrM3 instruction pattern: Standard Names. (line 520) 47563 * lt: Comparisons. (line 68) 47564 * lt and attributes: Expressions. (line 85) 47565 * LT_EXPR: Unary and Binary Expressions. 47566 (line 6) 47567 * LTGT_EXPR: Unary and Binary Expressions. 47568 (line 6) 47569 * lto: LTO. (line 6) 47570 * ltrans: LTO. (line 6) 47571 * ltu: Comparisons. (line 68) 47572 * m in constraint: Simple Constraints. (line 17) 47573 * machine attributes: Target Attributes. (line 6) 47574 * machine description macros: Target Macros. (line 6) 47575 * machine descriptions: Machine Desc. (line 6) 47576 * machine mode conversions: Conversions. (line 6) 47577 * machine modes: Machine Modes. (line 6) 47578 * machine specific constraints: Machine Constraints. 47579 (line 6) 47580 * machine-independent predicates: Machine-Independent Predicates. 47581 (line 6) 47582 * macros, target description: Target Macros. (line 6) 47583 * maddMN4 instruction pattern: Standard Names. (line 443) 47584 * MAKE_DECL_ONE_ONLY: Label Output. (line 250) 47585 * make_safe_from: Expander Definitions. 47586 (line 151) 47587 * makefile fragment: Fragments. (line 6) 47588 * makefile targets: Makefile. (line 6) 47589 * MALLOC_ABI_ALIGNMENT: Storage Layout. (line 175) 47590 * Manipulating GIMPLE statements: Manipulating GIMPLE statements. 47591 (line 6) 47592 * mark_hook: GTY Options. (line 171) 47593 * marking roots: GGC Roots. (line 6) 47594 * MASK_RETURN_ADDR: Exception Region Output. 47595 (line 35) 47596 * match_dup <1>: define_peephole2. (line 28) 47597 * match_dup: RTL Template. (line 73) 47598 * match_dup and attributes: Insn Lengths. (line 16) 47599 * match_op_dup: RTL Template. (line 163) 47600 * match_operand: RTL Template. (line 16) 47601 * match_operand and attributes: Expressions. (line 55) 47602 * match_operator: RTL Template. (line 95) 47603 * match_par_dup: RTL Template. (line 219) 47604 * match_parallel: RTL Template. (line 172) 47605 * match_scratch <1>: define_peephole2. (line 28) 47606 * match_scratch: RTL Template. (line 58) 47607 * match_test and attributes: Expressions. (line 64) 47608 * matching constraint: Simple Constraints. (line 142) 47609 * matching operands: Output Template. (line 49) 47610 * math library: Soft float library routines. 47611 (line 6) 47612 * math, in RTL: Arithmetic. (line 6) 47613 * MATH_LIBRARY: Misc. (line 496) 47614 * matherr: Library Calls. (line 52) 47615 * MAX_BITS_PER_WORD: Storage Layout. (line 60) 47616 * MAX_CONDITIONAL_EXECUTE: Misc. (line 518) 47617 * MAX_FIXED_MODE_SIZE: Storage Layout. (line 433) 47618 * MAX_MOVE_MAX: Misc. (line 106) 47619 * MAX_OFILE_ALIGNMENT: Storage Layout. (line 212) 47620 * MAX_REGS_PER_ADDRESS: Addressing Modes. (line 43) 47621 * MAX_STACK_ALIGNMENT: Storage Layout. (line 205) 47622 * maxM3 instruction pattern: Standard Names. (line 304) 47623 * may_trap_p, tree_could_trap_p: Edges. (line 115) 47624 * maybe_undef: GTY Options. (line 179) 47625 * mcount: Profiling. (line 12) 47626 * MD_CAN_REDIRECT_BRANCH: Misc. (line 678) 47627 * MD_EXEC_PREFIX: Driver. (line 268) 47628 * MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 94) 47629 * MD_HANDLE_UNWABI: Exception Handling. (line 114) 47630 * MD_STARTFILE_PREFIX: Driver. (line 296) 47631 * MD_STARTFILE_PREFIX_1: Driver. (line 301) 47632 * mem: Regs and Memory. (line 374) 47633 * mem and /c: Flags. (line 81) 47634 * mem and /f: Flags. (line 85) 47635 * mem and /j: Flags. (line 70) 47636 * mem and /u: Flags. (line 134) 47637 * mem and /v: Flags. (line 76) 47638 * mem, RTL sharing: Sharing. (line 40) 47639 * MEM_ADDR_SPACE: Special Accessors. (line 49) 47640 * MEM_ALIAS_SET: Special Accessors. (line 9) 47641 * MEM_ALIGN: Special Accessors. (line 46) 47642 * MEM_EXPR: Special Accessors. (line 20) 47643 * MEM_KEEP_ALIAS_SET_P: Flags. (line 70) 47644 * MEM_NOTRAP_P: Flags. (line 81) 47645 * MEM_OFFSET: Special Accessors. (line 32) 47646 * MEM_OFFSET_KNOWN_P: Special Accessors. (line 28) 47647 * MEM_POINTER: Flags. (line 85) 47648 * MEM_READONLY_P: Flags. (line 134) 47649 * MEM_REF: Storage References. (line 6) 47650 * mem_signal_fenceMODE instruction pattern: Standard Names. (line 1844) 47651 * MEM_SIZE: Special Accessors. (line 40) 47652 * MEM_SIZE_KNOWN_P: Special Accessors. (line 36) 47653 * mem_thread_fenceMODE instruction pattern: Standard Names. (line 1836) 47654 * MEM_VOLATILE_P: Flags. (line 76) 47655 * memory model: Memory model. (line 6) 47656 * memory reference, nonoffsettable: Simple Constraints. (line 256) 47657 * memory references in constraints: Simple Constraints. (line 17) 47658 * memory_barrier instruction pattern: Standard Names. (line 1585) 47659 * MEMORY_MOVE_COST: Costs. (line 54) 47660 * memory_operand: Machine-Independent Predicates. 47661 (line 58) 47662 * METHOD_TYPE: Types. (line 6) 47663 * MIN_UNITS_PER_WORD: Storage Layout. (line 70) 47664 * MINIMUM_ALIGNMENT: Storage Layout. (line 300) 47665 * MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 183) 47666 * minM3 instruction pattern: Standard Names. (line 304) 47667 * minus: Arithmetic. (line 36) 47668 * minus and attributes: Expressions. (line 85) 47669 * minus, canonicalization of: Insn Canonicalizations. 47670 (line 27) 47671 * MINUS_EXPR: Unary and Binary Expressions. 47672 (line 6) 47673 * MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 47674 * mod: Arithmetic. (line 136) 47675 * mod and attributes: Expressions. (line 85) 47676 * mode classes: Machine Modes. (line 219) 47677 * mode iterators in .md files: Mode Iterators. (line 6) 47678 * mode switching: Mode Switching. (line 6) 47679 * MODE_ACCUM: Machine Modes. (line 249) 47680 * MODE_AFTER: Mode Switching. (line 49) 47681 * MODE_BASE_REG_CLASS: Register Classes. (line 119) 47682 * MODE_BASE_REG_REG_CLASS: Register Classes. (line 125) 47683 * MODE_CC <1>: MODE_CC Condition Codes. 47684 (line 6) 47685 * MODE_CC: Machine Modes. (line 268) 47686 * MODE_CODE_BASE_REG_CLASS: Register Classes. (line 133) 47687 * MODE_COMPLEX_FLOAT: Machine Modes. (line 260) 47688 * MODE_COMPLEX_INT: Machine Modes. (line 257) 47689 * MODE_DECIMAL_FLOAT: Machine Modes. (line 237) 47690 * MODE_ENTRY: Mode Switching. (line 55) 47691 * MODE_EXIT: Mode Switching. (line 61) 47692 * MODE_FLOAT: Machine Modes. (line 233) 47693 * MODE_FRACT: Machine Modes. (line 241) 47694 * MODE_FUNCTION: Machine Modes. (line 264) 47695 * MODE_INT: Machine Modes. (line 225) 47696 * MODE_NEEDED: Mode Switching. (line 42) 47697 * MODE_PARTIAL_INT: Machine Modes. (line 229) 47698 * MODE_PRIORITY_TO_MODE: Mode Switching. (line 67) 47699 * MODE_RANDOM: Machine Modes. (line 273) 47700 * MODE_UACCUM: Machine Modes. (line 253) 47701 * MODE_UFRACT: Machine Modes. (line 245) 47702 * MODES_TIEABLE_P: Values in Registers. 47703 (line 129) 47704 * modifiers in constraints: Modifiers. (line 6) 47705 * MODIFY_EXPR: Unary and Binary Expressions. 47706 (line 6) 47707 * MODIFY_JNI_METHOD_CALL: Misc. (line 763) 47708 * modM3 instruction pattern: Standard Names. (line 269) 47709 * modulo scheduling: RTL passes. (line 132) 47710 * MOVE_BY_PIECES_P: Costs. (line 165) 47711 * MOVE_MAX: Misc. (line 101) 47712 * MOVE_MAX_PIECES: Costs. (line 171) 47713 * MOVE_RATIO: Costs. (line 149) 47714 * movM instruction pattern: Standard Names. (line 11) 47715 * movmemM instruction pattern: Standard Names. (line 750) 47716 * movmisalignM instruction pattern: Standard Names. (line 126) 47717 * movMODEcc instruction pattern: Standard Names. (line 1037) 47718 * movstr instruction pattern: Standard Names. (line 785) 47719 * movstrictM instruction pattern: Standard Names. (line 120) 47720 * msubMN4 instruction pattern: Standard Names. (line 466) 47721 * mulhisi3 instruction pattern: Standard Names. (line 419) 47722 * mulM3 instruction pattern: Standard Names. (line 269) 47723 * mulqihi3 instruction pattern: Standard Names. (line 423) 47724 * mulsidi3 instruction pattern: Standard Names. (line 423) 47725 * mult: Arithmetic. (line 92) 47726 * mult and attributes: Expressions. (line 85) 47727 * mult, canonicalization of: Insn Canonicalizations. 47728 (line 27) 47729 * MULT_EXPR: Unary and Binary Expressions. 47730 (line 6) 47731 * MULT_HIGHPART_EXPR: Unary and Binary Expressions. 47732 (line 6) 47733 * MULTIARCH_DIRNAME: Target Fragment. (line 170) 47734 * MULTILIB_DEFAULTS: Driver. (line 253) 47735 * MULTILIB_DIRNAMES: Target Fragment. (line 44) 47736 * MULTILIB_EXCEPTIONS: Target Fragment. (line 70) 47737 * MULTILIB_EXTRA_OPTS: Target Fragment. (line 132) 47738 * MULTILIB_MATCHES: Target Fragment. (line 63) 47739 * MULTILIB_OPTIONS: Target Fragment. (line 24) 47740 * MULTILIB_OSDIRNAMES: Target Fragment. (line 139) 47741 * MULTILIB_REQUIRED: Target Fragment. (line 82) 47742 * MULTILIB_REUSE: Target Fragment. (line 103) 47743 * multiple alternative constraints: Multi-Alternative. (line 6) 47744 * MULTIPLE_SYMBOL_SPACES: Misc. (line 476) 47745 * multiplication: Arithmetic. (line 92) 47746 * multiplication with signed saturation: Arithmetic. (line 92) 47747 * multiplication with unsigned saturation: Arithmetic. (line 92) 47748 * n in constraint: Simple Constraints. (line 75) 47749 * N_REG_CLASSES: Register Classes. (line 83) 47750 * name: Identifiers. (line 6) 47751 * named address spaces: Named Address Spaces. 47752 (line 6) 47753 * named patterns and conditions: Patterns. (line 47) 47754 * names, pattern: Standard Names. (line 6) 47755 * namespace, scope: Namespaces. (line 6) 47756 * NAMESPACE_DECL <1>: Namespaces. (line 6) 47757 * NAMESPACE_DECL: Declarations. (line 6) 47758 * NATIVE_SYSTEM_HEADER_COMPONENT: Driver. (line 323) 47759 * ne: Comparisons. (line 56) 47760 * ne and attributes: Expressions. (line 85) 47761 * NE_EXPR: Unary and Binary Expressions. 47762 (line 6) 47763 * nearbyintM2 instruction pattern: Standard Names. (line 660) 47764 * neg: Arithmetic. (line 81) 47765 * neg and attributes: Expressions. (line 85) 47766 * neg, canonicalization of: Insn Canonicalizations. 47767 (line 27) 47768 * NEGATE_EXPR: Unary and Binary Expressions. 47769 (line 6) 47770 * negation: Arithmetic. (line 81) 47771 * negation with signed saturation: Arithmetic. (line 81) 47772 * negation with unsigned saturation: Arithmetic. (line 81) 47773 * negM2 instruction pattern: Standard Names. (line 532) 47774 * nested functions, trampolines for: Trampolines. (line 6) 47775 * nested_ptr: GTY Options. (line 186) 47776 * next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks. (line 25) 47777 * NEXT_INSN: Insns. (line 30) 47778 * NEXT_OBJC_RUNTIME: Library Calls. (line 88) 47779 * nil: RTL Objects. (line 73) 47780 * NM_FLAGS: Macros for Initialization. 47781 (line 111) 47782 * NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 26) 47783 * NO_DBX_FUNCTION_END: DBX Hooks. (line 20) 47784 * NO_DBX_GCC_MARKER: File Names and DBX. (line 28) 47785 * NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 23) 47786 * NO_DOLLAR_IN_LABEL: Label Output. (line 67) 47787 * NO_DOT_IN_LABEL: Label Output. (line 73) 47788 * NO_FUNCTION_CSE: Costs. (line 261) 47789 * NO_IMPLICIT_EXTERN_C: Misc. (line 374) 47790 * NO_PROFILE_COUNTERS: Profiling. (line 28) 47791 * NO_REGS: Register Classes. (line 17) 47792 * NON_LVALUE_EXPR: Unary and Binary Expressions. 47793 (line 6) 47794 * nondeterministic finite state automaton: Processor pipeline description. 47795 (line 305) 47796 * nonimmediate_operand: Machine-Independent Predicates. 47797 (line 101) 47798 * nonlocal goto handler: Edges. (line 172) 47799 * nonlocal_goto instruction pattern: Standard Names. (line 1417) 47800 * nonlocal_goto_receiver instruction pattern: Standard Names. 47801 (line 1434) 47802 * nonmemory_operand: Machine-Independent Predicates. 47803 (line 97) 47804 * nonoffsettable memory reference: Simple Constraints. (line 256) 47805 * nop instruction pattern: Standard Names. (line 1220) 47806 * NOP_EXPR: Unary and Binary Expressions. 47807 (line 6) 47808 * normal predicates: Predicates. (line 31) 47809 * not: Arithmetic. (line 154) 47810 * not and attributes: Expressions. (line 50) 47811 * not equal: Comparisons. (line 56) 47812 * not, canonicalization of: Insn Canonicalizations. 47813 (line 27) 47814 * note: Insns. (line 174) 47815 * note and /i: Flags. (line 59) 47816 * note and /v: Flags. (line 44) 47817 * NOTE_INSN_BASIC_BLOCK: Basic Blocks. (line 50) 47818 * NOTE_INSN_BLOCK_BEG: Insns. (line 199) 47819 * NOTE_INSN_BLOCK_END: Insns. (line 199) 47820 * NOTE_INSN_DELETED: Insns. (line 189) 47821 * NOTE_INSN_DELETED_LABEL: Insns. (line 194) 47822 * NOTE_INSN_EH_REGION_BEG: Insns. (line 205) 47823 * NOTE_INSN_EH_REGION_END: Insns. (line 205) 47824 * NOTE_INSN_FUNCTION_BEG: Insns. (line 229) 47825 * NOTE_INSN_LOOP_BEG: Insns. (line 213) 47826 * NOTE_INSN_LOOP_CONT: Insns. (line 219) 47827 * NOTE_INSN_LOOP_END: Insns. (line 213) 47828 * NOTE_INSN_LOOP_VTOP: Insns. (line 223) 47829 * NOTE_INSN_VAR_LOCATION: Insns. (line 233) 47830 * NOTE_LINE_NUMBER: Insns. (line 174) 47831 * NOTE_SOURCE_FILE: Insns. (line 174) 47832 * NOTE_VAR_LOCATION: Insns. (line 233) 47833 * NOTICE_UPDATE_CC: CC0 Condition Codes. 47834 (line 31) 47835 * NUM_MACHINE_MODES: Machine Modes. (line 286) 47836 * NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 47837 * Number of iterations analysis: Number of iterations. 47838 (line 6) 47839 * o in constraint: Simple Constraints. (line 23) 47840 * OBJC_GEN_METHOD_LABEL: Label Output. (line 452) 47841 * OBJC_JBLEN: Misc. (line 958) 47842 * OBJECT_FORMAT_COFF: Macros for Initialization. 47843 (line 97) 47844 * OFFSET_TYPE: Types. (line 6) 47845 * offsettable address: Simple Constraints. (line 23) 47846 * OImode: Machine Modes. (line 51) 47847 * Omega a solver for linear programming problems: Omega. (line 6) 47848 * OMP_ATOMIC: OpenMP. (line 6) 47849 * OMP_CLAUSE: OpenMP. (line 6) 47850 * OMP_CONTINUE: OpenMP. (line 6) 47851 * OMP_CRITICAL: OpenMP. (line 6) 47852 * OMP_FOR: OpenMP. (line 6) 47853 * OMP_MASTER: OpenMP. (line 6) 47854 * OMP_ORDERED: OpenMP. (line 6) 47855 * OMP_PARALLEL: OpenMP. (line 6) 47856 * OMP_RETURN: OpenMP. (line 6) 47857 * OMP_SECTION: OpenMP. (line 6) 47858 * OMP_SECTIONS: OpenMP. (line 6) 47859 * OMP_SINGLE: OpenMP. (line 6) 47860 * one_cmplM2 instruction pattern: Standard Names. (line 747) 47861 * operand access: Accessors. (line 6) 47862 * Operand Access Routines: SSA Operands. (line 119) 47863 * operand constraints: Constraints. (line 6) 47864 * Operand Iterators: SSA Operands. (line 119) 47865 * operand predicates: Predicates. (line 6) 47866 * operand substitution: Output Template. (line 6) 47867 * operands <1>: Patterns. (line 53) 47868 * operands: SSA Operands. (line 6) 47869 * Operands: Operands. (line 6) 47870 * operator predicates: Predicates. (line 6) 47871 * optc-gen.awk: Options. (line 6) 47872 * Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 47873 * OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9) 47874 * option specification files: Options. (line 6) 47875 * OPTION_DEFAULT_SPECS: Driver. (line 26) 47876 * optional hardware or system features: Run-time Target. (line 59) 47877 * options, directory search: Including Patterns. (line 44) 47878 * order of register allocation: Allocation Order. (line 6) 47879 * ordered_comparison_operator: Machine-Independent Predicates. 47880 (line 116) 47881 * ORDERED_EXPR: Unary and Binary Expressions. 47882 (line 6) 47883 * Ordering of Patterns: Pattern Ordering. (line 6) 47884 * ORIGINAL_REGNO: Special Accessors. (line 54) 47885 * other register constraints: Simple Constraints. (line 173) 47886 * outgoing_args_size: Stack Arguments. (line 48) 47887 * OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 74) 47888 * OUTGOING_REGNO: Register Basics. (line 95) 47889 * output of assembler code: File Framework. (line 6) 47890 * output statements: Output Statement. (line 6) 47891 * output templates: Output Template. (line 6) 47892 * output_asm_insn: Output Statement. (line 53) 47893 * OUTPUT_QUOTED_STRING: File Framework. (line 108) 47894 * OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 21) 47895 * OVERLOAD: Functions for C++. (line 6) 47896 * OVERRIDE_ABI_FORMAT: Register Arguments. (line 141) 47897 * OVL_CURRENT: Functions for C++. (line 6) 47898 * OVL_NEXT: Functions for C++. (line 6) 47899 * p in constraint: Simple Constraints. (line 164) 47900 * PAD_VARARGS_DOWN: Register Arguments. (line 222) 47901 * parallel: Side Effects. (line 210) 47902 * param_is: GTY Options. (line 114) 47903 * parameters, c++ abi: C++ ABI. (line 6) 47904 * parameters, miscellaneous: Misc. (line 6) 47905 * parameters, precompiled headers: PCH Target. (line 6) 47906 * paramN_is: GTY Options. (line 132) 47907 * parity: Arithmetic. (line 243) 47908 * parityM2 instruction pattern: Standard Names. (line 741) 47909 * PARM_BOUNDARY: Storage Layout. (line 140) 47910 * PARM_DECL: Declarations. (line 6) 47911 * PARSE_LDD_OUTPUT: Macros for Initialization. 47912 (line 127) 47913 * pass_duplicate_computed_gotos: Edges. (line 162) 47914 * passes and files of the compiler: Passes. (line 6) 47915 * passing arguments: Interface. (line 36) 47916 * PATH_SEPARATOR: Filesystem. (line 31) 47917 * PATTERN: Insns. (line 294) 47918 * pattern conditions: Patterns. (line 43) 47919 * pattern names: Standard Names. (line 6) 47920 * Pattern Ordering: Pattern Ordering. (line 6) 47921 * patterns: Patterns. (line 6) 47922 * pc: Regs and Memory. (line 361) 47923 * pc and attributes: Insn Lengths. (line 20) 47924 * pc, RTL sharing: Sharing. (line 25) 47925 * PC_REGNUM: Register Basics. (line 109) 47926 * pc_rtx: Regs and Memory. (line 366) 47927 * PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 326) 47928 * PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 65) 47929 * PDImode: Machine Modes. (line 40) 47930 * peephole optimization, RTL representation: Side Effects. (line 244) 47931 * peephole optimizer definitions: Peephole Definitions. 47932 (line 6) 47933 * per-function data: Per-Function Data. (line 6) 47934 * percent sign: Output Template. (line 6) 47935 * PHI nodes: SSA. (line 31) 47936 * PHI_ARG_DEF: SSA. (line 71) 47937 * PHI_ARG_EDGE: SSA. (line 68) 47938 * PHI_ARG_ELT: SSA. (line 63) 47939 * PHI_NUM_ARGS: SSA. (line 59) 47940 * PHI_RESULT: SSA. (line 56) 47941 * PIC: PIC. (line 6) 47942 * PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26) 47943 * PIC_OFFSET_TABLE_REGNUM: PIC. (line 16) 47944 * pipeline hazard recognizer: Processor pipeline description. 47945 (line 6) 47946 * Plugins: Plugins. (line 6) 47947 * plus: Arithmetic. (line 14) 47948 * plus and attributes: Expressions. (line 85) 47949 * plus, canonicalization of: Insn Canonicalizations. 47950 (line 27) 47951 * PLUS_EXPR: Unary and Binary Expressions. 47952 (line 6) 47953 * Pmode: Misc. (line 330) 47954 * pmode_register_operand: Machine-Independent Predicates. 47955 (line 35) 47956 * pointer: Types. (line 6) 47957 * POINTER_PLUS_EXPR: Unary and Binary Expressions. 47958 (line 6) 47959 * POINTER_SIZE: Storage Layout. (line 76) 47960 * POINTER_TYPE: Types. (line 6) 47961 * POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 82) 47962 * pop_operand: Machine-Independent Predicates. 47963 (line 88) 47964 * popcount: Arithmetic. (line 239) 47965 * popcountM2 instruction pattern: Standard Names. (line 735) 47966 * pops_args: Function Entry. (line 106) 47967 * portability: Portability. (line 6) 47968 * position independent code: PIC. (line 6) 47969 * post_dec: Incdec. (line 25) 47970 * post_inc: Incdec. (line 30) 47971 * post_modify: Incdec. (line 33) 47972 * post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks. 47973 (line 34) 47974 * POSTDECREMENT_EXPR: Unary and Binary Expressions. 47975 (line 6) 47976 * POSTINCREMENT_EXPR: Unary and Binary Expressions. 47977 (line 6) 47978 * POWI_MAX_MULTS: Misc. (line 826) 47979 * powM3 instruction pattern: Standard Names. (line 609) 47980 * pragma: Misc. (line 379) 47981 * pre_dec: Incdec. (line 8) 47982 * PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 127) 47983 * pre_inc: Incdec. (line 22) 47984 * pre_modify: Incdec. (line 51) 47985 * PREDECREMENT_EXPR: Unary and Binary Expressions. 47986 (line 6) 47987 * predefined macros: Run-time Target. (line 6) 47988 * predicates: Predicates. (line 6) 47989 * predicates and machine modes: Predicates. (line 31) 47990 * predication <1>: Cond Exec Macros. (line 6) 47991 * predication: Conditional Execution. 47992 (line 6) 47993 * predict.def: Profile information. 47994 (line 24) 47995 * PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 42) 47996 * PREFERRED_RELOAD_CLASS: Register Classes. (line 253) 47997 * PREFERRED_STACK_BOUNDARY: Storage Layout. (line 154) 47998 * prefetch: Side Effects. (line 318) 47999 * prefetch and /v: Flags. (line 214) 48000 * prefetch instruction pattern: Standard Names. (line 1562) 48001 * PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 214) 48002 * PREINCREMENT_EXPR: Unary and Binary Expressions. 48003 (line 6) 48004 * presence_set: Processor pipeline description. 48005 (line 224) 48006 * preserving SSA form: SSA. (line 76) 48007 * preserving virtual SSA form: SSA. (line 184) 48008 * pretend_args_size: Function Entry. (line 112) 48009 * prev_active_insn: define_peephole. (line 60) 48010 * PREV_INSN: Insns. (line 26) 48011 * PRINT_OPERAND: Instruction Output. (line 96) 48012 * PRINT_OPERAND_ADDRESS: Instruction Output. (line 124) 48013 * PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 117) 48014 * probe_stack instruction pattern: Standard Names. (line 1409) 48015 * probe_stack_address instruction pattern: Standard Names. (line 1402) 48016 * processor functional units: Processor pipeline description. 48017 (line 6) 48018 * processor pipeline description: Processor pipeline description. 48019 (line 6) 48020 * product: Arithmetic. (line 92) 48021 * profile feedback: Profile information. 48022 (line 14) 48023 * profile representation: Profile information. 48024 (line 6) 48025 * PROFILE_BEFORE_PROLOGUE: Profiling. (line 35) 48026 * PROFILE_HOOK: Profiling. (line 23) 48027 * profiling, code generation: Profiling. (line 6) 48028 * program counter: Regs and Memory. (line 362) 48029 * prologue: Function Entry. (line 6) 48030 * prologue instruction pattern: Standard Names. (line 1500) 48031 * PROMOTE_MODE: Storage Layout. (line 93) 48032 * pseudo registers: Regs and Memory. (line 9) 48033 * PSImode: Machine Modes. (line 32) 48034 * PTRDIFF_TYPE: Type Layout. (line 201) 48035 * purge_dead_edges <1>: Maintaining the CFG. 48036 (line 82) 48037 * purge_dead_edges: Edges. (line 104) 48038 * push address instruction: Simple Constraints. (line 164) 48039 * PUSH_ARGS: Stack Arguments. (line 18) 48040 * PUSH_ARGS_REVERSED: Stack Arguments. (line 26) 48041 * push_operand: Machine-Independent Predicates. 48042 (line 81) 48043 * push_reload: Addressing Modes. (line 177) 48044 * PUSH_ROUNDING: Stack Arguments. (line 32) 48045 * pushM1 instruction pattern: Standard Names. (line 256) 48046 * PUT_CODE: RTL Objects. (line 47) 48047 * PUT_MODE: Machine Modes. (line 283) 48048 * PUT_REG_NOTE_KIND: Insns. (line 357) 48049 * PUT_SDB_: SDB and DWARF. (line 106) 48050 * QCmode: Machine Modes. (line 197) 48051 * QFmode: Machine Modes. (line 54) 48052 * QImode: Machine Modes. (line 25) 48053 * QImode, in insn: Insns. (line 278) 48054 * QQmode: Machine Modes. (line 103) 48055 * qualified type <1>: Types for C++. (line 6) 48056 * qualified type: Types. (line 6) 48057 * querying function unit reservations: Processor pipeline description. 48058 (line 90) 48059 * question mark: Multi-Alternative. (line 41) 48060 * quotient: Arithmetic. (line 116) 48061 * r in constraint: Simple Constraints. (line 66) 48062 * RDIV_EXPR: Unary and Binary Expressions. 48063 (line 6) 48064 * READONLY_DATA_SECTION_ASM_OP: Sections. (line 63) 48065 * real operands: SSA Operands. (line 6) 48066 * REAL_ARITHMETIC: Floating Point. (line 66) 48067 * REAL_CST: Constant expressions. 48068 (line 6) 48069 * REAL_LIBGCC_SPEC: Driver. (line 125) 48070 * REAL_NM_FILE_NAME: Macros for Initialization. 48071 (line 106) 48072 * REAL_TYPE: Types. (line 6) 48073 * REAL_VALUE_ABS: Floating Point. (line 82) 48074 * REAL_VALUE_ATOF: Floating Point. (line 50) 48075 * REAL_VALUE_FIX: Floating Point. (line 41) 48076 * REAL_VALUE_FROM_INT: Floating Point. (line 92) 48077 * REAL_VALUE_ISINF: Floating Point. (line 59) 48078 * REAL_VALUE_ISNAN: Floating Point. (line 62) 48079 * REAL_VALUE_NEGATE: Floating Point. (line 79) 48080 * REAL_VALUE_NEGATIVE: Floating Point. (line 56) 48081 * REAL_VALUE_TO_INT: Floating Point. (line 86) 48082 * REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 145) 48083 * REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 143) 48084 * REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 144) 48085 * REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 141) 48086 * REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 142) 48087 * REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 140) 48088 * REAL_VALUE_TYPE: Floating Point. (line 26) 48089 * REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 45) 48090 * REAL_VALUES_EQUAL: Floating Point. (line 32) 48091 * REAL_VALUES_LESS: Floating Point. (line 38) 48092 * REALPART_EXPR: Unary and Binary Expressions. 48093 (line 6) 48094 * recog_data.operand: Instruction Output. (line 54) 48095 * recognizing insns: RTL Template. (line 6) 48096 * RECORD_TYPE <1>: Classes. (line 6) 48097 * RECORD_TYPE: Types. (line 6) 48098 * redirect_edge_and_branch: Profile information. 48099 (line 71) 48100 * redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 48101 (line 92) 48102 * reduc_smax_M instruction pattern: Standard Names. (line 310) 48103 * reduc_smin_M instruction pattern: Standard Names. (line 310) 48104 * reduc_splus_M instruction pattern: Standard Names. (line 322) 48105 * reduc_umax_M instruction pattern: Standard Names. (line 316) 48106 * reduc_umin_M instruction pattern: Standard Names. (line 316) 48107 * reduc_uplus_M instruction pattern: Standard Names. (line 328) 48108 * reference: Types. (line 6) 48109 * REFERENCE_TYPE: Types. (line 6) 48110 * reg: Regs and Memory. (line 9) 48111 * reg and /f: Flags. (line 94) 48112 * reg and /i: Flags. (line 89) 48113 * reg and /v: Flags. (line 98) 48114 * reg, RTL sharing: Sharing. (line 17) 48115 * REG_ALLOC_ORDER: Allocation Order. (line 9) 48116 * REG_BR_PRED: Insns. (line 538) 48117 * REG_BR_PROB: Insns. (line 532) 48118 * REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 48119 (line 82) 48120 * REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 48121 (line 52) 48122 * REG_CC_SETTER: Insns. (line 503) 48123 * REG_CC_USER: Insns. (line 503) 48124 * REG_CLASS_CONTENTS: Register Classes. (line 93) 48125 * reg_class_contents: Register Basics. (line 59) 48126 * REG_CLASS_FROM_CONSTRAINT: Old Constraints. (line 35) 48127 * REG_CLASS_FROM_LETTER: Old Constraints. (line 27) 48128 * REG_CLASS_NAMES: Register Classes. (line 88) 48129 * REG_CROSSING_JUMP: Insns. (line 416) 48130 * REG_DEAD: Insns. (line 368) 48131 * REG_DEAD, REG_UNUSED: Liveness information. 48132 (line 32) 48133 * REG_DEP_ANTI: Insns. (line 525) 48134 * REG_DEP_OUTPUT: Insns. (line 521) 48135 * REG_DEP_TRUE: Insns. (line 518) 48136 * REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 110) 48137 * REG_EQUAL: Insns. (line 431) 48138 * REG_EQUIV: Insns. (line 431) 48139 * REG_EXPR: Special Accessors. (line 60) 48140 * REG_FRAME_RELATED_EXPR: Insns. (line 544) 48141 * REG_FUNCTION_VALUE_P: Flags. (line 89) 48142 * REG_INC: Insns. (line 384) 48143 * reg_label and /v: Flags. (line 65) 48144 * REG_LABEL_OPERAND: Insns. (line 398) 48145 * REG_LABEL_TARGET: Insns. (line 407) 48146 * reg_names <1>: Instruction Output. (line 108) 48147 * reg_names: Register Basics. (line 59) 48148 * REG_NONNEG: Insns. (line 390) 48149 * REG_NOTE_KIND: Insns. (line 357) 48150 * REG_NOTES: Insns. (line 331) 48151 * REG_OFFSET: Special Accessors. (line 64) 48152 * REG_OK_STRICT: Addressing Modes. (line 100) 48153 * REG_PARM_STACK_SPACE: Stack Arguments. (line 59) 48154 * REG_PARM_STACK_SPACE, and TARGET_FUNCTION_ARG: Register Arguments. 48155 (line 51) 48156 * REG_POINTER: Flags. (line 94) 48157 * REG_SETJMP: Insns. (line 425) 48158 * REG_UNUSED: Insns. (line 377) 48159 * REG_USERVAR_P: Flags. (line 98) 48160 * REG_VALUE_IN_UNWIND_CONTEXT: Frame Registers. (line 157) 48161 * REG_WORDS_BIG_ENDIAN: Storage Layout. (line 36) 48162 * regclass_for_constraint: C Constraint Interface. 48163 (line 60) 48164 * register allocation order: Allocation Order. (line 6) 48165 * register class definitions: Register Classes. (line 6) 48166 * register class preference constraints: Class Preferences. (line 6) 48167 * register pairs: Values in Registers. 48168 (line 69) 48169 * Register Transfer Language (RTL): RTL. (line 6) 48170 * register usage: Registers. (line 6) 48171 * REGISTER_MOVE_COST: Costs. (line 10) 48172 * REGISTER_NAMES: Instruction Output. (line 9) 48173 * register_operand: Machine-Independent Predicates. 48174 (line 30) 48175 * REGISTER_PREFIX: Instruction Output. (line 152) 48176 * REGISTER_TARGET_PRAGMAS: Misc. (line 380) 48177 * registers arguments: Register Arguments. (line 6) 48178 * registers in constraints: Simple Constraints. (line 66) 48179 * REGMODE_NATURAL_SIZE: Values in Registers. 48180 (line 50) 48181 * REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 176) 48182 * REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 153) 48183 * REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 163) 48184 * REGNO_OK_FOR_BASE_P: Register Classes. (line 149) 48185 * REGNO_OK_FOR_INDEX_P: Register Classes. (line 190) 48186 * REGNO_REG_CLASS: Register Classes. (line 108) 48187 * regs_ever_live: Function Entry. (line 21) 48188 * regular expressions: Processor pipeline description. 48189 (line 6) 48190 * relative costs: Costs. (line 6) 48191 * RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 263) 48192 * reload_completed: Standard Names. (line 1187) 48193 * reload_in instruction pattern: Standard Names. (line 99) 48194 * reload_in_progress: Standard Names. (line 57) 48195 * reload_out instruction pattern: Standard Names. (line 99) 48196 * reloading: RTL passes. (line 183) 48197 * remainder: Arithmetic. (line 136) 48198 * remainderM3 instruction pattern: Standard Names. (line 555) 48199 * reorder: GTY Options. (line 210) 48200 * representation of RTL: RTL. (line 6) 48201 * reservation delays: Processor pipeline description. 48202 (line 6) 48203 * rest_of_decl_compilation: Parsing pass. (line 52) 48204 * rest_of_type_compilation: Parsing pass. (line 52) 48205 * restore_stack_block instruction pattern: Standard Names. (line 1322) 48206 * restore_stack_function instruction pattern: Standard Names. 48207 (line 1322) 48208 * restore_stack_nonlocal instruction pattern: Standard Names. 48209 (line 1322) 48210 * RESULT_DECL: Declarations. (line 6) 48211 * return: Side Effects. (line 72) 48212 * return instruction pattern: Standard Names. (line 1160) 48213 * return values in registers: Scalar Return. (line 6) 48214 * RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 135) 48215 * RETURN_ADDR_OFFSET: Exception Handling. (line 60) 48216 * RETURN_ADDR_RTX: Frame Layout. (line 124) 48217 * RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 65) 48218 * RETURN_EXPR: Statements for C++. (line 6) 48219 * RETURN_STMT: Statements for C++. (line 6) 48220 * return_val: Flags. (line 274) 48221 * return_val, in call_insn: Flags. (line 24) 48222 * return_val, in reg: Flags. (line 89) 48223 * return_val, in symbol_ref: Flags. (line 202) 48224 * returning aggregate values: Aggregate Return. (line 6) 48225 * returning structures and unions: Interface. (line 10) 48226 * reverse probability: Profile information. 48227 (line 66) 48228 * REVERSE_CONDITION: MODE_CC Condition Codes. 48229 (line 92) 48230 * REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 48231 (line 78) 48232 * right rotate: Arithmetic. (line 195) 48233 * right shift: Arithmetic. (line 190) 48234 * rintM2 instruction pattern: Standard Names. (line 668) 48235 * RISC: Processor pipeline description. 48236 (line 6) 48237 * roots, marking: GGC Roots. (line 6) 48238 * rotate: Arithmetic. (line 195) 48239 * rotatert: Arithmetic. (line 195) 48240 * rotlM3 instruction pattern: Standard Names. (line 520) 48241 * rotrM3 instruction pattern: Standard Names. (line 520) 48242 * ROUND_DIV_EXPR: Unary and Binary Expressions. 48243 (line 6) 48244 * ROUND_MOD_EXPR: Unary and Binary Expressions. 48245 (line 6) 48246 * ROUND_TOWARDS_ZERO: Storage Layout. (line 477) 48247 * ROUND_TYPE_ALIGN: Storage Layout. (line 424) 48248 * roundM2 instruction pattern: Standard Names. (line 644) 48249 * RSHIFT_EXPR: Unary and Binary Expressions. 48250 (line 6) 48251 * RTL addition: Arithmetic. (line 14) 48252 * RTL addition with signed saturation: Arithmetic. (line 14) 48253 * RTL addition with unsigned saturation: Arithmetic. (line 14) 48254 * RTL classes: RTL Classes. (line 6) 48255 * RTL comparison: Arithmetic. (line 43) 48256 * RTL comparison operations: Comparisons. (line 6) 48257 * RTL constant expression types: Constants. (line 6) 48258 * RTL constants: Constants. (line 6) 48259 * RTL declarations: RTL Declarations. (line 6) 48260 * RTL difference: Arithmetic. (line 36) 48261 * RTL expression: RTL Objects. (line 6) 48262 * RTL expressions for arithmetic: Arithmetic. (line 6) 48263 * RTL format: RTL Classes. (line 72) 48264 * RTL format characters: RTL Classes. (line 77) 48265 * RTL function-call insns: Calls. (line 6) 48266 * RTL insn template: RTL Template. (line 6) 48267 * RTL integers: RTL Objects. (line 6) 48268 * RTL memory expressions: Regs and Memory. (line 6) 48269 * RTL object types: RTL Objects. (line 6) 48270 * RTL postdecrement: Incdec. (line 6) 48271 * RTL postincrement: Incdec. (line 6) 48272 * RTL predecrement: Incdec. (line 6) 48273 * RTL preincrement: Incdec. (line 6) 48274 * RTL register expressions: Regs and Memory. (line 6) 48275 * RTL representation: RTL. (line 6) 48276 * RTL side effect expressions: Side Effects. (line 6) 48277 * RTL strings: RTL Objects. (line 6) 48278 * RTL structure sharing assumptions: Sharing. (line 6) 48279 * RTL subtraction: Arithmetic. (line 36) 48280 * RTL subtraction with signed saturation: Arithmetic. (line 36) 48281 * RTL subtraction with unsigned saturation: Arithmetic. (line 36) 48282 * RTL sum: Arithmetic. (line 14) 48283 * RTL vectors: RTL Objects. (line 6) 48284 * RTL_CONST_CALL_P: Flags. (line 19) 48285 * RTL_CONST_OR_PURE_CALL_P: Flags. (line 29) 48286 * RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 33) 48287 * RTL_PURE_CALL_P: Flags. (line 24) 48288 * RTX (See RTL): RTL Objects. (line 6) 48289 * RTX codes, classes of: RTL Classes. (line 6) 48290 * RTX_FRAME_RELATED_P: Flags. (line 107) 48291 * run-time conventions: Interface. (line 6) 48292 * run-time target specification: Run-time Target. (line 6) 48293 * s in constraint: Simple Constraints. (line 102) 48294 * same_type_p: Types. (line 88) 48295 * SAmode: Machine Modes. (line 148) 48296 * sat_fract: Conversions. (line 90) 48297 * satfractMN2 instruction pattern: Standard Names. (line 925) 48298 * satfractunsMN2 instruction pattern: Standard Names. (line 938) 48299 * satisfies_constraint_: C Constraint Interface. 48300 (line 47) 48301 * SAVE_EXPR: Unary and Binary Expressions. 48302 (line 6) 48303 * save_stack_block instruction pattern: Standard Names. (line 1322) 48304 * save_stack_function instruction pattern: Standard Names. (line 1322) 48305 * save_stack_nonlocal instruction pattern: Standard Names. (line 1322) 48306 * SBSS_SECTION_ASM_OP: Sections. (line 76) 48307 * Scalar evolutions: Scalar evolutions. (line 6) 48308 * scalars, returned as values: Scalar Return. (line 6) 48309 * SCHED_GROUP_P: Flags. (line 148) 48310 * SCmode: Machine Modes. (line 197) 48311 * scratch: Regs and Memory. (line 298) 48312 * scratch operands: Regs and Memory. (line 298) 48313 * scratch, RTL sharing: Sharing. (line 35) 48314 * scratch_operand: Machine-Independent Predicates. 48315 (line 50) 48316 * SDATA_SECTION_ASM_OP: Sections. (line 58) 48317 * SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 124) 48318 * SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 119) 48319 * SDB_DEBUGGING_INFO: SDB and DWARF. (line 9) 48320 * SDB_DELIM: SDB and DWARF. (line 112) 48321 * SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 129) 48322 * SDmode: Machine Modes. (line 85) 48323 * sdot_prodM instruction pattern: Standard Names. (line 334) 48324 * search options: Including Patterns. (line 44) 48325 * SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 396) 48326 * SECONDARY_MEMORY_NEEDED: Register Classes. (line 452) 48327 * SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 471) 48328 * SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 462) 48329 * SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 397) 48330 * SECONDARY_RELOAD_CLASS: Register Classes. (line 395) 48331 * SELECT_CC_MODE: MODE_CC Condition Codes. 48332 (line 7) 48333 * sequence: Side Effects. (line 260) 48334 * Sequence iterators: Sequence iterators. (line 6) 48335 * set: Side Effects. (line 15) 48336 * set and /f: Flags. (line 107) 48337 * SET_ASM_OP: Label Output. (line 419) 48338 * set_attr: Tagging Insns. (line 31) 48339 * set_attr_alternative: Tagging Insns. (line 49) 48340 * set_bb_seq: GIMPLE sequences. (line 76) 48341 * SET_BY_PIECES_P: Costs. (line 206) 48342 * SET_DEST: Side Effects. (line 69) 48343 * SET_IS_RETURN_P: Flags. (line 157) 48344 * SET_LABEL_KIND: Insns. (line 146) 48345 * set_optab_libfunc: Library Calls. (line 15) 48346 * SET_RATIO: Costs. (line 194) 48347 * SET_SRC: Side Effects. (line 69) 48348 * set_thread_pointerMODE instruction pattern: Standard Names. 48349 (line 1856) 48350 * SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6) 48351 * setmemM instruction pattern: Standard Names. (line 793) 48352 * SETUP_FRAME_ADDRESSES: Frame Layout. (line 102) 48353 * SF_SIZE: Type Layout. (line 136) 48354 * SFmode: Machine Modes. (line 66) 48355 * sharing of RTL components: Sharing. (line 6) 48356 * shift: Arithmetic. (line 173) 48357 * SHIFT_COUNT_TRUNCATED: Misc. (line 113) 48358 * SHLIB_SUFFIX: Macros for Initialization. 48359 (line 135) 48360 * SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 83) 48361 * SHORT_FRACT_TYPE_SIZE: Type Layout. (line 63) 48362 * SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 87) 48363 * SHORT_TYPE_SIZE: Type Layout. (line 16) 48364 * sibcall_epilogue instruction pattern: Standard Names. (line 1532) 48365 * sibling call: Edges. (line 122) 48366 * SIBLING_CALL_P: Flags. (line 161) 48367 * SIG_ATOMIC_TYPE: Type Layout. (line 252) 48368 * sign_extend: Conversions. (line 23) 48369 * sign_extract: Bit-Fields. (line 8) 48370 * sign_extract, canonicalization of: Insn Canonicalizations. 48371 (line 88) 48372 * signed division: Arithmetic. (line 116) 48373 * signed division with signed saturation: Arithmetic. (line 116) 48374 * signed maximum: Arithmetic. (line 141) 48375 * signed minimum: Arithmetic. (line 141) 48376 * SImode: Machine Modes. (line 37) 48377 * simple constraints: Simple Constraints. (line 6) 48378 * simple_return: Side Effects. (line 86) 48379 * simple_return instruction pattern: Standard Names. (line 1176) 48380 * sincos math function, implicit usage: Library Calls. (line 78) 48381 * sincosM3 instruction pattern: Standard Names. (line 580) 48382 * sinM2 instruction pattern: Standard Names. (line 572) 48383 * SIZE_ASM_OP: Label Output. (line 35) 48384 * SIZE_TYPE: Type Layout. (line 175) 48385 * SIZETYPE: Type Layout. (line 191) 48386 * skip: GTY Options. (line 77) 48387 * SLOW_BYTE_ACCESS: Costs. (line 118) 48388 * SLOW_UNALIGNED_ACCESS: Costs. (line 133) 48389 * smax: Arithmetic. (line 141) 48390 * smin: Arithmetic. (line 141) 48391 * sms, swing, software pipelining: RTL passes. (line 132) 48392 * smulM3_highpart instruction pattern: Standard Names. (line 435) 48393 * soft float library: Soft float library routines. 48394 (line 6) 48395 * special: GTY Options. (line 295) 48396 * special predicates: Predicates. (line 31) 48397 * SPECS: Target Fragment. (line 191) 48398 * speed of instructions: Costs. (line 6) 48399 * split_block: Maintaining the CFG. 48400 (line 99) 48401 * splitting instructions: Insn Splitting. (line 6) 48402 * SQmode: Machine Modes. (line 111) 48403 * sqrt: Arithmetic. (line 207) 48404 * sqrtM2 instruction pattern: Standard Names. (line 538) 48405 * square root: Arithmetic. (line 207) 48406 * ss_abs: Arithmetic. (line 200) 48407 * ss_ashift: Arithmetic. (line 173) 48408 * ss_div: Arithmetic. (line 116) 48409 * ss_minus: Arithmetic. (line 36) 48410 * ss_mult: Arithmetic. (line 92) 48411 * ss_neg: Arithmetic. (line 81) 48412 * ss_plus: Arithmetic. (line 14) 48413 * ss_truncate: Conversions. (line 43) 48414 * SSA: SSA. (line 6) 48415 * SSA_NAME_DEF_STMT: SSA. (line 219) 48416 * SSA_NAME_VERSION: SSA. (line 224) 48417 * ssaddM3 instruction pattern: Standard Names. (line 269) 48418 * ssashlM3 instruction pattern: Standard Names. (line 510) 48419 * ssdivM3 instruction pattern: Standard Names. (line 269) 48420 * ssmaddMN4 instruction pattern: Standard Names. (line 458) 48421 * ssmsubMN4 instruction pattern: Standard Names. (line 482) 48422 * ssmulM3 instruction pattern: Standard Names. (line 269) 48423 * ssnegM2 instruction pattern: Standard Names. (line 532) 48424 * sssubM3 instruction pattern: Standard Names. (line 269) 48425 * ssum_widenM3 instruction pattern: Standard Names. (line 344) 48426 * stack arguments: Stack Arguments. (line 6) 48427 * stack frame layout: Frame Layout. (line 6) 48428 * stack smashing protection: Stack Smashing Protection. 48429 (line 6) 48430 * STACK_ALIGNMENT_NEEDED: Frame Layout. (line 48) 48431 * STACK_BOUNDARY: Storage Layout. (line 146) 48432 * STACK_CHECK_BUILTIN: Stack Checking. (line 32) 48433 * STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83) 48434 * STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74) 48435 * STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90) 48436 * STACK_CHECK_MOVING_SP: Stack Checking. (line 54) 48437 * STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 46) 48438 * STACK_CHECK_PROTECT: Stack Checking. (line 63) 48439 * STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 39) 48440 * STACK_DYNAMIC_OFFSET: Frame Layout. (line 75) 48441 * STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 48442 (line 83) 48443 * STACK_GROWS_DOWNWARD: Frame Layout. (line 9) 48444 * STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 84) 48445 * STACK_POINTER_OFFSET: Frame Layout. (line 58) 48446 * STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 48447 (line 93) 48448 * STACK_POINTER_REGNUM: Frame Registers. (line 9) 48449 * STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 48450 (line 83) 48451 * stack_pointer_rtx: Frame Registers. (line 104) 48452 * stack_protect_set instruction pattern: Standard Names. (line 1866) 48453 * stack_protect_test instruction pattern: Standard Names. (line 1876) 48454 * STACK_PUSH_CODE: Frame Layout. (line 17) 48455 * STACK_REG_COVER_CLASS: Stack Registers. (line 23) 48456 * STACK_REGS: Stack Registers. (line 20) 48457 * STACK_SAVEAREA_MODE: Storage Layout. (line 440) 48458 * STACK_SIZE_MODE: Storage Layout. (line 452) 48459 * STACK_SLOT_ALIGNMENT: Storage Layout. (line 271) 48460 * standard pattern names: Standard Names. (line 6) 48461 * STANDARD_STARTFILE_PREFIX: Driver. (line 275) 48462 * STANDARD_STARTFILE_PREFIX_1: Driver. (line 282) 48463 * STANDARD_STARTFILE_PREFIX_2: Driver. (line 289) 48464 * STARTFILE_SPEC: Driver. (line 148) 48465 * STARTING_FRAME_OFFSET: Frame Layout. (line 39) 48466 * STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 48467 (line 74) 48468 * Statement and operand traversals: Statement and operand traversals. 48469 (line 6) 48470 * Statement Sequences: Statement Sequences. 48471 (line 6) 48472 * statements <1>: Statements for C++. (line 6) 48473 * statements: Function Properties. 48474 (line 6) 48475 * Statements: Statements. (line 6) 48476 * Static profile estimation: Profile information. 48477 (line 24) 48478 * static single assignment: SSA. (line 6) 48479 * STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 78) 48480 * STATIC_CHAIN_REGNUM: Frame Registers. (line 77) 48481 * stdarg.h and register arguments: Register Arguments. (line 45) 48482 * STDC_0_IN_SYSTEM_HEADERS: Misc. (line 351) 48483 * STMT_EXPR: Unary and Binary Expressions. 48484 (line 6) 48485 * STMT_IS_FULL_EXPR_P: Statements for C++. (line 22) 48486 * storage layout: Storage Layout. (line 6) 48487 * STORE_BY_PIECES_P: Costs. (line 213) 48488 * STORE_FLAG_VALUE: Misc. (line 202) 48489 * store_multiple instruction pattern: Standard Names. (line 160) 48490 * strcpy: Storage Layout. (line 231) 48491 * STRICT_ALIGNMENT: Storage Layout. (line 321) 48492 * strict_low_part: RTL Declarations. (line 9) 48493 * strict_memory_address_p: Addressing Modes. (line 187) 48494 * STRING_CST: Constant expressions. 48495 (line 6) 48496 * STRING_POOL_ADDRESS_P: Flags. (line 165) 48497 * strlenM instruction pattern: Standard Names. (line 860) 48498 * structure value address: Aggregate Return. (line 6) 48499 * STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 313) 48500 * structures, returning: Interface. (line 10) 48501 * subM3 instruction pattern: Standard Names. (line 269) 48502 * SUBOBJECT: Statements for C++. (line 6) 48503 * SUBOBJECT_CLEANUP: Statements for C++. (line 6) 48504 * subreg: Regs and Memory. (line 97) 48505 * subreg and /s: Flags. (line 187) 48506 * subreg and /u: Flags. (line 180) 48507 * subreg and /u and /v: Flags. (line 170) 48508 * subreg, in strict_low_part: RTL Declarations. (line 9) 48509 * SUBREG_BYTE: Regs and Memory. (line 289) 48510 * SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 170) 48511 * SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 180) 48512 * SUBREG_PROMOTED_VAR_P: Flags. (line 187) 48513 * SUBREG_REG: Regs and Memory. (line 289) 48514 * subst iterators in .md files: Subst Iterators. (line 6) 48515 * SUCCESS_EXIT_CODE: Host Misc. (line 12) 48516 * SUPPORTS_INIT_PRIORITY: Macros for Initialization. 48517 (line 58) 48518 * SUPPORTS_ONE_ONLY: Label Output. (line 259) 48519 * SUPPORTS_WEAK: Label Output. (line 233) 48520 * SWITCH_BODY: Statements for C++. (line 6) 48521 * SWITCH_COND: Statements for C++. (line 6) 48522 * SWITCH_STMT: Statements for C++. (line 6) 48523 * SWITCHABLE_TARGET: Run-time Target. (line 165) 48524 * SYMBOL_FLAG_ANCHOR: Special Accessors. (line 120) 48525 * SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 102) 48526 * SYMBOL_FLAG_FUNCTION: Special Accessors. (line 95) 48527 * SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 116) 48528 * SYMBOL_FLAG_LOCAL: Special Accessors. (line 98) 48529 * SYMBOL_FLAG_SMALL: Special Accessors. (line 107) 48530 * SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 111) 48531 * symbol_ref: Constants. (line 87) 48532 * symbol_ref and /f: Flags. (line 165) 48533 * symbol_ref and /i: Flags. (line 202) 48534 * symbol_ref and /u: Flags. (line 10) 48535 * symbol_ref and /v: Flags. (line 206) 48536 * symbol_ref, RTL sharing: Sharing. (line 20) 48537 * SYMBOL_REF_ANCHOR_P: Special Accessors. (line 120) 48538 * SYMBOL_REF_BLOCK: Special Accessors. (line 133) 48539 * SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 138) 48540 * SYMBOL_REF_CONSTANT: Special Accessors. (line 81) 48541 * SYMBOL_REF_DATA: Special Accessors. (line 85) 48542 * SYMBOL_REF_DECL: Special Accessors. (line 69) 48543 * SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 102) 48544 * SYMBOL_REF_FLAG: Flags. (line 206) 48545 * SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 277) 48546 * SYMBOL_REF_FLAGS: Special Accessors. (line 89) 48547 * SYMBOL_REF_FUNCTION_P: Special Accessors. (line 95) 48548 * SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 116) 48549 * SYMBOL_REF_LOCAL_P: Special Accessors. (line 98) 48550 * SYMBOL_REF_SMALL_P: Special Accessors. (line 107) 48551 * SYMBOL_REF_TLS_MODEL: Special Accessors. (line 111) 48552 * SYMBOL_REF_USED: Flags. (line 197) 48553 * SYMBOL_REF_WEAK: Flags. (line 202) 48554 * symbolic label: Sharing. (line 20) 48555 * sync_addMODE instruction pattern: Standard Names. (line 1631) 48556 * sync_andMODE instruction pattern: Standard Names. (line 1631) 48557 * sync_compare_and_swapMODE instruction pattern: Standard Names. 48558 (line 1591) 48559 * sync_iorMODE instruction pattern: Standard Names. (line 1631) 48560 * sync_lock_releaseMODE instruction pattern: Standard Names. (line 1696) 48561 * sync_lock_test_and_setMODE instruction pattern: Standard Names. 48562 (line 1670) 48563 * sync_nandMODE instruction pattern: Standard Names. (line 1631) 48564 * sync_new_addMODE instruction pattern: Standard Names. (line 1663) 48565 * sync_new_andMODE instruction pattern: Standard Names. (line 1663) 48566 * sync_new_iorMODE instruction pattern: Standard Names. (line 1663) 48567 * sync_new_nandMODE instruction pattern: Standard Names. (line 1663) 48568 * sync_new_subMODE instruction pattern: Standard Names. (line 1663) 48569 * sync_new_xorMODE instruction pattern: Standard Names. (line 1663) 48570 * sync_old_addMODE instruction pattern: Standard Names. (line 1646) 48571 * sync_old_andMODE instruction pattern: Standard Names. (line 1646) 48572 * sync_old_iorMODE instruction pattern: Standard Names. (line 1646) 48573 * sync_old_nandMODE instruction pattern: Standard Names. (line 1646) 48574 * sync_old_subMODE instruction pattern: Standard Names. (line 1646) 48575 * sync_old_xorMODE instruction pattern: Standard Names. (line 1646) 48576 * sync_subMODE instruction pattern: Standard Names. (line 1631) 48577 * sync_xorMODE instruction pattern: Standard Names. (line 1631) 48578 * SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 177) 48579 * SYSROOT_SUFFIX_SPEC: Driver. (line 172) 48580 * t-TARGET: Target Fragment. (line 6) 48581 * table jump: Basic Blocks. (line 67) 48582 * tablejump instruction pattern: Standard Names. (line 1249) 48583 * tag: GTY Options. (line 82) 48584 * tagging insns: Tagging Insns. (line 6) 48585 * tail calls: Tail Calls. (line 6) 48586 * TAmode: Machine Modes. (line 156) 48587 * target attributes: Target Attributes. (line 6) 48588 * target description macros: Target Macros. (line 6) 48589 * target functions: Target Structure. (line 6) 48590 * target hooks: Target Structure. (line 6) 48591 * target makefile fragment: Target Fragment. (line 6) 48592 * target specifications: Run-time Target. (line 6) 48593 * TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 48594 (line 45) 48595 * TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 48596 (line 88) 48597 * TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 48598 (line 63) 48599 * TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 48600 (line 72) 48601 * TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 48602 (line 38) 48603 * TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 48604 (line 79) 48605 * TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 48606 (line 52) 48607 * TARGET_ADDRESS_COST: Costs. (line 302) 48608 * TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 398) 48609 * TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 700) 48610 * TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 980) 48611 * TARGET_ALWAYS_STRIP_DOTDOT: Driver. (line 247) 48612 * TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 84) 48613 * TARGET_ARM_EABI_UNWINDER: Exception Region Output. 48614 (line 129) 48615 * TARGET_ARRAY_MODE_SUPPORTED_P: Register Arguments. (line 337) 48616 * TARGET_ASAN_SHADOW_OFFSET: Misc. (line 1008) 48617 * TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10) 48618 * TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8) 48619 * TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9) 48620 * TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11) 48621 * TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 271) 48622 * TARGET_ASM_BYTE_OP: Data Output. (line 7) 48623 * TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 207) 48624 * TARGET_ASM_CLOSE_PAREN: Data Output. (line 131) 48625 * TARGET_ASM_CODE_END: File Framework. (line 59) 48626 * TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 48627 (line 69) 48628 * TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 154) 48629 * TARGET_ASM_DESTRUCTOR: Macros for Initialization. 48630 (line 83) 48631 * TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 82) 48632 * TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 74) 48633 * TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 63) 48634 * TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 306) 48635 * TARGET_ASM_FILE_END: File Framework. (line 37) 48636 * TARGET_ASM_FILE_START: File Framework. (line 9) 48637 * TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17) 48638 * TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31) 48639 * TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 84) 48640 * TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61) 48641 * TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55) 48642 * TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68) 48643 * TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11) 48644 * TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 215) 48645 * TARGET_ASM_FUNCTION_SECTION: File Framework. (line 124) 48646 * TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework. 48647 (line 134) 48648 * TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 199) 48649 * TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 190) 48650 * TARGET_ASM_INIT_SECTIONS: Sections. (line 160) 48651 * TARGET_ASM_INTEGER: Data Output. (line 27) 48652 * TARGET_ASM_INTERNAL_LABEL: Label Output. (line 350) 48653 * TARGET_ASM_JUMP_ALIGN_MAX_SKIP: Alignment Output. (line 22) 48654 * TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. 48655 (line 36) 48656 * TARGET_ASM_LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 69) 48657 * TARGET_ASM_LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 54) 48658 * TARGET_ASM_LTO_END: File Framework. (line 54) 48659 * TARGET_ASM_LTO_START: File Framework. (line 49) 48660 * TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 313) 48661 * TARGET_ASM_MERGEABLE_RODATA_PREFIX: Sections. (line 222) 48662 * TARGET_ASM_NAMED_SECTION: File Framework. (line 116) 48663 * TARGET_ASM_OPEN_PAREN: Data Output. (line 130) 48664 * TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 40) 48665 * TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 44) 48666 * TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 101) 48667 * TARGET_ASM_OUTPUT_IDENT: File Framework. (line 102) 48668 * TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 165) 48669 * TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 94) 48670 * TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 165) 48671 * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 209) 48672 * TARGET_ASM_RELOC_RW_MASK: Sections. (line 169) 48673 * TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 232) 48674 * TARGET_ASM_SELECT_SECTION: Sections. (line 181) 48675 * TARGET_ASM_TM_CLONE_TABLE_SECTION: Sections. (line 227) 48676 * TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 29) 48677 * TARGET_ASM_TTYPE: Exception Region Output. 48678 (line 123) 48679 * TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14) 48680 * TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12) 48681 * TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13) 48682 * TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15) 48683 * TARGET_ASM_UNIQUE_SECTION: Sections. (line 202) 48684 * TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 88) 48685 * TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 93) 48686 * TARGET_ATOMIC_TEST_AND_SET_TRUEVAL: Misc. (line 1018) 48687 * TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11) 48688 * TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 19) 48689 * TARGET_BINDS_LOCAL_P: Sections. (line 309) 48690 * TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 797) 48691 * TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 789) 48692 * TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 273) 48693 * TARGET_BUILTIN_DECL: Misc. (line 597) 48694 * TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 264) 48695 * TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 109) 48696 * TARGET_C99_FUNCTIONS: Library Calls. (line 71) 48697 * TARGET_C_PREINCLUDE: Misc. (line 362) 48698 * TARGET_CALLEE_COPIES: Register Arguments. (line 116) 48699 * TARGET_CAN_ELIMINATE: Elimination. (line 75) 48700 * TARGET_CAN_FOLLOW_JUMP: Misc. (line 687) 48701 * TARGET_CAN_INLINE_P: Target Attributes. (line 158) 48702 * TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 237) 48703 * TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 776) 48704 * TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 294) 48705 * TARGET_CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 48706 (line 57) 48707 * TARGET_CASE_VALUES_THRESHOLD: Misc. (line 47) 48708 * TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 48709 (line 121) 48710 * TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 28) 48711 * TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 121) 48712 * TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 494) 48713 * TARGET_CLASS_MAX_NREGS: Register Classes. (line 511) 48714 * TARGET_COMMUTATIVE_P: Misc. (line 693) 48715 * TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 27) 48716 * TARGET_COMPARE_VERSION_PRIORITY: Misc. (line 637) 48717 * TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60) 48718 * TARGET_CONST_ANCHOR: Misc. (line 991) 48719 * TARGET_CONST_NOT_OK_FOR_DEBUG_P: Addressing Modes. (line 232) 48720 * TARGET_CONVERT_TO_TYPE: Misc. (line 944) 48721 * TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9) 48722 * TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 87) 48723 * TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 38) 48724 * TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 62) 48725 * TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 25) 48726 * TARGET_CXX_DECL_MANGLING_CONTEXT: C++ ABI. (line 93) 48727 * TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 54) 48728 * TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 18) 48729 * TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 12) 48730 * TARGET_CXX_GUARD_TYPE: C++ ABI. (line 7) 48731 * TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 30) 48732 * TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 43) 48733 * TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 69) 48734 * TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 74) 48735 * TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 80) 48736 * TARGET_DEBUG_UNWIND_INFO: SDB and DWARF. (line 37) 48737 * TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 524) 48738 * TARGET_DECLSPEC: Target Attributes. (line 73) 48739 * TARGET_DEFAULT_PACK_STRUCT: Misc. (line 440) 48740 * TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 167) 48741 * TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 56) 48742 * TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 434) 48743 * TARGET_DELAY_SCHED2: SDB and DWARF. (line 66) 48744 * TARGET_DELAY_VARTRACK: SDB and DWARF. (line 70) 48745 * TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 223) 48746 * TARGET_DIFFERENT_ADDR_DISPLACEMENT_P: Register Classes. (line 570) 48747 * TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55) 48748 * TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 18) 48749 * TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 172) 48750 * TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 48751 (line 106) 48752 * TARGET_EDOM: Library Calls. (line 53) 48753 * TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 68) 48754 * TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 19) 48755 * TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 24) 48756 * TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 45) 48757 * TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 36) 48758 * TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 63) 48759 * TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 49) 48760 * TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 57) 48761 * TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 41) 48762 * TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 31) 48763 * TARGET_ENCODE_SECTION_INFO: Sections. (line 253) 48764 * TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 48765 (line 83) 48766 * TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 128) 48767 * TARGET_ENUM_VA_LIST_P: Register Arguments. (line 278) 48768 * TARGET_EXCEPT_UNWIND_INFO: Exception Region Output. 48769 (line 48) 48770 * TARGET_EXECUTABLE_SUFFIX: Misc. (line 750) 48771 * TARGET_EXPAND_BUILTIN: Misc. (line 607) 48772 * TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 67) 48773 * TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 530) 48774 * TARGET_EXPR: Unary and Binary Expressions. 48775 (line 6) 48776 * TARGET_EXTRA_INCLUDES: Misc. (line 837) 48777 * TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 21) 48778 * TARGET_EXTRA_PRE_INCLUDES: Misc. (line 844) 48779 * TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 48780 (line 106) 48781 * TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 527) 48782 * target_flags: Run-time Target. (line 52) 48783 * TARGET_FLAGS_REGNUM: Register Arguments. (line 394) 48784 * TARGET_FLT_EVAL_METHOD: Type Layout. (line 148) 48785 * TARGET_FN_ABI_VA_LIST: Register Arguments. (line 289) 48786 * TARGET_FOLD_BUILTIN: Misc. (line 628) 48787 * TARGET_FORCE_AT_COMP_DIR: SDB and DWARF. (line 61) 48788 * TARGET_FORMAT_TYPES: Misc. (line 864) 48789 * TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 9) 48790 * TARGET_FUNCTION_ARG: Register Arguments. (line 12) 48791 * TARGET_FUNCTION_ARG_ADVANCE: Register Arguments. (line 187) 48792 * TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 241) 48793 * TARGET_FUNCTION_ARG_ROUND_BOUNDARY: Register Arguments. (line 247) 48794 * TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 95) 48795 * TARGET_FUNCTION_INCOMING_ARG: Register Arguments. (line 68) 48796 * TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8) 48797 * TARGET_FUNCTION_VALUE: Scalar Return. (line 11) 48798 * TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 97) 48799 * TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc. (line 654) 48800 * TARGET_GET_DRAP_RTX: Misc. (line 974) 48801 * TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc. (line 647) 48802 * TARGET_GET_PCH_VALIDITY: PCH Target. (line 7) 48803 * TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 83) 48804 * TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 78) 48805 * TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 300) 48806 * TARGET_HANDLE_C_OPTION: Run-time Target. (line 75) 48807 * TARGET_HANDLE_OPTION: Run-time Target. (line 62) 48808 * TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 48809 (line 144) 48810 * TARGET_HAS_SINCOS: Library Calls. (line 79) 48811 * TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 811) 48812 * TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 48813 (line 64) 48814 * TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 141) 48815 * TARGET_HAVE_SRODATA_SECTION: Sections. (line 298) 48816 * TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 146) 48817 * TARGET_HAVE_TLS: Sections. (line 318) 48818 * TARGET_IN_SMALL_DATA_P: Sections. (line 294) 48819 * TARGET_INIT_BUILTINS: Misc. (line 580) 48820 * TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 48821 (line 115) 48822 * TARGET_INIT_LIBFUNCS: Library Calls. (line 16) 48823 * TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 82) 48824 * TARGET_INSTANTIATE_DECLS: Storage Layout. (line 538) 48825 * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 898) 48826 * TARGET_INVALID_BINARY_OP: Misc. (line 917) 48827 * TARGET_INVALID_CONVERSION: Misc. (line 904) 48828 * TARGET_INVALID_PARAMETER_TYPE: Misc. (line 923) 48829 * TARGET_INVALID_RETURN_TYPE: Misc. (line 930) 48830 * TARGET_INVALID_UNARY_OP: Misc. (line 910) 48831 * TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 661) 48832 * TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 50) 48833 * TARGET_LEGITIMATE_COMBINED_INSN: Misc. (line 673) 48834 * TARGET_LEGITIMATE_CONSTANT_P: Addressing Modes. (line 216) 48835 * TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 132) 48836 * TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 43) 48837 * TARGET_LIBCALL_VALUE: Scalar Return. (line 66) 48838 * TARGET_LIBFUNC_GNU_PREFIX: Library Calls. (line 25) 48839 * TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 461) 48840 * TARGET_LIBGCC_SDATA_SECTION: Sections. (line 132) 48841 * TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 467) 48842 * TARGET_LOOP_UNROLL_ADJUST: Misc. (line 818) 48843 * TARGET_LRA_P: Register Classes. (line 553) 48844 * TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 565) 48845 * TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 325) 48846 * TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 243) 48847 * TARGET_MANGLE_TYPE: Storage Layout. (line 542) 48848 * TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 39) 48849 * TARGET_MD_ASM_CLOBBERS: Misc. (line 486) 48850 * TARGET_MEM_CONSTRAINT: Addressing Modes. (line 109) 48851 * TARGET_MEM_REF: Storage References. (line 6) 48852 * TARGET_MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 413) 48853 * TARGET_MEMMODEL_CHECK: Misc. (line 1014) 48854 * TARGET_MEMORY_MOVE_COST: Costs. (line 81) 48855 * TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 47) 48856 * TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 39) 48857 * TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 33) 48858 * TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 92) 48859 * TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 199) 48860 * TARGET_MODE_REP_EXTENDED: Misc. (line 177) 48861 * TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 497) 48862 * TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 61) 48863 * TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments. 48864 (line 51) 48865 * TARGET_N_FORMAT_TYPES: Misc. (line 869) 48866 * TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 404) 48867 * TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 90) 48868 * TARGET_OBJC_DECLARE_CLASS_DEFINITION: Run-time Target. (line 111) 48869 * TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target. 48870 (line 106) 48871 * TARGET_OBJECT_SUFFIX: Misc. (line 745) 48872 * TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46) 48873 * TARGET_OPTF: Misc. (line 851) 48874 * TARGET_OPTION_DEFAULT_PARAMS: Run-time Target. (line 161) 48875 * TARGET_OPTION_FUNCTION_VERSIONS: Target Attributes. (line 151) 48876 * TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 158) 48877 * TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 144) 48878 * TARGET_OPTION_OVERRIDE: Target Attributes. (line 137) 48879 * TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 131) 48880 * TARGET_OPTION_PRINT: Target Attributes. (line 125) 48881 * TARGET_OPTION_RESTORE: Target Attributes. (line 119) 48882 * TARGET_OPTION_SAVE: Target Attributes. (line 113) 48883 * TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 102) 48884 * TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42) 48885 * TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 127) 48886 * TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 873) 48887 * TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 879) 48888 * TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 883) 48889 * TARGET_PASS_BY_REFERENCE: Register Arguments. (line 104) 48890 * TARGET_PCH_VALID_P: PCH Target. (line 13) 48891 * TARGET_POSIX_IO: Misc. (line 510) 48892 * TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 289) 48893 * TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 218) 48894 * TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 206) 48895 * TARGET_PREPARE_PCH_SAVE: PCH Target. (line 35) 48896 * TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 128) 48897 * TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 302) 48898 * TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 118) 48899 * TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11) 48900 * TARGET_PROMOTED_TYPE: Misc. (line 936) 48901 * TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 295) 48902 * TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 311) 48903 * TARGET_REGISTER_MOVE_COST: Costs. (line 33) 48904 * TARGET_REGISTER_PRIORITY: Register Classes. (line 558) 48905 * TARGET_RELAXED_ORDERING: Misc. (line 888) 48906 * TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 617) 48907 * TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 17) 48908 * TARGET_RETURN_IN_MSB: Scalar Return. (line 117) 48909 * TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 94) 48910 * TARGET_RTX_COSTS: Costs. (line 271) 48911 * TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 319) 48912 * TARGET_SCHED_ADJUST_COST: Scheduling. (line 37) 48913 * TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 52) 48914 * TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 274) 48915 * TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 289) 48916 * TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 89) 48917 * TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 235) 48918 * TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 160) 48919 * TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 144) 48920 * TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 153) 48921 * TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 132) 48922 * TARGET_SCHED_DISPATCH: Scheduling. (line 355) 48923 * TARGET_SCHED_DISPATCH_DO: Scheduling. (line 360) 48924 * TARGET_SCHED_EXPOSED_PIPELINE: Scheduling. (line 364) 48925 * TARGET_SCHED_FINISH: Scheduling. (line 109) 48926 * TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 126) 48927 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 215) 48928 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 204) 48929 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 48930 (line 168) 48931 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 48932 (line 196) 48933 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC: Scheduling. 48934 (line 328) 48935 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 220) 48936 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 230) 48937 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 225) 48938 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 210) 48939 * TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 293) 48940 * TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 315) 48941 * TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 269) 48942 * TARGET_SCHED_INIT: Scheduling. (line 99) 48943 * TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 149) 48944 * TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 141) 48945 * TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 118) 48946 * TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 279) 48947 * TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 246) 48948 * TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12) 48949 * TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 308) 48950 * TARGET_SCHED_REASSOCIATION_WIDTH: Scheduling. (line 370) 48951 * TARGET_SCHED_REORDER: Scheduling. (line 60) 48952 * TARGET_SCHED_REORDER2: Scheduling. (line 77) 48953 * TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 285) 48954 * TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 340) 48955 * TARGET_SCHED_SMS_RES_MII: Scheduling. (line 346) 48956 * TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 297) 48957 * TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 24) 48958 * TARGET_SECONDARY_RELOAD: Register Classes. (line 318) 48959 * TARGET_SECTION_TYPE_FLAGS: File Framework. (line 152) 48960 * TARGET_SET_CURRENT_FUNCTION: Misc. (line 727) 48961 * TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 34) 48962 * TARGET_SET_UP_BY_PROLOGUE: Tail Calls. (line 31) 48963 * TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 76) 48964 * TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 140) 48965 * TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments. 48966 (line 361) 48967 * TARGET_SPILL_CLASS: Register Classes. (line 578) 48968 * TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 261) 48969 * TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 48970 (line 17) 48971 * TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 48972 (line 7) 48973 * TARGET_STATIC_CHAIN: Frame Registers. (line 92) 48974 * TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 112) 48975 * TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 116) 48976 * TARGET_STRIP_NAME_ENCODING: Sections. (line 290) 48977 * TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 45) 48978 * TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection. 48979 (line 27) 48980 * TARGET_SUPPORTS_WEAK: Label Output. (line 241) 48981 * TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 48982 (line 100) 48983 * TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 75) 48984 * TARGET_TRAMPOLINE_INIT: Trampolines. (line 56) 48985 * TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 719) 48986 * TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 48987 (line 74) 48988 * TARGET_UNWIND_WORD_MODE: Storage Layout. (line 473) 48989 * TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 970) 48990 * TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 55) 48991 * TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 251) 48992 * TARGET_USE_BLOCKS_FOR_DECL_P: Addressing Modes. (line 257) 48993 * TARGET_USE_JCR_SECTION: Misc. (line 952) 48994 * TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 126) 48995 * TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 68) 48996 * TARGET_VALID_POINTER_MODE: Register Arguments. (line 306) 48997 * TARGET_VECTOR_ALIGNMENT: Storage Layout. (line 264) 48998 * TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 331) 48999 * TARGET_VECTORIZE_ADD_STMT_COST: Addressing Modes. (line 373) 49000 * TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES: Addressing Modes. 49001 (line 353) 49002 * TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 315) 49003 * TARGET_VECTORIZE_BUILTIN_GATHER: Addressing Modes. (line 404) 49004 * TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 273) 49005 * TARGET_VECTORIZE_BUILTIN_TM_LOAD: Addressing Modes. (line 395) 49006 * TARGET_VECTORIZE_BUILTIN_TM_STORE: Addressing Modes. (line 399) 49007 * TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 49008 (line 300) 49009 * TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 49010 (line 327) 49011 * TARGET_VECTORIZE_DESTROY_COST_DATA: Addressing Modes. (line 390) 49012 * TARGET_VECTORIZE_FINISH_COST: Addressing Modes. (line 384) 49013 * TARGET_VECTORIZE_INIT_COST: Addressing Modes. (line 361) 49014 * TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 346) 49015 * TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. 49016 (line 337) 49017 * TARGET_VECTORIZE_VEC_PERM_CONST_OK: Addressing Modes. (line 311) 49018 * TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 49019 (line 306) 49020 * TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 348) 49021 * TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 342) 49022 * TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 331) 49023 * TARGET_WANT_DEBUG_PUB_SECTIONS: SDB and DWARF. (line 56) 49024 * TARGET_WARN_FUNC_RETURN: Tail Calls. (line 36) 49025 * TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 277) 49026 * targetm: Target Structure. (line 7) 49027 * targets, makefile: Makefile. (line 6) 49028 * TCmode: Machine Modes. (line 197) 49029 * TDmode: Machine Modes. (line 94) 49030 * TEMPLATE_DECL: Declarations. (line 6) 49031 * Temporaries: Temporaries. (line 6) 49032 * termination routines: Initialization. (line 6) 49033 * testing constraints: C Constraint Interface. 49034 (line 6) 49035 * TEXT_SECTION_ASM_OP: Sections. (line 38) 49036 * TF_SIZE: Type Layout. (line 139) 49037 * TFmode: Machine Modes. (line 98) 49038 * THEN_CLAUSE: Statements for C++. (line 6) 49039 * THREAD_MODEL_SPEC: Driver. (line 163) 49040 * THROW_EXPR: Unary and Binary Expressions. 49041 (line 6) 49042 * THUNK_DECL: Declarations. (line 6) 49043 * THUNK_DELTA: Declarations. (line 6) 49044 * TImode: Machine Modes. (line 48) 49045 * TImode, in insn: Insns. (line 278) 49046 * TLS_COMMON_ASM_OP: Sections. (line 81) 49047 * TLS_SECTION_ASM_FLAG: Sections. (line 86) 49048 * tm.h macros: Target Macros. (line 6) 49049 * TQFmode: Machine Modes. (line 62) 49050 * TQmode: Machine Modes. (line 119) 49051 * TRAMPOLINE_ALIGNMENT: Trampolines. (line 49) 49052 * TRAMPOLINE_SECTION: Trampolines. (line 40) 49053 * TRAMPOLINE_SIZE: Trampolines. (line 45) 49054 * trampolines for nested functions: Trampolines. (line 6) 49055 * TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 111) 49056 * trap instruction pattern: Standard Names. (line 1542) 49057 * tree <1>: Macros and Functions. 49058 (line 6) 49059 * tree: Tree overview. (line 6) 49060 * Tree SSA: Tree SSA. (line 6) 49061 * TREE_CHAIN: Macros and Functions. 49062 (line 6) 49063 * TREE_CODE: Tree overview. (line 6) 49064 * tree_int_cst_equal: Constant expressions. 49065 (line 6) 49066 * TREE_INT_CST_HIGH: Constant expressions. 49067 (line 6) 49068 * TREE_INT_CST_LOW: Constant expressions. 49069 (line 6) 49070 * tree_int_cst_lt: Constant expressions. 49071 (line 6) 49072 * TREE_LIST: Containers. (line 6) 49073 * TREE_OPERAND: Expression trees. (line 6) 49074 * TREE_PUBLIC <1>: Function Properties. 49075 (line 28) 49076 * TREE_PUBLIC: Function Basics. (line 6) 49077 * TREE_PURPOSE: Containers. (line 6) 49078 * TREE_READONLY: Function Properties. 49079 (line 37) 49080 * tree_size: Macros and Functions. 49081 (line 13) 49082 * TREE_STATIC: Function Properties. 49083 (line 31) 49084 * TREE_STRING_LENGTH: Constant expressions. 49085 (line 6) 49086 * TREE_STRING_POINTER: Constant expressions. 49087 (line 6) 49088 * TREE_THIS_VOLATILE: Function Properties. 49089 (line 34) 49090 * TREE_TYPE <1>: Types for C++. (line 6) 49091 * TREE_TYPE <2>: Function Basics. (line 47) 49092 * TREE_TYPE <3>: Expression trees. (line 6) 49093 * TREE_TYPE <4>: Working with declarations. 49094 (line 11) 49095 * TREE_TYPE <5>: Types. (line 6) 49096 * TREE_TYPE: Macros and Functions. 49097 (line 6) 49098 * TREE_VALUE: Containers. (line 6) 49099 * TREE_VEC: Containers. (line 6) 49100 * TREE_VEC_ELT: Containers. (line 6) 49101 * TREE_VEC_LENGTH: Containers. (line 6) 49102 * TRULY_NOOP_TRUNCATION: Misc. (line 163) 49103 * TRUNC_DIV_EXPR: Unary and Binary Expressions. 49104 (line 6) 49105 * TRUNC_MOD_EXPR: Unary and Binary Expressions. 49106 (line 6) 49107 * truncate: Conversions. (line 38) 49108 * truncMN2 instruction pattern: Standard Names. (line 903) 49109 * TRUTH_AND_EXPR: Unary and Binary Expressions. 49110 (line 6) 49111 * TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 49112 (line 6) 49113 * TRUTH_NOT_EXPR: Unary and Binary Expressions. 49114 (line 6) 49115 * TRUTH_OR_EXPR: Unary and Binary Expressions. 49116 (line 6) 49117 * TRUTH_ORIF_EXPR: Unary and Binary Expressions. 49118 (line 6) 49119 * TRUTH_XOR_EXPR: Unary and Binary Expressions. 49120 (line 6) 49121 * TRY_BLOCK: Statements for C++. (line 6) 49122 * TRY_HANDLERS: Statements for C++. (line 6) 49123 * TRY_STMTS: Statements for C++. (line 6) 49124 * Tuple specific accessors: Tuple specific accessors. 49125 (line 6) 49126 * tuples: Tuple representation. 49127 (line 6) 49128 * type: Types. (line 6) 49129 * type declaration: Declarations. (line 6) 49130 * TYPE_ALIGN <1>: Types for C++. (line 6) 49131 * TYPE_ALIGN: Types. (line 6) 49132 * TYPE_ARG_TYPES <1>: Types for C++. (line 6) 49133 * TYPE_ARG_TYPES: Types. (line 6) 49134 * TYPE_ASM_OP: Label Output. (line 79) 49135 * TYPE_ATTRIBUTES: Attributes. (line 25) 49136 * TYPE_BINFO: Classes. (line 6) 49137 * TYPE_BUILT_IN: Types for C++. (line 68) 49138 * TYPE_CANONICAL: Types. (line 6) 49139 * TYPE_CONTEXT <1>: Types for C++. (line 6) 49140 * TYPE_CONTEXT: Types. (line 6) 49141 * TYPE_DECL: Declarations. (line 6) 49142 * TYPE_FIELDS <1>: Classes. (line 6) 49143 * TYPE_FIELDS <2>: Types for C++. (line 6) 49144 * TYPE_FIELDS: Types. (line 6) 49145 * TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 96) 49146 * TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 81) 49147 * TYPE_HAS_MUTABLE_P: Classes. (line 86) 49148 * TYPE_HAS_NEW_OPERATOR: Classes. (line 93) 49149 * TYPE_MAIN_VARIANT <1>: Types for C++. (line 6) 49150 * TYPE_MAIN_VARIANT: Types. (line 6) 49151 * TYPE_MAX_VALUE: Types. (line 6) 49152 * TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 49153 * TYPE_METHOD_BASETYPE: Types. (line 6) 49154 * TYPE_METHODS: Classes. (line 6) 49155 * TYPE_MIN_VALUE: Types. (line 6) 49156 * TYPE_NAME <1>: Types for C++. (line 6) 49157 * TYPE_NAME: Types. (line 6) 49158 * TYPE_NOTHROW_P: Functions for C++. (line 154) 49159 * TYPE_OFFSET_BASETYPE <1>: Types for C++. (line 6) 49160 * TYPE_OFFSET_BASETYPE: Types. (line 6) 49161 * TYPE_OPERAND_FMT: Label Output. (line 90) 49162 * TYPE_OVERLOADS_ARRAY_REF: Classes. (line 104) 49163 * TYPE_OVERLOADS_ARROW: Classes. (line 107) 49164 * TYPE_OVERLOADS_CALL_EXPR: Classes. (line 100) 49165 * TYPE_POLYMORPHIC_P: Classes. (line 77) 49166 * TYPE_PRECISION <1>: Types for C++. (line 6) 49167 * TYPE_PRECISION: Types. (line 6) 49168 * TYPE_PTR_P: Types for C++. (line 74) 49169 * TYPE_PTRDATAMEM_P: Types for C++. (line 6) 49170 * TYPE_PTRFN_P: Types for C++. (line 78) 49171 * TYPE_PTROB_P: Types for C++. (line 81) 49172 * TYPE_PTROBV_P: Types for C++. (line 6) 49173 * TYPE_QUAL_CONST <1>: Types for C++. (line 6) 49174 * TYPE_QUAL_CONST: Types. (line 6) 49175 * TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 49176 * TYPE_QUAL_RESTRICT: Types. (line 6) 49177 * TYPE_QUAL_VOLATILE <1>: Types for C++. (line 6) 49178 * TYPE_QUAL_VOLATILE: Types. (line 6) 49179 * TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 49180 * TYPE_SIZE <1>: Types for C++. (line 6) 49181 * TYPE_SIZE: Types. (line 6) 49182 * TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 49183 * TYPE_UNQUALIFIED <1>: Types for C++. (line 6) 49184 * TYPE_UNQUALIFIED: Types. (line 6) 49185 * TYPE_VFIELD: Classes. (line 6) 49186 * TYPENAME_TYPE: Types for C++. (line 6) 49187 * TYPENAME_TYPE_FULLNAME <1>: Types for C++. (line 6) 49188 * TYPENAME_TYPE_FULLNAME: Types. (line 6) 49189 * TYPEOF_TYPE: Types for C++. (line 6) 49190 * UDAmode: Machine Modes. (line 168) 49191 * udiv: Arithmetic. (line 130) 49192 * udivM3 instruction pattern: Standard Names. (line 269) 49193 * udivmodM4 instruction pattern: Standard Names. (line 507) 49194 * udot_prodM instruction pattern: Standard Names. (line 335) 49195 * UDQmode: Machine Modes. (line 136) 49196 * UHAmode: Machine Modes. (line 160) 49197 * UHQmode: Machine Modes. (line 128) 49198 * UINT16_TYPE: Type Layout. (line 258) 49199 * UINT32_TYPE: Type Layout. (line 259) 49200 * UINT64_TYPE: Type Layout. (line 260) 49201 * UINT8_TYPE: Type Layout. (line 257) 49202 * UINT_FAST16_TYPE: Type Layout. (line 274) 49203 * UINT_FAST32_TYPE: Type Layout. (line 275) 49204 * UINT_FAST64_TYPE: Type Layout. (line 276) 49205 * UINT_FAST8_TYPE: Type Layout. (line 273) 49206 * UINT_LEAST16_TYPE: Type Layout. (line 266) 49207 * UINT_LEAST32_TYPE: Type Layout. (line 267) 49208 * UINT_LEAST64_TYPE: Type Layout. (line 268) 49209 * UINT_LEAST8_TYPE: Type Layout. (line 265) 49210 * UINTMAX_TYPE: Type Layout. (line 241) 49211 * UINTPTR_TYPE: Type Layout. (line 278) 49212 * umaddMN4 instruction pattern: Standard Names. (line 454) 49213 * umax: Arithmetic. (line 149) 49214 * umaxM3 instruction pattern: Standard Names. (line 269) 49215 * umin: Arithmetic. (line 149) 49216 * uminM3 instruction pattern: Standard Names. (line 269) 49217 * umod: Arithmetic. (line 136) 49218 * umodM3 instruction pattern: Standard Names. (line 269) 49219 * umsubMN4 instruction pattern: Standard Names. (line 478) 49220 * umulhisi3 instruction pattern: Standard Names. (line 426) 49221 * umulM3_highpart instruction pattern: Standard Names. (line 440) 49222 * umulqihi3 instruction pattern: Standard Names. (line 426) 49223 * umulsidi3 instruction pattern: Standard Names. (line 426) 49224 * unchanging: Flags. (line 296) 49225 * unchanging, in call_insn: Flags. (line 19) 49226 * unchanging, in jump_insn, call_insn and insn: Flags. (line 39) 49227 * unchanging, in mem: Flags. (line 134) 49228 * unchanging, in subreg: Flags. (line 170) 49229 * unchanging, in symbol_ref: Flags. (line 10) 49230 * UNEQ_EXPR: Unary and Binary Expressions. 49231 (line 6) 49232 * UNGE_EXPR: Unary and Binary Expressions. 49233 (line 6) 49234 * UNGT_EXPR: Unary and Binary Expressions. 49235 (line 6) 49236 * UNION_TYPE <1>: Classes. (line 6) 49237 * UNION_TYPE: Types. (line 6) 49238 * unions, returning: Interface. (line 10) 49239 * UNITS_PER_WORD: Storage Layout. (line 66) 49240 * UNKNOWN_TYPE <1>: Types for C++. (line 6) 49241 * UNKNOWN_TYPE: Types. (line 6) 49242 * UNLE_EXPR: Unary and Binary Expressions. 49243 (line 6) 49244 * UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 49) 49245 * UNLT_EXPR: Unary and Binary Expressions. 49246 (line 6) 49247 * UNORDERED_EXPR: Unary and Binary Expressions. 49248 (line 6) 49249 * unshare_all_rtl: Sharing. (line 58) 49250 * unsigned division: Arithmetic. (line 130) 49251 * unsigned division with unsigned saturation: Arithmetic. (line 130) 49252 * unsigned greater than: Comparisons. (line 64) 49253 * unsigned less than: Comparisons. (line 68) 49254 * unsigned minimum and maximum: Arithmetic. (line 149) 49255 * unsigned_fix: Conversions. (line 77) 49256 * unsigned_float: Conversions. (line 62) 49257 * unsigned_fract_convert: Conversions. (line 97) 49258 * unsigned_sat_fract: Conversions. (line 103) 49259 * unspec <1>: Constant Definitions. 49260 (line 111) 49261 * unspec: Side Effects. (line 293) 49262 * unspec_volatile <1>: Constant Definitions. 49263 (line 99) 49264 * unspec_volatile: Side Effects. (line 293) 49265 * untyped_call instruction pattern: Standard Names. (line 1145) 49266 * untyped_return instruction pattern: Standard Names. (line 1209) 49267 * UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 49268 * update_ssa: SSA. (line 76) 49269 * update_stmt <1>: SSA Operands. (line 6) 49270 * update_stmt: Manipulating GIMPLE statements. 49271 (line 141) 49272 * update_stmt_if_modified: Manipulating GIMPLE statements. 49273 (line 144) 49274 * UQQmode: Machine Modes. (line 123) 49275 * us_ashift: Arithmetic. (line 173) 49276 * us_minus: Arithmetic. (line 36) 49277 * us_mult: Arithmetic. (line 92) 49278 * us_neg: Arithmetic. (line 81) 49279 * us_plus: Arithmetic. (line 14) 49280 * us_truncate: Conversions. (line 48) 49281 * usaddM3 instruction pattern: Standard Names. (line 269) 49282 * USAmode: Machine Modes. (line 164) 49283 * usashlM3 instruction pattern: Standard Names. (line 510) 49284 * usdivM3 instruction pattern: Standard Names. (line 269) 49285 * use: Side Effects. (line 168) 49286 * USE_C_ALLOCA: Host Misc. (line 19) 49287 * USE_LD_AS_NEEDED: Driver. (line 136) 49288 * USE_LOAD_POST_DECREMENT: Costs. (line 226) 49289 * USE_LOAD_POST_INCREMENT: Costs. (line 221) 49290 * USE_LOAD_PRE_DECREMENT: Costs. (line 236) 49291 * USE_LOAD_PRE_INCREMENT: Costs. (line 231) 49292 * use_param: GTY Options. (line 114) 49293 * use_paramN: GTY Options. (line 132) 49294 * use_params: GTY Options. (line 140) 49295 * USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 194) 49296 * USE_STORE_POST_DECREMENT: Costs. (line 246) 49297 * USE_STORE_POST_INCREMENT: Costs. (line 241) 49298 * USE_STORE_PRE_DECREMENT: Costs. (line 256) 49299 * USE_STORE_PRE_INCREMENT: Costs. (line 251) 49300 * used: Flags. (line 314) 49301 * used, in symbol_ref: Flags. (line 197) 49302 * user: GTY Options. (line 301) 49303 * user gc: User GC. (line 6) 49304 * USER_LABEL_PREFIX: Instruction Output. (line 154) 49305 * USING_STMT: Statements for C++. (line 6) 49306 * usmaddMN4 instruction pattern: Standard Names. (line 462) 49307 * usmsubMN4 instruction pattern: Standard Names. (line 486) 49308 * usmulhisi3 instruction pattern: Standard Names. (line 430) 49309 * usmulM3 instruction pattern: Standard Names. (line 269) 49310 * usmulqihi3 instruction pattern: Standard Names. (line 430) 49311 * usmulsidi3 instruction pattern: Standard Names. (line 430) 49312 * usnegM2 instruction pattern: Standard Names. (line 532) 49313 * USQmode: Machine Modes. (line 132) 49314 * ussubM3 instruction pattern: Standard Names. (line 269) 49315 * usum_widenM3 instruction pattern: Standard Names. (line 345) 49316 * UTAmode: Machine Modes. (line 172) 49317 * UTQmode: Machine Modes. (line 140) 49318 * V in constraint: Simple Constraints. (line 43) 49319 * VA_ARG_EXPR: Unary and Binary Expressions. 49320 (line 6) 49321 * values, returned by functions: Scalar Return. (line 6) 49322 * VAR_DECL: Declarations. (line 6) 49323 * var_location: Debug Information. (line 14) 49324 * varargs implementation: Varargs. (line 6) 49325 * variable: Declarations. (line 6) 49326 * Variable Location Debug Information in RTL: Debug Information. 49327 (line 6) 49328 * variable_size: GTY Options. (line 230) 49329 * vashlM3 instruction pattern: Standard Names. (line 524) 49330 * vashrM3 instruction pattern: Standard Names. (line 524) 49331 * vcondMN instruction pattern: Standard Names. (line 214) 49332 * vec_concat: Vector Operations. (line 28) 49333 * vec_duplicate: Vector Operations. (line 33) 49334 * vec_extractM instruction pattern: Standard Names. (line 204) 49335 * vec_initM instruction pattern: Standard Names. (line 209) 49336 * vec_load_lanesMN instruction pattern: Standard Names. (line 166) 49337 * VEC_LSHIFT_EXPR: Vectors. (line 6) 49338 * vec_merge: Vector Operations. (line 11) 49339 * VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 49340 * VEC_PACK_SAT_EXPR: Vectors. (line 6) 49341 * vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 372) 49342 * vec_pack_ssat_M instruction pattern: Standard Names. (line 365) 49343 * VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 49344 * vec_pack_trunc_M instruction pattern: Standard Names. (line 358) 49345 * vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 372) 49346 * vec_pack_usat_M instruction pattern: Standard Names. (line 365) 49347 * vec_perm_constM instruction pattern: Standard Names. (line 242) 49348 * vec_permM instruction pattern: Standard Names. (line 224) 49349 * VEC_RSHIFT_EXPR: Vectors. (line 6) 49350 * vec_select: Vector Operations. (line 19) 49351 * vec_setM instruction pattern: Standard Names. (line 199) 49352 * vec_shl_M instruction pattern: Standard Names. (line 352) 49353 * vec_shr_M instruction pattern: Standard Names. (line 352) 49354 * vec_store_lanesMN instruction pattern: Standard Names. (line 188) 49355 * VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 49356 * VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 49357 * VEC_UNPACK_HI_EXPR: Vectors. (line 6) 49358 * VEC_UNPACK_LO_EXPR: Vectors. (line 6) 49359 * vec_unpacks_float_hi_M instruction pattern: Standard Names. 49360 (line 394) 49361 * vec_unpacks_float_lo_M instruction pattern: Standard Names. 49362 (line 394) 49363 * vec_unpacks_hi_M instruction pattern: Standard Names. (line 379) 49364 * vec_unpacks_lo_M instruction pattern: Standard Names. (line 379) 49365 * vec_unpacku_float_hi_M instruction pattern: Standard Names. 49366 (line 394) 49367 * vec_unpacku_float_lo_M instruction pattern: Standard Names. 49368 (line 394) 49369 * vec_unpacku_hi_M instruction pattern: Standard Names. (line 387) 49370 * vec_unpacku_lo_M instruction pattern: Standard Names. (line 387) 49371 * VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 49372 * VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 49373 * vec_widen_smult_even_M instruction pattern: Standard Names. 49374 (line 403) 49375 * vec_widen_smult_hi_M instruction pattern: Standard Names. (line 403) 49376 * vec_widen_smult_lo_M instruction pattern: Standard Names. (line 403) 49377 * vec_widen_smult_odd_M instruction pattern: Standard Names. (line 403) 49378 * vec_widen_sshiftl_hi_M instruction pattern: Standard Names. 49379 (line 412) 49380 * vec_widen_sshiftl_lo_M instruction pattern: Standard Names. 49381 (line 412) 49382 * vec_widen_umult_even_M instruction pattern: Standard Names. 49383 (line 403) 49384 * vec_widen_umult_hi_M instruction pattern: Standard Names. (line 403) 49385 * vec_widen_umult_lo_M instruction pattern: Standard Names. (line 403) 49386 * vec_widen_umult_odd_M instruction pattern: Standard Names. (line 403) 49387 * vec_widen_ushiftl_hi_M instruction pattern: Standard Names. 49388 (line 412) 49389 * vec_widen_ushiftl_lo_M instruction pattern: Standard Names. 49390 (line 412) 49391 * vector: Containers. (line 6) 49392 * vector operations: Vector Operations. (line 6) 49393 * VECTOR_CST: Constant expressions. 49394 (line 6) 49395 * VECTOR_STORE_FLAG_VALUE: Misc. (line 294) 49396 * verify_flow_info: Maintaining the CFG. 49397 (line 119) 49398 * virtual operands: SSA Operands. (line 6) 49399 * VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 49400 * VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 49401 * VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 49402 * VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 49403 * VLIW: Processor pipeline description. 49404 (line 6) 49405 * vlshrM3 instruction pattern: Standard Names. (line 524) 49406 * VMS: Filesystem. (line 37) 49407 * VMS_DEBUGGING_INFO: VMS Debug. (line 9) 49408 * VOID_TYPE: Types. (line 6) 49409 * VOIDmode: Machine Modes. (line 190) 49410 * volatil: Flags. (line 328) 49411 * volatil, in insn, call_insn, jump_insn, code_label, barrier, and note: Flags. 49412 (line 44) 49413 * volatil, in label_ref and reg_label: Flags. (line 65) 49414 * volatil, in mem, asm_operands, and asm_input: Flags. (line 76) 49415 * volatil, in reg: Flags. (line 98) 49416 * volatil, in subreg: Flags. (line 170) 49417 * volatil, in symbol_ref: Flags. (line 206) 49418 * volatile memory references: Flags. (line 329) 49419 * volatile, in prefetch: Flags. (line 214) 49420 * voting between constraint alternatives: Class Preferences. (line 6) 49421 * vrotlM3 instruction pattern: Standard Names. (line 524) 49422 * vrotrM3 instruction pattern: Standard Names. (line 524) 49423 * walk_dominator_tree: SSA. (line 254) 49424 * walk_gimple_op: Statement and operand traversals. 49425 (line 32) 49426 * walk_gimple_seq: Statement and operand traversals. 49427 (line 50) 49428 * walk_gimple_stmt: Statement and operand traversals. 49429 (line 13) 49430 * walk_use_def_chains: SSA. (line 230) 49431 * WCHAR_TYPE: Type Layout. (line 209) 49432 * WCHAR_TYPE_SIZE: Type Layout. (line 217) 49433 * which_alternative: Output Statement. (line 59) 49434 * WHILE_BODY: Statements for C++. (line 6) 49435 * WHILE_COND: Statements for C++. (line 6) 49436 * WHILE_STMT: Statements for C++. (line 6) 49437 * whopr: LTO. (line 6) 49438 * WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 154) 49439 * window_save instruction pattern: Standard Names. (line 1513) 49440 * WINT_TYPE: Type Layout. (line 222) 49441 * word_mode: Machine Modes. (line 336) 49442 * WORD_REGISTER_OPERATIONS: Misc. (line 54) 49443 * WORDS_BIG_ENDIAN: Storage Layout. (line 29) 49444 * WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 217) 49445 * wpa: LTO. (line 6) 49446 * X in constraint: Simple Constraints. (line 124) 49447 * x-HOST: Host Fragment. (line 6) 49448 * XCmode: Machine Modes. (line 197) 49449 * XCOFF_DEBUGGING_INFO: DBX Options. (line 13) 49450 * XEXP: Accessors. (line 6) 49451 * XF_SIZE: Type Layout. (line 138) 49452 * XFmode: Machine Modes. (line 79) 49453 * XINT: Accessors. (line 6) 49454 * xm-MACHINE.h <1>: Host Misc. (line 6) 49455 * xm-MACHINE.h: Filesystem. (line 6) 49456 * xor: Arithmetic. (line 168) 49457 * xor, canonicalization of: Insn Canonicalizations. 49458 (line 79) 49459 * xorM3 instruction pattern: Standard Names. (line 269) 49460 * XSTR: Accessors. (line 6) 49461 * XVEC: Accessors. (line 41) 49462 * XVECEXP: Accessors. (line 48) 49463 * XVECLEN: Accessors. (line 44) 49464 * XWINT: Accessors. (line 6) 49465 * zero_extend: Conversions. (line 28) 49466 * zero_extendMN2 instruction pattern: Standard Names. (line 913) 49467 * zero_extract: Bit-Fields. (line 30) 49468 * zero_extract, canonicalization of: Insn Canonicalizations. 49469 (line 88) 49470 49471 49472 49473 Tag Table: 49474 Node: Top1854 49475 Node: Contributing4942 49476 Node: Portability5683 49477 Node: Interface7471 49478 Node: Libgcc10511 49479 Node: Integer library routines12352 49480 Node: Soft float library routines19194 49481 Node: Decimal float library routines31131 49482 Node: Fixed-point fractional library routines46888 49483 Node: Exception handling routines147286 49484 Node: Miscellaneous routines148393 49485 Node: Languages150513 49486 Node: Source Tree152062 49487 Node: Configure Terms152644 49488 Node: Top Level155602 49489 Node: gcc Directory159176 49490 Node: Subdirectories160126 49491 Node: Configuration162293 49492 Node: Config Fragments163013 49493 Node: System Config164242 49494 Node: Configuration Files165178 49495 Node: Build168003 49496 Node: Makefile168415 49497 Ref: Makefile-Footnote-1175218 49498 Ref: Makefile-Footnote-2175363 49499 Node: Library Files175435 49500 Node: Headers175997 49501 Node: Documentation178080 49502 Node: Texinfo Manuals178939 49503 Node: Man Page Generation181272 49504 Node: Miscellaneous Docs183187 49505 Node: Front End184581 49506 Node: Front End Directory188274 49507 Node: Front End Config189594 49508 Node: Front End Makefile192420 49509 Node: Back End196202 49510 Node: Testsuites199999 49511 Node: Test Idioms200930 49512 Node: Test Directives204327 49513 Node: Directives204854 49514 Node: Selectors215164 49515 Node: Effective-Target Keywords216522 49516 Ref: arm_neon_ok224081 49517 Ref: arm_neonv2_ok224239 49518 Ref: arm_neon_fp16_ok224411 49519 Node: Add Options234782 49520 Node: Require Support235979 49521 Node: Final Actions238486 49522 Node: Ada Tests243653 49523 Node: C Tests244985 49524 Node: libgcj Tests249408 49525 Node: LTO Testing250535 49526 Node: gcov Testing252182 49527 Node: profopt Testing255169 49528 Node: compat Testing256884 49529 Node: Torture Tests261124 49530 Node: Options262741 49531 Node: Option file format263181 49532 Node: Option properties270171 49533 Node: Passes283050 49534 Node: Parsing pass283794 49535 Node: Gimplification pass287324 49536 Node: Pass manager289157 49537 Node: Tree SSA passes290951 49538 Node: RTL passes313423 49539 Node: RTL326554 49540 Node: RTL Objects328742 49541 Node: RTL Classes332616 49542 Node: Accessors337614 49543 Node: Special Accessors340008 49544 Node: Flags345778 49545 Node: Machine Modes360502 49546 Node: Constants372814 49547 Node: Regs and Memory379544 49548 Node: Arithmetic397445 49549 Node: Comparisons407535 49550 Node: Bit-Fields411827 49551 Node: Vector Operations413379 49552 Node: Conversions415261 49553 Node: RTL Declarations419759 49554 Node: Side Effects420580 49555 Node: Incdec437180 49556 Node: Assembler440515 49557 Node: Debug Information442060 49558 Node: Insns443258 49559 Node: Calls469752 49560 Node: Sharing472345 49561 Node: Reading RTL475455 49562 Node: GENERIC476447 49563 Node: Deficiencies478320 49564 Node: Tree overview478561 49565 Node: Macros and Functions482688 49566 Node: Identifiers483513 49567 Node: Containers485124 49568 Node: Types486281 49569 Node: Declarations498377 49570 Node: Working with declarations498872 49571 Node: Internal structure504478 49572 Node: Current structure hierarchy504862 49573 Node: Adding new DECL node types506956 49574 Node: Attributes511029 49575 Node: Expression trees512274 49576 Node: Constant expressions514027 49577 Node: Storage References518246 49578 Node: Unary and Binary Expressions521765 49579 Node: Vectors541627 49580 Node: Statements546354 49581 Node: Basic Statements546874 49582 Node: Blocks551381 49583 Node: Statement Sequences552785 49584 Node: Empty Statements553118 49585 Node: Jumps553692 49586 Node: Cleanups554345 49587 Node: OpenMP556113 49588 Node: Functions561953 49589 Node: Function Basics562424 49590 Node: Function Properties566109 49591 Node: Language-dependent trees568891 49592 Node: C and C++ Trees569777 49593 Node: Types for C++572681 49594 Node: Namespaces577659 49595 Node: Classes580766 49596 Node: Functions for C++585844 49597 Node: Statements for C++592097 49598 Node: C++ Expressions600145 49599 Node: Java Trees601646 49600 Node: GIMPLE601759 49601 Node: Tuple representation605380 49602 Node: GIMPLE instruction set613656 49603 Node: GIMPLE Exception Handling615324 49604 Node: Temporaries617238 49605 Ref: Temporaries-Footnote-1618553 49606 Node: Operands618616 49607 Node: Compound Expressions619378 49608 Node: Compound Lvalues619612 49609 Node: Conditional Expressions620374 49610 Node: Logical Operators621032 49611 Node: Manipulating GIMPLE statements627789 49612 Node: Tuple specific accessors633723 49613 Node: `GIMPLE_ASM'634542 49614 Node: `GIMPLE_ASSIGN'637175 49615 Node: `GIMPLE_BIND'641281 49616 Node: `GIMPLE_CALL'643088 49617 Node: `GIMPLE_CATCH'647358 49618 Node: `GIMPLE_COND'648502 49619 Node: `GIMPLE_DEBUG'651290 49620 Node: `GIMPLE_EH_FILTER'654673 49621 Node: `GIMPLE_LABEL'656161 49622 Node: `GIMPLE_NOP'657136 49623 Node: `GIMPLE_OMP_ATOMIC_LOAD'657505 49624 Node: `GIMPLE_OMP_ATOMIC_STORE'658415 49625 Node: `GIMPLE_OMP_CONTINUE'659054 49626 Node: `GIMPLE_OMP_CRITICAL'660404 49627 Node: `GIMPLE_OMP_FOR'661341 49628 Node: `GIMPLE_OMP_MASTER'664856 49629 Node: `GIMPLE_OMP_ORDERED'665239 49630 Node: `GIMPLE_OMP_PARALLEL'665639 49631 Node: `GIMPLE_OMP_RETURN'668411 49632 Node: `GIMPLE_OMP_SECTION'669061 49633 Node: `GIMPLE_OMP_SECTIONS'669727 49634 Node: `GIMPLE_OMP_SINGLE'671333 49635 Node: `GIMPLE_PHI'672270 49636 Node: `GIMPLE_RESX'673556 49637 Node: `GIMPLE_RETURN'674275 49638 Node: `GIMPLE_SWITCH'674843 49639 Node: `GIMPLE_TRY'676643 49640 Node: `GIMPLE_WITH_CLEANUP_EXPR'678433 49641 Node: GIMPLE sequences679316 49642 Node: Sequence iterators682522 49643 Node: Adding a new GIMPLE statement code690978 49644 Node: Statement and operand traversals692254 49645 Node: Tree SSA694854 49646 Node: Annotations696640 49647 Node: SSA Operands697166 49648 Node: SSA711697 49649 Node: Alias analysis723817 49650 Node: Memory model727597 49651 Node: Loop Analysis and Representation728960 49652 Node: Loop representation730141 49653 Node: Loop querying737061 49654 Node: Loop manipulation739894 49655 Node: LCSSA742262 49656 Node: Scalar evolutions744334 49657 Node: loop-iv747578 49658 Node: Number of iterations749504 49659 Node: Dependency analysis752313 49660 Node: Lambda758681 49661 Node: Omega760352 49662 Node: Control Flow761917 49663 Node: Basic Blocks763683 49664 Node: Edges768974 49665 Node: Profile information777606 49666 Node: Maintaining the CFG782290 49667 Node: Liveness information788152 49668 Node: Machine Desc790278 49669 Node: Overview792841 49670 Node: Patterns794882 49671 Node: Example798320 49672 Node: RTL Template799755 49673 Node: Output Template810410 49674 Node: Output Statement814375 49675 Node: Predicates818714 49676 Node: Machine-Independent Predicates821632 49677 Node: Defining Predicates826577 49678 Node: Constraints832542 49679 Node: Simple Constraints834024 49680 Node: Multi-Alternative846880 49681 Node: Class Preferences849721 49682 Node: Modifiers850613 49683 Node: Machine Constraints854859 49684 Node: Disable Insn Alternatives906168 49685 Node: Define Constraints909070 49686 Node: C Constraint Interface915857 49687 Node: Standard Names919498 49688 Ref: shift patterns942049 49689 Ref: prologue instruction pattern986989 49690 Ref: window_save instruction pattern987482 49691 Ref: epilogue instruction pattern987757 49692 Node: Pattern Ordering1005328 49693 Node: Dependent Patterns1006564 49694 Node: Jump Patterns1008184 49695 Ref: Jump Patterns-Footnote-11010328 49696 Node: Looping Patterns1010374 49697 Node: Insn Canonicalizations1015102 49698 Node: Expander Definitions1019693 49699 Node: Insn Splitting1027905 49700 Node: Including Patterns1037507 49701 Node: Peephole Definitions1039287 49702 Node: define_peephole1040540 49703 Node: define_peephole21046871 49704 Node: Insn Attributes1049938 49705 Node: Defining Attributes1051044 49706 Ref: define_enum_attr1054255 49707 Node: Expressions1055290 49708 Node: Tagging Insns1062039 49709 Node: Attr Example1066392 49710 Node: Insn Lengths1068766 49711 Node: Constant Attributes1071825 49712 Node: Delay Slots1072994 49713 Node: Processor pipeline description1076218 49714 Ref: Processor pipeline description-Footnote-11095031 49715 Node: Conditional Execution1095353 49716 Node: Define Subst1098415 49717 Node: Define Subst Example1100449 49718 Node: Define Subst Pattern Matching1103443 49719 Node: Define Subst Output Template1104668 49720 Node: Constant Definitions1106738 49721 Ref: define_enum1110520 49722 Node: Iterators1111008 49723 Node: Mode Iterators1111586 49724 Node: Defining Mode Iterators1112564 49725 Node: Substitutions1114058 49726 Node: Examples1116299 49727 Node: Code Iterators1117747 49728 Node: Int Iterators1120026 49729 Node: Subst Iterators1122484 49730 Node: Target Macros1124176 49731 Node: Target Structure1127264 49732 Node: Driver1129379 49733 Node: Run-time Target1148162 49734 Node: Per-Function Data1157315 49735 Node: Storage Layout1160080 49736 Node: Type Layout1186155 49737 Node: Registers1201482 49738 Node: Register Basics1202456 49739 Node: Allocation Order1207961 49740 Node: Values in Registers1210407 49741 Node: Leaf Functions1217896 49742 Node: Stack Registers1220754 49743 Node: Register Classes1222026 49744 Node: Old Constraints1252031 49745 Node: Stack and Calling1259183 49746 Node: Frame Layout1259717 49747 Node: Exception Handling1270597 49748 Node: Stack Checking1276819 49749 Node: Frame Registers1281632 49750 Node: Elimination1289891 49751 Node: Stack Arguments1294120 49752 Node: Register Arguments1300982 49753 Node: Scalar Return1321298 49754 Node: Aggregate Return1327384 49755 Node: Caller Saves1331594 49756 Node: Function Entry1332772 49757 Node: Profiling1343876 49758 Node: Tail Calls1345575 49759 Node: Stack Smashing Protection1347478 49760 Node: Varargs1349106 49761 Node: Trampolines1355802 49762 Node: Library Calls1361845 49763 Node: Addressing Modes1366784 49764 Node: Anchored Addresses1386818 49765 Node: Condition Code1389467 49766 Node: CC0 Condition Codes1391596 49767 Node: MODE_CC Condition Codes1394842 49768 Node: Cond Exec Macros1401363 49769 Node: Costs1401709 49770 Node: Scheduling1418178 49771 Node: Sections1437584 49772 Node: PIC1453282 49773 Node: Assembler Format1455342 49774 Node: File Framework1456480 49775 Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1463421 49776 Node: Data Output1466686 49777 Node: Uninitialized Data1474462 49778 Node: Label Output1479473 49779 Node: Initialization1502441 49780 Node: Macros for Initialization1508403 49781 Node: Instruction Output1515126 49782 Node: Dispatch Tables1525628 49783 Node: Exception Region Output1530006 49784 Node: Alignment Output1536689 49785 Node: Debugging Info1541234 49786 Node: All Debuggers1541904 49787 Node: DBX Options1544759 49788 Node: DBX Hooks1550208 49789 Node: File Names and DBX1551517 49790 Node: SDB and DWARF1553629 49791 Node: VMS Debug1559701 49792 Node: Floating Point1560288 49793 Node: Mode Switching1564764 49794 Node: Target Attributes1568760 49795 Node: Emulated TLS1577074 49796 Node: MIPS Coprocessors1580464 49797 Node: PCH Target1581761 49798 Node: C++ ABI1583603 49799 Node: Named Address Spaces1588395 49800 Node: Misc1593334 49801 Ref: TARGET_SHIFT_TRUNCATION_MASK1600076 49802 Node: Host Config1645242 49803 Node: Host Common1646310 49804 Node: Filesystem1648689 49805 Node: Host Misc1652804 49806 Node: Fragments1655253 49807 Node: Target Fragment1656448 49808 Node: Host Fragment1667081 49809 Node: Collect21667321 49810 Node: Header Dirs1669957 49811 Node: Type Information1671380 49812 Node: GTY Options1674603 49813 Node: User GC1688924 49814 Node: GGC Roots1692651 49815 Node: Files1693367 49816 Node: Invoking the garbage collector1696074 49817 Node: Troubleshooting1697577 49818 Node: Plugins1698653 49819 Node: Plugins loading1699771 49820 Node: Plugin API1700640 49821 Node: Plugins pass1707669 49822 Node: Plugins GC1709638 49823 Node: Plugins description1711298 49824 Node: Plugins attr1711833 49825 Node: Plugins recording1713718 49826 Node: Plugins gate1714568 49827 Node: Plugins tracking1715159 49828 Node: Plugins building1715747 49829 Node: LTO1717533 49830 Node: LTO Overview1718394 49831 Node: LTO object file layout1724226 49832 Node: IPA1728858 49833 Node: WHOPR1737823 49834 Node: Internal flags1742514 49835 Node: Funding1743726 49836 Node: GNU Project1746209 49837 Node: Copying1746858 49838 Node: GNU Free Documentation License1784389 49839 Node: Contributors1809529 49840 Node: Option Index1846934 49841 Node: Concept Index1847738 49842 49843 End Tag Table 49844
