1This is gccint.info, produced by makeinfo version 6.5 from gccint.texi. 2 3Copyright (C) 1988-2020 Free Software Foundation, Inc. 4 5 Permission is granted to copy, distribute and/or modify this document 6under the terms of the GNU Free Documentation License, Version 1.3 or 7any later version published by the Free Software Foundation; with the 8Invariant Sections being "Funding Free Software", the Front-Cover Texts 9being (a) (see below), and with the Back-Cover Texts being (b) (see 10below). A copy of the license is included in the section entitled "GNU 11Free Documentation License". 12 13 (a) The FSF's Front-Cover Text is: 14 15 A GNU Manual 16 17 (b) The FSF's Back-Cover Text is: 18 19 You have freedom to copy and modify this GNU Manual, like GNU software. 20Copies published by the Free Software Foundation raise funds for GNU 21development. 22INFO-DIR-SECTION Software development 23START-INFO-DIR-ENTRY 24* gccint: (gccint). Internals of the GNU Compiler Collection. 25END-INFO-DIR-ENTRY 26 27 This file documents the internals of the GNU compilers. 28 29 Copyright (C) 1988-2020 Free Software Foundation, Inc. 30 31 Permission is granted to copy, distribute and/or modify this document 32under the terms of the GNU Free Documentation License, Version 1.3 or 33any later version published by the Free Software Foundation; with the 34Invariant Sections being "Funding Free Software", the Front-Cover Texts 35being (a) (see below), and with the Back-Cover Texts being (b) (see 36below). A copy of the license is included in the section entitled "GNU 37Free Documentation License". 38 39 (a) The FSF's Front-Cover Text is: 40 41 A GNU Manual 42 43 (b) The FSF's Back-Cover Text is: 44 45 You have freedom to copy and modify this GNU Manual, like GNU software. 46Copies published by the Free Software Foundation raise funds for GNU 47development. 48 49 50File: gccint.info, Node: Top, Next: Contributing 51 52Introduction 53************ 54 55This manual documents the internals of the GNU compilers, including how 56to port them to new targets and some information about how to write 57front ends for new languages. It corresponds to the compilers (GCC) 58version 10.3.0. The use of the GNU compilers is documented in a 59separate manual. *Note Introduction: (gcc)Top. 60 61 This manual is mainly a reference manual rather than a tutorial. It 62discusses how to contribute to GCC (*note Contributing::), the 63characteristics of the machines supported by GCC as hosts and targets 64(*note Portability::), how GCC relates to the ABIs on such systems 65(*note Interface::), and the characteristics of the languages for which 66GCC front ends are written (*note Languages::). It then describes the 67GCC source tree structure and build system, some of the interfaces to 68GCC front ends, and how support for a target system is implemented in 69GCC. 70 71 Additional tutorial information is linked to from 72<http://gcc.gnu.org/readings.html>. 73 74* Menu: 75 76* Contributing:: How to contribute to testing and developing GCC. 77* Portability:: Goals of GCC's portability features. 78* Interface:: Function-call interface of GCC output. 79* Libgcc:: Low-level runtime library used by GCC. 80* Languages:: Languages for which GCC front ends are written. 81* Source Tree:: GCC source tree structure and build system. 82* Testsuites:: GCC testsuites. 83* Options:: Option specification files. 84* Passes:: Order of passes, what they do, and what each file is for. 85* poly_int:: Representation of runtime sizes and offsets. 86* GENERIC:: Language-independent representation generated by Front Ends 87* GIMPLE:: Tuple representation used by Tree SSA optimizers 88* Tree SSA:: Analysis and optimization of GIMPLE 89* RTL:: Machine-dependent low-level intermediate representation. 90* Control Flow:: Maintaining and manipulating the control flow graph. 91* Loop Analysis and Representation:: Analysis and representation of loops 92* Machine Desc:: How to write machine description instruction patterns. 93* Target Macros:: How to write the machine description C macros and functions. 94* Host Config:: Writing the 'xm-MACHINE.h' file. 95* Fragments:: Writing the 't-TARGET' and 'x-HOST' files. 96* Collect2:: How 'collect2' works; how it finds 'ld'. 97* Header Dirs:: Understanding the standard header file directories. 98* Type Information:: GCC's memory management; generating type information. 99* Plugins:: Extending the compiler with plugins. 100* LTO:: Using Link-Time Optimization. 101 102* Match and Simplify:: How to write expression simplification patterns for GIMPLE and GENERIC 103* Static Analyzer:: Working with the static analyzer. 104* User Experience Guidelines:: Guidelines for implementing diagnostics and options. 105* Funding:: How to help assure funding for free software. 106* GNU Project:: The GNU Project and GNU/Linux. 107 108* Copying:: GNU General Public License says 109 how you can copy and share GCC. 110* GNU Free Documentation License:: How you can copy and share this manual. 111* Contributors:: People who have contributed to GCC. 112 113* Option Index:: Index to command line options. 114* Concept Index:: Index of concepts and symbol names. 115 116 117File: gccint.info, Node: Contributing, Next: Portability, Up: Top 118 1191 Contributing to GCC Development 120********************************* 121 122If you would like to help pretest GCC releases to assure they work well, 123current development sources are available via Git (see 124<http://gcc.gnu.org/git.html>). Source and binary snapshots are also 125available for FTP; see <http://gcc.gnu.org/snapshots.html>. 126 127 If you would like to work on improvements to GCC, please read the 128advice at these URLs: 129 130 <http://gcc.gnu.org/contribute.html> 131 <http://gcc.gnu.org/contributewhy.html> 132 133for information on how to make useful contributions and avoid 134duplication of effort. Suggested projects are listed at 135<http://gcc.gnu.org/projects/>. 136 137 138File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top 139 1402 GCC and Portability 141********************* 142 143GCC itself aims to be portable to any machine where 'int' is at least a 14432-bit type. It aims to target machines with a flat (non-segmented) 145byte addressed data address space (the code address space can be 146separate). Target ABIs may have 8, 16, 32 or 64-bit 'int' type. 'char' 147can be wider than 8 bits. 148 149 GCC gets most of the information about the target machine from a 150machine description which gives an algebraic formula for each of the 151machine's instructions. This is a very clean way to describe the 152target. But when the compiler needs information that is difficult to 153express in this fashion, ad-hoc parameters have been defined for machine 154descriptions. The purpose of portability is to reduce the total work 155needed on the compiler; it was not of interest for its own sake. 156 157 GCC does not contain machine dependent code, but it does contain code 158that depends on machine parameters such as endianness (whether the most 159significant byte has the highest or lowest address of the bytes in a 160word) and the availability of autoincrement addressing. In the 161RTL-generation pass, it is often necessary to have multiple strategies 162for generating code for a particular kind of syntax tree, strategies 163that are usable for different combinations of parameters. Often, not 164all possible cases have been addressed, but only the common ones or only 165the ones that have been encountered. As a result, a new target may 166require additional strategies. You will know if this happens because 167the compiler will call 'abort'. Fortunately, the new strategies can be 168added in a machine-independent fashion, and will affect only the target 169machines that need them. 170 171 172File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top 173 1743 Interfacing to GCC Output 175*************************** 176 177GCC is normally configured to use the same function calling convention 178normally in use on the target system. This is done with the 179machine-description macros described (*note Target Macros::). 180 181 However, returning of structure and union values is done differently on 182some target machines. As a result, functions compiled with PCC 183returning such types cannot be called from code compiled with GCC, and 184vice versa. This does not cause trouble often because few Unix library 185routines return structures or unions. 186 187 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes long 188in the same registers used for 'int' or 'double' return values. (GCC 189typically allocates variables of such types in registers also.) 190Structures and unions of other sizes are returned by storing them into 191an address passed by the caller (usually in a register). The target 192hook 'TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. 193 194 By contrast, PCC on most target machines returns structures and unions 195of any size by copying the data into an area of static storage, and then 196returning the address of that storage as if it were a pointer value. 197The caller must copy the data from that memory area to the place where 198the value is wanted. This is slower than the method used by GCC, and 199fails to be reentrant. 200 201 On some target machines, such as RISC machines and the 80386, the 202standard system convention is to pass to the subroutine the address of 203where to return the value. On these machines, GCC has been configured 204to be compatible with the standard compiler, when this method is used. 205It may not be compatible for structures of 1, 2, 4 or 8 bytes. 206 207 GCC uses the system's standard convention for passing arguments. On 208some machines, the first few arguments are passed in registers; in 209others, all are passed on the stack. It would be possible to use 210registers for argument passing on any machine, and this would probably 211result in a significant speedup. But the result would be complete 212incompatibility with code that follows the standard convention. So this 213change is practical only if you are switching to GCC as the sole C 214compiler for the system. We may implement register argument passing on 215certain machines once we have a complete GNU system so that we can 216compile the libraries with GCC. 217 218 On some machines (particularly the SPARC), certain types of arguments 219are passed "by invisible reference". This means that the value is 220stored in memory, and the address of the memory location is passed to 221the subroutine. 222 223 If you use 'longjmp', beware of automatic variables. ISO C says that 224automatic variables that are not declared 'volatile' have undefined 225values after a 'longjmp'. And this is all GCC promises to do, because 226it is very difficult to restore register variables correctly, and one of 227GCC's features is that it can put variables in registers without your 228asking it to. 229 230 231File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top 232 2334 The GCC low-level runtime library 234*********************************** 235 236GCC provides a low-level runtime library, 'libgcc.a' or 'libgcc_s.so.1' 237on some platforms. GCC generates calls to routines in this library 238automatically, whenever it needs to perform some operation that is too 239complicated to emit inline code for. 240 241 Most of the routines in 'libgcc' handle arithmetic operations that the 242target processor cannot perform directly. This includes integer 243multiply and divide on some machines, and all floating-point and 244fixed-point operations on other machines. 'libgcc' also includes 245routines for exception handling, and a handful of miscellaneous 246operations. 247 248 Some of these routines can be defined in mostly machine-independent C. 249Others must be hand-written in assembly language for each processor that 250needs them. 251 252 GCC will also generate calls to C library routines, such as 'memcpy' 253and 'memset', in some cases. The set of routines that GCC may possibly 254use is documented in *note (gcc)Other Builtins::. 255 256 These routines take arguments and return values of a specific machine 257mode, not a specific C type. *Note Machine Modes::, for an explanation 258of this concept. For illustrative purposes, in this chapter the 259floating point type 'float' is assumed to correspond to 'SFmode'; 260'double' to 'DFmode'; and 'long double' to both 'TFmode' and 'XFmode'. 261Similarly, the integer types 'int' and 'unsigned int' correspond to 262'SImode'; 'long' and 'unsigned long' to 'DImode'; and 'long long' and 263'unsigned long long' to 'TImode'. 264 265* Menu: 266 267* Integer library routines:: 268* Soft float library routines:: 269* Decimal float library routines:: 270* Fixed-point fractional library routines:: 271* Exception handling routines:: 272* Miscellaneous routines:: 273 274 275File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc 276 2774.1 Routines for integer arithmetic 278=================================== 279 280The integer arithmetic routines are used on platforms that don't provide 281hardware support for arithmetic operations on some modes. 282 2834.1.1 Arithmetic functions 284-------------------------- 285 286 -- Runtime Function: int __ashlsi3 (int A, int B) 287 -- Runtime Function: long __ashldi3 (long A, int B) 288 -- Runtime Function: long long __ashlti3 (long long A, int B) 289 These functions return the result of shifting A left by B bits. 290 291 -- Runtime Function: int __ashrsi3 (int A, int B) 292 -- Runtime Function: long __ashrdi3 (long A, int B) 293 -- Runtime Function: long long __ashrti3 (long long A, int B) 294 These functions return the result of arithmetically shifting A 295 right by B bits. 296 297 -- Runtime Function: int __divsi3 (int A, int B) 298 -- Runtime Function: long __divdi3 (long A, long B) 299 -- Runtime Function: long long __divti3 (long long A, long long B) 300 These functions return the quotient of the signed division of A and 301 B. 302 303 -- Runtime Function: int __lshrsi3 (int A, int B) 304 -- Runtime Function: long __lshrdi3 (long A, int B) 305 -- Runtime Function: long long __lshrti3 (long long A, int B) 306 These functions return the result of logically shifting A right by 307 B bits. 308 309 -- Runtime Function: int __modsi3 (int A, int B) 310 -- Runtime Function: long __moddi3 (long A, long B) 311 -- Runtime Function: long long __modti3 (long long A, long long B) 312 These functions return the remainder of the signed division of A 313 and B. 314 315 -- Runtime Function: int __mulsi3 (int A, int B) 316 -- Runtime Function: long __muldi3 (long A, long B) 317 -- Runtime Function: long long __multi3 (long long A, long long B) 318 These functions return the product of A and B. 319 320 -- Runtime Function: long __negdi2 (long A) 321 -- Runtime Function: long long __negti2 (long long A) 322 These functions return the negation of A. 323 324 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned 325 int B) 326 -- Runtime Function: unsigned long __udivdi3 (unsigned long A, unsigned 327 long B) 328 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 329 A, unsigned long long B) 330 These functions return the quotient of the unsigned division of A 331 and B. 332 333 -- Runtime Function: unsigned long __udivmoddi4 (unsigned long A, 334 unsigned long B, unsigned long *C) 335 -- Runtime Function: unsigned long long __udivmodti4 (unsigned long 336 long A, unsigned long long B, unsigned long long *C) 337 These functions calculate both the quotient and remainder of the 338 unsigned division of A and B. The return value is the quotient, 339 and the remainder is placed in variable pointed to by C. 340 341 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned 342 int B) 343 -- Runtime Function: unsigned long __umoddi3 (unsigned long A, unsigned 344 long B) 345 -- Runtime Function: unsigned long long __umodti3 (unsigned long long 346 A, unsigned long long B) 347 These functions return the remainder of the unsigned division of A 348 and B. 349 3504.1.2 Comparison functions 351-------------------------- 352 353The following functions implement integral comparisons. These functions 354implement a low-level compare, upon which the higher level comparison 355operators (such as less than and greater than or equal to) can be 356constructed. The returned values lie in the range zero to two, to allow 357the high-level operators to be implemented by testing the returned 358result using either signed or unsigned comparison. 359 360 -- Runtime Function: int __cmpdi2 (long A, long B) 361 -- Runtime Function: int __cmpti2 (long long A, long long B) 362 These functions perform a signed comparison of A and B. If A is 363 less than B, they return 0; if A is greater than B, they return 2; 364 and if A and B are equal they return 1. 365 366 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B) 367 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned long 368 long B) 369 These functions perform an unsigned comparison of A and B. If A is 370 less than B, they return 0; if A is greater than B, they return 2; 371 and if A and B are equal they return 1. 372 3734.1.3 Trapping arithmetic functions 374----------------------------------- 375 376The following functions implement trapping arithmetic. These functions 377call the libc function 'abort' upon signed arithmetic overflow. 378 379 -- Runtime Function: int __absvsi2 (int A) 380 -- Runtime Function: long __absvdi2 (long A) 381 These functions return the absolute value of A. 382 383 -- Runtime Function: int __addvsi3 (int A, int B) 384 -- Runtime Function: long __addvdi3 (long A, long B) 385 These functions return the sum of A and B; that is 'A + B'. 386 387 -- Runtime Function: int __mulvsi3 (int A, int B) 388 -- Runtime Function: long __mulvdi3 (long A, long B) 389 The functions return the product of A and B; that is 'A * B'. 390 391 -- Runtime Function: int __negvsi2 (int A) 392 -- Runtime Function: long __negvdi2 (long A) 393 These functions return the negation of A; that is '-A'. 394 395 -- Runtime Function: int __subvsi3 (int A, int B) 396 -- Runtime Function: long __subvdi3 (long A, long B) 397 These functions return the difference between B and A; that is 'A - 398 B'. 399 4004.1.4 Bit operations 401-------------------- 402 403 -- Runtime Function: int __clzsi2 (unsigned int A) 404 -- Runtime Function: int __clzdi2 (unsigned long A) 405 -- Runtime Function: int __clzti2 (unsigned long long A) 406 These functions return the number of leading 0-bits in A, starting 407 at the most significant bit position. If A is zero, the result is 408 undefined. 409 410 -- Runtime Function: int __ctzsi2 (unsigned int A) 411 -- Runtime Function: int __ctzdi2 (unsigned long A) 412 -- Runtime Function: int __ctzti2 (unsigned long long A) 413 These functions return the number of trailing 0-bits in A, starting 414 at the least significant bit position. If A is zero, the result is 415 undefined. 416 417 -- Runtime Function: int __ffsdi2 (unsigned long A) 418 -- Runtime Function: int __ffsti2 (unsigned long long A) 419 These functions return the index of the least significant 1-bit in 420 A, or the value zero if A is zero. The least significant bit is 421 index one. 422 423 -- Runtime Function: int __paritysi2 (unsigned int A) 424 -- Runtime Function: int __paritydi2 (unsigned long A) 425 -- Runtime Function: int __parityti2 (unsigned long long A) 426 These functions return the value zero if the number of bits set in 427 A is even, and the value one otherwise. 428 429 -- Runtime Function: int __popcountsi2 (unsigned int A) 430 -- Runtime Function: int __popcountdi2 (unsigned long A) 431 -- Runtime Function: int __popcountti2 (unsigned long long A) 432 These functions return the number of bits set in A. 433 434 -- Runtime Function: int32_t __bswapsi2 (int32_t A) 435 -- Runtime Function: int64_t __bswapdi2 (int64_t A) 436 These functions return the A byteswapped. 437 438 439File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc 440 4414.2 Routines for floating point emulation 442========================================= 443 444The software floating point library is used on machines which do not 445have hardware support for floating point. It is also used whenever 446'-msoft-float' is used to disable generation of floating point 447instructions. (Not all targets support this switch.) 448 449 For compatibility with other compilers, the floating point emulation 450routines can be renamed with the 'DECLARE_LIBRARY_RENAMES' macro (*note 451Library Calls::). In this section, the default names are used. 452 453 Presently the library does not support 'XFmode', which is used for 454'long double' on some architectures. 455 4564.2.1 Arithmetic functions 457-------------------------- 458 459 -- Runtime Function: float __addsf3 (float A, float B) 460 -- Runtime Function: double __adddf3 (double A, double B) 461 -- Runtime Function: long double __addtf3 (long double A, long double 462 B) 463 -- Runtime Function: long double __addxf3 (long double A, long double 464 B) 465 These functions return the sum of A and B. 466 467 -- Runtime Function: float __subsf3 (float A, float B) 468 -- Runtime Function: double __subdf3 (double A, double B) 469 -- Runtime Function: long double __subtf3 (long double A, long double 470 B) 471 -- Runtime Function: long double __subxf3 (long double A, long double 472 B) 473 These functions return the difference between B and A; that is, 474 A - B. 475 476 -- Runtime Function: float __mulsf3 (float A, float B) 477 -- Runtime Function: double __muldf3 (double A, double B) 478 -- Runtime Function: long double __multf3 (long double A, long double 479 B) 480 -- Runtime Function: long double __mulxf3 (long double A, long double 481 B) 482 These functions return the product of A and B. 483 484 -- Runtime Function: float __divsf3 (float A, float B) 485 -- Runtime Function: double __divdf3 (double A, double B) 486 -- Runtime Function: long double __divtf3 (long double A, long double 487 B) 488 -- Runtime Function: long double __divxf3 (long double A, long double 489 B) 490 These functions return the quotient of A and B; that is, A / B. 491 492 -- Runtime Function: float __negsf2 (float A) 493 -- Runtime Function: double __negdf2 (double A) 494 -- Runtime Function: long double __negtf2 (long double A) 495 -- Runtime Function: long double __negxf2 (long double A) 496 These functions return the negation of A. They simply flip the 497 sign bit, so they can produce negative zero and negative NaN. 498 4994.2.2 Conversion functions 500-------------------------- 501 502 -- Runtime Function: double __extendsfdf2 (float A) 503 -- Runtime Function: long double __extendsftf2 (float A) 504 -- Runtime Function: long double __extendsfxf2 (float A) 505 -- Runtime Function: long double __extenddftf2 (double A) 506 -- Runtime Function: long double __extenddfxf2 (double A) 507 These functions extend A to the wider mode of their return type. 508 509 -- Runtime Function: double __truncxfdf2 (long double A) 510 -- Runtime Function: double __trunctfdf2 (long double A) 511 -- Runtime Function: float __truncxfsf2 (long double A) 512 -- Runtime Function: float __trunctfsf2 (long double A) 513 -- Runtime Function: float __truncdfsf2 (double A) 514 These functions truncate A to the narrower mode of their return 515 type, rounding toward zero. 516 517 -- Runtime Function: int __fixsfsi (float A) 518 -- Runtime Function: int __fixdfsi (double A) 519 -- Runtime Function: int __fixtfsi (long double A) 520 -- Runtime Function: int __fixxfsi (long double A) 521 These functions convert A to a signed integer, rounding toward 522 zero. 523 524 -- Runtime Function: long __fixsfdi (float A) 525 -- Runtime Function: long __fixdfdi (double A) 526 -- Runtime Function: long __fixtfdi (long double A) 527 -- Runtime Function: long __fixxfdi (long double A) 528 These functions convert A to a signed long, rounding toward zero. 529 530 -- Runtime Function: long long __fixsfti (float A) 531 -- Runtime Function: long long __fixdfti (double A) 532 -- Runtime Function: long long __fixtfti (long double A) 533 -- Runtime Function: long long __fixxfti (long double A) 534 These functions convert A to a signed long long, rounding toward 535 zero. 536 537 -- Runtime Function: unsigned int __fixunssfsi (float A) 538 -- Runtime Function: unsigned int __fixunsdfsi (double A) 539 -- Runtime Function: unsigned int __fixunstfsi (long double A) 540 -- Runtime Function: unsigned int __fixunsxfsi (long double A) 541 These functions convert A to an unsigned integer, rounding toward 542 zero. Negative values all become zero. 543 544 -- Runtime Function: unsigned long __fixunssfdi (float A) 545 -- Runtime Function: unsigned long __fixunsdfdi (double A) 546 -- Runtime Function: unsigned long __fixunstfdi (long double A) 547 -- Runtime Function: unsigned long __fixunsxfdi (long double A) 548 These functions convert A to an unsigned long, rounding toward 549 zero. Negative values all become zero. 550 551 -- Runtime Function: unsigned long long __fixunssfti (float A) 552 -- Runtime Function: unsigned long long __fixunsdfti (double A) 553 -- Runtime Function: unsigned long long __fixunstfti (long double A) 554 -- Runtime Function: unsigned long long __fixunsxfti (long double A) 555 These functions convert A to an unsigned long long, rounding toward 556 zero. Negative values all become zero. 557 558 -- Runtime Function: float __floatsisf (int I) 559 -- Runtime Function: double __floatsidf (int I) 560 -- Runtime Function: long double __floatsitf (int I) 561 -- Runtime Function: long double __floatsixf (int I) 562 These functions convert I, a signed integer, to floating point. 563 564 -- Runtime Function: float __floatdisf (long I) 565 -- Runtime Function: double __floatdidf (long I) 566 -- Runtime Function: long double __floatditf (long I) 567 -- Runtime Function: long double __floatdixf (long I) 568 These functions convert I, a signed long, to floating point. 569 570 -- Runtime Function: float __floattisf (long long I) 571 -- Runtime Function: double __floattidf (long long I) 572 -- Runtime Function: long double __floattitf (long long I) 573 -- Runtime Function: long double __floattixf (long long I) 574 These functions convert I, a signed long long, to floating point. 575 576 -- Runtime Function: float __floatunsisf (unsigned int I) 577 -- Runtime Function: double __floatunsidf (unsigned int I) 578 -- Runtime Function: long double __floatunsitf (unsigned int I) 579 -- Runtime Function: long double __floatunsixf (unsigned int I) 580 These functions convert I, an unsigned integer, to floating point. 581 582 -- Runtime Function: float __floatundisf (unsigned long I) 583 -- Runtime Function: double __floatundidf (unsigned long I) 584 -- Runtime Function: long double __floatunditf (unsigned long I) 585 -- Runtime Function: long double __floatundixf (unsigned long I) 586 These functions convert I, an unsigned long, to floating point. 587 588 -- Runtime Function: float __floatuntisf (unsigned long long I) 589 -- Runtime Function: double __floatuntidf (unsigned long long I) 590 -- Runtime Function: long double __floatuntitf (unsigned long long I) 591 -- Runtime Function: long double __floatuntixf (unsigned long long I) 592 These functions convert I, an unsigned long long, to floating 593 point. 594 5954.2.3 Comparison functions 596-------------------------- 597 598There are two sets of basic comparison functions. 599 600 -- Runtime Function: int __cmpsf2 (float A, float B) 601 -- Runtime Function: int __cmpdf2 (double A, double B) 602 -- Runtime Function: int __cmptf2 (long double A, long double B) 603 These functions calculate a <=> b. That is, if A is less than B, 604 they return -1; if A is greater than B, they return 1; and if A and 605 B are equal they return 0. If either argument is NaN they return 606 1, but you should not rely on this; if NaN is a possibility, use 607 one of the higher-level comparison functions. 608 609 -- Runtime Function: int __unordsf2 (float A, float B) 610 -- Runtime Function: int __unorddf2 (double A, double B) 611 -- Runtime Function: int __unordtf2 (long double A, long double B) 612 These functions return a nonzero value if either argument is NaN, 613 otherwise 0. 614 615 There is also a complete group of higher level functions which 616correspond directly to comparison operators. They implement the ISO C 617semantics for floating-point comparisons, taking NaN into account. Pay 618careful attention to the return values defined for each set. Under the 619hood, all of these routines are implemented as 620 621 if (__unordXf2 (a, b)) 622 return E; 623 return __cmpXf2 (a, b); 624 625where E is a constant chosen to give the proper behavior for NaN. Thus, 626the meaning of the return value is different for each set. Do not rely 627on this implementation; only the semantics documented below are 628guaranteed. 629 630 -- Runtime Function: int __eqsf2 (float A, float B) 631 -- Runtime Function: int __eqdf2 (double A, double B) 632 -- Runtime Function: int __eqtf2 (long double A, long double B) 633 These functions return zero if neither argument is NaN, and A and B 634 are equal. 635 636 -- Runtime Function: int __nesf2 (float A, float B) 637 -- Runtime Function: int __nedf2 (double A, double B) 638 -- Runtime Function: int __netf2 (long double A, long double B) 639 These functions return a nonzero value if either argument is NaN, 640 or if A and B are unequal. 641 642 -- Runtime Function: int __gesf2 (float A, float B) 643 -- Runtime Function: int __gedf2 (double A, double B) 644 -- Runtime Function: int __getf2 (long double A, long double B) 645 These functions return a value greater than or equal to zero if 646 neither argument is NaN, and A is greater than or equal to B. 647 648 -- Runtime Function: int __ltsf2 (float A, float B) 649 -- Runtime Function: int __ltdf2 (double A, double B) 650 -- Runtime Function: int __lttf2 (long double A, long double B) 651 These functions return a value less than zero if neither argument 652 is NaN, and A is strictly less than B. 653 654 -- Runtime Function: int __lesf2 (float A, float B) 655 -- Runtime Function: int __ledf2 (double A, double B) 656 -- Runtime Function: int __letf2 (long double A, long double B) 657 These functions return a value less than or equal to zero if 658 neither argument is NaN, and A is less than or equal to B. 659 660 -- Runtime Function: int __gtsf2 (float A, float B) 661 -- Runtime Function: int __gtdf2 (double A, double B) 662 -- Runtime Function: int __gttf2 (long double A, long double B) 663 These functions return a value greater than zero if neither 664 argument is NaN, and A is strictly greater than B. 665 6664.2.4 Other floating-point functions 667------------------------------------ 668 669 -- Runtime Function: float __powisf2 (float A, int B) 670 -- Runtime Function: double __powidf2 (double A, int B) 671 -- Runtime Function: long double __powitf2 (long double A, int B) 672 -- Runtime Function: long double __powixf2 (long double A, int B) 673 These functions convert raise A to the power B. 674 675 -- Runtime Function: complex float __mulsc3 (float A, float B, float C, 676 float D) 677 -- Runtime Function: complex double __muldc3 (double A, double B, 678 double C, double D) 679 -- Runtime Function: complex long double __multc3 (long double A, long 680 double B, long double C, long double D) 681 -- Runtime Function: complex long double __mulxc3 (long double A, long 682 double B, long double C, long double D) 683 These functions return the product of A + iB and C + iD, following 684 the rules of C99 Annex G. 685 686 -- Runtime Function: complex float __divsc3 (float A, float B, float C, 687 float D) 688 -- Runtime Function: complex double __divdc3 (double A, double B, 689 double C, double D) 690 -- Runtime Function: complex long double __divtc3 (long double A, long 691 double B, long double C, long double D) 692 -- Runtime Function: complex long double __divxc3 (long double A, long 693 double B, long double C, long double D) 694 These functions return the quotient of A + iB and C + iD (i.e., (A 695 + iB) / (C + iD)), following the rules of C99 Annex G. 696 697 698File: gccint.info, Node: Decimal float library routines, Next: Fixed-point fractional library routines, Prev: Soft float library routines, Up: Libgcc 699 7004.3 Routines for decimal floating point emulation 701================================================= 702 703The software decimal floating point library implements IEEE 754-2008 704decimal floating point arithmetic and is only activated on selected 705targets. 706 707 The software decimal floating point library supports either DPD 708(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as 709selected at configure time. 710 7114.3.1 Arithmetic functions 712-------------------------- 713 714 -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32 715 B) 716 -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32 717 B) 718 -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64 719 B) 720 -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64 721 B) 722 -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A, 723 _Decimal128 B) 724 -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A, 725 _Decimal128 B) 726 These functions return the sum of A and B. 727 728 -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32 729 B) 730 -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32 731 B) 732 -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64 733 B) 734 -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64 735 B) 736 -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A, 737 _Decimal128 B) 738 -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A, 739 _Decimal128 B) 740 These functions return the difference between B and A; that is, 741 A - B. 742 743 -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32 744 B) 745 -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32 746 B) 747 -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64 748 B) 749 -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64 750 B) 751 -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A, 752 _Decimal128 B) 753 -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A, 754 _Decimal128 B) 755 These functions return the product of A and B. 756 757 -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32 758 B) 759 -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32 760 B) 761 -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64 762 B) 763 -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64 764 B) 765 -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A, 766 _Decimal128 B) 767 -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A, 768 _Decimal128 B) 769 These functions return the quotient of A and B; that is, A / B. 770 771 -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A) 772 -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A) 773 -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A) 774 -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A) 775 -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A) 776 -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A) 777 These functions return the negation of A. They simply flip the 778 sign bit, so they can produce negative zero and negative NaN. 779 7804.3.2 Conversion functions 781-------------------------- 782 783 -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A) 784 -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A) 785 -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A) 786 -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A) 787 -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A) 788 -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A) 789 -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A) 790 -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A) 791 -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A) 792 -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A) 793 -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A) 794 -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A) 795 These functions convert the value A from one decimal floating type 796 to another. 797 798 -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A) 799 -- Runtime Function: _Decimal64 __bid_extendsfdd (float A) 800 -- Runtime Function: _Decimal128 __dpd_extendsftd (float A) 801 -- Runtime Function: _Decimal128 __bid_extendsftd (float A) 802 -- Runtime Function: _Decimal128 __dpd_extenddftd (double A) 803 -- Runtime Function: _Decimal128 __bid_extenddftd (double A) 804 -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A) 805 -- Runtime Function: _Decimal128 __bid_extendxftd (long double A) 806 -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A) 807 -- Runtime Function: _Decimal32 __bid_truncdfsd (double A) 808 -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A) 809 -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A) 810 -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A) 811 -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A) 812 -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A) 813 -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A) 814 -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A) 815 -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A) 816 These functions convert the value of A from a binary floating type 817 to a decimal floating type of a different size. 818 819 -- Runtime Function: float __dpd_truncddsf (_Decimal64 A) 820 -- Runtime Function: float __bid_truncddsf (_Decimal64 A) 821 -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A) 822 -- Runtime Function: float __bid_trunctdsf (_Decimal128 A) 823 -- Runtime Function: double __dpd_extendsddf (_Decimal32 A) 824 -- Runtime Function: double __bid_extendsddf (_Decimal32 A) 825 -- Runtime Function: double __dpd_trunctddf (_Decimal128 A) 826 -- Runtime Function: double __bid_trunctddf (_Decimal128 A) 827 -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A) 828 -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A) 829 -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A) 830 -- Runtime Function: long double __bid_extendddxf (_Decimal64 A) 831 -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A) 832 -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A) 833 -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A) 834 -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A) 835 -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A) 836 -- Runtime Function: long double __bid_extendddtf (_Decimal64 A) 837 These functions convert the value of A from a decimal floating type 838 to a binary floating type of a different size. 839 840 -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A) 841 -- Runtime Function: _Decimal32 __bid_extendsfsd (float A) 842 -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A) 843 -- Runtime Function: _Decimal64 __bid_extenddfdd (double A) 844 -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A) 845 -- Runtime Function: _Decimal128 __bid_extendtftd (long double A) 846 -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A) 847 -- Runtime Function: float __bid_truncsdsf (_Decimal32 A) 848 -- Runtime Function: double __dpd_truncdddf (_Decimal64 A) 849 -- Runtime Function: double __bid_truncdddf (_Decimal64 A) 850 -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A) 851 -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A) 852 These functions convert the value of A between decimal and binary 853 floating types of the same size. 854 855 -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A) 856 -- Runtime Function: int __bid_fixsdsi (_Decimal32 A) 857 -- Runtime Function: int __dpd_fixddsi (_Decimal64 A) 858 -- Runtime Function: int __bid_fixddsi (_Decimal64 A) 859 -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A) 860 -- Runtime Function: int __bid_fixtdsi (_Decimal128 A) 861 These functions convert A to a signed integer. 862 863 -- Runtime Function: long __dpd_fixsddi (_Decimal32 A) 864 -- Runtime Function: long __bid_fixsddi (_Decimal32 A) 865 -- Runtime Function: long __dpd_fixdddi (_Decimal64 A) 866 -- Runtime Function: long __bid_fixdddi (_Decimal64 A) 867 -- Runtime Function: long __dpd_fixtddi (_Decimal128 A) 868 -- Runtime Function: long __bid_fixtddi (_Decimal128 A) 869 These functions convert A to a signed long. 870 871 -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A) 872 -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A) 873 -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A) 874 -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A) 875 -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A) 876 -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A) 877 These functions convert A to an unsigned integer. Negative values 878 all become zero. 879 880 -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A) 881 -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A) 882 -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A) 883 -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A) 884 -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A) 885 -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A) 886 These functions convert A to an unsigned long. Negative values all 887 become zero. 888 889 -- Runtime Function: _Decimal32 __dpd_floatsisd (int I) 890 -- Runtime Function: _Decimal32 __bid_floatsisd (int I) 891 -- Runtime Function: _Decimal64 __dpd_floatsidd (int I) 892 -- Runtime Function: _Decimal64 __bid_floatsidd (int I) 893 -- Runtime Function: _Decimal128 __dpd_floatsitd (int I) 894 -- Runtime Function: _Decimal128 __bid_floatsitd (int I) 895 These functions convert I, a signed integer, to decimal floating 896 point. 897 898 -- Runtime Function: _Decimal32 __dpd_floatdisd (long I) 899 -- Runtime Function: _Decimal32 __bid_floatdisd (long I) 900 -- Runtime Function: _Decimal64 __dpd_floatdidd (long I) 901 -- Runtime Function: _Decimal64 __bid_floatdidd (long I) 902 -- Runtime Function: _Decimal128 __dpd_floatditd (long I) 903 -- Runtime Function: _Decimal128 __bid_floatditd (long I) 904 These functions convert I, a signed long, to decimal floating 905 point. 906 907 -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I) 908 -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I) 909 -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I) 910 -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I) 911 -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I) 912 -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I) 913 These functions convert I, an unsigned integer, to decimal floating 914 point. 915 916 -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I) 917 -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I) 918 -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I) 919 -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I) 920 -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I) 921 -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I) 922 These functions convert I, an unsigned long, to decimal floating 923 point. 924 9254.3.3 Comparison functions 926-------------------------- 927 928 -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B) 929 -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B) 930 -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B) 931 -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B) 932 -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B) 933 -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B) 934 These functions return a nonzero value if either argument is NaN, 935 otherwise 0. 936 937 There is also a complete group of higher level functions which 938correspond directly to comparison operators. They implement the ISO C 939semantics for floating-point comparisons, taking NaN into account. Pay 940careful attention to the return values defined for each set. Under the 941hood, all of these routines are implemented as 942 943 if (__bid_unordXd2 (a, b)) 944 return E; 945 return __bid_cmpXd2 (a, b); 946 947where E is a constant chosen to give the proper behavior for NaN. Thus, 948the meaning of the return value is different for each set. Do not rely 949on this implementation; only the semantics documented below are 950guaranteed. 951 952 -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B) 953 -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B) 954 -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B) 955 -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B) 956 -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B) 957 -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B) 958 These functions return zero if neither argument is NaN, and A and B 959 are equal. 960 961 -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B) 962 -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B) 963 -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B) 964 -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B) 965 -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B) 966 -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B) 967 These functions return a nonzero value if either argument is NaN, 968 or if A and B are unequal. 969 970 -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B) 971 -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B) 972 -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B) 973 -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B) 974 -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B) 975 -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B) 976 These functions return a value greater than or equal to zero if 977 neither argument is NaN, and A is greater than or equal to B. 978 979 -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B) 980 -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B) 981 -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B) 982 -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B) 983 -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B) 984 -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B) 985 These functions return a value less than zero if neither argument 986 is NaN, and A is strictly less than B. 987 988 -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B) 989 -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B) 990 -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B) 991 -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B) 992 -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B) 993 -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B) 994 These functions return a value less than or equal to zero if 995 neither argument is NaN, and A is less than or equal to B. 996 997 -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B) 998 -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B) 999 -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B) 1000 -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B) 1001 -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B) 1002 -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B) 1003 These functions return a value greater than zero if neither 1004 argument is NaN, and A is strictly greater than B. 1005 1006 1007File: gccint.info, Node: Fixed-point fractional library routines, Next: Exception handling routines, Prev: Decimal float library routines, Up: Libgcc 1008 10094.4 Routines for fixed-point fractional emulation 1010================================================= 1011 1012The software fixed-point library implements fixed-point fractional 1013arithmetic, and is only activated on selected targets. 1014 1015 For ease of comprehension 'fract' is an alias for the '_Fract' type, 1016'accum' an alias for '_Accum', and 'sat' an alias for '_Sat'. 1017 1018 For illustrative purposes, in this section the fixed-point fractional 1019type 'short fract' is assumed to correspond to machine mode 'QQmode'; 1020'unsigned short fract' to 'UQQmode'; 'fract' to 'HQmode'; 1021'unsigned fract' to 'UHQmode'; 'long fract' to 'SQmode'; 1022'unsigned long fract' to 'USQmode'; 'long long fract' to 'DQmode'; and 1023'unsigned long long fract' to 'UDQmode'. Similarly the fixed-point 1024accumulator type 'short accum' corresponds to 'HAmode'; 1025'unsigned short accum' to 'UHAmode'; 'accum' to 'SAmode'; 1026'unsigned accum' to 'USAmode'; 'long accum' to 'DAmode'; 1027'unsigned long accum' to 'UDAmode'; 'long long accum' to 'TAmode'; and 1028'unsigned long long accum' to 'UTAmode'. 1029 10304.4.1 Arithmetic functions 1031-------------------------- 1032 1033 -- Runtime Function: short fract __addqq3 (short fract A, short fract 1034 B) 1035 -- Runtime Function: fract __addhq3 (fract A, fract B) 1036 -- Runtime Function: long fract __addsq3 (long fract A, long fract B) 1037 -- Runtime Function: long long fract __adddq3 (long long fract A, long 1038 long fract B) 1039 -- Runtime Function: unsigned short fract __adduqq3 (unsigned short 1040 fract A, unsigned short fract B) 1041 -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A, 1042 unsigned fract B) 1043 -- Runtime Function: unsigned long fract __addusq3 (unsigned long fract 1044 A, unsigned long fract B) 1045 -- Runtime Function: unsigned long long fract __addudq3 (unsigned long 1046 long fract A, unsigned long long fract B) 1047 -- Runtime Function: short accum __addha3 (short accum A, short accum 1048 B) 1049 -- Runtime Function: accum __addsa3 (accum A, accum B) 1050 -- Runtime Function: long accum __addda3 (long accum A, long accum B) 1051 -- Runtime Function: long long accum __addta3 (long long accum A, long 1052 long accum B) 1053 -- Runtime Function: unsigned short accum __adduha3 (unsigned short 1054 accum A, unsigned short accum B) 1055 -- Runtime Function: unsigned accum __addusa3 (unsigned accum A, 1056 unsigned accum B) 1057 -- Runtime Function: unsigned long accum __adduda3 (unsigned long accum 1058 A, unsigned long accum B) 1059 -- Runtime Function: unsigned long long accum __adduta3 (unsigned long 1060 long accum A, unsigned long long accum B) 1061 These functions return the sum of A and B. 1062 1063 -- Runtime Function: short fract __ssaddqq3 (short fract A, short fract 1064 B) 1065 -- Runtime Function: fract __ssaddhq3 (fract A, fract B) 1066 -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B) 1067 -- Runtime Function: long long fract __ssadddq3 (long long fract A, 1068 long long fract B) 1069 -- Runtime Function: short accum __ssaddha3 (short accum A, short accum 1070 B) 1071 -- Runtime Function: accum __ssaddsa3 (accum A, accum B) 1072 -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B) 1073 -- Runtime Function: long long accum __ssaddta3 (long long accum A, 1074 long long accum B) 1075 These functions return the sum of A and B with signed saturation. 1076 1077 -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short 1078 fract A, unsigned short fract B) 1079 -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A, 1080 unsigned fract B) 1081 -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long 1082 fract A, unsigned long fract B) 1083 -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned 1084 long long fract A, unsigned long long fract B) 1085 -- Runtime Function: unsigned short accum __usadduha3 (unsigned short 1086 accum A, unsigned short accum B) 1087 -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A, 1088 unsigned accum B) 1089 -- Runtime Function: unsigned long accum __usadduda3 (unsigned long 1090 accum A, unsigned long accum B) 1091 -- Runtime Function: unsigned long long accum __usadduta3 (unsigned 1092 long long accum A, unsigned long long accum B) 1093 These functions return the sum of A and B with unsigned saturation. 1094 1095 -- Runtime Function: short fract __subqq3 (short fract A, short fract 1096 B) 1097 -- Runtime Function: fract __subhq3 (fract A, fract B) 1098 -- Runtime Function: long fract __subsq3 (long fract A, long fract B) 1099 -- Runtime Function: long long fract __subdq3 (long long fract A, long 1100 long fract B) 1101 -- Runtime Function: unsigned short fract __subuqq3 (unsigned short 1102 fract A, unsigned short fract B) 1103 -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A, 1104 unsigned fract B) 1105 -- Runtime Function: unsigned long fract __subusq3 (unsigned long fract 1106 A, unsigned long fract B) 1107 -- Runtime Function: unsigned long long fract __subudq3 (unsigned long 1108 long fract A, unsigned long long fract B) 1109 -- Runtime Function: short accum __subha3 (short accum A, short accum 1110 B) 1111 -- Runtime Function: accum __subsa3 (accum A, accum B) 1112 -- Runtime Function: long accum __subda3 (long accum A, long accum B) 1113 -- Runtime Function: long long accum __subta3 (long long accum A, long 1114 long accum B) 1115 -- Runtime Function: unsigned short accum __subuha3 (unsigned short 1116 accum A, unsigned short accum B) 1117 -- Runtime Function: unsigned accum __subusa3 (unsigned accum A, 1118 unsigned accum B) 1119 -- Runtime Function: unsigned long accum __subuda3 (unsigned long accum 1120 A, unsigned long accum B) 1121 -- Runtime Function: unsigned long long accum __subuta3 (unsigned long 1122 long accum A, unsigned long long accum B) 1123 These functions return the difference of A and B; that is, 'A - B'. 1124 1125 -- Runtime Function: short fract __sssubqq3 (short fract A, short fract 1126 B) 1127 -- Runtime Function: fract __sssubhq3 (fract A, fract B) 1128 -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B) 1129 -- Runtime Function: long long fract __sssubdq3 (long long fract A, 1130 long long fract B) 1131 -- Runtime Function: short accum __sssubha3 (short accum A, short accum 1132 B) 1133 -- Runtime Function: accum __sssubsa3 (accum A, accum B) 1134 -- Runtime Function: long accum __sssubda3 (long accum A, long accum B) 1135 -- Runtime Function: long long accum __sssubta3 (long long accum A, 1136 long long accum B) 1137 These functions return the difference of A and B with signed 1138 saturation; that is, 'A - B'. 1139 1140 -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short 1141 fract A, unsigned short fract B) 1142 -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A, 1143 unsigned fract B) 1144 -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long 1145 fract A, unsigned long fract B) 1146 -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned 1147 long long fract A, unsigned long long fract B) 1148 -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short 1149 accum A, unsigned short accum B) 1150 -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A, 1151 unsigned accum B) 1152 -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long 1153 accum A, unsigned long accum B) 1154 -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned 1155 long long accum A, unsigned long long accum B) 1156 These functions return the difference of A and B with unsigned 1157 saturation; that is, 'A - B'. 1158 1159 -- Runtime Function: short fract __mulqq3 (short fract A, short fract 1160 B) 1161 -- Runtime Function: fract __mulhq3 (fract A, fract B) 1162 -- Runtime Function: long fract __mulsq3 (long fract A, long fract B) 1163 -- Runtime Function: long long fract __muldq3 (long long fract A, long 1164 long fract B) 1165 -- Runtime Function: unsigned short fract __muluqq3 (unsigned short 1166 fract A, unsigned short fract B) 1167 -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A, 1168 unsigned fract B) 1169 -- Runtime Function: unsigned long fract __mulusq3 (unsigned long fract 1170 A, unsigned long fract B) 1171 -- Runtime Function: unsigned long long fract __muludq3 (unsigned long 1172 long fract A, unsigned long long fract B) 1173 -- Runtime Function: short accum __mulha3 (short accum A, short accum 1174 B) 1175 -- Runtime Function: accum __mulsa3 (accum A, accum B) 1176 -- Runtime Function: long accum __mulda3 (long accum A, long accum B) 1177 -- Runtime Function: long long accum __multa3 (long long accum A, long 1178 long accum B) 1179 -- Runtime Function: unsigned short accum __muluha3 (unsigned short 1180 accum A, unsigned short accum B) 1181 -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A, 1182 unsigned accum B) 1183 -- Runtime Function: unsigned long accum __muluda3 (unsigned long accum 1184 A, unsigned long accum B) 1185 -- Runtime Function: unsigned long long accum __muluta3 (unsigned long 1186 long accum A, unsigned long long accum B) 1187 These functions return the product of A and B. 1188 1189 -- Runtime Function: short fract __ssmulqq3 (short fract A, short fract 1190 B) 1191 -- Runtime Function: fract __ssmulhq3 (fract A, fract B) 1192 -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B) 1193 -- Runtime Function: long long fract __ssmuldq3 (long long fract A, 1194 long long fract B) 1195 -- Runtime Function: short accum __ssmulha3 (short accum A, short accum 1196 B) 1197 -- Runtime Function: accum __ssmulsa3 (accum A, accum B) 1198 -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B) 1199 -- Runtime Function: long long accum __ssmulta3 (long long accum A, 1200 long long accum B) 1201 These functions return the product of A and B with signed 1202 saturation. 1203 1204 -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short 1205 fract A, unsigned short fract B) 1206 -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A, 1207 unsigned fract B) 1208 -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long 1209 fract A, unsigned long fract B) 1210 -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned 1211 long long fract A, unsigned long long fract B) 1212 -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short 1213 accum A, unsigned short accum B) 1214 -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A, 1215 unsigned accum B) 1216 -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long 1217 accum A, unsigned long accum B) 1218 -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned 1219 long long accum A, unsigned long long accum B) 1220 These functions return the product of A and B with unsigned 1221 saturation. 1222 1223 -- Runtime Function: short fract __divqq3 (short fract A, short fract 1224 B) 1225 -- Runtime Function: fract __divhq3 (fract A, fract B) 1226 -- Runtime Function: long fract __divsq3 (long fract A, long fract B) 1227 -- Runtime Function: long long fract __divdq3 (long long fract A, long 1228 long fract B) 1229 -- Runtime Function: short accum __divha3 (short accum A, short accum 1230 B) 1231 -- Runtime Function: accum __divsa3 (accum A, accum B) 1232 -- Runtime Function: long accum __divda3 (long accum A, long accum B) 1233 -- Runtime Function: long long accum __divta3 (long long accum A, long 1234 long accum B) 1235 These functions return the quotient of the signed division of A and 1236 B. 1237 1238 -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short 1239 fract A, unsigned short fract B) 1240 -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A, 1241 unsigned fract B) 1242 -- Runtime Function: unsigned long fract __udivusq3 (unsigned long 1243 fract A, unsigned long fract B) 1244 -- Runtime Function: unsigned long long fract __udivudq3 (unsigned long 1245 long fract A, unsigned long long fract B) 1246 -- Runtime Function: unsigned short accum __udivuha3 (unsigned short 1247 accum A, unsigned short accum B) 1248 -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A, 1249 unsigned accum B) 1250 -- Runtime Function: unsigned long accum __udivuda3 (unsigned long 1251 accum A, unsigned long accum B) 1252 -- Runtime Function: unsigned long long accum __udivuta3 (unsigned long 1253 long accum A, unsigned long long accum B) 1254 These functions return the quotient of the unsigned division of A 1255 and B. 1256 1257 -- Runtime Function: short fract __ssdivqq3 (short fract A, short fract 1258 B) 1259 -- Runtime Function: fract __ssdivhq3 (fract A, fract B) 1260 -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B) 1261 -- Runtime Function: long long fract __ssdivdq3 (long long fract A, 1262 long long fract B) 1263 -- Runtime Function: short accum __ssdivha3 (short accum A, short accum 1264 B) 1265 -- Runtime Function: accum __ssdivsa3 (accum A, accum B) 1266 -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B) 1267 -- Runtime Function: long long accum __ssdivta3 (long long accum A, 1268 long long accum B) 1269 These functions return the quotient of the signed division of A and 1270 B with signed saturation. 1271 1272 -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short 1273 fract A, unsigned short fract B) 1274 -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A, 1275 unsigned fract B) 1276 -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long 1277 fract A, unsigned long fract B) 1278 -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned 1279 long long fract A, unsigned long long fract B) 1280 -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short 1281 accum A, unsigned short accum B) 1282 -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A, 1283 unsigned accum B) 1284 -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long 1285 accum A, unsigned long accum B) 1286 -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned 1287 long long accum A, unsigned long long accum B) 1288 These functions return the quotient of the unsigned division of A 1289 and B with unsigned saturation. 1290 1291 -- Runtime Function: short fract __negqq2 (short fract A) 1292 -- Runtime Function: fract __neghq2 (fract A) 1293 -- Runtime Function: long fract __negsq2 (long fract A) 1294 -- Runtime Function: long long fract __negdq2 (long long fract A) 1295 -- Runtime Function: unsigned short fract __neguqq2 (unsigned short 1296 fract A) 1297 -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A) 1298 -- Runtime Function: unsigned long fract __negusq2 (unsigned long fract 1299 A) 1300 -- Runtime Function: unsigned long long fract __negudq2 (unsigned long 1301 long fract A) 1302 -- Runtime Function: short accum __negha2 (short accum A) 1303 -- Runtime Function: accum __negsa2 (accum A) 1304 -- Runtime Function: long accum __negda2 (long accum A) 1305 -- Runtime Function: long long accum __negta2 (long long accum A) 1306 -- Runtime Function: unsigned short accum __neguha2 (unsigned short 1307 accum A) 1308 -- Runtime Function: unsigned accum __negusa2 (unsigned accum A) 1309 -- Runtime Function: unsigned long accum __neguda2 (unsigned long accum 1310 A) 1311 -- Runtime Function: unsigned long long accum __neguta2 (unsigned long 1312 long accum A) 1313 These functions return the negation of A. 1314 1315 -- Runtime Function: short fract __ssnegqq2 (short fract A) 1316 -- Runtime Function: fract __ssneghq2 (fract A) 1317 -- Runtime Function: long fract __ssnegsq2 (long fract A) 1318 -- Runtime Function: long long fract __ssnegdq2 (long long fract A) 1319 -- Runtime Function: short accum __ssnegha2 (short accum A) 1320 -- Runtime Function: accum __ssnegsa2 (accum A) 1321 -- Runtime Function: long accum __ssnegda2 (long accum A) 1322 -- Runtime Function: long long accum __ssnegta2 (long long accum A) 1323 These functions return the negation of A with signed saturation. 1324 1325 -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short 1326 fract A) 1327 -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A) 1328 -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long 1329 fract A) 1330 -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned 1331 long long fract A) 1332 -- Runtime Function: unsigned short accum __usneguha2 (unsigned short 1333 accum A) 1334 -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A) 1335 -- Runtime Function: unsigned long accum __usneguda2 (unsigned long 1336 accum A) 1337 -- Runtime Function: unsigned long long accum __usneguta2 (unsigned 1338 long long accum A) 1339 These functions return the negation of A with unsigned saturation. 1340 1341 -- Runtime Function: short fract __ashlqq3 (short fract A, int B) 1342 -- Runtime Function: fract __ashlhq3 (fract A, int B) 1343 -- Runtime Function: long fract __ashlsq3 (long fract A, int B) 1344 -- Runtime Function: long long fract __ashldq3 (long long fract A, int 1345 B) 1346 -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short 1347 fract A, int B) 1348 -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int 1349 B) 1350 -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long 1351 fract A, int B) 1352 -- Runtime Function: unsigned long long fract __ashludq3 (unsigned long 1353 long fract A, int B) 1354 -- Runtime Function: short accum __ashlha3 (short accum A, int B) 1355 -- Runtime Function: accum __ashlsa3 (accum A, int B) 1356 -- Runtime Function: long accum __ashlda3 (long accum A, int B) 1357 -- Runtime Function: long long accum __ashlta3 (long long accum A, int 1358 B) 1359 -- Runtime Function: unsigned short accum __ashluha3 (unsigned short 1360 accum A, int B) 1361 -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int 1362 B) 1363 -- Runtime Function: unsigned long accum __ashluda3 (unsigned long 1364 accum A, int B) 1365 -- Runtime Function: unsigned long long accum __ashluta3 (unsigned long 1366 long accum A, int B) 1367 These functions return the result of shifting A left by B bits. 1368 1369 -- Runtime Function: short fract __ashrqq3 (short fract A, int B) 1370 -- Runtime Function: fract __ashrhq3 (fract A, int B) 1371 -- Runtime Function: long fract __ashrsq3 (long fract A, int B) 1372 -- Runtime Function: long long fract __ashrdq3 (long long fract A, int 1373 B) 1374 -- Runtime Function: short accum __ashrha3 (short accum A, int B) 1375 -- Runtime Function: accum __ashrsa3 (accum A, int B) 1376 -- Runtime Function: long accum __ashrda3 (long accum A, int B) 1377 -- Runtime Function: long long accum __ashrta3 (long long accum A, int 1378 B) 1379 These functions return the result of arithmetically shifting A 1380 right by B bits. 1381 1382 -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short 1383 fract A, int B) 1384 -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int 1385 B) 1386 -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long 1387 fract A, int B) 1388 -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned long 1389 long fract A, int B) 1390 -- Runtime Function: unsigned short accum __lshruha3 (unsigned short 1391 accum A, int B) 1392 -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int 1393 B) 1394 -- Runtime Function: unsigned long accum __lshruda3 (unsigned long 1395 accum A, int B) 1396 -- Runtime Function: unsigned long long accum __lshruta3 (unsigned long 1397 long accum A, int B) 1398 These functions return the result of logically shifting A right by 1399 B bits. 1400 1401 -- Runtime Function: fract __ssashlhq3 (fract A, int B) 1402 -- Runtime Function: long fract __ssashlsq3 (long fract A, int B) 1403 -- Runtime Function: long long fract __ssashldq3 (long long fract A, 1404 int B) 1405 -- Runtime Function: short accum __ssashlha3 (short accum A, int B) 1406 -- Runtime Function: accum __ssashlsa3 (accum A, int B) 1407 -- Runtime Function: long accum __ssashlda3 (long accum A, int B) 1408 -- Runtime Function: long long accum __ssashlta3 (long long accum A, 1409 int B) 1410 These functions return the result of shifting A left by B bits with 1411 signed saturation. 1412 1413 -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short 1414 fract A, int B) 1415 -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A, int 1416 B) 1417 -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long 1418 fract A, int B) 1419 -- Runtime Function: unsigned long long fract __usashludq3 (unsigned 1420 long long fract A, int B) 1421 -- Runtime Function: unsigned short accum __usashluha3 (unsigned short 1422 accum A, int B) 1423 -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A, int 1424 B) 1425 -- Runtime Function: unsigned long accum __usashluda3 (unsigned long 1426 accum A, int B) 1427 -- Runtime Function: unsigned long long accum __usashluta3 (unsigned 1428 long long accum A, int B) 1429 These functions return the result of shifting A left by B bits with 1430 unsigned saturation. 1431 14324.4.2 Comparison functions 1433-------------------------- 1434 1435The following functions implement fixed-point comparisons. These 1436functions implement a low-level compare, upon which the higher level 1437comparison operators (such as less than and greater than or equal to) 1438can be constructed. The returned values lie in the range zero to two, 1439to allow the high-level operators to be implemented by testing the 1440returned result using either signed or unsigned comparison. 1441 1442 -- Runtime Function: int __cmpqq2 (short fract A, short fract B) 1443 -- Runtime Function: int __cmphq2 (fract A, fract B) 1444 -- Runtime Function: int __cmpsq2 (long fract A, long fract B) 1445 -- Runtime Function: int __cmpdq2 (long long fract A, long long fract 1446 B) 1447 -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned 1448 short fract B) 1449 -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B) 1450 -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned 1451 long fract B) 1452 -- Runtime Function: int __cmpudq2 (unsigned long long fract A, 1453 unsigned long long fract B) 1454 -- Runtime Function: int __cmpha2 (short accum A, short accum B) 1455 -- Runtime Function: int __cmpsa2 (accum A, accum B) 1456 -- Runtime Function: int __cmpda2 (long accum A, long accum B) 1457 -- Runtime Function: int __cmpta2 (long long accum A, long long accum 1458 B) 1459 -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned 1460 short accum B) 1461 -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B) 1462 -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned 1463 long accum B) 1464 -- Runtime Function: int __cmputa2 (unsigned long long accum A, 1465 unsigned long long accum B) 1466 These functions perform a signed or unsigned comparison of A and B 1467 (depending on the selected machine mode). If A is less than B, 1468 they return 0; if A is greater than B, they return 2; and if A and 1469 B are equal they return 1. 1470 14714.4.3 Conversion functions 1472-------------------------- 1473 1474 -- Runtime Function: fract __fractqqhq2 (short fract A) 1475 -- Runtime Function: long fract __fractqqsq2 (short fract A) 1476 -- Runtime Function: long long fract __fractqqdq2 (short fract A) 1477 -- Runtime Function: short accum __fractqqha (short fract A) 1478 -- Runtime Function: accum __fractqqsa (short fract A) 1479 -- Runtime Function: long accum __fractqqda (short fract A) 1480 -- Runtime Function: long long accum __fractqqta (short fract A) 1481 -- Runtime Function: unsigned short fract __fractqquqq (short fract A) 1482 -- Runtime Function: unsigned fract __fractqquhq (short fract A) 1483 -- Runtime Function: unsigned long fract __fractqqusq (short fract A) 1484 -- Runtime Function: unsigned long long fract __fractqqudq (short fract 1485 A) 1486 -- Runtime Function: unsigned short accum __fractqquha (short fract A) 1487 -- Runtime Function: unsigned accum __fractqqusa (short fract A) 1488 -- Runtime Function: unsigned long accum __fractqquda (short fract A) 1489 -- Runtime Function: unsigned long long accum __fractqquta (short fract 1490 A) 1491 -- Runtime Function: signed char __fractqqqi (short fract A) 1492 -- Runtime Function: short __fractqqhi (short fract A) 1493 -- Runtime Function: int __fractqqsi (short fract A) 1494 -- Runtime Function: long __fractqqdi (short fract A) 1495 -- Runtime Function: long long __fractqqti (short fract A) 1496 -- Runtime Function: float __fractqqsf (short fract A) 1497 -- Runtime Function: double __fractqqdf (short fract A) 1498 -- Runtime Function: short fract __fracthqqq2 (fract A) 1499 -- Runtime Function: long fract __fracthqsq2 (fract A) 1500 -- Runtime Function: long long fract __fracthqdq2 (fract A) 1501 -- Runtime Function: short accum __fracthqha (fract A) 1502 -- Runtime Function: accum __fracthqsa (fract A) 1503 -- Runtime Function: long accum __fracthqda (fract A) 1504 -- Runtime Function: long long accum __fracthqta (fract A) 1505 -- Runtime Function: unsigned short fract __fracthquqq (fract A) 1506 -- Runtime Function: unsigned fract __fracthquhq (fract A) 1507 -- Runtime Function: unsigned long fract __fracthqusq (fract A) 1508 -- Runtime Function: unsigned long long fract __fracthqudq (fract A) 1509 -- Runtime Function: unsigned short accum __fracthquha (fract A) 1510 -- Runtime Function: unsigned accum __fracthqusa (fract A) 1511 -- Runtime Function: unsigned long accum __fracthquda (fract A) 1512 -- Runtime Function: unsigned long long accum __fracthquta (fract A) 1513 -- Runtime Function: signed char __fracthqqi (fract A) 1514 -- Runtime Function: short __fracthqhi (fract A) 1515 -- Runtime Function: int __fracthqsi (fract A) 1516 -- Runtime Function: long __fracthqdi (fract A) 1517 -- Runtime Function: long long __fracthqti (fract A) 1518 -- Runtime Function: float __fracthqsf (fract A) 1519 -- Runtime Function: double __fracthqdf (fract A) 1520 -- Runtime Function: short fract __fractsqqq2 (long fract A) 1521 -- Runtime Function: fract __fractsqhq2 (long fract A) 1522 -- Runtime Function: long long fract __fractsqdq2 (long fract A) 1523 -- Runtime Function: short accum __fractsqha (long fract A) 1524 -- Runtime Function: accum __fractsqsa (long fract A) 1525 -- Runtime Function: long accum __fractsqda (long fract A) 1526 -- Runtime Function: long long accum __fractsqta (long fract A) 1527 -- Runtime Function: unsigned short fract __fractsquqq (long fract A) 1528 -- Runtime Function: unsigned fract __fractsquhq (long fract A) 1529 -- Runtime Function: unsigned long fract __fractsqusq (long fract A) 1530 -- Runtime Function: unsigned long long fract __fractsqudq (long fract 1531 A) 1532 -- Runtime Function: unsigned short accum __fractsquha (long fract A) 1533 -- Runtime Function: unsigned accum __fractsqusa (long fract A) 1534 -- Runtime Function: unsigned long accum __fractsquda (long fract A) 1535 -- Runtime Function: unsigned long long accum __fractsquta (long fract 1536 A) 1537 -- Runtime Function: signed char __fractsqqi (long fract A) 1538 -- Runtime Function: short __fractsqhi (long fract A) 1539 -- Runtime Function: int __fractsqsi (long fract A) 1540 -- Runtime Function: long __fractsqdi (long fract A) 1541 -- Runtime Function: long long __fractsqti (long fract A) 1542 -- Runtime Function: float __fractsqsf (long fract A) 1543 -- Runtime Function: double __fractsqdf (long fract A) 1544 -- Runtime Function: short fract __fractdqqq2 (long long fract A) 1545 -- Runtime Function: fract __fractdqhq2 (long long fract A) 1546 -- Runtime Function: long fract __fractdqsq2 (long long fract A) 1547 -- Runtime Function: short accum __fractdqha (long long fract A) 1548 -- Runtime Function: accum __fractdqsa (long long fract A) 1549 -- Runtime Function: long accum __fractdqda (long long fract A) 1550 -- Runtime Function: long long accum __fractdqta (long long fract A) 1551 -- Runtime Function: unsigned short fract __fractdquqq (long long fract 1552 A) 1553 -- Runtime Function: unsigned fract __fractdquhq (long long fract A) 1554 -- Runtime Function: unsigned long fract __fractdqusq (long long fract 1555 A) 1556 -- Runtime Function: unsigned long long fract __fractdqudq (long long 1557 fract A) 1558 -- Runtime Function: unsigned short accum __fractdquha (long long fract 1559 A) 1560 -- Runtime Function: unsigned accum __fractdqusa (long long fract A) 1561 -- Runtime Function: unsigned long accum __fractdquda (long long fract 1562 A) 1563 -- Runtime Function: unsigned long long accum __fractdquta (long long 1564 fract A) 1565 -- Runtime Function: signed char __fractdqqi (long long fract A) 1566 -- Runtime Function: short __fractdqhi (long long fract A) 1567 -- Runtime Function: int __fractdqsi (long long fract A) 1568 -- Runtime Function: long __fractdqdi (long long fract A) 1569 -- Runtime Function: long long __fractdqti (long long fract A) 1570 -- Runtime Function: float __fractdqsf (long long fract A) 1571 -- Runtime Function: double __fractdqdf (long long fract A) 1572 -- Runtime Function: short fract __fracthaqq (short accum A) 1573 -- Runtime Function: fract __fracthahq (short accum A) 1574 -- Runtime Function: long fract __fracthasq (short accum A) 1575 -- Runtime Function: long long fract __fracthadq (short accum A) 1576 -- Runtime Function: accum __fracthasa2 (short accum A) 1577 -- Runtime Function: long accum __fracthada2 (short accum A) 1578 -- Runtime Function: long long accum __fracthata2 (short accum A) 1579 -- Runtime Function: unsigned short fract __fracthauqq (short accum A) 1580 -- Runtime Function: unsigned fract __fracthauhq (short accum A) 1581 -- Runtime Function: unsigned long fract __fracthausq (short accum A) 1582 -- Runtime Function: unsigned long long fract __fracthaudq (short accum 1583 A) 1584 -- Runtime Function: unsigned short accum __fracthauha (short accum A) 1585 -- Runtime Function: unsigned accum __fracthausa (short accum A) 1586 -- Runtime Function: unsigned long accum __fracthauda (short accum A) 1587 -- Runtime Function: unsigned long long accum __fracthauta (short accum 1588 A) 1589 -- Runtime Function: signed char __fracthaqi (short accum A) 1590 -- Runtime Function: short __fracthahi (short accum A) 1591 -- Runtime Function: int __fracthasi (short accum A) 1592 -- Runtime Function: long __fracthadi (short accum A) 1593 -- Runtime Function: long long __fracthati (short accum A) 1594 -- Runtime Function: float __fracthasf (short accum A) 1595 -- Runtime Function: double __fracthadf (short accum A) 1596 -- Runtime Function: short fract __fractsaqq (accum A) 1597 -- Runtime Function: fract __fractsahq (accum A) 1598 -- Runtime Function: long fract __fractsasq (accum A) 1599 -- Runtime Function: long long fract __fractsadq (accum A) 1600 -- Runtime Function: short accum __fractsaha2 (accum A) 1601 -- Runtime Function: long accum __fractsada2 (accum A) 1602 -- Runtime Function: long long accum __fractsata2 (accum A) 1603 -- Runtime Function: unsigned short fract __fractsauqq (accum A) 1604 -- Runtime Function: unsigned fract __fractsauhq (accum A) 1605 -- Runtime Function: unsigned long fract __fractsausq (accum A) 1606 -- Runtime Function: unsigned long long fract __fractsaudq (accum A) 1607 -- Runtime Function: unsigned short accum __fractsauha (accum A) 1608 -- Runtime Function: unsigned accum __fractsausa (accum A) 1609 -- Runtime Function: unsigned long accum __fractsauda (accum A) 1610 -- Runtime Function: unsigned long long accum __fractsauta (accum A) 1611 -- Runtime Function: signed char __fractsaqi (accum A) 1612 -- Runtime Function: short __fractsahi (accum A) 1613 -- Runtime Function: int __fractsasi (accum A) 1614 -- Runtime Function: long __fractsadi (accum A) 1615 -- Runtime Function: long long __fractsati (accum A) 1616 -- Runtime Function: float __fractsasf (accum A) 1617 -- Runtime Function: double __fractsadf (accum A) 1618 -- Runtime Function: short fract __fractdaqq (long accum A) 1619 -- Runtime Function: fract __fractdahq (long accum A) 1620 -- Runtime Function: long fract __fractdasq (long accum A) 1621 -- Runtime Function: long long fract __fractdadq (long accum A) 1622 -- Runtime Function: short accum __fractdaha2 (long accum A) 1623 -- Runtime Function: accum __fractdasa2 (long accum A) 1624 -- Runtime Function: long long accum __fractdata2 (long accum A) 1625 -- Runtime Function: unsigned short fract __fractdauqq (long accum A) 1626 -- Runtime Function: unsigned fract __fractdauhq (long accum A) 1627 -- Runtime Function: unsigned long fract __fractdausq (long accum A) 1628 -- Runtime Function: unsigned long long fract __fractdaudq (long accum 1629 A) 1630 -- Runtime Function: unsigned short accum __fractdauha (long accum A) 1631 -- Runtime Function: unsigned accum __fractdausa (long accum A) 1632 -- Runtime Function: unsigned long accum __fractdauda (long accum A) 1633 -- Runtime Function: unsigned long long accum __fractdauta (long accum 1634 A) 1635 -- Runtime Function: signed char __fractdaqi (long accum A) 1636 -- Runtime Function: short __fractdahi (long accum A) 1637 -- Runtime Function: int __fractdasi (long accum A) 1638 -- Runtime Function: long __fractdadi (long accum A) 1639 -- Runtime Function: long long __fractdati (long accum A) 1640 -- Runtime Function: float __fractdasf (long accum A) 1641 -- Runtime Function: double __fractdadf (long accum A) 1642 -- Runtime Function: short fract __fracttaqq (long long accum A) 1643 -- Runtime Function: fract __fracttahq (long long accum A) 1644 -- Runtime Function: long fract __fracttasq (long long accum A) 1645 -- Runtime Function: long long fract __fracttadq (long long accum A) 1646 -- Runtime Function: short accum __fracttaha2 (long long accum A) 1647 -- Runtime Function: accum __fracttasa2 (long long accum A) 1648 -- Runtime Function: long accum __fracttada2 (long long accum A) 1649 -- Runtime Function: unsigned short fract __fracttauqq (long long accum 1650 A) 1651 -- Runtime Function: unsigned fract __fracttauhq (long long accum A) 1652 -- Runtime Function: unsigned long fract __fracttausq (long long accum 1653 A) 1654 -- Runtime Function: unsigned long long fract __fracttaudq (long long 1655 accum A) 1656 -- Runtime Function: unsigned short accum __fracttauha (long long accum 1657 A) 1658 -- Runtime Function: unsigned accum __fracttausa (long long accum A) 1659 -- Runtime Function: unsigned long accum __fracttauda (long long accum 1660 A) 1661 -- Runtime Function: unsigned long long accum __fracttauta (long long 1662 accum A) 1663 -- Runtime Function: signed char __fracttaqi (long long accum A) 1664 -- Runtime Function: short __fracttahi (long long accum A) 1665 -- Runtime Function: int __fracttasi (long long accum A) 1666 -- Runtime Function: long __fracttadi (long long accum A) 1667 -- Runtime Function: long long __fracttati (long long accum A) 1668 -- Runtime Function: float __fracttasf (long long accum A) 1669 -- Runtime Function: double __fracttadf (long long accum A) 1670 -- Runtime Function: short fract __fractuqqqq (unsigned short fract A) 1671 -- Runtime Function: fract __fractuqqhq (unsigned short fract A) 1672 -- Runtime Function: long fract __fractuqqsq (unsigned short fract A) 1673 -- Runtime Function: long long fract __fractuqqdq (unsigned short fract 1674 A) 1675 -- Runtime Function: short accum __fractuqqha (unsigned short fract A) 1676 -- Runtime Function: accum __fractuqqsa (unsigned short fract A) 1677 -- Runtime Function: long accum __fractuqqda (unsigned short fract A) 1678 -- Runtime Function: long long accum __fractuqqta (unsigned short fract 1679 A) 1680 -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short 1681 fract A) 1682 -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned short 1683 fract A) 1684 -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned 1685 short fract A) 1686 -- Runtime Function: unsigned short accum __fractuqquha (unsigned short 1687 fract A) 1688 -- Runtime Function: unsigned accum __fractuqqusa (unsigned short fract 1689 A) 1690 -- Runtime Function: unsigned long accum __fractuqquda (unsigned short 1691 fract A) 1692 -- Runtime Function: unsigned long long accum __fractuqquta (unsigned 1693 short fract A) 1694 -- Runtime Function: signed char __fractuqqqi (unsigned short fract A) 1695 -- Runtime Function: short __fractuqqhi (unsigned short fract A) 1696 -- Runtime Function: int __fractuqqsi (unsigned short fract A) 1697 -- Runtime Function: long __fractuqqdi (unsigned short fract A) 1698 -- Runtime Function: long long __fractuqqti (unsigned short fract A) 1699 -- Runtime Function: float __fractuqqsf (unsigned short fract A) 1700 -- Runtime Function: double __fractuqqdf (unsigned short fract A) 1701 -- Runtime Function: short fract __fractuhqqq (unsigned fract A) 1702 -- Runtime Function: fract __fractuhqhq (unsigned fract A) 1703 -- Runtime Function: long fract __fractuhqsq (unsigned fract A) 1704 -- Runtime Function: long long fract __fractuhqdq (unsigned fract A) 1705 -- Runtime Function: short accum __fractuhqha (unsigned fract A) 1706 -- Runtime Function: accum __fractuhqsa (unsigned fract A) 1707 -- Runtime Function: long accum __fractuhqda (unsigned fract A) 1708 -- Runtime Function: long long accum __fractuhqta (unsigned fract A) 1709 -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned 1710 fract A) 1711 -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned fract 1712 A) 1713 -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned 1714 fract A) 1715 -- Runtime Function: unsigned short accum __fractuhquha (unsigned fract 1716 A) 1717 -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A) 1718 -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract 1719 A) 1720 -- Runtime Function: unsigned long long accum __fractuhquta (unsigned 1721 fract A) 1722 -- Runtime Function: signed char __fractuhqqi (unsigned fract A) 1723 -- Runtime Function: short __fractuhqhi (unsigned fract A) 1724 -- Runtime Function: int __fractuhqsi (unsigned fract A) 1725 -- Runtime Function: long __fractuhqdi (unsigned fract A) 1726 -- Runtime Function: long long __fractuhqti (unsigned fract A) 1727 -- Runtime Function: float __fractuhqsf (unsigned fract A) 1728 -- Runtime Function: double __fractuhqdf (unsigned fract A) 1729 -- Runtime Function: short fract __fractusqqq (unsigned long fract A) 1730 -- Runtime Function: fract __fractusqhq (unsigned long fract A) 1731 -- Runtime Function: long fract __fractusqsq (unsigned long fract A) 1732 -- Runtime Function: long long fract __fractusqdq (unsigned long fract 1733 A) 1734 -- Runtime Function: short accum __fractusqha (unsigned long fract A) 1735 -- Runtime Function: accum __fractusqsa (unsigned long fract A) 1736 -- Runtime Function: long accum __fractusqda (unsigned long fract A) 1737 -- Runtime Function: long long accum __fractusqta (unsigned long fract 1738 A) 1739 -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned long 1740 fract A) 1741 -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long fract 1742 A) 1743 -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned 1744 long fract A) 1745 -- Runtime Function: unsigned short accum __fractusquha (unsigned long 1746 fract A) 1747 -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract 1748 A) 1749 -- Runtime Function: unsigned long accum __fractusquda (unsigned long 1750 fract A) 1751 -- Runtime Function: unsigned long long accum __fractusquta (unsigned 1752 long fract A) 1753 -- Runtime Function: signed char __fractusqqi (unsigned long fract A) 1754 -- Runtime Function: short __fractusqhi (unsigned long fract A) 1755 -- Runtime Function: int __fractusqsi (unsigned long fract A) 1756 -- Runtime Function: long __fractusqdi (unsigned long fract A) 1757 -- Runtime Function: long long __fractusqti (unsigned long fract A) 1758 -- Runtime Function: float __fractusqsf (unsigned long fract A) 1759 -- Runtime Function: double __fractusqdf (unsigned long fract A) 1760 -- Runtime Function: short fract __fractudqqq (unsigned long long fract 1761 A) 1762 -- Runtime Function: fract __fractudqhq (unsigned long long fract A) 1763 -- Runtime Function: long fract __fractudqsq (unsigned long long fract 1764 A) 1765 -- Runtime Function: long long fract __fractudqdq (unsigned long long 1766 fract A) 1767 -- Runtime Function: short accum __fractudqha (unsigned long long fract 1768 A) 1769 -- Runtime Function: accum __fractudqsa (unsigned long long fract A) 1770 -- Runtime Function: long accum __fractudqda (unsigned long long fract 1771 A) 1772 -- Runtime Function: long long accum __fractudqta (unsigned long long 1773 fract A) 1774 -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned long 1775 long fract A) 1776 -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long 1777 fract A) 1778 -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long 1779 long fract A) 1780 -- Runtime Function: unsigned short accum __fractudquha (unsigned long 1781 long fract A) 1782 -- Runtime Function: unsigned accum __fractudqusa (unsigned long long 1783 fract A) 1784 -- Runtime Function: unsigned long accum __fractudquda (unsigned long 1785 long fract A) 1786 -- Runtime Function: unsigned long long accum __fractudquta (unsigned 1787 long long fract A) 1788 -- Runtime Function: signed char __fractudqqi (unsigned long long fract 1789 A) 1790 -- Runtime Function: short __fractudqhi (unsigned long long fract A) 1791 -- Runtime Function: int __fractudqsi (unsigned long long fract A) 1792 -- Runtime Function: long __fractudqdi (unsigned long long fract A) 1793 -- Runtime Function: long long __fractudqti (unsigned long long fract 1794 A) 1795 -- Runtime Function: float __fractudqsf (unsigned long long fract A) 1796 -- Runtime Function: double __fractudqdf (unsigned long long fract A) 1797 -- Runtime Function: short fract __fractuhaqq (unsigned short accum A) 1798 -- Runtime Function: fract __fractuhahq (unsigned short accum A) 1799 -- Runtime Function: long fract __fractuhasq (unsigned short accum A) 1800 -- Runtime Function: long long fract __fractuhadq (unsigned short accum 1801 A) 1802 -- Runtime Function: short accum __fractuhaha (unsigned short accum A) 1803 -- Runtime Function: accum __fractuhasa (unsigned short accum A) 1804 -- Runtime Function: long accum __fractuhada (unsigned short accum A) 1805 -- Runtime Function: long long accum __fractuhata (unsigned short accum 1806 A) 1807 -- Runtime Function: unsigned short fract __fractuhauqq (unsigned short 1808 accum A) 1809 -- Runtime Function: unsigned fract __fractuhauhq (unsigned short accum 1810 A) 1811 -- Runtime Function: unsigned long fract __fractuhausq (unsigned short 1812 accum A) 1813 -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned 1814 short accum A) 1815 -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short 1816 accum A) 1817 -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned short 1818 accum A) 1819 -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned 1820 short accum A) 1821 -- Runtime Function: signed char __fractuhaqi (unsigned short accum A) 1822 -- Runtime Function: short __fractuhahi (unsigned short accum A) 1823 -- Runtime Function: int __fractuhasi (unsigned short accum A) 1824 -- Runtime Function: long __fractuhadi (unsigned short accum A) 1825 -- Runtime Function: long long __fractuhati (unsigned short accum A) 1826 -- Runtime Function: float __fractuhasf (unsigned short accum A) 1827 -- Runtime Function: double __fractuhadf (unsigned short accum A) 1828 -- Runtime Function: short fract __fractusaqq (unsigned accum A) 1829 -- Runtime Function: fract __fractusahq (unsigned accum A) 1830 -- Runtime Function: long fract __fractusasq (unsigned accum A) 1831 -- Runtime Function: long long fract __fractusadq (unsigned accum A) 1832 -- Runtime Function: short accum __fractusaha (unsigned accum A) 1833 -- Runtime Function: accum __fractusasa (unsigned accum A) 1834 -- Runtime Function: long accum __fractusada (unsigned accum A) 1835 -- Runtime Function: long long accum __fractusata (unsigned accum A) 1836 -- Runtime Function: unsigned short fract __fractusauqq (unsigned accum 1837 A) 1838 -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A) 1839 -- Runtime Function: unsigned long fract __fractusausq (unsigned accum 1840 A) 1841 -- Runtime Function: unsigned long long fract __fractusaudq (unsigned 1842 accum A) 1843 -- Runtime Function: unsigned short accum __fractusauha2 (unsigned 1844 accum A) 1845 -- Runtime Function: unsigned long accum __fractusauda2 (unsigned accum 1846 A) 1847 -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned 1848 accum A) 1849 -- Runtime Function: signed char __fractusaqi (unsigned accum A) 1850 -- Runtime Function: short __fractusahi (unsigned accum A) 1851 -- Runtime Function: int __fractusasi (unsigned accum A) 1852 -- Runtime Function: long __fractusadi (unsigned accum A) 1853 -- Runtime Function: long long __fractusati (unsigned accum A) 1854 -- Runtime Function: float __fractusasf (unsigned accum A) 1855 -- Runtime Function: double __fractusadf (unsigned accum A) 1856 -- Runtime Function: short fract __fractudaqq (unsigned long accum A) 1857 -- Runtime Function: fract __fractudahq (unsigned long accum A) 1858 -- Runtime Function: long fract __fractudasq (unsigned long accum A) 1859 -- Runtime Function: long long fract __fractudadq (unsigned long accum 1860 A) 1861 -- Runtime Function: short accum __fractudaha (unsigned long accum A) 1862 -- Runtime Function: accum __fractudasa (unsigned long accum A) 1863 -- Runtime Function: long accum __fractudada (unsigned long accum A) 1864 -- Runtime Function: long long accum __fractudata (unsigned long accum 1865 A) 1866 -- Runtime Function: unsigned short fract __fractudauqq (unsigned long 1867 accum A) 1868 -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum 1869 A) 1870 -- Runtime Function: unsigned long fract __fractudausq (unsigned long 1871 accum A) 1872 -- Runtime Function: unsigned long long fract __fractudaudq (unsigned 1873 long accum A) 1874 -- Runtime Function: unsigned short accum __fractudauha2 (unsigned long 1875 accum A) 1876 -- Runtime Function: unsigned accum __fractudausa2 (unsigned long accum 1877 A) 1878 -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned 1879 long accum A) 1880 -- Runtime Function: signed char __fractudaqi (unsigned long accum A) 1881 -- Runtime Function: short __fractudahi (unsigned long accum A) 1882 -- Runtime Function: int __fractudasi (unsigned long accum A) 1883 -- Runtime Function: long __fractudadi (unsigned long accum A) 1884 -- Runtime Function: long long __fractudati (unsigned long accum A) 1885 -- Runtime Function: float __fractudasf (unsigned long accum A) 1886 -- Runtime Function: double __fractudadf (unsigned long accum A) 1887 -- Runtime Function: short fract __fractutaqq (unsigned long long accum 1888 A) 1889 -- Runtime Function: fract __fractutahq (unsigned long long accum A) 1890 -- Runtime Function: long fract __fractutasq (unsigned long long accum 1891 A) 1892 -- Runtime Function: long long fract __fractutadq (unsigned long long 1893 accum A) 1894 -- Runtime Function: short accum __fractutaha (unsigned long long accum 1895 A) 1896 -- Runtime Function: accum __fractutasa (unsigned long long accum A) 1897 -- Runtime Function: long accum __fractutada (unsigned long long accum 1898 A) 1899 -- Runtime Function: long long accum __fractutata (unsigned long long 1900 accum A) 1901 -- Runtime Function: unsigned short fract __fractutauqq (unsigned long 1902 long accum A) 1903 -- Runtime Function: unsigned fract __fractutauhq (unsigned long long 1904 accum A) 1905 -- Runtime Function: unsigned long fract __fractutausq (unsigned long 1906 long accum A) 1907 -- Runtime Function: unsigned long long fract __fractutaudq (unsigned 1908 long long accum A) 1909 -- Runtime Function: unsigned short accum __fractutauha2 (unsigned long 1910 long accum A) 1911 -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long 1912 accum A) 1913 -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long 1914 long accum A) 1915 -- Runtime Function: signed char __fractutaqi (unsigned long long accum 1916 A) 1917 -- Runtime Function: short __fractutahi (unsigned long long accum A) 1918 -- Runtime Function: int __fractutasi (unsigned long long accum A) 1919 -- Runtime Function: long __fractutadi (unsigned long long accum A) 1920 -- Runtime Function: long long __fractutati (unsigned long long accum 1921 A) 1922 -- Runtime Function: float __fractutasf (unsigned long long accum A) 1923 -- Runtime Function: double __fractutadf (unsigned long long accum A) 1924 -- Runtime Function: short fract __fractqiqq (signed char A) 1925 -- Runtime Function: fract __fractqihq (signed char A) 1926 -- Runtime Function: long fract __fractqisq (signed char A) 1927 -- Runtime Function: long long fract __fractqidq (signed char A) 1928 -- Runtime Function: short accum __fractqiha (signed char A) 1929 -- Runtime Function: accum __fractqisa (signed char A) 1930 -- Runtime Function: long accum __fractqida (signed char A) 1931 -- Runtime Function: long long accum __fractqita (signed char A) 1932 -- Runtime Function: unsigned short fract __fractqiuqq (signed char A) 1933 -- Runtime Function: unsigned fract __fractqiuhq (signed char A) 1934 -- Runtime Function: unsigned long fract __fractqiusq (signed char A) 1935 -- Runtime Function: unsigned long long fract __fractqiudq (signed char 1936 A) 1937 -- Runtime Function: unsigned short accum __fractqiuha (signed char A) 1938 -- Runtime Function: unsigned accum __fractqiusa (signed char A) 1939 -- Runtime Function: unsigned long accum __fractqiuda (signed char A) 1940 -- Runtime Function: unsigned long long accum __fractqiuta (signed char 1941 A) 1942 -- Runtime Function: short fract __fracthiqq (short A) 1943 -- Runtime Function: fract __fracthihq (short A) 1944 -- Runtime Function: long fract __fracthisq (short A) 1945 -- Runtime Function: long long fract __fracthidq (short A) 1946 -- Runtime Function: short accum __fracthiha (short A) 1947 -- Runtime Function: accum __fracthisa (short A) 1948 -- Runtime Function: long accum __fracthida (short A) 1949 -- Runtime Function: long long accum __fracthita (short A) 1950 -- Runtime Function: unsigned short fract __fracthiuqq (short A) 1951 -- Runtime Function: unsigned fract __fracthiuhq (short A) 1952 -- Runtime Function: unsigned long fract __fracthiusq (short A) 1953 -- Runtime Function: unsigned long long fract __fracthiudq (short A) 1954 -- Runtime Function: unsigned short accum __fracthiuha (short A) 1955 -- Runtime Function: unsigned accum __fracthiusa (short A) 1956 -- Runtime Function: unsigned long accum __fracthiuda (short A) 1957 -- Runtime Function: unsigned long long accum __fracthiuta (short A) 1958 -- Runtime Function: short fract __fractsiqq (int A) 1959 -- Runtime Function: fract __fractsihq (int A) 1960 -- Runtime Function: long fract __fractsisq (int A) 1961 -- Runtime Function: long long fract __fractsidq (int A) 1962 -- Runtime Function: short accum __fractsiha (int A) 1963 -- Runtime Function: accum __fractsisa (int A) 1964 -- Runtime Function: long accum __fractsida (int A) 1965 -- Runtime Function: long long accum __fractsita (int A) 1966 -- Runtime Function: unsigned short fract __fractsiuqq (int A) 1967 -- Runtime Function: unsigned fract __fractsiuhq (int A) 1968 -- Runtime Function: unsigned long fract __fractsiusq (int A) 1969 -- Runtime Function: unsigned long long fract __fractsiudq (int A) 1970 -- Runtime Function: unsigned short accum __fractsiuha (int A) 1971 -- Runtime Function: unsigned accum __fractsiusa (int A) 1972 -- Runtime Function: unsigned long accum __fractsiuda (int A) 1973 -- Runtime Function: unsigned long long accum __fractsiuta (int A) 1974 -- Runtime Function: short fract __fractdiqq (long A) 1975 -- Runtime Function: fract __fractdihq (long A) 1976 -- Runtime Function: long fract __fractdisq (long A) 1977 -- Runtime Function: long long fract __fractdidq (long A) 1978 -- Runtime Function: short accum __fractdiha (long A) 1979 -- Runtime Function: accum __fractdisa (long A) 1980 -- Runtime Function: long accum __fractdida (long A) 1981 -- Runtime Function: long long accum __fractdita (long A) 1982 -- Runtime Function: unsigned short fract __fractdiuqq (long A) 1983 -- Runtime Function: unsigned fract __fractdiuhq (long A) 1984 -- Runtime Function: unsigned long fract __fractdiusq (long A) 1985 -- Runtime Function: unsigned long long fract __fractdiudq (long A) 1986 -- Runtime Function: unsigned short accum __fractdiuha (long A) 1987 -- Runtime Function: unsigned accum __fractdiusa (long A) 1988 -- Runtime Function: unsigned long accum __fractdiuda (long A) 1989 -- Runtime Function: unsigned long long accum __fractdiuta (long A) 1990 -- Runtime Function: short fract __fracttiqq (long long A) 1991 -- Runtime Function: fract __fracttihq (long long A) 1992 -- Runtime Function: long fract __fracttisq (long long A) 1993 -- Runtime Function: long long fract __fracttidq (long long A) 1994 -- Runtime Function: short accum __fracttiha (long long A) 1995 -- Runtime Function: accum __fracttisa (long long A) 1996 -- Runtime Function: long accum __fracttida (long long A) 1997 -- Runtime Function: long long accum __fracttita (long long A) 1998 -- Runtime Function: unsigned short fract __fracttiuqq (long long A) 1999 -- Runtime Function: unsigned fract __fracttiuhq (long long A) 2000 -- Runtime Function: unsigned long fract __fracttiusq (long long A) 2001 -- Runtime Function: unsigned long long fract __fracttiudq (long long 2002 A) 2003 -- Runtime Function: unsigned short accum __fracttiuha (long long A) 2004 -- Runtime Function: unsigned accum __fracttiusa (long long A) 2005 -- Runtime Function: unsigned long accum __fracttiuda (long long A) 2006 -- Runtime Function: unsigned long long accum __fracttiuta (long long 2007 A) 2008 -- Runtime Function: short fract __fractsfqq (float A) 2009 -- Runtime Function: fract __fractsfhq (float A) 2010 -- Runtime Function: long fract __fractsfsq (float A) 2011 -- Runtime Function: long long fract __fractsfdq (float A) 2012 -- Runtime Function: short accum __fractsfha (float A) 2013 -- Runtime Function: accum __fractsfsa (float A) 2014 -- Runtime Function: long accum __fractsfda (float A) 2015 -- Runtime Function: long long accum __fractsfta (float A) 2016 -- Runtime Function: unsigned short fract __fractsfuqq (float A) 2017 -- Runtime Function: unsigned fract __fractsfuhq (float A) 2018 -- Runtime Function: unsigned long fract __fractsfusq (float A) 2019 -- Runtime Function: unsigned long long fract __fractsfudq (float A) 2020 -- Runtime Function: unsigned short accum __fractsfuha (float A) 2021 -- Runtime Function: unsigned accum __fractsfusa (float A) 2022 -- Runtime Function: unsigned long accum __fractsfuda (float A) 2023 -- Runtime Function: unsigned long long accum __fractsfuta (float A) 2024 -- Runtime Function: short fract __fractdfqq (double A) 2025 -- Runtime Function: fract __fractdfhq (double A) 2026 -- Runtime Function: long fract __fractdfsq (double A) 2027 -- Runtime Function: long long fract __fractdfdq (double A) 2028 -- Runtime Function: short accum __fractdfha (double A) 2029 -- Runtime Function: accum __fractdfsa (double A) 2030 -- Runtime Function: long accum __fractdfda (double A) 2031 -- Runtime Function: long long accum __fractdfta (double A) 2032 -- Runtime Function: unsigned short fract __fractdfuqq (double A) 2033 -- Runtime Function: unsigned fract __fractdfuhq (double A) 2034 -- Runtime Function: unsigned long fract __fractdfusq (double A) 2035 -- Runtime Function: unsigned long long fract __fractdfudq (double A) 2036 -- Runtime Function: unsigned short accum __fractdfuha (double A) 2037 -- Runtime Function: unsigned accum __fractdfusa (double A) 2038 -- Runtime Function: unsigned long accum __fractdfuda (double A) 2039 -- Runtime Function: unsigned long long accum __fractdfuta (double A) 2040 These functions convert from fractional and signed non-fractionals 2041 to fractionals and signed non-fractionals, without saturation. 2042 2043 -- Runtime Function: fract __satfractqqhq2 (short fract A) 2044 -- Runtime Function: long fract __satfractqqsq2 (short fract A) 2045 -- Runtime Function: long long fract __satfractqqdq2 (short fract A) 2046 -- Runtime Function: short accum __satfractqqha (short fract A) 2047 -- Runtime Function: accum __satfractqqsa (short fract A) 2048 -- Runtime Function: long accum __satfractqqda (short fract A) 2049 -- Runtime Function: long long accum __satfractqqta (short fract A) 2050 -- Runtime Function: unsigned short fract __satfractqquqq (short fract 2051 A) 2052 -- Runtime Function: unsigned fract __satfractqquhq (short fract A) 2053 -- Runtime Function: unsigned long fract __satfractqqusq (short fract 2054 A) 2055 -- Runtime Function: unsigned long long fract __satfractqqudq (short 2056 fract A) 2057 -- Runtime Function: unsigned short accum __satfractqquha (short fract 2058 A) 2059 -- Runtime Function: unsigned accum __satfractqqusa (short fract A) 2060 -- Runtime Function: unsigned long accum __satfractqquda (short fract 2061 A) 2062 -- Runtime Function: unsigned long long accum __satfractqquta (short 2063 fract A) 2064 -- Runtime Function: short fract __satfracthqqq2 (fract A) 2065 -- Runtime Function: long fract __satfracthqsq2 (fract A) 2066 -- Runtime Function: long long fract __satfracthqdq2 (fract A) 2067 -- Runtime Function: short accum __satfracthqha (fract A) 2068 -- Runtime Function: accum __satfracthqsa (fract A) 2069 -- Runtime Function: long accum __satfracthqda (fract A) 2070 -- Runtime Function: long long accum __satfracthqta (fract A) 2071 -- Runtime Function: unsigned short fract __satfracthquqq (fract A) 2072 -- Runtime Function: unsigned fract __satfracthquhq (fract A) 2073 -- Runtime Function: unsigned long fract __satfracthqusq (fract A) 2074 -- Runtime Function: unsigned long long fract __satfracthqudq (fract A) 2075 -- Runtime Function: unsigned short accum __satfracthquha (fract A) 2076 -- Runtime Function: unsigned accum __satfracthqusa (fract A) 2077 -- Runtime Function: unsigned long accum __satfracthquda (fract A) 2078 -- Runtime Function: unsigned long long accum __satfracthquta (fract A) 2079 -- Runtime Function: short fract __satfractsqqq2 (long fract A) 2080 -- Runtime Function: fract __satfractsqhq2 (long fract A) 2081 -- Runtime Function: long long fract __satfractsqdq2 (long fract A) 2082 -- Runtime Function: short accum __satfractsqha (long fract A) 2083 -- Runtime Function: accum __satfractsqsa (long fract A) 2084 -- Runtime Function: long accum __satfractsqda (long fract A) 2085 -- Runtime Function: long long accum __satfractsqta (long fract A) 2086 -- Runtime Function: unsigned short fract __satfractsquqq (long fract 2087 A) 2088 -- Runtime Function: unsigned fract __satfractsquhq (long fract A) 2089 -- Runtime Function: unsigned long fract __satfractsqusq (long fract A) 2090 -- Runtime Function: unsigned long long fract __satfractsqudq (long 2091 fract A) 2092 -- Runtime Function: unsigned short accum __satfractsquha (long fract 2093 A) 2094 -- Runtime Function: unsigned accum __satfractsqusa (long fract A) 2095 -- Runtime Function: unsigned long accum __satfractsquda (long fract A) 2096 -- Runtime Function: unsigned long long accum __satfractsquta (long 2097 fract A) 2098 -- Runtime Function: short fract __satfractdqqq2 (long long fract A) 2099 -- Runtime Function: fract __satfractdqhq2 (long long fract A) 2100 -- Runtime Function: long fract __satfractdqsq2 (long long fract A) 2101 -- Runtime Function: short accum __satfractdqha (long long fract A) 2102 -- Runtime Function: accum __satfractdqsa (long long fract A) 2103 -- Runtime Function: long accum __satfractdqda (long long fract A) 2104 -- Runtime Function: long long accum __satfractdqta (long long fract A) 2105 -- Runtime Function: unsigned short fract __satfractdquqq (long long 2106 fract A) 2107 -- Runtime Function: unsigned fract __satfractdquhq (long long fract A) 2108 -- Runtime Function: unsigned long fract __satfractdqusq (long long 2109 fract A) 2110 -- Runtime Function: unsigned long long fract __satfractdqudq (long 2111 long fract A) 2112 -- Runtime Function: unsigned short accum __satfractdquha (long long 2113 fract A) 2114 -- Runtime Function: unsigned accum __satfractdqusa (long long fract A) 2115 -- Runtime Function: unsigned long accum __satfractdquda (long long 2116 fract A) 2117 -- Runtime Function: unsigned long long accum __satfractdquta (long 2118 long fract A) 2119 -- Runtime Function: short fract __satfracthaqq (short accum A) 2120 -- Runtime Function: fract __satfracthahq (short accum A) 2121 -- Runtime Function: long fract __satfracthasq (short accum A) 2122 -- Runtime Function: long long fract __satfracthadq (short accum A) 2123 -- Runtime Function: accum __satfracthasa2 (short accum A) 2124 -- Runtime Function: long accum __satfracthada2 (short accum A) 2125 -- Runtime Function: long long accum __satfracthata2 (short accum A) 2126 -- Runtime Function: unsigned short fract __satfracthauqq (short accum 2127 A) 2128 -- Runtime Function: unsigned fract __satfracthauhq (short accum A) 2129 -- Runtime Function: unsigned long fract __satfracthausq (short accum 2130 A) 2131 -- Runtime Function: unsigned long long fract __satfracthaudq (short 2132 accum A) 2133 -- Runtime Function: unsigned short accum __satfracthauha (short accum 2134 A) 2135 -- Runtime Function: unsigned accum __satfracthausa (short accum A) 2136 -- Runtime Function: unsigned long accum __satfracthauda (short accum 2137 A) 2138 -- Runtime Function: unsigned long long accum __satfracthauta (short 2139 accum A) 2140 -- Runtime Function: short fract __satfractsaqq (accum A) 2141 -- Runtime Function: fract __satfractsahq (accum A) 2142 -- Runtime Function: long fract __satfractsasq (accum A) 2143 -- Runtime Function: long long fract __satfractsadq (accum A) 2144 -- Runtime Function: short accum __satfractsaha2 (accum A) 2145 -- Runtime Function: long accum __satfractsada2 (accum A) 2146 -- Runtime Function: long long accum __satfractsata2 (accum A) 2147 -- Runtime Function: unsigned short fract __satfractsauqq (accum A) 2148 -- Runtime Function: unsigned fract __satfractsauhq (accum A) 2149 -- Runtime Function: unsigned long fract __satfractsausq (accum A) 2150 -- Runtime Function: unsigned long long fract __satfractsaudq (accum A) 2151 -- Runtime Function: unsigned short accum __satfractsauha (accum A) 2152 -- Runtime Function: unsigned accum __satfractsausa (accum A) 2153 -- Runtime Function: unsigned long accum __satfractsauda (accum A) 2154 -- Runtime Function: unsigned long long accum __satfractsauta (accum A) 2155 -- Runtime Function: short fract __satfractdaqq (long accum A) 2156 -- Runtime Function: fract __satfractdahq (long accum A) 2157 -- Runtime Function: long fract __satfractdasq (long accum A) 2158 -- Runtime Function: long long fract __satfractdadq (long accum A) 2159 -- Runtime Function: short accum __satfractdaha2 (long accum A) 2160 -- Runtime Function: accum __satfractdasa2 (long accum A) 2161 -- Runtime Function: long long accum __satfractdata2 (long accum A) 2162 -- Runtime Function: unsigned short fract __satfractdauqq (long accum 2163 A) 2164 -- Runtime Function: unsigned fract __satfractdauhq (long accum A) 2165 -- Runtime Function: unsigned long fract __satfractdausq (long accum A) 2166 -- Runtime Function: unsigned long long fract __satfractdaudq (long 2167 accum A) 2168 -- Runtime Function: unsigned short accum __satfractdauha (long accum 2169 A) 2170 -- Runtime Function: unsigned accum __satfractdausa (long accum A) 2171 -- Runtime Function: unsigned long accum __satfractdauda (long accum A) 2172 -- Runtime Function: unsigned long long accum __satfractdauta (long 2173 accum A) 2174 -- Runtime Function: short fract __satfracttaqq (long long accum A) 2175 -- Runtime Function: fract __satfracttahq (long long accum A) 2176 -- Runtime Function: long fract __satfracttasq (long long accum A) 2177 -- Runtime Function: long long fract __satfracttadq (long long accum A) 2178 -- Runtime Function: short accum __satfracttaha2 (long long accum A) 2179 -- Runtime Function: accum __satfracttasa2 (long long accum A) 2180 -- Runtime Function: long accum __satfracttada2 (long long accum A) 2181 -- Runtime Function: unsigned short fract __satfracttauqq (long long 2182 accum A) 2183 -- Runtime Function: unsigned fract __satfracttauhq (long long accum A) 2184 -- Runtime Function: unsigned long fract __satfracttausq (long long 2185 accum A) 2186 -- Runtime Function: unsigned long long fract __satfracttaudq (long 2187 long accum A) 2188 -- Runtime Function: unsigned short accum __satfracttauha (long long 2189 accum A) 2190 -- Runtime Function: unsigned accum __satfracttausa (long long accum A) 2191 -- Runtime Function: unsigned long accum __satfracttauda (long long 2192 accum A) 2193 -- Runtime Function: unsigned long long accum __satfracttauta (long 2194 long accum A) 2195 -- Runtime Function: short fract __satfractuqqqq (unsigned short fract 2196 A) 2197 -- Runtime Function: fract __satfractuqqhq (unsigned short fract A) 2198 -- Runtime Function: long fract __satfractuqqsq (unsigned short fract 2199 A) 2200 -- Runtime Function: long long fract __satfractuqqdq (unsigned short 2201 fract A) 2202 -- Runtime Function: short accum __satfractuqqha (unsigned short fract 2203 A) 2204 -- Runtime Function: accum __satfractuqqsa (unsigned short fract A) 2205 -- Runtime Function: long accum __satfractuqqda (unsigned short fract 2206 A) 2207 -- Runtime Function: long long accum __satfractuqqta (unsigned short 2208 fract A) 2209 -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short 2210 fract A) 2211 -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned 2212 short fract A) 2213 -- Runtime Function: unsigned long long fract __satfractuqqudq2 2214 (unsigned short fract A) 2215 -- Runtime Function: unsigned short accum __satfractuqquha (unsigned 2216 short fract A) 2217 -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short 2218 fract A) 2219 -- Runtime Function: unsigned long accum __satfractuqquda (unsigned 2220 short fract A) 2221 -- Runtime Function: unsigned long long accum __satfractuqquta 2222 (unsigned short fract A) 2223 -- Runtime Function: short fract __satfractuhqqq (unsigned fract A) 2224 -- Runtime Function: fract __satfractuhqhq (unsigned fract A) 2225 -- Runtime Function: long fract __satfractuhqsq (unsigned fract A) 2226 -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A) 2227 -- Runtime Function: short accum __satfractuhqha (unsigned fract A) 2228 -- Runtime Function: accum __satfractuhqsa (unsigned fract A) 2229 -- Runtime Function: long accum __satfractuhqda (unsigned fract A) 2230 -- Runtime Function: long long accum __satfractuhqta (unsigned fract A) 2231 -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned 2232 fract A) 2233 -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned 2234 fract A) 2235 -- Runtime Function: unsigned long long fract __satfractuhqudq2 2236 (unsigned fract A) 2237 -- Runtime Function: unsigned short accum __satfractuhquha (unsigned 2238 fract A) 2239 -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A) 2240 -- Runtime Function: unsigned long accum __satfractuhquda (unsigned 2241 fract A) 2242 -- Runtime Function: unsigned long long accum __satfractuhquta 2243 (unsigned fract A) 2244 -- Runtime Function: short fract __satfractusqqq (unsigned long fract 2245 A) 2246 -- Runtime Function: fract __satfractusqhq (unsigned long fract A) 2247 -- Runtime Function: long fract __satfractusqsq (unsigned long fract A) 2248 -- Runtime Function: long long fract __satfractusqdq (unsigned long 2249 fract A) 2250 -- Runtime Function: short accum __satfractusqha (unsigned long fract 2251 A) 2252 -- Runtime Function: accum __satfractusqsa (unsigned long fract A) 2253 -- Runtime Function: long accum __satfractusqda (unsigned long fract A) 2254 -- Runtime Function: long long accum __satfractusqta (unsigned long 2255 fract A) 2256 -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned 2257 long fract A) 2258 -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long 2259 fract A) 2260 -- Runtime Function: unsigned long long fract __satfractusqudq2 2261 (unsigned long fract A) 2262 -- Runtime Function: unsigned short accum __satfractusquha (unsigned 2263 long fract A) 2264 -- Runtime Function: unsigned accum __satfractusqusa (unsigned long 2265 fract A) 2266 -- Runtime Function: unsigned long accum __satfractusquda (unsigned 2267 long fract A) 2268 -- Runtime Function: unsigned long long accum __satfractusquta 2269 (unsigned long fract A) 2270 -- Runtime Function: short fract __satfractudqqq (unsigned long long 2271 fract A) 2272 -- Runtime Function: fract __satfractudqhq (unsigned long long fract A) 2273 -- Runtime Function: long fract __satfractudqsq (unsigned long long 2274 fract A) 2275 -- Runtime Function: long long fract __satfractudqdq (unsigned long 2276 long fract A) 2277 -- Runtime Function: short accum __satfractudqha (unsigned long long 2278 fract A) 2279 -- Runtime Function: accum __satfractudqsa (unsigned long long fract A) 2280 -- Runtime Function: long accum __satfractudqda (unsigned long long 2281 fract A) 2282 -- Runtime Function: long long accum __satfractudqta (unsigned long 2283 long fract A) 2284 -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned 2285 long long fract A) 2286 -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long 2287 long fract A) 2288 -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned 2289 long long fract A) 2290 -- Runtime Function: unsigned short accum __satfractudquha (unsigned 2291 long long fract A) 2292 -- Runtime Function: unsigned accum __satfractudqusa (unsigned long 2293 long fract A) 2294 -- Runtime Function: unsigned long accum __satfractudquda (unsigned 2295 long long fract A) 2296 -- Runtime Function: unsigned long long accum __satfractudquta 2297 (unsigned long long fract A) 2298 -- Runtime Function: short fract __satfractuhaqq (unsigned short accum 2299 A) 2300 -- Runtime Function: fract __satfractuhahq (unsigned short accum A) 2301 -- Runtime Function: long fract __satfractuhasq (unsigned short accum 2302 A) 2303 -- Runtime Function: long long fract __satfractuhadq (unsigned short 2304 accum A) 2305 -- Runtime Function: short accum __satfractuhaha (unsigned short accum 2306 A) 2307 -- Runtime Function: accum __satfractuhasa (unsigned short accum A) 2308 -- Runtime Function: long accum __satfractuhada (unsigned short accum 2309 A) 2310 -- Runtime Function: long long accum __satfractuhata (unsigned short 2311 accum A) 2312 -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned 2313 short accum A) 2314 -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short 2315 accum A) 2316 -- Runtime Function: unsigned long fract __satfractuhausq (unsigned 2317 short accum A) 2318 -- Runtime Function: unsigned long long fract __satfractuhaudq 2319 (unsigned short accum A) 2320 -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short 2321 accum A) 2322 -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned 2323 short accum A) 2324 -- Runtime Function: unsigned long long accum __satfractuhauta2 2325 (unsigned short accum A) 2326 -- Runtime Function: short fract __satfractusaqq (unsigned accum A) 2327 -- Runtime Function: fract __satfractusahq (unsigned accum A) 2328 -- Runtime Function: long fract __satfractusasq (unsigned accum A) 2329 -- Runtime Function: long long fract __satfractusadq (unsigned accum A) 2330 -- Runtime Function: short accum __satfractusaha (unsigned accum A) 2331 -- Runtime Function: accum __satfractusasa (unsigned accum A) 2332 -- Runtime Function: long accum __satfractusada (unsigned accum A) 2333 -- Runtime Function: long long accum __satfractusata (unsigned accum A) 2334 -- Runtime Function: unsigned short fract __satfractusauqq (unsigned 2335 accum A) 2336 -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A) 2337 -- Runtime Function: unsigned long fract __satfractusausq (unsigned 2338 accum A) 2339 -- Runtime Function: unsigned long long fract __satfractusaudq 2340 (unsigned accum A) 2341 -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned 2342 accum A) 2343 -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned 2344 accum A) 2345 -- Runtime Function: unsigned long long accum __satfractusauta2 2346 (unsigned accum A) 2347 -- Runtime Function: short fract __satfractudaqq (unsigned long accum 2348 A) 2349 -- Runtime Function: fract __satfractudahq (unsigned long accum A) 2350 -- Runtime Function: long fract __satfractudasq (unsigned long accum A) 2351 -- Runtime Function: long long fract __satfractudadq (unsigned long 2352 accum A) 2353 -- Runtime Function: short accum __satfractudaha (unsigned long accum 2354 A) 2355 -- Runtime Function: accum __satfractudasa (unsigned long accum A) 2356 -- Runtime Function: long accum __satfractudada (unsigned long accum A) 2357 -- Runtime Function: long long accum __satfractudata (unsigned long 2358 accum A) 2359 -- Runtime Function: unsigned short fract __satfractudauqq (unsigned 2360 long accum A) 2361 -- Runtime Function: unsigned fract __satfractudauhq (unsigned long 2362 accum A) 2363 -- Runtime Function: unsigned long fract __satfractudausq (unsigned 2364 long accum A) 2365 -- Runtime Function: unsigned long long fract __satfractudaudq 2366 (unsigned long accum A) 2367 -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned 2368 long accum A) 2369 -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long 2370 accum A) 2371 -- Runtime Function: unsigned long long accum __satfractudauta2 2372 (unsigned long accum A) 2373 -- Runtime Function: short fract __satfractutaqq (unsigned long long 2374 accum A) 2375 -- Runtime Function: fract __satfractutahq (unsigned long long accum A) 2376 -- Runtime Function: long fract __satfractutasq (unsigned long long 2377 accum A) 2378 -- Runtime Function: long long fract __satfractutadq (unsigned long 2379 long accum A) 2380 -- Runtime Function: short accum __satfractutaha (unsigned long long 2381 accum A) 2382 -- Runtime Function: accum __satfractutasa (unsigned long long accum A) 2383 -- Runtime Function: long accum __satfractutada (unsigned long long 2384 accum A) 2385 -- Runtime Function: long long accum __satfractutata (unsigned long 2386 long accum A) 2387 -- Runtime Function: unsigned short fract __satfractutauqq (unsigned 2388 long long accum A) 2389 -- Runtime Function: unsigned fract __satfractutauhq (unsigned long 2390 long accum A) 2391 -- Runtime Function: unsigned long fract __satfractutausq (unsigned 2392 long long accum A) 2393 -- Runtime Function: unsigned long long fract __satfractutaudq 2394 (unsigned long long accum A) 2395 -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned 2396 long long accum A) 2397 -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long 2398 long accum A) 2399 -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned 2400 long long accum A) 2401 -- Runtime Function: short fract __satfractqiqq (signed char A) 2402 -- Runtime Function: fract __satfractqihq (signed char A) 2403 -- Runtime Function: long fract __satfractqisq (signed char A) 2404 -- Runtime Function: long long fract __satfractqidq (signed char A) 2405 -- Runtime Function: short accum __satfractqiha (signed char A) 2406 -- Runtime Function: accum __satfractqisa (signed char A) 2407 -- Runtime Function: long accum __satfractqida (signed char A) 2408 -- Runtime Function: long long accum __satfractqita (signed char A) 2409 -- Runtime Function: unsigned short fract __satfractqiuqq (signed char 2410 A) 2411 -- Runtime Function: unsigned fract __satfractqiuhq (signed char A) 2412 -- Runtime Function: unsigned long fract __satfractqiusq (signed char 2413 A) 2414 -- Runtime Function: unsigned long long fract __satfractqiudq (signed 2415 char A) 2416 -- Runtime Function: unsigned short accum __satfractqiuha (signed char 2417 A) 2418 -- Runtime Function: unsigned accum __satfractqiusa (signed char A) 2419 -- Runtime Function: unsigned long accum __satfractqiuda (signed char 2420 A) 2421 -- Runtime Function: unsigned long long accum __satfractqiuta (signed 2422 char A) 2423 -- Runtime Function: short fract __satfracthiqq (short A) 2424 -- Runtime Function: fract __satfracthihq (short A) 2425 -- Runtime Function: long fract __satfracthisq (short A) 2426 -- Runtime Function: long long fract __satfracthidq (short A) 2427 -- Runtime Function: short accum __satfracthiha (short A) 2428 -- Runtime Function: accum __satfracthisa (short A) 2429 -- Runtime Function: long accum __satfracthida (short A) 2430 -- Runtime Function: long long accum __satfracthita (short A) 2431 -- Runtime Function: unsigned short fract __satfracthiuqq (short A) 2432 -- Runtime Function: unsigned fract __satfracthiuhq (short A) 2433 -- Runtime Function: unsigned long fract __satfracthiusq (short A) 2434 -- Runtime Function: unsigned long long fract __satfracthiudq (short A) 2435 -- Runtime Function: unsigned short accum __satfracthiuha (short A) 2436 -- Runtime Function: unsigned accum __satfracthiusa (short A) 2437 -- Runtime Function: unsigned long accum __satfracthiuda (short A) 2438 -- Runtime Function: unsigned long long accum __satfracthiuta (short A) 2439 -- Runtime Function: short fract __satfractsiqq (int A) 2440 -- Runtime Function: fract __satfractsihq (int A) 2441 -- Runtime Function: long fract __satfractsisq (int A) 2442 -- Runtime Function: long long fract __satfractsidq (int A) 2443 -- Runtime Function: short accum __satfractsiha (int A) 2444 -- Runtime Function: accum __satfractsisa (int A) 2445 -- Runtime Function: long accum __satfractsida (int A) 2446 -- Runtime Function: long long accum __satfractsita (int A) 2447 -- Runtime Function: unsigned short fract __satfractsiuqq (int A) 2448 -- Runtime Function: unsigned fract __satfractsiuhq (int A) 2449 -- Runtime Function: unsigned long fract __satfractsiusq (int A) 2450 -- Runtime Function: unsigned long long fract __satfractsiudq (int A) 2451 -- Runtime Function: unsigned short accum __satfractsiuha (int A) 2452 -- Runtime Function: unsigned accum __satfractsiusa (int A) 2453 -- Runtime Function: unsigned long accum __satfractsiuda (int A) 2454 -- Runtime Function: unsigned long long accum __satfractsiuta (int A) 2455 -- Runtime Function: short fract __satfractdiqq (long A) 2456 -- Runtime Function: fract __satfractdihq (long A) 2457 -- Runtime Function: long fract __satfractdisq (long A) 2458 -- Runtime Function: long long fract __satfractdidq (long A) 2459 -- Runtime Function: short accum __satfractdiha (long A) 2460 -- Runtime Function: accum __satfractdisa (long A) 2461 -- Runtime Function: long accum __satfractdida (long A) 2462 -- Runtime Function: long long accum __satfractdita (long A) 2463 -- Runtime Function: unsigned short fract __satfractdiuqq (long A) 2464 -- Runtime Function: unsigned fract __satfractdiuhq (long A) 2465 -- Runtime Function: unsigned long fract __satfractdiusq (long A) 2466 -- Runtime Function: unsigned long long fract __satfractdiudq (long A) 2467 -- Runtime Function: unsigned short accum __satfractdiuha (long A) 2468 -- Runtime Function: unsigned accum __satfractdiusa (long A) 2469 -- Runtime Function: unsigned long accum __satfractdiuda (long A) 2470 -- Runtime Function: unsigned long long accum __satfractdiuta (long A) 2471 -- Runtime Function: short fract __satfracttiqq (long long A) 2472 -- Runtime Function: fract __satfracttihq (long long A) 2473 -- Runtime Function: long fract __satfracttisq (long long A) 2474 -- Runtime Function: long long fract __satfracttidq (long long A) 2475 -- Runtime Function: short accum __satfracttiha (long long A) 2476 -- Runtime Function: accum __satfracttisa (long long A) 2477 -- Runtime Function: long accum __satfracttida (long long A) 2478 -- Runtime Function: long long accum __satfracttita (long long A) 2479 -- Runtime Function: unsigned short fract __satfracttiuqq (long long A) 2480 -- Runtime Function: unsigned fract __satfracttiuhq (long long A) 2481 -- Runtime Function: unsigned long fract __satfracttiusq (long long A) 2482 -- Runtime Function: unsigned long long fract __satfracttiudq (long 2483 long A) 2484 -- Runtime Function: unsigned short accum __satfracttiuha (long long A) 2485 -- Runtime Function: unsigned accum __satfracttiusa (long long A) 2486 -- Runtime Function: unsigned long accum __satfracttiuda (long long A) 2487 -- Runtime Function: unsigned long long accum __satfracttiuta (long 2488 long A) 2489 -- Runtime Function: short fract __satfractsfqq (float A) 2490 -- Runtime Function: fract __satfractsfhq (float A) 2491 -- Runtime Function: long fract __satfractsfsq (float A) 2492 -- Runtime Function: long long fract __satfractsfdq (float A) 2493 -- Runtime Function: short accum __satfractsfha (float A) 2494 -- Runtime Function: accum __satfractsfsa (float A) 2495 -- Runtime Function: long accum __satfractsfda (float A) 2496 -- Runtime Function: long long accum __satfractsfta (float A) 2497 -- Runtime Function: unsigned short fract __satfractsfuqq (float A) 2498 -- Runtime Function: unsigned fract __satfractsfuhq (float A) 2499 -- Runtime Function: unsigned long fract __satfractsfusq (float A) 2500 -- Runtime Function: unsigned long long fract __satfractsfudq (float A) 2501 -- Runtime Function: unsigned short accum __satfractsfuha (float A) 2502 -- Runtime Function: unsigned accum __satfractsfusa (float A) 2503 -- Runtime Function: unsigned long accum __satfractsfuda (float A) 2504 -- Runtime Function: unsigned long long accum __satfractsfuta (float A) 2505 -- Runtime Function: short fract __satfractdfqq (double A) 2506 -- Runtime Function: fract __satfractdfhq (double A) 2507 -- Runtime Function: long fract __satfractdfsq (double A) 2508 -- Runtime Function: long long fract __satfractdfdq (double A) 2509 -- Runtime Function: short accum __satfractdfha (double A) 2510 -- Runtime Function: accum __satfractdfsa (double A) 2511 -- Runtime Function: long accum __satfractdfda (double A) 2512 -- Runtime Function: long long accum __satfractdfta (double A) 2513 -- Runtime Function: unsigned short fract __satfractdfuqq (double A) 2514 -- Runtime Function: unsigned fract __satfractdfuhq (double A) 2515 -- Runtime Function: unsigned long fract __satfractdfusq (double A) 2516 -- Runtime Function: unsigned long long fract __satfractdfudq (double 2517 A) 2518 -- Runtime Function: unsigned short accum __satfractdfuha (double A) 2519 -- Runtime Function: unsigned accum __satfractdfusa (double A) 2520 -- Runtime Function: unsigned long accum __satfractdfuda (double A) 2521 -- Runtime Function: unsigned long long accum __satfractdfuta (double 2522 A) 2523 The functions convert from fractional and signed non-fractionals to 2524 fractionals, with saturation. 2525 2526 -- Runtime Function: unsigned char __fractunsqqqi (short fract A) 2527 -- Runtime Function: unsigned short __fractunsqqhi (short fract A) 2528 -- Runtime Function: unsigned int __fractunsqqsi (short fract A) 2529 -- Runtime Function: unsigned long __fractunsqqdi (short fract A) 2530 -- Runtime Function: unsigned long long __fractunsqqti (short fract A) 2531 -- Runtime Function: unsigned char __fractunshqqi (fract A) 2532 -- Runtime Function: unsigned short __fractunshqhi (fract A) 2533 -- Runtime Function: unsigned int __fractunshqsi (fract A) 2534 -- Runtime Function: unsigned long __fractunshqdi (fract A) 2535 -- Runtime Function: unsigned long long __fractunshqti (fract A) 2536 -- Runtime Function: unsigned char __fractunssqqi (long fract A) 2537 -- Runtime Function: unsigned short __fractunssqhi (long fract A) 2538 -- Runtime Function: unsigned int __fractunssqsi (long fract A) 2539 -- Runtime Function: unsigned long __fractunssqdi (long fract A) 2540 -- Runtime Function: unsigned long long __fractunssqti (long fract A) 2541 -- Runtime Function: unsigned char __fractunsdqqi (long long fract A) 2542 -- Runtime Function: unsigned short __fractunsdqhi (long long fract A) 2543 -- Runtime Function: unsigned int __fractunsdqsi (long long fract A) 2544 -- Runtime Function: unsigned long __fractunsdqdi (long long fract A) 2545 -- Runtime Function: unsigned long long __fractunsdqti (long long fract 2546 A) 2547 -- Runtime Function: unsigned char __fractunshaqi (short accum A) 2548 -- Runtime Function: unsigned short __fractunshahi (short accum A) 2549 -- Runtime Function: unsigned int __fractunshasi (short accum A) 2550 -- Runtime Function: unsigned long __fractunshadi (short accum A) 2551 -- Runtime Function: unsigned long long __fractunshati (short accum A) 2552 -- Runtime Function: unsigned char __fractunssaqi (accum A) 2553 -- Runtime Function: unsigned short __fractunssahi (accum A) 2554 -- Runtime Function: unsigned int __fractunssasi (accum A) 2555 -- Runtime Function: unsigned long __fractunssadi (accum A) 2556 -- Runtime Function: unsigned long long __fractunssati (accum A) 2557 -- Runtime Function: unsigned char __fractunsdaqi (long accum A) 2558 -- Runtime Function: unsigned short __fractunsdahi (long accum A) 2559 -- Runtime Function: unsigned int __fractunsdasi (long accum A) 2560 -- Runtime Function: unsigned long __fractunsdadi (long accum A) 2561 -- Runtime Function: unsigned long long __fractunsdati (long accum A) 2562 -- Runtime Function: unsigned char __fractunstaqi (long long accum A) 2563 -- Runtime Function: unsigned short __fractunstahi (long long accum A) 2564 -- Runtime Function: unsigned int __fractunstasi (long long accum A) 2565 -- Runtime Function: unsigned long __fractunstadi (long long accum A) 2566 -- Runtime Function: unsigned long long __fractunstati (long long accum 2567 A) 2568 -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short 2569 fract A) 2570 -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short 2571 fract A) 2572 -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short fract 2573 A) 2574 -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short 2575 fract A) 2576 -- Runtime Function: unsigned long long __fractunsuqqti (unsigned short 2577 fract A) 2578 -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A) 2579 -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A) 2580 -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A) 2581 -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A) 2582 -- Runtime Function: unsigned long long __fractunsuhqti (unsigned fract 2583 A) 2584 -- Runtime Function: unsigned char __fractunsusqqi (unsigned long fract 2585 A) 2586 -- Runtime Function: unsigned short __fractunsusqhi (unsigned long 2587 fract A) 2588 -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract 2589 A) 2590 -- Runtime Function: unsigned long __fractunsusqdi (unsigned long fract 2591 A) 2592 -- Runtime Function: unsigned long long __fractunsusqti (unsigned long 2593 fract A) 2594 -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long 2595 fract A) 2596 -- Runtime Function: unsigned short __fractunsudqhi (unsigned long long 2597 fract A) 2598 -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long 2599 fract A) 2600 -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long 2601 fract A) 2602 -- Runtime Function: unsigned long long __fractunsudqti (unsigned long 2603 long fract A) 2604 -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short 2605 accum A) 2606 -- Runtime Function: unsigned short __fractunsuhahi (unsigned short 2607 accum A) 2608 -- Runtime Function: unsigned int __fractunsuhasi (unsigned short accum 2609 A) 2610 -- Runtime Function: unsigned long __fractunsuhadi (unsigned short 2611 accum A) 2612 -- Runtime Function: unsigned long long __fractunsuhati (unsigned short 2613 accum A) 2614 -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A) 2615 -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A) 2616 -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A) 2617 -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A) 2618 -- Runtime Function: unsigned long long __fractunsusati (unsigned accum 2619 A) 2620 -- Runtime Function: unsigned char __fractunsudaqi (unsigned long accum 2621 A) 2622 -- Runtime Function: unsigned short __fractunsudahi (unsigned long 2623 accum A) 2624 -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum 2625 A) 2626 -- Runtime Function: unsigned long __fractunsudadi (unsigned long accum 2627 A) 2628 -- Runtime Function: unsigned long long __fractunsudati (unsigned long 2629 accum A) 2630 -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long 2631 accum A) 2632 -- Runtime Function: unsigned short __fractunsutahi (unsigned long long 2633 accum A) 2634 -- Runtime Function: unsigned int __fractunsutasi (unsigned long long 2635 accum A) 2636 -- Runtime Function: unsigned long __fractunsutadi (unsigned long long 2637 accum A) 2638 -- Runtime Function: unsigned long long __fractunsutati (unsigned long 2639 long accum A) 2640 -- Runtime Function: short fract __fractunsqiqq (unsigned char A) 2641 -- Runtime Function: fract __fractunsqihq (unsigned char A) 2642 -- Runtime Function: long fract __fractunsqisq (unsigned char A) 2643 -- Runtime Function: long long fract __fractunsqidq (unsigned char A) 2644 -- Runtime Function: short accum __fractunsqiha (unsigned char A) 2645 -- Runtime Function: accum __fractunsqisa (unsigned char A) 2646 -- Runtime Function: long accum __fractunsqida (unsigned char A) 2647 -- Runtime Function: long long accum __fractunsqita (unsigned char A) 2648 -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned 2649 char A) 2650 -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A) 2651 -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned char 2652 A) 2653 -- Runtime Function: unsigned long long fract __fractunsqiudq (unsigned 2654 char A) 2655 -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned 2656 char A) 2657 -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A) 2658 -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned char 2659 A) 2660 -- Runtime Function: unsigned long long accum __fractunsqiuta (unsigned 2661 char A) 2662 -- Runtime Function: short fract __fractunshiqq (unsigned short A) 2663 -- Runtime Function: fract __fractunshihq (unsigned short A) 2664 -- Runtime Function: long fract __fractunshisq (unsigned short A) 2665 -- Runtime Function: long long fract __fractunshidq (unsigned short A) 2666 -- Runtime Function: short accum __fractunshiha (unsigned short A) 2667 -- Runtime Function: accum __fractunshisa (unsigned short A) 2668 -- Runtime Function: long accum __fractunshida (unsigned short A) 2669 -- Runtime Function: long long accum __fractunshita (unsigned short A) 2670 -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned 2671 short A) 2672 -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A) 2673 -- Runtime Function: unsigned long fract __fractunshiusq (unsigned 2674 short A) 2675 -- Runtime Function: unsigned long long fract __fractunshiudq (unsigned 2676 short A) 2677 -- Runtime Function: unsigned short accum __fractunshiuha (unsigned 2678 short A) 2679 -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A) 2680 -- Runtime Function: unsigned long accum __fractunshiuda (unsigned 2681 short A) 2682 -- Runtime Function: unsigned long long accum __fractunshiuta (unsigned 2683 short A) 2684 -- Runtime Function: short fract __fractunssiqq (unsigned int A) 2685 -- Runtime Function: fract __fractunssihq (unsigned int A) 2686 -- Runtime Function: long fract __fractunssisq (unsigned int A) 2687 -- Runtime Function: long long fract __fractunssidq (unsigned int A) 2688 -- Runtime Function: short accum __fractunssiha (unsigned int A) 2689 -- Runtime Function: accum __fractunssisa (unsigned int A) 2690 -- Runtime Function: long accum __fractunssida (unsigned int A) 2691 -- Runtime Function: long long accum __fractunssita (unsigned int A) 2692 -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned int 2693 A) 2694 -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A) 2695 -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int 2696 A) 2697 -- Runtime Function: unsigned long long fract __fractunssiudq (unsigned 2698 int A) 2699 -- Runtime Function: unsigned short accum __fractunssiuha (unsigned int 2700 A) 2701 -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A) 2702 -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int 2703 A) 2704 -- Runtime Function: unsigned long long accum __fractunssiuta (unsigned 2705 int A) 2706 -- Runtime Function: short fract __fractunsdiqq (unsigned long A) 2707 -- Runtime Function: fract __fractunsdihq (unsigned long A) 2708 -- Runtime Function: long fract __fractunsdisq (unsigned long A) 2709 -- Runtime Function: long long fract __fractunsdidq (unsigned long A) 2710 -- Runtime Function: short accum __fractunsdiha (unsigned long A) 2711 -- Runtime Function: accum __fractunsdisa (unsigned long A) 2712 -- Runtime Function: long accum __fractunsdida (unsigned long A) 2713 -- Runtime Function: long long accum __fractunsdita (unsigned long A) 2714 -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned 2715 long A) 2716 -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A) 2717 -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned long 2718 A) 2719 -- Runtime Function: unsigned long long fract __fractunsdiudq (unsigned 2720 long A) 2721 -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned 2722 long A) 2723 -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A) 2724 -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned long 2725 A) 2726 -- Runtime Function: unsigned long long accum __fractunsdiuta (unsigned 2727 long A) 2728 -- Runtime Function: short fract __fractunstiqq (unsigned long long A) 2729 -- Runtime Function: fract __fractunstihq (unsigned long long A) 2730 -- Runtime Function: long fract __fractunstisq (unsigned long long A) 2731 -- Runtime Function: long long fract __fractunstidq (unsigned long long 2732 A) 2733 -- Runtime Function: short accum __fractunstiha (unsigned long long A) 2734 -- Runtime Function: accum __fractunstisa (unsigned long long A) 2735 -- Runtime Function: long accum __fractunstida (unsigned long long A) 2736 -- Runtime Function: long long accum __fractunstita (unsigned long long 2737 A) 2738 -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned 2739 long long A) 2740 -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long long 2741 A) 2742 -- Runtime Function: unsigned long fract __fractunstiusq (unsigned long 2743 long A) 2744 -- Runtime Function: unsigned long long fract __fractunstiudq (unsigned 2745 long long A) 2746 -- Runtime Function: unsigned short accum __fractunstiuha (unsigned 2747 long long A) 2748 -- Runtime Function: unsigned accum __fractunstiusa (unsigned long long 2749 A) 2750 -- Runtime Function: unsigned long accum __fractunstiuda (unsigned long 2751 long A) 2752 -- Runtime Function: unsigned long long accum __fractunstiuta (unsigned 2753 long long A) 2754 These functions convert from fractionals to unsigned 2755 non-fractionals; and from unsigned non-fractionals to fractionals, 2756 without saturation. 2757 2758 -- Runtime Function: short fract __satfractunsqiqq (unsigned char A) 2759 -- Runtime Function: fract __satfractunsqihq (unsigned char A) 2760 -- Runtime Function: long fract __satfractunsqisq (unsigned char A) 2761 -- Runtime Function: long long fract __satfractunsqidq (unsigned char 2762 A) 2763 -- Runtime Function: short accum __satfractunsqiha (unsigned char A) 2764 -- Runtime Function: accum __satfractunsqisa (unsigned char A) 2765 -- Runtime Function: long accum __satfractunsqida (unsigned char A) 2766 -- Runtime Function: long long accum __satfractunsqita (unsigned char 2767 A) 2768 -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned 2769 char A) 2770 -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char 2771 A) 2772 -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned 2773 char A) 2774 -- Runtime Function: unsigned long long fract __satfractunsqiudq 2775 (unsigned char A) 2776 -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned 2777 char A) 2778 -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char 2779 A) 2780 -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned 2781 char A) 2782 -- Runtime Function: unsigned long long accum __satfractunsqiuta 2783 (unsigned char A) 2784 -- Runtime Function: short fract __satfractunshiqq (unsigned short A) 2785 -- Runtime Function: fract __satfractunshihq (unsigned short A) 2786 -- Runtime Function: long fract __satfractunshisq (unsigned short A) 2787 -- Runtime Function: long long fract __satfractunshidq (unsigned short 2788 A) 2789 -- Runtime Function: short accum __satfractunshiha (unsigned short A) 2790 -- Runtime Function: accum __satfractunshisa (unsigned short A) 2791 -- Runtime Function: long accum __satfractunshida (unsigned short A) 2792 -- Runtime Function: long long accum __satfractunshita (unsigned short 2793 A) 2794 -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned 2795 short A) 2796 -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short 2797 A) 2798 -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned 2799 short A) 2800 -- Runtime Function: unsigned long long fract __satfractunshiudq 2801 (unsigned short A) 2802 -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned 2803 short A) 2804 -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short 2805 A) 2806 -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned 2807 short A) 2808 -- Runtime Function: unsigned long long accum __satfractunshiuta 2809 (unsigned short A) 2810 -- Runtime Function: short fract __satfractunssiqq (unsigned int A) 2811 -- Runtime Function: fract __satfractunssihq (unsigned int A) 2812 -- Runtime Function: long fract __satfractunssisq (unsigned int A) 2813 -- Runtime Function: long long fract __satfractunssidq (unsigned int A) 2814 -- Runtime Function: short accum __satfractunssiha (unsigned int A) 2815 -- Runtime Function: accum __satfractunssisa (unsigned int A) 2816 -- Runtime Function: long accum __satfractunssida (unsigned int A) 2817 -- Runtime Function: long long accum __satfractunssita (unsigned int A) 2818 -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned 2819 int A) 2820 -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A) 2821 -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned 2822 int A) 2823 -- Runtime Function: unsigned long long fract __satfractunssiudq 2824 (unsigned int A) 2825 -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned 2826 int A) 2827 -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A) 2828 -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned 2829 int A) 2830 -- Runtime Function: unsigned long long accum __satfractunssiuta 2831 (unsigned int A) 2832 -- Runtime Function: short fract __satfractunsdiqq (unsigned long A) 2833 -- Runtime Function: fract __satfractunsdihq (unsigned long A) 2834 -- Runtime Function: long fract __satfractunsdisq (unsigned long A) 2835 -- Runtime Function: long long fract __satfractunsdidq (unsigned long 2836 A) 2837 -- Runtime Function: short accum __satfractunsdiha (unsigned long A) 2838 -- Runtime Function: accum __satfractunsdisa (unsigned long A) 2839 -- Runtime Function: long accum __satfractunsdida (unsigned long A) 2840 -- Runtime Function: long long accum __satfractunsdita (unsigned long 2841 A) 2842 -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned 2843 long A) 2844 -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long 2845 A) 2846 -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned 2847 long A) 2848 -- Runtime Function: unsigned long long fract __satfractunsdiudq 2849 (unsigned long A) 2850 -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned 2851 long A) 2852 -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long 2853 A) 2854 -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned 2855 long A) 2856 -- Runtime Function: unsigned long long accum __satfractunsdiuta 2857 (unsigned long A) 2858 -- Runtime Function: short fract __satfractunstiqq (unsigned long long 2859 A) 2860 -- Runtime Function: fract __satfractunstihq (unsigned long long A) 2861 -- Runtime Function: long fract __satfractunstisq (unsigned long long 2862 A) 2863 -- Runtime Function: long long fract __satfractunstidq (unsigned long 2864 long A) 2865 -- Runtime Function: short accum __satfractunstiha (unsigned long long 2866 A) 2867 -- Runtime Function: accum __satfractunstisa (unsigned long long A) 2868 -- Runtime Function: long accum __satfractunstida (unsigned long long 2869 A) 2870 -- Runtime Function: long long accum __satfractunstita (unsigned long 2871 long A) 2872 -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned 2873 long long A) 2874 -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long 2875 long A) 2876 -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned 2877 long long A) 2878 -- Runtime Function: unsigned long long fract __satfractunstiudq 2879 (unsigned long long A) 2880 -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned 2881 long long A) 2882 -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long 2883 long A) 2884 -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned 2885 long long A) 2886 -- Runtime Function: unsigned long long accum __satfractunstiuta 2887 (unsigned long long A) 2888 These functions convert from unsigned non-fractionals to 2889 fractionals, with saturation. 2890 2891 2892File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Fixed-point fractional library routines, Up: Libgcc 2893 28944.5 Language-independent routines for exception handling 2895======================================================== 2896 2897document me! 2898 2899 _Unwind_DeleteException 2900 _Unwind_Find_FDE 2901 _Unwind_ForcedUnwind 2902 _Unwind_GetGR 2903 _Unwind_GetIP 2904 _Unwind_GetLanguageSpecificData 2905 _Unwind_GetRegionStart 2906 _Unwind_GetTextRelBase 2907 _Unwind_GetDataRelBase 2908 _Unwind_RaiseException 2909 _Unwind_Resume 2910 _Unwind_SetGR 2911 _Unwind_SetIP 2912 _Unwind_FindEnclosingFunction 2913 _Unwind_SjLj_Register 2914 _Unwind_SjLj_Unregister 2915 _Unwind_SjLj_RaiseException 2916 _Unwind_SjLj_ForcedUnwind 2917 _Unwind_SjLj_Resume 2918 __deregister_frame 2919 __deregister_frame_info 2920 __deregister_frame_info_bases 2921 __register_frame 2922 __register_frame_info 2923 __register_frame_info_bases 2924 __register_frame_info_table 2925 __register_frame_info_table_bases 2926 __register_frame_table 2927 2928 2929File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc 2930 29314.6 Miscellaneous runtime library routines 2932========================================== 2933 29344.6.1 Cache control functions 2935----------------------------- 2936 2937 -- Runtime Function: void __clear_cache (char *BEG, char *END) 2938 This function clears the instruction cache between BEG and END. 2939 29404.6.2 Split stack functions and variables 2941----------------------------------------- 2942 2943 -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void 2944 *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void 2945 **INITIAL_SP) 2946 When using '-fsplit-stack', this call may be used to iterate over 2947 the stack segments. It may be called like this: 2948 void *next_segment = NULL; 2949 void *next_sp = NULL; 2950 void *initial_sp = NULL; 2951 void *stack; 2952 size_t stack_size; 2953 while ((stack = __splitstack_find (next_segment, next_sp, 2954 &stack_size, &next_segment, 2955 &next_sp, &initial_sp)) 2956 != NULL) 2957 { 2958 /* Stack segment starts at stack and is 2959 stack_size bytes long. */ 2960 } 2961 2962 There is no way to iterate over the stack segments of a different 2963 thread. However, what is permitted is for one thread to call this 2964 with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT, 2965 NEXT_SP, and INITIAL_SP to a different thread, and then to suspend 2966 one way or another. A different thread may run the subsequent 2967 '__splitstack_find' iterations. Of course, this will only work if 2968 the first thread is suspended while the second thread is calling 2969 '__splitstack_find'. If not, the second thread could be looking at 2970 the stack while it is changing, and anything could happen. 2971 2972 -- Variable: __morestack_segments 2973 -- Variable: __morestack_current_segment 2974 -- Variable: __morestack_initial_sp 2975 Internal variables used by the '-fsplit-stack' implementation. 2976 2977 2978File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top 2979 29805 Language Front Ends in GCC 2981**************************** 2982 2983The interface to front ends for languages in GCC, and in particular the 2984'tree' structure (*note GENERIC::), was initially designed for C, and 2985many aspects of it are still somewhat biased towards C and C-like 2986languages. It is, however, reasonably well suited to other procedural 2987languages, and front ends for many such languages have been written for 2988GCC. 2989 2990 Writing a compiler as a front end for GCC, rather than compiling 2991directly to assembler or generating C code which is then compiled by 2992GCC, has several advantages: 2993 2994 * GCC front ends benefit from the support for many different target 2995 machines already present in GCC. 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 * Better debugging information is generated when compiling directly 3001 from source code than when going via intermediate generated C code. 3002 3003 Because of the advantages of writing a compiler as a GCC front end, GCC 3004front ends have also been created for languages very different from 3005those for which GCC was designed, such as the declarative 3006logic/functional language Mercury. For these reasons, it may also be 3007useful to implement compilers created for specialized purposes (for 3008example, as part of a research project) as GCC front ends. 3009 3010 3011File: gccint.info, Node: Source Tree, Next: Testsuites, Prev: Languages, Up: Top 3012 30136 Source Tree Structure and Build System 3014**************************************** 3015 3016This chapter describes the structure of the GCC source tree, and how GCC 3017is built. The user documentation for building and installing GCC is in 3018a separate manual (<http://gcc.gnu.org/install/>), with which it is 3019presumed that you are familiar. 3020 3021* Menu: 3022 3023* Configure Terms:: Configuration terminology and history. 3024* Top Level:: The top level source directory. 3025* gcc Directory:: The 'gcc' subdirectory. 3026 3027 3028File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree 3029 30306.1 Configure Terms and History 3031=============================== 3032 3033The configure and build process has a long and colorful history, and can 3034be confusing to anyone who doesn't know why things are the way they are. 3035While there are other documents which describe the configuration process 3036in detail, here are a few things that everyone working on GCC should 3037know. 3038 3039 There are three system names that the build knows about: the machine 3040you are building on ("build"), the machine that you are building for 3041("host"), and the machine that GCC will produce code for ("target"). 3042When you configure GCC, you specify these with '--build=', '--host=', 3043and '--target='. 3044 3045 Specifying the host without specifying the build should be avoided, as 3046'configure' may (and once did) assume that the host you specify is also 3047the build, which may not be true. 3048 3049 If build, host, and target are all the same, this is called a "native". 3050If build and host are the same but target is different, this is called a 3051"cross". If build, host, and target are all different this is called a 3052"canadian" (for obscure reasons dealing with Canada's political party 3053and the background of the person working on the build at that time). If 3054host and target are the same, but build is different, you are using a 3055cross-compiler to build a native for a different system. Some people 3056call this a "host-x-host", "crossed native", or "cross-built native". 3057If build and target are the same, but host is different, you are using a 3058cross compiler to build a cross compiler that produces code for the 3059machine you're building on. This is rare, so there is no common way of 3060describing it. There is a proposal to call this a "crossback". 3061 3062 If build and host are the same, the GCC you are building will also be 3063used to build the target libraries (like 'libstdc++'). If build and 3064host are different, you must have already built and installed a cross 3065compiler that will be used to build the target libraries (if you 3066configured with '--target=foo-bar', this compiler will be called 3067'foo-bar-gcc'). 3068 3069 In the case of target libraries, the machine you're building for is the 3070machine you specified with '--target'. So, build is the machine you're 3071building on (no change there), host is the machine you're building for 3072(the target libraries are built for the target, so host is the target 3073you specified), and target doesn't apply (because you're not building a 3074compiler, you're building libraries). The configure/make process will 3075adjust these variables as needed. It also sets '$with_cross_host' to 3076the original '--host' value in case you need it. 3077 3078 The 'libiberty' support library is built up to three times: once for 3079the host, once for the target (even if they are the same), and once for 3080the build if build and host are different. This allows it to be used by 3081all programs which are generated in the course of the build process. 3082 3083 3084File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree 3085 30866.2 Top Level Source Directory 3087============================== 3088 3089The top level source directory in a GCC distribution contains several 3090files and directories that are shared with other software distributions 3091such as that of GNU Binutils. It also contains several subdirectories 3092that contain parts of GCC and its runtime libraries: 3093 3094'boehm-gc' 3095 The Boehm conservative garbage collector, optionally used as part 3096 of the ObjC runtime library when configured with 3097 '--enable-objc-gc'. 3098 3099'config' 3100 Autoconf macros and Makefile fragments used throughout the tree. 3101 3102'contrib' 3103 Contributed scripts that may be found useful in conjunction with 3104 GCC. One of these, 'contrib/texi2pod.pl', is used to generate man 3105 pages from Texinfo manuals as part of the GCC build process. 3106 3107'fixincludes' 3108 The support for fixing system headers to work with GCC. See 3109 'fixincludes/README' for more information. The headers fixed by 3110 this mechanism are installed in 'LIBSUBDIR/include-fixed'. Along 3111 with those headers, 'README-fixinc' is also installed, as 3112 'LIBSUBDIR/include-fixed/README'. 3113 3114'gcc' 3115 The main sources of GCC itself (except for runtime libraries), 3116 including optimizers, support for different target architectures, 3117 language front ends, and testsuites. *Note The 'gcc' Subdirectory: 3118 gcc Directory, for details. 3119 3120'gnattools' 3121 Support tools for GNAT. 3122 3123'include' 3124 Headers for the 'libiberty' library. 3125 3126'intl' 3127 GNU 'libintl', from GNU 'gettext', for systems which do not include 3128 it in 'libc'. 3129 3130'libada' 3131 The Ada runtime library. 3132 3133'libatomic' 3134 The runtime support library for atomic operations (e.g. for 3135 '__sync' and '__atomic'). 3136 3137'libcpp' 3138 The C preprocessor library. 3139 3140'libdecnumber' 3141 The Decimal Float support library. 3142 3143'libffi' 3144 The 'libffi' library, used as part of the Go runtime library. 3145 3146'libgcc' 3147 The GCC runtime library. 3148 3149'libgfortran' 3150 The Fortran runtime library. 3151 3152'libgo' 3153 The Go runtime library. The bulk of this library is mirrored from 3154 the master Go repository (https://github.com/golang/go). 3155 3156'libgomp' 3157 The GNU Offloading and Multi Processing Runtime Library. 3158 3159'libiberty' 3160 The 'libiberty' library, used for portability and for some 3161 generally useful data structures and algorithms. *Note 3162 Introduction: (libiberty)Top, for more information about this 3163 library. 3164 3165'libitm' 3166 The runtime support library for transactional memory. 3167 3168'libobjc' 3169 The Objective-C and Objective-C++ runtime library. 3170 3171'libquadmath' 3172 The runtime support library for quad-precision math operations. 3173 3174'libphobos' 3175 The D standard and runtime library. The bulk of this library is 3176 mirrored from the master D repositories (https://github.com/dlang). 3177 3178'libssp' 3179 The Stack protector runtime library. 3180 3181'libstdc++-v3' 3182 The C++ runtime library. 3183 3184'lto-plugin' 3185 Plugin used by the linker if link-time optimizations are enabled. 3186 3187'maintainer-scripts' 3188 Scripts used by the 'gccadmin' account on 'gcc.gnu.org'. 3189 3190'zlib' 3191 The 'zlib' compression library, used for compressing and 3192 uncompressing GCC's intermediate language in LTO object files. 3193 3194 The build system in the top level directory, including how recursion 3195into subdirectories works and how building runtime libraries for 3196multilibs is handled, is documented in a separate manual, included with 3197GNU Binutils. *Note GNU configure and build system: (configure)Top, for 3198details. 3199 3200 3201File: gccint.info, Node: gcc Directory, Prev: Top Level, Up: Source Tree 3202 32036.3 The 'gcc' Subdirectory 3204========================== 3205 3206The 'gcc' directory contains many files that are part of the C sources 3207of GCC, other files used as part of the configuration and build process, 3208and subdirectories including documentation and a testsuite. The files 3209that are sources of GCC are documented in a separate chapter. *Note 3210Passes and Files of the Compiler: Passes. 3211 3212* Menu: 3213 3214* Subdirectories:: Subdirectories of 'gcc'. 3215* Configuration:: The configuration process, and the files it uses. 3216* Build:: The build system in the 'gcc' directory. 3217* Makefile:: Targets in 'gcc/Makefile'. 3218* Library Files:: Library source files and headers under 'gcc/'. 3219* Headers:: Headers installed by GCC. 3220* Documentation:: Building documentation in GCC. 3221* Front End:: Anatomy of a language front end. 3222* Back End:: Anatomy of a target back end. 3223 3224 3225File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory 3226 32276.3.1 Subdirectories of 'gcc' 3228----------------------------- 3229 3230The 'gcc' directory contains the following subdirectories: 3231 3232'LANGUAGE' 3233 Subdirectories for various languages. Directories containing a 3234 file 'config-lang.in' are language subdirectories. The contents of 3235 the subdirectories 'c' (for C), 'cp' (for C++), 'objc' (for 3236 Objective-C), 'objcp' (for Objective-C++), and 'lto' (for LTO) are 3237 documented in this manual (*note Passes and Files of the Compiler: 3238 Passes.); those for other languages are not. *Note Anatomy of a 3239 Language Front End: Front End, for details of the files in these 3240 directories. 3241 3242'common' 3243 Source files shared between the compiler drivers (such as 'gcc') 3244 and the compilers proper (such as 'cc1'). If an architecture 3245 defines target hooks shared between those places, it also has a 3246 subdirectory in 'common/config'. *Note Target Structure::. 3247 3248'config' 3249 Configuration files for supported architectures and operating 3250 systems. *Note Anatomy of a Target Back End: Back End, for details 3251 of the files in this directory. 3252 3253'doc' 3254 Texinfo documentation for GCC, together with automatically 3255 generated man pages and support for converting the installation 3256 manual to HTML. *Note Documentation::. 3257 3258'ginclude' 3259 System headers installed by GCC, mainly those required by the C 3260 standard of freestanding implementations. *Note Headers Installed 3261 by GCC: Headers, for details of when these and other headers are 3262 installed. 3263 3264'po' 3265 Message catalogs with translations of messages produced by GCC into 3266 various languages, 'LANGUAGE.po'. This directory also contains 3267 'gcc.pot', the template for these message catalogues, 'exgettext', 3268 a wrapper around 'gettext' to extract the messages from the GCC 3269 sources and create 'gcc.pot', which is run by 'make gcc.pot', and 3270 'EXCLUDES', a list of files from which messages should not be 3271 extracted. 3272 3273'testsuite' 3274 The GCC testsuites (except for those for runtime libraries). *Note 3275 Testsuites::. 3276 3277 3278File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory 3279 32806.3.2 Configuration in the 'gcc' Directory 3281------------------------------------------ 3282 3283The 'gcc' directory is configured with an Autoconf-generated script 3284'configure'. The 'configure' script is generated from 'configure.ac' 3285and 'aclocal.m4'. From the files 'configure.ac' and 'acconfig.h', 3286Autoheader generates the file 'config.in'. The file 'cstamp-h.in' is 3287used as a timestamp. 3288 3289* Menu: 3290 3291* Config Fragments:: Scripts used by 'configure'. 3292* System Config:: The 'config.build', 'config.host', and 3293 'config.gcc' files. 3294* Configuration Files:: Files created by running 'configure'. 3295 3296 3297File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration 3298 32996.3.2.1 Scripts Used by 'configure' 3300................................... 3301 3302'configure' uses some other scripts to help in its work: 3303 3304 * The standard GNU 'config.sub' and 'config.guess' files, kept in the 3305 top level directory, are used. 3306 3307 * The file 'config.gcc' is used to handle configuration specific to 3308 the particular target machine. The file 'config.build' is used to 3309 handle configuration specific to the particular build machine. The 3310 file 'config.host' is used to handle configuration specific to the 3311 particular host machine. (In general, these should only be used 3312 for features that cannot reasonably be tested in Autoconf feature 3313 tests.) *Note The 'config.build'; 'config.host'; and 'config.gcc' 3314 Files: System Config, for details of the contents of these files. 3315 3316 * Each language subdirectory has a file 'LANGUAGE/config-lang.in' 3317 that is used for front-end-specific configuration. *Note The Front 3318 End 'config-lang.in' File: Front End Config, for details of this 3319 file. 3320 3321 * A helper script 'configure.frag' is used as part of creating the 3322 output of 'configure'. 3323 3324 3325File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration 3326 33276.3.2.2 The 'config.build'; 'config.host'; and 'config.gcc' Files 3328................................................................. 3329 3330The 'config.build' file contains specific rules for particular systems 3331which GCC is built on. This should be used as rarely as possible, as 3332the behavior of the build system can always be detected by autoconf. 3333 3334 The 'config.host' file contains specific rules for particular systems 3335which GCC will run on. This is rarely needed. 3336 3337 The 'config.gcc' file contains specific rules for particular systems 3338which GCC will generate code for. This is usually needed. 3339 3340 Each file has a list of the shell variables it sets, with descriptions, 3341at the top of the file. 3342 3343 FIXME: document the contents of these files, and what variables should 3344be set to control build, host and target configuration. 3345 3346 3347File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration 3348 33496.3.2.3 Files Created by 'configure' 3350.................................... 3351 3352Here we spell out what files will be set up by 'configure' in the 'gcc' 3353directory. Some other files are created as temporary files in the 3354configuration process, and are not used in the subsequent build; these 3355are not documented. 3356 3357 * 'Makefile' is constructed from 'Makefile.in', together with the 3358 host and target fragments (*note Makefile Fragments: Fragments.) 3359 't-TARGET' and 'x-HOST' from 'config', if any, and language 3360 Makefile fragments 'LANGUAGE/Make-lang.in'. 3361 * 'auto-host.h' contains information about the host machine 3362 determined by 'configure'. If the host machine is different from 3363 the build machine, then 'auto-build.h' is also created, containing 3364 such information about the build machine. 3365 * 'config.status' is a script that may be run to recreate the current 3366 configuration. 3367 * 'configargs.h' is a header containing details of the arguments 3368 passed to 'configure' to configure GCC, and of the thread model 3369 used. 3370 * 'cstamp-h' is used as a timestamp. 3371 * If a language 'config-lang.in' file (*note The Front End 3372 'config-lang.in' File: Front End Config.) sets 'outputs', then the 3373 files listed in 'outputs' there are also generated. 3374 3375 The following configuration headers are created from the Makefile, 3376using 'mkconfig.sh', rather than directly by 'configure'. 'config.h', 3377'bconfig.h' and 'tconfig.h' all contain the 'xm-MACHINE.h' header, if 3378any, appropriate to the host, build and target machines respectively, 3379the configuration headers for the target, and some definitions; for the 3380host and build machines, these include the autoconfigured headers 3381generated by 'configure'. The other configuration headers are 3382determined by 'config.gcc'. They also contain the typedefs for 'rtx', 3383'rtvec' and 'tree'. 3384 3385 * 'config.h', for use in programs that run on the host machine. 3386 * 'bconfig.h', for use in programs that run on the build machine. 3387 * 'tconfig.h', for use in programs and libraries for the target 3388 machine. 3389 * 'tm_p.h', which includes the header 'MACHINE-protos.h' that 3390 contains prototypes for functions in the target 'MACHINE.c' file. 3391 The 'MACHINE-protos.h' header is included after the 'rtl.h' and/or 3392 'tree.h' would have been included. The 'tm_p.h' also includes the 3393 header 'tm-preds.h' which is generated by 'genpreds' program during 3394 the build to define the declarations and inline functions for the 3395 predicate functions. 3396 3397 3398File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory 3399 34006.3.3 Build System in the 'gcc' Directory 3401----------------------------------------- 3402 3403FIXME: describe the build system, including what is built in what 3404stages. Also list the various source files that are used in the build 3405process but aren't source files of GCC itself and so aren't documented 3406below (*note Passes::). 3407 3408 3409File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory 3410 34116.3.4 Makefile Targets 3412---------------------- 3413 3414These targets are available from the 'gcc' directory: 3415 3416'all' 3417 This is the default target. Depending on what your 3418 build/host/target configuration is, it coordinates all the things 3419 that need to be built. 3420 3421'doc' 3422 Produce info-formatted documentation and man pages. Essentially it 3423 calls 'make man' and 'make info'. 3424 3425'dvi' 3426 Produce DVI-formatted documentation. 3427 3428'pdf' 3429 Produce PDF-formatted documentation. 3430 3431'html' 3432 Produce HTML-formatted documentation. 3433 3434'man' 3435 Generate man pages. 3436 3437'info' 3438 Generate info-formatted pages. 3439 3440'mostlyclean' 3441 Delete the files made while building the compiler. 3442 3443'clean' 3444 That, and all the other files built by 'make all'. 3445 3446'distclean' 3447 That, and all the files created by 'configure'. 3448 3449'maintainer-clean' 3450 Distclean plus any file that can be generated from other files. 3451 Note that additional tools may be required beyond what is normally 3452 needed to build GCC. 3453 3454'srcextra' 3455 Generates files in the source directory that are not 3456 version-controlled but should go into a release tarball. 3457 3458'srcinfo' 3459'srcman' 3460 Copies the info-formatted and manpage documentation into the source 3461 directory usually for the purpose of generating a release tarball. 3462 3463'install' 3464 Installs GCC. 3465 3466'uninstall' 3467 Deletes installed files, though this is not supported. 3468 3469'check' 3470 Run the testsuite. This creates a 'testsuite' subdirectory that 3471 has various '.sum' and '.log' files containing the results of the 3472 testing. You can run subsets with, for example, 'make check-gcc'. 3473 You can specify specific tests by setting 'RUNTESTFLAGS' to be the 3474 name of the '.exp' file, optionally followed by (for some tests) an 3475 equals and a file wildcard, like: 3476 3477 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*" 3478 3479 Note that running the testsuite may require additional tools be 3480 installed, such as Tcl or DejaGnu. 3481 3482 The toplevel tree from which you start GCC compilation is not the GCC 3483directory, but rather a complex Makefile that coordinates the various 3484steps of the build, including bootstrapping the compiler and using the 3485new compiler to build target libraries. 3486 3487 When GCC is configured for a native configuration, the default action 3488for 'make' is to do a full three-stage bootstrap. This means that GCC 3489is built three times--once with the native compiler, once with the 3490native-built compiler it just built, and once with the compiler it built 3491the second time. In theory, the last two should produce the same 3492results, which 'make compare' can check. Each stage is configured 3493separately and compiled into a separate directory, to minimize problems 3494due to ABI incompatibilities between the native compiler and GCC. 3495 3496 If you do a change, rebuilding will also start from the first stage and 3497"bubble" up the change through the three stages. Each stage is taken 3498from its build directory (if it had been built previously), rebuilt, and 3499copied to its subdirectory. This will allow you to, for example, 3500continue a bootstrap after fixing a bug which causes the stage2 build to 3501crash. It does not provide as good coverage of the compiler as 3502bootstrapping from scratch, but it ensures that the new code is 3503syntactically correct (e.g., that you did not use GCC extensions by 3504mistake), and avoids spurious bootstrap comparison failures(1). 3505 3506 Other targets available from the top level include: 3507 3508'bootstrap-lean' 3509 Like 'bootstrap', except that the various stages are removed once 3510 they're no longer needed. This saves disk space. 3511 3512'bootstrap2' 3513'bootstrap2-lean' 3514 Performs only the first two stages of bootstrap. Unlike a 3515 three-stage bootstrap, this does not perform a comparison to test 3516 that the compiler is running properly. Note that the disk space 3517 required by a "lean" bootstrap is approximately independent of the 3518 number of stages. 3519 3520'stageN-bubble (N = 1...4, profile, feedback)' 3521 Rebuild all the stages up to N, with the appropriate flags, 3522 "bubbling" the changes as described above. 3523 3524'all-stageN (N = 1...4, profile, feedback)' 3525 Assuming that stage N has already been built, rebuild it with the 3526 appropriate flags. This is rarely needed. 3527 3528'cleanstrap' 3529 Remove everything ('make clean') and rebuilds ('make bootstrap'). 3530 3531'compare' 3532 Compares the results of stages 2 and 3. This ensures that the 3533 compiler is running properly, since it should produce the same 3534 object files regardless of how it itself was compiled. 3535 3536'profiledbootstrap' 3537 Builds a compiler with profiling feedback information. In this 3538 case, the second and third stages are named 'profile' and 3539 'feedback', respectively. For more information, see the 3540 installation instructions. 3541 3542'restrap' 3543 Restart a bootstrap, so that everything that was not built with the 3544 system compiler is rebuilt. 3545 3546'stageN-start (N = 1...4, profile, feedback)' 3547 For each package that is bootstrapped, rename directories so that, 3548 for example, 'gcc' points to the stageN GCC, compiled with the 3549 stageN-1 GCC(2). 3550 3551 You will invoke this target if you need to test or debug the stageN 3552 GCC. If you only need to execute GCC (but you need not run 'make' 3553 either to rebuild it or to run test suites), you should be able to 3554 work directly in the 'stageN-gcc' directory. This makes it easier 3555 to debug multiple stages in parallel. 3556 3557'stage' 3558 For each package that is bootstrapped, relocate its build directory 3559 to indicate its stage. For example, if the 'gcc' directory points 3560 to the stage2 GCC, after invoking this target it will be renamed to 3561 'stage2-gcc'. 3562 3563 If you wish to use non-default GCC flags when compiling the stage2 and 3564stage3 compilers, set 'BOOT_CFLAGS' on the command line when doing 3565'make'. 3566 3567 Usually, the first stage only builds the languages that the compiler is 3568written in: typically, C and maybe Ada. If you are debugging a 3569miscompilation of a different stage2 front-end (for example, of the 3570Fortran front-end), you may want to have front-ends for other languages 3571in the first stage as well. To do so, set 'STAGE1_LANGUAGES' on the 3572command line when doing 'make'. 3573 3574 For example, in the aforementioned scenario of debugging a Fortran 3575front-end miscompilation caused by the stage1 compiler, you may need a 3576command like 3577 3578 make stage2-bubble STAGE1_LANGUAGES=c,fortran 3579 3580 Alternatively, you can use per-language targets to build and test 3581languages that are not enabled by default in stage1. For example, 'make 3582f951' will build a Fortran compiler even in the stage1 build directory. 3583 3584 ---------- Footnotes ---------- 3585 3586 (1) Except if the compiler was buggy and miscompiled some of the 3587files that were not modified. In this case, it's best to use 'make 3588restrap'. 3589 3590 (2) Customarily, the system compiler is also termed the 'stage0' GCC. 3591 3592 3593File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory 3594 35956.3.5 Library Source Files and Headers under the 'gcc' Directory 3596---------------------------------------------------------------- 3597 3598FIXME: list here, with explanation, all the C source files and headers 3599under the 'gcc' directory that aren't built into the GCC executable but 3600rather are part of runtime libraries and object files, such as 3601'crtstuff.c' and 'unwind-dw2.c'. *Note Headers Installed by GCC: 3602Headers, for more information about the 'ginclude' directory. 3603 3604 3605File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory 3606 36076.3.6 Headers Installed by GCC 3608------------------------------ 3609 3610In general, GCC expects the system C library to provide most of the 3611headers to be used with it. However, GCC will fix those headers if 3612necessary to make them work with GCC, and will install some headers 3613required of freestanding implementations. These headers are installed 3614in 'LIBSUBDIR/include'. Headers for non-C runtime libraries are also 3615installed by GCC; these are not documented here. (FIXME: document them 3616somewhere.) 3617 3618 Several of the headers GCC installs are in the 'ginclude' directory. 3619These headers, 'iso646.h', 'stdarg.h', 'stdbool.h', and 'stddef.h', are 3620installed in 'LIBSUBDIR/include', unless the target Makefile fragment 3621(*note Target Fragment::) overrides this by setting 'USER_H'. 3622 3623 In addition to these headers and those generated by fixing system 3624headers to work with GCC, some other headers may also be installed in 3625'LIBSUBDIR/include'. 'config.gcc' may set 'extra_headers'; this 3626specifies additional headers under 'config' to be installed on some 3627systems. 3628 3629 GCC installs its own version of '<float.h>', from 'ginclude/float.h'. 3630This is done to cope with command-line options that change the 3631representation of floating point numbers. 3632 3633 GCC also installs its own version of '<limits.h>'; this is generated 3634from 'glimits.h', together with 'limitx.h' and 'limity.h' if the system 3635also has its own version of '<limits.h>'. (GCC provides its own header 3636because it is required of ISO C freestanding implementations, but needs 3637to include the system header from its own header as well because other 3638standards such as POSIX specify additional values to be defined in 3639'<limits.h>'.) The system's '<limits.h>' header is used via 3640'LIBSUBDIR/include/syslimits.h', which is copied from 'gsyslimits.h' if 3641it does not need fixing to work with GCC; if it needs fixing, 3642'syslimits.h' is the fixed copy. 3643 3644 GCC can also install '<tgmath.h>'. It will do this when 'config.gcc' 3645sets 'use_gcc_tgmath' to 'yes'. 3646 3647 3648File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory 3649 36506.3.7 Building Documentation 3651---------------------------- 3652 3653The main GCC documentation is in the form of manuals in Texinfo format. 3654These are installed in Info format; DVI versions may be generated by 3655'make dvi', PDF versions by 'make pdf', and HTML versions by 'make 3656html'. In addition, some man pages are generated from the Texinfo 3657manuals, there are some other text files with miscellaneous 3658documentation, and runtime libraries have their own documentation 3659outside the 'gcc' directory. FIXME: document the documentation for 3660runtime libraries somewhere. 3661 3662* Menu: 3663 3664* Texinfo Manuals:: GCC manuals in Texinfo format. 3665* Man Page Generation:: Generating man pages from Texinfo manuals. 3666* Miscellaneous Docs:: Miscellaneous text files with documentation. 3667 3668 3669File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation 3670 36716.3.7.1 Texinfo Manuals 3672....................... 3673 3674The manuals for GCC as a whole, and the C and C++ front ends, are in 3675files 'doc/*.texi'. Other front ends have their own manuals in files 3676'LANGUAGE/*.texi'. Common files 'doc/include/*.texi' are provided which 3677may be included in multiple manuals; the following files are in 3678'doc/include': 3679 3680'fdl.texi' 3681 The GNU Free Documentation License. 3682'funding.texi' 3683 The section "Funding Free Software". 3684'gcc-common.texi' 3685 Common definitions for manuals. 3686'gpl_v3.texi' 3687 The GNU General Public License. 3688'texinfo.tex' 3689 A copy of 'texinfo.tex' known to work with the GCC manuals. 3690 3691 DVI-formatted manuals are generated by 'make dvi', which uses 3692'texi2dvi' (via the Makefile macro '$(TEXI2DVI)'). PDF-formatted 3693manuals are generated by 'make pdf', which uses 'texi2pdf' (via the 3694Makefile macro '$(TEXI2PDF)'). HTML formatted manuals are generated by 3695'make html'. Info manuals are generated by 'make info' (which is run as 3696part of a bootstrap); this generates the manuals in the source 3697directory, using 'makeinfo' via the Makefile macro '$(MAKEINFO)', and 3698they are included in release distributions. 3699 3700 Manuals are also provided on the GCC web site, in both HTML and 3701PostScript forms. This is done via the script 3702'maintainer-scripts/update_web_docs_git'. Each manual to be provided 3703online must be listed in the definition of 'MANUALS' in that file; a 3704file 'NAME.texi' must only appear once in the source tree, and the 3705output manual must have the same name as the source file. (However, 3706other Texinfo files, included in manuals but not themselves the root 3707files of manuals, may have names that appear more than once in the 3708source tree.) The manual file 'NAME.texi' should only include other 3709files in its own directory or in 'doc/include'. HTML manuals will be 3710generated by 'makeinfo --html', PostScript manuals by 'texi2dvi' and 3711'dvips', and PDF manuals by 'texi2pdf'. All Texinfo files that are 3712parts of manuals must be version-controlled, even if they are generated 3713files, for the generation of online manuals to work. 3714 3715 The installation manual, 'doc/install.texi', is also provided on the 3716GCC web site. The HTML version is generated by the script 3717'doc/install.texi2html'. 3718 3719 3720File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation 3721 37226.3.7.2 Man Page Generation 3723........................... 3724 3725Because of user demand, in addition to full Texinfo manuals, man pages 3726are provided which contain extracts from those manuals. These man pages 3727are generated from the Texinfo manuals using 'contrib/texi2pod.pl' and 3728'pod2man'. (The man page for 'g++', 'cp/g++.1', just contains a '.so' 3729reference to 'gcc.1', but all the other man pages are generated from 3730Texinfo manuals.) 3731 3732 Because many systems may not have the necessary tools installed to 3733generate the man pages, they are only generated if the 'configure' 3734script detects that recent enough tools are installed, and the Makefiles 3735allow generating man pages to fail without aborting the build. Man 3736pages are also included in release distributions. They are generated in 3737the source directory. 3738 3739 Magic comments in Texinfo files starting '@c man' control what parts of 3740a Texinfo file go into a man page. Only a subset of Texinfo is 3741supported by 'texi2pod.pl', and it may be necessary to add support for 3742more Texinfo features to this script when generating new man pages. To 3743improve the man page output, some special Texinfo macros are provided in 3744'doc/include/gcc-common.texi' which 'texi2pod.pl' understands: 3745 3746'@gcctabopt' 3747 Use in the form '@table @gcctabopt' for tables of options, where 3748 for printed output the effect of '@code' is better than that of 3749 '@option' but for man page output a different effect is wanted. 3750'@gccoptlist' 3751 Use for summary lists of options in manuals. 3752'@gol' 3753 Use at the end of each line inside '@gccoptlist'. This is 3754 necessary to avoid problems with differences in how the 3755 '@gccoptlist' macro is handled by different Texinfo formatters. 3756 3757 FIXME: describe the 'texi2pod.pl' input language and magic comments in 3758more detail. 3759 3760 3761File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation 3762 37636.3.7.3 Miscellaneous Documentation 3764................................... 3765 3766In addition to the formal documentation that is installed by GCC, there 3767are several other text files in the 'gcc' subdirectory with 3768miscellaneous documentation: 3769 3770'ABOUT-GCC-NLS' 3771 Notes on GCC's Native Language Support. FIXME: this should be part 3772 of this manual rather than a separate file. 3773'ABOUT-NLS' 3774 Notes on the Free Translation Project. 3775'COPYING' 3776'COPYING3' 3777 The GNU General Public License, Versions 2 and 3. 3778'COPYING.LIB' 3779'COPYING3.LIB' 3780 The GNU Lesser General Public License, Versions 2.1 and 3. 3781'*ChangeLog*' 3782'*/ChangeLog*' 3783 Change log files for various parts of GCC. 3784'LANGUAGES' 3785 Details of a few changes to the GCC front-end interface. FIXME: 3786 the information in this file should be part of general 3787 documentation of the front-end interface in this manual. 3788'ONEWS' 3789 Information about new features in old versions of GCC. (For recent 3790 versions, the information is on the GCC web site.) 3791'README.Portability' 3792 Information about portability issues when writing code in GCC. 3793 FIXME: why isn't this part of this manual or of the GCC Coding 3794 Conventions? 3795 3796 FIXME: document such files in subdirectories, at least 'config', 'c', 3797'cp', 'objc', 'testsuite'. 3798 3799 3800File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory 3801 38026.3.8 Anatomy of a Language Front End 3803------------------------------------- 3804 3805A front end for a language in GCC has the following parts: 3806 3807 * A directory 'LANGUAGE' under 'gcc' containing source files for that 3808 front end. *Note The Front End 'LANGUAGE' Directory: Front End 3809 Directory, for details. 3810 * A mention of the language in the list of supported languages in 3811 'gcc/doc/install.texi'. 3812 * A mention of the name under which the language's runtime library is 3813 recognized by '--enable-shared=PACKAGE' in the documentation of 3814 that option in 'gcc/doc/install.texi'. 3815 * A mention of any special prerequisites for building the front end 3816 in the documentation of prerequisites in 'gcc/doc/install.texi'. 3817 * Details of contributors to that front end in 3818 'gcc/doc/contrib.texi'. If the details are in that front end's own 3819 manual then there should be a link to that manual's list in 3820 'contrib.texi'. 3821 * Information about support for that language in 3822 'gcc/doc/frontends.texi'. 3823 * Information about standards for that language, and the front end's 3824 support for them, in 'gcc/doc/standards.texi'. This may be a link 3825 to such information in the front end's own manual. 3826 * Details of source file suffixes for that language and '-x LANG' 3827 options supported, in 'gcc/doc/invoke.texi'. 3828 * Entries in 'default_compilers' in 'gcc.c' for source file suffixes 3829 for that language. 3830 * Preferably testsuites, which may be under 'gcc/testsuite' or 3831 runtime library directories. FIXME: document somewhere how to 3832 write testsuite harnesses. 3833 * Probably a runtime library for the language, outside the 'gcc' 3834 directory. FIXME: document this further. 3835 * Details of the directories of any runtime libraries in 3836 'gcc/doc/sourcebuild.texi'. 3837 * Check targets in 'Makefile.def' for the top-level 'Makefile' to 3838 check just the compiler or the compiler and runtime library for the 3839 language. 3840 3841 If the front end is added to the official GCC source repository, the 3842following are also necessary: 3843 3844 * At least one Bugzilla component for bugs in that front end and 3845 runtime libraries. This category needs to be added to the Bugzilla 3846 database. 3847 * Normally, one or more maintainers of that front end listed in 3848 'MAINTAINERS'. 3849 * Mentions on the GCC web site in 'index.html' and 'frontends.html', 3850 with any relevant links on 'readings.html'. (Front ends that are 3851 not an official part of GCC may also be listed on 'frontends.html', 3852 with relevant links.) 3853 * A news item on 'index.html', and possibly an announcement on the 3854 <gcc-announce@gcc.gnu.org> mailing list. 3855 * The front end's manuals should be mentioned in 3856 'maintainer-scripts/update_web_docs_git' (*note Texinfo Manuals::) 3857 and the online manuals should be linked to from 3858 'onlinedocs/index.html'. 3859 * Any old releases or CVS repositories of the front end, before its 3860 inclusion in GCC, should be made available on the GCC web site at 3861 <https://gcc.gnu.org/pub/gcc/old-releases/>. 3862 * The release and snapshot script 'maintainer-scripts/gcc_release' 3863 should be updated to generate appropriate tarballs for this front 3864 end. 3865 * If this front end includes its own version files that include the 3866 current date, 'maintainer-scripts/update_version' should be updated 3867 accordingly. 3868 3869* Menu: 3870 3871* Front End Directory:: The front end 'LANGUAGE' directory. 3872* Front End Config:: The front end 'config-lang.in' file. 3873* Front End Makefile:: The front end 'Make-lang.in' file. 3874 3875 3876File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End 3877 38786.3.8.1 The Front End 'LANGUAGE' Directory 3879.......................................... 3880 3881A front end 'LANGUAGE' directory contains the source files of that front 3882end (but not of any runtime libraries, which should be outside the 'gcc' 3883directory). This includes documentation, and possibly some subsidiary 3884programs built alongside the front end. Certain files are special and 3885other parts of the compiler depend on their names: 3886 3887'config-lang.in' 3888 This file is required in all language subdirectories. *Note The 3889 Front End 'config-lang.in' File: Front End Config, for details of 3890 its contents 3891'Make-lang.in' 3892 This file is required in all language subdirectories. *Note The 3893 Front End 'Make-lang.in' File: Front End Makefile, for details of 3894 its contents. 3895'lang.opt' 3896 This file registers the set of switches that the front end accepts 3897 on the command line, and their '--help' text. *Note Options::. 3898'lang-specs.h' 3899 This file provides entries for 'default_compilers' in 'gcc.c' which 3900 override the default of giving an error that a compiler for that 3901 language is not installed. 3902'LANGUAGE-tree.def' 3903 This file, which need not exist, defines any language-specific tree 3904 codes. 3905 3906 3907File: gccint.info, Node: Front End Config, Next: Front End Makefile, Prev: Front End Directory, Up: Front End 3908 39096.3.8.2 The Front End 'config-lang.in' File 3910........................................... 3911 3912Each language subdirectory contains a 'config-lang.in' file. This file 3913is a shell script that may define some variables describing the 3914language: 3915 3916'language' 3917 This definition must be present, and gives the name of the language 3918 for some purposes such as arguments to '--enable-languages'. 3919'lang_requires' 3920 If defined, this variable lists (space-separated) language front 3921 ends other than C that this front end requires to be enabled (with 3922 the names given being their 'language' settings). For example, the 3923 Obj-C++ front end depends on the C++ and ObjC front ends, so sets 3924 'lang_requires="objc c++"'. 3925'subdir_requires' 3926 If defined, this variable lists (space-separated) front end 3927 directories other than C that this front end requires to be 3928 present. For example, the Objective-C++ front end uses source 3929 files from the C++ and Objective-C front ends, so sets 3930 'subdir_requires="cp objc"'. 3931'target_libs' 3932 If defined, this variable lists (space-separated) targets in the 3933 top level 'Makefile' to build the runtime libraries for this 3934 language, such as 'target-libobjc'. 3935'lang_dirs' 3936 If defined, this variable lists (space-separated) top level 3937 directories (parallel to 'gcc'), apart from the runtime libraries, 3938 that should not be configured if this front end is not built. 3939'build_by_default' 3940 If defined to 'no', this language front end is not built unless 3941 enabled in a '--enable-languages' argument. Otherwise, front ends 3942 are built by default, subject to any special logic in 3943 'configure.ac' (as is present to disable the Ada front end if the 3944 Ada compiler is not already installed). 3945'boot_language' 3946 If defined to 'yes', this front end is built in stage1 of the 3947 bootstrap. This is only relevant to front ends written in their 3948 own languages. 3949'compilers' 3950 If defined, a space-separated list of compiler executables that 3951 will be run by the driver. The names here will each end with 3952 '\$(exeext)'. 3953'outputs' 3954 If defined, a space-separated list of files that should be 3955 generated by 'configure' substituting values in them. This 3956 mechanism can be used to create a file 'LANGUAGE/Makefile' from 3957 'LANGUAGE/Makefile.in', but this is deprecated, building everything 3958 from the single 'gcc/Makefile' is preferred. 3959'gtfiles' 3960 If defined, a space-separated list of files that should be scanned 3961 by 'gengtype.c' to generate the garbage collection tables and 3962 routines for this language. This excludes the files that are 3963 common to all front ends. *Note Type Information::. 3964 3965 3966File: gccint.info, Node: Front End Makefile, Prev: Front End Config, Up: Front End 3967 39686.3.8.3 The Front End 'Make-lang.in' File 3969......................................... 3970 3971Each language subdirectory contains a 'Make-lang.in' file. It contains 3972targets 'LANG.HOOK' (where 'LANG' is the setting of 'language' in 3973'config-lang.in') for the following values of 'HOOK', and any other 3974Makefile rules required to build those targets (which may if necessary 3975use other Makefiles specified in 'outputs' in 'config-lang.in', although 3976this is deprecated). It also adds any testsuite targets that can use 3977the standard rule in 'gcc/Makefile.in' to the variable 'lang_checks'. 3978 3979'all.cross' 3980'start.encap' 3981'rest.encap' 3982 FIXME: exactly what goes in each of these targets? 3983'tags' 3984 Build an 'etags' 'TAGS' file in the language subdirectory in the 3985 source tree. 3986'info' 3987 Build info documentation for the front end, in the build directory. 3988 This target is only called by 'make bootstrap' if a suitable 3989 version of 'makeinfo' is available, so does not need to check for 3990 this, and should fail if an error occurs. 3991'dvi' 3992 Build DVI documentation for the front end, in the build directory. 3993 This should be done using '$(TEXI2DVI)', with appropriate '-I' 3994 arguments pointing to directories of included files. 3995'pdf' 3996 Build PDF documentation for the front end, in the build directory. 3997 This should be done using '$(TEXI2PDF)', with appropriate '-I' 3998 arguments pointing to directories of included files. 3999'html' 4000 Build HTML documentation for the front end, in the build directory. 4001'man' 4002 Build generated man pages for the front end from Texinfo manuals 4003 (*note Man Page Generation::), in the build directory. This target 4004 is only called if the necessary tools are available, but should 4005 ignore errors so as not to stop the build if errors occur; man 4006 pages are optional and the tools involved may be installed in a 4007 broken way. 4008'install-common' 4009 Install everything that is part of the front end, apart from the 4010 compiler executables listed in 'compilers' in 'config-lang.in'. 4011'install-info' 4012 Install info documentation for the front end, if it is present in 4013 the source directory. This target should have dependencies on info 4014 files that should be installed. 4015'install-man' 4016 Install man pages for the front end. This target should ignore 4017 errors. 4018'install-plugin' 4019 Install headers needed for plugins. 4020'srcextra' 4021 Copies its dependencies into the source directory. This generally 4022 should be used for generated files such as Bison output files which 4023 are not version-controlled, but should be included in any release 4024 tarballs. This target will be executed during a bootstrap if 4025 '--enable-generated-files-in-srcdir' was specified as a 'configure' 4026 option. 4027'srcinfo' 4028'srcman' 4029 Copies its dependencies into the source directory. These targets 4030 will be executed during a bootstrap if 4031 '--enable-generated-files-in-srcdir' was specified as a 'configure' 4032 option. 4033'uninstall' 4034 Uninstall files installed by installing the compiler. This is 4035 currently documented not to be supported, so the hook need not do 4036 anything. 4037'mostlyclean' 4038'clean' 4039'distclean' 4040'maintainer-clean' 4041 The language parts of the standard GNU '*clean' targets. *Note 4042 Standard Targets for Users: (standards)Standard Targets, for 4043 details of the standard targets. For GCC, 'maintainer-clean' 4044 should delete all generated files in the source directory that are 4045 not version-controlled, but should not delete anything that is. 4046 4047 'Make-lang.in' must also define a variable 'LANG_OBJS' to a list of 4048host object files that are used by that language. 4049 4050 4051File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory 4052 40536.3.9 Anatomy of a Target Back End 4054---------------------------------- 4055 4056A back end for a target architecture in GCC has the following parts: 4057 4058 * A directory 'MACHINE' under 'gcc/config', containing a machine 4059 description 'MACHINE.md' file (*note Machine Descriptions: Machine 4060 Desc.), header files 'MACHINE.h' and 'MACHINE-protos.h' and a 4061 source file 'MACHINE.c' (*note Target Description Macros and 4062 Functions: Target Macros.), possibly a target Makefile fragment 4063 't-MACHINE' (*note The Target Makefile Fragment: Target Fragment.), 4064 and maybe some other files. The names of these files may be 4065 changed from the defaults given by explicit specifications in 4066 'config.gcc'. 4067 * If necessary, a file 'MACHINE-modes.def' in the 'MACHINE' 4068 directory, containing additional machine modes to represent 4069 condition codes. *Note Condition Code::, for further details. 4070 * An optional 'MACHINE.opt' file in the 'MACHINE' directory, 4071 containing a list of target-specific options. You can also add 4072 other option files using the 'extra_options' variable in 4073 'config.gcc'. *Note Options::. 4074 * Entries in 'config.gcc' (*note The 'config.gcc' File: System 4075 Config.) for the systems with this target architecture. 4076 * Documentation in 'gcc/doc/invoke.texi' for any command-line options 4077 supported by this target (*note Run-time Target Specification: 4078 Run-time Target.). This means both entries in the summary table of 4079 options and details of the individual options. 4080 * Documentation in 'gcc/doc/extend.texi' for any target-specific 4081 attributes supported (*note Defining target-specific uses of 4082 '__attribute__': Target Attributes.), including where the same 4083 attribute is already supported on some targets, which are 4084 enumerated in the manual. 4085 * Documentation in 'gcc/doc/extend.texi' for any target-specific 4086 pragmas supported. 4087 * Documentation in 'gcc/doc/extend.texi' of any target-specific 4088 built-in functions supported. 4089 * Documentation in 'gcc/doc/extend.texi' of any target-specific 4090 format checking styles supported. 4091 * Documentation in 'gcc/doc/md.texi' of any target-specific 4092 constraint letters (*note Constraints for Particular Machines: 4093 Machine Constraints.). 4094 * A note in 'gcc/doc/contrib.texi' under the person or people who 4095 contributed the target support. 4096 * Entries in 'gcc/doc/install.texi' for all target triplets supported 4097 with this target architecture, giving details of any special notes 4098 about installation for this target, or saying that there are no 4099 special notes if there are none. 4100 * Possibly other support outside the 'gcc' directory for runtime 4101 libraries. FIXME: reference docs for this. The 'libstdc++' 4102 porting manual needs to be installed as info for this to work, or 4103 to be a chapter of this manual. 4104 4105 The 'MACHINE.h' header is included very early in GCC's standard 4106sequence of header files, while 'MACHINE-protos.h' is included late in 4107the sequence. Thus 'MACHINE-protos.h' can include declarations 4108referencing types that are not defined when 'MACHINE.h' is included, 4109specifically including those from 'rtl.h' and 'tree.h'. Since both RTL 4110and tree types may not be available in every context where 4111'MACHINE-protos.h' is included, in this file you should guard 4112declarations using these types inside appropriate '#ifdef RTX_CODE' or 4113'#ifdef TREE_CODE' conditional code segments. 4114 4115 If the backend uses shared data structures that require 'GTY' markers 4116for garbage collection (*note Type Information::), you must declare 4117those in 'MACHINE.h' rather than 'MACHINE-protos.h'. Any definitions 4118required for building libgcc must also go in 'MACHINE.h'. 4119 4120 GCC uses the macro 'IN_TARGET_CODE' to distinguish between 4121machine-specific '.c' and '.cc' files and machine-independent '.c' and 4122'.cc' files. Machine-specific files should use the directive: 4123 4124 #define IN_TARGET_CODE 1 4125 4126 before including 'config.h'. 4127 4128 If the back end is added to the official GCC source repository, the 4129following are also necessary: 4130 4131 * An entry for the target architecture in 'readings.html' on the GCC 4132 web site, with any relevant links. 4133 * Details of the properties of the back end and target architecture 4134 in 'backends.html' on the GCC web site. 4135 * A news item about the contribution of support for that target 4136 architecture, in 'index.html' on the GCC web site. 4137 * Normally, one or more maintainers of that target listed in 4138 'MAINTAINERS'. Some existing architectures may be unmaintained, 4139 but it would be unusual to add support for a target that does not 4140 have a maintainer when support is added. 4141 * Target triplets covering all 'config.gcc' stanzas for the target, 4142 in the list in 'contrib/config-list.mk'. 4143 4144 4145File: gccint.info, Node: Testsuites, Next: Options, Prev: Source Tree, Up: Top 4146 41477 Testsuites 4148************ 4149 4150GCC contains several testsuites to help maintain compiler quality. Most 4151of the runtime libraries and language front ends in GCC have testsuites. 4152Currently only the C language testsuites are documented here; FIXME: 4153document the others. 4154 4155* Menu: 4156 4157* Test Idioms:: Idioms used in testsuite code. 4158* Test Directives:: Directives used within DejaGnu tests. 4159* Ada Tests:: The Ada language testsuites. 4160* C Tests:: The C language testsuites. 4161* LTO Testing:: Support for testing link-time optimizations. 4162* gcov Testing:: Support for testing gcov. 4163* profopt Testing:: Support for testing profile-directed optimizations. 4164* compat Testing:: Support for testing binary compatibility. 4165* Torture Tests:: Support for torture testing using multiple options. 4166* GIMPLE Tests:: Support for testing GIMPLE passes. 4167* RTL Tests:: Support for testing RTL passes. 4168 4169 4170File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites 4171 41727.1 Idioms Used in Testsuite Code 4173================================= 4174 4175In general, C testcases have a trailing '-N.c', starting with '-1.c', in 4176case other testcases with similar names are added later. If the test is 4177a test of some well-defined feature, it should have a name referring to 4178that feature such as 'FEATURE-1.c'. If it does not test a well-defined 4179feature but just happens to exercise a bug somewhere in the compiler, 4180and a bug report has been filed for this bug in the GCC bug database, 4181'prBUG-NUMBER-1.c' is the appropriate form of name. Otherwise (for 4182miscellaneous bugs not filed in the GCC bug database), and previously 4183more generally, test cases are named after the date on which they were 4184added. This allows people to tell at a glance whether a test failure is 4185because of a recently found bug that has not yet been fixed, or whether 4186it may be a regression, but does not give any other information about 4187the bug or where discussion of it may be found. Some other language 4188testsuites follow similar conventions. 4189 4190 In the 'gcc.dg' testsuite, it is often necessary to test that an error 4191is indeed a hard error and not just a warning--for example, where it is 4192a constraint violation in the C standard, which must become an error 4193with '-pedantic-errors'. The following idiom, where the first line 4194shown is line LINE of the file and the line that generates the error, is 4195used for this: 4196 4197 /* { dg-bogus "warning" "warning in place of error" } */ 4198 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */ 4199 4200 It may be necessary to check that an expression is an integer constant 4201expression and has a certain value. To check that 'E' has value 'V', an 4202idiom similar to the following is used: 4203 4204 char x[((E) == (V) ? 1 : -1)]; 4205 4206 In 'gcc.dg' tests, '__typeof__' is sometimes used to make assertions 4207about the types of expressions. See, for example, 4208'gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact 4209rules for the types of conditional expressions in the C standard; see, 4210for example, 'gcc.dg/c99-intconst-1.c'. 4211 4212 It is useful to be able to test that optimizations are being made 4213properly. This cannot be done in all cases, but it can be done where 4214the optimization will lead to code being optimized away (for example, 4215where flow analysis or alias analysis should show that certain code 4216cannot be called) or to functions not being called because they have 4217been expanded as built-in functions. Such tests go in 4218'gcc.c-torture/execute'. Where code should be optimized away, a call to 4219a nonexistent function such as 'link_failure ()' may be inserted; a 4220definition 4221 4222 #ifndef __OPTIMIZE__ 4223 void 4224 link_failure (void) 4225 { 4226 abort (); 4227 } 4228 #endif 4229 4230will also be needed so that linking still succeeds when the test is run 4231without optimization. When all calls to a built-in function should have 4232been optimized and no calls to the non-built-in version of the function 4233should remain, that function may be defined as 'static' to call 'abort 4234()' (although redeclaring a function as static may not work on all 4235targets). 4236 4237 All testcases must be portable. Target-specific testcases must have 4238appropriate code to avoid causing failures on unsupported systems; 4239unfortunately, the mechanisms for this differ by directory. 4240 4241 FIXME: discuss non-C testsuites here. 4242 4243 4244File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites 4245 42467.2 Directives used within DejaGnu tests 4247======================================== 4248 4249* Menu: 4250 4251* Directives:: Syntax and descriptions of test directives. 4252* Selectors:: Selecting targets to which a test applies. 4253* Effective-Target Keywords:: Keywords describing target attributes. 4254* Add Options:: Features for 'dg-add-options' 4255* Require Support:: Variants of 'dg-require-SUPPORT' 4256* Final Actions:: Commands for use in 'dg-final' 4257 4258 4259File: gccint.info, Node: Directives, Next: Selectors, Up: Test Directives 4260 42617.2.1 Syntax and Descriptions of test directives 4262------------------------------------------------ 4263 4264Test directives appear within comments in a test source file and begin 4265with 'dg-'. Some of these are defined within DejaGnu and others are 4266local to the GCC testsuite. 4267 4268 The order in which test directives appear in a test can be important: 4269directives local to GCC sometimes override information used by the 4270DejaGnu directives, which know nothing about the GCC directives, so the 4271DejaGnu directives must precede GCC directives. 4272 4273 Several test directives include selectors (*note Selectors::) which are 4274usually preceded by the keyword 'target' or 'xfail'. 4275 42767.2.1.1 Specify how to build the test 4277..................................... 4278 4279'{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }' 4280 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 4281 is executed. It is one of: 4282 4283 'preprocess' 4284 Compile with '-E' to run only the preprocessor. 4285 'compile' 4286 Compile with '-S' to produce an assembly code file. 4287 'assemble' 4288 Compile with '-c' to produce a relocatable object file. 4289 'link' 4290 Compile, assemble, and link to produce an executable file. 4291 'run' 4292 Produce and run an executable file, which is expected to 4293 return an exit code of 0. 4294 4295 The default is 'compile'. That can be overridden for a set of 4296 tests by redefining 'dg-do-what-default' within the '.exp' file for 4297 those tests. 4298 4299 If the directive includes the optional '{ target SELECTOR }' then 4300 the test is skipped unless the target system matches the SELECTOR. 4301 4302 If DO-WHAT-KEYWORD is 'run' and the directive includes the optional 4303 '{ xfail SELECTOR }' and the selector is met then the test is 4304 expected to fail. The 'xfail' clause is ignored for other values 4305 of DO-WHAT-KEYWORD; those tests can use directive 'dg-xfail-if'. 4306 43077.2.1.2 Specify additional compiler options 4308........................................... 4309 4310'{ dg-options OPTIONS [{ target SELECTOR }] }' 4311 This DejaGnu directive provides a list of compiler options, to be 4312 used if the target system matches SELECTOR, that replace the 4313 default options used for this set of tests. 4314 4315'{ dg-add-options FEATURE ... }' 4316 Add any compiler options that are needed to access certain 4317 features. This directive does nothing on targets that enable the 4318 features by default, or that don't provide them at all. It must 4319 come after all 'dg-options' directives. For supported values of 4320 FEATURE see *note Add Options::. 4321 4322'{ dg-additional-options OPTIONS [{ target SELECTOR }] }' 4323 This directive provides a list of compiler options, to be used if 4324 the target system matches SELECTOR, that are added to the default 4325 options used for this set of tests. 4326 43277.2.1.3 Modify the test timeout value 4328..................................... 4329 4330The normal timeout limit, in seconds, is found by searching the 4331following in order: 4332 4333 * the value defined by an earlier 'dg-timeout' directive in the test 4334 4335 * variable TOOL_TIMEOUT defined by the set of tests 4336 4337 * GCC,TIMEOUT set in the target board 4338 4339 * 300 4340 4341'{ dg-timeout N [{target SELECTOR }] }' 4342 Set the time limit for the compilation and for the execution of the 4343 test to the specified number of seconds. 4344 4345'{ dg-timeout-factor X [{ target SELECTOR }] }' 4346 Multiply the normal time limit for compilation and execution of the 4347 test by the specified floating-point factor. 4348 43497.2.1.4 Skip a test for some targets 4350.................................... 4351 4352'{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4353 Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each 4354 element is a string of zero or more GCC options. Skip the test if 4355 all of the following conditions are met: 4356 * the test system is included in SELECTOR 4357 4358 * for at least one of the option strings in INCLUDE-OPTS, every 4359 option from that string is in the set of options with which 4360 the test would be compiled; use '"*"' for an INCLUDE-OPTS list 4361 that matches any options; that is the default if INCLUDE-OPTS 4362 is not specified 4363 4364 * for each of the option strings in EXCLUDE-OPTS, at least one 4365 option from that string is not in the set of options with 4366 which the test would be compiled; use '""' for an empty 4367 EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not 4368 specified 4369 4370 For example, to skip a test if option '-Os' is present: 4371 4372 /* { dg-skip-if "" { *-*-* } { "-Os" } { "" } } */ 4373 4374 To skip a test if both options '-O2' and '-g' are present: 4375 4376 /* { dg-skip-if "" { *-*-* } { "-O2 -g" } { "" } } */ 4377 4378 To skip a test if either '-O2' or '-O3' is present: 4379 4380 /* { dg-skip-if "" { *-*-* } { "-O2" "-O3" } { "" } } */ 4381 4382 To skip a test unless option '-Os' is present: 4383 4384 /* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */ 4385 4386 To skip a test if either '-O2' or '-O3' is used with '-g' but not 4387 if '-fpic' is also present: 4388 4389 /* { dg-skip-if "" { *-*-* } { "-O2 -g" "-O3 -g" } { "-fpic" } } */ 4390 4391'{ dg-require-effective-target KEYWORD [{ SELECTOR }] }' 4392 Skip the test if the test target, including current multilib flags, 4393 is not covered by the effective-target keyword. If the directive 4394 includes the optional '{ SELECTOR }' then the effective-target test 4395 is only performed if the target system matches the SELECTOR. This 4396 directive must appear after any 'dg-do' directive in the test and 4397 before any 'dg-additional-sources' directive. *Note 4398 Effective-Target Keywords::. 4399 4400'{ dg-require-SUPPORT args }' 4401 Skip the test if the target does not provide the required support. 4402 These directives must appear after any 'dg-do' directive in the 4403 test and before any 'dg-additional-sources' directive. They 4404 require at least one argument, which can be an empty string if the 4405 specific procedure does not examine the argument. *Note Require 4406 Support::, for a complete list of these directives. 4407 44087.2.1.5 Expect a test to fail for some targets 4409.............................................. 4410 4411'{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4412 Expect the test to fail if the conditions (which are the same as 4413 for 'dg-skip-if') are met. This does not affect the execute step. 4414 4415'{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4416 Expect the execute step of a test to fail if the conditions (which 4417 are the same as for 'dg-skip-if') are met. 4418 44197.2.1.6 Expect the test executable to fail 4420.......................................... 4421 4422'{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }' 4423 Expect the test executable to return a nonzero exit status if the 4424 conditions (which are the same as for 'dg-skip-if') are met. 4425 44267.2.1.7 Verify compiler messages 4427................................ 4428 4429Where LINE is an accepted argument for these commands, a value of '0' 4430can be used if there is no line associated with the message. 4431 4432'{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4433 This DejaGnu directive appears on a source line that is expected to 4434 get an error message, or else specifies the source line associated 4435 with the message. If there is no message for that line or if the 4436 text of that message is not matched by REGEXP then the check fails 4437 and COMMENT is included in the 'FAIL' message. The check does not 4438 look for the string 'error' unless it is part of REGEXP. 4439 4440'{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4441 This DejaGnu directive appears on a source line that is expected to 4442 get a warning message, or else specifies the source line associated 4443 with the message. If there is no message for that line or if the 4444 text of that message is not matched by REGEXP then the check fails 4445 and COMMENT is included in the 'FAIL' message. The check does not 4446 look for the string 'warning' unless it is part of REGEXP. 4447 4448'{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4449 The line is expected to get a message other than an error or 4450 warning. If there is no message for that line or if the text of 4451 that message is not matched by REGEXP then the check fails and 4452 COMMENT is included in the 'FAIL' message. 4453 4454'{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4455 This DejaGnu directive appears on a source line that should not get 4456 a message matching REGEXP, or else specifies the source line 4457 associated with the bogus message. It is usually used with 'xfail' 4458 to indicate that the message is a known problem for a particular 4459 set of targets. 4460 4461'{ dg-line LINENUMVAR }' 4462 This DejaGnu directive sets the variable LINENUMVAR to the line 4463 number of the source line. The variable LINENUMVAR can then be 4464 used in subsequent 'dg-error', 'dg-warning', 'dg-message' and 4465 'dg-bogus' directives. For example: 4466 4467 int a; /* { dg-line first_def_a } */ 4468 float a; /* { dg-error "conflicting types of" } */ 4469 /* { dg-message "previous declaration of" "" { target *-*-* } first_def_a } */ 4470 4471'{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }' 4472 This DejaGnu directive indicates that the test is expected to fail 4473 due to compiler messages that are not handled by 'dg-error', 4474 'dg-warning' or 'dg-bogus'. For this directive 'xfail' has the 4475 same effect as 'target'. 4476 4477'{ dg-prune-output REGEXP }' 4478 Prune messages matching REGEXP from the test output. 4479 44807.2.1.8 Verify output of the test executable 4481............................................ 4482 4483'{ dg-output REGEXP [{ target/xfail SELECTOR }] }' 4484 This DejaGnu directive compares REGEXP to the combined output that 4485 the test executable writes to 'stdout' and 'stderr'. 4486 44877.2.1.9 Specify environment variables for a test 4488................................................ 4489 4490'{ dg-set-compiler-env-var VAR_NAME "VAR_VALUE" }' 4491 Specify that the environment variable VAR_NAME needs to be set to 4492 VAR_VALUE before invoking the compiler on the test file. 4493 4494'{ dg-set-target-env-var VAR_NAME "VAR_VALUE" }' 4495 Specify that the environment variable VAR_NAME needs to be set to 4496 VAR_VALUE before execution of the program created by the test. 4497 44987.2.1.10 Specify additional files for a test 4499............................................ 4500 4501'{ dg-additional-files "FILELIST" }' 4502 Specify additional files, other than source files, that must be 4503 copied to the system where the compiler runs. 4504 4505'{ dg-additional-sources "FILELIST" }' 4506 Specify additional source files to appear in the compile line 4507 following the main test file. 4508 45097.2.1.11 Add checks at the end of a test 4510........................................ 4511 4512'{ dg-final { LOCAL-DIRECTIVE } }' 4513 This DejaGnu directive is placed within a comment anywhere in the 4514 source file and is processed after the test has been compiled and 4515 run. Multiple 'dg-final' commands are processed in the order in 4516 which they appear in the source file. *Note Final Actions::, for a 4517 list of directives that can be used within 'dg-final'. 4518 4519 4520File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives 4521 45227.2.2 Selecting targets to which a test applies 4523----------------------------------------------- 4524 4525Several test directives include SELECTORs to limit the targets for which 4526a test is run or to declare that a test is expected to fail on 4527particular targets. 4528 4529 A selector is: 4530 * one or more target triplets, possibly including wildcard 4531 characters; use '*-*-*' to match any target 4532 * a single effective-target keyword (*note Effective-Target 4533 Keywords::) 4534 * a logical expression 4535 4536 Depending on the context, the selector specifies whether a test is 4537skipped and reported as unsupported or is expected to fail. A context 4538that allows either 'target' or 'xfail' also allows '{ target SELECTOR1 4539xfail SELECTOR2 }' to skip the test for targets that don't match 4540SELECTOR1 and the test to fail for targets that match SELECTOR2. 4541 4542 A selector expression appears within curly braces and uses a single 4543logical operator: one of '!', '&&', or '||'. An operand is another 4544selector expression, an effective-target keyword, a single target 4545triplet, or a list of target triplets within quotes or curly braces. 4546For example: 4547 4548 { target { ! "hppa*-*-* ia64*-*-*" } } 4549 { target { powerpc*-*-* && lp64 } } 4550 { xfail { lp64 || vect_no_align } } 4551 4552 4553File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives 4554 45557.2.3 Keywords describing target attributes 4556------------------------------------------- 4557 4558Effective-target keywords identify sets of targets that support 4559particular functionality. They are used to limit tests to be run only 4560for particular targets, or to specify that particular sets of targets 4561are expected to fail some tests. 4562 4563 Effective-target keywords are defined in 'lib/target-supports.exp' in 4564the GCC testsuite, with the exception of those that are documented as 4565being local to a particular test directory. 4566 4567 The 'effective target' takes into account all of the compiler options 4568with which the test will be compiled, including the multilib options. 4569By convention, keywords ending in '_nocache' can also include options 4570specified for the particular test in an earlier 'dg-options' or 4571'dg-add-options' directive. 4572 45737.2.3.1 Endianness 4574.................. 4575 4576'be' 4577 Target uses big-endian memory order for multi-byte and multi-word 4578 data. 4579 4580'le' 4581 Target uses little-endian memory order for multi-byte and 4582 multi-word data. 4583 45847.2.3.2 Data type sizes 4585....................... 4586 4587'ilp32' 4588 Target has 32-bit 'int', 'long', and pointers. 4589 4590'lp64' 4591 Target has 32-bit 'int', 64-bit 'long' and pointers. 4592 4593'llp64' 4594 Target has 32-bit 'int' and 'long', 64-bit 'long long' and 4595 pointers. 4596 4597'double64' 4598 Target has 64-bit 'double'. 4599 4600'double64plus' 4601 Target has 'double' that is 64 bits or longer. 4602 4603'longdouble128' 4604 Target has 128-bit 'long double'. 4605 4606'int32plus' 4607 Target has 'int' that is at 32 bits or longer. 4608 4609'int16' 4610 Target has 'int' that is 16 bits or shorter. 4611 4612'longlong64' 4613 Target has 64-bit 'long long'. 4614 4615'long_neq_int' 4616 Target has 'int' and 'long' with different sizes. 4617 4618'int_eq_float' 4619 Target has 'int' and 'float' with the same size. 4620 4621'ptr_eq_long' 4622 Target has pointers ('void *') and 'long' with the same size. 4623 4624'large_double' 4625 Target supports 'double' that is longer than 'float'. 4626 4627'large_long_double' 4628 Target supports 'long double' that is longer than 'double'. 4629 4630'ptr32plus' 4631 Target has pointers that are 32 bits or longer. 4632 4633'size20plus' 4634 Target has a 20-bit or larger address space, so at least supports 4635 16-bit array and structure sizes. 4636 4637'size32plus' 4638 Target has a 32-bit or larger address space, so at least supports 4639 24-bit array and structure sizes. 4640 4641'4byte_wchar_t' 4642 Target has 'wchar_t' that is at least 4 bytes. 4643 4644'floatN' 4645 Target has the '_FloatN' type. 4646 4647'floatNx' 4648 Target has the '_FloatNx' type. 4649 4650'floatN_runtime' 4651 Target has the '_FloatN' type, including runtime support for any 4652 options added with 'dg-add-options'. 4653 4654'floatNx_runtime' 4655 Target has the '_FloatNx' type, including runtime support for any 4656 options added with 'dg-add-options'. 4657 4658'floatn_nx_runtime' 4659 Target has runtime support for any options added with 4660 'dg-add-options' for any '_FloatN' or '_FloatNx' type. 4661 4662'inf' 4663 Target supports floating point infinite ('inf') for type 'double'. 4664 46657.2.3.3 Fortran-specific attributes 4666................................... 4667 4668'fortran_integer_16' 4669 Target supports Fortran 'integer' that is 16 bytes or longer. 4670 4671'fortran_real_10' 4672 Target supports Fortran 'real' that is 10 bytes or longer. 4673 4674'fortran_real_16' 4675 Target supports Fortran 'real' that is 16 bytes or longer. 4676 4677'fortran_large_int' 4678 Target supports Fortran 'integer' kinds larger than 'integer(8)'. 4679 4680'fortran_large_real' 4681 Target supports Fortran 'real' kinds larger than 'real(8)'. 4682 46837.2.3.4 Vector-specific attributes 4684.................................. 4685 4686'vect_align_stack_vars' 4687 The target's ABI allows stack variables to be aligned to the 4688 preferred vector alignment. 4689 4690'vect_avg_qi' 4691 Target supports both signed and unsigned averaging operations on 4692 vectors of bytes. 4693 4694'vect_mulhrs_hi' 4695 Target supports both signed and unsigned 4696 multiply-high-with-round-and-scale operations on vectors of 4697 half-words. 4698 4699'vect_sdiv_pow2_si' 4700 Target supports signed division by constant power-of-2 operations 4701 on vectors of 4-byte integers. 4702 4703'vect_condition' 4704 Target supports vector conditional operations. 4705 4706'vect_cond_mixed' 4707 Target supports vector conditional operations where comparison 4708 operands have different type from the value operands. 4709 4710'vect_double' 4711 Target supports hardware vectors of 'double'. 4712 4713'vect_double_cond_arith' 4714 Target supports conditional addition, subtraction, multiplication, 4715 division, minimum and maximum on vectors of 'double', via the 4716 'cond_' optabs. 4717 4718'vect_element_align_preferred' 4719 The target's preferred vector alignment is the same as the element 4720 alignment. 4721 4722'vect_float' 4723 Target supports hardware vectors of 'float' when 4724 '-funsafe-math-optimizations' is in effect. 4725 4726'vect_float_strict' 4727 Target supports hardware vectors of 'float' when 4728 '-funsafe-math-optimizations' is not in effect. This implies 4729 'vect_float'. 4730 4731'vect_int' 4732 Target supports hardware vectors of 'int'. 4733 4734'vect_long' 4735 Target supports hardware vectors of 'long'. 4736 4737'vect_long_long' 4738 Target supports hardware vectors of 'long long'. 4739 4740'vect_check_ptrs' 4741 Target supports the 'check_raw_ptrs' and 'check_war_ptrs' optabs on 4742 vectors. 4743 4744'vect_fully_masked' 4745 Target supports fully-masked (also known as fully-predicated) 4746 loops, so that vector loops can handle partial as well as full 4747 vectors. 4748 4749'vect_masked_store' 4750 Target supports vector masked stores. 4751 4752'vect_scatter_store' 4753 Target supports vector scatter stores. 4754 4755'vect_aligned_arrays' 4756 Target aligns arrays to vector alignment boundary. 4757 4758'vect_hw_misalign' 4759 Target supports a vector misalign access. 4760 4761'vect_no_align' 4762 Target does not support a vector alignment mechanism. 4763 4764'vect_peeling_profitable' 4765 Target might require to peel loops for alignment purposes. 4766 4767'vect_no_int_min_max' 4768 Target does not support a vector min and max instruction on 'int'. 4769 4770'vect_no_int_add' 4771 Target does not support a vector add instruction on 'int'. 4772 4773'vect_no_bitwise' 4774 Target does not support vector bitwise instructions. 4775 4776'vect_bool_cmp' 4777 Target supports comparison of 'bool' vectors for at least one 4778 vector length. 4779 4780'vect_char_add' 4781 Target supports addition of 'char' vectors for at least one vector 4782 length. 4783 4784'vect_char_mult' 4785 Target supports 'vector char' multiplication. 4786 4787'vect_short_mult' 4788 Target supports 'vector short' multiplication. 4789 4790'vect_int_mult' 4791 Target supports 'vector int' multiplication. 4792 4793'vect_long_mult' 4794 Target supports 64 bit 'vector long' multiplication. 4795 4796'vect_extract_even_odd' 4797 Target supports vector even/odd element extraction. 4798 4799'vect_extract_even_odd_wide' 4800 Target supports vector even/odd element extraction of vectors with 4801 elements 'SImode' or larger. 4802 4803'vect_interleave' 4804 Target supports vector interleaving. 4805 4806'vect_strided' 4807 Target supports vector interleaving and extract even/odd. 4808 4809'vect_strided_wide' 4810 Target supports vector interleaving and extract even/odd for wide 4811 element types. 4812 4813'vect_perm' 4814 Target supports vector permutation. 4815 4816'vect_perm_byte' 4817 Target supports permutation of vectors with 8-bit elements. 4818 4819'vect_perm_short' 4820 Target supports permutation of vectors with 16-bit elements. 4821 4822'vect_perm3_byte' 4823 Target supports permutation of vectors with 8-bit elements, and for 4824 the default vector length it is possible to permute: 4825 { a0, a1, a2, b0, b1, b2, ... } 4826 to: 4827 { a0, a0, a0, b0, b0, b0, ... } 4828 { a1, a1, a1, b1, b1, b1, ... } 4829 { a2, a2, a2, b2, b2, b2, ... } 4830 using only two-vector permutes, regardless of how long the sequence 4831 is. 4832 4833'vect_perm3_int' 4834 Like 'vect_perm3_byte', but for 32-bit elements. 4835 4836'vect_perm3_short' 4837 Like 'vect_perm3_byte', but for 16-bit elements. 4838 4839'vect_shift' 4840 Target supports a hardware vector shift operation. 4841 4842'vect_unaligned_possible' 4843 Target prefers vectors to have an alignment greater than element 4844 alignment, but also allows unaligned vector accesses in some 4845 circumstances. 4846 4847'vect_variable_length' 4848 Target has variable-length vectors. 4849 4850'vect_widen_sum_hi_to_si' 4851 Target supports a vector widening summation of 'short' operands 4852 into 'int' results, or can promote (unpack) from 'short' to 'int'. 4853 4854'vect_widen_sum_qi_to_hi' 4855 Target supports a vector widening summation of 'char' operands into 4856 'short' results, or can promote (unpack) from 'char' to 'short'. 4857 4858'vect_widen_sum_qi_to_si' 4859 Target supports a vector widening summation of 'char' operands into 4860 'int' results. 4861 4862'vect_widen_mult_qi_to_hi' 4863 Target supports a vector widening multiplication of 'char' operands 4864 into 'short' results, or can promote (unpack) from 'char' to 4865 'short' and perform non-widening multiplication of 'short'. 4866 4867'vect_widen_mult_hi_to_si' 4868 Target supports a vector widening multiplication of 'short' 4869 operands into 'int' results, or can promote (unpack) from 'short' 4870 to 'int' and perform non-widening multiplication of 'int'. 4871 4872'vect_widen_mult_si_to_di_pattern' 4873 Target supports a vector widening multiplication of 'int' operands 4874 into 'long' results. 4875 4876'vect_sdot_qi' 4877 Target supports a vector dot-product of 'signed char'. 4878 4879'vect_udot_qi' 4880 Target supports a vector dot-product of 'unsigned char'. 4881 4882'vect_sdot_hi' 4883 Target supports a vector dot-product of 'signed short'. 4884 4885'vect_udot_hi' 4886 Target supports a vector dot-product of 'unsigned short'. 4887 4888'vect_pack_trunc' 4889 Target supports a vector demotion (packing) of 'short' to 'char' 4890 and from 'int' to 'short' using modulo arithmetic. 4891 4892'vect_unpack' 4893 Target supports a vector promotion (unpacking) of 'char' to 'short' 4894 and from 'char' to 'int'. 4895 4896'vect_intfloat_cvt' 4897 Target supports conversion from 'signed int' to 'float'. 4898 4899'vect_uintfloat_cvt' 4900 Target supports conversion from 'unsigned int' to 'float'. 4901 4902'vect_floatint_cvt' 4903 Target supports conversion from 'float' to 'signed int'. 4904 4905'vect_floatuint_cvt' 4906 Target supports conversion from 'float' to 'unsigned int'. 4907 4908'vect_intdouble_cvt' 4909 Target supports conversion from 'signed int' to 'double'. 4910 4911'vect_doubleint_cvt' 4912 Target supports conversion from 'double' to 'signed int'. 4913 4914'vect_max_reduc' 4915 Target supports max reduction for vectors. 4916 4917'vect_sizes_16B_8B' 4918 Target supports 16- and 8-bytes vectors. 4919 4920'vect_sizes_32B_16B' 4921 Target supports 32- and 16-bytes vectors. 4922 4923'vect_logical_reduc' 4924 Target supports AND, IOR and XOR reduction on vectors. 4925 4926'vect_fold_extract_last' 4927 Target supports the 'fold_extract_last' optab. 4928 49297.2.3.5 Thread Local Storage attributes 4930....................................... 4931 4932'tls' 4933 Target supports thread-local storage. 4934 4935'tls_native' 4936 Target supports native (rather than emulated) thread-local storage. 4937 4938'tls_runtime' 4939 Test system supports executing TLS executables. 4940 49417.2.3.6 Decimal floating point attributes 4942......................................... 4943 4944'dfp' 4945 Targets supports compiling decimal floating point extension to C. 4946 4947'dfp_nocache' 4948 Including the options used to compile this particular test, the 4949 target supports compiling decimal floating point extension to C. 4950 4951'dfprt' 4952 Test system can execute decimal floating point tests. 4953 4954'dfprt_nocache' 4955 Including the options used to compile this particular test, the 4956 test system can execute decimal floating point tests. 4957 4958'hard_dfp' 4959 Target generates decimal floating point instructions with current 4960 options. 4961 49627.2.3.7 ARM-specific attributes 4963............................... 4964 4965'arm32' 4966 ARM target generates 32-bit code. 4967 4968'arm_little_endian' 4969 ARM target that generates little-endian code. 4970 4971'arm_eabi' 4972 ARM target adheres to the ABI for the ARM Architecture. 4973 4974'arm_fp_ok' 4975 ARM target defines '__ARM_FP' using '-mfloat-abi=softfp' or 4976 equivalent options. Some multilibs may be incompatible with these 4977 options. 4978 4979'arm_fp_dp_ok' 4980 ARM target defines '__ARM_FP' with double-precision support using 4981 '-mfloat-abi=softfp' or equivalent options. Some multilibs may be 4982 incompatible with these options. 4983 4984'arm_hf_eabi' 4985 ARM target adheres to the VFP and Advanced SIMD Register Arguments 4986 variant of the ABI for the ARM Architecture (as selected with 4987 '-mfloat-abi=hard'). 4988 4989'arm_softfloat' 4990 ARM target uses the soft-float ABI with no floating-point 4991 instructions used whatsoever (as selected with '-mfloat-abi=soft'). 4992 4993'arm_hard_vfp_ok' 4994 ARM target supports '-mfpu=vfp -mfloat-abi=hard'. Some multilibs 4995 may be incompatible with these options. 4996 4997'arm_iwmmxt_ok' 4998 ARM target supports '-mcpu=iwmmxt'. Some multilibs may be 4999 incompatible with this option. 5000 5001'arm_neon' 5002 ARM target supports generating NEON instructions. 5003 5004'arm_tune_string_ops_prefer_neon' 5005 Test CPU tune supports inlining string operations with NEON 5006 instructions. 5007 5008'arm_neon_hw' 5009 Test system supports executing NEON instructions. 5010 5011'arm_neonv2_hw' 5012 Test system supports executing NEON v2 instructions. 5013 5014'arm_neon_ok' 5015 ARM Target supports '-mfpu=neon -mfloat-abi=softfp' or compatible 5016 options. Some multilibs may be incompatible with these options. 5017 5018'arm_neon_ok_no_float_abi' 5019 ARM Target supports NEON with '-mfpu=neon', but without any 5020 -mfloat-abi= option. Some multilibs may be incompatible with this 5021 option. 5022 5023'arm_neonv2_ok' 5024 ARM Target supports '-mfpu=neon-vfpv4 -mfloat-abi=softfp' or 5025 compatible options. Some multilibs may be incompatible with these 5026 options. 5027 5028'arm_fp16_ok' 5029 Target supports options to generate VFP half-precision 5030 floating-point instructions. Some multilibs may be incompatible 5031 with these options. This test is valid for ARM only. 5032 5033'arm_fp16_hw' 5034 Target supports executing VFP half-precision floating-point 5035 instructions. This test is valid for ARM only. 5036 5037'arm_neon_fp16_ok' 5038 ARM Target supports '-mfpu=neon-fp16 -mfloat-abi=softfp' or 5039 compatible options, including '-mfp16-format=ieee' if necessary to 5040 obtain the '__fp16' type. Some multilibs may be incompatible with 5041 these options. 5042 5043'arm_neon_fp16_hw' 5044 Test system supports executing Neon half-precision float 5045 instructions. (Implies previous.) 5046 5047'arm_fp16_alternative_ok' 5048 ARM target supports the ARM FP16 alternative format. Some 5049 multilibs may be incompatible with the options needed. 5050 5051'arm_fp16_none_ok' 5052 ARM target supports specifying none as the ARM FP16 format. 5053 5054'arm_thumb1_ok' 5055 ARM target generates Thumb-1 code for '-mthumb'. 5056 5057'arm_thumb2_ok' 5058 ARM target generates Thumb-2 code for '-mthumb'. 5059 5060'arm_nothumb' 5061 ARM target that is not using Thumb. 5062 5063'arm_vfp_ok' 5064 ARM target supports '-mfpu=vfp -mfloat-abi=softfp'. Some multilibs 5065 may be incompatible with these options. 5066 5067'arm_vfp3_ok' 5068 ARM target supports '-mfpu=vfp3 -mfloat-abi=softfp'. Some 5069 multilibs may be incompatible with these options. 5070 5071'arm_arch_v8a_hard_ok' 5072 The compiler is targeting 'arm*-*-*' and can compile and assemble 5073 code using the options '-march=armv8-a -mfpu=neon-fp-armv8 5074 -mfloat-abi=hard'. This is not enough to guarantee that linking 5075 works. 5076 5077'arm_arch_v8a_hard_multilib' 5078 The compiler is targeting 'arm*-*-*' and can build programs using 5079 the options '-march=armv8-a -mfpu=neon-fp-armv8 -mfloat-abi=hard'. 5080 The target can also run the resulting binaries. 5081 5082'arm_v8_vfp_ok' 5083 ARM target supports '-mfpu=fp-armv8 -mfloat-abi=softfp'. Some 5084 multilibs may be incompatible with these options. 5085 5086'arm_v8_neon_ok' 5087 ARM target supports '-mfpu=neon-fp-armv8 -mfloat-abi=softfp'. Some 5088 multilibs may be incompatible with these options. 5089 5090'arm_v8_1a_neon_ok' 5091 ARM target supports options to generate ARMv8.1-A Adv.SIMD 5092 instructions. Some multilibs may be incompatible with these 5093 options. 5094 5095'arm_v8_1a_neon_hw' 5096 ARM target supports executing ARMv8.1-A Adv.SIMD instructions. 5097 Some multilibs may be incompatible with the options needed. 5098 Implies arm_v8_1a_neon_ok. 5099 5100'arm_acq_rel' 5101 ARM target supports acquire-release instructions. 5102 5103'arm_v8_2a_fp16_scalar_ok' 5104 ARM target supports options to generate instructions for ARMv8.2-A 5105 and scalar instructions from the FP16 extension. Some multilibs 5106 may be incompatible with these options. 5107 5108'arm_v8_2a_fp16_scalar_hw' 5109 ARM target supports executing instructions for ARMv8.2-A and scalar 5110 instructions from the FP16 extension. Some multilibs may be 5111 incompatible with these options. Implies arm_v8_2a_fp16_neon_ok. 5112 5113'arm_v8_2a_fp16_neon_ok' 5114 ARM target supports options to generate instructions from ARMv8.2-A 5115 with the FP16 extension. Some multilibs may be incompatible with 5116 these options. Implies arm_v8_2a_fp16_scalar_ok. 5117 5118'arm_v8_2a_fp16_neon_hw' 5119 ARM target supports executing instructions from ARMv8.2-A with the 5120 FP16 extension. Some multilibs may be incompatible with these 5121 options. Implies arm_v8_2a_fp16_neon_ok and 5122 arm_v8_2a_fp16_scalar_hw. 5123 5124'arm_v8_2a_dotprod_neon_ok' 5125 ARM target supports options to generate instructions from ARMv8.2-A 5126 with the Dot Product extension. Some multilibs may be incompatible 5127 with these options. 5128 5129'arm_v8_2a_dotprod_neon_hw' 5130 ARM target supports executing instructions from ARMv8.2-A with the 5131 Dot Product extension. Some multilibs may be incompatible with 5132 these options. Implies arm_v8_2a_dotprod_neon_ok. 5133 5134'arm_fp16fml_neon_ok' 5135 ARM target supports extensions to generate the 'VFMAL' and 'VFMLS' 5136 half-precision floating-point instructions available from ARMv8.2-A 5137 and onwards. Some multilibs may be incompatible with these 5138 options. 5139 5140'arm_v8_2a_bf16_neon_ok' 5141 ARM target supports options to generate instructions from ARMv8.2-A 5142 with the BFloat16 extension (bf16). Some multilibs may be 5143 incompatible with these options. 5144 5145'arm_v8_2a_i8mm_ok' 5146 ARM target supports options to generate instructions from ARMv8.2-A 5147 with the 8-Bit Integer Matrix Multiply extension (i8mm). Some 5148 multilibs may be incompatible with these options. 5149 5150'arm_v8_1m_mve_ok' 5151 ARM target supports options to generate instructions from ARMv8.1-M 5152 with the M-Profile Vector Extension (MVE). Some multilibs may be 5153 incompatible with these options. 5154 5155'arm_v8_1m_mve_fp_ok' 5156 ARM target supports options to generate instructions from ARMv8.1-M 5157 with the Half-precision floating-point instructions (HP), 5158 Floating-point Extension (FP) along with M-Profile Vector Extension 5159 (MVE). Some multilibs may be incompatible with these options. 5160 5161'arm_mve_hw' 5162 Test system supports executing MVE instructions. 5163 5164'arm_v8m_main_cde' 5165 ARM target supports options to generate instructions from ARMv8-M 5166 with the Custom Datapath Extension (CDE). Some multilibs may be 5167 incompatible with these options. 5168 5169'arm_v8m_main_cde_fp' 5170 ARM target supports options to generate instructions from ARMv8-M 5171 with the Custom Datapath Extension (CDE) and floating-point (VFP). 5172 Some multilibs may be incompatible with these options. 5173 5174'arm_v8_1m_main_cde_mve' 5175 ARM target supports options to generate instructions from ARMv8.1-M 5176 with the Custom Datapath Extension (CDE) and M-Profile Vector 5177 Extension (MVE). Some multilibs may be incompatible with these 5178 options. 5179 5180'arm_prefer_ldrd_strd' 5181 ARM target prefers 'LDRD' and 'STRD' instructions over 'LDM' and 5182 'STM' instructions. 5183 5184'arm_thumb1_movt_ok' 5185 ARM target generates Thumb-1 code for '-mthumb' with 'MOVW' and 5186 'MOVT' instructions available. 5187 5188'arm_thumb1_cbz_ok' 5189 ARM target generates Thumb-1 code for '-mthumb' with 'CBZ' and 5190 'CBNZ' instructions available. 5191 5192'arm_divmod_simode' 5193 ARM target for which divmod transform is disabled, if it supports 5194 hardware div instruction. 5195 5196'arm_cmse_ok' 5197 ARM target supports ARMv8-M Security Extensions, enabled by the 5198 '-mcmse' option. 5199 5200'arm_coproc1_ok' 5201 ARM target supports the following coprocessor instructions: 'CDP', 5202 'LDC', 'STC', 'MCR' and 'MRC'. 5203 5204'arm_coproc2_ok' 5205 ARM target supports all the coprocessor instructions also listed as 5206 supported in *note arm_coproc1_ok:: in addition to the following: 5207 'CDP2', 'LDC2', 'LDC2l', 'STC2', 'STC2l', 'MCR2' and 'MRC2'. 5208 5209'arm_coproc3_ok' 5210 ARM target supports all the coprocessor instructions also listed as 5211 supported in *note arm_coproc2_ok:: in addition the following: 5212 'MCRR' and 'MRRC'. 5213 5214'arm_coproc4_ok' 5215 ARM target supports all the coprocessor instructions also listed as 5216 supported in *note arm_coproc3_ok:: in addition the following: 5217 'MCRR2' and 'MRRC2'. 5218 5219'arm_simd32_ok' 5220 ARM Target supports options suitable for accessing the SIMD32 5221 intrinsics from 'arm_acle.h'. Some multilibs may be incompatible 5222 with these options. 5223 5224'arm_qbit_ok' 5225 ARM Target supports options suitable for accessing the Q-bit 5226 manipulation intrinsics from 'arm_acle.h'. Some multilibs may be 5227 incompatible with these options. 5228 5229'arm_softfp_ok' 5230 ARM target supports the '-mfloat-abi=softfp' option. 5231 5232'arm_hard_ok' 5233 ARM target supports the '-mfloat-abi=hard' option. 5234 52357.2.3.8 AArch64-specific attributes 5236................................... 5237 5238'aarch64_asm_<ext>_ok' 5239 AArch64 assembler supports the architecture extension 'ext' via the 5240 '.arch_extension' pseudo-op. 5241'aarch64_tiny' 5242 AArch64 target which generates instruction sequences for tiny 5243 memory model. 5244'aarch64_small' 5245 AArch64 target which generates instruction sequences for small 5246 memory model. 5247'aarch64_large' 5248 AArch64 target which generates instruction sequences for large 5249 memory model. 5250'aarch64_little_endian' 5251 AArch64 target which generates instruction sequences for little 5252 endian. 5253'aarch64_big_endian' 5254 AArch64 target which generates instruction sequences for big 5255 endian. 5256'aarch64_small_fpic' 5257 Binutils installed on test system supports relocation types 5258 required by -fpic for AArch64 small memory model. 5259'aarch64_sve_hw' 5260 AArch64 target that is able to generate and execute SVE code 5261 (regardless of whether it does so by default). 5262'aarch64_sve128_hw' 5263'aarch64_sve256_hw' 5264'aarch64_sve512_hw' 5265'aarch64_sve1024_hw' 5266'aarch64_sve2048_hw' 5267 Like 'aarch64_sve_hw', but also test for an exact hardware vector 5268 length. 5269 5270'aarch64_fjcvtzs_hw' 5271 AArch64 target that is able to generate and execute armv8.3-a 5272 FJCVTZS instruction. 5273 52747.2.3.9 MIPS-specific attributes 5275................................ 5276 5277'mips64' 5278 MIPS target supports 64-bit instructions. 5279 5280'nomips16' 5281 MIPS target does not produce MIPS16 code. 5282 5283'mips16_attribute' 5284 MIPS target can generate MIPS16 code. 5285 5286'mips_loongson' 5287 MIPS target is a Loongson-2E or -2F target using an ABI that 5288 supports the Loongson vector modes. 5289 5290'mips_msa' 5291 MIPS target supports '-mmsa', MIPS SIMD Architecture (MSA). 5292 5293'mips_newabi_large_long_double' 5294 MIPS target supports 'long double' larger than 'double' when using 5295 the new ABI. 5296 5297'mpaired_single' 5298 MIPS target supports '-mpaired-single'. 5299 53007.2.3.10 PowerPC-specific attributes 5301.................................... 5302 5303'dfp_hw' 5304 PowerPC target supports executing hardware DFP instructions. 5305 5306'p8vector_hw' 5307 PowerPC target supports executing VSX instructions (ISA 2.07). 5308 5309'powerpc64' 5310 Test system supports executing 64-bit instructions. 5311 5312'powerpc_altivec' 5313 PowerPC target supports AltiVec. 5314 5315'powerpc_altivec_ok' 5316 PowerPC target supports '-maltivec'. 5317 5318'powerpc_eabi_ok' 5319 PowerPC target supports '-meabi'. 5320 5321'powerpc_elfv2' 5322 PowerPC target supports '-mabi=elfv2'. 5323 5324'powerpc_fprs' 5325 PowerPC target supports floating-point registers. 5326 5327'powerpc_hard_double' 5328 PowerPC target supports hardware double-precision floating-point. 5329 5330'powerpc_htm_ok' 5331 PowerPC target supports '-mhtm' 5332 5333'powerpc_p8vector_ok' 5334 PowerPC target supports '-mpower8-vector' 5335 5336'powerpc_popcntb_ok' 5337 PowerPC target supports the 'popcntb' instruction, indicating that 5338 this target supports '-mcpu=power5'. 5339 5340'powerpc_ppu_ok' 5341 PowerPC target supports '-mcpu=cell'. 5342 5343'powerpc_spe' 5344 PowerPC target supports PowerPC SPE. 5345 5346'powerpc_spe_nocache' 5347 Including the options used to compile this particular test, the 5348 PowerPC target supports PowerPC SPE. 5349 5350'powerpc_spu' 5351 PowerPC target supports PowerPC SPU. 5352 5353'powerpc_vsx_ok' 5354 PowerPC target supports '-mvsx'. 5355 5356'powerpc_405_nocache' 5357 Including the options used to compile this particular test, the 5358 PowerPC target supports PowerPC 405. 5359 5360'ppc_recip_hw' 5361 PowerPC target supports executing reciprocal estimate instructions. 5362 5363'vmx_hw' 5364 PowerPC target supports executing AltiVec instructions. 5365 5366'vsx_hw' 5367 PowerPC target supports executing VSX instructions (ISA 2.06). 5368 53697.2.3.11 Other hardware attributes 5370.................................. 5371 5372'autoincdec' 5373 Target supports autoincrement/decrement addressing. 5374 5375'avx' 5376 Target supports compiling 'avx' instructions. 5377 5378'avx_runtime' 5379 Target supports the execution of 'avx' instructions. 5380 5381'avx2' 5382 Target supports compiling 'avx2' instructions. 5383 5384'avx2_runtime' 5385 Target supports the execution of 'avx2' instructions. 5386 5387'avx512f' 5388 Target supports compiling 'avx512f' instructions. 5389 5390'avx512f_runtime' 5391 Target supports the execution of 'avx512f' instructions. 5392 5393'avx512vp2intersect' 5394 Target supports the execution of 'avx512vp2intersect' instructions. 5395 5396'cell_hw' 5397 Test system can execute AltiVec and Cell PPU instructions. 5398 5399'coldfire_fpu' 5400 Target uses a ColdFire FPU. 5401 5402'divmod' 5403 Target supporting hardware divmod insn or divmod libcall. 5404 5405'divmod_simode' 5406 Target supporting hardware divmod insn or divmod libcall for 5407 SImode. 5408 5409'hard_float' 5410 Target supports FPU instructions. 5411 5412'non_strict_align' 5413 Target does not require strict alignment. 5414 5415'pie_copyreloc' 5416 The x86-64 target linker supports PIE with copy reloc. 5417 5418'rdrand' 5419 Target supports x86 'rdrand' instruction. 5420 5421'sqrt_insn' 5422 Target has a square root instruction that the compiler can 5423 generate. 5424 5425'sse' 5426 Target supports compiling 'sse' instructions. 5427 5428'sse_runtime' 5429 Target supports the execution of 'sse' instructions. 5430 5431'sse2' 5432 Target supports compiling 'sse2' instructions. 5433 5434'sse2_runtime' 5435 Target supports the execution of 'sse2' instructions. 5436 5437'sync_char_short' 5438 Target supports atomic operations on 'char' and 'short'. 5439 5440'sync_int_long' 5441 Target supports atomic operations on 'int' and 'long'. 5442 5443'ultrasparc_hw' 5444 Test environment appears to run executables on a simulator that 5445 accepts only 'EM_SPARC' executables and chokes on 'EM_SPARC32PLUS' 5446 or 'EM_SPARCV9' executables. 5447 5448'vect_cmdline_needed' 5449 Target requires a command line argument to enable a SIMD 5450 instruction set. 5451 5452'xorsign' 5453 Target supports the xorsign optab expansion. 5454 54557.2.3.12 Environment attributes 5456............................... 5457 5458'c' 5459 The language for the compiler under test is C. 5460 5461'c++' 5462 The language for the compiler under test is C++. 5463 5464'c99_runtime' 5465 Target provides a full C99 runtime. 5466 5467'correct_iso_cpp_string_wchar_protos' 5468 Target 'string.h' and 'wchar.h' headers provide C++ required 5469 overloads for 'strchr' etc. functions. 5470 5471'd_runtime' 5472 Target provides the D runtime. 5473 5474'd_runtime_has_std_library' 5475 Target provides the D standard library (Phobos). 5476 5477'dummy_wcsftime' 5478 Target uses a dummy 'wcsftime' function that always returns zero. 5479 5480'fd_truncate' 5481 Target can truncate a file from a file descriptor, as used by 5482 'libgfortran/io/unix.c:fd_truncate'; i.e. 'ftruncate' or 'chsize'. 5483 5484'fenv' 5485 Target provides 'fenv.h' include file. 5486 5487'fenv_exceptions' 5488 Target supports 'fenv.h' with all the standard IEEE exceptions and 5489 floating-point exceptions are raised by arithmetic operations. 5490 5491'fileio' 5492 Target offers such file I/O library functions as 'fopen', 'fclose', 5493 'tmpnam', and 'remove'. This is a link-time requirement for the 5494 presence of the functions in the library; even if they fail at 5495 runtime, the requirement is still regarded as satisfied. 5496 5497'freestanding' 5498 Target is 'freestanding' as defined in section 4 of the C99 5499 standard. Effectively, it is a target which supports no extra 5500 headers or libraries other than what is considered essential. 5501 5502'gettimeofday' 5503 Target supports 'gettimeofday'. 5504 5505'init_priority' 5506 Target supports constructors with initialization priority 5507 arguments. 5508 5509'inttypes_types' 5510 Target has the basic signed and unsigned types in 'inttypes.h'. 5511 This is for tests that GCC's notions of these types agree with 5512 those in the header, as some systems have only 'inttypes.h'. 5513 5514'lax_strtofp' 5515 Target might have errors of a few ULP in string to floating-point 5516 conversion functions and overflow is not always detected correctly 5517 by those functions. 5518 5519'mempcpy' 5520 Target provides 'mempcpy' function. 5521 5522'mmap' 5523 Target supports 'mmap'. 5524 5525'newlib' 5526 Target supports Newlib. 5527 5528'newlib_nano_io' 5529 GCC was configured with '--enable-newlib-nano-formatted-io', which 5530 reduces the code size of Newlib formatted I/O functions. 5531 5532'pow10' 5533 Target provides 'pow10' function. 5534 5535'pthread' 5536 Target can compile using 'pthread.h' with no errors or warnings. 5537 5538'pthread_h' 5539 Target has 'pthread.h'. 5540 5541'run_expensive_tests' 5542 Expensive testcases (usually those that consume excessive amounts 5543 of CPU time) should be run on this target. This can be enabled by 5544 setting the 'GCC_TEST_RUN_EXPENSIVE' environment variable to a 5545 non-empty string. 5546 5547'simulator' 5548 Test system runs executables on a simulator (i.e. slowly) rather 5549 than hardware (i.e. fast). 5550 5551'signal' 5552 Target has 'signal.h'. 5553 5554'stabs' 5555 Target supports the stabs debugging format. 5556 5557'stdint_types' 5558 Target has the basic signed and unsigned C types in 'stdint.h'. 5559 This will be obsolete when GCC ensures a working 'stdint.h' for all 5560 targets. 5561 5562'stpcpy' 5563 Target provides 'stpcpy' function. 5564 5565'trampolines' 5566 Target supports trampolines. 5567 5568'uclibc' 5569 Target supports uClibc. 5570 5571'unwrapped' 5572 Target does not use a status wrapper. 5573 5574'vxworks_kernel' 5575 Target is a VxWorks kernel. 5576 5577'vxworks_rtp' 5578 Target is a VxWorks RTP. 5579 5580'wchar' 5581 Target supports wide characters. 5582 55837.2.3.13 Other attributes 5584......................... 5585 5586'automatic_stack_alignment' 5587 Target supports automatic stack alignment. 5588 5589'branch_cost' 5590 Target supports '-branch-cost=N'. 5591 5592'cxa_atexit' 5593 Target uses '__cxa_atexit'. 5594 5595'default_packed' 5596 Target has packed layout of structure members by default. 5597 5598'exceptions' 5599 Target supports exceptions. 5600 5601'exceptions_enabled' 5602 Target supports exceptions and they are enabled in the current 5603 testing configuration. 5604 5605'fgraphite' 5606 Target supports Graphite optimizations. 5607 5608'fixed_point' 5609 Target supports fixed-point extension to C. 5610 5611'fopenacc' 5612 Target supports OpenACC via '-fopenacc'. 5613 5614'fopenmp' 5615 Target supports OpenMP via '-fopenmp'. 5616 5617'fpic' 5618 Target supports '-fpic' and '-fPIC'. 5619 5620'freorder' 5621 Target supports '-freorder-blocks-and-partition'. 5622 5623'fstack_protector' 5624 Target supports '-fstack-protector'. 5625 5626'gas' 5627 Target uses GNU 'as'. 5628 5629'gc_sections' 5630 Target supports '--gc-sections'. 5631 5632'gld' 5633 Target uses GNU 'ld'. 5634 5635'keeps_null_pointer_checks' 5636 Target keeps null pointer checks, either due to the use of 5637 '-fno-delete-null-pointer-checks' or hardwired into the target. 5638 5639'llvm_binutils' 5640 Target is using an LLVM assembler and/or linker, instead of GNU 5641 Binutils. 5642 5643'lto' 5644 Compiler has been configured to support link-time optimization 5645 (LTO). 5646 5647'lto_incremental' 5648 Compiler and linker support link-time optimization relocatable 5649 linking with '-r' and '-flto' options. 5650 5651'naked_functions' 5652 Target supports the 'naked' function attribute. 5653 5654'named_sections' 5655 Target supports named sections. 5656 5657'natural_alignment_32' 5658 Target uses natural alignment (aligned to type size) for types of 5659 32 bits or less. 5660 5661'target_natural_alignment_64' 5662 Target uses natural alignment (aligned to type size) for types of 5663 64 bits or less. 5664 5665'noinit' 5666 Target supports the 'noinit' variable attribute. 5667 5668'nonpic' 5669 Target does not generate PIC by default. 5670 5671'offload_gcn' 5672 Target has been configured for OpenACC/OpenMP offloading on AMD 5673 GCN. 5674 5675'pie_enabled' 5676 Target generates PIE by default. 5677 5678'pcc_bitfield_type_matters' 5679 Target defines 'PCC_BITFIELD_TYPE_MATTERS'. 5680 5681'pe_aligned_commons' 5682 Target supports '-mpe-aligned-commons'. 5683 5684'pie' 5685 Target supports '-pie', '-fpie' and '-fPIE'. 5686 5687'rdynamic' 5688 Target supports '-rdynamic'. 5689 5690'scalar_all_fma' 5691 Target supports all four fused multiply-add optabs for both 'float' 5692 and 'double'. These optabs are: 'fma_optab', 'fms_optab', 5693 'fnma_optab' and 'fnms_optab'. 5694 5695'section_anchors' 5696 Target supports section anchors. 5697 5698'short_enums' 5699 Target defaults to short enums. 5700 5701'stack_size' 5702 Target has limited stack size. The stack size limit can be 5703 obtained using the STACK_SIZE macro defined by *note 5704 'dg-add-options' feature 'stack_size': stack_size_ao. 5705 5706'static' 5707 Target supports '-static'. 5708 5709'static_libgfortran' 5710 Target supports statically linking 'libgfortran'. 5711 5712'string_merging' 5713 Target supports merging string constants at link time. 5714 5715'ucn' 5716 Target supports compiling and assembling UCN. 5717 5718'ucn_nocache' 5719 Including the options used to compile this particular test, the 5720 target supports compiling and assembling UCN. 5721 5722'unaligned_stack' 5723 Target does not guarantee that its 'STACK_BOUNDARY' is greater than 5724 or equal to the required vector alignment. 5725 5726'vector_alignment_reachable' 5727 Vector alignment is reachable for types of 32 bits or less. 5728 5729'vector_alignment_reachable_for_64bit' 5730 Vector alignment is reachable for types of 64 bits or less. 5731 5732'wchar_t_char16_t_compatible' 5733 Target supports 'wchar_t' that is compatible with 'char16_t'. 5734 5735'wchar_t_char32_t_compatible' 5736 Target supports 'wchar_t' that is compatible with 'char32_t'. 5737 5738'comdat_group' 5739 Target uses comdat groups. 5740 5741'indirect_calls' 5742 Target supports indirect calls, i.e. calls where the target is not 5743 constant. 5744 57457.2.3.14 Local to tests in 'gcc.target/i386' 5746............................................ 5747 5748'3dnow' 5749 Target supports compiling '3dnow' instructions. 5750 5751'aes' 5752 Target supports compiling 'aes' instructions. 5753 5754'fma4' 5755 Target supports compiling 'fma4' instructions. 5756 5757'mfentry' 5758 Target supports the '-mfentry' option that alters the position of 5759 profiling calls such that they precede the prologue. 5760 5761'ms_hook_prologue' 5762 Target supports attribute 'ms_hook_prologue'. 5763 5764'pclmul' 5765 Target supports compiling 'pclmul' instructions. 5766 5767'sse3' 5768 Target supports compiling 'sse3' instructions. 5769 5770'sse4' 5771 Target supports compiling 'sse4' instructions. 5772 5773'sse4a' 5774 Target supports compiling 'sse4a' instructions. 5775 5776'ssse3' 5777 Target supports compiling 'ssse3' instructions. 5778 5779'vaes' 5780 Target supports compiling 'vaes' instructions. 5781 5782'vpclmul' 5783 Target supports compiling 'vpclmul' instructions. 5784 5785'xop' 5786 Target supports compiling 'xop' instructions. 5787 57887.2.3.15 Local to tests in 'gcc.test-framework' 5789............................................... 5790 5791'no' 5792 Always returns 0. 5793 5794'yes' 5795 Always returns 1. 5796 5797 5798File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5799 58007.2.4 Features for 'dg-add-options' 5801----------------------------------- 5802 5803The supported values of FEATURE for directive 'dg-add-options' are: 5804 5805'arm_fp' 5806 '__ARM_FP' definition. Only ARM targets support this feature, and 5807 only then in certain modes; see the *note arm_fp_ok effective 5808 target keyword: arm_fp_ok. 5809 5810'arm_fp_dp' 5811 '__ARM_FP' definition with double-precision support. Only ARM 5812 targets support this feature, and only then in certain modes; see 5813 the *note arm_fp_dp_ok effective target keyword: arm_fp_dp_ok. 5814 5815'arm_neon' 5816 NEON support. Only ARM targets support this feature, and only then 5817 in certain modes; see the *note arm_neon_ok effective target 5818 keyword: arm_neon_ok. 5819 5820'arm_fp16' 5821 VFP half-precision floating point support. This does not select 5822 the FP16 format; for that, use *note arm_fp16_ieee: arm_fp16_ieee. 5823 or *note arm_fp16_alternative: arm_fp16_alternative. instead. This 5824 feature is only supported by ARM targets and then only in certain 5825 modes; see the *note arm_fp16_ok effective target keyword: 5826 arm_fp16_ok. 5827 5828'arm_fp16_ieee' 5829 ARM IEEE 754-2008 format VFP half-precision floating point support. 5830 This feature is only supported by ARM targets and then only in 5831 certain modes; see the *note arm_fp16_ok effective target keyword: 5832 arm_fp16_ok. 5833 5834'arm_fp16_alternative' 5835 ARM Alternative format VFP half-precision floating point support. 5836 This feature is only supported by ARM targets and then only in 5837 certain modes; see the *note arm_fp16_ok effective target keyword: 5838 arm_fp16_ok. 5839 5840'arm_neon_fp16' 5841 NEON and half-precision floating point support. Only ARM targets 5842 support this feature, and only then in certain modes; see the *note 5843 arm_neon_fp16_ok effective target keyword: arm_neon_fp16_ok. 5844 5845'arm_vfp3' 5846 arm vfp3 floating point support; see the *note arm_vfp3_ok 5847 effective target keyword: arm_vfp3_ok. 5848 5849'arm_arch_v8a_hard' 5850 Add options for ARMv8-A and the hard-float variant of the AAPCS, if 5851 this is supported by the compiler; see the *note 5852 arm_arch_v8a_hard_ok: arm_arch_v8a_hard_ok. effective target 5853 keyword. 5854 5855'arm_v8_1a_neon' 5856 Add options for ARMv8.1-A with Adv.SIMD support, if this is 5857 supported by the target; see the *note arm_v8_1a_neon_ok: 5858 arm_v8_1a_neon_ok. effective target keyword. 5859 5860'arm_v8_2a_fp16_scalar' 5861 Add options for ARMv8.2-A with scalar FP16 support, if this is 5862 supported by the target; see the *note arm_v8_2a_fp16_scalar_ok: 5863 arm_v8_2a_fp16_scalar_ok. effective target keyword. 5864 5865'arm_v8_2a_fp16_neon' 5866 Add options for ARMv8.2-A with Adv.SIMD FP16 support, if this is 5867 supported by the target; see the *note arm_v8_2a_fp16_neon_ok: 5868 arm_v8_2a_fp16_neon_ok. effective target keyword. 5869 5870'arm_v8_2a_dotprod_neon' 5871 Add options for ARMv8.2-A with Adv.SIMD Dot Product support, if 5872 this is supported by the target; see the *note 5873 arm_v8_2a_dotprod_neon_ok:: effective target keyword. 5874 5875'arm_fp16fml_neon' 5876 Add options to enable generation of the 'VFMAL' and 'VFMSL' 5877 instructions, if this is supported by the target; see the *note 5878 arm_fp16fml_neon_ok:: effective target keyword. 5879 5880'bind_pic_locally' 5881 Add the target-specific flags needed to enable functions to bind 5882 locally when using pic/PIC passes in the testsuite. 5883 5884'floatN' 5885 Add the target-specific flags needed to use the '_FloatN' type. 5886 5887'floatNx' 5888 Add the target-specific flags needed to use the '_FloatNx' type. 5889 5890'ieee' 5891 Add the target-specific flags needed to enable full IEEE compliance 5892 mode. 5893 5894'mips16_attribute' 5895 'mips16' function attributes. Only MIPS targets support this 5896 feature, and only then in certain modes. 5897 5898'stack_size' 5899 Add the flags needed to define macro STACK_SIZE and set it to the 5900 stack size limit associated with the *note 'stack_size' effective 5901 target: stack_size_et. 5902 5903'sqrt_insn' 5904 Add the target-specific flags needed to enable hardware square root 5905 instructions, if any. 5906 5907'tls' 5908 Add the target-specific flags needed to use thread-local storage. 5909 5910 5911File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 5912 59137.2.5 Variants of 'dg-require-SUPPORT' 5914-------------------------------------- 5915 5916A few of the 'dg-require' directives take arguments. 5917 5918'dg-require-iconv CODESET' 5919 Skip the test if the target does not support iconv. CODESET is the 5920 codeset to convert to. 5921 5922'dg-require-profiling PROFOPT' 5923 Skip the test if the target does not support profiling with option 5924 PROFOPT. 5925 5926'dg-require-stack-check CHECK' 5927 Skip the test if the target does not support the '-fstack-check' 5928 option. If CHECK is '""', support for '-fstack-check' is checked, 5929 for '-fstack-check=("CHECK")' otherwise. 5930 5931'dg-require-stack-size SIZE' 5932 Skip the test if the target does not support a stack size of SIZE. 5933 5934'dg-require-visibility VIS' 5935 Skip the test if the target does not support the 'visibility' 5936 attribute. If VIS is '""', support for 'visibility("hidden")' is 5937 checked, for 'visibility("VIS")' otherwise. 5938 5939 The original 'dg-require' directives were defined before there was 5940support for effective-target keywords. The directives that do not take 5941arguments could be replaced with effective-target keywords. 5942 5943'dg-require-alias ""' 5944 Skip the test if the target does not support the 'alias' attribute. 5945 5946'dg-require-ascii-locale ""' 5947 Skip the test if the host does not support an ASCII locale. 5948 5949'dg-require-compat-dfp ""' 5950 Skip this test unless both compilers in a 'compat' testsuite 5951 support decimal floating point. 5952 5953'dg-require-cxa-atexit ""' 5954 Skip the test if the target does not support '__cxa_atexit'. This 5955 is equivalent to 'dg-require-effective-target cxa_atexit'. 5956 5957'dg-require-dll ""' 5958 Skip the test if the target does not support DLL attributes. 5959 5960'dg-require-dot ""' 5961 Skip the test if the host does not have 'dot'. 5962 5963'dg-require-fork ""' 5964 Skip the test if the target does not support 'fork'. 5965 5966'dg-require-gc-sections ""' 5967 Skip the test if the target's linker does not support the 5968 '--gc-sections' flags. This is equivalent to 5969 'dg-require-effective-target gc-sections'. 5970 5971'dg-require-host-local ""' 5972 Skip the test if the host is remote, rather than the same as the 5973 build system. Some tests are incompatible with DejaGnu's handling 5974 of remote hosts, which involves copying the source file to the host 5975 and compiling it with a relative path and "'-o a.out'". 5976 5977'dg-require-mkfifo ""' 5978 Skip the test if the target does not support 'mkfifo'. 5979 5980'dg-require-named-sections ""' 5981 Skip the test is the target does not support named sections. This 5982 is equivalent to 'dg-require-effective-target named_sections'. 5983 5984'dg-require-weak ""' 5985 Skip the test if the target does not support weak symbols. 5986 5987'dg-require-weak-override ""' 5988 Skip the test if the target does not support overriding weak 5989 symbols. 5990 5991 5992File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 5993 59947.2.6 Commands for use in 'dg-final' 5995------------------------------------ 5996 5997The GCC testsuite defines the following directives to be used within 5998'dg-final'. 5999 60007.2.6.1 Scan a particular file 6001.............................. 6002 6003'scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 6004 Passes if REGEXP matches text in FILENAME. 6005'scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 6006 Passes if REGEXP does not match text in FILENAME. 6007'scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 6008 Passes if REGEXP matches in Fortran module MODULE. 6009'dg-check-dot FILENAME' 6010 Passes if FILENAME is a valid '.dot' file (by running 'dot -Tpng' 6011 on it, and verifying the exit code is 0). 6012 60137.2.6.2 Scan the assembly output 6014................................ 6015 6016'scan-assembler REGEX [{ target/xfail SELECTOR }]' 6017 Passes if REGEX matches text in the test's assembler output. 6018 6019'scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 6020 Passes if REGEX does not match text in the test's assembler output. 6021 6022'scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 6023 Passes if REGEX is matched exactly NUM times in the test's 6024 assembler output. 6025 6026'scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 6027 Passes if REGEX matches text in the test's demangled assembler 6028 output. 6029 6030'scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 6031 Passes if REGEX does not match text in the test's demangled 6032 assembler output. 6033 6034'scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 6035 Passes if SYMBOL is defined as a hidden symbol in the test's 6036 assembly output. 6037 6038'scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 6039 Passes if SYMBOL is not defined as a hidden symbol in the test's 6040 assembly output. 6041 6042'check-function-bodies PREFIX TERMINATOR [OPTIONS [{ target/xfail SELECTOR }]]' 6043 Looks through the source file for comments that give the expected 6044 assembly output for selected functions. Each line of expected 6045 output starts with the prefix string PREFIX and the expected output 6046 for a function as a whole is followed by a line that starts with 6047 the string TERMINATOR. Specifying an empty terminator is 6048 equivalent to specifying '"*/"'. 6049 6050 OPTIONS, if specified, is a list of regular expressions, each of 6051 which matches a full command-line option. A non-empty list 6052 prevents the test from running unless all of the given options are 6053 present on the command line. This can help if a source file is 6054 compiled both with and without optimization, since it is rarely 6055 useful to check the full function body for unoptimized code. 6056 6057 The first line of the expected output for a function FN has the 6058 form: 6059 6060 PREFIX FN: [{ target/xfail SELECTOR }] 6061 6062 Subsequent lines of the expected output also start with PREFIX. In 6063 both cases, whitespace after PREFIX is not significant. 6064 6065 The test discards assembly directives such as '.cfi_startproc' and 6066 local label definitions such as '.LFB0' from the compiler's 6067 assembly output. It then matches the result against the expected 6068 output for a function as a single regular expression. This means 6069 that later lines can use backslashes to refer back to '(...)' 6070 captures on earlier lines. For example: 6071 6072 /* { dg-final { check-function-bodies "**" "" "-DCHECK_ASM" } } */ 6073 ... 6074 /* 6075 ** add_w0_s8_m: 6076 ** mov (z[0-9]+\.b), w0 6077 ** add z0\.b, p0/m, z0\.b, \1 6078 ** ret 6079 */ 6080 svint8_t add_w0_s8_m (...) { ... } 6081 ... 6082 /* 6083 ** add_b0_s8_m: 6084 ** mov (z[0-9]+\.b), b0 6085 ** add z1\.b, p0/m, z1\.b, \1 6086 ** ret 6087 */ 6088 svint8_t add_b0_s8_m (...) { ... } 6089 6090 checks whether the implementations of 'add_w0_s8_m' and 6091 'add_b0_s8_m' match the regular expressions given. The test only 6092 runs when '-DCHECK_ASM' is passed on the command line. 6093 6094 It is possible to create non-capturing multi-line regular 6095 expression groups of the form '(A|B|...)' by putting the '(', '|' 6096 and ')' on separate lines (each still using PREFIX). For example: 6097 6098 /* 6099 ** cmple_f16_tied: 6100 ** ( 6101 ** fcmge p0\.h, p0/z, z1\.h, z0\.h 6102 ** | 6103 ** fcmle p0\.h, p0/z, z0\.h, z1\.h 6104 ** ) 6105 ** ret 6106 */ 6107 svbool_t cmple_f16_tied (...) { ... } 6108 6109 checks whether 'cmple_f16_tied' is implemented by the 'fcmge' 6110 instruction followed by 'ret' or by the 'fcmle' instruction 6111 followed by 'ret'. The test is still a single regular rexpression. 6112 6113 A line containing just: 6114 6115 PREFIX ... 6116 6117 stands for zero or more unmatched lines; the whitespace after 6118 PREFIX is again not significant. 6119 61207.2.6.3 Scan optimization dump files 6121.................................... 6122 6123These commands are available for KIND of 'tree', 'ltrans-tree', 6124'offload-tree', 'rtl', 'offload-rtl', 'ipa', and 'wpa-ipa'. 6125 6126'scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 6127 Passes if REGEX matches text in the dump file with suffix SUFFIX. 6128 6129'scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 6130 Passes if REGEX does not match text in the dump file with suffix 6131 SUFFIX. 6132 6133'scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 6134 Passes if REGEX is found exactly NUM times in the dump file with 6135 suffix SUFFIX. 6136 6137'scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 6138 Passes if REGEX matches demangled text in the dump file with suffix 6139 SUFFIX. 6140 6141'scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 6142 Passes if REGEX does not match demangled text in the dump file with 6143 suffix SUFFIX. 6144 61457.2.6.4 Check for output files 6146.............................. 6147 6148'output-exists [{ target/xfail SELECTOR }]' 6149 Passes if compiler output file exists. 6150 6151'output-exists-not [{ target/xfail SELECTOR }]' 6152 Passes if compiler output file does not exist. 6153 6154'scan-symbol REGEXP [{ target/xfail SELECTOR }]' 6155 Passes if the pattern is present in the final executable. 6156 6157'scan-symbol-not REGEXP [{ target/xfail SELECTOR }]' 6158 Passes if the pattern is absent from the final executable. 6159 61607.2.6.5 Checks for 'gcov' tests 6161............................... 6162 6163'run-gcov SOURCEFILE' 6164 Check line counts in 'gcov' tests. 6165 6166'run-gcov [branches] [calls] { OPTS SOURCEFILE }' 6167 Check branch and/or call counts, in addition to line counts, in 6168 'gcov' tests. 6169 61707.2.6.6 Clean up generated test files 6171..................................... 6172 6173Usually the test-framework removes files that were generated during 6174testing. If a testcase, for example, uses any dumping mechanism to 6175inspect a passes dump file, the testsuite recognized the dump option 6176passed to the tool and schedules a final cleanup to remove these files. 6177 6178 There are, however, following additional cleanup directives that can be 6179used to annotate a testcase "manually". 6180'cleanup-coverage-files' 6181 Removes coverage data files generated for this test. 6182 6183'cleanup-modules "LIST-OF-EXTRA-MODULES"' 6184 Removes Fortran module files generated for this test, excluding the 6185 module names listed in keep-modules. Cleaning up module files is 6186 usually done automatically by the testsuite by looking at the 6187 source files and removing the modules after the test has been 6188 executed. 6189 module MoD1 6190 end module MoD1 6191 module Mod2 6192 end module Mod2 6193 module moD3 6194 end module moD3 6195 module mod4 6196 end module mod4 6197 ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant 6198 ! { dg-final { keep-modules "mod3 mod4" } } 6199 6200'keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"' 6201 Whitespace separated list of module names that should not be 6202 deleted by cleanup-modules. If the list of modules is empty, all 6203 modules defined in this file are kept. 6204 module maybe_unneeded 6205 end module maybe_unneeded 6206 module keep1 6207 end module keep1 6208 module keep2 6209 end module keep2 6210 ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two 6211 ! { dg-final { keep-modules "" } } ! keep all 6212 6213'dg-keep-saved-temps "LIST-OF-SUFFIXES-NOT-TO-DELETE"' 6214 Whitespace separated list of suffixes that should not be deleted 6215 automatically in a testcase that uses '-save-temps'. 6216 // { dg-options "-save-temps -fpch-preprocess -I." } 6217 int main() { return 0; } 6218 // { dg-keep-saved-temps ".s" } ! just keep assembler file 6219 // { dg-keep-saved-temps ".s" ".i" } ! ... and .i 6220 // { dg-keep-saved-temps ".ii" ".o" } ! or just .ii and .o 6221 6222'cleanup-profile-file' 6223 Removes profiling files generated for this test. 6224 6225 6226File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 6227 62287.3 Ada Language Testsuites 6229=========================== 6230 6231The Ada testsuite includes executable tests from the ACATS testsuite, 6232publicly available at <http://www.ada-auth.org/acats.html>. 6233 6234 These tests are integrated in the GCC testsuite in the 'ada/acats' 6235directory, and enabled automatically when running 'make check', assuming 6236the Ada language has been enabled when configuring GCC. 6237 6238 You can also run the Ada testsuite independently, using 'make 6239check-ada', or run a subset of the tests by specifying which chapter to 6240run, e.g.: 6241 6242 $ make check-ada CHAPTERS="c3 c9" 6243 6244 The tests are organized by directory, each directory corresponding to a 6245chapter of the Ada Reference Manual. So for example, 'c9' corresponds 6246to chapter 9, which deals with tasking features of the language. 6247 6248 The tests are run using two 'sh' scripts: 'run_acats' and 'run_all.sh'. 6249To run the tests using a simulator or a cross target, see the small 6250customization section at the top of 'run_all.sh'. 6251 6252 These tests are run using the build tree: they can be run without doing 6253a 'make install'. 6254 6255 6256File: gccint.info, Node: C Tests, Next: LTO Testing, Prev: Ada Tests, Up: Testsuites 6257 62587.4 C Language Testsuites 6259========================= 6260 6261GCC contains the following C language testsuites, in the 'gcc/testsuite' 6262directory: 6263 6264'gcc.dg' 6265 This contains tests of particular features of the C compiler, using 6266 the more modern 'dg' harness. Correctness tests for various 6267 compiler features should go here if possible. 6268 6269 Magic comments determine whether the file is preprocessed, 6270 compiled, linked or run. In these tests, error and warning message 6271 texts are compared against expected texts or regular expressions 6272 given in comments. These tests are run with the options '-ansi 6273 -pedantic' unless other options are given in the test. Except as 6274 noted below they are not run with multiple optimization options. 6275'gcc.dg/compat' 6276 This subdirectory contains tests for binary compatibility using 6277 'lib/compat.exp', which in turn uses the language-independent 6278 support (*note Support for testing binary compatibility: compat 6279 Testing.). 6280'gcc.dg/cpp' 6281 This subdirectory contains tests of the preprocessor. 6282'gcc.dg/debug' 6283 This subdirectory contains tests for debug formats. Tests in this 6284 subdirectory are run for each debug format that the compiler 6285 supports. 6286'gcc.dg/format' 6287 This subdirectory contains tests of the '-Wformat' format checking. 6288 Tests in this directory are run with and without '-DWIDE'. 6289'gcc.dg/noncompile' 6290 This subdirectory contains tests of code that should not compile 6291 and does not need any special compilation options. They are run 6292 with multiple optimization options, since sometimes invalid code 6293 crashes the compiler with optimization. 6294'gcc.dg/special' 6295 FIXME: describe this. 6296 6297'gcc.c-torture' 6298 This contains particular code fragments which have historically 6299 broken easily. These tests are run with multiple optimization 6300 options, so tests for features which only break at some 6301 optimization levels belong here. This also contains tests to check 6302 that certain optimizations occur. It might be worthwhile to 6303 separate the correctness tests cleanly from the code quality tests, 6304 but it hasn't been done yet. 6305 6306'gcc.c-torture/compat' 6307 FIXME: describe this. 6308 6309 This directory should probably not be used for new tests. 6310'gcc.c-torture/compile' 6311 This testsuite contains test cases that should compile, but do not 6312 need to link or run. These test cases are compiled with several 6313 different combinations of optimization options. All warnings are 6314 disabled for these test cases, so this directory is not suitable if 6315 you wish to test for the presence or absence of compiler warnings. 6316 While special options can be set, and tests disabled on specific 6317 platforms, by the use of '.x' files, mostly these test cases should 6318 not contain platform dependencies. FIXME: discuss how defines such 6319 as 'STACK_SIZE' are used. 6320'gcc.c-torture/execute' 6321 This testsuite contains test cases that should compile, link and 6322 run; otherwise the same comments as for 'gcc.c-torture/compile' 6323 apply. 6324'gcc.c-torture/execute/ieee' 6325 This contains tests which are specific to IEEE floating point. 6326'gcc.c-torture/unsorted' 6327 FIXME: describe this. 6328 6329 This directory should probably not be used for new tests. 6330'gcc.misc-tests' 6331 This directory contains C tests that require special handling. 6332 Some of these tests have individual expect files, and others share 6333 special-purpose expect files: 6334 6335 'bprob*.c' 6336 Test '-fbranch-probabilities' using 6337 'gcc.misc-tests/bprob.exp', which in turn uses the generic, 6338 language-independent framework (*note Support for testing 6339 profile-directed optimizations: profopt Testing.). 6340 6341 'gcov*.c' 6342 Test 'gcov' output using 'gcov.exp', which in turn uses the 6343 language-independent support (*note Support for testing gcov: 6344 gcov Testing.). 6345 6346 'i386-pf-*.c' 6347 Test i386-specific support for data prefetch using 6348 'i386-prefetch.exp'. 6349 6350'gcc.test-framework' 6351 'dg-*.c' 6352 Test the testsuite itself using 6353 'gcc.test-framework/test-framework.exp'. 6354 6355 FIXME: merge in 'testsuite/README.gcc' and discuss the format of test 6356cases and magic comments more. 6357 6358 6359File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: C Tests, Up: Testsuites 6360 63617.5 Support for testing link-time optimizations 6362=============================================== 6363 6364Tests for link-time optimizations usually require multiple source files 6365that are compiled separately, perhaps with different sets of options. 6366There are several special-purpose test directives used for these tests. 6367 6368'{ dg-lto-do DO-WHAT-KEYWORD }' 6369 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 6370 is executed. It is one of: 6371 6372 'assemble' 6373 Compile with '-c' to produce a relocatable object file. 6374 'link' 6375 Compile, assemble, and link to produce an executable file. 6376 'run' 6377 Produce and run an executable file, which is expected to 6378 return an exit code of 0. 6379 6380 The default is 'assemble'. That can be overridden for a set of 6381 tests by redefining 'dg-do-what-default' within the '.exp' file for 6382 those tests. 6383 6384 Unlike 'dg-do', 'dg-lto-do' does not support an optional 'target' 6385 or 'xfail' list. Use 'dg-skip-if', 'dg-xfail-if', or 6386 'dg-xfail-run-if'. 6387 6388'{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 6389 This directive provides a list of one or more sets of compiler 6390 options to override LTO_OPTIONS. Each test will be compiled and 6391 run with each of these sets of options. 6392 6393'{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}' 6394 This directive adds OPTIONS to the linker options used. 6395 6396'{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}' 6397 This directive removes OPTIONS from the set of linker options used. 6398 6399 6400File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 6401 64027.6 Support for testing 'gcov' 6403============================== 6404 6405Language-independent support for testing 'gcov', and for checking that 6406branch profiling produces expected values, is provided by the expect 6407file 'lib/gcov.exp'. 'gcov' tests also rely on procedures in 6408'lib/gcc-dg.exp' to compile and run the test program. A typical 'gcov' 6409test contains the following DejaGnu commands within comments: 6410 6411 { dg-options "--coverage" } 6412 { dg-do run { target native } } 6413 { dg-final { run-gcov sourcefile } } 6414 6415 Checks of 'gcov' output can include line counts, branch percentages, 6416and call return percentages. All of these checks are requested via 6417commands that appear in comments in the test's source file. Commands to 6418check line counts are processed by default. Commands to check branch 6419percentages and call return percentages are processed if the 'run-gcov' 6420command has arguments 'branches' or 'calls', respectively. For example, 6421the following specifies checking both, as well as passing '-b' to 6422'gcov': 6423 6424 { dg-final { run-gcov branches calls { -b sourcefile } } } 6425 6426 A line count command appears within a comment on the source line that 6427is expected to get the specified count and has the form 'count(CNT)'. A 6428test should only check line counts for lines that will get the same 6429count for any architecture. 6430 6431 Commands to check branch percentages ('branch') and call return 6432percentages ('returns') are very similar to each other. A beginning 6433command appears on or before the first of a range of lines that will 6434report the percentage, and the ending command follows that range of 6435lines. The beginning command can include a list of percentages, all of 6436which are expected to be found within the range. A range is terminated 6437by the next command of the same kind. A command 'branch(end)' or 6438'returns(end)' marks the end of a range without starting a new one. For 6439example: 6440 6441 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 6442 /* branch(end) */ 6443 foo (i, j); 6444 6445 For a call return percentage, the value specified is the percentage of 6446calls reported to return. For a branch percentage, the value is either 6447the expected percentage or 100 minus that value, since the direction of 6448a branch can differ depending on the target or the optimization level. 6449 6450 Not all branches and calls need to be checked. A test should not check 6451for branches that might be optimized away or replaced with predicated 6452instructions. Don't check for calls inserted by the compiler or ones 6453that might be inlined or optimized away. 6454 6455 A single test can check for combinations of line counts, branch 6456percentages, and call return percentages. The command to check a line 6457count must appear on the line that will report that count, but commands 6458to check branch percentages and call return percentages can bracket the 6459lines that report them. 6460 6461 6462File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 6463 64647.7 Support for testing profile-directed optimizations 6465====================================================== 6466 6467The file 'profopt.exp' provides language-independent support for 6468checking correct execution of a test built with profile-directed 6469optimization. This testing requires that a test program be built and 6470executed twice. The first time it is compiled to generate profile data, 6471and the second time it is compiled to use the data that was generated 6472during the first execution. The second execution is to verify that the 6473test produces the expected results. 6474 6475 To check that the optimization actually generated better code, a test 6476can be built and run a third time with normal optimizations to verify 6477that the performance is better with the profile-directed optimizations. 6478'profopt.exp' has the beginnings of this kind of support. 6479 6480 'profopt.exp' provides generic support for profile-directed 6481optimizations. Each set of tests that uses it provides information 6482about a specific optimization: 6483 6484'tool' 6485 tool being tested, e.g., 'gcc' 6486 6487'profile_option' 6488 options used to generate profile data 6489 6490'feedback_option' 6491 options used to optimize using that profile data 6492 6493'prof_ext' 6494 suffix of profile data files 6495 6496'PROFOPT_OPTIONS' 6497 list of options with which to run each test, similar to the lists 6498 for torture tests 6499 6500'{ dg-final-generate { LOCAL-DIRECTIVE } }' 6501 This directive is similar to 'dg-final', but the LOCAL-DIRECTIVE is 6502 run after the generation of profile data. 6503 6504'{ dg-final-use { LOCAL-DIRECTIVE } }' 6505 The LOCAL-DIRECTIVE is run after the profile data have been used. 6506 6507 6508File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 6509 65107.8 Support for testing binary compatibility 6511============================================ 6512 6513The file 'compat.exp' provides language-independent support for binary 6514compatibility testing. It supports testing interoperability of two 6515compilers that follow the same ABI, or of multiple sets of compiler 6516options that should not affect binary compatibility. It is intended to 6517be used for testsuites that complement ABI testsuites. 6518 6519 A test supported by this framework has three parts, each in a separate 6520source file: a main program and two pieces that interact with each other 6521to split up the functionality being tested. 6522 6523'TESTNAME_main.SUFFIX' 6524 Contains the main program, which calls a function in file 6525 'TESTNAME_x.SUFFIX'. 6526 6527'TESTNAME_x.SUFFIX' 6528 Contains at least one call to a function in 'TESTNAME_y.SUFFIX'. 6529 6530'TESTNAME_y.SUFFIX' 6531 Shares data with, or gets arguments from, 'TESTNAME_x.SUFFIX'. 6532 6533 Within each test, the main program and one functional piece are 6534compiled by the GCC under test. The other piece can be compiled by an 6535alternate compiler. If no alternate compiler is specified, then all 6536three source files are all compiled by the GCC under test. You can 6537specify pairs of sets of compiler options. The first element of such a 6538pair specifies options used with the GCC under test, and the second 6539element of the pair specifies options used with the alternate compiler. 6540Each test is compiled with each pair of options. 6541 6542 'compat.exp' defines default pairs of compiler options. These can be 6543overridden by defining the environment variable 'COMPAT_OPTIONS' as: 6544 6545 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 6546 ...[list {TSTN} {ALTN}]]" 6547 6548 where TSTI and ALTI are lists of options, with TSTI used by the 6549compiler under test and ALTI used by the alternate compiler. For 6550example, with '[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 6551the test is first built with '-g -O0' by the compiler under test and 6552with '-O3' by the alternate compiler. The test is built a second time 6553using '-fpic' by the compiler under test and '-fPIC -O2' by the 6554alternate compiler. 6555 6556 An alternate compiler is specified by defining an environment variable 6557to be the full pathname of an installed compiler; for C define 6558'ALT_CC_UNDER_TEST', and for C++ define 'ALT_CXX_UNDER_TEST'. These 6559will be written to the 'site.exp' file used by DejaGnu. The default is 6560to build each test with the compiler under test using the first of each 6561pair of compiler options from 'COMPAT_OPTIONS'. When 6562'ALT_CC_UNDER_TEST' or 'ALT_CXX_UNDER_TEST' is 'same', each test is 6563built using the compiler under test but with combinations of the options 6564from 'COMPAT_OPTIONS'. 6565 6566 To run only the C++ compatibility suite using the compiler under test 6567and another version of GCC using specific compiler options, do the 6568following from 'OBJDIR/gcc': 6569 6570 rm site.exp 6571 make -k \ 6572 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 6573 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 6574 check-c++ \ 6575 RUNTESTFLAGS="compat.exp" 6576 6577 A test that fails when the source files are compiled with different 6578compilers, but passes when the files are compiled with the same 6579compiler, demonstrates incompatibility of the generated code or runtime 6580support. A test that fails for the alternate compiler but passes for 6581the compiler under test probably tests for a bug that was fixed in the 6582compiler under test but is present in the alternate compiler. 6583 6584 The binary compatibility tests support a small number of test framework 6585commands that appear within comments in a test file. 6586 6587'dg-require-*' 6588 These commands can be used in 'TESTNAME_main.SUFFIX' to skip the 6589 test if specific support is not available on the target. 6590 6591'dg-options' 6592 The specified options are used for compiling this particular source 6593 file, appended to the options from 'COMPAT_OPTIONS'. When this 6594 command appears in 'TESTNAME_main.SUFFIX' the options are also used 6595 to link the test program. 6596 6597'dg-xfail-if' 6598 This command can be used in a secondary source file to specify that 6599 compilation is expected to fail for particular options on 6600 particular targets. 6601 6602 6603File: gccint.info, Node: Torture Tests, Next: GIMPLE Tests, Prev: compat Testing, Up: Testsuites 6604 66057.9 Support for torture testing using multiple options 6606====================================================== 6607 6608Throughout the compiler testsuite there are several directories whose 6609tests are run multiple times, each with a different set of options. 6610These are known as torture tests. 'lib/torture-options.exp' defines 6611procedures to set up these lists: 6612 6613'torture-init' 6614 Initialize use of torture lists. 6615'set-torture-options' 6616 Set lists of torture options to use for tests with and without 6617 loops. Optionally combine a set of torture options with a set of 6618 other options, as is done with Objective-C runtime options. 6619'torture-finish' 6620 Finalize use of torture lists. 6621 6622 The '.exp' file for a set of tests that use torture options must 6623include calls to these three procedures if: 6624 6625 * It calls 'gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 6626 6627 * It calls ${TOOL}'-torture' or ${TOOL}'-torture-execute', where TOOL 6628 is 'c', 'fortran', or 'objc'. 6629 6630 * It calls 'dg-pch'. 6631 6632 It is not necessary for a '.exp' file that calls 'gcc-dg-runtest' to 6633call the torture procedures if the tests should use the list in 6634DG_TORTURE_OPTIONS defined in 'gcc-dg.exp'. 6635 6636 Most uses of torture options can override the default lists by defining 6637TORTURE_OPTIONS or add to the default list by defining 6638ADDITIONAL_TORTURE_OPTIONS. Define these in a '.dejagnurc' file or add 6639them to the 'site.exp' file; for example 6640 6641 set ADDITIONAL_TORTURE_OPTIONS [list \ 6642 { -O2 -ftree-loop-linear } \ 6643 { -O2 -fpeel-loops } ] 6644 6645 6646File: gccint.info, Node: GIMPLE Tests, Next: RTL Tests, Prev: Torture Tests, Up: Testsuites 6647 66487.10 Support for testing GIMPLE passes 6649====================================== 6650 6651As of gcc 7, C functions can be tagged with '__GIMPLE' to indicate that 6652the function body will be GIMPLE, rather than C. The compiler requires 6653the option '-fgimple' to enable this functionality. For example: 6654 6655 /* { dg-do compile } */ 6656 /* { dg-options "-O -fgimple" } */ 6657 6658 void __GIMPLE (startwith ("dse2")) foo () 6659 { 6660 int a; 6661 6662 bb_2: 6663 if (a > 4) 6664 goto bb_3; 6665 else 6666 goto bb_4; 6667 6668 bb_3: 6669 a_2 = 10; 6670 goto bb_5; 6671 6672 bb_4: 6673 a_3 = 20; 6674 6675 bb_5: 6676 a_1 = __PHI (bb_3: a_2, bb_4: a_3); 6677 a_4 = a_1 + 4; 6678 6679 return; 6680 } 6681 6682 The 'startwith' argument indicates at which pass to begin. 6683 6684 Use the dump modifier '-gimple' (e.g. '-fdump-tree-all-gimple') to make 6685tree dumps more closely follow the format accepted by the GIMPLE parser. 6686 6687 Example DejaGnu tests of GIMPLE can be seen in the source tree at 6688'gcc/testsuite/gcc.dg/gimplefe-*.c'. 6689 6690 The '__GIMPLE' parser is integrated with the C tokenizer and 6691preprocessor, so it should be possible to use macros to build out test 6692coverage. 6693 6694 6695File: gccint.info, Node: RTL Tests, Prev: GIMPLE Tests, Up: Testsuites 6696 66977.11 Support for testing RTL passes 6698=================================== 6699 6700As of gcc 7, C functions can be tagged with '__RTL' to indicate that the 6701function body will be RTL, rather than C. For example: 6702 6703 double __RTL (startwith ("ira")) test (struct foo *f, const struct bar *b) 6704 { 6705 (function "test" 6706 [...snip; various directives go in here...] 6707 ) ;; function "test" 6708 } 6709 6710 The 'startwith' argument indicates at which pass to begin. 6711 6712 The parser expects the RTL body to be in the format emitted by this 6713dumping function: 6714 6715 DEBUG_FUNCTION void 6716 print_rtx_function (FILE *outfile, function *fn, bool compact); 6717 6718 when "compact" is true. So you can capture RTL in the correct format 6719from the debugger using: 6720 6721 (gdb) print_rtx_function (stderr, cfun, true); 6722 6723 and copy and paste the output into the body of the C function. 6724 6725 Example DejaGnu tests of RTL can be seen in the source tree under 6726'gcc/testsuite/gcc.dg/rtl'. 6727 6728 The '__RTL' parser is not integrated with the C tokenizer or 6729preprocessor, and works simply by reading the relevant lines within the 6730braces. In particular, the RTL body must be on separate lines from the 6731enclosing braces, and the preprocessor is not usable within it. 6732 6733 6734File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 6735 67368 Option specification files 6737**************************** 6738 6739Most GCC command-line options are described by special option definition 6740files, the names of which conventionally end in '.opt'. This chapter 6741describes the format of these files. 6742 6743* Menu: 6744 6745* Option file format:: The general layout of the files 6746* Option properties:: Supported option properties 6747 6748 6749File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 6750 67518.1 Option file format 6752====================== 6753 6754Option files are a simple list of records in which each field occupies 6755its own line and in which the records themselves are separated by blank 6756lines. Comments may appear on their own line anywhere within the file 6757and are preceded by semicolons. Whitespace is allowed before the 6758semicolon. 6759 6760 The files can contain the following types of record: 6761 6762 * A language definition record. These records have two fields: the 6763 string 'Language' and the name of the language. Once a language 6764 has been declared in this way, it can be used as an option 6765 property. *Note Option properties::. 6766 6767 * A target specific save record to save additional information. 6768 These records have two fields: the string 'TargetSave', and a 6769 declaration type to go in the 'cl_target_option' structure. 6770 6771 * A variable record to define a variable used to store option 6772 information. These records have two fields: the string 'Variable', 6773 and a declaration of the type and name of the variable, optionally 6774 with an initializer (but without any trailing ';'). These records 6775 may be used for variables used for many options where declaring the 6776 initializer in a single option definition record, or duplicating it 6777 in many records, would be inappropriate, or for variables set in 6778 option handlers rather than referenced by 'Var' properties. 6779 6780 * A variable record to define a variable used to store option 6781 information. These records have two fields: the string 6782 'TargetVariable', and a declaration of the type and name of the 6783 variable, optionally with an initializer (but without any trailing 6784 ';'). 'TargetVariable' is a combination of 'Variable' and 6785 'TargetSave' records in that the variable is defined in the 6786 'gcc_options' structure, but these variables are also stored in the 6787 'cl_target_option' structure. The variables are saved in the 6788 target save code and restored in the target restore code. 6789 6790 * A variable record to record any additional files that the 6791 'options.h' file should include. This is useful to provide 6792 enumeration or structure definitions needed for target variables. 6793 These records have two fields: the string 'HeaderInclude' and the 6794 name of the include file. 6795 6796 * A variable record to record any additional files that the 6797 'options.c' or 'options-save.c' file should include. This is 6798 useful to provide inline functions needed for target variables 6799 and/or '#ifdef' sequences to properly set up the initialization. 6800 These records have two fields: the string 'SourceInclude' and the 6801 name of the include file. 6802 6803 * An enumeration record to define a set of strings that may be used 6804 as arguments to an option or options. These records have three 6805 fields: the string 'Enum', a space-separated list of properties and 6806 help text used to describe the set of strings in '--help' output. 6807 Properties use the same format as option properties; the following 6808 are valid: 6809 'Name(NAME)' 6810 This property is required; NAME must be a name (suitable for 6811 use in C identifiers) used to identify the set of strings in 6812 'Enum' option properties. 6813 6814 'Type(TYPE)' 6815 This property is required; TYPE is the C type for variables 6816 set by options using this enumeration together with 'Var'. 6817 6818 'UnknownError(MESSAGE)' 6819 The message MESSAGE will be used as an error message if the 6820 argument is invalid; for enumerations without 'UnknownError', 6821 a generic error message is used. MESSAGE should contain a 6822 single '%qs' format, which will be used to format the invalid 6823 argument. 6824 6825 * An enumeration value record to define one of the strings in a set 6826 given in an 'Enum' record. These records have two fields: the 6827 string 'EnumValue' and a space-separated list of properties. 6828 Properties use the same format as option properties; the following 6829 are valid: 6830 'Enum(NAME)' 6831 This property is required; NAME says which 'Enum' record this 6832 'EnumValue' record corresponds to. 6833 6834 'String(STRING)' 6835 This property is required; STRING is the string option 6836 argument being described by this record. 6837 6838 'Value(VALUE)' 6839 This property is required; it says what value (representable 6840 as 'int') should be used for the given string. 6841 6842 'Canonical' 6843 This property is optional. If present, it says the present 6844 string is the canonical one among all those with the given 6845 value. Other strings yielding that value will be mapped to 6846 this one so specs do not need to handle them. 6847 6848 'DriverOnly' 6849 This property is optional. If present, the present string 6850 will only be accepted by the driver. This is used for cases 6851 such as '-march=native' that are processed by the driver so 6852 that 'gcc -v' shows how the options chosen depended on the 6853 system on which the compiler was run. 6854 6855 * An option definition record. These records have the following 6856 fields: 6857 1. the name of the option, with the leading "-" removed 6858 2. a space-separated list of option properties (*note Option 6859 properties::) 6860 3. the help text to use for '--help' (omitted if the second field 6861 contains the 'Undocumented' property). 6862 6863 By default, all options beginning with "f", "W" or "m" are 6864 implicitly assumed to take a "no-" form. This form should not be 6865 listed separately. If an option beginning with one of these 6866 letters does not have a "no-" form, you can use the 6867 'RejectNegative' property to reject it. 6868 6869 The help text is automatically line-wrapped before being displayed. 6870 Normally the name of the option is printed on the left-hand side of 6871 the output and the help text is printed on the right. However, if 6872 the help text contains a tab character, the text to the left of the 6873 tab is used instead of the option's name and the text to the right 6874 of the tab forms the help text. This allows you to elaborate on 6875 what type of argument the option takes. 6876 6877 * A target mask record. These records have one field of the form 6878 'Mask(X)'. The options-processing script will automatically 6879 allocate a bit in 'target_flags' (*note Run-time Target::) for each 6880 mask name X and set the macro 'MASK_X' to the appropriate bitmask. 6881 It will also declare a 'TARGET_X' macro that has the value 1 when 6882 bit 'MASK_X' is set and 0 otherwise. 6883 6884 They are primarily intended to declare target masks that are not 6885 associated with user options, either because these masks represent 6886 internal switches or because the options are not available on all 6887 configurations and yet the masks always need to be defined. 6888 6889 6890File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 6891 68928.2 Option properties 6893===================== 6894 6895The second field of an option record can specify any of the following 6896properties. When an option takes an argument, it is enclosed in 6897parentheses following the option property name. The parser that handles 6898option files is quite simplistic, and will be tricked by any nested 6899parentheses within the argument text itself; in this case, the entire 6900option argument can be wrapped in curly braces within the parentheses to 6901demarcate it, e.g.: 6902 6903 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 6904 6905'Common' 6906 The option is available for all languages and targets. 6907 6908'Target' 6909 The option is available for all languages but is target-specific. 6910 6911'Driver' 6912 The option is handled by the compiler driver using code not shared 6913 with the compilers proper ('cc1' etc.). 6914 6915'LANGUAGE' 6916 The option is available when compiling for the given language. 6917 6918 It is possible to specify several different languages for the same 6919 option. Each LANGUAGE must have been declared by an earlier 6920 'Language' record. *Note Option file format::. 6921 6922'RejectDriver' 6923 The option is only handled by the compilers proper ('cc1' etc.) and 6924 should not be accepted by the driver. 6925 6926'RejectNegative' 6927 The option does not have a "no-" form. All options beginning with 6928 "f", "W" or "m" are assumed to have a "no-" form unless this 6929 property is used. 6930 6931'Negative(OTHERNAME)' 6932 The option will turn off another option OTHERNAME, which is the 6933 option name with the leading "-" removed. This chain action will 6934 propagate through the 'Negative' property of the option to be 6935 turned off. The driver will prune options, removing those that are 6936 turned off by some later option. This pruning is not done for 6937 options with 'Joined' or 'JoinedOrMissing' properties, unless the 6938 options have either 'RejectNegative' property or the 'Negative' 6939 property mentions an option other than itself. 6940 6941 As a consequence, if you have a group of mutually-exclusive 6942 options, their 'Negative' properties should form a circular chain. 6943 For example, if options '-A', '-B' and '-C' are mutually exclusive, 6944 their respective 'Negative' properties should be 'Negative(B)', 6945 'Negative(C)' and 'Negative(A)'. 6946 6947'Joined' 6948'Separate' 6949 The option takes a mandatory argument. 'Joined' indicates that the 6950 option and argument can be included in the same 'argv' entry (as 6951 with '-mflush-func=NAME', for example). 'Separate' indicates that 6952 the option and argument can be separate 'argv' entries (as with 6953 '-o'). An option is allowed to have both of these properties. 6954 6955'JoinedOrMissing' 6956 The option takes an optional argument. If the argument is given, 6957 it will be part of the same 'argv' entry as the option itself. 6958 6959 This property cannot be used alongside 'Joined' or 'Separate'. 6960 6961'MissingArgError(MESSAGE)' 6962 For an option marked 'Joined' or 'Separate', the message MESSAGE 6963 will be used as an error message if the mandatory argument is 6964 missing; for options without 'MissingArgError', a generic error 6965 message is used. MESSAGE should contain a single '%qs' format, 6966 which will be used to format the name of the option passed. 6967 6968'Args(N)' 6969 For an option marked 'Separate', indicate that it takes N 6970 arguments. The default is 1. 6971 6972'UInteger' 6973 The option's argument is a non-negative integer consisting of 6974 either decimal or hexadecimal digits interpreted as 'int'. 6975 Hexadecimal integers may optionally start with the '0x' or '0X' 6976 prefix. The option parser validates and converts the argument 6977 before passing it to the relevant option handler. 'UInteger' 6978 should also be used with options like '-falign-loops' where both 6979 '-falign-loops' and '-falign-loops'=N are supported to make sure 6980 the saved options are given a full integer. Positive values of the 6981 argument in excess of 'INT_MAX' wrap around zero. 6982 6983'Host_Wide_Int' 6984 The option's argument is a non-negative integer consisting of 6985 either decimal or hexadecimal digits interpreted as the widest 6986 integer type on the host. As with an 'UInteger' argument, 6987 hexadecimal integers may optionally start with the '0x' or '0X' 6988 prefix. The option parser validates and converts the argument 6989 before passing it to the relevant option handler. 'Host_Wide_Int' 6990 should be used with options that need to accept very large values. 6991 Positive values of the argument in excess of 'HOST_WIDE_INT_M1U' 6992 are assigned 'HOST_WIDE_INT_M1U'. 6993 6994'IntegerRange(N, M)' 6995 The options's arguments are integers of type 'int'. The option's 6996 parser validates that the value of an option integer argument is 6997 within the closed range [N, M]. 6998 6999'ByteSize' 7000 A property applicable only to 'UInteger' or 'Host_Wide_Int' 7001 arguments. The option's integer argument is interpreted as if in 7002 infinite precision using saturation arithmetic in the corresponding 7003 type. The argument may be followed by a 'byte-size' suffix 7004 designating a multiple of bytes such as 'kB' and 'KiB' for kilobyte 7005 and kibibyte, respectively, 'MB' and 'MiB' for megabyte and 7006 mebibyte, 'GB' and 'GiB' for gigabyte and gigibyte, and so on. 7007 'ByteSize' should be used for with options that take a very large 7008 argument representing a size in bytes, such as '-Wlarger-than='. 7009 7010'ToLower' 7011 The option's argument should be converted to lowercase as part of 7012 putting it in canonical form, and before comparing with the strings 7013 indicated by any 'Enum' property. 7014 7015'NoDriverArg' 7016 For an option marked 'Separate', the option only takes an argument 7017 in the compiler proper, not in the driver. This is for 7018 compatibility with existing options that are used both directly and 7019 via '-Wp,'; new options should not have this property. 7020 7021'Var(VAR)' 7022 The state of this option should be stored in variable VAR (actually 7023 a macro for 'global_options.x_VAR'). The way that the state is 7024 stored depends on the type of option: 7025 7026'WarnRemoved' 7027 The option is removed and every usage of such option will result in 7028 a warning. We use it option backward compatibility. 7029 7030'Var(VAR, SET)' 7031 The option controls an integer variable VAR and is active when VAR 7032 equals SET. The option parser will set VAR to SET when the 7033 positive form of the option is used and '!SET' when the "no-" form 7034 is used. 7035 7036 VAR is declared in the same way as for the single-argument form 7037 described above. 7038 7039 * If the option uses the 'Mask' or 'InverseMask' properties, VAR 7040 is the integer variable that contains the mask. 7041 7042 * If the option is a normal on/off switch, VAR is an integer 7043 variable that is nonzero when the option is enabled. The 7044 options parser will set the variable to 1 when the positive 7045 form of the option is used and 0 when the "no-" form is used. 7046 7047 * If the option takes an argument and has the 'UInteger' 7048 property, VAR is an integer variable that stores the value of 7049 the argument. 7050 7051 * If the option takes an argument and has the 'Enum' property, 7052 VAR is a variable (type given in the 'Type' property of the 7053 'Enum' record whose 'Name' property has the same argument as 7054 the 'Enum' property of this option) that stores the value of 7055 the argument. 7056 7057 * If the option has the 'Defer' property, VAR is a pointer to a 7058 'VEC(cl_deferred_option,heap)' that stores the option for 7059 later processing. (VAR is declared with type 'void *' and 7060 needs to be cast to 'VEC(cl_deferred_option,heap)' before 7061 use.) 7062 7063 * Otherwise, if the option takes an argument, VAR is a pointer 7064 to the argument string. The pointer will be null if the 7065 argument is optional and wasn't given. 7066 7067 The option-processing script will usually zero-initialize VAR. You 7068 can modify this behavior using 'Init'. 7069 7070'Init(VALUE)' 7071 The variable specified by the 'Var' property should be statically 7072 initialized to VALUE. If more than one option using the same 7073 variable specifies 'Init', all must specify the same initializer. 7074 7075'Mask(NAME)' 7076 The option is associated with a bit in the 'target_flags' variable 7077 (*note Run-time Target::) and is active when that bit is set. You 7078 may also specify 'Var' to select a variable other than 7079 'target_flags'. 7080 7081 The options-processing script will automatically allocate a unique 7082 bit for the option. If the option is attached to 'target_flags', 7083 the script will set the macro 'MASK_NAME' to the appropriate 7084 bitmask. It will also declare a 'TARGET_NAME' macro that has the 7085 value 1 when the option is active and 0 otherwise. If you use 7086 'Var' to attach the option to a different variable, the bitmask 7087 macro with be called 'OPTION_MASK_NAME'. 7088 7089'InverseMask(OTHERNAME)' 7090'InverseMask(OTHERNAME, THISNAME)' 7091 The option is the inverse of another option that has the 7092 'Mask(OTHERNAME)' property. If THISNAME is given, the 7093 options-processing script will declare a 'TARGET_THISNAME' macro 7094 that is 1 when the option is active and 0 otherwise. 7095 7096'Enum(NAME)' 7097 The option's argument is a string from the set of strings 7098 associated with the corresponding 'Enum' record. The string is 7099 checked and converted to the integer specified in the corresponding 7100 'EnumValue' record before being passed to option handlers. 7101 7102'Defer' 7103 The option should be stored in a vector, specified with 'Var', for 7104 later processing. 7105 7106'Alias(OPT)' 7107'Alias(OPT, ARG)' 7108'Alias(OPT, POSARG, NEGARG)' 7109 The option is an alias for '-OPT' (or the negative form of that 7110 option, depending on 'NegativeAlias'). In the first form, any 7111 argument passed to the alias is considered to be passed to '-OPT', 7112 and '-OPT' is considered to be negated if the alias is used in 7113 negated form. In the second form, the alias may not be negated or 7114 have an argument, and POSARG is considered to be passed as an 7115 argument to '-OPT'. In the third form, the alias may not have an 7116 argument, if the alias is used in the positive form then POSARG is 7117 considered to be passed to '-OPT', and if the alias is used in the 7118 negative form then NEGARG is considered to be passed to '-OPT'. 7119 7120 Aliases should not specify 'Var' or 'Mask' or 'UInteger'. Aliases 7121 should normally specify the same languages as the target of the 7122 alias; the flags on the target will be used to determine any 7123 diagnostic for use of an option for the wrong language, while those 7124 on the alias will be used to identify what command-line text is the 7125 option and what text is any argument to that option. 7126 7127 When an 'Alias' definition is used for an option, driver specs do 7128 not need to handle it and no 'OPT_' enumeration value is defined 7129 for it; only the canonical form of the option will be seen in those 7130 places. 7131 7132'NegativeAlias' 7133 For an option marked with 'Alias(OPT)', the option is considered to 7134 be an alias for the positive form of '-OPT' if negated and for the 7135 negative form of '-OPT' if not negated. 'NegativeAlias' may not be 7136 used with the forms of 'Alias' taking more than one argument. 7137 7138'Ignore' 7139 This option is ignored apart from printing any warning specified 7140 using 'Warn'. The option will not be seen by specs and no 'OPT_' 7141 enumeration value is defined for it. 7142 7143'SeparateAlias' 7144 For an option marked with 'Joined', 'Separate' and 'Alias', the 7145 option only acts as an alias when passed a separate argument; with 7146 a joined argument it acts as a normal option, with an 'OPT_' 7147 enumeration value. This is for compatibility with the Java '-d' 7148 option and should not be used for new options. 7149 7150'Warn(MESSAGE)' 7151 If this option is used, output the warning MESSAGE. MESSAGE is a 7152 format string, either taking a single operand with a '%qs' format 7153 which is the option name, or not taking any operands, which is 7154 passed to the 'warning' function. If an alias is marked 'Warn', 7155 the target of the alias must not also be marked 'Warn'. 7156 7157'Report' 7158 The state of the option should be printed by '-fverbose-asm'. 7159 7160'Warning' 7161 This is a warning option and should be shown as such in '--help' 7162 output. This flag does not currently affect anything other than 7163 '--help'. 7164 7165'Optimization' 7166 This is an optimization option. It should be shown as such in 7167 '--help' output, and any associated variable named using 'Var' 7168 should be saved and restored when the optimization level is changed 7169 with 'optimize' attributes. 7170 7171'PerFunction' 7172 This is an option that can be overridden on a per-function basis. 7173 'Optimization' implies 'PerFunction', but options that do not 7174 affect executable code generation may use this flag instead, so 7175 that the option is not taken into account in ways that might affect 7176 executable code generation. 7177 7178'Param' 7179 This is an option that is a parameter. 7180 7181'Undocumented' 7182 The option is deliberately missing documentation and should not be 7183 included in the '--help' output. 7184 7185'Condition(COND)' 7186 The option should only be accepted if preprocessor condition COND 7187 is true. Note that any C declarations associated with the option 7188 will be present even if COND is false; COND simply controls whether 7189 the option is accepted and whether it is printed in the '--help' 7190 output. 7191 7192'Save' 7193 Build the 'cl_target_option' structure to hold a copy of the 7194 option, add the functions 'cl_target_option_save' and 7195 'cl_target_option_restore' to save and restore the options. 7196 7197'SetByCombined' 7198 The option may also be set by a combined option such as 7199 '-ffast-math'. This causes the 'gcc_options' struct to have a 7200 field 'frontend_set_NAME', where 'NAME' is the name of the field 7201 holding the value of this option (without the leading 'x_'). This 7202 gives the front end a way to indicate that the value has been set 7203 explicitly and should not be changed by the combined option. For 7204 example, some front ends use this to prevent '-ffast-math' and 7205 '-fno-fast-math' from changing the value of '-fmath-errno' for 7206 languages that do not use 'errno'. 7207 7208'EnabledBy(OPT)' 7209'EnabledBy(OPT || OPT2)' 7210'EnabledBy(OPT && OPT2)' 7211 If not explicitly set, the option is set to the value of '-OPT'; 7212 multiple options can be given, separated by '||'. The third form 7213 using '&&' specifies that the option is only set if both OPT and 7214 OPT2 are set. The options OPT and OPT2 must have the 'Common' 7215 property; otherwise, use 'LangEnabledBy'. 7216 7217'LangEnabledBy(LANGUAGE, OPT)' 7218'LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)' 7219 When compiling for the given language, the option is set to the 7220 value of '-OPT', if not explicitly set. OPT can be also a list of 7221 '||' separated options. In the second form, if OPT is used in the 7222 positive form then POSARG is considered to be passed to the option, 7223 and if OPT is used in the negative form then NEGARG is considered 7224 to be passed to the option. It is possible to specify several 7225 different languages. Each LANGUAGE must have been declared by an 7226 earlier 'Language' record. *Note Option file format::. 7227 7228'NoDWARFRecord' 7229 The option is omitted from the producer string written by 7230 '-grecord-gcc-switches'. 7231 7232'PchIgnore' 7233 Even if this is a target option, this option will not be recorded / 7234 compared to determine if a precompiled header file matches. 7235 7236'CPP(VAR)' 7237 The state of this option should be kept in sync with the 7238 preprocessor option VAR. If this property is set, then properties 7239 'Var' and 'Init' must be set as well. 7240 7241'CppReason(CPP_W_ENUM)' 7242 This warning option corresponds to 'cpplib.h' warning reason code 7243 CPP_W_ENUM. This should only be used for warning options of the 7244 C-family front-ends. 7245 7246 7247File: gccint.info, Node: Passes, Next: poly_int, Prev: Options, Up: Top 7248 72499 Passes and Files of the Compiler 7250********************************** 7251 7252This chapter is dedicated to giving an overview of the optimization and 7253code generation passes of the compiler. In the process, it describes 7254some of the language front end interface, though this description is no 7255where near complete. 7256 7257* Menu: 7258 7259* Parsing pass:: The language front end turns text into bits. 7260* Gimplification pass:: The bits are turned into something we can optimize. 7261* Pass manager:: Sequencing the optimization passes. 7262* IPA passes:: Inter-procedural optimizations. 7263* Tree SSA passes:: Optimizations on a high-level representation. 7264* RTL passes:: Optimizations on a low-level representation. 7265* Optimization info:: Dumping optimization information from passes. 7266 7267 7268File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes 7269 72709.1 Parsing pass 7271================ 7272 7273The language front end is invoked only once, via 7274'lang_hooks.parse_file', to parse the entire input. The language front 7275end may use any intermediate language representation deemed appropriate. 7276The C front end uses GENERIC trees (*note GENERIC::), plus a double 7277handful of language specific tree codes defined in 'c-common.def'. The 7278Fortran front end uses a completely different private representation. 7279 7280 At some point the front end must translate the representation used in 7281the front end to a representation understood by the language-independent 7282portions of the compiler. Current practice takes one of two forms. The 7283C front end manually invokes the gimplifier (*note GIMPLE::) on each 7284function, and uses the gimplifier callbacks to convert the 7285language-specific tree nodes directly to GIMPLE before passing the 7286function off to be compiled. The Fortran front end converts from a 7287private representation to GENERIC, which is later lowered to GIMPLE when 7288the function is compiled. Which route to choose probably depends on how 7289well GENERIC (plus extensions) can be made to match up with the source 7290language and necessary parsing data structures. 7291 7292 BUG: Gimplification must occur before nested function lowering, and 7293nested function lowering must be done by the front end before passing 7294the data off to cgraph. 7295 7296 TODO: Cgraph should control nested function lowering. It would only be 7297invoked when it is certain that the outer-most function is used. 7298 7299 TODO: Cgraph needs a gimplify_function callback. It should be invoked 7300when (1) it is certain that the function is used, (2) warning flags 7301specified by the user require some amount of compilation in order to 7302honor, (3) the language indicates that semantic analysis is not complete 7303until gimplification occurs. Hum... this sounds overly complicated. 7304Perhaps we should just have the front end gimplify always; in most cases 7305it's only one function call. 7306 7307 The front end needs to pass all function definitions and top level 7308declarations off to the middle-end so that they can be compiled and 7309emitted to the object file. For a simple procedural language, it is 7310usually most convenient to do this as each top level declaration or 7311definition is seen. There is also a distinction to be made between 7312generating functional code and generating complete debug information. 7313The only thing that is absolutely required for functional code is that 7314function and data _definitions_ be passed to the middle-end. For 7315complete debug information, function, data and type declarations should 7316all be passed as well. 7317 7318 In any case, the front end needs each complete top-level function or 7319data declaration, and each data definition should be passed to 7320'rest_of_decl_compilation'. Each complete type definition should be 7321passed to 'rest_of_type_compilation'. Each function definition should 7322be passed to 'cgraph_finalize_function'. 7323 7324 TODO: I know rest_of_compilation currently has all sorts of RTL 7325generation semantics. I plan to move all code generation bits (both 7326Tree and RTL) to compile_function. Should we hide cgraph from the front 7327ends and move back to rest_of_compilation as the official interface? 7328Possibly we should rename all three interfaces such that the names match 7329in some meaningful way and that is more descriptive than "rest_of". 7330 7331 The middle-end will, at its option, emit the function and data 7332definitions immediately or queue them for later processing. 7333 7334 7335File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes 7336 73379.2 Gimplification pass 7338======================= 7339 7340"Gimplification" is a whimsical term for the process of converting the 7341intermediate representation of a function into the GIMPLE language 7342(*note GIMPLE::). The term stuck, and so words like "gimplification", 7343"gimplify", "gimplifier" and the like are sprinkled throughout this 7344section of code. 7345 7346 While a front end may certainly choose to generate GIMPLE directly if 7347it chooses, this can be a moderately complex process unless the 7348intermediate language used by the front end is already fairly simple. 7349Usually it is easier to generate GENERIC trees plus extensions and let 7350the language-independent gimplifier do most of the work. 7351 7352 The main entry point to this pass is 'gimplify_function_tree' located 7353in 'gimplify.c'. From here we process the entire function gimplifying 7354each statement in turn. The main workhorse for this pass is 7355'gimplify_expr'. Approximately everything passes through here at least 7356once, and it is from here that we invoke the 'lang_hooks.gimplify_expr' 7357callback. 7358 7359 The callback should examine the expression in question and return 7360'GS_UNHANDLED' if the expression is not a language specific construct 7361that requires attention. Otherwise it should alter the expression in 7362some way to such that forward progress is made toward producing valid 7363GIMPLE. If the callback is certain that the transformation is complete 7364and the expression is valid GIMPLE, it should return 'GS_ALL_DONE'. 7365Otherwise it should return 'GS_OK', which will cause the expression to 7366be processed again. If the callback encounters an error during the 7367transformation (because the front end is relying on the gimplification 7368process to finish semantic checks), it should return 'GS_ERROR'. 7369 7370 7371File: gccint.info, Node: Pass manager, Next: IPA passes, Prev: Gimplification pass, Up: Passes 7372 73739.3 Pass manager 7374================ 7375 7376The pass manager is located in 'passes.c', 'tree-optimize.c' and 7377'tree-pass.h'. It processes passes as described in 'passes.def'. Its 7378job is to run all of the individual passes in the correct order, and 7379take care of standard bookkeeping that applies to every pass. 7380 7381 The theory of operation is that each pass defines a structure that 7382represents everything we need to know about that pass--when it should be 7383run, how it should be run, what intermediate language form or 7384on-the-side data structures it needs. We register the pass to be run in 7385some particular order, and the pass manager arranges for everything to 7386happen in the correct order. 7387 7388 The actuality doesn't completely live up to the theory at present. 7389Command-line switches and 'timevar_id_t' enumerations must still be 7390defined elsewhere. The pass manager validates constraints but does not 7391attempt to (re-)generate data structures or lower intermediate language 7392form based on the requirements of the next pass. Nevertheless, what is 7393present is useful, and a far sight better than nothing at all. 7394 7395 Each pass should have a unique name. Each pass may have its own dump 7396file (for GCC debugging purposes). Passes with a name starting with a 7397star do not dump anything. Sometimes passes are supposed to share a 7398dump file / option name. To still give these unique names, you can use 7399a prefix that is delimited by a space from the part that is used for the 7400dump file / option name. E.g. When the pass name is "ud dce", the name 7401used for dump file/options is "dce". 7402 7403 TODO: describe the global variables set up by the pass manager, and a 7404brief description of how a new pass should use it. I need to look at 7405what info RTL passes use first... 7406 7407 7408File: gccint.info, Node: IPA passes, Next: Tree SSA passes, Prev: Pass manager, Up: Passes 7409 74109.4 Inter-procedural optimization passes 7411======================================== 7412 7413The inter-procedural optimization (IPA) passes use call graph 7414information to perform transformations across function boundaries. IPA 7415is a critical part of link-time optimization (LTO) and whole-program 7416(WHOPR) optimization, and these passes are structured with the needs of 7417LTO and WHOPR in mind by dividing their operations into stages. For 7418detailed discussion of the LTO/WHOPR IPA pass stages and interfaces, see 7419*note IPA::. 7420 7421 The following briefly describes the inter-procedural optimization (IPA) 7422passes, which are split into small IPA passes, regular IPA passes, and 7423late IPA passes, according to the LTO/WHOPR processing model. 7424 7425* Menu: 7426 7427* Small IPA passes:: 7428* Regular IPA passes:: 7429* Late IPA passes:: 7430 7431 7432File: gccint.info, Node: Small IPA passes, Next: Regular IPA passes, Up: IPA passes 7433 74349.4.1 Small IPA passes 7435---------------------- 7436 7437A small IPA pass is a pass derived from 'simple_ipa_opt_pass'. As 7438described in *note IPA::, it does everything at once and defines only 7439the _Execute_ stage. During this stage it accesses and modifies the 7440function bodies. No 'generate_summary', 'read_summary', or 7441'write_summary' hooks are defined. 7442 7443 * IPA free lang data 7444 7445 This pass frees resources that are used by the front end but are 7446 not needed once it is done. It is located in 'tree.c' and is 7447 described by 'pass_ipa_free_lang_data'. 7448 7449 * IPA function and variable visibility 7450 7451 This is a local function pass handling visibilities of all symbols. 7452 This happens before LTO streaming, so '-fwhole-program' should be 7453 ignored at this level. It is located in 'ipa-visibility.c' and is 7454 described by 'pass_ipa_function_and_variable_visibility'. 7455 7456 * IPA remove symbols 7457 7458 This pass performs reachability analysis and reclaims all 7459 unreachable nodes. It is located in 'passes.c' and is described by 7460 'pass_ipa_remove_symbols'. 7461 7462 * IPA OpenACC 7463 7464 This is a pass group for OpenACC processing. It is located in 7465 'tree-ssa-loop.c' and is described by 'pass_ipa_oacc'. 7466 7467 * IPA points-to analysis 7468 7469 This is a tree-based points-to analysis pass. The idea behind this 7470 analyzer is to generate set constraints from the program, then 7471 solve the resulting constraints in order to generate the points-to 7472 sets. It is located in 'tree-ssa-structalias.c' and is described 7473 by 'pass_ipa_pta'. 7474 7475 * IPA OpenACC kernels 7476 7477 This is a pass group for processing OpenACC kernels regions. It is 7478 a subpass of the IPA OpenACC pass group that runs on offloaded 7479 functions containing OpenACC kernels loops. It is located in 7480 'tree-ssa-loop.c' and is described by 'pass_ipa_oacc_kernels'. 7481 7482 * Target clone 7483 7484 This is a pass for parsing functions with multiple target 7485 attributes. It is located in 'multiple_target.c' and is described 7486 by 'pass_target_clone'. 7487 7488 * IPA auto profile 7489 7490 This pass uses AutoFDO profiling data to annotate the control flow 7491 graph. It is located in 'auto-profile.c' and is described by 7492 'pass_ipa_auto_profile'. 7493 7494 * IPA tree profile 7495 7496 This pass does profiling for all functions in the call graph. It 7497 calculates branch probabilities and basic block execution counts. 7498 It is located in 'tree-profile.c' and is described by 7499 'pass_ipa_tree_profile'. 7500 7501 * IPA free function summary 7502 7503 This pass is a small IPA pass when argument 'small_p' is true. It 7504 releases inline function summaries and call summaries. It is 7505 located in 'ipa-fnsummary.c' and is described by 7506 'pass_ipa_free_free_fn_summary'. 7507 7508 * IPA increase alignment 7509 7510 This pass increases the alignment of global arrays to improve 7511 vectorization. It is located in 'tree-vectorizer.c' and is 7512 described by 'pass_ipa_increase_alignment'. 7513 7514 * IPA transactional memory 7515 7516 This pass is for transactional memory support. It is located in 7517 'trans-mem.c' and is described by 'pass_ipa_tm'. 7518 7519 * IPA lower emulated TLS 7520 7521 This pass lowers thread-local storage (TLS) operations to emulation 7522 functions provided by libgcc. It is located in 'tree-emutls.c' and 7523 is described by 'pass_ipa_lower_emutls'. 7524 7525 7526File: gccint.info, Node: Regular IPA passes, Next: Late IPA passes, Prev: Small IPA passes, Up: IPA passes 7527 75289.4.2 Regular IPA passes 7529------------------------ 7530 7531A regular IPA pass is a pass derived from 'ipa_opt_pass_d' that is 7532executed in WHOPR compilation. Regular IPA passes may have summary 7533hooks implemented in any of the LGEN, WPA or LTRANS stages (*note 7534IPA::). 7535 7536 * IPA whole program visibility 7537 7538 This pass performs various optimizations involving symbol 7539 visibility with '-fwhole-program', including symbol privatization, 7540 discovering local functions, and dismantling comdat groups. It is 7541 located in 'ipa-visibility.c' and is described by 7542 'pass_ipa_whole_program_visibility'. 7543 7544 * IPA profile 7545 7546 The IPA profile pass propagates profiling frequencies across the 7547 call graph. It is located in 'ipa-profile.c' and is described by 7548 'pass_ipa_profile'. 7549 7550 * IPA identical code folding 7551 7552 This is the inter-procedural identical code folding pass. The goal 7553 of this transformation is to discover functions and read-only 7554 variables that have exactly the same semantics. It is located in 7555 'ipa-icf.c' and is described by 'pass_ipa_icf'. 7556 7557 * IPA devirtualization 7558 7559 This pass performs speculative devirtualization based on the type 7560 inheritance graph. When a polymorphic call has only one likely 7561 target in the unit, it is turned into a speculative call. It is 7562 located in 'ipa-devirt.c' and is described by 'pass_ipa_devirt'. 7563 7564 * IPA constant propagation 7565 7566 The goal of this pass is to discover functions that are always 7567 invoked with some arguments with the same known constant values and 7568 to modify the functions accordingly. It can also do partial 7569 specialization and type-based devirtualization. It is located in 7570 'ipa-cp.c' and is described by 'pass_ipa_cp'. 7571 7572 * IPA scalar replacement of aggregates 7573 7574 This pass can replace an aggregate parameter with a set of other 7575 parameters representing part of the original, turning those passed 7576 by reference into new ones which pass the value directly. It also 7577 removes unused function return values and unused function 7578 parameters. This pass is located in 'ipa-sra.c' and is described 7579 by 'pass_ipa_sra'. 7580 7581 * IPA constructor/destructor merge 7582 7583 This pass merges multiple constructors and destructors for static 7584 objects into single functions. It's only run at LTO time unless 7585 the target doesn't support constructors and destructors natively. 7586 The pass is located in 'ipa.c' and is described by 7587 'pass_ipa_cdtor_merge'. 7588 7589 * IPA HSA 7590 7591 This pass is part of the GCC support for HSA (Heterogeneous System 7592 Architecture) accelerators. It is responsible for creation of HSA 7593 clones and emitting HSAIL instructions for them. It is located in 7594 'ipa-hsa.c' and is described by 'pass_ipa_hsa'. 7595 7596 * IPA function summary 7597 7598 This pass provides function analysis for inter-procedural passes. 7599 It collects estimates of function body size, execution time, and 7600 frame size for each function. It also estimates information about 7601 function calls: call statement size, time and how often the 7602 parameters change for each call. It is located in 7603 'ipa-fnsummary.c' and is described by 'pass_ipa_fn_summary'. 7604 7605 * IPA inline 7606 7607 The IPA inline pass handles function inlining with whole-program 7608 knowledge. Small functions that are candidates for inlining are 7609 ordered in increasing badness, bounded by unit growth parameters. 7610 Unreachable functions are removed from the call graph. Functions 7611 called once and not exported from the unit are inlined. This pass 7612 is located in 'ipa-inline.c' and is described by 'pass_ipa_inline'. 7613 7614 * IPA pure/const analysis 7615 7616 This pass marks functions as being either const ('TREE_READONLY') 7617 or pure ('DECL_PURE_P'). The per-function information is produced 7618 by 'pure_const_generate_summary', then the global information is 7619 computed by performing a transitive closure over the call graph. 7620 It is located in 'ipa-pure-const.c' and is described by 7621 'pass_ipa_pure_const'. 7622 7623 * IPA free function summary 7624 7625 This pass is a regular IPA pass when argument 'small_p' is false. 7626 It releases inline function summaries and call summaries. It is 7627 located in 'ipa-fnsummary.c' and is described by 7628 'pass_ipa_free_fn_summary'. 7629 7630 * IPA reference 7631 7632 This pass gathers information about how variables whose scope is 7633 confined to the compilation unit are used. It is located in 7634 'ipa-reference.c' and is described by 'pass_ipa_reference'. 7635 7636 * IPA single use 7637 7638 This pass checks whether variables are used by a single function. 7639 It is located in 'ipa.c' and is described by 'pass_ipa_single_use'. 7640 7641 * IPA comdats 7642 7643 This pass looks for static symbols that are used exclusively within 7644 one comdat group, and moves them into that comdat group. It is 7645 located in 'ipa-comdats.c' and is described by 'pass_ipa_comdats'. 7646 7647 7648File: gccint.info, Node: Late IPA passes, Prev: Regular IPA passes, Up: IPA passes 7649 76509.4.3 Late IPA passes 7651--------------------- 7652 7653Late IPA passes are simple IPA passes executed after the regular passes. 7654In WHOPR mode the passes are executed after partitioning and thus see 7655just parts of the compiled unit. 7656 7657 * Materialize all clones 7658 7659 Once all functions from compilation unit are in memory, produce all 7660 clones and update all calls. It is located in 'ipa.c' and is 7661 described by 'pass_materialize_all_clones'. 7662 7663 * IPA points-to analysis 7664 7665 Points-to analysis; this is the same as the points-to-analysis pass 7666 run with the small IPA passes (*note Small IPA passes::). 7667 7668 * OpenMP simd clone 7669 7670 This is the OpenMP constructs' SIMD clone pass. It creates the 7671 appropriate SIMD clones for functions tagged as elemental SIMD 7672 functions. It is located in 'omp-simd-clone.c' and is described by 7673 'pass_omp_simd_clone'. 7674 7675 7676File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: IPA passes, Up: Passes 7677 76789.5 Tree SSA passes 7679=================== 7680 7681The following briefly describes the Tree optimization passes that are 7682run after gimplification and what source files they are located in. 7683 7684 * Remove useless statements 7685 7686 This pass is an extremely simple sweep across the gimple code in 7687 which we identify obviously dead code and remove it. Here we do 7688 things like simplify 'if' statements with constant conditions, 7689 remove exception handling constructs surrounding code that 7690 obviously cannot throw, remove lexical bindings that contain no 7691 variables, and other assorted simplistic cleanups. The idea is to 7692 get rid of the obvious stuff quickly rather than wait until later 7693 when it's more work to get rid of it. This pass is located in 7694 'tree-cfg.c' and described by 'pass_remove_useless_stmts'. 7695 7696 * OpenMP lowering 7697 7698 If OpenMP generation ('-fopenmp') is enabled, this pass lowers 7699 OpenMP constructs into GIMPLE. 7700 7701 Lowering of OpenMP constructs involves creating replacement 7702 expressions for local variables that have been mapped using data 7703 sharing clauses, exposing the control flow of most synchronization 7704 directives and adding region markers to facilitate the creation of 7705 the control flow graph. The pass is located in 'omp-low.c' and is 7706 described by 'pass_lower_omp'. 7707 7708 * OpenMP expansion 7709 7710 If OpenMP generation ('-fopenmp') is enabled, this pass expands 7711 parallel regions into their own functions to be invoked by the 7712 thread library. The pass is located in 'omp-low.c' and is 7713 described by 'pass_expand_omp'. 7714 7715 * Lower control flow 7716 7717 This pass flattens 'if' statements ('COND_EXPR') and moves lexical 7718 bindings ('BIND_EXPR') out of line. After this pass, all 'if' 7719 statements will have exactly two 'goto' statements in its 'then' 7720 and 'else' arms. Lexical binding information for each statement 7721 will be found in 'TREE_BLOCK' rather than being inferred from its 7722 position under a 'BIND_EXPR'. This pass is found in 'gimple-low.c' 7723 and is described by 'pass_lower_cf'. 7724 7725 * Lower exception handling control flow 7726 7727 This pass decomposes high-level exception handling constructs 7728 ('TRY_FINALLY_EXPR' and 'TRY_CATCH_EXPR') into a form that 7729 explicitly represents the control flow involved. After this pass, 7730 'lookup_stmt_eh_region' will return a non-negative number for any 7731 statement that may have EH control flow semantics; examine 7732 'tree_can_throw_internal' or 'tree_can_throw_external' for exact 7733 semantics. Exact control flow may be extracted from 7734 'foreach_reachable_handler'. The EH region nesting tree is defined 7735 in 'except.h' and built in 'except.c'. The lowering pass itself is 7736 in 'tree-eh.c' and is described by 'pass_lower_eh'. 7737 7738 * Build the control flow graph 7739 7740 This pass decomposes a function into basic blocks and creates all 7741 of the edges that connect them. It is located in 'tree-cfg.c' and 7742 is described by 'pass_build_cfg'. 7743 7744 * Find all referenced variables 7745 7746 This pass walks the entire function and collects an array of all 7747 variables referenced in the function, 'referenced_vars'. The index 7748 at which a variable is found in the array is used as a UID for the 7749 variable within this function. This data is needed by the SSA 7750 rewriting routines. The pass is located in 'tree-dfa.c' and is 7751 described by 'pass_referenced_vars'. 7752 7753 * Enter static single assignment form 7754 7755 This pass rewrites the function such that it is in SSA form. After 7756 this pass, all 'is_gimple_reg' variables will be referenced by 7757 'SSA_NAME', and all occurrences of other variables will be 7758 annotated with 'VDEFS' and 'VUSES'; PHI nodes will have been 7759 inserted as necessary for each basic block. This pass is located 7760 in 'tree-ssa.c' and is described by 'pass_build_ssa'. 7761 7762 * Warn for uninitialized variables 7763 7764 This pass scans the function for uses of 'SSA_NAME's that are fed 7765 by default definition. For non-parameter variables, such uses are 7766 uninitialized. The pass is run twice, before and after 7767 optimization (if turned on). In the first pass we only warn for 7768 uses that are positively uninitialized; in the second pass we warn 7769 for uses that are possibly uninitialized. The pass is located in 7770 'tree-ssa.c' and is defined by 'pass_early_warn_uninitialized' and 7771 'pass_late_warn_uninitialized'. 7772 7773 * Dead code elimination 7774 7775 This pass scans the function for statements without side effects 7776 whose result is unused. It does not do memory life analysis, so 7777 any value that is stored in memory is considered used. The pass is 7778 run multiple times throughout the optimization process. It is 7779 located in 'tree-ssa-dce.c' and is described by 'pass_dce'. 7780 7781 * Dominator optimizations 7782 7783 This pass performs trivial dominator-based copy and constant 7784 propagation, expression simplification, and jump threading. It is 7785 run multiple times throughout the optimization process. It is 7786 located in 'tree-ssa-dom.c' and is described by 'pass_dominator'. 7787 7788 * Forward propagation of single-use variables 7789 7790 This pass attempts to remove redundant computation by substituting 7791 variables that are used once into the expression that uses them and 7792 seeing if the result can be simplified. It is located in 7793 'tree-ssa-forwprop.c' and is described by 'pass_forwprop'. 7794 7795 * Copy Renaming 7796 7797 This pass attempts to change the name of compiler temporaries 7798 involved in copy operations such that SSA->normal can coalesce the 7799 copy away. When compiler temporaries are copies of user variables, 7800 it also renames the compiler temporary to the user variable 7801 resulting in better use of user symbols. It is located in 7802 'tree-ssa-copyrename.c' and is described by 'pass_copyrename'. 7803 7804 * PHI node optimizations 7805 7806 This pass recognizes forms of PHI inputs that can be represented as 7807 conditional expressions and rewrites them into straight line code. 7808 It is located in 'tree-ssa-phiopt.c' and is described by 7809 'pass_phiopt'. 7810 7811 * May-alias optimization 7812 7813 This pass performs a flow sensitive SSA-based points-to analysis. 7814 The resulting may-alias, must-alias, and escape analysis 7815 information is used to promote variables from in-memory addressable 7816 objects to non-aliased variables that can be renamed into SSA form. 7817 We also update the 'VDEF'/'VUSE' memory tags for non-renameable 7818 aggregates so that we get fewer false kills. The pass is located 7819 in 'tree-ssa-alias.c' and is described by 'pass_may_alias'. 7820 7821 Interprocedural points-to information is located in 7822 'tree-ssa-structalias.c' and described by 'pass_ipa_pta'. 7823 7824 * Profiling 7825 7826 This pass instruments the function in order to collect runtime 7827 block and value profiling data. Such data may be fed back into the 7828 compiler on a subsequent run so as to allow optimization based on 7829 expected execution frequencies. The pass is located in 7830 'tree-profile.c' and is described by 'pass_ipa_tree_profile'. 7831 7832 * Static profile estimation 7833 7834 This pass implements series of heuristics to guess propababilities 7835 of branches. The resulting predictions are turned into edge 7836 profile by propagating branches across the control flow graphs. 7837 The pass is located in 'tree-profile.c' and is described by 7838 'pass_profile'. 7839 7840 * Lower complex arithmetic 7841 7842 This pass rewrites complex arithmetic operations into their 7843 component scalar arithmetic operations. The pass is located in 7844 'tree-complex.c' and is described by 'pass_lower_complex'. 7845 7846 * Scalar replacement of aggregates 7847 7848 This pass rewrites suitable non-aliased local aggregate variables 7849 into a set of scalar variables. The resulting scalar variables are 7850 rewritten into SSA form, which allows subsequent optimization 7851 passes to do a significantly better job with them. The pass is 7852 located in 'tree-sra.c' and is described by 'pass_sra'. 7853 7854 * Dead store elimination 7855 7856 This pass eliminates stores to memory that are subsequently 7857 overwritten by another store, without any intervening loads. The 7858 pass is located in 'tree-ssa-dse.c' and is described by 'pass_dse'. 7859 7860 * Tail recursion elimination 7861 7862 This pass transforms tail recursion into a loop. It is located in 7863 'tree-tailcall.c' and is described by 'pass_tail_recursion'. 7864 7865 * Forward store motion 7866 7867 This pass sinks stores and assignments down the flowgraph closer to 7868 their use point. The pass is located in 'tree-ssa-sink.c' and is 7869 described by 'pass_sink_code'. 7870 7871 * Partial redundancy elimination 7872 7873 This pass eliminates partially redundant computations, as well as 7874 performing load motion. The pass is located in 'tree-ssa-pre.c' 7875 and is described by 'pass_pre'. 7876 7877 Just before partial redundancy elimination, if 7878 '-funsafe-math-optimizations' is on, GCC tries to convert divisions 7879 to multiplications by the reciprocal. The pass is located in 7880 'tree-ssa-math-opts.c' and is described by 'pass_cse_reciprocal'. 7881 7882 * Full redundancy elimination 7883 7884 This is a simpler form of PRE that only eliminates redundancies 7885 that occur on all paths. It is located in 'tree-ssa-pre.c' and 7886 described by 'pass_fre'. 7887 7888 * Loop optimization 7889 7890 The main driver of the pass is placed in 'tree-ssa-loop.c' and 7891 described by 'pass_loop'. 7892 7893 The optimizations performed by this pass are: 7894 7895 Loop invariant motion. This pass moves only invariants that would 7896 be hard to handle on RTL level (function calls, operations that 7897 expand to nontrivial sequences of insns). With '-funswitch-loops' 7898 it also moves operands of conditions that are invariant out of the 7899 loop, so that we can use just trivial invariantness analysis in 7900 loop unswitching. The pass also includes store motion. The pass 7901 is implemented in 'tree-ssa-loop-im.c'. 7902 7903 Canonical induction variable creation. This pass creates a simple 7904 counter for number of iterations of the loop and replaces the exit 7905 condition of the loop using it, in case when a complicated analysis 7906 is necessary to determine the number of iterations. Later 7907 optimizations then may determine the number easily. The pass is 7908 implemented in 'tree-ssa-loop-ivcanon.c'. 7909 7910 Induction variable optimizations. This pass performs standard 7911 induction variable optimizations, including strength reduction, 7912 induction variable merging and induction variable elimination. The 7913 pass is implemented in 'tree-ssa-loop-ivopts.c'. 7914 7915 Loop unswitching. This pass moves the conditional jumps that are 7916 invariant out of the loops. To achieve this, a duplicate of the 7917 loop is created for each possible outcome of conditional jump(s). 7918 The pass is implemented in 'tree-ssa-loop-unswitch.c'. 7919 7920 Loop splitting. If a loop contains a conditional statement that is 7921 always true for one part of the iteration space and false for the 7922 other this pass splits the loop into two, one dealing with one side 7923 the other only with the other, thereby removing one inner-loop 7924 conditional. The pass is implemented in 'tree-ssa-loop-split.c'. 7925 7926 The optimizations also use various utility functions contained in 7927 'tree-ssa-loop-manip.c', 'cfgloop.c', 'cfgloopanal.c' and 7928 'cfgloopmanip.c'. 7929 7930 Vectorization. This pass transforms loops to operate on vector 7931 types instead of scalar types. Data parallelism across loop 7932 iterations is exploited to group data elements from consecutive 7933 iterations into a vector and operate on them in parallel. 7934 Depending on available target support the loop is conceptually 7935 unrolled by a factor 'VF' (vectorization factor), which is the 7936 number of elements operated upon in parallel in each iteration, and 7937 the 'VF' copies of each scalar operation are fused to form a vector 7938 operation. Additional loop transformations such as peeling and 7939 versioning may take place to align the number of iterations, and to 7940 align the memory accesses in the loop. The pass is implemented in 7941 'tree-vectorizer.c' (the main driver), 'tree-vect-loop.c' and 7942 'tree-vect-loop-manip.c' (loop specific parts and general loop 7943 utilities), 'tree-vect-slp' (loop-aware SLP functionality), 7944 'tree-vect-stmts.c' and 'tree-vect-data-refs.c'. Analysis of data 7945 references is in 'tree-data-ref.c'. 7946 7947 SLP Vectorization. This pass performs vectorization of 7948 straight-line code. The pass is implemented in 'tree-vectorizer.c' 7949 (the main driver), 'tree-vect-slp.c', 'tree-vect-stmts.c' and 7950 'tree-vect-data-refs.c'. 7951 7952 Autoparallelization. This pass splits the loop iteration space to 7953 run into several threads. The pass is implemented in 7954 'tree-parloops.c'. 7955 7956 Graphite is a loop transformation framework based on the polyhedral 7957 model. Graphite stands for Gimple Represented as Polyhedra. The 7958 internals of this infrastructure are documented in 7959 <http://gcc.gnu.org/wiki/Graphite>. The passes working on this 7960 representation are implemented in the various 'graphite-*' files. 7961 7962 * Tree level if-conversion for vectorizer 7963 7964 This pass applies if-conversion to simple loops to help vectorizer. 7965 We identify if convertible loops, if-convert statements and merge 7966 basic blocks in one big block. The idea is to present loop in such 7967 form so that vectorizer can have one to one mapping between 7968 statements and available vector operations. This pass is located 7969 in 'tree-if-conv.c' and is described by 'pass_if_conversion'. 7970 7971 * Conditional constant propagation 7972 7973 This pass relaxes a lattice of values in order to identify those 7974 that must be constant even in the presence of conditional branches. 7975 The pass is located in 'tree-ssa-ccp.c' and is described by 7976 'pass_ccp'. 7977 7978 A related pass that works on memory loads and stores, and not just 7979 register values, is located in 'tree-ssa-ccp.c' and described by 7980 'pass_store_ccp'. 7981 7982 * Conditional copy propagation 7983 7984 This is similar to constant propagation but the lattice of values 7985 is the "copy-of" relation. It eliminates redundant copies from the 7986 code. The pass is located in 'tree-ssa-copy.c' and described by 7987 'pass_copy_prop'. 7988 7989 A related pass that works on memory copies, and not just register 7990 copies, is located in 'tree-ssa-copy.c' and described by 7991 'pass_store_copy_prop'. 7992 7993 * Value range propagation 7994 7995 This transformation is similar to constant propagation but instead 7996 of propagating single constant values, it propagates known value 7997 ranges. The implementation is based on Patterson's range 7998 propagation algorithm (Accurate Static Branch Prediction by Value 7999 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 8000 Patterson's algorithm, this implementation does not propagate 8001 branch probabilities nor it uses more than a single range per SSA 8002 name. This means that the current implementation cannot be used 8003 for branch prediction (though adapting it would not be difficult). 8004 The pass is located in 'tree-vrp.c' and is described by 'pass_vrp'. 8005 8006 * Folding built-in functions 8007 8008 This pass simplifies built-in functions, as applicable, with 8009 constant arguments or with inferable string lengths. It is located 8010 in 'tree-ssa-ccp.c' and is described by 'pass_fold_builtins'. 8011 8012 * Split critical edges 8013 8014 This pass identifies critical edges and inserts empty basic blocks 8015 such that the edge is no longer critical. The pass is located in 8016 'tree-cfg.c' and is described by 'pass_split_crit_edges'. 8017 8018 * Control dependence dead code elimination 8019 8020 This pass is a stronger form of dead code elimination that can 8021 eliminate unnecessary control flow statements. It is located in 8022 'tree-ssa-dce.c' and is described by 'pass_cd_dce'. 8023 8024 * Tail call elimination 8025 8026 This pass identifies function calls that may be rewritten into 8027 jumps. No code transformation is actually applied here, but the 8028 data and control flow problem is solved. The code transformation 8029 requires target support, and so is delayed until RTL. In the 8030 meantime 'CALL_EXPR_TAILCALL' is set indicating the possibility. 8031 The pass is located in 'tree-tailcall.c' and is described by 8032 'pass_tail_calls'. The RTL transformation is handled by 8033 'fixup_tail_calls' in 'calls.c'. 8034 8035 * Warn for function return without value 8036 8037 For non-void functions, this pass locates return statements that do 8038 not specify a value and issues a warning. Such a statement may 8039 have been injected by falling off the end of the function. This 8040 pass is run last so that we have as much time as possible to prove 8041 that the statement is not reachable. It is located in 'tree-cfg.c' 8042 and is described by 'pass_warn_function_return'. 8043 8044 * Leave static single assignment form 8045 8046 This pass rewrites the function such that it is in normal form. At 8047 the same time, we eliminate as many single-use temporaries as 8048 possible, so the intermediate language is no longer GIMPLE, but 8049 GENERIC. The pass is located in 'tree-outof-ssa.c' and is 8050 described by 'pass_del_ssa'. 8051 8052 * Merge PHI nodes that feed into one another 8053 8054 This is part of the CFG cleanup passes. It attempts to join PHI 8055 nodes from a forwarder CFG block into another block with PHI nodes. 8056 The pass is located in 'tree-cfgcleanup.c' and is described by 8057 'pass_merge_phi'. 8058 8059 * Return value optimization 8060 8061 If a function always returns the same local variable, and that 8062 local variable is an aggregate type, then the variable is replaced 8063 with the return value for the function (i.e., the function's 8064 DECL_RESULT). This is equivalent to the C++ named return value 8065 optimization applied to GIMPLE. The pass is located in 8066 'tree-nrv.c' and is described by 'pass_nrv'. 8067 8068 * Return slot optimization 8069 8070 If a function returns a memory object and is called as 'var = 8071 foo()', this pass tries to change the call so that the address of 8072 'var' is sent to the caller to avoid an extra memory copy. This 8073 pass is located in 'tree-nrv.c' and is described by 8074 'pass_return_slot'. 8075 8076 * Optimize calls to '__builtin_object_size' 8077 8078 This is a propagation pass similar to CCP that tries to remove 8079 calls to '__builtin_object_size' when the size of the object can be 8080 computed at compile-time. This pass is located in 8081 'tree-object-size.c' and is described by 'pass_object_sizes'. 8082 8083 * Loop invariant motion 8084 8085 This pass removes expensive loop-invariant computations out of 8086 loops. The pass is located in 'tree-ssa-loop.c' and described by 8087 'pass_lim'. 8088 8089 * Loop nest optimizations 8090 8091 This is a family of loop transformations that works on loop nests. 8092 It includes loop interchange, scaling, skewing and reversal and 8093 they are all geared to the optimization of data locality in array 8094 traversals and the removal of dependencies that hamper 8095 optimizations such as loop parallelization and vectorization. The 8096 pass is located in 'tree-loop-linear.c' and described by 8097 'pass_linear_transform'. 8098 8099 * Removal of empty loops 8100 8101 This pass removes loops with no code in them. The pass is located 8102 in 'tree-ssa-loop-ivcanon.c' and described by 'pass_empty_loop'. 8103 8104 * Unrolling of small loops 8105 8106 This pass completely unrolls loops with few iterations. The pass 8107 is located in 'tree-ssa-loop-ivcanon.c' and described by 8108 'pass_complete_unroll'. 8109 8110 * Predictive commoning 8111 8112 This pass makes the code reuse the computations from the previous 8113 iterations of the loops, especially loads and stores to memory. It 8114 does so by storing the values of these computations to a bank of 8115 temporary variables that are rotated at the end of loop. To avoid 8116 the need for this rotation, the loop is then unrolled and the 8117 copies of the loop body are rewritten to use the appropriate 8118 version of the temporary variable. This pass is located in 8119 'tree-predcom.c' and described by 'pass_predcom'. 8120 8121 * Array prefetching 8122 8123 This pass issues prefetch instructions for array references inside 8124 loops. The pass is located in 'tree-ssa-loop-prefetch.c' and 8125 described by 'pass_loop_prefetch'. 8126 8127 * Reassociation 8128 8129 This pass rewrites arithmetic expressions to enable optimizations 8130 that operate on them, like redundancy elimination and 8131 vectorization. The pass is located in 'tree-ssa-reassoc.c' and 8132 described by 'pass_reassoc'. 8133 8134 * Optimization of 'stdarg' functions 8135 8136 This pass tries to avoid the saving of register arguments into the 8137 stack on entry to 'stdarg' functions. If the function doesn't use 8138 any 'va_start' macros, no registers need to be saved. If 8139 'va_start' macros are used, the 'va_list' variables don't escape 8140 the function, it is only necessary to save registers that will be 8141 used in 'va_arg' macros. For instance, if 'va_arg' is only used 8142 with integral types in the function, floating point registers don't 8143 need to be saved. This pass is located in 'tree-stdarg.c' and 8144 described by 'pass_stdarg'. 8145 8146 8147File: gccint.info, Node: RTL passes, Next: Optimization info, Prev: Tree SSA passes, Up: Passes 8148 81499.6 RTL passes 8150============== 8151 8152The following briefly describes the RTL generation and optimization 8153passes that are run after the Tree optimization passes. 8154 8155 * RTL generation 8156 8157 The source files for RTL generation include 'stmt.c', 'calls.c', 8158 'expr.c', 'explow.c', 'expmed.c', 'function.c', 'optabs.c' and 8159 'emit-rtl.c'. Also, the file 'insn-emit.c', generated from the 8160 machine description by the program 'genemit', is used in this pass. 8161 The header file 'expr.h' is used for communication within this 8162 pass. 8163 8164 The header files 'insn-flags.h' and 'insn-codes.h', generated from 8165 the machine description by the programs 'genflags' and 'gencodes', 8166 tell this pass which standard names are available for use and which 8167 patterns correspond to them. 8168 8169 * Generation of exception landing pads 8170 8171 This pass generates the glue that handles communication between the 8172 exception handling library routines and the exception handlers 8173 within the function. Entry points in the function that are invoked 8174 by the exception handling library are called "landing pads". The 8175 code for this pass is located in 'except.c'. 8176 8177 * Control flow graph cleanup 8178 8179 This pass removes unreachable code, simplifies jumps to next, jumps 8180 to jump, jumps across jumps, etc. The pass is run multiple times. 8181 For historical reasons, it is occasionally referred to as the "jump 8182 optimization pass". The bulk of the code for this pass is in 8183 'cfgcleanup.c', and there are support routines in 'cfgrtl.c' and 8184 'jump.c'. 8185 8186 * Forward propagation of single-def values 8187 8188 This pass attempts to remove redundant computation by substituting 8189 variables that come from a single definition, and seeing if the 8190 result can be simplified. It performs copy propagation and 8191 addressing mode selection. The pass is run twice, with values 8192 being propagated into loops only on the second run. The code is 8193 located in 'fwprop.c'. 8194 8195 * Common subexpression elimination 8196 8197 This pass removes redundant computation within basic blocks, and 8198 optimizes addressing modes based on cost. The pass is run twice. 8199 The code for this pass is located in 'cse.c'. 8200 8201 * Global common subexpression elimination 8202 8203 This pass performs two different types of GCSE depending on whether 8204 you are optimizing for size or not (LCM based GCSE tends to 8205 increase code size for a gain in speed, while Morel-Renvoise based 8206 GCSE does not). When optimizing for size, GCSE is done using 8207 Morel-Renvoise Partial Redundancy Elimination, with the exception 8208 that it does not try to move invariants out of loops--that is left 8209 to the loop optimization pass. If MR PRE GCSE is done, code 8210 hoisting (aka unification) is also done, as well as load motion. 8211 If you are optimizing for speed, LCM (lazy code motion) based GCSE 8212 is done. LCM is based on the work of Knoop, Ruthing, and Steffen. 8213 LCM based GCSE also does loop invariant code motion. We also 8214 perform load and store motion when optimizing for speed. 8215 Regardless of which type of GCSE is used, the GCSE pass also 8216 performs global constant and copy propagation. The source file for 8217 this pass is 'gcse.c', and the LCM routines are in 'lcm.c'. 8218 8219 * Loop optimization 8220 8221 This pass performs several loop related optimizations. The source 8222 files 'cfgloopanal.c' and 'cfgloopmanip.c' contain generic loop 8223 analysis and manipulation code. Initialization and finalization of 8224 loop structures is handled by 'loop-init.c'. A loop invariant 8225 motion pass is implemented in 'loop-invariant.c'. Basic block 8226 level optimizations--unrolling, and peeling loops-- are implemented 8227 in 'loop-unroll.c'. Replacing of the exit condition of loops by 8228 special machine-dependent instructions is handled by 8229 'loop-doloop.c'. 8230 8231 * Jump bypassing 8232 8233 This pass is an aggressive form of GCSE that transforms the control 8234 flow graph of a function by propagating constants into conditional 8235 branch instructions. The source file for this pass is 'gcse.c'. 8236 8237 * If conversion 8238 8239 This pass attempts to replace conditional branches and surrounding 8240 assignments with arithmetic, boolean value producing comparison 8241 instructions, and conditional move instructions. In the very last 8242 invocation after reload/LRA, it will generate predicated 8243 instructions when supported by the target. The code is located in 8244 'ifcvt.c'. 8245 8246 * Web construction 8247 8248 This pass splits independent uses of each pseudo-register. This 8249 can improve effect of the other transformation, such as CSE or 8250 register allocation. The code for this pass is located in 'web.c'. 8251 8252 * Instruction combination 8253 8254 This pass attempts to combine groups of two or three instructions 8255 that are related by data flow into single instructions. It 8256 combines the RTL expressions for the instructions by substitution, 8257 simplifies the result using algebra, and then attempts to match the 8258 result against the machine description. The code is located in 8259 'combine.c'. 8260 8261 * Mode switching optimization 8262 8263 This pass looks for instructions that require the processor to be 8264 in a specific "mode" and minimizes the number of mode changes 8265 required to satisfy all users. What these modes are, and what they 8266 apply to are completely target-specific. The code for this pass is 8267 located in 'mode-switching.c'. 8268 8269 * Modulo scheduling 8270 8271 This pass looks at innermost loops and reorders their instructions 8272 by overlapping different iterations. Modulo scheduling is 8273 performed immediately before instruction scheduling. The code for 8274 this pass is located in 'modulo-sched.c'. 8275 8276 * Instruction scheduling 8277 8278 This pass looks for instructions whose output will not be available 8279 by the time that it is used in subsequent instructions. Memory 8280 loads and floating point instructions often have this behavior on 8281 RISC machines. It re-orders instructions within a basic block to 8282 try to separate the definition and use of items that otherwise 8283 would cause pipeline stalls. This pass is performed twice, before 8284 and after register allocation. The code for this pass is located 8285 in 'haifa-sched.c', 'sched-deps.c', 'sched-ebb.c', 'sched-rgn.c' 8286 and 'sched-vis.c'. 8287 8288 * Register allocation 8289 8290 These passes make sure that all occurrences of pseudo registers are 8291 eliminated, either by allocating them to a hard register, replacing 8292 them by an equivalent expression (e.g. a constant) or by placing 8293 them on the stack. This is done in several subpasses: 8294 8295 * The integrated register allocator (IRA). It is called 8296 integrated because coalescing, register live range splitting, 8297 and hard register preferencing are done on-the-fly during 8298 coloring. It also has better integration with the reload/LRA 8299 pass. Pseudo-registers spilled by the allocator or the 8300 reload/LRA have still a chance to get hard-registers if the 8301 reload/LRA evicts some pseudo-registers from hard-registers. 8302 The allocator helps to choose better pseudos for spilling 8303 based on their live ranges and to coalesce stack slots 8304 allocated for the spilled pseudo-registers. IRA is a regional 8305 register allocator which is transformed into Chaitin-Briggs 8306 allocator if there is one region. By default, IRA chooses 8307 regions using register pressure but the user can force it to 8308 use one region or regions corresponding to all loops. 8309 8310 Source files of the allocator are 'ira.c', 'ira-build.c', 8311 'ira-costs.c', 'ira-conflicts.c', 'ira-color.c', 'ira-emit.c', 8312 'ira-lives', plus header files 'ira.h' and 'ira-int.h' used 8313 for the communication between the allocator and the rest of 8314 the compiler and between the IRA files. 8315 8316 * Reloading. This pass renumbers pseudo registers with the 8317 hardware registers numbers they were allocated. Pseudo 8318 registers that did not get hard registers are replaced with 8319 stack slots. Then it finds instructions that are invalid 8320 because a value has failed to end up in a register, or has 8321 ended up in a register of the wrong kind. It fixes up these 8322 instructions by reloading the problematical values temporarily 8323 into registers. Additional instructions are generated to do 8324 the copying. 8325 8326 The reload pass also optionally eliminates the frame pointer 8327 and inserts instructions to save and restore call-clobbered 8328 registers around calls. 8329 8330 Source files are 'reload.c' and 'reload1.c', plus the header 8331 'reload.h' used for communication between them. 8332 8333 * This pass is a modern replacement of the reload pass. Source 8334 files are 'lra.c', 'lra-assign.c', 'lra-coalesce.c', 8335 'lra-constraints.c', 'lra-eliminations.c', 'lra-lives.c', 8336 'lra-remat.c', 'lra-spills.c', the header 'lra-int.h' used for 8337 communication between them, and the header 'lra.h' used for 8338 communication between LRA and the rest of compiler. 8339 8340 Unlike the reload pass, intermediate LRA decisions are 8341 reflected in RTL as much as possible. This reduces the number 8342 of target-dependent macros and hooks, leaving instruction 8343 constraints as the primary source of control. 8344 8345 LRA is run on targets for which TARGET_LRA_P returns true. 8346 8347 * Basic block reordering 8348 8349 This pass implements profile guided code positioning. If profile 8350 information is not available, various types of static analysis are 8351 performed to make the predictions normally coming from the profile 8352 feedback (IE execution frequency, branch probability, etc). It is 8353 implemented in the file 'bb-reorder.c', and the various prediction 8354 routines are in 'predict.c'. 8355 8356 * Variable tracking 8357 8358 This pass computes where the variables are stored at each position 8359 in code and generates notes describing the variable locations to 8360 RTL code. The location lists are then generated according to these 8361 notes to debug information if the debugging information format 8362 supports location lists. The code is located in 'var-tracking.c'. 8363 8364 * Delayed branch scheduling 8365 8366 This optional pass attempts to find instructions that can go into 8367 the delay slots of other instructions, usually jumps and calls. 8368 The code for this pass is located in 'reorg.c'. 8369 8370 * Branch shortening 8371 8372 On many RISC machines, branch instructions have a limited range. 8373 Thus, longer sequences of instructions must be used for long 8374 branches. In this pass, the compiler figures out what how far each 8375 instruction will be from each other instruction, and therefore 8376 whether the usual instructions, or the longer sequences, must be 8377 used for each branch. The code for this pass is located in 8378 'final.c'. 8379 8380 * Register-to-stack conversion 8381 8382 Conversion from usage of some hard registers to usage of a register 8383 stack may be done at this point. Currently, this is supported only 8384 for the floating-point registers of the Intel 80387 coprocessor. 8385 The code for this pass is located in 'reg-stack.c'. 8386 8387 * Final 8388 8389 This pass outputs the assembler code for the function. The source 8390 files are 'final.c' plus 'insn-output.c'; the latter is generated 8391 automatically from the machine description by the tool 'genoutput'. 8392 The header file 'conditions.h' is used for communication between 8393 these files. 8394 8395 * Debugging information output 8396 8397 This is run after final because it must output the stack slot 8398 offsets for pseudo registers that did not get hard registers. 8399 Source files are 'dbxout.c' for DBX symbol table format, 8400 'dwarfout.c' for DWARF symbol table format, files 'dwarf2out.c' and 8401 'dwarf2asm.c' for DWARF2 symbol table format, and 'vmsdbgout.c' for 8402 VMS debug symbol table format. 8403 8404 8405File: gccint.info, Node: Optimization info, Prev: RTL passes, Up: Passes 8406 84079.7 Optimization info 8408===================== 8409 8410This section is describes dump infrastructure which is common to both 8411pass dumps as well as optimization dumps. The goal for this 8412infrastructure is to provide both gcc developers and users detailed 8413information about various compiler transformations and optimizations. 8414 8415* Menu: 8416 8417* Dump setup:: Setup of optimization dumps. 8418* Optimization groups:: Groups made up of optimization passes. 8419* Dump files and streams:: Dump output file names and streams. 8420* Dump output verbosity:: How much information to dump. 8421* Dump types:: Various types of dump functions. 8422* Dump examples:: Sample usage. 8423 8424 8425File: gccint.info, Node: Dump setup, Next: Optimization groups, Up: Optimization info 8426 84279.7.1 Dump setup 8428---------------- 8429 8430A dump_manager class is defined in 'dumpfile.h'. Various passes 8431register dumping pass-specific information via 'dump_register' in 8432'passes.c'. During the registration, an optimization pass can select 8433its optimization group (*note Optimization groups::). After that 8434optimization information corresponding to the entire group (presumably 8435from multiple passes) can be output via command-line switches. Note 8436that if a pass does not fit into any of the pre-defined groups, it can 8437select 'OPTGROUP_NONE'. 8438 8439 Note that in general, a pass need not know its dump output file name, 8440whether certain flags are enabled, etc. However, for legacy reasons, 8441passes could also call 'dump_begin' which returns a stream in case the 8442particular pass has optimization dumps enabled. A pass could call 8443'dump_end' when the dump has ended. These methods should go away once 8444all the passes are converted to use the new dump infrastructure. 8445 8446 The recommended way to setup the dump output is via 'dump_start' and 8447'dump_end'. 8448 8449 8450File: gccint.info, Node: Optimization groups, Next: Dump files and streams, Prev: Dump setup, Up: Optimization info 8451 84529.7.2 Optimization groups 8453------------------------- 8454 8455The optimization passes are grouped into several categories. Currently 8456defined categories in 'dumpfile.h' are 8457 8458'OPTGROUP_IPA' 8459 IPA optimization passes. Enabled by '-ipa' 8460 8461'OPTGROUP_LOOP' 8462 Loop optimization passes. Enabled by '-loop'. 8463 8464'OPTGROUP_INLINE' 8465 Inlining passes. Enabled by '-inline'. 8466 8467'OPTGROUP_OMP' 8468 OMP (Offloading and Multi Processing) passes. Enabled by '-omp'. 8469 8470'OPTGROUP_VEC' 8471 Vectorization passes. Enabled by '-vec'. 8472 8473'OPTGROUP_OTHER' 8474 All other optimization passes which do not fall into one of the 8475 above. 8476 8477'OPTGROUP_ALL' 8478 All optimization passes. Enabled by '-optall'. 8479 8480 By using groups a user could selectively enable optimization 8481information only for a group of passes. By default, the optimization 8482information for all the passes is dumped. 8483 8484 8485File: gccint.info, Node: Dump files and streams, Next: Dump output verbosity, Prev: Optimization groups, Up: Optimization info 8486 84879.7.3 Dump files and streams 8488---------------------------- 8489 8490There are two separate output streams available for outputting 8491optimization information from passes. Note that both these streams 8492accept 'stderr' and 'stdout' as valid streams and thus it is possible to 8493dump output to standard output or error. This is specially handy for 8494outputting all available information in a single file by redirecting 8495'stderr'. 8496 8497'pstream' 8498 This stream is for pass-specific dump output. For example, 8499 '-fdump-tree-vect=foo.v' dumps tree vectorization pass output into 8500 the given file name 'foo.v'. If the file name is not provided, the 8501 default file name is based on the source file and pass number. 8502 Note that one could also use special file names 'stdout' and 8503 'stderr' for dumping to standard output and standard error 8504 respectively. 8505 8506'alt_stream' 8507 This steam is used for printing optimization specific output in 8508 response to the '-fopt-info'. Again a file name can be given. If 8509 the file name is not given, it defaults to 'stderr'. 8510 8511 8512File: gccint.info, Node: Dump output verbosity, Next: Dump types, Prev: Dump files and streams, Up: Optimization info 8513 85149.7.4 Dump output verbosity 8515--------------------------- 8516 8517The dump verbosity has the following options 8518 8519'optimized' 8520 Print information when an optimization is successfully applied. It 8521 is up to a pass to decide which information is relevant. For 8522 example, the vectorizer passes print the source location of loops 8523 which got successfully vectorized. 8524 8525'missed' 8526 Print information about missed optimizations. Individual passes 8527 control which information to include in the output. For example, 8528 8529 gcc -O2 -ftree-vectorize -fopt-info-vec-missed 8530 8531 will print information about missed optimization opportunities from 8532 vectorization passes on stderr. 8533 8534'note' 8535 Print verbose information about optimizations, such as certain 8536 transformations, more detailed messages about decisions etc. 8537 8538'all' 8539 Print detailed optimization information. This includes OPTIMIZED, 8540 MISSED, and NOTE. 8541 8542 8543File: gccint.info, Node: Dump types, Next: Dump examples, Prev: Dump output verbosity, Up: Optimization info 8544 85459.7.5 Dump types 8546---------------- 8547 8548'dump_printf' 8549 8550 This is a generic method for doing formatted output. It takes an 8551 additional argument 'dump_kind' which signifies the type of dump. 8552 This method outputs information only when the dumps are enabled for 8553 this particular 'dump_kind'. Note that the caller doesn't need to 8554 know if the particular dump is enabled or not, or even the file 8555 name. The caller only needs to decide which dump output 8556 information is relevant, and under what conditions. This 8557 determines the associated flags. 8558 8559 Consider the following example from 'loop-unroll.c' where an 8560 informative message about a loop (along with its location) is 8561 printed when any of the following flags is enabled 8562 8563 - optimization messages 8564 - RTL dumps 8565 - detailed dumps 8566 8567 int report_flags = MSG_OPTIMIZED_LOCATIONS | TDF_RTL | TDF_DETAILS; 8568 dump_printf_loc (report_flags, insn, 8569 "loop turned into non-loop; it never loops.\n"); 8570 8571'dump_basic_block' 8572 Output basic block. 8573'dump_generic_expr' 8574 Output generic expression. 8575'dump_gimple_stmt' 8576 Output gimple statement. 8577 8578 Note that the above methods also have variants prefixed with 8579 '_loc', such as 'dump_printf_loc', which are similar except they 8580 also output the source location information. The '_loc' variants 8581 take a 'const dump_location_t &'. This class can be constructed 8582 from a 'gimple *' or from a 'rtx_insn *', and so callers can pass a 8583 'gimple *' or a 'rtx_insn *' as the '_loc' argument. The 8584 'dump_location_t' constructor will extract the source location from 8585 the statement or instruction, along with the profile count, and the 8586 location in GCC's own source code (or the plugin) from which the 8587 dump call was emitted. Only the source location is currently used. 8588 There is also a 'dump_user_location_t' class, capturing the source 8589 location and profile count, but not the dump emission location, so 8590 that locations in the user's code can be passed around. This can 8591 also be constructed from a 'gimple *' and from a 'rtx_insn *', and 8592 it too can be passed as the '_loc' argument. 8593 8594 8595File: gccint.info, Node: Dump examples, Prev: Dump types, Up: Optimization info 8596 85979.7.6 Dump examples 8598------------------- 8599 8600 gcc -O3 -fopt-info-missed=missed.all 8601 8602 outputs missed optimization report from all the passes into 8603'missed.all'. 8604 8605 As another example, 8606 gcc -O3 -fopt-info-inline-optimized-missed=inline.txt 8607 8608 will output information about missed optimizations as well as optimized 8609locations from all the inlining passes into 'inline.txt'. 8610 8611 If the FILENAME is provided, then the dumps from all the applicable 8612optimizations are concatenated into the 'filename'. Otherwise the dump 8613is output onto 'stderr'. If OPTIONS is omitted, it defaults to 8614'optimized-optall', which means dump all information about successful 8615optimizations from all the passes. In the following example, the 8616optimization information is output on to 'stderr'. 8617 8618 gcc -O3 -fopt-info 8619 8620 Note that '-fopt-info-vec-missed' behaves the same as 8621'-fopt-info-missed-vec'. The order of the optimization group names and 8622message types listed after '-fopt-info' does not matter. 8623 8624 As another example, consider 8625 8626 gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt 8627 8628 Here the two output file names 'vec.miss' and 'loop.opt' are in 8629conflict since only one output file is allowed. In this case, only the 8630first option takes effect and the subsequent options are ignored. Thus 8631only the 'vec.miss' is produced which containts dumps from the 8632vectorizer about missed opportunities. 8633 8634 8635File: gccint.info, Node: poly_int, Next: GENERIC, Prev: Passes, Up: Top 8636 863710 Sizes and offsets as runtime invariants 8638****************************************** 8639 8640GCC allows the size of a hardware register to be a runtime invariant 8641rather than a compile-time constant. This in turn means that various 8642sizes and offsets must also be runtime invariants rather than 8643compile-time constants, such as: 8644 8645 * the size of a general 'machine_mode' (*note Machine Modes::); 8646 8647 * the size of a spill slot; 8648 8649 * the offset of something within a stack frame; 8650 8651 * the number of elements in a vector; 8652 8653 * the size and offset of a 'mem' rtx (*note Regs and Memory::); and 8654 8655 * the byte offset in a 'subreg' rtx (*note Regs and Memory::). 8656 8657 The motivating example is the Arm SVE ISA, whose vector registers can 8658be any multiple of 128 bits between 128 and 2048 inclusive. The 8659compiler normally produces code that works for all SVE register sizes, 8660with the actual size only being known at runtime. 8661 8662 GCC's main representation of such runtime invariants is the 'poly_int' 8663class. This chapter describes what 'poly_int' does, lists the available 8664operations, and gives some general usage guidelines. 8665 8666* Menu: 8667 8668* Overview of poly_int:: 8669* Consequences of using poly_int:: 8670* Comparisons involving poly_int:: 8671* Arithmetic on poly_ints:: 8672* Alignment of poly_ints:: 8673* Computing bounds on poly_ints:: 8674* Converting poly_ints:: 8675* Miscellaneous poly_int routines:: 8676* Guidelines for using poly_int:: 8677 8678 8679File: gccint.info, Node: Overview of poly_int, Next: Consequences of using poly_int, Up: poly_int 8680 868110.1 Overview of 'poly_int' 8682=========================== 8683 8684We define indeterminates X1, ..., XN whose values are only known at 8685runtime and use polynomials of the form: 8686 8687 C0 + C1 * X1 + ... + CN * XN 8688 8689 to represent a size or offset whose value might depend on some of these 8690indeterminates. The coefficients C0, ..., CN are always known at 8691compile time, with the C0 term being the "constant" part that does not 8692depend on any runtime value. 8693 8694 GCC uses the 'poly_int' class to represent these coefficients. The 8695class has two template parameters: the first specifies the number of 8696coefficients (N + 1) and the second specifies the type of the 8697coefficients. For example, 'poly_int<2, unsigned short>' represents a 8698polynomial with two coefficients (and thus one indeterminate), with each 8699coefficient having type 'unsigned short'. When N is 0, the class 8700degenerates to a single compile-time constant C0. 8701 8702 The number of coefficients needed for compilation is a fixed property 8703of each target and is specified by the configuration macro 8704'NUM_POLY_INT_COEFFS'. The default value is 1, since most targets do 8705not have such runtime invariants. Targets that need a different value 8706should '#define' the macro in their 'CPU-modes.def' file. *Note Back 8707End::. 8708 8709 'poly_int' makes the simplifying requirement that each indeterminate 8710must be a nonnegative integer. An indeterminate value of 0 should 8711usually represent the minimum possible runtime value, with C0 specifying 8712the value in that case. 8713 8714 For example, when targetting the Arm SVE ISA, the single indeterminate 8715represents the number of 128-bit blocks in a vector _beyond the minimum 8716length of 128 bits_. Thus the number of 64-bit doublewords in a vector 8717is 2 + 2 * X1. If an aggregate has a single SVE vector and 16 8718additional bytes, its total size is 32 + 16 * X1 bytes. 8719 8720 The header file 'poly-int-types.h' provides typedefs for the most 8721common forms of 'poly_int', all having 'NUM_POLY_INT_COEFFS' 8722coefficients: 8723 8724'poly_uint16' 8725 a 'poly_int' with 'unsigned short' coefficients. 8726 8727'poly_int64' 8728 a 'poly_int' with 'HOST_WIDE_INT' coefficients. 8729 8730'poly_uint64' 8731 a 'poly_int' with 'unsigned HOST_WIDE_INT' coefficients. 8732 8733'poly_offset_int' 8734 a 'poly_int' with 'offset_int' coefficients. 8735 8736'poly_wide_int' 8737 a 'poly_int' with 'wide_int' coefficients. 8738 8739'poly_widest_int' 8740 a 'poly_int' with 'widest_int' coefficients. 8741 8742 Since the main purpose of 'poly_int' is to represent sizes and offsets, 8743the last two typedefs are only rarely used. 8744 8745 8746File: gccint.info, Node: Consequences of using poly_int, Next: Comparisons involving poly_int, Prev: Overview of poly_int, Up: poly_int 8747 874810.2 Consequences of using 'poly_int' 8749===================================== 8750 8751The two main consequences of using polynomial sizes and offsets are 8752that: 8753 8754 * there is no total ordering between the values at compile time, and 8755 8756 * some operations might yield results that cannot be expressed as a 8757 'poly_int'. 8758 8759 For example, if X is a runtime invariant, we cannot tell at compile 8760time whether: 8761 8762 3 + 4X <= 1 + 5X 8763 8764 since the condition is false when X <= 1 and true when X >= 2. 8765 8766 Similarly, 'poly_int' cannot represent the result of: 8767 8768 (3 + 4X) * (1 + 5X) 8769 8770 since it cannot (and in practice does not need to) store powers greater 8771than one. It also cannot represent the result of: 8772 8773 (3 + 4X) / (1 + 5X) 8774 8775 The following sections describe how we deal with these restrictions. 8776 8777 As described earlier, a 'poly_int<1, T>' has no indeterminates and so 8778degenerates to a compile-time constant of type T. It would be possible 8779in that case to do all normal arithmetic on the T, and to compare the T 8780using the normal C++ operators. We deliberately prevent 8781target-independent code from doing this, since the compiler needs to 8782support other 'poly_int<N, T>' as well, regardless of the current 8783target's 'NUM_POLY_INT_COEFFS'. 8784 8785 However, it would be very artificial to force target-specific code to 8786follow these restrictions if the target has no runtime indeterminates. 8787There is therefore an implicit conversion from 'poly_int<1, T>' to T 8788when compiling target-specific translation units. 8789 8790 8791File: gccint.info, Node: Comparisons involving poly_int, Next: Arithmetic on poly_ints, Prev: Consequences of using poly_int, Up: poly_int 8792 879310.3 Comparisons involving 'poly_int' 8794===================================== 8795 8796In general we need to compare sizes and offsets in two situations: those 8797in which the values need to be ordered, and those in which the values 8798can be unordered. More loosely, the distinction is often between values 8799that have a definite link (usually because they refer to the same 8800underlying register or memory location) and values that have no definite 8801link. An example of the former is the relationship between the inner 8802and outer sizes of a subreg, where we must know at compile time whether 8803the subreg is paradoxical, partial, or complete. An example of the 8804latter is alias analysis: we might want to check whether two arbitrary 8805memory references overlap. 8806 8807 Referring back to the examples in the previous section, it makes sense 8808to ask whether a memory reference of size '3 + 4X' overlaps one of size 8809'1 + 5X', but it does not make sense to have a subreg in which the outer 8810mode has '3 + 4X' bytes and the inner mode has '1 + 5X' bytes (or vice 8811versa). Such subregs are always invalid and should trigger an internal 8812compiler error if formed. 8813 8814 The underlying operators are the same in both cases, but the 8815distinction affects how they are used. 8816 8817* Menu: 8818 8819* Comparison functions for poly_int:: 8820* Properties of the poly_int comparisons:: 8821* Comparing potentially-unordered poly_ints:: 8822* Comparing ordered poly_ints:: 8823* Checking for a poly_int marker value:: 8824* Range checks on poly_ints:: 8825* Sorting poly_ints:: 8826 8827 8828File: gccint.info, Node: Comparison functions for poly_int, Next: Properties of the poly_int comparisons, Up: Comparisons involving poly_int 8829 883010.3.1 Comparison functions for 'poly_int' 8831------------------------------------------ 8832 8833'poly_int' provides the following routines for checking whether a 8834particular condition "may be" (might be) true: 8835 8836 maybe_lt maybe_le maybe_eq maybe_ge maybe_gt 8837 maybe_ne 8838 8839 The functions have their natural meaning: 8840 8841'maybe_lt(A, B)' 8842 Return true if A might be less than B. 8843 8844'maybe_le(A, B)' 8845 Return true if A might be less than or equal to B. 8846 8847'maybe_eq(A, B)' 8848 Return true if A might be equal to B. 8849 8850'maybe_ne(A, B)' 8851 Return true if A might not be equal to B. 8852 8853'maybe_ge(A, B)' 8854 Return true if A might be greater than or equal to B. 8855 8856'maybe_gt(A, B)' 8857 Return true if A might be greater than B. 8858 8859 For readability, 'poly_int' also provides "known" inverses of these 8860functions: 8861 8862 known_lt (A, B) == !maybe_ge (A, B) 8863 known_le (A, B) == !maybe_gt (A, B) 8864 known_eq (A, B) == !maybe_ne (A, B) 8865 known_ge (A, B) == !maybe_lt (A, B) 8866 known_gt (A, B) == !maybe_le (A, B) 8867 known_ne (A, B) == !maybe_eq (A, B) 8868 8869 8870File: gccint.info, Node: Properties of the poly_int comparisons, Next: Comparing potentially-unordered poly_ints, Prev: Comparison functions for poly_int, Up: Comparisons involving poly_int 8871 887210.3.2 Properties of the 'poly_int' comparisons 8873----------------------------------------------- 8874 8875All "maybe" relations except 'maybe_ne' are transitive, so for example: 8876 8877 maybe_lt (A, B) && maybe_lt (B, C) implies maybe_lt (A, C) 8878 8879 for all A, B and C. 'maybe_lt', 'maybe_gt' and 'maybe_ne' are 8880irreflexive, so for example: 8881 8882 !maybe_lt (A, A) 8883 8884 is true for all A. 'maybe_le', 'maybe_eq' and 'maybe_ge' are 8885reflexive, so for example: 8886 8887 maybe_le (A, A) 8888 8889 is true for all A. 'maybe_eq' and 'maybe_ne' are symmetric, so: 8890 8891 maybe_eq (A, B) == maybe_eq (B, A) 8892 maybe_ne (A, B) == maybe_ne (B, A) 8893 8894 for all A and B. In addition: 8895 8896 maybe_le (A, B) == maybe_lt (A, B) || maybe_eq (A, B) 8897 maybe_ge (A, B) == maybe_gt (A, B) || maybe_eq (A, B) 8898 maybe_lt (A, B) == maybe_gt (B, A) 8899 maybe_le (A, B) == maybe_ge (B, A) 8900 8901 However: 8902 8903 maybe_le (A, B) && maybe_le (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)] 8904 maybe_ge (A, B) && maybe_ge (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)] 8905 8906 One example is again 'A == 3 + 4X' and 'B == 1 + 5X', where 'maybe_le 8907(A, B)', 'maybe_ge (A, B)' and 'maybe_ne (A, B)' all hold. 'maybe_le' 8908and 'maybe_ge' are therefore not antisymetric and do not form a partial 8909order. 8910 8911 From the above, it follows that: 8912 8913 * All "known" relations except 'known_ne' are transitive. 8914 8915 * 'known_lt', 'known_ne' and 'known_gt' are irreflexive. 8916 8917 * 'known_le', 'known_eq' and 'known_ge' are reflexive. 8918 8919 Also: 8920 8921 known_lt (A, B) == known_gt (B, A) 8922 known_le (A, B) == known_ge (B, A) 8923 known_lt (A, B) implies !known_lt (B, A) [asymmetry] 8924 known_gt (A, B) implies !known_gt (B, A) 8925 known_le (A, B) && known_le (B, A) == known_eq (A, B) [== !maybe_ne (A, B)] 8926 known_ge (A, B) && known_ge (B, A) == known_eq (A, B) [== !maybe_ne (A, B)] 8927 8928 'known_le' and 'known_ge' are therefore antisymmetric and are partial 8929orders. However: 8930 8931 known_le (A, B) does not imply known_lt (A, B) || known_eq (A, B) 8932 known_ge (A, B) does not imply known_gt (A, B) || known_eq (A, B) 8933 8934 For example, 'known_le (4, 4 + 4X)' holds because the runtime 8935indeterminate X is a nonnegative integer, but neither 'known_lt (4, 4 + 89364X)' nor 'known_eq (4, 4 + 4X)' hold. 8937 8938 8939File: gccint.info, Node: Comparing potentially-unordered poly_ints, Next: Comparing ordered poly_ints, Prev: Properties of the poly_int comparisons, Up: Comparisons involving poly_int 8940 894110.3.3 Comparing potentially-unordered 'poly_int's 8942-------------------------------------------------- 8943 8944In cases where there is no definite link between two 'poly_int's, we can 8945usually make a conservatively-correct assumption. For example, the 8946conservative assumption for alias analysis is that two references 8947_might_ alias. 8948 8949 One way of checking whether [BEGIN1, END1) might overlap [BEGIN2, END2) 8950using the 'poly_int' comparisons is: 8951 8952 maybe_gt (END1, BEGIN2) && maybe_gt (END2, BEGIN1) 8953 8954 and another (equivalent) way is: 8955 8956 !(known_le (END1, BEGIN2) || known_le (END2, BEGIN1)) 8957 8958 However, in this particular example, it is better to use the range 8959helper functions instead. *Note Range checks on poly_ints::. 8960 8961 8962File: gccint.info, Node: Comparing ordered poly_ints, Next: Checking for a poly_int marker value, Prev: Comparing potentially-unordered poly_ints, Up: Comparisons involving poly_int 8963 896410.3.4 Comparing ordered 'poly_int's 8965------------------------------------ 8966 8967In cases where there is a definite link between two 'poly_int's, such as 8968the outer and inner sizes of subregs, we usually require the sizes to be 8969ordered by the 'known_le' partial order. 'poly_int' provides the 8970following utility functions for ordered values: 8971 8972'ordered_p (A, B)' 8973 Return true if A and B are ordered by the 'known_le' partial order. 8974 8975'ordered_min (A, B)' 8976 Assert that A and B are ordered by 'known_le' and return the 8977 minimum of the two. When using this function, please add a comment 8978 explaining why the values are known to be ordered. 8979 8980'ordered_max (A, B)' 8981 Assert that A and B are ordered by 'known_le' and return the 8982 maximum of the two. When using this function, please add a comment 8983 explaining why the values are known to be ordered. 8984 8985 For example, if a subreg has an outer mode of size OUTER and an inner 8986mode of size INNER: 8987 8988 * the subreg is complete if known_eq (INNER, OUTER) 8989 8990 * otherwise, the subreg is paradoxical if known_le (INNER, OUTER) 8991 8992 * otherwise, the subreg is partial if known_le (OUTER, INNER) 8993 8994 * otherwise, the subreg is ill-formed 8995 8996 Thus the subreg is only valid if 'ordered_p (OUTER, INNER)' is true. 8997If this condition is already known to be true then: 8998 8999 * the subreg is complete if known_eq (INNER, OUTER) 9000 9001 * the subreg is paradoxical if maybe_lt (INNER, OUTER) 9002 9003 * the subreg is partial if maybe_lt (OUTER, INNER) 9004 9005 with the three conditions being mutually exclusive. 9006 9007 Code that checks whether a subreg is valid would therefore generally 9008check whether 'ordered_p' holds (in addition to whatever other checks 9009are required for subreg validity). Code that is dealing with existing 9010subregs can assert that 'ordered_p' holds and use either of the 9011classifications above. 9012 9013 9014File: gccint.info, Node: Checking for a poly_int marker value, Next: Range checks on poly_ints, Prev: Comparing ordered poly_ints, Up: Comparisons involving poly_int 9015 901610.3.5 Checking for a 'poly_int' marker value 9017--------------------------------------------- 9018 9019It is sometimes useful to have a special "marker value" that is not 9020meant to be taken literally. For example, some code uses a size of -1 9021to represent an unknown size, rather than having to carry around a 9022separate boolean to say whether the size is known. 9023 9024 The best way of checking whether something is a marker value is 9025'known_eq'. Conversely the best way of checking whether something is 9026_not_ a marker value is 'maybe_ne'. 9027 9028 Thus in the size example just mentioned, 'known_eq (size, -1)' would 9029check for an unknown size and 'maybe_ne (size, -1)' would check for a 9030known size. 9031 9032 9033File: gccint.info, Node: Range checks on poly_ints, Next: Sorting poly_ints, Prev: Checking for a poly_int marker value, Up: Comparisons involving poly_int 9034 903510.3.6 Range checks on 'poly_int's 9036---------------------------------- 9037 9038As well as the core comparisons (*note Comparison functions for 9039poly_int::), 'poly_int' provides utilities for various kinds of range 9040check. In each case the range is represented by a start position and a 9041size rather than a start position and an end position; this is because 9042the former is used much more often than the latter in GCC. Also, the 9043sizes can be -1 (or all ones for unsigned sizes) to indicate a range 9044with a known start position but an unknown size. All other sizes must 9045be nonnegative. A range of size 0 does not contain anything or overlap 9046anything. 9047 9048'known_size_p (SIZE)' 9049 Return true if SIZE represents a known range size, false if it is 9050 -1 or all ones (for signed and unsigned types respectively). 9051 9052'ranges_maybe_overlap_p (POS1, SIZE1, POS2, SIZE2)' 9053 Return true if the range described by POS1 and SIZE1 _might_ 9054 overlap the range described by POS2 and SIZE2 (in other words, 9055 return true if we cannot prove that the ranges are disjoint). 9056 9057'ranges_known_overlap_p (POS1, SIZE1, POS2, SIZE2)' 9058 Return true if the range described by POS1 and SIZE1 is known to 9059 overlap the range described by POS2 and SIZE2. 9060 9061'known_subrange_p (POS1, SIZE1, POS2, SIZE2)' 9062 Return true if the range described by POS1 and SIZE1 is known to be 9063 contained in the range described by POS2 and SIZE2. 9064 9065'maybe_in_range_p (VALUE, POS, SIZE)' 9066 Return true if VALUE _might_ be in the range described by POS and 9067 SIZE (in other words, return true if we cannot prove that VALUE is 9068 outside that range). 9069 9070'known_in_range_p (VALUE, POS, SIZE)' 9071 Return true if VALUE is known to be in the range described by POS 9072 and SIZE. 9073 9074'endpoint_representable_p (POS, SIZE)' 9075 Return true if the range described by POS and SIZE is open-ended or 9076 if the endpoint (POS + SIZE) is representable in the same type as 9077 POS and SIZE. The function returns false if adding SIZE to POS 9078 makes conceptual sense but could overflow. 9079 9080 There is also a 'poly_int' version of the 'IN_RANGE_P' macro: 9081 9082'coeffs_in_range_p (X, LOWER, UPPER)' 9083 Return true if every coefficient of X is in the inclusive range 9084 [LOWER, UPPER]. This function can be useful when testing whether 9085 an operation would cause the values of coefficients to overflow. 9086 9087 Note that the function does not indicate whether X itself is in the 9088 given range. X can be either a constant or a 'poly_int'. 9089 9090 9091File: gccint.info, Node: Sorting poly_ints, Prev: Range checks on poly_ints, Up: Comparisons involving poly_int 9092 909310.3.7 Sorting 'poly_int's 9094-------------------------- 9095 9096'poly_int' provides the following routine for sorting: 9097 9098'compare_sizes_for_sort (A, B)' 9099 Compare A and B in reverse lexicographical order (that is, compare 9100 the highest-indexed coefficients first). This can be useful when 9101 sorting data structures, since it has the effect of separating 9102 constant and non-constant values. If all values are nonnegative, 9103 the constant values come first. 9104 9105 Note that the values do not necessarily end up in numerical order. 9106 For example, '1 + 1X' would come after '100' in the sort order, but 9107 may well be less than '100' at run time. 9108 9109 9110File: gccint.info, Node: Arithmetic on poly_ints, Next: Alignment of poly_ints, Prev: Comparisons involving poly_int, Up: poly_int 9111 911210.4 Arithmetic on 'poly_int's 9113============================== 9114 9115Addition, subtraction, negation and bit inversion all work normally for 9116'poly_int's. Multiplication by a constant multiplier and left shifting 9117by a constant shift amount also work normally. General multiplication 9118of two 'poly_int's is not supported and is not useful in practice. 9119 9120 Other operations are only conditionally supported: the operation might 9121succeed or might fail, depending on the inputs. 9122 9123 This section describes both types of operation. 9124 9125* Menu: 9126 9127* Using poly_int with C++ arithmetic operators:: 9128* wi arithmetic on poly_ints:: 9129* Division of poly_ints:: 9130* Other poly_int arithmetic:: 9131 9132 9133File: gccint.info, Node: Using poly_int with C++ arithmetic operators, Next: wi arithmetic on poly_ints, Up: Arithmetic on poly_ints 9134 913510.4.1 Using 'poly_int' with C++ arithmetic operators 9136----------------------------------------------------- 9137 9138The following C++ expressions are supported, where P1 and P2 are 9139'poly_int's and where C1 and C2 are scalars: 9140 9141 -P1 9142 ~P1 9143 9144 P1 + P2 9145 P1 + C2 9146 C1 + P2 9147 9148 P1 - P2 9149 P1 - C2 9150 C1 - P2 9151 9152 C1 * P2 9153 P1 * C2 9154 9155 P1 << C2 9156 9157 P1 += P2 9158 P1 += C2 9159 9160 P1 -= P2 9161 P1 -= C2 9162 9163 P1 *= C2 9164 P1 <<= C2 9165 9166 These arithmetic operations handle integer ranks in a similar way to 9167C++. The main difference is that every coefficient narrower than 9168'HOST_WIDE_INT' promotes to 'HOST_WIDE_INT', whereas in C++ everything 9169narrower than 'int' promotes to 'int'. For example: 9170 9171 poly_uint16 + int -> poly_int64 9172 unsigned int + poly_uint16 -> poly_int64 9173 poly_int64 + int -> poly_int64 9174 poly_int32 + poly_uint64 -> poly_uint64 9175 uint64 + poly_int64 -> poly_uint64 9176 poly_offset_int + int32 -> poly_offset_int 9177 offset_int + poly_uint16 -> poly_offset_int 9178 9179 In the first two examples, both coefficients are narrower than 9180'HOST_WIDE_INT', so the result has coefficients of type 'HOST_WIDE_INT'. 9181In the other examples, the coefficient with the highest rank "wins". 9182 9183 If one of the operands is 'wide_int' or 'poly_wide_int', the rules are 9184the same as for 'wide_int' arithmetic. 9185 9186 9187File: gccint.info, Node: wi arithmetic on poly_ints, Next: Division of poly_ints, Prev: Using poly_int with C++ arithmetic operators, Up: Arithmetic on poly_ints 9188 918910.4.2 'wi' arithmetic on 'poly_int's 9190------------------------------------- 9191 9192As well as the C++ operators, 'poly_int' supports the following 'wi' 9193routines: 9194 9195 wi::neg (P1, &OVERFLOW) 9196 9197 wi::add (P1, P2) 9198 wi::add (P1, C2) 9199 wi::add (C1, P1) 9200 wi::add (P1, P2, SIGN, &OVERFLOW) 9201 9202 wi::sub (P1, P2) 9203 wi::sub (P1, C2) 9204 wi::sub (C1, P1) 9205 wi::sub (P1, P2, SIGN, &OVERFLOW) 9206 9207 wi::mul (P1, C2) 9208 wi::mul (C1, P1) 9209 wi::mul (P1, C2, SIGN, &OVERFLOW) 9210 9211 wi::lshift (P1, C2) 9212 9213 These routines just check whether overflow occurs on any individual 9214coefficient; it is not possible to know at compile time whether the 9215final runtime value would overflow. 9216 9217 9218File: gccint.info, Node: Division of poly_ints, Next: Other poly_int arithmetic, Prev: wi arithmetic on poly_ints, Up: Arithmetic on poly_ints 9219 922010.4.3 Division of 'poly_int's 9221------------------------------ 9222 9223Division of 'poly_int's is possible for certain inputs. The functions 9224for division return true if the operation is possible and in most cases 9225return the results by pointer. The routines are: 9226 9227'multiple_p (A, B)' 9228'multiple_p (A, B, "IENT)' 9229 Return true if A is an exact multiple of B, storing the result in 9230 QUOTIENT if so. There are overloads for various combinations of 9231 polynomial and constant A, B and QUOTIENT. 9232 9233'constant_multiple_p (A, B)' 9234'constant_multiple_p (A, B, "IENT)' 9235 Like 'multiple_p', but also test whether the multiple is a 9236 compile-time constant. 9237 9238'can_div_trunc_p (A, B, "IENT)' 9239'can_div_trunc_p (A, B, "IENT, &REMAINDER)' 9240 Return true if we can calculate 'trunc (A / B)' at compile time, 9241 storing the result in QUOTIENT and REMAINDER if so. 9242 9243'can_div_away_from_zero_p (A, B, "IENT)' 9244 Return true if we can calculate 'A / B' at compile time, rounding 9245 away from zero. Store the result in QUOTIENT if so. 9246 9247 Note that this is true if and only if 'can_div_trunc_p' is true. 9248 The only difference is in the rounding of the result. 9249 9250 There is also an asserting form of division: 9251 9252'exact_div (A, B)' 9253 Assert that A is a multiple of B and return 'A / B'. The result is 9254 a 'poly_int' if A is a 'poly_int'. 9255 9256 9257File: gccint.info, Node: Other poly_int arithmetic, Prev: Division of poly_ints, Up: Arithmetic on poly_ints 9258 925910.4.4 Other 'poly_int' arithmetic 9260---------------------------------- 9261 9262There are tentative routines for other operations besides division: 9263 9264'can_ior_p (A, B, &RESULT)' 9265 Return true if we can calculate 'A | B' at compile time, storing 9266 the result in RESULT if so. 9267 9268 Also, ANDs with a value '(1 << Y) - 1' or its inverse can be treated as 9269alignment operations. *Note Alignment of poly_ints::. 9270 9271 In addition, the following miscellaneous routines are available: 9272 9273'coeff_gcd (A)' 9274 Return the greatest common divisor of all nonzero coefficients in 9275 A, or zero if A is known to be zero. 9276 9277'common_multiple (A, B)' 9278 Return a value that is a multiple of both A and B, where one value 9279 is a 'poly_int' and the other is a scalar. The result will be the 9280 least common multiple for some indeterminate values but not 9281 necessarily for all. 9282 9283'force_common_multiple (A, B)' 9284 Return a value that is a multiple of both 'poly_int' A and 9285 'poly_int' B, asserting that such a value exists. The result will 9286 be the least common multiple for some indeterminate values but not 9287 necessarily for all. 9288 9289 When using this routine, please add a comment explaining why the 9290 assertion is known to hold. 9291 9292 Please add any other operations that you find to be useful. 9293 9294 9295File: gccint.info, Node: Alignment of poly_ints, Next: Computing bounds on poly_ints, Prev: Arithmetic on poly_ints, Up: poly_int 9296 929710.5 Alignment of 'poly_int's 9298============================= 9299 9300'poly_int' provides various routines for aligning values and for 9301querying misalignments. In each case the alignment must be a power of 93022. 9303 9304'can_align_p (VALUE, ALIGN)' 9305 Return true if we can align VALUE up or down to the nearest 9306 multiple of ALIGN at compile time. The answer is the same for both 9307 directions. 9308 9309'can_align_down (VALUE, ALIGN, &ALIGNED)' 9310 Return true if 'can_align_p'; if so, set ALIGNED to the greatest 9311 aligned value that is less than or equal to VALUE. 9312 9313'can_align_up (VALUE, ALIGN, &ALIGNED)' 9314 Return true if 'can_align_p'; if so, set ALIGNED to the lowest 9315 aligned value that is greater than or equal to VALUE. 9316 9317'known_equal_after_align_down (A, B, ALIGN)' 9318 Return true if we can align A and B down to the nearest ALIGN 9319 boundary at compile time and if the two results are equal. 9320 9321'known_equal_after_align_up (A, B, ALIGN)' 9322 Return true if we can align A and B up to the nearest ALIGN 9323 boundary at compile time and if the two results are equal. 9324 9325'aligned_lower_bound (VALUE, ALIGN)' 9326 Return a result that is no greater than VALUE and that is aligned 9327 to ALIGN. The result will the closest aligned value for some 9328 indeterminate values but not necessarily for all. 9329 9330 For example, suppose we are allocating an object of SIZE bytes in a 9331 downward-growing stack whose current limit is given by LIMIT. If 9332 the object requires ALIGN bytes of alignment, the new stack limit 9333 is given by: 9334 9335 aligned_lower_bound (LIMIT - SIZE, ALIGN) 9336 9337'aligned_upper_bound (VALUE, ALIGN)' 9338 Likewise return a result that is no less than VALUE and that is 9339 aligned to ALIGN. This is the routine that would be used for 9340 upward-growing stacks in the scenario just described. 9341 9342'known_misalignment (VALUE, ALIGN, &MISALIGN)' 9343 Return true if we can calculate the misalignment of VALUE with 9344 respect to ALIGN at compile time, storing the result in MISALIGN if 9345 so. 9346 9347'known_alignment (VALUE)' 9348 Return the minimum alignment that VALUE is known to have (in other 9349 words, the largest alignment that can be guaranteed whatever the 9350 values of the indeterminates turn out to be). Return 0 if VALUE is 9351 known to be 0. 9352 9353'force_align_down (VALUE, ALIGN)' 9354 Assert that VALUE can be aligned down to ALIGN at compile time and 9355 return the result. When using this routine, please add a comment 9356 explaining why the assertion is known to hold. 9357 9358'force_align_up (VALUE, ALIGN)' 9359 Likewise, but aligning up. 9360 9361'force_align_down_and_div (VALUE, ALIGN)' 9362 Divide the result of 'force_align_down' by ALIGN. Again, please 9363 add a comment explaining why the assertion in 'force_align_down' is 9364 known to hold. 9365 9366'force_align_up_and_div (VALUE, ALIGN)' 9367 Likewise for 'force_align_up'. 9368 9369'force_get_misalignment (VALUE, ALIGN)' 9370 Assert that we can calculate the misalignment of VALUE with respect 9371 to ALIGN at compile time and return the misalignment. When using 9372 this function, please add a comment explaining why the assertion is 9373 known to hold. 9374 9375 9376File: gccint.info, Node: Computing bounds on poly_ints, Next: Converting poly_ints, Prev: Alignment of poly_ints, Up: poly_int 9377 937810.6 Computing bounds on 'poly_int's 9379==================================== 9380 9381'poly_int' also provides routines for calculating lower and upper 9382bounds: 9383 9384'constant_lower_bound (A)' 9385 Assert that A is nonnegative and return the smallest value it can 9386 have. 9387 9388'constant_lower_bound_with_limit (A, B)' 9389 Return the least value A can have, given that the context in which 9390 A appears guarantees that the answer is no less than B. In other 9391 words, the caller is asserting that A is greater than or equal to B 9392 even if 'known_ge (A, B)' doesn't hold. 9393 9394'constant_upper_bound_with_limit (A, B)' 9395 Return the greatest value A can have, given that the context in 9396 which A appears guarantees that the answer is no greater than B. 9397 In other words, the caller is asserting that A is less than or 9398 equal to B even if 'known_le (A, B)' doesn't hold. 9399 9400'lower_bound (A, B)' 9401 Return a value that is always less than or equal to both A and B. 9402 It will be the greatest such value for some indeterminate values 9403 but necessarily for all. 9404 9405'upper_bound (A, B)' 9406 Return a value that is always greater than or equal to both A and 9407 B. It will be the least such value for some indeterminate values 9408 but necessarily for all. 9409 9410 9411File: gccint.info, Node: Converting poly_ints, Next: Miscellaneous poly_int routines, Prev: Computing bounds on poly_ints, Up: poly_int 9412 941310.7 Converting 'poly_int's 9414=========================== 9415 9416A 'poly_int<N, T>' can be constructed from up to N individual T 9417coefficients, with the remaining coefficients being implicitly zero. In 9418particular, this means that every 'poly_int<N, T>' can be constructed 9419from a single scalar T, or something compatible with T. 9420 9421 Also, a 'poly_int<N, T>' can be constructed from a 'poly_int<N, U>' if 9422T can be constructed from U. 9423 9424 The following functions provide other forms of conversion, or test 9425whether such a conversion would succeed. 9426 9427'VALUE.is_constant ()' 9428 Return true if 'poly_int' VALUE is a compile-time constant. 9429 9430'VALUE.is_constant (&C1)' 9431 Return true if 'poly_int' VALUE is a compile-time constant, storing 9432 it in C1 if so. C1 must be able to hold all constant values of 9433 VALUE without loss of precision. 9434 9435'VALUE.to_constant ()' 9436 Assert that VALUE is a compile-time constant and return its value. 9437 When using this function, please add a comment explaining why the 9438 condition is known to hold (for example, because an earlier phase 9439 of analysis rejected non-constants). 9440 9441'VALUE.to_shwi (&P2)' 9442 Return true if 'poly_int<N, T>' VALUE can be represented without 9443 loss of precision as a 'poly_int<N, 'HOST_WIDE_INT'>', storing it 9444 in that form in P2 if so. 9445 9446'VALUE.to_uhwi (&P2)' 9447 Return true if 'poly_int<N, T>' VALUE can be represented without 9448 loss of precision as a 'poly_int<N, 'unsigned HOST_WIDE_INT'>', 9449 storing it in that form in P2 if so. 9450 9451'VALUE.force_shwi ()' 9452 Forcibly convert each coefficient of 'poly_int<N, T>' VALUE to 9453 'HOST_WIDE_INT', truncating any that are out of range. Return the 9454 result as a 'poly_int<N, 'HOST_WIDE_INT'>'. 9455 9456'VALUE.force_uhwi ()' 9457 Forcibly convert each coefficient of 'poly_int<N, T>' VALUE to 9458 'unsigned HOST_WIDE_INT', truncating any that are out of range. 9459 Return the result as a 'poly_int<N, 'unsigned HOST_WIDE_INT'>'. 9460 9461'wi::shwi (VALUE, PRECISION)' 9462 Return a 'poly_int' with the same value as VALUE, but with the 9463 coefficients converted from 'HOST_WIDE_INT' to 'wide_int'. 9464 PRECISION specifies the precision of the 'wide_int' cofficients; if 9465 this is wider than a 'HOST_WIDE_INT', the coefficients of VALUE 9466 will be sign-extended to fit. 9467 9468'wi::uhwi (VALUE, PRECISION)' 9469 Like 'wi::shwi', except that VALUE has coefficients of type 9470 'unsigned HOST_WIDE_INT'. If PRECISION is wider than a 9471 'HOST_WIDE_INT', the coefficients of VALUE will be zero-extended to 9472 fit. 9473 9474'wi::sext (VALUE, PRECISION)' 9475 Return a 'poly_int' of the same type as VALUE, sign-extending every 9476 coefficient from the low PRECISION bits. This in effect applies 9477 'wi::sext' to each coefficient individually. 9478 9479'wi::zext (VALUE, PRECISION)' 9480 Like 'wi::sext', but for zero extension. 9481 9482'poly_wide_int::from (VALUE, PRECISION, SIGN)' 9483 Convert VALUE to a 'poly_wide_int' in which each coefficient has 9484 PRECISION bits. Extend the coefficients according to SIGN if the 9485 coefficients have fewer bits. 9486 9487'poly_offset_int::from (VALUE, SIGN)' 9488 Convert VALUE to a 'poly_offset_int', extending its coefficients 9489 according to SIGN if they have fewer bits than 'offset_int'. 9490 9491'poly_widest_int::from (VALUE, SIGN)' 9492 Convert VALUE to a 'poly_widest_int', extending its coefficients 9493 according to SIGN if they have fewer bits than 'widest_int'. 9494 9495 9496File: gccint.info, Node: Miscellaneous poly_int routines, Next: Guidelines for using poly_int, Prev: Converting poly_ints, Up: poly_int 9497 949810.8 Miscellaneous 'poly_int' routines 9499====================================== 9500 9501'print_dec (VALUE, FILE, SIGN)' 9502'print_dec (VALUE, FILE)' 9503 Print VALUE to FILE as a decimal value, interpreting the 9504 coefficients according to SIGN. The final argument is optional if 9505 VALUE has an inherent sign; for example, 'poly_int64' values print 9506 as signed by default and 'poly_uint64' values print as unsigned by 9507 default. 9508 9509 This is a simply a 'poly_int' version of a wide-int routine. 9510 9511 9512File: gccint.info, Node: Guidelines for using poly_int, Prev: Miscellaneous poly_int routines, Up: poly_int 9513 951410.9 Guidelines for using 'poly_int' 9515==================================== 9516 9517One of the main design goals of 'poly_int' was to make it easy to write 9518target-independent code that handles variable-sized registers even when 9519the current target has fixed-sized registers. There are two aspects to 9520this: 9521 9522 * The set of 'poly_int' operations should be complete enough that the 9523 question in most cases becomes "Can we do this operation on these 9524 particular 'poly_int' values? If not, bail out" rather than "Are 9525 these 'poly_int' values constant? If so, do the operation, 9526 otherwise bail out". 9527 9528 * If target-independent code compiles and runs correctly on a target 9529 with one value of 'NUM_POLY_INT_COEFFS', and if the code does not 9530 use asserting functions like 'to_constant', it is reasonable to 9531 assume that the code also works on targets with other values of 9532 'NUM_POLY_INT_COEFFS'. There is no need to check this during 9533 everyday development. 9534 9535 So the general principle is: if target-independent code is dealing with 9536a 'poly_int' value, it is better to operate on it as a 'poly_int' if at 9537all possible, choosing conservatively-correct behavior if a particular 9538operation fails. For example, the following code handles an index 'pos' 9539into a sequence of vectors that each have 'nunits' elements: 9540 9541 /* Calculate which vector contains the result, and which lane of 9542 that vector we need. */ 9543 if (!can_div_trunc_p (pos, nunits, &vec_entry, &vec_index)) 9544 { 9545 if (dump_enabled_p ()) 9546 dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, 9547 "Cannot determine which vector holds the" 9548 " final result.\n"); 9549 return false; 9550 } 9551 9552 However, there are some contexts in which operating on a 'poly_int' is 9553not possible or does not make sense. One example is when handling 9554static initializers, since no current target supports the concept of a 9555variable-length static initializer. In these situations, a reasonable 9556fallback is: 9557 9558 if (POLY_VALUE.is_constant (&CONST_VALUE)) 9559 { 9560 ... 9561 /* Operate on CONST_VALUE. */ 9562 ... 9563 } 9564 else 9565 { 9566 ... 9567 /* Conservatively correct fallback. */ 9568 ... 9569 } 9570 9571 'poly_int' also provides some asserting functions like 'to_constant'. 9572Please only use these functions if there is a good theoretical reason to 9573believe that the assertion cannot fire. For example, if some work is 9574divided into an analysis phase and an implementation phase, the analysis 9575phase might reject inputs that are not 'is_constant', in which case the 9576implementation phase can reasonably use 'to_constant' on the remaining 9577inputs. The assertions should not be used to discover whether a 9578condition ever occurs "in the field"; in other words, they should not be 9579used to restrict code to constants at first, with the intention of only 9580implementing a 'poly_int' version if a user hits the assertion. 9581 9582 If a particular asserting function like 'to_constant' is needed more 9583than once for the same reason, it is probably worth adding a helper 9584function or macro for that situation, so that the justification only 9585needs to be given once. For example: 9586 9587 /* Return the size of an element in a vector of size SIZE, given that 9588 the vector has NELTS elements. The return value is in the same units 9589 as SIZE (either bits or bytes). 9590 9591 to_constant () is safe in this situation because vector elements are 9592 always constant-sized scalars. */ 9593 #define vector_element_size(SIZE, NELTS) \ 9594 (exact_div (SIZE, NELTS).to_constant ()) 9595 9596 Target-specific code in 'config/CPU' only needs to handle non-constant 9597'poly_int's if 'NUM_POLY_INT_COEFFS' is greater than one. For other 9598targets, 'poly_int' degenerates to a compile-time constant and is often 9599interchangable with a normal scalar integer. There are two main 9600exceptions: 9601 9602 * Sometimes an explicit cast to an integer type might be needed, such 9603 as to resolve ambiguities in a '?:' expression, or when passing 9604 values through '...' to things like print functions. 9605 9606 * Target macros are included in target-independent code and so do not 9607 have access to the implicit conversion to a scalar integer. If 9608 this becomes a problem for a particular target macro, the possible 9609 solutions, in order of preference, are: 9610 9611 * Convert the target macro to a target hook (for all targets). 9612 9613 * Put the target's implementation of the target macro in its 9614 'CPU.c' file and call it from the target macro in the 'CPU.h' 9615 file. 9616 9617 * Add 'to_constant ()' calls where necessary. The previous 9618 option is preferable because it will help with any future 9619 conversion of the macro to a hook. 9620 9621 9622File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: poly_int, Up: Top 9623 962411 GENERIC 9625********** 9626 9627The purpose of GENERIC is simply to provide a language-independent way 9628of representing an entire function in trees. To this end, it was 9629necessary to add a few new tree codes to the back end, but almost 9630everything was already there. If you can express it with the codes in 9631'gcc/tree.def', it's GENERIC. 9632 9633 Early on, there was a great deal of debate about how to think about 9634statements in a tree IL. In GENERIC, a statement is defined as any 9635expression whose value, if any, is ignored. A statement will always 9636have 'TREE_SIDE_EFFECTS' set (or it will be discarded), but a 9637non-statement expression may also have side effects. A 'CALL_EXPR', for 9638instance. 9639 9640 It would be possible for some local optimizations to work on the 9641GENERIC form of a function; indeed, the adapted tree inliner works fine 9642on GENERIC, but the current compiler performs inlining after lowering to 9643GIMPLE (a restricted form described in the next section). Indeed, 9644currently the frontends perform this lowering before handing off to 9645'tree_rest_of_compilation', but this seems inelegant. 9646 9647* Menu: 9648 9649* Deficiencies:: Topics net yet covered in this document. 9650* Tree overview:: All about 'tree's. 9651* Types:: Fundamental and aggregate types. 9652* Declarations:: Type declarations and variables. 9653* Attributes:: Declaration and type attributes. 9654* Expressions: Expression trees. Operating on data. 9655* Statements:: Control flow and related trees. 9656* Functions:: Function bodies, linkage, and other aspects. 9657* Language-dependent trees:: Topics and trees specific to language front ends. 9658* C and C++ Trees:: Trees specific to C and C++. 9659 9660 9661File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 9662 966311.1 Deficiencies 9664================= 9665 9666There are many places in which this document is incomplet and incorrekt. 9667It is, as of yet, only _preliminary_ documentation. 9668 9669 9670File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 9671 967211.2 Overview 9673============= 9674 9675The central data structure used by the internal representation is the 9676'tree'. These nodes, while all of the C type 'tree', are of many 9677varieties. A 'tree' is a pointer type, but the object to which it 9678points may be of a variety of types. From this point forward, we will 9679refer to trees in ordinary type, rather than in 'this font', except when 9680talking about the actual C type 'tree'. 9681 9682 You can tell what kind of node a particular tree is by using the 9683'TREE_CODE' macro. Many, many macros take trees as input and return 9684trees as output. However, most macros require a certain kind of tree 9685node as input. In other words, there is a type-system for trees, but it 9686is not reflected in the C type-system. 9687 9688 For safety, it is useful to configure GCC with '--enable-checking'. 9689Although this results in a significant performance penalty (since all 9690tree types are checked at run-time), and is therefore inappropriate in a 9691release version, it is extremely helpful during the development process. 9692 9693 Many macros behave as predicates. Many, although not all, of these 9694predicates end in '_P'. Do not rely on the result type of these macros 9695being of any particular type. You may, however, rely on the fact that 9696the type can be compared to '0', so that statements like 9697 if (TEST_P (t) && !TEST_P (y)) 9698 x = 1; 9699and 9700 int i = (TEST_P (t) != 0); 9701are legal. Macros that return 'int' values now may be changed to return 9702'tree' values, or other pointers in the future. Even those that 9703continue to return 'int' may return multiple nonzero codes where 9704previously they returned only zero and one. Therefore, you should not 9705write code like 9706 if (TEST_P (t) == 1) 9707as this code is not guaranteed to work correctly in the future. 9708 9709 You should not take the address of values returned by the macros or 9710functions described here. In particular, no guarantee is given that the 9711values are lvalues. 9712 9713 In general, the names of macros are all in uppercase, while the names 9714of functions are entirely in lowercase. There are rare exceptions to 9715this rule. You should assume that any macro or function whose name is 9716made up entirely of uppercase letters may evaluate its arguments more 9717than once. You may assume that a macro or function whose name is made 9718up entirely of lowercase letters will evaluate its arguments only once. 9719 9720 The 'error_mark_node' is a special tree. Its tree code is 9721'ERROR_MARK', but since there is only ever one node with that code, the 9722usual practice is to compare the tree against 'error_mark_node'. (This 9723test is just a test for pointer equality.) If an error has occurred 9724during front-end processing the flag 'errorcount' will be set. If the 9725front end has encountered code it cannot handle, it will issue a message 9726to the user and set 'sorrycount'. When these flags are set, any macro 9727or function which normally returns a tree of a particular kind may 9728instead return the 'error_mark_node'. Thus, if you intend to do any 9729processing of erroneous code, you must be prepared to deal with the 9730'error_mark_node'. 9731 9732 Occasionally, a particular tree slot (like an operand to an expression, 9733or a particular field in a declaration) will be referred to as "reserved 9734for the back end". These slots are used to store RTL when the tree is 9735converted to RTL for use by the GCC back end. However, if that process 9736is not taking place (e.g., if the front end is being hooked up to an 9737intelligent editor), then those slots may be used by the back end 9738presently in use. 9739 9740 If you encounter situations that do not match this documentation, such 9741as tree nodes of types not mentioned here, or macros documented to 9742return entities of a particular kind that instead return entities of 9743some different kind, you have found a bug, either in the front end or in 9744the documentation. Please report these bugs as you would any other bug. 9745 9746* Menu: 9747 9748* Macros and Functions::Macros and functions that can be used with all trees. 9749* Identifiers:: The names of things. 9750* Containers:: Lists and vectors. 9751 9752 9753File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 9754 975511.2.1 Trees 9756------------ 9757 9758All GENERIC trees have two fields in common. First, 'TREE_CHAIN' is a 9759pointer that can be used as a singly-linked list to other trees. The 9760other is 'TREE_TYPE'. Many trees store the type of an expression or 9761declaration in this field. 9762 9763 These are some other functions for handling trees: 9764 9765'tree_size' 9766 Return the number of bytes a tree takes. 9767 9768'build0' 9769'build1' 9770'build2' 9771'build3' 9772'build4' 9773'build5' 9774'build6' 9775 9776 These functions build a tree and supply values to put in each 9777 parameter. The basic signature is 'code, type, [operands]'. 9778 'code' is the 'TREE_CODE', and 'type' is a tree representing the 9779 'TREE_TYPE'. These are followed by the operands, each of which is 9780 also a tree. 9781 9782 9783File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 9784 978511.2.2 Identifiers 9786------------------ 9787 9788An 'IDENTIFIER_NODE' represents a slightly more general concept than the 9789standard C or C++ concept of identifier. In particular, an 9790'IDENTIFIER_NODE' may contain a '$', or other extraordinary characters. 9791 9792 There are never two distinct 'IDENTIFIER_NODE's representing the same 9793identifier. Therefore, you may use pointer equality to compare 9794'IDENTIFIER_NODE's, rather than using a routine like 'strcmp'. Use 9795'get_identifier' to obtain the unique 'IDENTIFIER_NODE' for a supplied 9796string. 9797 9798 You can use the following macros to access identifiers: 9799'IDENTIFIER_POINTER' 9800 The string represented by the identifier, represented as a 'char*'. 9801 This string is always 'NUL'-terminated, and contains no embedded 9802 'NUL' characters. 9803 9804'IDENTIFIER_LENGTH' 9805 The length of the string returned by 'IDENTIFIER_POINTER', not 9806 including the trailing 'NUL'. This value of 'IDENTIFIER_LENGTH 9807 (x)' is always the same as 'strlen (IDENTIFIER_POINTER (x))'. 9808 9809'IDENTIFIER_OPNAME_P' 9810 This predicate holds if the identifier represents the name of an 9811 overloaded operator. In this case, you should not depend on the 9812 contents of either the 'IDENTIFIER_POINTER' or the 9813 'IDENTIFIER_LENGTH'. 9814 9815'IDENTIFIER_TYPENAME_P' 9816 This predicate holds if the identifier represents the name of a 9817 user-defined conversion operator. In this case, the 'TREE_TYPE' of 9818 the 'IDENTIFIER_NODE' holds the type to which the conversion 9819 operator converts. 9820 9821 9822File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 9823 982411.2.3 Containers 9825----------------- 9826 9827Two common container data structures can be represented directly with 9828tree nodes. A 'TREE_LIST' is a singly linked list containing two trees 9829per node. These are the 'TREE_PURPOSE' and 'TREE_VALUE' of each node. 9830(Often, the 'TREE_PURPOSE' contains some kind of tag, or additional 9831information, while the 'TREE_VALUE' contains the majority of the 9832payload. In other cases, the 'TREE_PURPOSE' is simply 'NULL_TREE', 9833while in still others both the 'TREE_PURPOSE' and 'TREE_VALUE' are of 9834equal stature.) Given one 'TREE_LIST' node, the next node is found by 9835following the 'TREE_CHAIN'. If the 'TREE_CHAIN' is 'NULL_TREE', then 9836you have reached the end of the list. 9837 9838 A 'TREE_VEC' is a simple vector. The 'TREE_VEC_LENGTH' is an integer 9839(not a tree) giving the number of nodes in the vector. The nodes 9840themselves are accessed using the 'TREE_VEC_ELT' macro, which takes two 9841arguments. The first is the 'TREE_VEC' in question; the second is an 9842integer indicating which element in the vector is desired. The elements 9843are indexed from zero. 9844 9845 9846File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 9847 984811.3 Types 9849========== 9850 9851All types have corresponding tree nodes. However, you should not assume 9852that there is exactly one tree node corresponding to each type. There 9853are often multiple nodes corresponding to the same type. 9854 9855 For the most part, different kinds of types have different tree codes. 9856(For example, pointer types use a 'POINTER_TYPE' code while arrays use 9857an 'ARRAY_TYPE' code.) However, pointers to member functions use the 9858'RECORD_TYPE' code. Therefore, when writing a 'switch' statement that 9859depends on the code associated with a particular type, you should take 9860care to handle pointers to member functions under the 'RECORD_TYPE' case 9861label. 9862 9863 The following functions and macros deal with cv-qualification of types: 9864'TYPE_MAIN_VARIANT' 9865 This macro returns the unqualified version of a type. It may be 9866 applied to an unqualified type, but it is not always the identity 9867 function in that case. 9868 9869 A few other macros and functions are usable with all types: 9870'TYPE_SIZE' 9871 The number of bits required to represent the type, represented as 9872 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 9873 'NULL_TREE'. 9874 9875'TYPE_ALIGN' 9876 The alignment of the type, in bits, represented as an 'int'. 9877 9878'TYPE_NAME' 9879 This macro returns a declaration (in the form of a 'TYPE_DECL') for 9880 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 9881 as you might expect, given its name!) You can look at the 9882 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 9883 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 9884 built-in type, the result of a typedef, or a named class type. 9885 9886'TYPE_CANONICAL' 9887 This macro returns the "canonical" type for the given type node. 9888 Canonical types are used to improve performance in the C++ and 9889 Objective-C++ front ends by allowing efficient comparison between 9890 two type nodes in 'same_type_p': if the 'TYPE_CANONICAL' values of 9891 the types are equal, the types are equivalent; otherwise, the types 9892 are not equivalent. The notion of equivalence for canonical types 9893 is the same as the notion of type equivalence in the language 9894 itself. For instance, 9895 9896 When 'TYPE_CANONICAL' is 'NULL_TREE', there is no canonical type 9897 for the given type node. In this case, comparison between this 9898 type and any other type requires the compiler to perform a deep, 9899 "structural" comparison to see if the two type nodes have the same 9900 form and properties. 9901 9902 The canonical type for a node is always the most fundamental type 9903 in the equivalence class of types. For instance, 'int' is its own 9904 canonical type. A typedef 'I' of 'int' will have 'int' as its 9905 canonical type. Similarly, 'I*' and a typedef 'IP' (defined to 9906 'I*') will has 'int*' as their canonical type. When building a new 9907 type node, be sure to set 'TYPE_CANONICAL' to the appropriate 9908 canonical type. If the new type is a compound type (built from 9909 other types), and any of those other types require structural 9910 equality, use 'SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the new 9911 type also requires structural equality. Finally, if for some 9912 reason you cannot guarantee that 'TYPE_CANONICAL' will point to the 9913 canonical type, use 'SET_TYPE_STRUCTURAL_EQUALITY' to make sure 9914 that the new type-and any type constructed based on it-requires 9915 structural equality. If you suspect that the canonical type system 9916 is miscomparing types, pass '--param verify-canonical-types=1' to 9917 the compiler or configure with '--enable-checking' to force the 9918 compiler to verify its canonical-type comparisons against the 9919 structural comparisons; the compiler will then print any warnings 9920 if the canonical types miscompare. 9921 9922'TYPE_STRUCTURAL_EQUALITY_P' 9923 This predicate holds when the node requires structural equality 9924 checks, e.g., when 'TYPE_CANONICAL' is 'NULL_TREE'. 9925 9926'SET_TYPE_STRUCTURAL_EQUALITY' 9927 This macro states that the type node it is given requires 9928 structural equality checks, e.g., it sets 'TYPE_CANONICAL' to 9929 'NULL_TREE'. 9930 9931'same_type_p' 9932 This predicate takes two types as input, and holds if they are the 9933 same type. For example, if one type is a 'typedef' for the other, 9934 or both are 'typedef's for the same type. This predicate also 9935 holds if the two trees given as input are simply copies of one 9936 another; i.e., there is no difference between them at the source 9937 level, but, for whatever reason, a duplicate has been made in the 9938 representation. You should never use '==' (pointer equality) to 9939 compare types; always use 'same_type_p' instead. 9940 9941 Detailed below are the various kinds of types, and the macros that can 9942be used to access them. Although other kinds of types are used 9943elsewhere in G++, the types described here are the only ones that you 9944will encounter while examining the intermediate representation. 9945 9946'VOID_TYPE' 9947 Used to represent the 'void' type. 9948 9949'INTEGER_TYPE' 9950 Used to represent the various integral types, including 'char', 9951 'short', 'int', 'long', and 'long long'. This code is not used for 9952 enumeration types, nor for the 'bool' type. The 'TYPE_PRECISION' 9953 is the number of bits used in the representation, represented as an 9954 'unsigned int'. (Note that in the general case this is not the 9955 same value as 'TYPE_SIZE'; suppose that there were a 24-bit integer 9956 type, but that alignment requirements for the ABI required 32-bit 9957 alignment. Then, 'TYPE_SIZE' would be an 'INTEGER_CST' for 32, 9958 while 'TYPE_PRECISION' would be 24.) The integer type is unsigned 9959 if 'TYPE_UNSIGNED' holds; otherwise, it is signed. 9960 9961 The 'TYPE_MIN_VALUE' is an 'INTEGER_CST' for the smallest integer 9962 that may be represented by this type. Similarly, the 9963 'TYPE_MAX_VALUE' is an 'INTEGER_CST' for the largest integer that 9964 may be represented by this type. 9965 9966'REAL_TYPE' 9967 Used to represent the 'float', 'double', and 'long double' types. 9968 The number of bits in the floating-point representation is given by 9969 'TYPE_PRECISION', as in the 'INTEGER_TYPE' case. 9970 9971'FIXED_POINT_TYPE' 9972 Used to represent the 'short _Fract', '_Fract', 'long _Fract', 9973 'long long _Fract', 'short _Accum', '_Accum', 'long _Accum', and 9974 'long long _Accum' types. The number of bits in the fixed-point 9975 representation is given by 'TYPE_PRECISION', as in the 9976 'INTEGER_TYPE' case. There may be padding bits, fractional bits 9977 and integral bits. The number of fractional bits is given by 9978 'TYPE_FBIT', and the number of integral bits is given by 9979 'TYPE_IBIT'. The fixed-point type is unsigned if 'TYPE_UNSIGNED' 9980 holds; otherwise, it is signed. The fixed-point type is saturating 9981 if 'TYPE_SATURATING' holds; otherwise, it is not saturating. 9982 9983'COMPLEX_TYPE' 9984 Used to represent GCC built-in '__complex__' data types. The 9985 'TREE_TYPE' is the type of the real and imaginary parts. 9986 9987'ENUMERAL_TYPE' 9988 Used to represent an enumeration type. The 'TYPE_PRECISION' gives 9989 (as an 'int'), the number of bits used to represent the type. If 9990 there are no negative enumeration constants, 'TYPE_UNSIGNED' will 9991 hold. The minimum and maximum enumeration constants may be 9992 obtained with 'TYPE_MIN_VALUE' and 'TYPE_MAX_VALUE', respectively; 9993 each of these macros returns an 'INTEGER_CST'. 9994 9995 The actual enumeration constants themselves may be obtained by 9996 looking at the 'TYPE_VALUES'. This macro will return a 9997 'TREE_LIST', containing the constants. The 'TREE_PURPOSE' of each 9998 node will be an 'IDENTIFIER_NODE' giving the name of the constant; 9999 the 'TREE_VALUE' will be an 'INTEGER_CST' giving the value assigned 10000 to that constant. These constants will appear in the order in 10001 which they were declared. The 'TREE_TYPE' of each of these 10002 constants will be the type of enumeration type itself. 10003 10004'BOOLEAN_TYPE' 10005 Used to represent the 'bool' type. 10006 10007'POINTER_TYPE' 10008 Used to represent pointer types, and pointer to data member types. 10009 The 'TREE_TYPE' gives the type to which this type points. 10010 10011'REFERENCE_TYPE' 10012 Used to represent reference types. The 'TREE_TYPE' gives the type 10013 to which this type refers. 10014 10015'FUNCTION_TYPE' 10016 Used to represent the type of non-member functions and of static 10017 member functions. The 'TREE_TYPE' gives the return type of the 10018 function. The 'TYPE_ARG_TYPES' are a 'TREE_LIST' of the argument 10019 types. The 'TREE_VALUE' of each node in this list is the type of 10020 the corresponding argument; the 'TREE_PURPOSE' is an expression for 10021 the default argument value, if any. If the last node in the list 10022 is 'void_list_node' (a 'TREE_LIST' node whose 'TREE_VALUE' is the 10023 'void_type_node'), then functions of this type do not take variable 10024 arguments. Otherwise, they do take a variable number of arguments. 10025 10026 Note that in C (but not in C++) a function declared like 'void f()' 10027 is an unprototyped function taking a variable number of arguments; 10028 the 'TYPE_ARG_TYPES' of such a function will be 'NULL'. 10029 10030'METHOD_TYPE' 10031 Used to represent the type of a non-static member function. Like a 10032 'FUNCTION_TYPE', the return type is given by the 'TREE_TYPE'. The 10033 type of '*this', i.e., the class of which functions of this type 10034 are a member, is given by the 'TYPE_METHOD_BASETYPE'. The 10035 'TYPE_ARG_TYPES' is the parameter list, as for a 'FUNCTION_TYPE', 10036 and includes the 'this' argument. 10037 10038'ARRAY_TYPE' 10039 Used to represent array types. The 'TREE_TYPE' gives the type of 10040 the elements in the array. If the array-bound is present in the 10041 type, the 'TYPE_DOMAIN' is an 'INTEGER_TYPE' whose 'TYPE_MIN_VALUE' 10042 and 'TYPE_MAX_VALUE' will be the lower and upper bounds of the 10043 array, respectively. The 'TYPE_MIN_VALUE' will always be an 10044 'INTEGER_CST' for zero, while the 'TYPE_MAX_VALUE' will be one less 10045 than the number of elements in the array, i.e., the highest value 10046 which may be used to index an element in the array. 10047 10048'RECORD_TYPE' 10049 Used to represent 'struct' and 'class' types, as well as pointers 10050 to member functions and similar constructs in other languages. 10051 'TYPE_FIELDS' contains the items contained in this type, each of 10052 which can be a 'FIELD_DECL', 'VAR_DECL', 'CONST_DECL', or 10053 'TYPE_DECL'. You may not make any assumptions about the ordering 10054 of the fields in the type or whether one or more of them overlap. 10055 10056'UNION_TYPE' 10057 Used to represent 'union' types. Similar to 'RECORD_TYPE' except 10058 that all 'FIELD_DECL' nodes in 'TYPE_FIELD' start at bit position 10059 zero. 10060 10061'QUAL_UNION_TYPE' 10062 Used to represent part of a variant record in Ada. Similar to 10063 'UNION_TYPE' except that each 'FIELD_DECL' has a 'DECL_QUALIFIER' 10064 field, which contains a boolean expression that indicates whether 10065 the field is present in the object. The type will only have one 10066 field, so each field's 'DECL_QUALIFIER' is only evaluated if none 10067 of the expressions in the previous fields in 'TYPE_FIELDS' are 10068 nonzero. Normally these expressions will reference a field in the 10069 outer object using a 'PLACEHOLDER_EXPR'. 10070 10071'LANG_TYPE' 10072 This node is used to represent a language-specific type. The front 10073 end must handle it. 10074 10075'OFFSET_TYPE' 10076 This node is used to represent a pointer-to-data member. For a 10077 data member 'X::m' the 'TYPE_OFFSET_BASETYPE' is 'X' and the 10078 'TREE_TYPE' is the type of 'm'. 10079 10080 There are variables whose values represent some of the basic types. 10081These include: 10082'void_type_node' 10083 A node for 'void'. 10084 10085'integer_type_node' 10086 A node for 'int'. 10087 10088'unsigned_type_node.' 10089 A node for 'unsigned int'. 10090 10091'char_type_node.' 10092 A node for 'char'. 10093It may sometimes be useful to compare one of these variables with a type 10094in hand, using 'same_type_p'. 10095 10096 10097File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 10098 1009911.4 Declarations 10100================= 10101 10102This section covers the various kinds of declarations that appear in the 10103internal representation, except for declarations of functions 10104(represented by 'FUNCTION_DECL' nodes), which are described in *note 10105Functions::. 10106 10107* Menu: 10108 10109* Working with declarations:: Macros and functions that work on 10110declarations. 10111* Internal structure:: How declaration nodes are represented. 10112 10113 10114File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 10115 1011611.4.1 Working with declarations 10117-------------------------------- 10118 10119Some macros can be used with any kind of declaration. These include: 10120'DECL_NAME' 10121 This macro returns an 'IDENTIFIER_NODE' giving the name of the 10122 entity. 10123 10124'TREE_TYPE' 10125 This macro returns the type of the entity declared. 10126 10127'EXPR_FILENAME' 10128 This macro returns the name of the file in which the entity was 10129 declared, as a 'char*'. For an entity declared implicitly by the 10130 compiler (like '__builtin_memcpy'), this will be the string 10131 '"<internal>"'. 10132 10133'EXPR_LINENO' 10134 This macro returns the line number at which the entity was 10135 declared, as an 'int'. 10136 10137'DECL_ARTIFICIAL' 10138 This predicate holds if the declaration was implicitly generated by 10139 the compiler. For example, this predicate will hold of an 10140 implicitly declared member function, or of the 'TYPE_DECL' 10141 implicitly generated for a class type. Recall that in C++ code 10142 like: 10143 struct S {}; 10144 is roughly equivalent to C code like: 10145 struct S {}; 10146 typedef struct S S; 10147 The implicitly generated 'typedef' declaration is represented by a 10148 'TYPE_DECL' for which 'DECL_ARTIFICIAL' holds. 10149 10150 The various kinds of declarations include: 10151'LABEL_DECL' 10152 These nodes are used to represent labels in function bodies. For 10153 more information, see *note Functions::. These nodes only appear 10154 in block scopes. 10155 10156'CONST_DECL' 10157 These nodes are used to represent enumeration constants. The value 10158 of the constant is given by 'DECL_INITIAL' which will be an 10159 'INTEGER_CST' with the same type as the 'TREE_TYPE' of the 10160 'CONST_DECL', i.e., an 'ENUMERAL_TYPE'. 10161 10162'RESULT_DECL' 10163 These nodes represent the value returned by a function. When a 10164 value is assigned to a 'RESULT_DECL', that indicates that the value 10165 should be returned, via bitwise copy, by the function. You can use 10166 'DECL_SIZE' and 'DECL_ALIGN' on a 'RESULT_DECL', just as with a 10167 'VAR_DECL'. 10168 10169'TYPE_DECL' 10170 These nodes represent 'typedef' declarations. The 'TREE_TYPE' is 10171 the type declared to have the name given by 'DECL_NAME'. In some 10172 cases, there is no associated name. 10173 10174'VAR_DECL' 10175 These nodes represent variables with namespace or block scope, as 10176 well as static data members. The 'DECL_SIZE' and 'DECL_ALIGN' are 10177 analogous to 'TYPE_SIZE' and 'TYPE_ALIGN'. For a declaration, you 10178 should always use the 'DECL_SIZE' and 'DECL_ALIGN' rather than the 10179 'TYPE_SIZE' and 'TYPE_ALIGN' given by the 'TREE_TYPE', since 10180 special attributes may have been applied to the variable to give it 10181 a particular size and alignment. You may use the predicates 10182 'DECL_THIS_STATIC' or 'DECL_THIS_EXTERN' to test whether the 10183 storage class specifiers 'static' or 'extern' were used to declare 10184 a variable. 10185 10186 If this variable is initialized (but does not require a 10187 constructor), the 'DECL_INITIAL' will be an expression for the 10188 initializer. The initializer should be evaluated, and a bitwise 10189 copy into the variable performed. If the 'DECL_INITIAL' is the 10190 'error_mark_node', there is an initializer, but it is given by an 10191 explicit statement later in the code; no bitwise copy is required. 10192 10193 GCC provides an extension that allows either automatic variables, 10194 or global variables, to be placed in particular registers. This 10195 extension is being used for a particular 'VAR_DECL' if 10196 'DECL_REGISTER' holds for the 'VAR_DECL', and if 10197 'DECL_ASSEMBLER_NAME' is not equal to 'DECL_NAME'. In that case, 10198 'DECL_ASSEMBLER_NAME' is the name of the register into which the 10199 variable will be placed. 10200 10201'PARM_DECL' 10202 Used to represent a parameter to a function. Treat these nodes 10203 similarly to 'VAR_DECL' nodes. These nodes only appear in the 10204 'DECL_ARGUMENTS' for a 'FUNCTION_DECL'. 10205 10206 The 'DECL_ARG_TYPE' for a 'PARM_DECL' is the type that will 10207 actually be used when a value is passed to this function. It may 10208 be a wider type than the 'TREE_TYPE' of the parameter; for example, 10209 the ordinary type might be 'short' while the 'DECL_ARG_TYPE' is 10210 'int'. 10211 10212'DEBUG_EXPR_DECL' 10213 Used to represent an anonymous debug-information temporary created 10214 to hold an expression as it is optimized away, so that its value 10215 can be referenced in debug bind statements. 10216 10217'FIELD_DECL' 10218 These nodes represent non-static data members. The 'DECL_SIZE' and 10219 'DECL_ALIGN' behave as for 'VAR_DECL' nodes. The position of the 10220 field within the parent record is specified by a combination of 10221 three attributes. 'DECL_FIELD_OFFSET' is the position, counting in 10222 bytes, of the 'DECL_OFFSET_ALIGN'-bit sized word containing the bit 10223 of the field closest to the beginning of the structure. 10224 'DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 10225 field within this word; this may be nonzero even for fields that 10226 are not bit-fields, since 'DECL_OFFSET_ALIGN' may be greater than 10227 the natural alignment of the field's type. 10228 10229 If 'DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 10230 bit-field, 'DECL_BIT_FIELD_TYPE' also contains the type that was 10231 originally specified for it, while DECL_TYPE may be a modified type 10232 with lesser precision, according to the size of the bit field. 10233 10234'NAMESPACE_DECL' 10235 Namespaces provide a name hierarchy for other declarations. They 10236 appear in the 'DECL_CONTEXT' of other '_DECL' nodes. 10237 10238 10239File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 10240 1024111.4.2 Internal structure 10242------------------------- 10243 10244'DECL' nodes are represented internally as a hierarchy of structures. 10245 10246* Menu: 10247 10248* Current structure hierarchy:: The current DECL node structure 10249hierarchy. 10250* Adding new DECL node types:: How to add a new DECL node to a 10251frontend. 10252 10253 10254File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 10255 1025611.4.2.1 Current structure hierarchy 10257.................................... 10258 10259'struct tree_decl_minimal' 10260 This is the minimal structure to inherit from in order for common 10261 'DECL' macros to work. The fields it contains are a unique ID, 10262 source location, context, and name. 10263 10264'struct tree_decl_common' 10265 This structure inherits from 'struct tree_decl_minimal'. It 10266 contains fields that most 'DECL' nodes need, such as a field to 10267 store alignment, machine mode, size, and attributes. 10268 10269'struct tree_field_decl' 10270 This structure inherits from 'struct tree_decl_common'. It is used 10271 to represent 'FIELD_DECL'. 10272 10273'struct tree_label_decl' 10274 This structure inherits from 'struct tree_decl_common'. It is used 10275 to represent 'LABEL_DECL'. 10276 10277'struct tree_translation_unit_decl' 10278 This structure inherits from 'struct tree_decl_common'. It is used 10279 to represent 'TRANSLATION_UNIT_DECL'. 10280 10281'struct tree_decl_with_rtl' 10282 This structure inherits from 'struct tree_decl_common'. It 10283 contains a field to store the low-level RTL associated with a 10284 'DECL' node. 10285 10286'struct tree_result_decl' 10287 This structure inherits from 'struct tree_decl_with_rtl'. It is 10288 used to represent 'RESULT_DECL'. 10289 10290'struct tree_const_decl' 10291 This structure inherits from 'struct tree_decl_with_rtl'. It is 10292 used to represent 'CONST_DECL'. 10293 10294'struct tree_parm_decl' 10295 This structure inherits from 'struct tree_decl_with_rtl'. It is 10296 used to represent 'PARM_DECL'. 10297 10298'struct tree_decl_with_vis' 10299 This structure inherits from 'struct tree_decl_with_rtl'. It 10300 contains fields necessary to store visibility information, as well 10301 as a section name and assembler name. 10302 10303'struct tree_var_decl' 10304 This structure inherits from 'struct tree_decl_with_vis'. It is 10305 used to represent 'VAR_DECL'. 10306 10307'struct tree_function_decl' 10308 This structure inherits from 'struct tree_decl_with_vis'. It is 10309 used to represent 'FUNCTION_DECL'. 10310 10311 10312File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 10313 1031411.4.2.2 Adding new DECL node types 10315................................... 10316 10317Adding a new 'DECL' tree consists of the following steps 10318 10319Add a new tree code for the 'DECL' node 10320 For language specific 'DECL' nodes, there is a '.def' file in each 10321 frontend directory where the tree code should be added. For 'DECL' 10322 nodes that are part of the middle-end, the code should be added to 10323 'tree.def'. 10324 10325Create a new structure type for the 'DECL' node 10326 These structures should inherit from one of the existing structures 10327 in the language hierarchy by using that structure as the first 10328 member. 10329 10330 struct tree_foo_decl 10331 { 10332 struct tree_decl_with_vis common; 10333 } 10334 10335 Would create a structure name 'tree_foo_decl' that inherits from 10336 'struct tree_decl_with_vis'. 10337 10338 For language specific 'DECL' nodes, this new structure type should 10339 go in the appropriate '.h' file. For 'DECL' nodes that are part of 10340 the middle-end, the structure type should go in 'tree.h'. 10341 10342Add a member to the tree structure enumerator for the node 10343 For garbage collection and dynamic checking purposes, each 'DECL' 10344 node structure type is required to have a unique enumerator value 10345 specified with it. For language specific 'DECL' nodes, this new 10346 enumerator value should go in the appropriate '.def' file. For 10347 'DECL' nodes that are part of the middle-end, the enumerator values 10348 are specified in 'treestruct.def'. 10349 10350Update 'union tree_node' 10351 In order to make your new structure type usable, it must be added 10352 to 'union tree_node'. For language specific 'DECL' nodes, a new 10353 entry should be added to the appropriate '.h' file of the form 10354 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 10355 For 'DECL' nodes that are part of the middle-end, the additional 10356 member goes directly into 'union tree_node' in 'tree.h'. 10357 10358Update dynamic checking info 10359 In order to be able to check whether accessing a named portion of 10360 'union tree_node' is legal, and whether a certain 'DECL' node 10361 contains one of the enumerated 'DECL' node structures in the 10362 hierarchy, a simple lookup table is used. This lookup table needs 10363 to be kept up to date with the tree structure hierarchy, or else 10364 checking and containment macros will fail inappropriately. 10365 10366 For language specific 'DECL' nodes, their is an 'init_ts' function 10367 in an appropriate '.c' file, which initializes the lookup table. 10368 Code setting up the table for new 'DECL' nodes should be added 10369 there. For each 'DECL' tree code and enumerator value representing 10370 a member of the inheritance hierarchy, the table should contain 1 10371 if that tree code inherits (directly or indirectly) from that 10372 member. Thus, a 'FOO_DECL' node derived from 'struct 10373 decl_with_rtl', and enumerator value 'TS_FOO_DECL', would be set up 10374 as follows 10375 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 10376 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 10377 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 10378 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 10379 10380 For 'DECL' nodes that are part of the middle-end, the setup code 10381 goes into 'tree.c'. 10382 10383Add macros to access any new fields and flags 10384 10385 Each added field or flag should have a macro that is used to access 10386 it, that performs appropriate checking to ensure only the right 10387 type of 'DECL' nodes access the field. 10388 10389 These macros generally take the following form 10390 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 10391 However, if the structure is simply a base class for further 10392 structures, something like the following should be used 10393 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 10394 #define BASE_STRUCT_FIELDNAME(NODE) \ 10395 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 10396 10397 Reading them from the generated 'all-tree.def' file (which in turn 10398 includes all the 'tree.def' files), 'gencheck.c' is used during 10399 GCC's build to generate the '*_CHECK' macros for all tree codes. 10400 10401 10402File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 10403 1040411.5 Attributes in trees 10405======================== 10406 10407Attributes, as specified using the '__attribute__' keyword, are 10408represented internally as a 'TREE_LIST'. The 'TREE_PURPOSE' is the name 10409of the attribute, as an 'IDENTIFIER_NODE'. The 'TREE_VALUE' is a 10410'TREE_LIST' of the arguments of the attribute, if any, or 'NULL_TREE' if 10411there are no arguments; the arguments are stored as the 'TREE_VALUE' of 10412successive entries in the list, and may be identifiers or expressions. 10413The 'TREE_CHAIN' of the attribute is the next attribute in a list of 10414attributes applying to the same declaration or type, or 'NULL_TREE' if 10415there are no further attributes in the list. 10416 10417 Attributes may be attached to declarations and to types; these 10418attributes may be accessed with the following macros. All attributes 10419are stored in this way, and many also cause other changes to the 10420declaration or type or to other internal compiler data structures. 10421 10422 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 10423 This macro returns the attributes on the declaration DECL. 10424 10425 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 10426 This macro returns the attributes on the type TYPE. 10427 10428 10429File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 10430 1043111.6 Expressions 10432================ 10433 10434The internal representation for expressions is for the most part quite 10435straightforward. However, there are a few facts that one must bear in 10436mind. In particular, the expression "tree" is actually a directed 10437acyclic graph. (For example there may be many references to the integer 10438constant zero throughout the source program; many of these will be 10439represented by the same expression node.) You should not rely on 10440certain kinds of node being shared, nor should you rely on certain kinds 10441of nodes being unshared. 10442 10443 The following macros can be used with all expression nodes: 10444 10445'TREE_TYPE' 10446 Returns the type of the expression. This value may not be 10447 precisely the same type that would be given the expression in the 10448 original program. 10449 10450 In what follows, some nodes that one might expect to always have type 10451'bool' are documented to have either integral or boolean type. At some 10452point in the future, the C front end may also make use of this same 10453intermediate representation, and at this point these nodes will 10454certainly have integral type. The previous sentence is not meant to 10455imply that the C++ front end does not or will not give these nodes 10456integral type. 10457 10458 Below, we list the various kinds of expression nodes. Except where 10459noted otherwise, the operands to an expression are accessed using the 10460'TREE_OPERAND' macro. For example, to access the first operand to a 10461binary plus expression 'expr', use: 10462 10463 TREE_OPERAND (expr, 0) 10464 10465 As this example indicates, the operands are zero-indexed. 10466 10467* Menu: 10468 10469* Constants: Constant expressions. 10470* Storage References:: 10471* Unary and Binary Expressions:: 10472* Vectors:: 10473 10474 10475File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 10476 1047711.6.1 Constant expressions 10478--------------------------- 10479 10480The table below begins with constants, moves on to unary expressions, 10481then proceeds to binary expressions, and concludes with various other 10482kinds of expressions: 10483 10484'INTEGER_CST' 10485 These nodes represent integer constants. Note that the type of 10486 these constants is obtained with 'TREE_TYPE'; they are not always 10487 of type 'int'. In particular, 'char' constants are represented 10488 with 'INTEGER_CST' nodes. The value of the integer constant 'e' is 10489 represented in an array of HOST_WIDE_INT. There are enough elements 10490 in the array to represent the value without taking extra elements 10491 for redundant 0s or -1. The number of elements used to represent 10492 'e' is available via 'TREE_INT_CST_NUNITS'. Element 'i' can be 10493 extracted by using 'TREE_INT_CST_ELT (e, i)'. 'TREE_INT_CST_LOW' 10494 is a shorthand for 'TREE_INT_CST_ELT (e, 0)'. 10495 10496 The functions 'tree_fits_shwi_p' and 'tree_fits_uhwi_p' can be used 10497 to tell if the value is small enough to fit in a signed 10498 HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively. The value 10499 can then be extracted using 'tree_to_shwi' and 'tree_to_uhwi'. 10500 10501'REAL_CST' 10502 10503 FIXME: Talk about how to obtain representations of this constant, 10504 do comparisons, and so forth. 10505 10506'FIXED_CST' 10507 10508 These nodes represent fixed-point constants. The type of these 10509 constants is obtained with 'TREE_TYPE'. 'TREE_FIXED_CST_PTR' 10510 points to a 'struct fixed_value'; 'TREE_FIXED_CST' returns the 10511 structure itself. 'struct fixed_value' contains 'data' with the 10512 size of two 'HOST_BITS_PER_WIDE_INT' and 'mode' as the associated 10513 fixed-point machine mode for 'data'. 10514 10515'COMPLEX_CST' 10516 These nodes are used to represent complex number constants, that is 10517 a '__complex__' whose parts are constant nodes. The 10518 'TREE_REALPART' and 'TREE_IMAGPART' return the real and the 10519 imaginary parts respectively. 10520 10521'VECTOR_CST' 10522 These nodes are used to represent vector constants. Each vector 10523 constant V is treated as a specific instance of an arbitrary-length 10524 sequence that itself contains 'VECTOR_CST_NPATTERNS (V)' 10525 interleaved patterns. Each pattern has the form: 10526 10527 { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... } 10528 10529 The first three elements in each pattern are enough to determine 10530 the values of the other elements. However, if all STEPs are zero, 10531 only the first two elements are needed. If in addition each BASE1 10532 is equal to the corresponding BASE0, only the first element in each 10533 pattern is needed. The number of encoded elements per pattern is 10534 given by 'VECTOR_CST_NELTS_PER_PATTERN (V)'. 10535 10536 For example, the constant: 10537 10538 { 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 } 10539 10540 is interpreted as an interleaving of the sequences: 10541 10542 { 0, 2, 3, 4, 5, 6, 7, 8 } 10543 { 1, 6, 8, 10, 12, 14, 16, 18 } 10544 10545 where the sequences are represented by the following patterns: 10546 10547 BASE0 == 0, BASE1 == 2, STEP == 1 10548 BASE0 == 1, BASE1 == 6, STEP == 2 10549 10550 In this case: 10551 10552 VECTOR_CST_NPATTERNS (V) == 2 10553 VECTOR_CST_NELTS_PER_PATTERN (V) == 3 10554 10555 The vector is therefore encoded using the first 6 elements ('{ 0, 10556 1, 2, 6, 3, 8 }'), with the remaining 10 elements being implicit 10557 extensions of them. 10558 10559 Sometimes this scheme can create two possible encodings of the same 10560 vector. For example { 0, 1 } could be seen as two patterns with 10561 one element each or one pattern with two elements (BASE0 and 10562 BASE1). The canonical encoding is always the one with the fewest 10563 patterns or (if both encodings have the same number of petterns) 10564 the one with the fewest encoded elements. 10565 10566 'vector_cst_encoding_nelts (V)' gives the total number of encoded 10567 elements in V, which is 6 in the example above. 10568 'VECTOR_CST_ENCODED_ELTS (V)' gives a pointer to the elements 10569 encoded in V and 'VECTOR_CST_ENCODED_ELT (V, I)' accesses the value 10570 of encoded element I. 10571 10572 'VECTOR_CST_DUPLICATE_P (V)' is true if V simply contains repeated 10573 instances of 'VECTOR_CST_NPATTERNS (V)' values. This is a 10574 shorthand for testing 'VECTOR_CST_NELTS_PER_PATTERN (V) == 1'. 10575 10576 'VECTOR_CST_STEPPED_P (V)' is true if at least one pattern in V has 10577 a nonzero step. This is a shorthand for testing 10578 'VECTOR_CST_NELTS_PER_PATTERN (V) == 3'. 10579 10580 The utility function 'vector_cst_elt' gives the value of an 10581 arbitrary index as a 'tree'. 'vector_cst_int_elt' gives the same 10582 value as a 'wide_int'. 10583 10584'STRING_CST' 10585 These nodes represent string-constants. The 'TREE_STRING_LENGTH' 10586 returns the length of the string, as an 'int'. The 10587 'TREE_STRING_POINTER' is a 'char*' containing the string itself. 10588 The string may not be 'NUL'-terminated, and it may contain embedded 10589 'NUL' characters. Therefore, the 'TREE_STRING_LENGTH' includes the 10590 trailing 'NUL' if it is present. 10591 10592 For wide string constants, the 'TREE_STRING_LENGTH' is the number 10593 of bytes in the string, and the 'TREE_STRING_POINTER' points to an 10594 array of the bytes of the string, as represented on the target 10595 system (that is, as integers in the target endianness). Wide and 10596 non-wide string constants are distinguished only by the 'TREE_TYPE' 10597 of the 'STRING_CST'. 10598 10599 FIXME: The formats of string constants are not well-defined when 10600 the target system bytes are not the same width as host system 10601 bytes. 10602 10603'POLY_INT_CST' 10604 These nodes represent invariants that depend on some 10605 target-specific runtime parameters. They consist of 10606 'NUM_POLY_INT_COEFFS' coefficients, with the first coefficient 10607 being the constant term and the others being multipliers that are 10608 applied to the runtime parameters. 10609 10610 'POLY_INT_CST_ELT (X, I)' references coefficient number I of 10611 'POLY_INT_CST' node X. Each coefficient is an 'INTEGER_CST'. 10612 10613 10614File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 10615 1061611.6.2 References to storage 10617---------------------------- 10618 10619'ARRAY_REF' 10620 These nodes represent array accesses. The first operand is the 10621 array; the second is the index. To calculate the address of the 10622 memory accessed, you must scale the index by the size of the type 10623 of the array elements. The type of these expressions must be the 10624 type of a component of the array. The third and fourth operands 10625 are used after gimplification to represent the lower bound and 10626 component size but should not be used directly; call 10627 'array_ref_low_bound' and 'array_ref_element_size' instead. 10628 10629'ARRAY_RANGE_REF' 10630 These nodes represent access to a range (or "slice") of an array. 10631 The operands are the same as that for 'ARRAY_REF' and have the same 10632 meanings. The type of these expressions must be an array whose 10633 component type is the same as that of the first operand. The range 10634 of that array type determines the amount of data these expressions 10635 access. 10636 10637'TARGET_MEM_REF' 10638 These nodes represent memory accesses whose address directly map to 10639 an addressing mode of the target architecture. The first argument 10640 is 'TMR_SYMBOL' and must be a 'VAR_DECL' of an object with a fixed 10641 address. The second argument is 'TMR_BASE' and the third one is 10642 'TMR_INDEX'. The fourth argument is 'TMR_STEP' and must be an 10643 'INTEGER_CST'. The fifth argument is 'TMR_OFFSET' and must be an 10644 'INTEGER_CST'. Any of the arguments may be NULL if the appropriate 10645 component does not appear in the address. Address of the 10646 'TARGET_MEM_REF' is determined in the following way. 10647 10648 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 10649 10650 The sixth argument is the reference to the original memory access, 10651 which is preserved for the purposes of the RTL alias analysis. The 10652 seventh argument is a tag representing the results of tree level 10653 alias analysis. 10654 10655'ADDR_EXPR' 10656 These nodes are used to represent the address of an object. (These 10657 expressions will always have pointer or reference type.) The 10658 operand may be another expression, or it may be a declaration. 10659 10660 As an extension, GCC allows users to take the address of a label. 10661 In this case, the operand of the 'ADDR_EXPR' will be a 10662 'LABEL_DECL'. The type of such an expression is 'void*'. 10663 10664 If the object addressed is not an lvalue, a temporary is created, 10665 and the address of the temporary is used. 10666 10667'INDIRECT_REF' 10668 These nodes are used to represent the object pointed to by a 10669 pointer. The operand is the pointer being dereferenced; it will 10670 always have pointer or reference type. 10671 10672'MEM_REF' 10673 These nodes are used to represent the object pointed to by a 10674 pointer offset by a constant. The first operand is the pointer 10675 being dereferenced; it will always have pointer or reference type. 10676 The second operand is a pointer constant. Its type is specifying 10677 the type to be used for type-based alias analysis. 10678 10679'COMPONENT_REF' 10680 These nodes represent non-static data member accesses. The first 10681 operand is the object (rather than a pointer to it); the second 10682 operand is the 'FIELD_DECL' for the data member. The third operand 10683 represents the byte offset of the field, but should not be used 10684 directly; call 'component_ref_field_offset' instead. 10685 10686 10687File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 10688 1068911.6.3 Unary and Binary Expressions 10690----------------------------------- 10691 10692'NEGATE_EXPR' 10693 These nodes represent unary negation of the single operand, for 10694 both integer and floating-point types. The type of negation can be 10695 determined by looking at the type of the expression. 10696 10697 The behavior of this operation on signed arithmetic overflow is 10698 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10699 10700'ABS_EXPR' 10701 These nodes represent the absolute value of the single operand, for 10702 both integer and floating-point types. This is typically used to 10703 implement the 'abs', 'labs' and 'llabs' builtins for integer types, 10704 and the 'fabs', 'fabsf' and 'fabsl' builtins for floating point 10705 types. The type of abs operation can be determined by looking at 10706 the type of the expression. 10707 10708 This node is not used for complex types. To represent the modulus 10709 or complex abs of a complex value, use the 'BUILT_IN_CABS', 10710 'BUILT_IN_CABSF' or 'BUILT_IN_CABSL' builtins, as used to implement 10711 the C99 'cabs', 'cabsf' and 'cabsl' built-in functions. 10712 10713'ABSU_EXPR' 10714 These nodes represent the absolute value of the single operand in 10715 equivalent unsigned type such that 'ABSU_EXPR' of 'TYPE_MIN' is 10716 well defined. 10717 10718'BIT_NOT_EXPR' 10719 These nodes represent bitwise complement, and will always have 10720 integral type. The only operand is the value to be complemented. 10721 10722'TRUTH_NOT_EXPR' 10723 These nodes represent logical negation, and will always have 10724 integral (or boolean) type. The operand is the value being 10725 negated. The type of the operand and that of the result are always 10726 of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 10727 10728'PREDECREMENT_EXPR' 10729'PREINCREMENT_EXPR' 10730'POSTDECREMENT_EXPR' 10731'POSTINCREMENT_EXPR' 10732 These nodes represent increment and decrement expressions. The 10733 value of the single operand is computed, and the operand 10734 incremented or decremented. In the case of 'PREDECREMENT_EXPR' and 10735 'PREINCREMENT_EXPR', the value of the expression is the value 10736 resulting after the increment or decrement; in the case of 10737 'POSTDECREMENT_EXPR' and 'POSTINCREMENT_EXPR' is the value before 10738 the increment or decrement occurs. The type of the operand, like 10739 that of the result, will be either integral, boolean, or 10740 floating-point. 10741 10742'FIX_TRUNC_EXPR' 10743 These nodes represent conversion of a floating-point value to an 10744 integer. The single operand will have a floating-point type, while 10745 the complete expression will have an integral (or boolean) type. 10746 The operand is rounded towards zero. 10747 10748'FLOAT_EXPR' 10749 These nodes represent conversion of an integral (or boolean) value 10750 to a floating-point value. The single operand will have integral 10751 type, while the complete expression will have a floating-point 10752 type. 10753 10754 FIXME: How is the operand supposed to be rounded? Is this 10755 dependent on '-mieee'? 10756 10757'COMPLEX_EXPR' 10758 These nodes are used to represent complex numbers constructed from 10759 two expressions of the same (integer or real) type. The first 10760 operand is the real part and the second operand is the imaginary 10761 part. 10762 10763'CONJ_EXPR' 10764 These nodes represent the conjugate of their operand. 10765 10766'REALPART_EXPR' 10767'IMAGPART_EXPR' 10768 These nodes represent respectively the real and the imaginary parts 10769 of complex numbers (their sole argument). 10770 10771'NON_LVALUE_EXPR' 10772 These nodes indicate that their one and only operand is not an 10773 lvalue. A back end can treat these identically to the single 10774 operand. 10775 10776'NOP_EXPR' 10777 These nodes are used to represent conversions that do not require 10778 any code-generation. For example, conversion of a 'char*' to an 10779 'int*' does not require any code be generated; such a conversion is 10780 represented by a 'NOP_EXPR'. The single operand is the expression 10781 to be converted. The conversion from a pointer to a reference is 10782 also represented with a 'NOP_EXPR'. 10783 10784'CONVERT_EXPR' 10785 These nodes are similar to 'NOP_EXPR's, but are used in those 10786 situations where code may need to be generated. For example, if an 10787 'int*' is converted to an 'int' code may need to be generated on 10788 some platforms. These nodes are never used for C++-specific 10789 conversions, like conversions between pointers to different classes 10790 in an inheritance hierarchy. Any adjustments that need to be made 10791 in such cases are always indicated explicitly. Similarly, a 10792 user-defined conversion is never represented by a 'CONVERT_EXPR'; 10793 instead, the function calls are made explicit. 10794 10795'FIXED_CONVERT_EXPR' 10796 These nodes are used to represent conversions that involve 10797 fixed-point values. For example, from a fixed-point value to 10798 another fixed-point value, from an integer to a fixed-point value, 10799 from a fixed-point value to an integer, from a floating-point value 10800 to a fixed-point value, or from a fixed-point value to a 10801 floating-point value. 10802 10803'LSHIFT_EXPR' 10804'RSHIFT_EXPR' 10805 These nodes represent left and right shifts, respectively. The 10806 first operand is the value to shift; it will always be of integral 10807 type. The second operand is an expression for the number of bits 10808 by which to shift. Right shift should be treated as arithmetic, 10809 i.e., the high-order bits should be zero-filled when the expression 10810 has unsigned type and filled with the sign bit when the expression 10811 has signed type. Note that the result is undefined if the second 10812 operand is larger than or equal to the first operand's type size. 10813 Unlike most nodes, these can have a vector as first operand and a 10814 scalar as second operand. 10815 10816'BIT_IOR_EXPR' 10817'BIT_XOR_EXPR' 10818'BIT_AND_EXPR' 10819 These nodes represent bitwise inclusive or, bitwise exclusive or, 10820 and bitwise and, respectively. Both operands will always have 10821 integral type. 10822 10823'TRUTH_ANDIF_EXPR' 10824'TRUTH_ORIF_EXPR' 10825 These nodes represent logical "and" and logical "or", respectively. 10826 These operators are not strict; i.e., the second operand is 10827 evaluated only if the value of the expression is not determined by 10828 evaluation of the first operand. The type of the operands and that 10829 of the result are always of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 10830 10831'TRUTH_AND_EXPR' 10832'TRUTH_OR_EXPR' 10833'TRUTH_XOR_EXPR' 10834 These nodes represent logical and, logical or, and logical 10835 exclusive or. They are strict; both arguments are always 10836 evaluated. There are no corresponding operators in C or C++, but 10837 the front end will sometimes generate these expressions anyhow, if 10838 it can tell that strictness does not matter. The type of the 10839 operands and that of the result are always of 'BOOLEAN_TYPE' or 10840 'INTEGER_TYPE'. 10841 10842'POINTER_PLUS_EXPR' 10843 This node represents pointer arithmetic. The first operand is 10844 always a pointer/reference type. The second operand is always an 10845 unsigned integer type compatible with sizetype. This and 10846 POINTER_DIFF_EXPR are the only binary arithmetic operators that can 10847 operate on pointer types. 10848 10849'POINTER_DIFF_EXPR' 10850 This node represents pointer subtraction. The two operands always 10851 have pointer/reference type. It returns a signed integer of the 10852 same precision as the pointers. The behavior is undefined if the 10853 difference of the two pointers, seen as infinite precision 10854 non-negative integers, does not fit in the result type. The result 10855 does not depend on the pointer type, it is not divided by the size 10856 of the pointed-to type. 10857 10858'PLUS_EXPR' 10859'MINUS_EXPR' 10860'MULT_EXPR' 10861 These nodes represent various binary arithmetic operations. 10862 Respectively, these operations are addition, subtraction (of the 10863 second operand from the first) and multiplication. Their operands 10864 may have either integral or floating type, but there will never be 10865 case in which one operand is of floating type and the other is of 10866 integral type. 10867 10868 The behavior of these operations on signed arithmetic overflow is 10869 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10870 10871'MULT_HIGHPART_EXPR' 10872 This node represents the "high-part" of a widening multiplication. 10873 For an integral type with B bits of precision, the result is the 10874 most significant B bits of the full 2B product. 10875 10876'RDIV_EXPR' 10877 This node represents a floating point division operation. 10878 10879'TRUNC_DIV_EXPR' 10880'FLOOR_DIV_EXPR' 10881'CEIL_DIV_EXPR' 10882'ROUND_DIV_EXPR' 10883 These nodes represent integer division operations that return an 10884 integer result. 'TRUNC_DIV_EXPR' rounds towards zero, 10885 'FLOOR_DIV_EXPR' rounds towards negative infinity, 'CEIL_DIV_EXPR' 10886 rounds towards positive infinity and 'ROUND_DIV_EXPR' rounds to the 10887 closest integer. Integer division in C and C++ is truncating, i.e. 10888 'TRUNC_DIV_EXPR'. 10889 10890 The behavior of these operations on signed arithmetic overflow, 10891 when dividing the minimum signed integer by minus one, is 10892 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10893 10894'TRUNC_MOD_EXPR' 10895'FLOOR_MOD_EXPR' 10896'CEIL_MOD_EXPR' 10897'ROUND_MOD_EXPR' 10898 These nodes represent the integer remainder or modulus operation. 10899 The integer modulus of two operands 'a' and 'b' is defined as 'a - 10900 (a/b)*b' where the division calculated using the corresponding 10901 division operator. Hence for 'TRUNC_MOD_EXPR' this definition 10902 assumes division using truncation towards zero, i.e. 10903 'TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 10904 division, i.e. 'TRUNC_MOD_EXPR'. 10905 10906'EXACT_DIV_EXPR' 10907 The 'EXACT_DIV_EXPR' code is used to represent integer divisions 10908 where the numerator is known to be an exact multiple of the 10909 denominator. This allows the backend to choose between the faster 10910 of 'TRUNC_DIV_EXPR', 'CEIL_DIV_EXPR' and 'FLOOR_DIV_EXPR' for the 10911 current target. 10912 10913'LT_EXPR' 10914'LE_EXPR' 10915'GT_EXPR' 10916'GE_EXPR' 10917'LTGT_EXPR' 10918'EQ_EXPR' 10919'NE_EXPR' 10920 These nodes represent the less than, less than or equal to, greater 10921 than, greater than or equal to, less or greater than, equal, and 10922 not equal comparison operators. The first and second operands will 10923 either be both of integral type, both of floating type or both of 10924 vector type, except for LTGT_EXPR where they will only be both of 10925 floating type. The result type of these expressions will always be 10926 of integral, boolean or signed integral vector type. These 10927 operations return the result type's zero value for false, the 10928 result type's one value for true, and a vector whose elements are 10929 zero (false) or minus one (true) for vectors. 10930 10931 For floating point comparisons, if we honor IEEE NaNs and either 10932 operand is NaN, then 'NE_EXPR' always returns true and the 10933 remaining operators always return false. On some targets, 10934 comparisons against an IEEE NaN, other than equality and 10935 inequality, may generate a floating-point exception. 10936 10937'ORDERED_EXPR' 10938'UNORDERED_EXPR' 10939 These nodes represent non-trapping ordered and unordered comparison 10940 operators. These operations take two floating point operands and 10941 determine whether they are ordered or unordered relative to each 10942 other. If either operand is an IEEE NaN, their comparison is 10943 defined to be unordered, otherwise the comparison is defined to be 10944 ordered. The result type of these expressions will always be of 10945 integral or boolean type. These operations return the result 10946 type's zero value for false, and the result type's one value for 10947 true. 10948 10949'UNLT_EXPR' 10950'UNLE_EXPR' 10951'UNGT_EXPR' 10952'UNGE_EXPR' 10953'UNEQ_EXPR' 10954 These nodes represent the unordered comparison operators. These 10955 operations take two floating point operands and determine whether 10956 the operands are unordered or are less than, less than or equal to, 10957 greater than, greater than or equal to, or equal respectively. For 10958 example, 'UNLT_EXPR' returns true if either operand is an IEEE NaN 10959 or the first operand is less than the second. All these operations 10960 are guaranteed not to generate a floating point exception. The 10961 result type of these expressions will always be of integral or 10962 boolean type. These operations return the result type's zero value 10963 for false, and the result type's one value for true. 10964 10965'MODIFY_EXPR' 10966 These nodes represent assignment. The left-hand side is the first 10967 operand; the right-hand side is the second operand. The left-hand 10968 side will be a 'VAR_DECL', 'INDIRECT_REF', 'COMPONENT_REF', or 10969 other lvalue. 10970 10971 These nodes are used to represent not only assignment with '=' but 10972 also compound assignments (like '+='), by reduction to '=' 10973 assignment. In other words, the representation for 'i += 3' looks 10974 just like that for 'i = i + 3'. 10975 10976'INIT_EXPR' 10977 These nodes are just like 'MODIFY_EXPR', but are used only when a 10978 variable is initialized, rather than assigned to subsequently. 10979 This means that we can assume that the target of the initialization 10980 is not used in computing its own value; any reference to the lhs in 10981 computing the rhs is undefined. 10982 10983'COMPOUND_EXPR' 10984 These nodes represent comma-expressions. The first operand is an 10985 expression whose value is computed and thrown away prior to the 10986 evaluation of the second operand. The value of the entire 10987 expression is the value of the second operand. 10988 10989'COND_EXPR' 10990 These nodes represent '?:' expressions. The first operand is of 10991 boolean or integral type. If it evaluates to a nonzero value, the 10992 second operand should be evaluated, and returned as the value of 10993 the expression. Otherwise, the third operand is evaluated, and 10994 returned as the value of the expression. 10995 10996 The second operand must have the same type as the entire 10997 expression, unless it unconditionally throws an exception or calls 10998 a noreturn function, in which case it should have void type. The 10999 same constraints apply to the third operand. This allows array 11000 bounds checks to be represented conveniently as '(i >= 0 && i < 10) 11001 ? i : abort()'. 11002 11003 As a GNU extension, the C language front-ends allow the second 11004 operand of the '?:' operator may be omitted in the source. For 11005 example, 'x ? : 3' is equivalent to 'x ? x : 3', assuming that 'x' 11006 is an expression without side effects. In the tree representation, 11007 however, the second operand is always present, possibly protected 11008 by 'SAVE_EXPR' if the first argument does cause side effects. 11009 11010'CALL_EXPR' 11011 These nodes are used to represent calls to functions, including 11012 non-static member functions. 'CALL_EXPR's are implemented as 11013 expression nodes with a variable number of operands. Rather than 11014 using 'TREE_OPERAND' to extract them, it is preferable to use the 11015 specialized accessor macros and functions that operate specifically 11016 on 'CALL_EXPR' nodes. 11017 11018 'CALL_EXPR_FN' returns a pointer to the function to call; it is 11019 always an expression whose type is a 'POINTER_TYPE'. 11020 11021 The number of arguments to the call is returned by 11022 'call_expr_nargs', while the arguments themselves can be accessed 11023 with the 'CALL_EXPR_ARG' macro. The arguments are zero-indexed and 11024 numbered left-to-right. You can iterate over the arguments using 11025 'FOR_EACH_CALL_EXPR_ARG', as in: 11026 11027 tree call, arg; 11028 call_expr_arg_iterator iter; 11029 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 11030 /* arg is bound to successive arguments of call. */ 11031 ...; 11032 11033 For non-static member functions, there will be an operand 11034 corresponding to the 'this' pointer. There will always be 11035 expressions corresponding to all of the arguments, even if the 11036 function is declared with default arguments and some arguments are 11037 not explicitly provided at the call sites. 11038 11039 'CALL_EXPR's also have a 'CALL_EXPR_STATIC_CHAIN' operand that is 11040 used to implement nested functions. This operand is otherwise 11041 null. 11042 11043'CLEANUP_POINT_EXPR' 11044 These nodes represent full-expressions. The single operand is an 11045 expression to evaluate. Any destructor calls engendered by the 11046 creation of temporaries during the evaluation of that expression 11047 should be performed immediately after the expression is evaluated. 11048 11049'CONSTRUCTOR' 11050 These nodes represent the brace-enclosed initializers for a 11051 structure or an array. They contain a sequence of component values 11052 made out of a vector of constructor_elt, which is a ('INDEX', 11053 'VALUE') pair. 11054 11055 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is a 'RECORD_TYPE', 11056 'UNION_TYPE' or 'QUAL_UNION_TYPE' then the 'INDEX' of each node in 11057 the sequence will be a 'FIELD_DECL' and the 'VALUE' will be the 11058 expression used to initialize that field. 11059 11060 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is an 'ARRAY_TYPE', then 11061 the 'INDEX' of each node in the sequence will be an 'INTEGER_CST' 11062 or a 'RANGE_EXPR' of two 'INTEGER_CST's. A single 'INTEGER_CST' 11063 indicates which element of the array is being assigned to. A 11064 'RANGE_EXPR' indicates an inclusive range of elements to 11065 initialize. In both cases the 'VALUE' is the corresponding 11066 initializer. It is re-evaluated for each element of a 11067 'RANGE_EXPR'. If the 'INDEX' is 'NULL_TREE', then the initializer 11068 is for the next available array element. 11069 11070 In the front end, you should not depend on the fields appearing in 11071 any particular order. However, in the middle end, fields must 11072 appear in declaration order. You should not assume that all fields 11073 will be represented. Unrepresented fields will be cleared 11074 (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which 11075 case their value becomes undefined. 11076 11077'COMPOUND_LITERAL_EXPR' 11078 These nodes represent ISO C99 compound literals. The 11079 'COMPOUND_LITERAL_EXPR_DECL_EXPR' is a 'DECL_EXPR' containing an 11080 anonymous 'VAR_DECL' for the unnamed object represented by the 11081 compound literal; the 'DECL_INITIAL' of that 'VAR_DECL' is a 11082 'CONSTRUCTOR' representing the brace-enclosed list of initializers 11083 in the compound literal. That anonymous 'VAR_DECL' can also be 11084 accessed directly by the 'COMPOUND_LITERAL_EXPR_DECL' macro. 11085 11086'SAVE_EXPR' 11087 11088 A 'SAVE_EXPR' represents an expression (possibly involving side 11089 effects) that is used more than once. The side effects should 11090 occur only the first time the expression is evaluated. Subsequent 11091 uses should just reuse the computed value. The first operand to 11092 the 'SAVE_EXPR' is the expression to evaluate. The side effects 11093 should be executed where the 'SAVE_EXPR' is first encountered in a 11094 depth-first preorder traversal of the expression tree. 11095 11096'TARGET_EXPR' 11097 A 'TARGET_EXPR' represents a temporary object. The first operand 11098 is a 'VAR_DECL' for the temporary variable. The second operand is 11099 the initializer for the temporary. The initializer is evaluated 11100 and, if non-void, copied (bitwise) into the temporary. If the 11101 initializer is void, that means that it will perform the 11102 initialization itself. 11103 11104 Often, a 'TARGET_EXPR' occurs on the right-hand side of an 11105 assignment, or as the second operand to a comma-expression which is 11106 itself the right-hand side of an assignment, etc. In this case, we 11107 say that the 'TARGET_EXPR' is "normal"; otherwise, we say it is 11108 "orphaned". For a normal 'TARGET_EXPR' the temporary variable 11109 should be treated as an alias for the left-hand side of the 11110 assignment, rather than as a new temporary variable. 11111 11112 The third operand to the 'TARGET_EXPR', if present, is a 11113 cleanup-expression (i.e., destructor call) for the temporary. If 11114 this expression is orphaned, then this expression must be executed 11115 when the statement containing this expression is complete. These 11116 cleanups must always be executed in the order opposite to that in 11117 which they were encountered. Note that if a temporary is created 11118 on one branch of a conditional operator (i.e., in the second or 11119 third operand to a 'COND_EXPR'), the cleanup must be run only if 11120 that branch is actually executed. 11121 11122'VA_ARG_EXPR' 11123 This node is used to implement support for the C/C++ variable 11124 argument-list mechanism. It represents expressions like 'va_arg 11125 (ap, type)'. Its 'TREE_TYPE' yields the tree representation for 11126 'type' and its sole argument yields the representation for 'ap'. 11127 11128'ANNOTATE_EXPR' 11129 This node is used to attach markers to an expression. The first 11130 operand is the annotated expression, the second is an 'INTEGER_CST' 11131 with a value from 'enum annot_expr_kind', the third is an 11132 'INTEGER_CST'. 11133 11134 11135File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 11136 1113711.6.4 Vectors 11138-------------- 11139 11140'VEC_DUPLICATE_EXPR' 11141 This node has a single operand and represents a vector in which 11142 every element is equal to that operand. 11143 11144'VEC_SERIES_EXPR' 11145 This node represents a vector formed from a scalar base and step, 11146 given as the first and second operands respectively. Element I of 11147 the result is equal to 'BASE + I*STEP'. 11148 11149 This node is restricted to integral types, in order to avoid 11150 specifying the rounding behavior for floating-point types. 11151 11152'VEC_LSHIFT_EXPR' 11153'VEC_RSHIFT_EXPR' 11154 These nodes represent whole vector left and right shifts, 11155 respectively. The first operand is the vector to shift; it will 11156 always be of vector type. The second operand is an expression for 11157 the number of bits by which to shift. Note that the result is 11158 undefined if the second operand is larger than or equal to the 11159 first operand's type size. 11160 11161'VEC_WIDEN_MULT_HI_EXPR' 11162'VEC_WIDEN_MULT_LO_EXPR' 11163 These nodes represent widening vector multiplication of the high 11164 and low parts of the two input vectors, respectively. Their 11165 operands are vectors that contain the same number of elements ('N') 11166 of the same integral type. The result is a vector that contains 11167 half as many elements, of an integral type whose size is twice as 11168 wide. In the case of 'VEC_WIDEN_MULT_HI_EXPR' the high 'N/2' 11169 elements of the two vector are multiplied to produce the vector of 11170 'N/2' products. In the case of 'VEC_WIDEN_MULT_LO_EXPR' the low 11171 'N/2' elements of the two vector are multiplied to produce the 11172 vector of 'N/2' products. 11173 11174'VEC_UNPACK_HI_EXPR' 11175'VEC_UNPACK_LO_EXPR' 11176 These nodes represent unpacking of the high and low parts of the 11177 input vector, respectively. The single operand is a vector that 11178 contains 'N' elements of the same integral or floating point type. 11179 The result is a vector that contains half as many elements, of an 11180 integral or floating point type whose size is twice as wide. In 11181 the case of 'VEC_UNPACK_HI_EXPR' the high 'N/2' elements of the 11182 vector are extracted and widened (promoted). In the case of 11183 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the vector are 11184 extracted and widened (promoted). 11185 11186'VEC_UNPACK_FLOAT_HI_EXPR' 11187'VEC_UNPACK_FLOAT_LO_EXPR' 11188 These nodes represent unpacking of the high and low parts of the 11189 input vector, where the values are converted from fixed point to 11190 floating point. The single operand is a vector that contains 'N' 11191 elements of the same integral type. The result is a vector that 11192 contains half as many elements of a floating point type whose size 11193 is twice as wide. In the case of 'VEC_UNPACK_FLOAT_HI_EXPR' the 11194 high 'N/2' elements of the vector are extracted, converted and 11195 widened. In the case of 'VEC_UNPACK_FLOAT_LO_EXPR' the low 'N/2' 11196 elements of the vector are extracted, converted and widened. 11197 11198'VEC_UNPACK_FIX_TRUNC_HI_EXPR' 11199'VEC_UNPACK_FIX_TRUNC_LO_EXPR' 11200 These nodes represent unpacking of the high and low parts of the 11201 input vector, where the values are truncated from floating point to 11202 fixed point. The single operand is a vector that contains 'N' 11203 elements of the same floating point type. The result is a vector 11204 that contains half as many elements of an integral type whose size 11205 is twice as wide. In the case of 'VEC_UNPACK_FIX_TRUNC_HI_EXPR' 11206 the high 'N/2' elements of the vector are extracted and converted 11207 with truncation. In the case of 'VEC_UNPACK_FIX_TRUNC_LO_EXPR' the 11208 low 'N/2' elements of the vector are extracted and converted with 11209 truncation. 11210 11211'VEC_PACK_TRUNC_EXPR' 11212 This node represents packing of truncated elements of the two input 11213 vectors into the output vector. Input operands are vectors that 11214 contain the same number of elements of the same integral or 11215 floating point type. The result is a vector that contains twice as 11216 many elements of an integral or floating point type whose size is 11217 half as wide. The elements of the two vectors are demoted and 11218 merged (concatenated) to form the output vector. 11219 11220'VEC_PACK_SAT_EXPR' 11221 This node represents packing of elements of the two input vectors 11222 into the output vector using saturation. Input operands are 11223 vectors that contain the same number of elements of the same 11224 integral type. The result is a vector that contains twice as many 11225 elements of an integral type whose size is half as wide. The 11226 elements of the two vectors are demoted and merged (concatenated) 11227 to form the output vector. 11228 11229'VEC_PACK_FIX_TRUNC_EXPR' 11230 This node represents packing of elements of the two input vectors 11231 into the output vector, where the values are converted from 11232 floating point to fixed point. Input operands are vectors that 11233 contain the same number of elements of a floating point type. The 11234 result is a vector that contains twice as many elements of an 11235 integral type whose size is half as wide. The elements of the two 11236 vectors are merged (concatenated) to form the output vector. 11237 11238'VEC_PACK_FLOAT_EXPR' 11239 This node represents packing of elements of the two input vectors 11240 into the output vector, where the values are converted from fixed 11241 point to floating point. Input operands are vectors that contain 11242 the same number of elements of an integral type. The result is a 11243 vector that contains twice as many elements of floating point type 11244 whose size is half as wide. The elements of the two vectors are 11245 merged (concatenated) to form the output vector. 11246 11247'VEC_COND_EXPR' 11248 These nodes represent '?:' expressions. The three operands must be 11249 vectors of the same size and number of elements. The second and 11250 third operands must have the same type as the entire expression. 11251 The first operand is of signed integral vector type. If an element 11252 of the first operand evaluates to a zero value, the corresponding 11253 element of the result is taken from the third operand. If it 11254 evaluates to a minus one value, it is taken from the second 11255 operand. It should never evaluate to any other value currently, 11256 but optimizations should not rely on that property. In contrast 11257 with a 'COND_EXPR', all operands are always evaluated. 11258 11259'SAD_EXPR' 11260 This node represents the Sum of Absolute Differences operation. 11261 The three operands must be vectors of integral types. The first 11262 and second operand must have the same type. The size of the vector 11263 element of the third operand must be at lease twice of the size of 11264 the vector element of the first and second one. The SAD is 11265 calculated between the first and second operands, added to the 11266 third operand, and returned. 11267 11268 11269File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 11270 1127111.7 Statements 11272=============== 11273 11274Most statements in GIMPLE are assignment statements, represented by 11275'GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 11276a reference to a volatile object is converted into a 'GIMPLE_ASSIGN'. 11277 11278 There are also several varieties of complex statements. 11279 11280* Menu: 11281 11282* Basic Statements:: 11283* Blocks:: 11284* Statement Sequences:: 11285* Empty Statements:: 11286* Jumps:: 11287* Cleanups:: 11288* OpenMP:: 11289* OpenACC:: 11290 11291 11292File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 11293 1129411.7.1 Basic Statements 11295----------------------- 11296 11297'ASM_EXPR' 11298 11299 Used to represent an inline assembly statement. For an inline 11300 assembly statement like: 11301 asm ("mov x, y"); 11302 The 'ASM_STRING' macro will return a 'STRING_CST' node for '"mov x, 11303 y"'. If the original statement made use of the extended-assembly 11304 syntax, then 'ASM_OUTPUTS', 'ASM_INPUTS', and 'ASM_CLOBBERS' will 11305 be the outputs, inputs, and clobbers for the statement, represented 11306 as 'STRING_CST' nodes. The extended-assembly syntax looks like: 11307 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 11308 The first string is the 'ASM_STRING', containing the instruction 11309 template. The next two strings are the output and inputs, 11310 respectively; this statement has no clobbers. As this example 11311 indicates, "plain" assembly statements are merely a special case of 11312 extended assembly statements; they have no cv-qualifiers, outputs, 11313 inputs, or clobbers. All of the strings will be 'NUL'-terminated, 11314 and will contain no embedded 'NUL'-characters. 11315 11316 If the assembly statement is declared 'volatile', or if the 11317 statement was not an extended assembly statement, and is therefore 11318 implicitly volatile, then the predicate 'ASM_VOLATILE_P' will hold 11319 of the 'ASM_EXPR'. 11320 11321'DECL_EXPR' 11322 11323 Used to represent a local declaration. The 'DECL_EXPR_DECL' macro 11324 can be used to obtain the entity declared. This declaration may be 11325 a 'LABEL_DECL', indicating that the label declared is a local 11326 label. (As an extension, GCC allows the declaration of labels with 11327 scope.) In C, this declaration may be a 'FUNCTION_DECL', 11328 indicating the use of the GCC nested function extension. For more 11329 information, *note Functions::. 11330 11331'LABEL_EXPR' 11332 11333 Used to represent a label. The 'LABEL_DECL' declared by this 11334 statement can be obtained with the 'LABEL_EXPR_LABEL' macro. The 11335 'IDENTIFIER_NODE' giving the name of the label can be obtained from 11336 the 'LABEL_DECL' with 'DECL_NAME'. 11337 11338'GOTO_EXPR' 11339 11340 Used to represent a 'goto' statement. The 'GOTO_DESTINATION' will 11341 usually be a 'LABEL_DECL'. However, if the "computed goto" 11342 extension has been used, the 'GOTO_DESTINATION' will be an 11343 arbitrary expression indicating the destination. This expression 11344 will always have pointer type. 11345 11346'RETURN_EXPR' 11347 11348 Used to represent a 'return' statement. Operand 0 represents the 11349 value to return. It should either be the 'RESULT_DECL' for the 11350 containing function, or a 'MODIFY_EXPR' or 'INIT_EXPR' setting the 11351 function's 'RESULT_DECL'. It will be 'NULL_TREE' if the statement 11352 was just 11353 return; 11354 11355'LOOP_EXPR' 11356 These nodes represent "infinite" loops. The 'LOOP_EXPR_BODY' 11357 represents the body of the loop. It should be executed forever, 11358 unless an 'EXIT_EXPR' is encountered. 11359 11360'EXIT_EXPR' 11361 These nodes represent conditional exits from the nearest enclosing 11362 'LOOP_EXPR'. The single operand is the condition; if it is 11363 nonzero, then the loop should be exited. An 'EXIT_EXPR' will only 11364 appear within a 'LOOP_EXPR'. 11365 11366'SWITCH_STMT' 11367 11368 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 11369 the expression on which the switch is occurring. See the 11370 documentation for an 'IF_STMT' for more information on the 11371 representation used for the condition. The 'SWITCH_STMT_BODY' is 11372 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 11373 original type of switch expression as given in the source, before 11374 any compiler conversions. 11375 11376'CASE_LABEL_EXPR' 11377 11378 Use to represent a 'case' label, range of 'case' labels, or a 11379 'default' label. If 'CASE_LOW' is 'NULL_TREE', then this is a 11380 'default' label. Otherwise, if 'CASE_HIGH' is 'NULL_TREE', then 11381 this is an ordinary 'case' label. In this case, 'CASE_LOW' is an 11382 expression giving the value of the label. Both 'CASE_LOW' and 11383 'CASE_HIGH' are 'INTEGER_CST' nodes. These values will have the 11384 same type as the condition expression in the switch statement. 11385 11386 Otherwise, if both 'CASE_LOW' and 'CASE_HIGH' are defined, the 11387 statement is a range of case labels. Such statements originate 11388 with the extension that allows users to write things of the form: 11389 case 2 ... 5: 11390 The first value will be 'CASE_LOW', while the second will be 11391 'CASE_HIGH'. 11392 11393'DEBUG_BEGIN_STMT' 11394 11395 Marks the beginning of a source statement, for purposes of debug 11396 information generation. 11397 11398 11399File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 11400 1140111.7.2 Blocks 11402------------- 11403 11404Block scopes and the variables they declare in GENERIC are expressed 11405using the 'BIND_EXPR' code, which in previous versions of GCC was 11406primarily used for the C statement-expression extension. 11407 11408 Variables in a block are collected into 'BIND_EXPR_VARS' in declaration 11409order through their 'TREE_CHAIN' field. Any runtime initialization is 11410moved out of 'DECL_INITIAL' and into a statement in the controlled 11411block. When gimplifying from C or C++, this initialization replaces the 11412'DECL_STMT'. These variables will never require cleanups. The scope of 11413these variables is just the body 11414 11415 Variable-length arrays (VLAs) complicate this process, as their size 11416often refers to variables initialized earlier in the block and their 11417initialization involves an explicit stack allocation. To handle this, 11418we add an indirection and replace them with a pointer to stack space 11419allocated by means of 'alloca'. In most cases, we also arrange for this 11420space to be reclaimed when the enclosing 'BIND_EXPR' is exited, the 11421exception to this being when there is an explicit call to 'alloca' in 11422the source code, in which case the stack is left depressed on exit of 11423the 'BIND_EXPR'. 11424 11425 A C++ program will usually contain more 'BIND_EXPR's than there are 11426syntactic blocks in the source code, since several C++ constructs have 11427implicit scopes associated with them. On the other hand, although the 11428C++ front end uses pseudo-scopes to handle cleanups for objects with 11429destructors, these don't translate into the GIMPLE form; multiple 11430declarations at the same level use the same 'BIND_EXPR'. 11431 11432 11433File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 11434 1143511.7.3 Statement Sequences 11436-------------------------- 11437 11438Multiple statements at the same nesting level are collected into a 11439'STATEMENT_LIST'. Statement lists are modified and traversed using the 11440interface in 'tree-iterator.h'. 11441 11442 11443File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 11444 1144511.7.4 Empty Statements 11446----------------------- 11447 11448Whenever possible, statements with no effect are discarded. But if they 11449are nested within another construct which cannot be discarded for some 11450reason, they are instead replaced with an empty statement, generated by 11451'build_empty_stmt'. Initially, all empty statements were shared, after 11452the pattern of the Java front end, but this caused a lot of trouble in 11453practice. 11454 11455 An empty statement is represented as '(void)0'. 11456 11457 11458File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 11459 1146011.7.5 Jumps 11461------------ 11462 11463Other jumps are expressed by either 'GOTO_EXPR' or 'RETURN_EXPR'. 11464 11465 The operand of a 'GOTO_EXPR' must be either a label or a variable 11466containing the address to jump to. 11467 11468 The operand of a 'RETURN_EXPR' is either 'NULL_TREE', 'RESULT_DECL', or 11469a 'MODIFY_EXPR' which sets the return value. It would be nice to move 11470the 'MODIFY_EXPR' into a separate statement, but the special return 11471semantics in 'expand_return' make that difficult. It may still happen 11472in the future, perhaps by moving most of that logic into 11473'expand_assignment'. 11474 11475 11476File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 11477 1147811.7.6 Cleanups 11479--------------- 11480 11481Destructors for local C++ objects and similar dynamic cleanups are 11482represented in GIMPLE by a 'TRY_FINALLY_EXPR'. 'TRY_FINALLY_EXPR' has 11483two operands, both of which are a sequence of statements to execute. 11484The first sequence is executed. When it completes the second sequence 11485is executed. 11486 11487 The first sequence may complete in the following ways: 11488 11489 1. Execute the last statement in the sequence and fall off the end. 11490 11491 2. Execute a goto statement ('GOTO_EXPR') to an ordinary label outside 11492 the sequence. 11493 11494 3. Execute a return statement ('RETURN_EXPR'). 11495 11496 4. Throw an exception. This is currently not explicitly represented 11497 in GIMPLE. 11498 11499 The second sequence is not executed if the first sequence completes by 11500calling 'setjmp' or 'exit' or any other function that does not return. 11501The second sequence is also not executed if the first sequence completes 11502via a non-local goto or a computed goto (in general the compiler does 11503not know whether such a goto statement exits the first sequence or not, 11504so we assume that it doesn't). 11505 11506 After the second sequence is executed, if it completes normally by 11507falling off the end, execution continues wherever the first sequence 11508would have continued, by falling off the end, or doing a goto, etc. 11509 11510 If the second sequence is an 'EH_ELSE_EXPR' selector, then the sequence 11511in its first operand is used when the first sequence completes normally, 11512and that in its second operand is used for exceptional cleanups, i.e., 11513when an exception propagates out of the first sequence. 11514 11515 'TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 11516to appear on every edge out of the controlled block; this reduces the 11517freedom to move code across these edges. Therefore, the EH lowering 11518pass which runs before most of the optimization passes eliminates these 11519expressions by explicitly adding the cleanup to each edge. Rethrowing 11520the exception is represented using 'RESX_EXPR'. 11521 11522 11523File: gccint.info, Node: OpenMP, Next: OpenACC, Prev: Cleanups, Up: Statements 11524 1152511.7.7 OpenMP 11526------------- 11527 11528All the statements starting with 'OMP_' represent directives and clauses 11529used by the OpenMP API <https://www.openmp.org>. 11530 11531'OMP_PARALLEL' 11532 11533 Represents '#pragma omp parallel [clause1 ... clauseN]'. It has 11534 four operands: 11535 11536 Operand 'OMP_PARALLEL_BODY' is valid while in GENERIC and High 11537 GIMPLE forms. It contains the body of code to be executed by all 11538 the threads. During GIMPLE lowering, this operand becomes 'NULL' 11539 and the body is emitted linearly after 'OMP_PARALLEL'. 11540 11541 Operand 'OMP_PARALLEL_CLAUSES' is the list of clauses associated 11542 with the directive. 11543 11544 Operand 'OMP_PARALLEL_FN' is created by 'pass_lower_omp', it 11545 contains the 'FUNCTION_DECL' for the function that will contain the 11546 body of the parallel region. 11547 11548 Operand 'OMP_PARALLEL_DATA_ARG' is also created by 11549 'pass_lower_omp'. If there are shared variables to be communicated 11550 to the children threads, this operand will contain the 'VAR_DECL' 11551 that contains all the shared values and variables. 11552 11553'OMP_FOR' 11554 11555 Represents '#pragma omp for [clause1 ... clauseN]'. It has six 11556 operands: 11557 11558 Operand 'OMP_FOR_BODY' contains the loop body. 11559 11560 Operand 'OMP_FOR_CLAUSES' is the list of clauses associated with 11561 the directive. 11562 11563 Operand 'OMP_FOR_INIT' is the loop initialization code of the form 11564 'VAR = N1'. 11565 11566 Operand 'OMP_FOR_COND' is the loop conditional expression of the 11567 form 'VAR {<,>,<=,>=} N2'. 11568 11569 Operand 'OMP_FOR_INCR' is the loop index increment of the form 'VAR 11570 {+=,-=} INCR'. 11571 11572 Operand 'OMP_FOR_PRE_BODY' contains side effect code from operands 11573 'OMP_FOR_INIT', 'OMP_FOR_COND' and 'OMP_FOR_INC'. These side 11574 effects are part of the 'OMP_FOR' block but must be evaluated 11575 before the start of loop body. 11576 11577 The loop index variable 'VAR' must be a signed integer variable, 11578 which is implicitly private to each thread. Bounds 'N1' and 'N2' 11579 and the increment expression 'INCR' are required to be loop 11580 invariant integer expressions that are evaluated without any 11581 synchronization. The evaluation order, frequency of evaluation and 11582 side effects are unspecified by the standard. 11583 11584'OMP_SECTIONS' 11585 11586 Represents '#pragma omp sections [clause1 ... clauseN]'. 11587 11588 Operand 'OMP_SECTIONS_BODY' contains the sections body, which in 11589 turn contains a set of 'OMP_SECTION' nodes for each of the 11590 concurrent sections delimited by '#pragma omp section'. 11591 11592 Operand 'OMP_SECTIONS_CLAUSES' is the list of clauses associated 11593 with the directive. 11594 11595'OMP_SECTION' 11596 11597 Section delimiter for 'OMP_SECTIONS'. 11598 11599'OMP_SINGLE' 11600 11601 Represents '#pragma omp single'. 11602 11603 Operand 'OMP_SINGLE_BODY' contains the body of code to be executed 11604 by a single thread. 11605 11606 Operand 'OMP_SINGLE_CLAUSES' is the list of clauses associated with 11607 the directive. 11608 11609'OMP_MASTER' 11610 11611 Represents '#pragma omp master'. 11612 11613 Operand 'OMP_MASTER_BODY' contains the body of code to be executed 11614 by the master thread. 11615 11616'OMP_ORDERED' 11617 11618 Represents '#pragma omp ordered'. 11619 11620 Operand 'OMP_ORDERED_BODY' contains the body of code to be executed 11621 in the sequential order dictated by the loop index variable. 11622 11623'OMP_CRITICAL' 11624 11625 Represents '#pragma omp critical [name]'. 11626 11627 Operand 'OMP_CRITICAL_BODY' is the critical section. 11628 11629 Operand 'OMP_CRITICAL_NAME' is an optional identifier to label the 11630 critical section. 11631 11632'OMP_RETURN' 11633 11634 This does not represent any OpenMP directive, it is an artificial 11635 marker to indicate the end of the body of an OpenMP. It is used by 11636 the flow graph ('tree-cfg.c') and OpenMP region building code 11637 ('omp-low.c'). 11638 11639'OMP_CONTINUE' 11640 11641 Similarly, this instruction does not represent an OpenMP directive, 11642 it is used by 'OMP_FOR' (and similar codes) as well as 11643 'OMP_SECTIONS' to mark the place where the code needs to loop to 11644 the next iteration, or the next section, respectively. 11645 11646 In some cases, 'OMP_CONTINUE' is placed right before 'OMP_RETURN'. 11647 But if there are cleanups that need to occur right after the 11648 looping body, it will be emitted between 'OMP_CONTINUE' and 11649 'OMP_RETURN'. 11650 11651'OMP_ATOMIC' 11652 11653 Represents '#pragma omp atomic'. 11654 11655 Operand 0 is the address at which the atomic operation is to be 11656 performed. 11657 11658 Operand 1 is the expression to evaluate. The gimplifier tries 11659 three alternative code generation strategies. Whenever possible, 11660 an atomic update built-in is used. If that fails, a 11661 compare-and-swap loop is attempted. If that also fails, a regular 11662 critical section around the expression is used. 11663 11664'OMP_CLAUSE' 11665 11666 Represents clauses associated with one of the 'OMP_' directives. 11667 Clauses are represented by separate subcodes defined in 'tree.h'. 11668 Clauses codes can be one of: 'OMP_CLAUSE_PRIVATE', 11669 'OMP_CLAUSE_SHARED', 'OMP_CLAUSE_FIRSTPRIVATE', 11670 'OMP_CLAUSE_LASTPRIVATE', 'OMP_CLAUSE_COPYIN', 11671 'OMP_CLAUSE_COPYPRIVATE', 'OMP_CLAUSE_IF', 11672 'OMP_CLAUSE_NUM_THREADS', 'OMP_CLAUSE_SCHEDULE', 11673 'OMP_CLAUSE_NOWAIT', 'OMP_CLAUSE_ORDERED', 'OMP_CLAUSE_DEFAULT', 11674 'OMP_CLAUSE_REDUCTION', 'OMP_CLAUSE_COLLAPSE', 'OMP_CLAUSE_UNTIED', 11675 'OMP_CLAUSE_FINAL', and 'OMP_CLAUSE_MERGEABLE'. Each code 11676 represents the corresponding OpenMP clause. 11677 11678 Clauses associated with the same directive are chained together via 11679 'OMP_CLAUSE_CHAIN'. Those clauses that accept a list of variables 11680 are restricted to exactly one, accessed with 'OMP_CLAUSE_VAR'. 11681 Therefore, multiple variables under the same clause 'C' need to be 11682 represented as multiple 'C' clauses chained together. This 11683 facilitates adding new clauses during compilation. 11684 11685 11686File: gccint.info, Node: OpenACC, Prev: OpenMP, Up: Statements 11687 1168811.7.8 OpenACC 11689-------------- 11690 11691All the statements starting with 'OACC_' represent directives and 11692clauses used by the OpenACC API <https://www.openacc.org>. 11693 11694'OACC_CACHE' 11695 11696 Represents '#pragma acc cache (var ...)'. 11697 11698'OACC_DATA' 11699 11700 Represents '#pragma acc data [clause1 ... clauseN]'. 11701 11702'OACC_DECLARE' 11703 11704 Represents '#pragma acc declare [clause1 ... clauseN]'. 11705 11706'OACC_ENTER_DATA' 11707 11708 Represents '#pragma acc enter data [clause1 ... clauseN]'. 11709 11710'OACC_EXIT_DATA' 11711 11712 Represents '#pragma acc exit data [clause1 ... clauseN]'. 11713 11714'OACC_HOST_DATA' 11715 11716 Represents '#pragma acc host_data [clause1 ... clauseN]'. 11717 11718'OACC_KERNELS' 11719 11720 Represents '#pragma acc kernels [clause1 ... clauseN]'. 11721 11722'OACC_LOOP' 11723 11724 Represents '#pragma acc loop [clause1 ... clauseN]'. 11725 11726 See the description of the 'OMP_FOR' code. 11727 11728'OACC_PARALLEL' 11729 11730 Represents '#pragma acc parallel [clause1 ... clauseN]'. 11731 11732'OACC_SERIAL' 11733 11734 Represents '#pragma acc serial [clause1 ... clauseN]'. 11735 11736'OACC_UPDATE' 11737 11738 Represents '#pragma acc update [clause1 ... clauseN]'. 11739 11740 11741File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 11742 1174311.8 Functions 11744============== 11745 11746A function is represented by a 'FUNCTION_DECL' node. It stores the 11747basic pieces of the function such as body, parameters, and return type 11748as well as information on the surrounding context, visibility, and 11749linkage. 11750 11751* Menu: 11752 11753* Function Basics:: Function names, body, and parameters. 11754* Function Properties:: Context, linkage, etc. 11755 11756 11757File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 11758 1175911.8.1 Function Basics 11760---------------------- 11761 11762A function has four core parts: the name, the parameters, the result, 11763and the body. The following macros and functions access these parts of 11764a 'FUNCTION_DECL' as well as other basic features: 11765'DECL_NAME' 11766 This macro returns the unqualified name of the function, as an 11767 'IDENTIFIER_NODE'. For an instantiation of a function template, 11768 the 'DECL_NAME' is the unqualified name of the template, not 11769 something like 'f<int>'. The value of 'DECL_NAME' is undefined 11770 when used on a constructor, destructor, overloaded operator, or 11771 type-conversion operator, or any function that is implicitly 11772 generated by the compiler. See below for macros that can be used 11773 to distinguish these cases. 11774 11775'DECL_ASSEMBLER_NAME' 11776 This macro returns the mangled name of the function, also an 11777 'IDENTIFIER_NODE'. This name does not contain leading underscores 11778 on systems that prefix all identifiers with underscores. The 11779 mangled name is computed in the same way on all platforms; if 11780 special processing is required to deal with the object file format 11781 used on a particular platform, it is the responsibility of the back 11782 end to perform those modifications. (Of course, the back end 11783 should not modify 'DECL_ASSEMBLER_NAME' itself.) 11784 11785 Using 'DECL_ASSEMBLER_NAME' will cause additional memory to be 11786 allocated (for the mangled name of the entity) so it should be used 11787 only when emitting assembly code. It should not be used within the 11788 optimizers to determine whether or not two declarations are the 11789 same, even though some of the existing optimizers do use it in that 11790 way. These uses will be removed over time. 11791 11792'DECL_ARGUMENTS' 11793 This macro returns the 'PARM_DECL' for the first argument to the 11794 function. Subsequent 'PARM_DECL' nodes can be obtained by 11795 following the 'TREE_CHAIN' links. 11796 11797'DECL_RESULT' 11798 This macro returns the 'RESULT_DECL' for the function. 11799 11800'DECL_SAVED_TREE' 11801 This macro returns the complete body of the function. 11802 11803'TREE_TYPE' 11804 This macro returns the 'FUNCTION_TYPE' or 'METHOD_TYPE' for the 11805 function. 11806 11807'DECL_INITIAL' 11808 A function that has a definition in the current translation unit 11809 will have a non-'NULL' 'DECL_INITIAL'. However, back ends should 11810 not make use of the particular value given by 'DECL_INITIAL'. 11811 11812 It should contain a tree of 'BLOCK' nodes that mirrors the scopes 11813 that variables are bound in the function. Each block contains a 11814 list of decls declared in a basic block, a pointer to a chain of 11815 blocks at the next lower scope level, then a pointer to the next 11816 block at the same level and a backpointer to the parent 'BLOCK' or 11817 'FUNCTION_DECL'. So given a function as follows: 11818 11819 void foo() 11820 { 11821 int a; 11822 { 11823 int b; 11824 } 11825 int c; 11826 } 11827 11828 you would get the following: 11829 11830 tree foo = FUNCTION_DECL; 11831 tree decl_a = VAR_DECL; 11832 tree decl_b = VAR_DECL; 11833 tree decl_c = VAR_DECL; 11834 tree block_a = BLOCK; 11835 tree block_b = BLOCK; 11836 tree block_c = BLOCK; 11837 BLOCK_VARS(block_a) = decl_a; 11838 BLOCK_SUBBLOCKS(block_a) = block_b; 11839 BLOCK_CHAIN(block_a) = block_c; 11840 BLOCK_SUPERCONTEXT(block_a) = foo; 11841 BLOCK_VARS(block_b) = decl_b; 11842 BLOCK_SUPERCONTEXT(block_b) = block_a; 11843 BLOCK_VARS(block_c) = decl_c; 11844 BLOCK_SUPERCONTEXT(block_c) = foo; 11845 DECL_INITIAL(foo) = block_a; 11846 11847 11848File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 11849 1185011.8.2 Function Properties 11851-------------------------- 11852 11853To determine the scope of a function, you can use the 'DECL_CONTEXT' 11854macro. This macro will return the class (either a 'RECORD_TYPE' or a 11855'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 11856a member. For a virtual function, this macro returns the class in which 11857the function was actually defined, not the base class in which the 11858virtual declaration occurred. 11859 11860 In C, the 'DECL_CONTEXT' for a function maybe another function. This 11861representation indicates that the GNU nested function extension is in 11862use. For details on the semantics of nested functions, see the GCC 11863Manual. The nested function can refer to local variables in its 11864containing function. Such references are not explicitly marked in the 11865tree structure; back ends must look at the 'DECL_CONTEXT' for the 11866referenced 'VAR_DECL'. If the 'DECL_CONTEXT' for the referenced 11867'VAR_DECL' is not the same as the function currently being processed, 11868and neither 'DECL_EXTERNAL' nor 'TREE_STATIC' hold, then the reference 11869is to a local variable in a containing function, and the back end must 11870take appropriate action. 11871 11872'DECL_EXTERNAL' 11873 This predicate holds if the function is undefined. 11874 11875'TREE_PUBLIC' 11876 This predicate holds if the function has external linkage. 11877 11878'TREE_STATIC' 11879 This predicate holds if the function has been defined. 11880 11881'TREE_THIS_VOLATILE' 11882 This predicate holds if the function does not return normally. 11883 11884'TREE_READONLY' 11885 This predicate holds if the function can only read its arguments. 11886 11887'DECL_PURE_P' 11888 This predicate holds if the function can only read its arguments, 11889 but may also read global memory. 11890 11891'DECL_VIRTUAL_P' 11892 This predicate holds if the function is virtual. 11893 11894'DECL_ARTIFICIAL' 11895 This macro holds if the function was implicitly generated by the 11896 compiler, rather than explicitly declared. In addition to 11897 implicitly generated class member functions, this macro holds for 11898 the special functions created to implement static initialization 11899 and destruction, to compute run-time type information, and so 11900 forth. 11901 11902'DECL_FUNCTION_SPECIFIC_TARGET' 11903 This macro returns a tree node that holds the target options that 11904 are to be used to compile this particular function or 'NULL_TREE' 11905 if the function is to be compiled with the target options specified 11906 on the command line. 11907 11908'DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 11909 This macro returns a tree node that holds the optimization options 11910 that are to be used to compile this particular function or 11911 'NULL_TREE' if the function is to be compiled with the optimization 11912 options specified on the command line. 11913 11914 11915File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 11916 1191711.9 Language-dependent trees 11918============================= 11919 11920Front ends may wish to keep some state associated with various GENERIC 11921trees while parsing. To support this, trees provide a set of flags that 11922may be used by the front end. They are accessed using 11923'TREE_LANG_FLAG_n' where 'n' is currently 0 through 6. 11924 11925 If necessary, a front end can use some language-dependent tree codes in 11926its GENERIC representation, so long as it provides a hook for converting 11927them to GIMPLE and doesn't expect them to work with any (hypothetical) 11928optimizers that run before the conversion to GIMPLE. The intermediate 11929representation used while parsing C and C++ looks very little like 11930GENERIC, but the C and C++ gimplifier hooks are perfectly happy to take 11931it as input and spit out GIMPLE. 11932 11933 11934File: gccint.info, Node: C and C++ Trees, Prev: Language-dependent trees, Up: GENERIC 11935 1193611.10 C and C++ Trees 11937===================== 11938 11939This section documents the internal representation used by GCC to 11940represent C and C++ source programs. When presented with a C or C++ 11941source program, GCC parses the program, performs semantic analysis 11942(including the generation of error messages), and then produces the 11943internal representation described here. This representation contains a 11944complete representation for the entire translation unit provided as 11945input to the front end. This representation is then typically processed 11946by a code-generator in order to produce machine code, but could also be 11947used in the creation of source browsers, intelligent editors, automatic 11948documentation generators, interpreters, and any other programs needing 11949the ability to process C or C++ code. 11950 11951 This section explains the internal representation. In particular, it 11952documents the internal representation for C and C++ source constructs, 11953and the macros, functions, and variables that can be used to access 11954these constructs. The C++ representation is largely a superset of the 11955representation used in the C front end. There is only one construct 11956used in C that does not appear in the C++ front end and that is the GNU 11957"nested function" extension. Many of the macros documented here do not 11958apply in C because the corresponding language constructs do not appear 11959in C. 11960 11961 The C and C++ front ends generate a mix of GENERIC trees and ones 11962specific to C and C++. These language-specific trees are higher-level 11963constructs than the ones in GENERIC to make the parser's job easier. 11964This section describes those trees that aren't part of GENERIC as well 11965as aspects of GENERIC trees that are treated in a language-specific 11966manner. 11967 11968 If you are developing a "back end", be it is a code-generator or some 11969other tool, that uses this representation, you may occasionally find 11970that you need to ask questions not easily answered by the functions and 11971macros available here. If that situation occurs, it is quite likely 11972that GCC already supports the functionality you desire, but that the 11973interface is simply not documented here. In that case, you should ask 11974the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting 11975the functionality you require. Similarly, if you find yourself writing 11976functions that do not deal directly with your back end, but instead 11977might be useful to other people using the GCC front end, you should 11978submit your patches for inclusion in GCC. 11979 11980* Menu: 11981 11982* Types for C++:: Fundamental and aggregate types. 11983* Namespaces:: Namespaces. 11984* Classes:: Classes. 11985* Functions for C++:: Overloading and accessors for C++. 11986* Statements for C++:: Statements specific to C and C++. 11987* C++ Expressions:: From 'typeid' to 'throw'. 11988 11989 11990File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 11991 1199211.10.1 Types for C++ 11993--------------------- 11994 11995In C++, an array type is not qualified; rather the type of the array 11996elements is qualified. This situation is reflected in the intermediate 11997representation. The macros described here will always examine the 11998qualification of the underlying element type when applied to an array 11999type. (If the element type is itself an array, then the recursion 12000continues until a non-array type is found, and the qualification of this 12001type is examined.) So, for example, 'CP_TYPE_CONST_P' will hold of the 12002type 'const int ()[7]', denoting an array of seven 'int's. 12003 12004 The following functions and macros deal with cv-qualification of types: 12005'cp_type_quals' 12006 This function returns the set of type qualifiers applied to this 12007 type. This value is 'TYPE_UNQUALIFIED' if no qualifiers have been 12008 applied. The 'TYPE_QUAL_CONST' bit is set if the type is 12009 'const'-qualified. The 'TYPE_QUAL_VOLATILE' bit is set if the type 12010 is 'volatile'-qualified. The 'TYPE_QUAL_RESTRICT' bit is set if 12011 the type is 'restrict'-qualified. 12012 12013'CP_TYPE_CONST_P' 12014 This macro holds if the type is 'const'-qualified. 12015 12016'CP_TYPE_VOLATILE_P' 12017 This macro holds if the type is 'volatile'-qualified. 12018 12019'CP_TYPE_RESTRICT_P' 12020 This macro holds if the type is 'restrict'-qualified. 12021 12022'CP_TYPE_CONST_NON_VOLATILE_P' 12023 This predicate holds for a type that is 'const'-qualified, but 12024 _not_ 'volatile'-qualified; other cv-qualifiers are ignored as 12025 well: only the 'const'-ness is tested. 12026 12027 A few other macros and functions are usable with all types: 12028'TYPE_SIZE' 12029 The number of bits required to represent the type, represented as 12030 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 12031 'NULL_TREE'. 12032 12033'TYPE_ALIGN' 12034 The alignment of the type, in bits, represented as an 'int'. 12035 12036'TYPE_NAME' 12037 This macro returns a declaration (in the form of a 'TYPE_DECL') for 12038 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 12039 as you might expect, given its name!) You can look at the 12040 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 12041 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 12042 built-in type, the result of a typedef, or a named class type. 12043 12044'CP_INTEGRAL_TYPE' 12045 This predicate holds if the type is an integral type. Notice that 12046 in C++, enumerations are _not_ integral types. 12047 12048'ARITHMETIC_TYPE_P' 12049 This predicate holds if the type is an integral type (in the C++ 12050 sense) or a floating point type. 12051 12052'CLASS_TYPE_P' 12053 This predicate holds for a class-type. 12054 12055'TYPE_BUILT_IN' 12056 This predicate holds for a built-in type. 12057 12058'TYPE_PTRDATAMEM_P' 12059 This predicate holds if the type is a pointer to data member. 12060 12061'TYPE_PTR_P' 12062 This predicate holds if the type is a pointer type, and the pointee 12063 is not a data member. 12064 12065'TYPE_PTRFN_P' 12066 This predicate holds for a pointer to function type. 12067 12068'TYPE_PTROB_P' 12069 This predicate holds for a pointer to object type. Note however 12070 that it does not hold for the generic pointer to object type 'void 12071 *'. You may use 'TYPE_PTROBV_P' to test for a pointer to object 12072 type as well as 'void *'. 12073 12074 The table below describes types specific to C and C++ as well as 12075language-dependent info about GENERIC types. 12076 12077'POINTER_TYPE' 12078 Used to represent pointer types, and pointer to data member types. 12079 If 'TREE_TYPE' is a pointer to data member type, then 12080 'TYPE_PTRDATAMEM_P' will hold. For a pointer to data member type 12081 of the form 'T X::*', 'TYPE_PTRMEM_CLASS_TYPE' will be the type 12082 'X', while 'TYPE_PTRMEM_POINTED_TO_TYPE' will be the type 'T'. 12083 12084'RECORD_TYPE' 12085 Used to represent 'struct' and 'class' types in C and C++. If 12086 'TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 12087 type. In that case, the 'TYPE_PTRMEMFUNC_FN_TYPE' is a 12088 'POINTER_TYPE' pointing to a 'METHOD_TYPE'. The 'METHOD_TYPE' is 12089 the type of a function pointed to by the pointer-to-member 12090 function. If 'TYPE_PTRMEMFUNC_P' does not hold, this type is a 12091 class type. For more information, *note Classes::. 12092 12093'UNKNOWN_TYPE' 12094 This node is used to represent a type the knowledge of which is 12095 insufficient for a sound processing. 12096 12097'TYPENAME_TYPE' 12098 Used to represent a construct of the form 'typename T::A'. The 12099 'TYPE_CONTEXT' is 'T'; the 'TYPE_NAME' is an 'IDENTIFIER_NODE' for 12100 'A'. If the type is specified via a template-id, then 12101 'TYPENAME_TYPE_FULLNAME' yields a 'TEMPLATE_ID_EXPR'. The 12102 'TREE_TYPE' is non-'NULL' if the node is implicitly generated in 12103 support for the implicit typename extension; in which case the 12104 'TREE_TYPE' is a type node for the base-class. 12105 12106'TYPEOF_TYPE' 12107 Used to represent the '__typeof__' extension. The 'TYPE_FIELDS' is 12108 the expression the type of which is being represented. 12109 12110 12111File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 12112 1211311.10.2 Namespaces 12114------------------ 12115 12116The root of the entire intermediate representation is the variable 12117'global_namespace'. This is the namespace specified with '::' in C++ 12118source code. All other namespaces, types, variables, functions, and so 12119forth can be found starting with this namespace. 12120 12121 However, except for the fact that it is distinguished as the root of 12122the representation, the global namespace is no different from any other 12123namespace. Thus, in what follows, we describe namespaces generally, 12124rather than the global namespace in particular. 12125 12126 A namespace is represented by a 'NAMESPACE_DECL' node. 12127 12128 The following macros and functions can be used on a 'NAMESPACE_DECL': 12129 12130'DECL_NAME' 12131 This macro is used to obtain the 'IDENTIFIER_NODE' corresponding to 12132 the unqualified name of the name of the namespace (*note 12133 Identifiers::). The name of the global namespace is '::', even 12134 though in C++ the global namespace is unnamed. However, you should 12135 use comparison with 'global_namespace', rather than 'DECL_NAME' to 12136 determine whether or not a namespace is the global one. An unnamed 12137 namespace will have a 'DECL_NAME' equal to 12138 'anonymous_namespace_name'. Within a single translation unit, all 12139 unnamed namespaces will have the same name. 12140 12141'DECL_CONTEXT' 12142 This macro returns the enclosing namespace. The 'DECL_CONTEXT' for 12143 the 'global_namespace' is 'NULL_TREE'. 12144 12145'DECL_NAMESPACE_ALIAS' 12146 If this declaration is for a namespace alias, then 12147 'DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 12148 alias. 12149 12150 Do not attempt to use 'cp_namespace_decls' for a namespace which is 12151 an alias. Instead, follow 'DECL_NAMESPACE_ALIAS' links until you 12152 reach an ordinary, non-alias, namespace, and call 12153 'cp_namespace_decls' there. 12154 12155'DECL_NAMESPACE_STD_P' 12156 This predicate holds if the namespace is the special '::std' 12157 namespace. 12158 12159'cp_namespace_decls' 12160 This function will return the declarations contained in the 12161 namespace, including types, overloaded functions, other namespaces, 12162 and so forth. If there are no declarations, this function will 12163 return 'NULL_TREE'. The declarations are connected through their 12164 'TREE_CHAIN' fields. 12165 12166 Although most entries on this list will be declarations, 12167 'TREE_LIST' nodes may also appear. In this case, the 'TREE_VALUE' 12168 will be an 'OVERLOAD'. The value of the 'TREE_PURPOSE' is 12169 unspecified; back ends should ignore this value. As with the other 12170 kinds of declarations returned by 'cp_namespace_decls', the 12171 'TREE_CHAIN' will point to the next declaration in this list. 12172 12173 For more information on the kinds of declarations that can occur on 12174 this list, *Note Declarations::. Some declarations will not appear 12175 on this list. In particular, no 'FIELD_DECL', 'LABEL_DECL', or 12176 'PARM_DECL' nodes will appear here. 12177 12178 This function cannot be used with namespaces that have 12179 'DECL_NAMESPACE_ALIAS' set. 12180 12181 12182File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 12183 1218411.10.3 Classes 12185--------------- 12186 12187Besides namespaces, the other high-level scoping construct in C++ is the 12188class. (Throughout this manual the term "class" is used to mean the 12189types referred to in the ANSI/ISO C++ Standard as classes; these include 12190types defined with the 'class', 'struct', and 'union' keywords.) 12191 12192 A class type is represented by either a 'RECORD_TYPE' or a 12193'UNION_TYPE'. A class declared with the 'union' tag is represented by a 12194'UNION_TYPE', while classes declared with either the 'struct' or the 12195'class' tag are represented by 'RECORD_TYPE's. You can use the 12196'CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 12197type is a 'class' as opposed to a 'struct'. This macro will be true 12198only for classes declared with the 'class' tag. 12199 12200 Almost all members are available on the 'TYPE_FIELDS' list. Given one 12201member, the next can be found by following the 'TREE_CHAIN'. You should 12202not depend in any way on the order in which fields appear on this list. 12203All nodes on this list will be 'DECL' nodes. A 'FIELD_DECL' is used to 12204represent a non-static data member, a 'VAR_DECL' is used to represent a 12205static data member, and a 'TYPE_DECL' is used to represent a type. Note 12206that the 'CONST_DECL' for an enumeration constant will appear on this 12207list, if the enumeration type was declared in the class. (Of course, 12208the 'TYPE_DECL' for the enumeration type will appear here as well.) 12209There are no entries for base classes on this list. In particular, 12210there is no 'FIELD_DECL' for the "base-class portion" of an object. If 12211a function member is overloaded, each of the overloaded functions 12212appears; no 'OVERLOAD' nodes appear on the 'TYPE_FIELDS' list. 12213Implicitly declared functions (including default constructors, copy 12214constructors, assignment operators, and destructors) will appear on this 12215list as well. 12216 12217 The 'TYPE_VFIELD' is a compiler-generated field used to point to 12218virtual function tables. It may or may not appear on the 'TYPE_FIELDS' 12219list. However, back ends should handle the 'TYPE_VFIELD' just like all 12220the entries on the 'TYPE_FIELDS' list. 12221 12222 Every class has an associated "binfo", which can be obtained with 12223'TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 12224given by 'TYPE_BINFO' is the degenerate case, whereby every class is 12225considered to be its own base-class. The base binfos for a particular 12226binfo are held in a vector, whose length is obtained with 12227'BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 12228'BINFO_BASE_BINFO' and 'BINFO_BASE_ITERATE'. To add a new binfo, use 12229'BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 12230'BINFO_BASE_BINFOS', but normally you do not need to use that. The 12231class type associated with a binfo is given by 'BINFO_TYPE'. It is not 12232always the case that 'BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 12233and qualified types. Neither is it the case that 'TYPE_BINFO 12234(BINFO_TYPE (y))' is the same binfo as 'y'. The reason is that if 'y' 12235is a binfo representing a base-class 'B' of a derived class 'D', then 12236'BINFO_TYPE (y)' will be 'B', and 'TYPE_BINFO (BINFO_TYPE (y))' will be 12237'B' as its own base-class, rather than as a base-class of 'D'. 12238 12239 The access to a base type can be found with 'BINFO_BASE_ACCESS'. This 12240will produce 'access_public_node', 'access_private_node' or 12241'access_protected_node'. If bases are always public, 12242'BINFO_BASE_ACCESSES' may be 'NULL'. 12243 12244 'BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 12245virtually or not. The other flags, 'BINFO_FLAG_0' to 'BINFO_FLAG_6', 12246can be used for language specific use. 12247 12248 The following macros can be used on a tree node representing a 12249class-type. 12250 12251'LOCAL_CLASS_P' 12252 This predicate holds if the class is local class _i.e._ declared 12253 inside a function body. 12254 12255'TYPE_POLYMORPHIC_P' 12256 This predicate holds if the class has at least one virtual function 12257 (declared or inherited). 12258 12259'TYPE_HAS_DEFAULT_CONSTRUCTOR' 12260 This predicate holds whenever its argument represents a class-type 12261 with default constructor. 12262 12263'CLASSTYPE_HAS_MUTABLE' 12264'TYPE_HAS_MUTABLE_P' 12265 These predicates hold for a class-type having a mutable data 12266 member. 12267 12268'CLASSTYPE_NON_POD_P' 12269 This predicate holds only for class-types that are not PODs. 12270 12271'TYPE_HAS_NEW_OPERATOR' 12272 This predicate holds for a class-type that defines 'operator new'. 12273 12274'TYPE_HAS_ARRAY_NEW_OPERATOR' 12275 This predicate holds for a class-type for which 'operator new[]' is 12276 defined. 12277 12278'TYPE_OVERLOADS_CALL_EXPR' 12279 This predicate holds for class-type for which the function call 12280 'operator()' is overloaded. 12281 12282'TYPE_OVERLOADS_ARRAY_REF' 12283 This predicate holds for a class-type that overloads 'operator[]' 12284 12285'TYPE_OVERLOADS_ARROW' 12286 This predicate holds for a class-type for which 'operator->' is 12287 overloaded. 12288 12289 12290File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees 12291 1229211.10.4 Functions for C++ 12293------------------------- 12294 12295A function is represented by a 'FUNCTION_DECL' node. A set of 12296overloaded functions is sometimes represented by an 'OVERLOAD' node. 12297 12298 An 'OVERLOAD' node is not a declaration, so none of the 'DECL_' macros 12299should be used on an 'OVERLOAD'. An 'OVERLOAD' node is similar to a 12300'TREE_LIST'. Use 'OVL_CURRENT' to get the function associated with an 12301'OVERLOAD' node; use 'OVL_NEXT' to get the next 'OVERLOAD' node in the 12302list of overloaded functions. The macros 'OVL_CURRENT' and 'OVL_NEXT' 12303are actually polymorphic; you can use them to work with 'FUNCTION_DECL' 12304nodes as well as with overloads. In the case of a 'FUNCTION_DECL', 12305'OVL_CURRENT' will always return the function itself, and 'OVL_NEXT' 12306will always be 'NULL_TREE'. 12307 12308 To determine the scope of a function, you can use the 'DECL_CONTEXT' 12309macro. This macro will return the class (either a 'RECORD_TYPE' or a 12310'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 12311a member. For a virtual function, this macro returns the class in which 12312the function was actually defined, not the base class in which the 12313virtual declaration occurred. 12314 12315 If a friend function is defined in a class scope, the 12316'DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 12317it was defined. For example, in 12318 class C { friend void f() {} }; 12319the 'DECL_CONTEXT' for 'f' will be the 'global_namespace', but the 12320'DECL_FRIEND_CONTEXT' will be the 'RECORD_TYPE' for 'C'. 12321 12322 The following macros and functions can be used on a 'FUNCTION_DECL': 12323'DECL_MAIN_P' 12324 This predicate holds for a function that is the program entry point 12325 '::code'. 12326 12327'DECL_LOCAL_FUNCTION_P' 12328 This predicate holds if the function was declared at block scope, 12329 even though it has a global scope. 12330 12331'DECL_ANTICIPATED' 12332 This predicate holds if the function is a built-in function but its 12333 prototype is not yet explicitly declared. 12334 12335'DECL_EXTERN_C_FUNCTION_P' 12336 This predicate holds if the function is declared as an ''extern 12337 "C"'' function. 12338 12339'DECL_LINKONCE_P' 12340 This macro holds if multiple copies of this function may be emitted 12341 in various translation units. It is the responsibility of the 12342 linker to merge the various copies. Template instantiations are 12343 the most common example of functions for which 'DECL_LINKONCE_P' 12344 holds; G++ instantiates needed templates in all translation units 12345 which require them, and then relies on the linker to remove 12346 duplicate instantiations. 12347 12348 FIXME: This macro is not yet implemented. 12349 12350'DECL_FUNCTION_MEMBER_P' 12351 This macro holds if the function is a member of a class, rather 12352 than a member of a namespace. 12353 12354'DECL_STATIC_FUNCTION_P' 12355 This predicate holds if the function a static member function. 12356 12357'DECL_NONSTATIC_MEMBER_FUNCTION_P' 12358 This macro holds for a non-static member function. 12359 12360'DECL_CONST_MEMFUNC_P' 12361 This predicate holds for a 'const'-member function. 12362 12363'DECL_VOLATILE_MEMFUNC_P' 12364 This predicate holds for a 'volatile'-member function. 12365 12366'DECL_CONSTRUCTOR_P' 12367 This macro holds if the function is a constructor. 12368 12369'DECL_NONCONVERTING_P' 12370 This predicate holds if the constructor is a non-converting 12371 constructor. 12372 12373'DECL_COMPLETE_CONSTRUCTOR_P' 12374 This predicate holds for a function which is a constructor for an 12375 object of a complete type. 12376 12377'DECL_BASE_CONSTRUCTOR_P' 12378 This predicate holds for a function which is a constructor for a 12379 base class sub-object. 12380 12381'DECL_COPY_CONSTRUCTOR_P' 12382 This predicate holds for a function which is a copy-constructor. 12383 12384'DECL_DESTRUCTOR_P' 12385 This macro holds if the function is a destructor. 12386 12387'DECL_COMPLETE_DESTRUCTOR_P' 12388 This predicate holds if the function is the destructor for an 12389 object a complete type. 12390 12391'DECL_OVERLOADED_OPERATOR_P' 12392 This macro holds if the function is an overloaded operator. 12393 12394'DECL_CONV_FN_P' 12395 This macro holds if the function is a type-conversion operator. 12396 12397'DECL_GLOBAL_CTOR_P' 12398 This predicate holds if the function is a file-scope initialization 12399 function. 12400 12401'DECL_GLOBAL_DTOR_P' 12402 This predicate holds if the function is a file-scope finalization 12403 function. 12404 12405'DECL_THUNK_P' 12406 This predicate holds if the function is a thunk. 12407 12408 These functions represent stub code that adjusts the 'this' pointer 12409 and then jumps to another function. When the jumped-to function 12410 returns, control is transferred directly to the caller, without 12411 returning to the thunk. The first parameter to the thunk is always 12412 the 'this' pointer; the thunk should add 'THUNK_DELTA' to this 12413 value. (The 'THUNK_DELTA' is an 'int', not an 'INTEGER_CST'.) 12414 12415 Then, if 'THUNK_VCALL_OFFSET' (an 'INTEGER_CST') is nonzero the 12416 adjusted 'this' pointer must be adjusted again. The complete 12417 calculation is given by the following pseudo-code: 12418 12419 this += THUNK_DELTA 12420 if (THUNK_VCALL_OFFSET) 12421 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 12422 12423 Finally, the thunk should jump to the location given by 12424 'DECL_INITIAL'; this will always be an expression for the address 12425 of a function. 12426 12427'DECL_NON_THUNK_FUNCTION_P' 12428 This predicate holds if the function is _not_ a thunk function. 12429 12430'GLOBAL_INIT_PRIORITY' 12431 If either 'DECL_GLOBAL_CTOR_P' or 'DECL_GLOBAL_DTOR_P' holds, then 12432 this gives the initialization priority for the function. The 12433 linker will arrange that all functions for which 12434 'DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 12435 before 'main' is called. When the program exits, all functions for 12436 which 'DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 12437 12438'TYPE_RAISES_EXCEPTIONS' 12439 This macro returns the list of exceptions that a (member-)function 12440 can raise. The returned list, if non 'NULL', is comprised of nodes 12441 whose 'TREE_VALUE' represents a type. 12442 12443'TYPE_NOTHROW_P' 12444 This predicate holds when the exception-specification of its 12445 arguments is of the form ''()''. 12446 12447'DECL_ARRAY_DELETE_OPERATOR_P' 12448 This predicate holds if the function an overloaded 'operator 12449 delete[]'. 12450 12451 12452File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 12453 1245411.10.5 Statements for C++ 12455-------------------------- 12456 12457A function that has a definition in the current translation unit will 12458have a non-'NULL' 'DECL_INITIAL'. However, back ends should not make 12459use of the particular value given by 'DECL_INITIAL'. 12460 12461 The 'DECL_SAVED_TREE' macro will give the complete body of the 12462function. 12463 1246411.10.5.1 Statements 12465.................... 12466 12467There are tree nodes corresponding to all of the source-level statement 12468constructs, used within the C and C++ frontends. These are enumerated 12469here, together with a list of the various macros that can be used to 12470obtain information about them. There are a few macros that can be used 12471with all statements: 12472 12473'STMT_IS_FULL_EXPR_P' 12474 In C++, statements normally constitute "full expressions"; 12475 temporaries created during a statement are destroyed when the 12476 statement is complete. However, G++ sometimes represents 12477 expressions by statements; these statements will not have 12478 'STMT_IS_FULL_EXPR_P' set. Temporaries created during such 12479 statements should be destroyed when the innermost enclosing 12480 statement with 'STMT_IS_FULL_EXPR_P' set is exited. 12481 12482 Here is the list of the various statement nodes, and the macros used to 12483access them. This documentation describes the use of these nodes in 12484non-template functions (including instantiations of template functions). 12485In template functions, the same nodes are used, but sometimes in 12486slightly different ways. 12487 12488 Many of the statements have substatements. For example, a 'while' loop 12489will have a body, which is itself a statement. If the substatement is 12490'NULL_TREE', it is considered equivalent to a statement consisting of a 12491single ';', i.e., an expression statement in which the expression has 12492been omitted. A substatement may in fact be a list of statements, 12493connected via their 'TREE_CHAIN's. So, you should always process the 12494statement tree by looping over substatements, like this: 12495 void process_stmt (stmt) 12496 tree stmt; 12497 { 12498 while (stmt) 12499 { 12500 switch (TREE_CODE (stmt)) 12501 { 12502 case IF_STMT: 12503 process_stmt (THEN_CLAUSE (stmt)); 12504 /* More processing here. */ 12505 break; 12506 12507 ... 12508 } 12509 12510 stmt = TREE_CHAIN (stmt); 12511 } 12512 } 12513 In other words, while the 'then' clause of an 'if' statement in C++ can 12514be only one statement (although that one statement may be a compound 12515statement), the intermediate representation will sometimes use several 12516statements chained together. 12517 12518'BREAK_STMT' 12519 12520 Used to represent a 'break' statement. There are no additional 12521 fields. 12522 12523'CLEANUP_STMT' 12524 12525 Used to represent an action that should take place upon exit from 12526 the enclosing scope. Typically, these actions are calls to 12527 destructors for local objects, but back ends cannot rely on this 12528 fact. If these nodes are in fact representing such destructors, 12529 'CLEANUP_DECL' will be the 'VAR_DECL' destroyed. Otherwise, 12530 'CLEANUP_DECL' will be 'NULL_TREE'. In any case, the 12531 'CLEANUP_EXPR' is the expression to execute. The cleanups executed 12532 on exit from a scope should be run in the reverse order of the 12533 order in which the associated 'CLEANUP_STMT's were encountered. 12534 12535'CONTINUE_STMT' 12536 12537 Used to represent a 'continue' statement. There are no additional 12538 fields. 12539 12540'CTOR_STMT' 12541 12542 Used to mark the beginning (if 'CTOR_BEGIN_P' holds) or end (if 12543 'CTOR_END_P' holds of the main body of a constructor. See also 12544 'SUBOBJECT' for more information on how to use these nodes. 12545 12546'DO_STMT' 12547 12548 Used to represent a 'do' loop. The body of the loop is given by 12549 'DO_BODY' while the termination condition for the loop is given by 12550 'DO_COND'. The condition for a 'do'-statement is always an 12551 expression. 12552 12553'EMPTY_CLASS_EXPR' 12554 12555 Used to represent a temporary object of a class with no data whose 12556 address is never taken. (All such objects are interchangeable.) 12557 The 'TREE_TYPE' represents the type of the object. 12558 12559'EXPR_STMT' 12560 12561 Used to represent an expression statement. Use 'EXPR_STMT_EXPR' to 12562 obtain the expression. 12563 12564'FOR_STMT' 12565 12566 Used to represent a 'for' statement. The 'FOR_INIT_STMT' is the 12567 initialization statement for the loop. The 'FOR_COND' is the 12568 termination condition. The 'FOR_EXPR' is the expression executed 12569 right before the 'FOR_COND' on each loop iteration; often, this 12570 expression increments a counter. The body of the loop is given by 12571 'FOR_BODY'. Note that 'FOR_INIT_STMT' and 'FOR_BODY' return 12572 statements, while 'FOR_COND' and 'FOR_EXPR' return expressions. 12573 12574'HANDLER' 12575 12576 Used to represent a C++ 'catch' block. The 'HANDLER_TYPE' is the 12577 type of exception that will be caught by this handler; it is equal 12578 (by pointer equality) to 'NULL' if this handler is for all types. 12579 'HANDLER_PARMS' is the 'DECL_STMT' for the catch parameter, and 12580 'HANDLER_BODY' is the code for the block itself. 12581 12582'IF_STMT' 12583 12584 Used to represent an 'if' statement. The 'IF_COND' is the 12585 expression. 12586 12587 If the condition is a 'TREE_LIST', then the 'TREE_PURPOSE' is a 12588 statement (usually a 'DECL_STMT'). Each time the condition is 12589 evaluated, the statement should be executed. Then, the 12590 'TREE_VALUE' should be used as the conditional expression itself. 12591 This representation is used to handle C++ code like this: 12592 12593 C++ distinguishes between this and 'COND_EXPR' for handling 12594 templates. 12595 12596 if (int i = 7) ... 12597 12598 where there is a new local variable (or variables) declared within 12599 the condition. 12600 12601 The 'THEN_CLAUSE' represents the statement given by the 'then' 12602 condition, while the 'ELSE_CLAUSE' represents the statement given 12603 by the 'else' condition. 12604 12605'SUBOBJECT' 12606 12607 In a constructor, these nodes are used to mark the point at which a 12608 subobject of 'this' is fully constructed. If, after this point, an 12609 exception is thrown before a 'CTOR_STMT' with 'CTOR_END_P' set is 12610 encountered, the 'SUBOBJECT_CLEANUP' must be executed. The 12611 cleanups must be executed in the reverse order in which they 12612 appear. 12613 12614'SWITCH_STMT' 12615 12616 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 12617 the expression on which the switch is occurring. See the 12618 documentation for an 'IF_STMT' for more information on the 12619 representation used for the condition. The 'SWITCH_STMT_BODY' is 12620 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 12621 original type of switch expression as given in the source, before 12622 any compiler conversions. 12623 12624'TRY_BLOCK' 12625 Used to represent a 'try' block. The body of the try block is 12626 given by 'TRY_STMTS'. Each of the catch blocks is a 'HANDLER' 12627 node. The first handler is given by 'TRY_HANDLERS'. Subsequent 12628 handlers are obtained by following the 'TREE_CHAIN' link from one 12629 handler to the next. The body of the handler is given by 12630 'HANDLER_BODY'. 12631 12632 If 'CLEANUP_P' holds of the 'TRY_BLOCK', then the 'TRY_HANDLERS' 12633 will not be a 'HANDLER' node. Instead, it will be an expression 12634 that should be executed if an exception is thrown in the try block. 12635 It must rethrow the exception after executing that code. And, if 12636 an exception is thrown while the expression is executing, 12637 'terminate' must be called. 12638 12639'USING_STMT' 12640 Used to represent a 'using' directive. The namespace is given by 12641 'USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 12642 is needed inside template functions, to implement using directives 12643 during instantiation. 12644 12645'WHILE_STMT' 12646 12647 Used to represent a 'while' loop. The 'WHILE_COND' is the 12648 termination condition for the loop. See the documentation for an 12649 'IF_STMT' for more information on the representation used for the 12650 condition. 12651 12652 The 'WHILE_BODY' is the body of the loop. 12653 12654 12655File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees 12656 1265711.10.6 C++ Expressions 12658----------------------- 12659 12660This section describes expressions specific to the C and C++ front ends. 12661 12662'TYPEID_EXPR' 12663 12664 Used to represent a 'typeid' expression. 12665 12666'NEW_EXPR' 12667'VEC_NEW_EXPR' 12668 12669 Used to represent a call to 'new' and 'new[]' respectively. 12670 12671'DELETE_EXPR' 12672'VEC_DELETE_EXPR' 12673 12674 Used to represent a call to 'delete' and 'delete[]' respectively. 12675 12676'MEMBER_REF' 12677 12678 Represents a reference to a member of a class. 12679 12680'THROW_EXPR' 12681 12682 Represents an instance of 'throw' in the program. Operand 0, which 12683 is the expression to throw, may be 'NULL_TREE'. 12684 12685'AGGR_INIT_EXPR' 12686 An 'AGGR_INIT_EXPR' represents the initialization as the return 12687 value of a function call, or as the result of a constructor. An 12688 'AGGR_INIT_EXPR' will only appear as a full-expression, or as the 12689 second operand of a 'TARGET_EXPR'. 'AGGR_INIT_EXPR's have a 12690 representation similar to that of 'CALL_EXPR's. You can use the 12691 'AGGR_INIT_EXPR_FN' and 'AGGR_INIT_EXPR_ARG' macros to access the 12692 function to call and the arguments to pass. 12693 12694 If 'AGGR_INIT_VIA_CTOR_P' holds of the 'AGGR_INIT_EXPR', then the 12695 initialization is via a constructor call. The address of the 12696 'AGGR_INIT_EXPR_SLOT' operand, which is always a 'VAR_DECL', is 12697 taken, and this value replaces the first argument in the argument 12698 list. 12699 12700 In either case, the expression is void. 12701 12702 12703File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 12704 1270512 GIMPLE 12706********* 12707 12708GIMPLE is a three-address representation derived from GENERIC by 12709breaking down GENERIC expressions into tuples of no more than 3 operands 12710(with some exceptions like function calls). GIMPLE was heavily 12711influenced by the SIMPLE IL used by the McCAT compiler project at McGill 12712University, though we have made some different choices. For one thing, 12713SIMPLE doesn't support 'goto'. 12714 12715 Temporaries are introduced to hold intermediate values needed to 12716compute complex expressions. Additionally, all the control structures 12717used in GENERIC are lowered into conditional jumps, lexical scopes are 12718removed and exception regions are converted into an on the side 12719exception region tree. 12720 12721 The compiler pass which converts GENERIC into GIMPLE is referred to as 12722the 'gimplifier'. The gimplifier works recursively, generating GIMPLE 12723tuples out of the original GENERIC expressions. 12724 12725 One of the early implementation strategies used for the GIMPLE 12726representation was to use the same internal data structures used by 12727front ends to represent parse trees. This simplified implementation 12728because we could leverage existing functionality and interfaces. 12729However, GIMPLE is a much more restrictive representation than abstract 12730syntax trees (AST), therefore it does not require the full structural 12731complexity provided by the main tree data structure. 12732 12733 The GENERIC representation of a function is stored in the 12734'DECL_SAVED_TREE' field of the associated 'FUNCTION_DECL' tree node. It 12735is converted to GIMPLE by a call to 'gimplify_function_tree'. 12736 12737 If a front end wants to include language-specific tree codes in the 12738tree representation which it provides to the back end, it must provide a 12739definition of 'LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 12740front end trees to GIMPLE. Usually such a hook will involve much of the 12741same code for expanding front end trees to RTL. This function can 12742return fully lowered GIMPLE, or it can return GENERIC trees and let the 12743main gimplifier lower them the rest of the way; this is often simpler. 12744GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 12745of the IL before the pass 'pass_lower_cf'. High GIMPLE contains some 12746container statements like lexical scopes (represented by 'GIMPLE_BIND') 12747and nested expressions (e.g., 'GIMPLE_TRY'), while "Low GIMPLE" exposes 12748all of the implicit jumps for control and exception expressions directly 12749in the IL and EH region trees. 12750 12751 The C and C++ front ends currently convert directly from front end 12752trees to GIMPLE, and hand that off to the back end rather than first 12753converting to GENERIC. Their gimplifier hooks know about all the 12754'_STMT' nodes and how to convert them to GENERIC forms. There was some 12755work done on a genericization pass which would run first, but the 12756existence of 'STMT_EXPR' meant that in order to convert all of the C 12757statements into GENERIC equivalents would involve walking the entire 12758tree anyway, so it was simpler to lower all the way. This might change 12759in the future if someone writes an optimization pass which would work 12760better with higher-level trees, but currently the optimizers all expect 12761GIMPLE. 12762 12763 You can request to dump a C-like representation of the GIMPLE form with 12764the flag '-fdump-tree-gimple'. 12765 12766* Menu: 12767 12768* Tuple representation:: 12769* Class hierarchy of GIMPLE statements:: 12770* GIMPLE instruction set:: 12771* GIMPLE Exception Handling:: 12772* Temporaries:: 12773* Operands:: 12774* Manipulating GIMPLE statements:: 12775* Tuple specific accessors:: 12776* GIMPLE sequences:: 12777* Sequence iterators:: 12778* Adding a new GIMPLE statement code:: 12779* Statement and operand traversals:: 12780 12781 12782File: gccint.info, Node: Tuple representation, Next: Class hierarchy of GIMPLE statements, Up: GIMPLE 12783 1278412.1 Tuple representation 12785========================= 12786 12787GIMPLE instructions are tuples of variable size divided in two groups: a 12788header describing the instruction and its locations, and a variable 12789length body with all the operands. Tuples are organized into a 12790hierarchy with 3 main classes of tuples. 12791 1279212.1.1 'gimple' (gsbase) 12793------------------------ 12794 12795This is the root of the hierarchy, it holds basic information needed by 12796most GIMPLE statements. There are some fields that may not be relevant 12797to every GIMPLE statement, but those were moved into the base structure 12798to take advantage of holes left by other fields (thus making the 12799structure more compact). The structure takes 4 words (32 bytes) on 64 12800bit hosts: 12801 12802Field Size (bits) 12803'code' 8 12804'subcode' 16 12805'no_warning' 1 12806'visited' 1 12807'nontemporal_move' 1 12808'plf' 2 12809'modified' 1 12810'has_volatile_ops' 1 12811'references_memory_p' 1 12812'uid' 32 12813'location' 32 12814'num_ops' 32 12815'bb' 64 12816'block' 63 12817Total size 32 bytes 12818 12819 * 'code' Main identifier for a GIMPLE instruction. 12820 12821 * 'subcode' Used to distinguish different variants of the same basic 12822 instruction or provide flags applicable to a given code. The 12823 'subcode' flags field has different uses depending on the code of 12824 the instruction, but mostly it distinguishes instructions of the 12825 same family. The most prominent use of this field is in 12826 assignments, where subcode indicates the operation done on the RHS 12827 of the assignment. For example, a = b + c is encoded as 12828 'GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 12829 12830 * 'no_warning' Bitflag to indicate whether a warning has already been 12831 issued on this statement. 12832 12833 * 'visited' General purpose "visited" marker. Set and cleared by 12834 each pass when needed. 12835 12836 * 'nontemporal_move' Bitflag used in assignments that represent 12837 non-temporal moves. Although this bitflag is only used in 12838 assignments, it was moved into the base to take advantage of the 12839 bit holes left by the previous fields. 12840 12841 * 'plf' Pass Local Flags. This 2-bit mask can be used as general 12842 purpose markers by any pass. Passes are responsible for clearing 12843 and setting these two flags accordingly. 12844 12845 * 'modified' Bitflag to indicate whether the statement has been 12846 modified. Used mainly by the operand scanner to determine when to 12847 re-scan a statement for operands. 12848 12849 * 'has_volatile_ops' Bitflag to indicate whether this statement 12850 contains operands that have been marked volatile. 12851 12852 * 'references_memory_p' Bitflag to indicate whether this statement 12853 contains memory references (i.e., its operands are either global 12854 variables, or pointer dereferences or anything that must reside in 12855 memory). 12856 12857 * 'uid' This is an unsigned integer used by passes that want to 12858 assign IDs to every statement. These IDs must be assigned and used 12859 by each pass. 12860 12861 * 'location' This is a 'location_t' identifier to specify source code 12862 location for this statement. It is inherited from the front end. 12863 12864 * 'num_ops' Number of operands that this statement has. This 12865 specifies the size of the operand vector embedded in the tuple. 12866 Only used in some tuples, but it is declared in the base tuple to 12867 take advantage of the 32-bit hole left by the previous fields. 12868 12869 * 'bb' Basic block holding the instruction. 12870 12871 * 'block' Lexical block holding this statement. Also used for debug 12872 information generation. 12873 1287412.1.2 'gimple_statement_with_ops' 12875---------------------------------- 12876 12877This tuple is actually split in two: 'gimple_statement_with_ops_base' 12878and 'gimple_statement_with_ops'. This is needed to accommodate the way 12879the operand vector is allocated. The operand vector is defined to be an 12880array of 1 element. So, to allocate a dynamic number of operands, the 12881memory allocator ('gimple_alloc') simply allocates enough memory to hold 12882the structure itself plus 'N - 1' operands which run "off the end" of 12883the structure. For example, to allocate space for a tuple with 3 12884operands, 'gimple_alloc' reserves 'sizeof (struct 12885gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 12886 12887 On the other hand, several fields in this tuple need to be shared with 12888the 'gimple_statement_with_memory_ops' tuple. So, these common fields 12889are placed in 'gimple_statement_with_ops_base' which is then inherited 12890from the other two tuples. 12891 12892'gsbase' 256 12893'def_ops' 64 12894'use_ops' 64 12895'op' 'num_ops' * 64 12896Total 48 + 8 * 'num_ops' bytes 12897size 12898 12899 * 'gsbase' Inherited from 'struct gimple'. 12900 12901 * 'def_ops' Array of pointers into the operand array indicating all 12902 the slots that contain a variable written-to by the statement. 12903 This array is also used for immediate use chaining. Note that it 12904 would be possible to not rely on this array, but the changes 12905 required to implement this are pretty invasive. 12906 12907 * 'use_ops' Similar to 'def_ops' but for variables read by the 12908 statement. 12909 12910 * 'op' Array of trees with 'num_ops' slots. 12911 1291212.1.3 'gimple_statement_with_memory_ops' 12913----------------------------------------- 12914 12915This tuple is essentially identical to 'gimple_statement_with_ops', 12916except that it contains 4 additional fields to hold vectors related 12917memory stores and loads. Similar to the previous case, the structure is 12918split in two to accommodate for the operand vector 12919('gimple_statement_with_memory_ops_base' and 12920'gimple_statement_with_memory_ops'). 12921 12922Field Size (bits) 12923'gsbase' 256 12924'def_ops' 64 12925'use_ops' 64 12926'vdef_ops' 64 12927'vuse_ops' 64 12928'stores' 64 12929'loads' 64 12930'op' 'num_ops' * 64 12931Total size 80 + 8 * 'num_ops' bytes 12932 12933 * 'vdef_ops' Similar to 'def_ops' but for 'VDEF' operators. There is 12934 one entry per memory symbol written by this statement. This is 12935 used to maintain the memory SSA use-def and def-def chains. 12936 12937 * 'vuse_ops' Similar to 'use_ops' but for 'VUSE' operators. There is 12938 one entry per memory symbol loaded by this statement. This is used 12939 to maintain the memory SSA use-def chains. 12940 12941 * 'stores' Bitset with all the UIDs for the symbols written-to by the 12942 statement. This is different than 'vdef_ops' in that all the 12943 affected symbols are mentioned in this set. If memory partitioning 12944 is enabled, the 'vdef_ops' vector will refer to memory partitions. 12945 Furthermore, no SSA information is stored in this set. 12946 12947 * 'loads' Similar to 'stores', but for memory loads. (Note that 12948 there is some amount of redundancy here, it should be possible to 12949 reduce memory utilization further by removing these sets). 12950 12951 All the other tuples are defined in terms of these three basic ones. 12952Each tuple will add some fields. 12953 12954 12955File: gccint.info, Node: Class hierarchy of GIMPLE statements, Next: GIMPLE instruction set, Prev: Tuple representation, Up: GIMPLE 12956 1295712.2 Class hierarchy of GIMPLE statements 12958========================================= 12959 12960The following diagram shows the C++ inheritance hierarchy of statement 12961kinds, along with their relationships to 'GSS_' values (layouts) and 12962'GIMPLE_' values (codes): 12963 12964 gimple 12965 | layout: GSS_BASE 12966 | used for 4 codes: GIMPLE_ERROR_MARK 12967 | GIMPLE_NOP 12968 | GIMPLE_OMP_SECTIONS_SWITCH 12969 | GIMPLE_PREDICT 12970 | 12971 + gimple_statement_with_ops_base 12972 | | (no GSS layout) 12973 | | 12974 | + gimple_statement_with_ops 12975 | | | layout: GSS_WITH_OPS 12976 | | | 12977 | | + gcond 12978 | | | code: GIMPLE_COND 12979 | | | 12980 | | + gdebug 12981 | | | code: GIMPLE_DEBUG 12982 | | | 12983 | | + ggoto 12984 | | | code: GIMPLE_GOTO 12985 | | | 12986 | | + glabel 12987 | | | code: GIMPLE_LABEL 12988 | | | 12989 | | + gswitch 12990 | | code: GIMPLE_SWITCH 12991 | | 12992 | + gimple_statement_with_memory_ops_base 12993 | | layout: GSS_WITH_MEM_OPS_BASE 12994 | | 12995 | + gimple_statement_with_memory_ops 12996 | | | layout: GSS_WITH_MEM_OPS 12997 | | | 12998 | | + gassign 12999 | | | code GIMPLE_ASSIGN 13000 | | | 13001 | | + greturn 13002 | | code GIMPLE_RETURN 13003 | | 13004 | + gcall 13005 | | layout: GSS_CALL, code: GIMPLE_CALL 13006 | | 13007 | + gasm 13008 | | layout: GSS_ASM, code: GIMPLE_ASM 13009 | | 13010 | + gtransaction 13011 | layout: GSS_TRANSACTION, code: GIMPLE_TRANSACTION 13012 | 13013 + gimple_statement_omp 13014 | | layout: GSS_OMP. Used for code GIMPLE_OMP_SECTION 13015 | | 13016 | + gomp_critical 13017 | | layout: GSS_OMP_CRITICAL, code: GIMPLE_OMP_CRITICAL 13018 | | 13019 | + gomp_for 13020 | | layout: GSS_OMP_FOR, code: GIMPLE_OMP_FOR 13021 | | 13022 | + gomp_parallel_layout 13023 | | | layout: GSS_OMP_PARALLEL_LAYOUT 13024 | | | 13025 | | + gimple_statement_omp_taskreg 13026 | | | | 13027 | | | + gomp_parallel 13028 | | | | code: GIMPLE_OMP_PARALLEL 13029 | | | | 13030 | | | + gomp_task 13031 | | | code: GIMPLE_OMP_TASK 13032 | | | 13033 | | + gimple_statement_omp_target 13034 | | code: GIMPLE_OMP_TARGET 13035 | | 13036 | + gomp_sections 13037 | | layout: GSS_OMP_SECTIONS, code: GIMPLE_OMP_SECTIONS 13038 | | 13039 | + gimple_statement_omp_single_layout 13040 | | layout: GSS_OMP_SINGLE_LAYOUT 13041 | | 13042 | + gomp_single 13043 | | code: GIMPLE_OMP_SINGLE 13044 | | 13045 | + gomp_teams 13046 | code: GIMPLE_OMP_TEAMS 13047 | 13048 + gbind 13049 | layout: GSS_BIND, code: GIMPLE_BIND 13050 | 13051 + gcatch 13052 | layout: GSS_CATCH, code: GIMPLE_CATCH 13053 | 13054 + geh_filter 13055 | layout: GSS_EH_FILTER, code: GIMPLE_EH_FILTER 13056 | 13057 + geh_else 13058 | layout: GSS_EH_ELSE, code: GIMPLE_EH_ELSE 13059 | 13060 + geh_mnt 13061 | layout: GSS_EH_MNT, code: GIMPLE_EH_MUST_NOT_THROW 13062 | 13063 + gphi 13064 | layout: GSS_PHI, code: GIMPLE_PHI 13065 | 13066 + gimple_statement_eh_ctrl 13067 | | layout: GSS_EH_CTRL 13068 | | 13069 | + gresx 13070 | | code: GIMPLE_RESX 13071 | | 13072 | + geh_dispatch 13073 | code: GIMPLE_EH_DISPATCH 13074 | 13075 + gtry 13076 | layout: GSS_TRY, code: GIMPLE_TRY 13077 | 13078 + gimple_statement_wce 13079 | layout: GSS_WCE, code: GIMPLE_WITH_CLEANUP_EXPR 13080 | 13081 + gomp_continue 13082 | layout: GSS_OMP_CONTINUE, code: GIMPLE_OMP_CONTINUE 13083 | 13084 + gomp_atomic_load 13085 | layout: GSS_OMP_ATOMIC_LOAD, code: GIMPLE_OMP_ATOMIC_LOAD 13086 | 13087 + gimple_statement_omp_atomic_store_layout 13088 | layout: GSS_OMP_ATOMIC_STORE_LAYOUT, 13089 | code: GIMPLE_OMP_ATOMIC_STORE 13090 | 13091 + gomp_atomic_store 13092 | code: GIMPLE_OMP_ATOMIC_STORE 13093 | 13094 + gomp_return 13095 code: GIMPLE_OMP_RETURN 13096 13097 13098File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Class hierarchy of GIMPLE statements, Up: GIMPLE 13099 1310012.3 GIMPLE instruction set 13101=========================== 13102 13103The following table briefly describes the GIMPLE instruction set. 13104 13105Instruction High GIMPLE Low GIMPLE 13106'GIMPLE_ASM' x x 13107'GIMPLE_ASSIGN' x x 13108'GIMPLE_BIND' x 13109'GIMPLE_CALL' x x 13110'GIMPLE_CATCH' x 13111'GIMPLE_COND' x x 13112'GIMPLE_DEBUG' x x 13113'GIMPLE_EH_FILTER' x 13114'GIMPLE_GOTO' x x 13115'GIMPLE_LABEL' x x 13116'GIMPLE_NOP' x x 13117'GIMPLE_OMP_ATOMIC_LOAD' x x 13118'GIMPLE_OMP_ATOMIC_STORE' x x 13119'GIMPLE_OMP_CONTINUE' x x 13120'GIMPLE_OMP_CRITICAL' x x 13121'GIMPLE_OMP_FOR' x x 13122'GIMPLE_OMP_MASTER' x x 13123'GIMPLE_OMP_ORDERED' x x 13124'GIMPLE_OMP_PARALLEL' x x 13125'GIMPLE_OMP_RETURN' x x 13126'GIMPLE_OMP_SECTION' x x 13127'GIMPLE_OMP_SECTIONS' x x 13128'GIMPLE_OMP_SECTIONS_SWITCH' x x 13129'GIMPLE_OMP_SINGLE' x x 13130'GIMPLE_PHI' x 13131'GIMPLE_RESX' x 13132'GIMPLE_RETURN' x x 13133'GIMPLE_SWITCH' x x 13134'GIMPLE_TRY' x 13135 13136 13137File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 13138 1313912.4 Exception Handling 13140======================= 13141 13142Other exception handling constructs are represented using 13143'GIMPLE_TRY_CATCH'. 'GIMPLE_TRY_CATCH' has two operands. The first 13144operand is a sequence of statements to execute. If executing these 13145statements does not throw an exception, then the second operand is 13146ignored. Otherwise, if an exception is thrown, then the second operand 13147of the 'GIMPLE_TRY_CATCH' is checked. The second operand may have the 13148following forms: 13149 13150 1. A sequence of statements to execute. When an exception occurs, 13151 these statements are executed, and then the exception is rethrown. 13152 13153 2. A sequence of 'GIMPLE_CATCH' statements. Each 'GIMPLE_CATCH' has a 13154 list of applicable exception types and handler code. If the thrown 13155 exception matches one of the caught types, the associated handler 13156 code is executed. If the handler code falls off the bottom, 13157 execution continues after the original 'GIMPLE_TRY_CATCH'. 13158 13159 3. A 'GIMPLE_EH_FILTER' statement. This has a list of permitted 13160 exception types, and code to handle a match failure. If the thrown 13161 exception does not match one of the allowed types, the associated 13162 match failure code is executed. If the thrown exception does 13163 match, it continues unwinding the stack looking for the next 13164 handler. 13165 13166 Currently throwing an exception is not directly represented in GIMPLE, 13167since it is implemented by calling a function. At some point in the 13168future we will want to add some way to express that the call will throw 13169an exception of a known type. 13170 13171 Just before running the optimizers, the compiler lowers the high-level 13172EH constructs above into a set of 'goto's, magic labels, and EH regions. 13173Continuing to unwind at the end of a cleanup is represented with a 13174'GIMPLE_RESX'. 13175 13176 13177File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 13178 1317912.5 Temporaries 13180================ 13181 13182When gimplification encounters a subexpression that is too complex, it 13183creates a new temporary variable to hold the value of the subexpression, 13184and adds a new statement to initialize it before the current statement. 13185These special temporaries are known as 'expression temporaries', and are 13186allocated using 'get_formal_tmp_var'. The compiler tries to always 13187evaluate identical expressions into the same temporary, to simplify 13188elimination of redundant calculations. 13189 13190 We can only use expression temporaries when we know that it will not be 13191reevaluated before its value is used, and that it will not be otherwise 13192modified(1). Other temporaries can be allocated using 13193'get_initialized_tmp_var' or 'create_tmp_var'. 13194 13195 Currently, an expression like 'a = b + 5' is not reduced any further. 13196We tried converting it to something like 13197 T1 = b + 5; 13198 a = T1; 13199 but this bloated the representation for minimal benefit. However, a 13200variable which must live in memory cannot appear in an expression; its 13201value is explicitly loaded into a temporary first. Similarly, storing 13202the value of an expression to a memory variable goes through a 13203temporary. 13204 13205 ---------- Footnotes ---------- 13206 13207 (1) These restrictions are derived from those in Morgan 4.8. 13208 13209 13210File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 13211 1321212.6 Operands 13213============= 13214 13215In general, expressions in GIMPLE consist of an operation and the 13216appropriate number of simple operands; these operands must either be a 13217GIMPLE rvalue ('is_gimple_val'), i.e. a constant or a register variable. 13218More complex operands are factored out into temporaries, so that 13219 a = b + c + d 13220 becomes 13221 T1 = b + c; 13222 a = T1 + d; 13223 13224 The same rule holds for arguments to a 'GIMPLE_CALL'. 13225 13226 The target of an assignment is usually a variable, but can also be a 13227'MEM_REF' or a compound lvalue as described below. 13228 13229* Menu: 13230 13231* Compound Expressions:: 13232* Compound Lvalues:: 13233* Conditional Expressions:: 13234* Logical Operators:: 13235 13236 13237File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 13238 1323912.6.1 Compound Expressions 13240--------------------------- 13241 13242The left-hand side of a C comma expression is simply moved into a 13243separate statement. 13244 13245 13246File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 13247 1324812.6.2 Compound Lvalues 13249----------------------- 13250 13251Currently compound lvalues involving array and structure field 13252references are not broken down; an expression like 'a.b[2] = 42' is not 13253reduced any further (though complex array subscripts are). This 13254restriction is a workaround for limitations in later optimizers; if we 13255were to convert this to 13256 13257 T1 = &a.b; 13258 T1[2] = 42; 13259 13260 alias analysis would not remember that the reference to 'T1[2]' came by 13261way of 'a.b', so it would think that the assignment could alias another 13262member of 'a'; this broke 'struct-alias-1.c'. Future optimizer 13263improvements may make this limitation unnecessary. 13264 13265 13266File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 13267 1326812.6.3 Conditional Expressions 13269------------------------------ 13270 13271A C '?:' expression is converted into an 'if' statement with each branch 13272assigning to the same temporary. So, 13273 13274 a = b ? c : d; 13275 becomes 13276 if (b == 1) 13277 T1 = c; 13278 else 13279 T1 = d; 13280 a = T1; 13281 13282 The GIMPLE level if-conversion pass re-introduces '?:' expression, if 13283appropriate. It is used to vectorize loops with conditions using vector 13284conditional operations. 13285 13286 Note that in GIMPLE, 'if' statements are represented using 13287'GIMPLE_COND', as described below. 13288 13289 13290File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 13291 1329212.6.4 Logical Operators 13293------------------------ 13294 13295Except when they appear in the condition operand of a 'GIMPLE_COND', 13296logical 'and' and 'or' operators are simplified as follows: 'a = b && c' 13297becomes 13298 13299 T1 = (bool)b; 13300 if (T1 == true) 13301 T1 = (bool)c; 13302 a = T1; 13303 13304 Note that 'T1' in this example cannot be an expression temporary, 13305because it has two different assignments. 13306 1330712.6.5 Manipulating operands 13308---------------------------- 13309 13310All gimple operands are of type 'tree'. But only certain types of trees 13311are allowed to be used as operand tuples. Basic validation is 13312controlled by the function 'get_gimple_rhs_class', which given a tree 13313code, returns an 'enum' with the following values of type 'enum 13314gimple_rhs_class' 13315 13316 * 'GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 13317 13318 * 'GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation. 13319 13320 * 'GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 13321 13322 * 'GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 13323 13324 * 'GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 13325 split into simpler operands (for instance, 'SSA_NAME', 'VAR_DECL', 13326 'COMPONENT_REF', etc). 13327 13328 This operand class also acts as an escape hatch for tree nodes that 13329 may be flattened out into the operand vector, but would need more 13330 than two slots on the RHS. For instance, a 'COND_EXPR' expression 13331 of the form '(a op b) ? x : y' could be flattened out on the 13332 operand vector using 4 slots, but it would also require additional 13333 processing to distinguish 'c = a op b' from 'c = a op b ? x : y'. 13334 Something similar occurs with 'ASSERT_EXPR'. In time, these 13335 special case tree expressions should be flattened into the operand 13336 vector. 13337 13338 For tree nodes in the categories 'GIMPLE_TERNARY_RHS', 13339'GIMPLE_BINARY_RHS' and 'GIMPLE_UNARY_RHS', they cannot be stored inside 13340tuples directly. They first need to be flattened and separated into 13341individual components. For instance, given the GENERIC expression 13342 13343 a = b + c 13344 13345 its tree representation is: 13346 13347 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 13348 13349 In this case, the GIMPLE form for this statement is logically identical 13350to its GENERIC form but in GIMPLE, the 'PLUS_EXPR' on the RHS of the 13351assignment is not represented as a tree, instead the two operands are 13352taken out of the 'PLUS_EXPR' sub-tree and flattened into the GIMPLE 13353tuple as follows: 13354 13355 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 13356 1335712.6.6 Operand vector allocation 13358-------------------------------- 13359 13360The operand vector is stored at the bottom of the three tuple structures 13361that accept operands. This means, that depending on the code of a given 13362statement, its operand vector will be at different offsets from the base 13363of the structure. To access tuple operands use the following accessors 13364 13365 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 13366 Returns the number of operands in statement G. 13367 13368 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 13369 Returns operand 'I' from statement 'G'. 13370 13371 -- GIMPLE function: tree * gimple_ops (gimple g) 13372 Returns a pointer into the operand vector for statement 'G'. This 13373 is computed using an internal table called 'gimple_ops_offset_'[]. 13374 This table is indexed by the gimple code of 'G'. 13375 13376 When the compiler is built, this table is filled-in using the sizes 13377 of the structures used by each statement code defined in 13378 gimple.def. Since the operand vector is at the bottom of the 13379 structure, for a gimple code 'C' the offset is computed as sizeof 13380 (struct-of 'C') - sizeof (tree). 13381 13382 This mechanism adds one memory indirection to every access when 13383 using 'gimple_op'(), if this becomes a bottleneck, a pass can 13384 choose to memoize the result from 'gimple_ops'() and use that to 13385 access the operands. 13386 1338712.6.7 Operand validation 13388------------------------- 13389 13390When adding a new operand to a gimple statement, the operand will be 13391validated according to what each tuple accepts in its operand vector. 13392These predicates are called by the 'gimple_NAME_set_...()'. Each tuple 13393will use one of the following predicates (Note, this list is not 13394exhaustive): 13395 13396 -- GIMPLE function: bool is_gimple_val (tree t) 13397 Returns true if t is a "GIMPLE value", which are all the 13398 non-addressable stack variables (variables for which 13399 'is_gimple_reg' returns true) and constants (expressions for which 13400 'is_gimple_min_invariant' returns true). 13401 13402 -- GIMPLE function: bool is_gimple_addressable (tree t) 13403 Returns true if t is a symbol or memory reference whose address can 13404 be taken. 13405 13406 -- GIMPLE function: bool is_gimple_asm_val (tree t) 13407 Similar to 'is_gimple_val' but it also accepts hard registers. 13408 13409 -- GIMPLE function: bool is_gimple_call_addr (tree t) 13410 Return true if t is a valid expression to use as the function 13411 called by a 'GIMPLE_CALL'. 13412 13413 -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t) 13414 Return true if t is a valid expression to use as first operand of a 13415 'MEM_REF' expression. 13416 13417 -- GIMPLE function: bool is_gimple_constant (tree t) 13418 Return true if t is a valid gimple constant. 13419 13420 -- GIMPLE function: bool is_gimple_min_invariant (tree t) 13421 Return true if t is a valid minimal invariant. This is different 13422 from constants, in that the specific value of t may not be known at 13423 compile time, but it is known that it doesn't change (e.g., the 13424 address of a function local variable). 13425 13426 -- GIMPLE function: bool is_gimple_ip_invariant (tree t) 13427 Return true if t is an interprocedural invariant. This means that 13428 t is a valid invariant in all functions (e.g. it can be an address 13429 of a global variable but not of a local one). 13430 13431 -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t) 13432 Return true if t is an 'ADDR_EXPR' that does not change once the 13433 program is running (and which is valid in all functions). 13434 1343512.6.8 Statement validation 13436--------------------------- 13437 13438 -- GIMPLE function: bool is_gimple_assign (gimple g) 13439 Return true if the code of g is 'GIMPLE_ASSIGN'. 13440 13441 -- GIMPLE function: bool is_gimple_call (gimple g) 13442 Return true if the code of g is 'GIMPLE_CALL'. 13443 13444 -- GIMPLE function: bool is_gimple_debug (gimple g) 13445 Return true if the code of g is 'GIMPLE_DEBUG'. 13446 13447 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple g) 13448 Return true if g is a 'GIMPLE_ASSIGN' that performs a type cast 13449 operation. 13450 13451 -- GIMPLE function: bool gimple_debug_bind_p (gimple g) 13452 Return true if g is a 'GIMPLE_DEBUG' that binds the value of an 13453 expression to a variable. 13454 13455 -- GIMPLE function: bool is_gimple_omp (gimple g) 13456 Return true if g is any of the OpenMP codes. 13457 13458 -- GIMPLE function: gimple_debug_begin_stmt_p (gimple g) 13459 Return true if g is a 'GIMPLE_DEBUG' that marks the beginning of a 13460 source statement. 13461 13462 -- GIMPLE function: gimple_debug_inline_entry_p (gimple g) 13463 Return true if g is a 'GIMPLE_DEBUG' that marks the entry point of 13464 an inlined function. 13465 13466 -- GIMPLE function: gimple_debug_nonbind_marker_p (gimple g) 13467 Return true if g is a 'GIMPLE_DEBUG' that marks a program location, 13468 without any variable binding. 13469 13470 13471File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 13472 1347312.7 Manipulating GIMPLE statements 13474=================================== 13475 13476This section documents all the functions available to handle each of the 13477GIMPLE instructions. 13478 1347912.7.1 Common accessors 13480----------------------- 13481 13482The following are common accessors for gimple statements. 13483 13484 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 13485 Return the code for statement 'G'. 13486 13487 -- GIMPLE function: basic_block gimple_bb (gimple g) 13488 Return the basic block to which statement 'G' belongs to. 13489 13490 -- GIMPLE function: tree gimple_block (gimple g) 13491 Return the lexical scope block holding statement 'G'. 13492 13493 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 13494 Return the type of the main expression computed by 'STMT'. Return 13495 'void_type_node' if 'STMT' computes nothing. This will only return 13496 something meaningful for 'GIMPLE_ASSIGN', 'GIMPLE_COND' and 13497 'GIMPLE_CALL'. For all other tuple codes, it will return 13498 'void_type_node'. 13499 13500 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 13501 Return the tree code for the expression computed by 'STMT'. This 13502 is only meaningful for 'GIMPLE_CALL', 'GIMPLE_ASSIGN' and 13503 'GIMPLE_COND'. If 'STMT' is 'GIMPLE_CALL', it will return 13504 'CALL_EXPR'. For 'GIMPLE_COND', it returns the code of the 13505 comparison predicate. For 'GIMPLE_ASSIGN' it returns the code of 13506 the operation performed by the 'RHS' of the assignment. 13507 13508 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 13509 Set the lexical scope block of 'G' to 'BLOCK'. 13510 13511 -- GIMPLE function: location_t gimple_locus (gimple g) 13512 Return locus information for statement 'G'. 13513 13514 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 13515 Set locus information for statement 'G'. 13516 13517 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 13518 Return true if 'G' does not have locus information. 13519 13520 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 13521 Return true if no warnings should be emitted for statement 'STMT'. 13522 13523 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 13524 visited_p) 13525 Set the visited status on statement 'STMT' to 'VISITED_P'. 13526 13527 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 13528 Return the visited status on statement 'STMT'. 13529 13530 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 13531 plf, bool val_p) 13532 Set pass local flag 'PLF' on statement 'STMT' to 'VAL_P'. 13533 13534 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum plf_mask 13535 plf) 13536 Return the value of pass local flag 'PLF' on statement 'STMT'. 13537 13538 -- GIMPLE function: bool gimple_has_ops (gimple g) 13539 Return true if statement 'G' has register or memory operands. 13540 13541 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 13542 Return true if statement 'G' has memory operands. 13543 13544 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 13545 Return the number of operands for statement 'G'. 13546 13547 -- GIMPLE function: tree * gimple_ops (gimple g) 13548 Return the array of operands for statement 'G'. 13549 13550 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 13551 Return operand 'I' for statement 'G'. 13552 13553 -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i) 13554 Return a pointer to operand 'I' for statement 'G'. 13555 13556 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 13557 Set operand 'I' of statement 'G' to 'OP'. 13558 13559 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 13560 Return the set of symbols that have had their address taken by 13561 'STMT'. 13562 13563 -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g) 13564 Return the set of 'DEF' operands for statement 'G'. 13565 13566 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 13567 def_optype_d *def) 13568 Set 'DEF' to be the set of 'DEF' operands for statement 'G'. 13569 13570 -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g) 13571 Return the set of 'USE' operands for statement 'G'. 13572 13573 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 13574 use_optype_d *use) 13575 Set 'USE' to be the set of 'USE' operands for statement 'G'. 13576 13577 -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g) 13578 Return the set of 'VUSE' operands for statement 'G'. 13579 13580 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 13581 voptype_d *ops) 13582 Set 'OPS' to be the set of 'VUSE' operands for statement 'G'. 13583 13584 -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g) 13585 Return the set of 'VDEF' operands for statement 'G'. 13586 13587 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 13588 voptype_d *ops) 13589 Set 'OPS' to be the set of 'VDEF' operands for statement 'G'. 13590 13591 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 13592 Return the set of symbols loaded by statement 'G'. Each element of 13593 the set is the 'DECL_UID' of the corresponding symbol. 13594 13595 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 13596 Return the set of symbols stored by statement 'G'. Each element of 13597 the set is the 'DECL_UID' of the corresponding symbol. 13598 13599 -- GIMPLE function: bool gimple_modified_p (gimple g) 13600 Return true if statement 'G' has operands and the modified field 13601 has been set. 13602 13603 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 13604 Return true if statement 'STMT' contains volatile operands. 13605 13606 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, bool 13607 volatilep) 13608 Return true if statement 'STMT' contains volatile operands. 13609 13610 -- GIMPLE function: void update_stmt (gimple s) 13611 Mark statement 'S' as modified, and update it. 13612 13613 -- GIMPLE function: void update_stmt_if_modified (gimple s) 13614 Update statement 'S' if it has been marked modified. 13615 13616 -- GIMPLE function: gimple gimple_copy (gimple stmt) 13617 Return a deep copy of statement 'STMT'. 13618 13619 13620File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 13621 1362212.8 Tuple specific accessors 13623============================= 13624 13625* Menu: 13626 13627* GIMPLE_ASM:: 13628* GIMPLE_ASSIGN:: 13629* GIMPLE_BIND:: 13630* GIMPLE_CALL:: 13631* GIMPLE_CATCH:: 13632* GIMPLE_COND:: 13633* GIMPLE_DEBUG:: 13634* GIMPLE_EH_FILTER:: 13635* GIMPLE_LABEL:: 13636* GIMPLE_GOTO:: 13637* GIMPLE_NOP:: 13638* GIMPLE_OMP_ATOMIC_LOAD:: 13639* GIMPLE_OMP_ATOMIC_STORE:: 13640* GIMPLE_OMP_CONTINUE:: 13641* GIMPLE_OMP_CRITICAL:: 13642* GIMPLE_OMP_FOR:: 13643* GIMPLE_OMP_MASTER:: 13644* GIMPLE_OMP_ORDERED:: 13645* GIMPLE_OMP_PARALLEL:: 13646* GIMPLE_OMP_RETURN:: 13647* GIMPLE_OMP_SECTION:: 13648* GIMPLE_OMP_SECTIONS:: 13649* GIMPLE_OMP_SINGLE:: 13650* GIMPLE_PHI:: 13651* GIMPLE_RESX:: 13652* GIMPLE_RETURN:: 13653* GIMPLE_SWITCH:: 13654* GIMPLE_TRY:: 13655* GIMPLE_WITH_CLEANUP_EXPR:: 13656 13657 13658File: gccint.info, Node: GIMPLE_ASM, Next: GIMPLE_ASSIGN, Up: Tuple specific accessors 13659 1366012.8.1 'GIMPLE_ASM' 13661------------------- 13662 13663 -- GIMPLE function: gasm *gimple_build_asm_vec ( const char *string, 13664 vec<tree, va_gc> *inputs, vec<tree, va_gc> *outputs, vec<tree, 13665 va_gc> *clobbers, vec<tree, va_gc> *labels) 13666 Build a 'GIMPLE_ASM' statement. This statement is used for 13667 building in-line assembly constructs. 'STRING' is the assembly 13668 code. 'INPUTS', 'OUTPUTS', 'CLOBBERS' and 'LABELS' are the inputs, 13669 outputs, clobbered registers and labels. 13670 13671 -- GIMPLE function: unsigned gimple_asm_ninputs (const gasm *g) 13672 Return the number of input operands for 'GIMPLE_ASM' 'G'. 13673 13674 -- GIMPLE function: unsigned gimple_asm_noutputs (const gasm *g) 13675 Return the number of output operands for 'GIMPLE_ASM' 'G'. 13676 13677 -- GIMPLE function: unsigned gimple_asm_nclobbers (const gasm *g) 13678 Return the number of clobber operands for 'GIMPLE_ASM' 'G'. 13679 13680 -- GIMPLE function: tree gimple_asm_input_op (const gasm *g, unsigned 13681 index) 13682 Return input operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13683 13684 -- GIMPLE function: void gimple_asm_set_input_op (gasm *g, unsigned 13685 index, tree in_op) 13686 Set 'IN_OP' to be input operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13687 13688 -- GIMPLE function: tree gimple_asm_output_op (const gasm *g, unsigned 13689 index) 13690 Return output operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13691 13692 -- GIMPLE function: void gimple_asm_set_output_op (gasm *g, unsigned 13693 index, tree out_op) 13694 Set 'OUT_OP' to be output operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13695 13696 -- GIMPLE function: tree gimple_asm_clobber_op (const gasm *g, unsigned 13697 index) 13698 Return clobber operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13699 13700 -- GIMPLE function: void gimple_asm_set_clobber_op (gasm *g, unsigned 13701 index, tree clobber_op) 13702 Set 'CLOBBER_OP' to be clobber operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13703 13704 -- GIMPLE function: const char * gimple_asm_string (const gasm *g) 13705 Return the string representing the assembly instruction in 13706 'GIMPLE_ASM' 'G'. 13707 13708 -- GIMPLE function: bool gimple_asm_volatile_p (const gasm *g) 13709 Return true if 'G' is an asm statement marked volatile. 13710 13711 -- GIMPLE function: void gimple_asm_set_volatile (gasm *g, bool 13712 volatile_p) 13713 Mark asm statement 'G' as volatile or non-volatile based on 13714 'VOLATILE_P'. 13715 13716 13717File: gccint.info, Node: GIMPLE_ASSIGN, Next: GIMPLE_BIND, Prev: GIMPLE_ASM, Up: Tuple specific accessors 13718 1371912.8.2 'GIMPLE_ASSIGN' 13720---------------------- 13721 13722 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, tree rhs) 13723 Build a 'GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 13724 passed in lhs. The right-hand side can be either a unary or binary 13725 tree expression. The expression tree rhs will be flattened and its 13726 operands assigned to the corresponding operand slots in the new 13727 statement. This function is useful when you already have a tree 13728 expression that you want to convert into a tuple. However, try to 13729 avoid building expression trees for the sole purpose of calling 13730 this function. If you already have the operands in separate trees, 13731 it is better to use 'gimple_build_assign' with 'enum tree_code' 13732 argument and separate arguments for each operand. 13733 13734 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13735 tree_code subcode, tree op1, tree op2, tree op3) 13736 This function is similar to two operand 'gimple_build_assign', but 13737 is used to build a 'GIMPLE_ASSIGN' statement when the operands of 13738 the right-hand side of the assignment are already split into 13739 different operands. 13740 13741 The left-hand side is an lvalue passed in lhs. Subcode is the 13742 'tree_code' for the right-hand side of the assignment. Op1, op2 13743 and op3 are the operands. 13744 13745 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13746 tree_code subcode, tree op1, tree op2) 13747 Like the above 5 operand 'gimple_build_assign', but with the last 13748 argument 'NULL' - this overload should not be used for 13749 'GIMPLE_TERNARY_RHS' assignments. 13750 13751 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13752 tree_code subcode, tree op1) 13753 Like the above 4 operand 'gimple_build_assign', but with the last 13754 argument 'NULL' - this overload should be used only for 13755 'GIMPLE_UNARY_RHS' and 'GIMPLE_SINGLE_RHS' assignments. 13756 13757 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 13758 gimple_seq *seq_p) 13759 Build a new 'GIMPLE_ASSIGN' tuple and append it to the end of 13760 '*SEQ_P'. 13761 13762 'DST'/'SRC' are the destination and source respectively. You can pass 13763ungimplified trees in 'DST' or 'SRC', in which case they will be 13764converted to a gimple operand if necessary. 13765 13766 This function returns the newly created 'GIMPLE_ASSIGN' tuple. 13767 13768 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 13769 Return the code of the expression computed on the 'RHS' of 13770 assignment statement 'G'. 13771 13772 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 13773 (gimple g) 13774 Return the gimple rhs class of the code for the expression computed 13775 on the rhs of assignment statement 'G'. This will never return 13776 'GIMPLE_INVALID_RHS'. 13777 13778 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 13779 Return the 'LHS' of assignment statement 'G'. 13780 13781 -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g) 13782 Return a pointer to the 'LHS' of assignment statement 'G'. 13783 13784 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 13785 Return the first operand on the 'RHS' of assignment statement 'G'. 13786 13787 -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g) 13788 Return the address of the first operand on the 'RHS' of assignment 13789 statement 'G'. 13790 13791 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 13792 Return the second operand on the 'RHS' of assignment statement 'G'. 13793 13794 -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g) 13795 Return the address of the second operand on the 'RHS' of assignment 13796 statement 'G'. 13797 13798 -- GIMPLE function: tree gimple_assign_rhs3 (gimple g) 13799 Return the third operand on the 'RHS' of assignment statement 'G'. 13800 13801 -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g) 13802 Return the address of the third operand on the 'RHS' of assignment 13803 statement 'G'. 13804 13805 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 13806 Set 'LHS' to be the 'LHS' operand of assignment statement 'G'. 13807 13808 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 13809 Set 'RHS' to be the first operand on the 'RHS' of assignment 13810 statement 'G'. 13811 13812 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 13813 Set 'RHS' to be the second operand on the 'RHS' of assignment 13814 statement 'G'. 13815 13816 -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs) 13817 Set 'RHS' to be the third operand on the 'RHS' of assignment 13818 statement 'G'. 13819 13820 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple s) 13821 Return true if 'S' is a type-cast assignment. 13822 13823 13824File: gccint.info, Node: GIMPLE_BIND, Next: GIMPLE_CALL, Prev: GIMPLE_ASSIGN, Up: Tuple specific accessors 13825 1382612.8.3 'GIMPLE_BIND' 13827-------------------- 13828 13829 -- GIMPLE function: gbind *gimple_build_bind (tree vars, gimple_seq 13830 body) 13831 Build a 'GIMPLE_BIND' statement with a list of variables in 'VARS' 13832 and a body of statements in sequence 'BODY'. 13833 13834 -- GIMPLE function: tree gimple_bind_vars (const gbind *g) 13835 Return the variables declared in the 'GIMPLE_BIND' statement 'G'. 13836 13837 -- GIMPLE function: void gimple_bind_set_vars (gbind *g, tree vars) 13838 Set 'VARS' to be the set of variables declared in the 'GIMPLE_BIND' 13839 statement 'G'. 13840 13841 -- GIMPLE function: void gimple_bind_append_vars (gbind *g, tree vars) 13842 Append 'VARS' to the set of variables declared in the 'GIMPLE_BIND' 13843 statement 'G'. 13844 13845 -- GIMPLE function: gimple_seq gimple_bind_body (gbind *g) 13846 Return the GIMPLE sequence contained in the 'GIMPLE_BIND' statement 13847 'G'. 13848 13849 -- GIMPLE function: void gimple_bind_set_body (gbind *g, gimple_seq 13850 seq) 13851 Set 'SEQ' to be sequence contained in the 'GIMPLE_BIND' statement 13852 'G'. 13853 13854 -- GIMPLE function: void gimple_bind_add_stmt (gbind *gs, gimple stmt) 13855 Append a statement to the end of a 'GIMPLE_BIND''s body. 13856 13857 -- GIMPLE function: void gimple_bind_add_seq (gbind *gs, gimple_seq 13858 seq) 13859 Append a sequence of statements to the end of a 'GIMPLE_BIND''s 13860 body. 13861 13862 -- GIMPLE function: tree gimple_bind_block (const gbind *g) 13863 Return the 'TREE_BLOCK' node associated with 'GIMPLE_BIND' 13864 statement 'G'. This is analogous to the 'BIND_EXPR_BLOCK' field in 13865 trees. 13866 13867 -- GIMPLE function: void gimple_bind_set_block (gbind *g, tree block) 13868 Set 'BLOCK' to be the 'TREE_BLOCK' node associated with 13869 'GIMPLE_BIND' statement 'G'. 13870 13871 13872File: gccint.info, Node: GIMPLE_CALL, Next: GIMPLE_CATCH, Prev: GIMPLE_BIND, Up: Tuple specific accessors 13873 1387412.8.4 'GIMPLE_CALL' 13875-------------------- 13876 13877 -- GIMPLE function: gcall *gimple_build_call (tree fn, unsigned nargs, 13878 ...) 13879 Build a 'GIMPLE_CALL' statement to function 'FN'. The argument 13880 'FN' must be either a 'FUNCTION_DECL' or a gimple call address as 13881 determined by 'is_gimple_call_addr'. 'NARGS' are the number of 13882 arguments. The rest of the arguments follow the argument 'NARGS', 13883 and must be trees that are valid as rvalues in gimple (i.e., each 13884 operand is validated with 'is_gimple_operand'). 13885 13886 -- GIMPLE function: gcall *gimple_build_call_from_tree (tree call_expr, 13887 tree fnptrtype) 13888 Build a 'GIMPLE_CALL' from a 'CALL_EXPR' node. The arguments and 13889 the function are taken from the expression directly. The type of 13890 the 'GIMPLE_CALL' is set from the second parameter passed by a 13891 caller. This routine assumes that 'call_expr' is already in GIMPLE 13892 form. That is, its operands are GIMPLE values and the function 13893 call needs no further simplification. All the call flags in 13894 'call_expr' are copied over to the new 'GIMPLE_CALL'. 13895 13896 -- GIMPLE function: gcall *gimple_build_call_vec (tree fn, 'vec<tree>' 13897 args) 13898 Identical to 'gimple_build_call' but the arguments are stored in a 13899 'vec<tree>'. 13900 13901 -- GIMPLE function: tree gimple_call_lhs (gimple g) 13902 Return the 'LHS' of call statement 'G'. 13903 13904 -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g) 13905 Return a pointer to the 'LHS' of call statement 'G'. 13906 13907 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 13908 Set 'LHS' to be the 'LHS' operand of call statement 'G'. 13909 13910 -- GIMPLE function: tree gimple_call_fn (gimple g) 13911 Return the tree node representing the function called by call 13912 statement 'G'. 13913 13914 -- GIMPLE function: void gimple_call_set_fn (gcall *g, tree fn) 13915 Set 'FN' to be the function called by call statement 'G'. This has 13916 to be a gimple value specifying the address of the called function. 13917 13918 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 13919 If a given 'GIMPLE_CALL''s callee is a 'FUNCTION_DECL', return it. 13920 Otherwise return 'NULL'. This function is analogous to 13921 'get_callee_fndecl' in 'GENERIC'. 13922 13923 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 13924 Set the called function to 'FNDECL'. 13925 13926 -- GIMPLE function: tree gimple_call_return_type (const gcall *g) 13927 Return the type returned by call statement 'G'. 13928 13929 -- GIMPLE function: tree gimple_call_chain (gimple g) 13930 Return the static chain for call statement 'G'. 13931 13932 -- GIMPLE function: void gimple_call_set_chain (gcall *g, tree chain) 13933 Set 'CHAIN' to be the static chain for call statement 'G'. 13934 13935 -- GIMPLE function: unsigned gimple_call_num_args (gimple g) 13936 Return the number of arguments used by call statement 'G'. 13937 13938 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 13939 Return the argument at position 'INDEX' for call statement 'G'. 13940 The first argument is 0. 13941 13942 -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned 13943 index) 13944 Return a pointer to the argument at position 'INDEX' for call 13945 statement 'G'. 13946 13947 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned index, 13948 tree arg) 13949 Set 'ARG' to be the argument at position 'INDEX' for call statement 13950 'G'. 13951 13952 -- GIMPLE function: void gimple_call_set_tail (gcall *s) 13953 Mark call statement 'S' as being a tail call (i.e., a call just 13954 before the exit of a function). These calls are candidate for tail 13955 call optimization. 13956 13957 -- GIMPLE function: bool gimple_call_tail_p (gcall *s) 13958 Return true if 'GIMPLE_CALL' 'S' is marked as a tail call. 13959 13960 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 13961 Return true if 'S' is a noreturn call. 13962 13963 -- GIMPLE function: gimple gimple_call_copy_skip_args (gcall *stmt, 13964 bitmap args_to_skip) 13965 Build a 'GIMPLE_CALL' identical to 'STMT' but skipping the 13966 arguments in the positions marked by the set 'ARGS_TO_SKIP'. 13967 13968 13969File: gccint.info, Node: GIMPLE_CATCH, Next: GIMPLE_COND, Prev: GIMPLE_CALL, Up: Tuple specific accessors 13970 1397112.8.5 'GIMPLE_CATCH' 13972--------------------- 13973 13974 -- GIMPLE function: gcatch *gimple_build_catch (tree types, gimple_seq 13975 handler) 13976 Build a 'GIMPLE_CATCH' statement. 'TYPES' are the tree types this 13977 catch handles. 'HANDLER' is a sequence of statements with the code 13978 for the handler. 13979 13980 -- GIMPLE function: tree gimple_catch_types (const gcatch *g) 13981 Return the types handled by 'GIMPLE_CATCH' statement 'G'. 13982 13983 -- GIMPLE function: tree * gimple_catch_types_ptr (gcatch *g) 13984 Return a pointer to the types handled by 'GIMPLE_CATCH' statement 13985 'G'. 13986 13987 -- GIMPLE function: gimple_seq gimple_catch_handler (gcatch *g) 13988 Return the GIMPLE sequence representing the body of the handler of 13989 'GIMPLE_CATCH' statement 'G'. 13990 13991 -- GIMPLE function: void gimple_catch_set_types (gcatch *g, tree t) 13992 Set 'T' to be the set of types handled by 'GIMPLE_CATCH' 'G'. 13993 13994 -- GIMPLE function: void gimple_catch_set_handler (gcatch *g, 13995 gimple_seq handler) 13996 Set 'HANDLER' to be the body of 'GIMPLE_CATCH' 'G'. 13997 13998 13999File: gccint.info, Node: GIMPLE_COND, Next: GIMPLE_DEBUG, Prev: GIMPLE_CATCH, Up: Tuple specific accessors 14000 1400112.8.6 'GIMPLE_COND' 14002-------------------- 14003 14004 -- GIMPLE function: gcond *gimple_build_cond ( enum tree_code 14005 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 14006 Build a 'GIMPLE_COND' statement. 'A' 'GIMPLE_COND' statement 14007 compares 'LHS' and 'RHS' and if the condition in 'PRED_CODE' is 14008 true, jump to the label in 't_label', otherwise jump to the label 14009 in 'f_label'. 'PRED_CODE' are relational operator tree codes like 14010 'EQ_EXPR', 'LT_EXPR', 'LE_EXPR', 'NE_EXPR', etc. 14011 14012 -- GIMPLE function: gcond *gimple_build_cond_from_tree (tree cond, tree 14013 t_label, tree f_label) 14014 Build a 'GIMPLE_COND' statement from the conditional expression 14015 tree 'COND'. 'T_LABEL' and 'F_LABEL' are as in 14016 'gimple_build_cond'. 14017 14018 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 14019 Return the code of the predicate computed by conditional statement 14020 'G'. 14021 14022 -- GIMPLE function: void gimple_cond_set_code (gcond *g, enum tree_code 14023 code) 14024 Set 'CODE' to be the predicate code for the conditional statement 14025 'G'. 14026 14027 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 14028 Return the 'LHS' of the predicate computed by conditional statement 14029 'G'. 14030 14031 -- GIMPLE function: void gimple_cond_set_lhs (gcond *g, tree lhs) 14032 Set 'LHS' to be the 'LHS' operand of the predicate computed by 14033 conditional statement 'G'. 14034 14035 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 14036 Return the 'RHS' operand of the predicate computed by conditional 14037 'G'. 14038 14039 -- GIMPLE function: void gimple_cond_set_rhs (gcond *g, tree rhs) 14040 Set 'RHS' to be the 'RHS' operand of the predicate computed by 14041 conditional statement 'G'. 14042 14043 -- GIMPLE function: tree gimple_cond_true_label (const gcond *g) 14044 Return the label used by conditional statement 'G' when its 14045 predicate evaluates to true. 14046 14047 -- GIMPLE function: void gimple_cond_set_true_label (gcond *g, tree 14048 label) 14049 Set 'LABEL' to be the label used by conditional statement 'G' when 14050 its predicate evaluates to true. 14051 14052 -- GIMPLE function: void gimple_cond_set_false_label (gcond *g, tree 14053 label) 14054 Set 'LABEL' to be the label used by conditional statement 'G' when 14055 its predicate evaluates to false. 14056 14057 -- GIMPLE function: tree gimple_cond_false_label (const gcond *g) 14058 Return the label used by conditional statement 'G' when its 14059 predicate evaluates to false. 14060 14061 -- GIMPLE function: void gimple_cond_make_false (gcond *g) 14062 Set the conditional 'COND_STMT' to be of the form 'if (1 == 0)'. 14063 14064 -- GIMPLE function: void gimple_cond_make_true (gcond *g) 14065 Set the conditional 'COND_STMT' to be of the form 'if (1 == 1)'. 14066 14067 14068File: gccint.info, Node: GIMPLE_DEBUG, Next: GIMPLE_EH_FILTER, Prev: GIMPLE_COND, Up: Tuple specific accessors 14069 1407012.8.7 'GIMPLE_DEBUG' 14071--------------------- 14072 14073 -- GIMPLE function: gdebug *gimple_build_debug_bind (tree var, tree 14074 value, gimple stmt) 14075 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BIND' 14076 'subcode'. The effect of this statement is to tell debug 14077 information generation machinery that the value of user variable 14078 'var' is given by 'value' at that point, and to remain with that 14079 value until 'var' runs out of scope, a dynamically-subsequent debug 14080 bind statement overrides the binding, or conflicting values reach a 14081 control flow merge point. Even if components of the 'value' 14082 expression change afterwards, the variable is supposed to retain 14083 the same value, though not necessarily the same location. 14084 14085 It is expected that 'var' be most often a tree for automatic user 14086 variables ('VAR_DECL' or 'PARM_DECL') that satisfy the requirements 14087 for gimple registers, but it may also be a tree for a scalarized 14088 component of a user variable ('ARRAY_REF', 'COMPONENT_REF'), or a 14089 debug temporary ('DEBUG_EXPR_DECL'). 14090 14091 As for 'value', it can be an arbitrary tree expression, but it is 14092 recommended that it be in a suitable form for a gimple assignment 14093 'RHS'. It is not expected that user variables that could appear as 14094 'var' ever appear in 'value', because in the latter we'd have their 14095 'SSA_NAME's instead, but even if they were not in SSA form, user 14096 variables appearing in 'value' are to be regarded as part of the 14097 executable code space, whereas those in 'var' are to be regarded as 14098 part of the source code space. There is no way to refer to the 14099 value bound to a user variable within a 'value' expression. 14100 14101 If 'value' is 'GIMPLE_DEBUG_BIND_NOVALUE', debug information 14102 generation machinery is informed that the variable 'var' is 14103 unbound, i.e., that its value is indeterminate, which sometimes 14104 means it is really unavailable, and other times that the compiler 14105 could not keep track of it. 14106 14107 Block and location information for the newly-created stmt are taken 14108 from 'stmt', if given. 14109 14110 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 14111 Return the user variable VAR that is bound at 'stmt'. 14112 14113 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 14114 Return the value expression that is bound to a user variable at 14115 'stmt'. 14116 14117 -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple 14118 stmt) 14119 Return a pointer to the value expression that is bound to a user 14120 variable at 'stmt'. 14121 14122 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 14123 var) 14124 Modify the user variable bound at 'stmt' to VAR. 14125 14126 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, tree 14127 var) 14128 Modify the value bound to the user variable bound at 'stmt' to 14129 VALUE. 14130 14131 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 14132 Modify the value bound to the user variable bound at 'stmt' so that 14133 the variable becomes unbound. 14134 14135 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 14136 Return 'TRUE' if 'stmt' binds a user variable to a value, and 14137 'FALSE' if it unbinds the variable. 14138 14139 -- GIMPLE function: gimple gimple_build_debug_begin_stmt (tree block, 14140 location_t location) 14141 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BEGIN_STMT' 14142 'subcode'. The effect of this statement is to tell debug 14143 information generation machinery that the user statement at the 14144 given 'location' and 'block' starts at the point at which the 14145 statement is inserted. The intent is that side effects (e.g. 14146 variable bindings) of all prior user statements are observable, and 14147 that none of the side effects of subsequent user statements are. 14148 14149 -- GIMPLE function: gimple gimple_build_debug_inline_entry (tree block, 14150 location_t location) 14151 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_INLINE_ENTRY' 14152 'subcode'. The effect of this statement is to tell debug 14153 information generation machinery that a function call at 'location' 14154 underwent inline substitution, that 'block' is the enclosing 14155 lexical block created for the substitution, and that at the point 14156 of the program in which the stmt is inserted, all parameters for 14157 the inlined function are bound to the respective arguments, and 14158 none of the side effects of its stmts are observable. 14159 14160 14161File: gccint.info, Node: GIMPLE_EH_FILTER, Next: GIMPLE_LABEL, Prev: GIMPLE_DEBUG, Up: Tuple specific accessors 14162 1416312.8.8 'GIMPLE_EH_FILTER' 14164------------------------- 14165 14166 -- GIMPLE function: geh_filter *gimple_build_eh_filter (tree types, 14167 gimple_seq failure) 14168 Build a 'GIMPLE_EH_FILTER' statement. 'TYPES' are the filter's 14169 types. 'FAILURE' is a sequence with the filter's failure action. 14170 14171 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 14172 Return the types handled by 'GIMPLE_EH_FILTER' statement 'G'. 14173 14174 -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g) 14175 Return a pointer to the types handled by 'GIMPLE_EH_FILTER' 14176 statement 'G'. 14177 14178 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 14179 Return the sequence of statement to execute when 'GIMPLE_EH_FILTER' 14180 statement fails. 14181 14182 -- GIMPLE function: void gimple_eh_filter_set_types (geh_filter *g, 14183 tree types) 14184 Set 'TYPES' to be the set of types handled by 'GIMPLE_EH_FILTER' 14185 'G'. 14186 14187 -- GIMPLE function: void gimple_eh_filter_set_failure (geh_filter *g, 14188 gimple_seq failure) 14189 Set 'FAILURE' to be the sequence of statements to execute on 14190 failure for 'GIMPLE_EH_FILTER' 'G'. 14191 14192 -- GIMPLE function: tree gimple_eh_must_not_throw_fndecl ( geh_mnt 14193 *eh_mnt_stmt) 14194 Get the function decl to be called by the MUST_NOT_THROW region. 14195 14196 -- GIMPLE function: void gimple_eh_must_not_throw_set_fndecl ( geh_mnt 14197 *eh_mnt_stmt, tree decl) 14198 Set the function decl to be called by GS to DECL. 14199 14200 14201File: gccint.info, Node: GIMPLE_LABEL, Next: GIMPLE_GOTO, Prev: GIMPLE_EH_FILTER, Up: Tuple specific accessors 14202 1420312.8.9 'GIMPLE_LABEL' 14204--------------------- 14205 14206 -- GIMPLE function: glabel *gimple_build_label (tree label) 14207 Build a 'GIMPLE_LABEL' statement with corresponding to the tree 14208 label, 'LABEL'. 14209 14210 -- GIMPLE function: tree gimple_label_label (const glabel *g) 14211 Return the 'LABEL_DECL' node used by 'GIMPLE_LABEL' statement 'G'. 14212 14213 -- GIMPLE function: void gimple_label_set_label (glabel *g, tree label) 14214 Set 'LABEL' to be the 'LABEL_DECL' node used by 'GIMPLE_LABEL' 14215 statement 'G'. 14216 14217 14218File: gccint.info, Node: GIMPLE_GOTO, Next: GIMPLE_NOP, Prev: GIMPLE_LABEL, Up: Tuple specific accessors 14219 1422012.8.10 'GIMPLE_GOTO' 14221--------------------- 14222 14223 -- GIMPLE function: ggoto *gimple_build_goto (tree dest) 14224 Build a 'GIMPLE_GOTO' statement to label 'DEST'. 14225 14226 -- GIMPLE function: tree gimple_goto_dest (gimple g) 14227 Return the destination of the unconditional jump 'G'. 14228 14229 -- GIMPLE function: void gimple_goto_set_dest (ggoto *g, tree dest) 14230 Set 'DEST' to be the destination of the unconditional jump 'G'. 14231 14232 14233File: gccint.info, Node: GIMPLE_NOP, Next: GIMPLE_OMP_ATOMIC_LOAD, Prev: GIMPLE_GOTO, Up: Tuple specific accessors 14234 1423512.8.11 'GIMPLE_NOP' 14236-------------------- 14237 14238 -- GIMPLE function: gimple gimple_build_nop (void) 14239 Build a 'GIMPLE_NOP' statement. 14240 14241 -- GIMPLE function: bool gimple_nop_p (gimple g) 14242 Returns 'TRUE' if statement 'G' is a 'GIMPLE_NOP'. 14243 14244 14245File: gccint.info, Node: GIMPLE_OMP_ATOMIC_LOAD, Next: GIMPLE_OMP_ATOMIC_STORE, Prev: GIMPLE_NOP, Up: Tuple specific accessors 14246 1424712.8.12 'GIMPLE_OMP_ATOMIC_LOAD' 14248-------------------------------- 14249 14250 -- GIMPLE function: gomp_atomic_load *gimple_build_omp_atomic_load ( 14251 tree lhs, tree rhs) 14252 Build a 'GIMPLE_OMP_ATOMIC_LOAD' statement. 'LHS' is the left-hand 14253 side of the assignment. 'RHS' is the right-hand side of the 14254 assignment. 14255 14256 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs ( 14257 gomp_atomic_load *g, tree lhs) 14258 Set the 'LHS' of an atomic load. 14259 14260 -- GIMPLE function: tree gimple_omp_atomic_load_lhs ( const 14261 gomp_atomic_load *g) 14262 Get the 'LHS' of an atomic load. 14263 14264 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs ( 14265 gomp_atomic_load *g, tree rhs) 14266 Set the 'RHS' of an atomic set. 14267 14268 -- GIMPLE function: tree gimple_omp_atomic_load_rhs ( const 14269 gomp_atomic_load *g) 14270 Get the 'RHS' of an atomic set. 14271 14272 14273File: gccint.info, Node: GIMPLE_OMP_ATOMIC_STORE, Next: GIMPLE_OMP_CONTINUE, Prev: GIMPLE_OMP_ATOMIC_LOAD, Up: Tuple specific accessors 14274 1427512.8.13 'GIMPLE_OMP_ATOMIC_STORE' 14276--------------------------------- 14277 14278 -- GIMPLE function: gomp_atomic_store *gimple_build_omp_atomic_store ( 14279 tree val) 14280 Build a 'GIMPLE_OMP_ATOMIC_STORE' statement. 'VAL' is the value to 14281 be stored. 14282 14283 -- GIMPLE function: void gimple_omp_atomic_store_set_val ( 14284 gomp_atomic_store *g, tree val) 14285 Set the value being stored in an atomic store. 14286 14287 -- GIMPLE function: tree gimple_omp_atomic_store_val ( const 14288 gomp_atomic_store *g) 14289 Return the value being stored in an atomic store. 14290 14291 14292File: gccint.info, Node: GIMPLE_OMP_CONTINUE, Next: GIMPLE_OMP_CRITICAL, Prev: GIMPLE_OMP_ATOMIC_STORE, Up: Tuple specific accessors 14293 1429412.8.14 'GIMPLE_OMP_CONTINUE' 14295----------------------------- 14296 14297 -- GIMPLE function: gomp_continue *gimple_build_omp_continue ( tree 14298 control_def, tree control_use) 14299 Build a 'GIMPLE_OMP_CONTINUE' statement. 'CONTROL_DEF' is the 14300 definition of the control variable. 'CONTROL_USE' is the use of 14301 the control variable. 14302 14303 -- GIMPLE function: tree gimple_omp_continue_control_def ( const 14304 gomp_continue *s) 14305 Return the definition of the control variable on a 14306 'GIMPLE_OMP_CONTINUE' in 'S'. 14307 14308 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr ( 14309 gomp_continue *s) 14310 Same as above, but return the pointer. 14311 14312 -- GIMPLE function: tree gimple_omp_continue_set_control_def ( 14313 gomp_continue *s) 14314 Set the control variable definition for a 'GIMPLE_OMP_CONTINUE' 14315 statement in 'S'. 14316 14317 -- GIMPLE function: tree gimple_omp_continue_control_use ( const 14318 gomp_continue *s) 14319 Return the use of the control variable on a 'GIMPLE_OMP_CONTINUE' 14320 in 'S'. 14321 14322 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr ( 14323 gomp_continue *s) 14324 Same as above, but return the pointer. 14325 14326 -- GIMPLE function: tree gimple_omp_continue_set_control_use ( 14327 gomp_continue *s) 14328 Set the control variable use for a 'GIMPLE_OMP_CONTINUE' statement 14329 in 'S'. 14330 14331 14332File: gccint.info, Node: GIMPLE_OMP_CRITICAL, Next: GIMPLE_OMP_FOR, Prev: GIMPLE_OMP_CONTINUE, Up: Tuple specific accessors 14333 1433412.8.15 'GIMPLE_OMP_CRITICAL' 14335----------------------------- 14336 14337 -- GIMPLE function: gomp_critical *gimple_build_omp_critical ( 14338 gimple_seq body, tree name) 14339 Build a 'GIMPLE_OMP_CRITICAL' statement. 'BODY' is the sequence of 14340 statements for which only one thread can execute. 'NAME' is an 14341 optional identifier for this critical block. 14342 14343 -- GIMPLE function: tree gimple_omp_critical_name ( const gomp_critical 14344 *g) 14345 Return the name associated with 'OMP_CRITICAL' statement 'G'. 14346 14347 -- GIMPLE function: tree * gimple_omp_critical_name_ptr ( gomp_critical 14348 *g) 14349 Return a pointer to the name associated with 'OMP' critical 14350 statement 'G'. 14351 14352 -- GIMPLE function: void gimple_omp_critical_set_name ( gomp_critical 14353 *g, tree name) 14354 Set 'NAME' to be the name associated with 'OMP' critical statement 14355 'G'. 14356 14357 14358File: gccint.info, Node: GIMPLE_OMP_FOR, Next: GIMPLE_OMP_MASTER, Prev: GIMPLE_OMP_CRITICAL, Up: Tuple specific accessors 14359 1436012.8.16 'GIMPLE_OMP_FOR' 14361------------------------ 14362 14363 -- GIMPLE function: gomp_for *gimple_build_omp_for (gimple_seq body, 14364 tree clauses, tree index, tree initial, tree final, tree incr, 14365 gimple_seq pre_body, enum tree_code omp_for_cond) 14366 Build a 'GIMPLE_OMP_FOR' statement. 'BODY' is sequence of 14367 statements inside the for loop. 'CLAUSES', are any of the loop 14368 construct's clauses. 'PRE_BODY' is the sequence of statements that 14369 are loop invariant. 'INDEX' is the index variable. 'INITIAL' is 14370 the initial value of 'INDEX'. 'FINAL' is final value of 'INDEX'. 14371 OMP_FOR_COND is the predicate used to compare 'INDEX' and 'FINAL'. 14372 'INCR' is the increment expression. 14373 14374 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 14375 Return the clauses associated with 'OMP_FOR' 'G'. 14376 14377 -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g) 14378 Return a pointer to the 'OMP_FOR' 'G'. 14379 14380 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 14381 clauses) 14382 Set 'CLAUSES' to be the list of clauses associated with 'OMP_FOR' 14383 'G'. 14384 14385 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 14386 Return the index variable for 'OMP_FOR' 'G'. 14387 14388 -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g) 14389 Return a pointer to the index variable for 'OMP_FOR' 'G'. 14390 14391 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 14392 index) 14393 Set 'INDEX' to be the index variable for 'OMP_FOR' 'G'. 14394 14395 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 14396 Return the initial value for 'OMP_FOR' 'G'. 14397 14398 -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g) 14399 Return a pointer to the initial value for 'OMP_FOR' 'G'. 14400 14401 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 14402 initial) 14403 Set 'INITIAL' to be the initial value for 'OMP_FOR' 'G'. 14404 14405 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 14406 Return the final value for 'OMP_FOR' 'G'. 14407 14408 -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g) 14409 turn a pointer to the final value for 'OMP_FOR' 'G'. 14410 14411 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 14412 final) 14413 Set 'FINAL' to be the final value for 'OMP_FOR' 'G'. 14414 14415 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 14416 Return the increment value for 'OMP_FOR' 'G'. 14417 14418 -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g) 14419 Return a pointer to the increment value for 'OMP_FOR' 'G'. 14420 14421 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 14422 Set 'INCR' to be the increment value for 'OMP_FOR' 'G'. 14423 14424 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 14425 Return the sequence of statements to execute before the 'OMP_FOR' 14426 statement 'G' starts. 14427 14428 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 14429 gimple_seq pre_body) 14430 Set 'PRE_BODY' to be the sequence of statements to execute before 14431 the 'OMP_FOR' statement 'G' starts. 14432 14433 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 14434 tree_code cond) 14435 Set 'COND' to be the condition code for 'OMP_FOR' 'G'. 14436 14437 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 14438 Return the condition code associated with 'OMP_FOR' 'G'. 14439 14440 14441File: gccint.info, Node: GIMPLE_OMP_MASTER, Next: GIMPLE_OMP_ORDERED, Prev: GIMPLE_OMP_FOR, Up: Tuple specific accessors 14442 1444312.8.17 'GIMPLE_OMP_MASTER' 14444--------------------------- 14445 14446 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 14447 Build a 'GIMPLE_OMP_MASTER' statement. 'BODY' is the sequence of 14448 statements to be executed by just the master. 14449 14450 14451File: gccint.info, Node: GIMPLE_OMP_ORDERED, Next: GIMPLE_OMP_PARALLEL, Prev: GIMPLE_OMP_MASTER, Up: Tuple specific accessors 14452 1445312.8.18 'GIMPLE_OMP_ORDERED' 14454---------------------------- 14455 14456 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 14457 Build a 'GIMPLE_OMP_ORDERED' statement. 14458 14459 'BODY' is the sequence of statements inside a loop that will executed 14460in sequence. 14461 14462 14463File: gccint.info, Node: GIMPLE_OMP_PARALLEL, Next: GIMPLE_OMP_RETURN, Prev: GIMPLE_OMP_ORDERED, Up: Tuple specific accessors 14464 1446512.8.19 'GIMPLE_OMP_PARALLEL' 14466----------------------------- 14467 14468 -- GIMPLE function: gomp_parallel *gimple_build_omp_parallel 14469 (gimple_seq body, tree clauses, tree child_fn, tree data_arg) 14470 Build a 'GIMPLE_OMP_PARALLEL' statement. 14471 14472 'BODY' is sequence of statements which are executed in parallel. 14473'CLAUSES', are the 'OMP' parallel construct's clauses. 'CHILD_FN' is 14474the function created for the parallel threads to execute. 'DATA_ARG' 14475are the shared data argument(s). 14476 14477 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 14478 Return true if 'OMP' parallel statement 'G' has the 14479 'GF_OMP_PARALLEL_COMBINED' flag set. 14480 14481 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 14482 Set the 'GF_OMP_PARALLEL_COMBINED' field in 'OMP' parallel 14483 statement 'G'. 14484 14485 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 14486 Return the body for the 'OMP' statement 'G'. 14487 14488 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 14489 body) 14490 Set 'BODY' to be the body for the 'OMP' statement 'G'. 14491 14492 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 14493 Return the clauses associated with 'OMP_PARALLEL' 'G'. 14494 14495 -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr ( 14496 gomp_parallel *g) 14497 Return a pointer to the clauses associated with 'OMP_PARALLEL' 'G'. 14498 14499 -- GIMPLE function: void gimple_omp_parallel_set_clauses ( 14500 gomp_parallel *g, tree clauses) 14501 Set 'CLAUSES' to be the list of clauses associated with 14502 'OMP_PARALLEL' 'G'. 14503 14504 -- GIMPLE function: tree gimple_omp_parallel_child_fn ( const 14505 gomp_parallel *g) 14506 Return the child function used to hold the body of 'OMP_PARALLEL' 14507 'G'. 14508 14509 -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr ( 14510 gomp_parallel *g) 14511 Return a pointer to the child function used to hold the body of 14512 'OMP_PARALLEL' 'G'. 14513 14514 -- GIMPLE function: void gimple_omp_parallel_set_child_fn ( 14515 gomp_parallel *g, tree child_fn) 14516 Set 'CHILD_FN' to be the child function for 'OMP_PARALLEL' 'G'. 14517 14518 -- GIMPLE function: tree gimple_omp_parallel_data_arg ( const 14519 gomp_parallel *g) 14520 Return the artificial argument used to send variables and values 14521 from the parent to the children threads in 'OMP_PARALLEL' 'G'. 14522 14523 -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr ( 14524 gomp_parallel *g) 14525 Return a pointer to the data argument for 'OMP_PARALLEL' 'G'. 14526 14527 -- GIMPLE function: void gimple_omp_parallel_set_data_arg ( 14528 gomp_parallel *g, tree data_arg) 14529 Set 'DATA_ARG' to be the data argument for 'OMP_PARALLEL' 'G'. 14530 14531 14532File: gccint.info, Node: GIMPLE_OMP_RETURN, Next: GIMPLE_OMP_SECTION, Prev: GIMPLE_OMP_PARALLEL, Up: Tuple specific accessors 14533 1453412.8.20 'GIMPLE_OMP_RETURN' 14535--------------------------- 14536 14537 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 14538 Build a 'GIMPLE_OMP_RETURN' statement. 'WAIT_P' is true if this is 14539 a non-waiting return. 14540 14541 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 14542 Set the nowait flag on 'GIMPLE_OMP_RETURN' statement 'S'. 14543 14544 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 14545 Return true if 'OMP' return statement 'G' has the 14546 'GF_OMP_RETURN_NOWAIT' flag set. 14547 14548 14549File: gccint.info, Node: GIMPLE_OMP_SECTION, Next: GIMPLE_OMP_SECTIONS, Prev: GIMPLE_OMP_RETURN, Up: Tuple specific accessors 14550 1455112.8.21 'GIMPLE_OMP_SECTION' 14552---------------------------- 14553 14554 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 14555 Build a 'GIMPLE_OMP_SECTION' statement for a sections statement. 14556 14557 'BODY' is the sequence of statements in the section. 14558 14559 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 14560 Return true if 'OMP' section statement 'G' has the 14561 'GF_OMP_SECTION_LAST' flag set. 14562 14563 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 14564 Set the 'GF_OMP_SECTION_LAST' flag on 'G'. 14565 14566 14567File: gccint.info, Node: GIMPLE_OMP_SECTIONS, Next: GIMPLE_OMP_SINGLE, Prev: GIMPLE_OMP_SECTION, Up: Tuple specific accessors 14568 1456912.8.22 'GIMPLE_OMP_SECTIONS' 14570----------------------------- 14571 14572 -- GIMPLE function: gomp_sections *gimple_build_omp_sections ( 14573 gimple_seq body, tree clauses) 14574 Build a 'GIMPLE_OMP_SECTIONS' statement. 'BODY' is a sequence of 14575 section statements. 'CLAUSES' are any of the 'OMP' sections 14576 construct's clauses: private, firstprivate, lastprivate, reduction, 14577 and nowait. 14578 14579 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 14580 Build a 'GIMPLE_OMP_SECTIONS_SWITCH' statement. 14581 14582 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 14583 Return the control variable associated with the 14584 'GIMPLE_OMP_SECTIONS' in 'G'. 14585 14586 -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g) 14587 Return a pointer to the clauses associated with the 14588 'GIMPLE_OMP_SECTIONS' in 'G'. 14589 14590 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 14591 tree control) 14592 Set 'CONTROL' to be the set of clauses associated with the 14593 'GIMPLE_OMP_SECTIONS' in 'G'. 14594 14595 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 14596 Return the clauses associated with 'OMP_SECTIONS' 'G'. 14597 14598 -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g) 14599 Return a pointer to the clauses associated with 'OMP_SECTIONS' 'G'. 14600 14601 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 14602 tree clauses) 14603 Set 'CLAUSES' to be the set of clauses associated with 14604 'OMP_SECTIONS' 'G'. 14605 14606 14607File: gccint.info, Node: GIMPLE_OMP_SINGLE, Next: GIMPLE_PHI, Prev: GIMPLE_OMP_SECTIONS, Up: Tuple specific accessors 14608 1460912.8.23 'GIMPLE_OMP_SINGLE' 14610--------------------------- 14611 14612 -- GIMPLE function: gomp_single *gimple_build_omp_single ( gimple_seq 14613 body, tree clauses) 14614 Build a 'GIMPLE_OMP_SINGLE' statement. 'BODY' is the sequence of 14615 statements that will be executed once. 'CLAUSES' are any of the 14616 'OMP' single construct's clauses: private, firstprivate, 14617 copyprivate, nowait. 14618 14619 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 14620 Return the clauses associated with 'OMP_SINGLE' 'G'. 14621 14622 -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g) 14623 Return a pointer to the clauses associated with 'OMP_SINGLE' 'G'. 14624 14625 -- GIMPLE function: void gimple_omp_single_set_clauses ( gomp_single 14626 *g, tree clauses) 14627 Set 'CLAUSES' to be the clauses associated with 'OMP_SINGLE' 'G'. 14628 14629 14630File: gccint.info, Node: GIMPLE_PHI, Next: GIMPLE_RESX, Prev: GIMPLE_OMP_SINGLE, Up: Tuple specific accessors 14631 1463212.8.24 'GIMPLE_PHI' 14633-------------------- 14634 14635 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 14636 Return the maximum number of arguments supported by 'GIMPLE_PHI' 14637 'G'. 14638 14639 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 14640 Return the number of arguments in 'GIMPLE_PHI' 'G'. This must 14641 always be exactly the number of incoming edges for the basic block 14642 holding 'G'. 14643 14644 -- GIMPLE function: tree gimple_phi_result (gimple g) 14645 Return the 'SSA' name created by 'GIMPLE_PHI' 'G'. 14646 14647 -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g) 14648 Return a pointer to the 'SSA' name created by 'GIMPLE_PHI' 'G'. 14649 14650 -- GIMPLE function: void gimple_phi_set_result (gphi *g, tree result) 14651 Set 'RESULT' to be the 'SSA' name created by 'GIMPLE_PHI' 'G'. 14652 14653 -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index) 14654 Return the 'PHI' argument corresponding to incoming edge 'INDEX' 14655 for 'GIMPLE_PHI' 'G'. 14656 14657 -- GIMPLE function: void gimple_phi_set_arg (gphi *g, index, struct 14658 phi_arg_d * phiarg) 14659 Set 'PHIARG' to be the argument corresponding to incoming edge 14660 'INDEX' for 'GIMPLE_PHI' 'G'. 14661 14662 14663File: gccint.info, Node: GIMPLE_RESX, Next: GIMPLE_RETURN, Prev: GIMPLE_PHI, Up: Tuple specific accessors 14664 1466512.8.25 'GIMPLE_RESX' 14666--------------------- 14667 14668 -- GIMPLE function: gresx *gimple_build_resx (int region) 14669 Build a 'GIMPLE_RESX' statement which is a statement. This 14670 statement is a placeholder for _Unwind_Resume before we know if a 14671 function call or a branch is needed. 'REGION' is the exception 14672 region from which control is flowing. 14673 14674 -- GIMPLE function: int gimple_resx_region (const gresx *g) 14675 Return the region number for 'GIMPLE_RESX' 'G'. 14676 14677 -- GIMPLE function: void gimple_resx_set_region (gresx *g, int region) 14678 Set 'REGION' to be the region number for 'GIMPLE_RESX' 'G'. 14679 14680 14681File: gccint.info, Node: GIMPLE_RETURN, Next: GIMPLE_SWITCH, Prev: GIMPLE_RESX, Up: Tuple specific accessors 14682 1468312.8.26 'GIMPLE_RETURN' 14684----------------------- 14685 14686 -- GIMPLE function: greturn *gimple_build_return (tree retval) 14687 Build a 'GIMPLE_RETURN' statement whose return value is retval. 14688 14689 -- GIMPLE function: tree gimple_return_retval (const greturn *g) 14690 Return the return value for 'GIMPLE_RETURN' 'G'. 14691 14692 -- GIMPLE function: void gimple_return_set_retval (greturn *g, tree 14693 retval) 14694 Set 'RETVAL' to be the return value for 'GIMPLE_RETURN' 'G'. 14695 14696 14697File: gccint.info, Node: GIMPLE_SWITCH, Next: GIMPLE_TRY, Prev: GIMPLE_RETURN, Up: Tuple specific accessors 14698 1469912.8.27 'GIMPLE_SWITCH' 14700----------------------- 14701 14702 -- GIMPLE function: gswitch *gimple_build_switch (tree index, tree 14703 default_label, 'vec'<tree> *args) 14704 Build a 'GIMPLE_SWITCH' statement. 'INDEX' is the index variable 14705 to switch on, and 'DEFAULT_LABEL' represents the default label. 14706 'ARGS' is a vector of 'CASE_LABEL_EXPR' trees that contain the 14707 non-default case labels. Each label is a tree of code 14708 'CASE_LABEL_EXPR'. 14709 14710 -- GIMPLE function: unsigned gimple_switch_num_labels ( const gswitch 14711 *g) 14712 Return the number of labels associated with the switch statement 14713 'G'. 14714 14715 -- GIMPLE function: void gimple_switch_set_num_labels (gswitch *g, 14716 unsigned nlabels) 14717 Set 'NLABELS' to be the number of labels for the switch statement 14718 'G'. 14719 14720 -- GIMPLE function: tree gimple_switch_index (const gswitch *g) 14721 Return the index variable used by the switch statement 'G'. 14722 14723 -- GIMPLE function: void gimple_switch_set_index (gswitch *g, tree 14724 index) 14725 Set 'INDEX' to be the index variable for switch statement 'G'. 14726 14727 -- GIMPLE function: tree gimple_switch_label (const gswitch *g, 14728 unsigned index) 14729 Return the label numbered 'INDEX'. The default label is 0, 14730 followed by any labels in a switch statement. 14731 14732 -- GIMPLE function: void gimple_switch_set_label (gswitch *g, unsigned 14733 index, tree label) 14734 Set the label number 'INDEX' to 'LABEL'. 0 is always the default 14735 label. 14736 14737 -- GIMPLE function: tree gimple_switch_default_label ( const gswitch 14738 *g) 14739 Return the default label for a switch statement. 14740 14741 -- GIMPLE function: void gimple_switch_set_default_label (gswitch *g, 14742 tree label) 14743 Set the default label for a switch statement. 14744 14745 14746File: gccint.info, Node: GIMPLE_TRY, Next: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_SWITCH, Up: Tuple specific accessors 14747 1474812.8.28 'GIMPLE_TRY' 14749-------------------- 14750 14751 -- GIMPLE function: gtry *gimple_build_try (gimple_seq eval, gimple_seq 14752 cleanup, unsigned int kind) 14753 Build a 'GIMPLE_TRY' statement. 'EVAL' is a sequence with the 14754 expression to evaluate. 'CLEANUP' is a sequence of statements to 14755 run at clean-up time. 'KIND' is the enumeration value 14756 'GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 14757 or 'GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 14758 construct. 14759 14760 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 14761 Return the kind of try block represented by 'GIMPLE_TRY' 'G'. This 14762 is either 'GIMPLE_TRY_CATCH' or 'GIMPLE_TRY_FINALLY'. 14763 14764 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 14765 Return the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 14766 14767 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 14768 Return the sequence of statements used as the body for 'GIMPLE_TRY' 14769 'G'. 14770 14771 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 14772 Return the sequence of statements used as the cleanup body for 14773 'GIMPLE_TRY' 'G'. 14774 14775 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 14776 bool catch_is_cleanup) 14777 Set the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 14778 14779 -- GIMPLE function: void gimple_try_set_eval (gtry *g, gimple_seq eval) 14780 Set 'EVAL' to be the sequence of statements to use as the body for 14781 'GIMPLE_TRY' 'G'. 14782 14783 -- GIMPLE function: void gimple_try_set_cleanup (gtry *g, gimple_seq 14784 cleanup) 14785 Set 'CLEANUP' to be the sequence of statements to use as the 14786 cleanup body for 'GIMPLE_TRY' 'G'. 14787 14788 14789File: gccint.info, Node: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_TRY, Up: Tuple specific accessors 14790 1479112.8.29 'GIMPLE_WITH_CLEANUP_EXPR' 14792---------------------------------- 14793 14794 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 14795 Build a 'GIMPLE_WITH_CLEANUP_EXPR' statement. 'CLEANUP' is the 14796 clean-up expression. 14797 14798 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 14799 Return the cleanup sequence for cleanup statement 'G'. 14800 14801 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 14802 cleanup) 14803 Set 'CLEANUP' to be the cleanup sequence for 'G'. 14804 14805 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 14806 Return the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 14807 14808 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, bool 14809 eh_only_p) 14810 Set the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 14811 14812 14813File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 14814 1481512.9 GIMPLE sequences 14816===================== 14817 14818GIMPLE sequences are the tuple equivalent of 'STATEMENT_LIST''s used in 14819'GENERIC'. They are used to chain statements together, and when used in 14820conjunction with sequence iterators, provide a framework for iterating 14821through statements. 14822 14823 GIMPLE sequences are of type struct 'gimple_sequence', but are more 14824commonly passed by reference to functions dealing with sequences. The 14825type for a sequence pointer is 'gimple_seq' which is the same as struct 14826'gimple_sequence' *. When declaring a local sequence, you can define a 14827local variable of type struct 'gimple_sequence'. When declaring a 14828sequence allocated on the garbage collected heap, use the function 14829'gimple_seq_alloc' documented below. 14830 14831 There are convenience functions for iterating through sequences in the 14832section entitled Sequence Iterators. 14833 14834 Below is a list of functions to manipulate and query sequences. 14835 14836 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 14837 g) 14838 Link a gimple statement to the end of the sequence *'SEQ' if 'G' is 14839 not 'NULL'. If *'SEQ' is 'NULL', allocate a sequence before 14840 linking. 14841 14842 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 14843 gimple_seq src) 14844 Append sequence 'SRC' to the end of sequence *'DEST' if 'SRC' is 14845 not 'NULL'. If *'DEST' is 'NULL', allocate a new sequence before 14846 appending. 14847 14848 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 14849 Perform a deep copy of sequence 'SRC' and return the result. 14850 14851 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 14852 Reverse the order of the statements in the sequence 'SEQ'. Return 14853 'SEQ'. 14854 14855 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 14856 Return the first statement in sequence 'S'. 14857 14858 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 14859 Return the last statement in sequence 'S'. 14860 14861 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 14862 last) 14863 Set the last statement in sequence 'S' to the statement in 'LAST'. 14864 14865 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 14866 first) 14867 Set the first statement in sequence 'S' to the statement in 14868 'FIRST'. 14869 14870 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 14871 Initialize sequence 'S' to an empty sequence. 14872 14873 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 14874 Allocate a new sequence in the garbage collected store and return 14875 it. 14876 14877 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 14878 src) 14879 Copy the sequence 'SRC' into the sequence 'DEST'. 14880 14881 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 14882 Return true if the sequence 'S' is empty. 14883 14884 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 14885 Returns the sequence of statements in 'BB'. 14886 14887 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 14888 Sets the sequence of statements in 'BB' to 'SEQ'. 14889 14890 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 14891 Determine whether 'SEQ' contains exactly one statement. 14892 14893 14894File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 14895 1489612.10 Sequence iterators 14897======================== 14898 14899Sequence iterators are convenience constructs for iterating through 14900statements in a sequence. Given a sequence 'SEQ', here is a typical use 14901of gimple sequence iterators: 14902 14903 gimple_stmt_iterator gsi; 14904 14905 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 14906 { 14907 gimple g = gsi_stmt (gsi); 14908 /* Do something with gimple statement G. */ 14909 } 14910 14911 Backward iterations are possible: 14912 14913 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 14914 14915 Forward and backward iterations on basic blocks are possible with 14916'gsi_start_bb' and 'gsi_last_bb'. 14917 14918 In the documentation below we sometimes refer to enum 14919'gsi_iterator_update'. The valid options for this enumeration are: 14920 14921 * 'GSI_NEW_STMT' Only valid when a single statement is added. Move 14922 the iterator to it. 14923 14924 * 'GSI_SAME_STMT' Leave the iterator at the same statement. 14925 14926 * 'GSI_CONTINUE_LINKING' Move iterator to whatever position is 14927 suitable for linking other statements in the same direction. 14928 14929 Below is a list of the functions used to manipulate and use statement 14930iterators. 14931 14932 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 14933 Return a new iterator pointing to the sequence 'SEQ''s first 14934 statement. If 'SEQ' is empty, the iterator's basic block is 14935 'NULL'. Use 'gsi_start_bb' instead when the iterator needs to 14936 always have the correct basic block set. 14937 14938 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 14939 Return a new iterator pointing to the first statement in basic 14940 block 'BB'. 14941 14942 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 14943 Return a new iterator initially pointing to the last statement of 14944 sequence 'SEQ'. If 'SEQ' is empty, the iterator's basic block is 14945 'NULL'. Use 'gsi_last_bb' instead when the iterator needs to 14946 always have the correct basic block set. 14947 14948 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 14949 Return a new iterator pointing to the last statement in basic block 14950 'BB'. 14951 14952 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 14953 Return 'TRUE' if at the end of 'I'. 14954 14955 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 14956 Return 'TRUE' if we're one statement before the end of 'I'. 14957 14958 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 14959 Advance the iterator to the next gimple statement. 14960 14961 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 14962 Advance the iterator to the previous gimple statement. 14963 14964 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 14965 Return the current stmt. 14966 14967 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 14968 bb) 14969 Return a block statement iterator that points to the first 14970 non-label statement in block 'BB'. 14971 14972 -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i) 14973 Return a pointer to the current stmt. 14974 14975 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 14976 Return the basic block associated with this iterator. 14977 14978 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 14979 Return the sequence associated with this iterator. 14980 14981 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 14982 remove_eh_info) 14983 Remove the current stmt from the sequence. The iterator is updated 14984 to point to the next statement. When 'REMOVE_EH_INFO' is true we 14985 remove the statement pointed to by iterator 'I' from the 'EH' 14986 tables. Otherwise we do not modify the 'EH' tables. Generally, 14987 'REMOVE_EH_INFO' should be true when the statement is going to be 14988 removed from the 'IL' and not reinserted elsewhere. 14989 14990 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 14991 gimple_seq seq, enum gsi_iterator_update mode) 14992 Links the sequence of statements 'SEQ' before the statement pointed 14993 by iterator 'I'. 'MODE' indicates what to do with the iterator 14994 after insertion (see 'enum gsi_iterator_update' above). 14995 14996 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 14997 gimple g, enum gsi_iterator_update mode) 14998 Links statement 'G' before the statement pointed-to by iterator 14999 'I'. Updates iterator 'I' according to 'MODE'. 15000 15001 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 15002 gimple_seq seq, enum gsi_iterator_update mode) 15003 Links sequence 'SEQ' after the statement pointed-to by iterator 15004 'I'. 'MODE' is as in 'gsi_insert_after'. 15005 15006 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 15007 gimple g, enum gsi_iterator_update mode) 15008 Links statement 'G' after the statement pointed-to by iterator 'I'. 15009 'MODE' is as in 'gsi_insert_after'. 15010 15011 -- GIMPLE function: gimple_seq gsi_split_seq_after 15012 (gimple_stmt_iterator i) 15013 Move all statements in the sequence after 'I' to a new sequence. 15014 Return this new sequence. 15015 15016 -- GIMPLE function: gimple_seq gsi_split_seq_before 15017 (gimple_stmt_iterator *i) 15018 Move all statements in the sequence before 'I' to a new sequence. 15019 Return this new sequence. 15020 15021 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 15022 stmt, bool update_eh_info) 15023 Replace the statement pointed-to by 'I' to 'STMT'. If 15024 'UPDATE_EH_INFO' is true, the exception handling information of the 15025 original statement is moved to the new statement. 15026 15027 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 15028 gimple stmt, enum gsi_iterator_update mode) 15029 Insert statement 'STMT' before the statement pointed-to by iterator 15030 'I', update 'STMT''s basic block and scan it for new operands. 15031 'MODE' specifies how to update iterator 'I' after insertion (see 15032 enum 'gsi_iterator_update'). 15033 15034 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 15035 *i, gimple_seq seq, enum gsi_iterator_update mode) 15036 Like 'gsi_insert_before', but for all the statements in 'SEQ'. 15037 15038 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 15039 gimple stmt, enum gsi_iterator_update mode) 15040 Insert statement 'STMT' after the statement pointed-to by iterator 15041 'I', update 'STMT''s basic block and scan it for new operands. 15042 'MODE' specifies how to update iterator 'I' after insertion (see 15043 enum 'gsi_iterator_update'). 15044 15045 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator *i, 15046 gimple_seq seq, enum gsi_iterator_update mode) 15047 Like 'gsi_insert_after', but for all the statements in 'SEQ'. 15048 15049 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 15050 Finds iterator for 'STMT'. 15051 15052 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 15053 gimple_stmt_iterator *to) 15054 Move the statement at 'FROM' so it comes right after the statement 15055 at 'TO'. 15056 15057 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 15058 gimple_stmt_iterator *to) 15059 Move the statement at 'FROM' so it comes right before the statement 15060 at 'TO'. 15061 15062 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 15063 *from, basic_block bb) 15064 Move the statement at 'FROM' to the end of basic block 'BB'. 15065 15066 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 15067 Add 'STMT' to the pending list of edge 'E'. No actual insertion is 15068 made until a call to 'gsi_commit_edge_inserts'() is made. 15069 15070 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 15071 seq) 15072 Add the sequence of statements in 'SEQ' to the pending list of edge 15073 'E'. No actual insertion is made until a call to 15074 'gsi_commit_edge_inserts'() is made. 15075 15076 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 15077 gimple stmt) 15078 Similar to 'gsi_insert_on_edge'+'gsi_commit_edge_inserts'. If a 15079 new block has to be created, it is returned. 15080 15081 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 15082 basic_block *new_bb) 15083 Commit insertions pending at edge 'E'. If a new block is created, 15084 set 'NEW_BB' to this block, otherwise set it to 'NULL'. 15085 15086 -- GIMPLE function: void gsi_commit_edge_inserts (void) 15087 This routine will commit all pending edge insertions, creating any 15088 new basic blocks which are necessary. 15089 15090 15091File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 15092 1509312.11 Adding a new GIMPLE statement code 15094======================================== 15095 15096The first step in adding a new GIMPLE statement code, is modifying the 15097file 'gimple.def', which contains all the GIMPLE codes. Then you must 15098add a corresponding gimple subclass located in 'gimple.h'. This in 15099turn, will require you to add a corresponding 'GTY' tag in 15100'gsstruct.def', and code to handle this tag in 'gss_for_code' which is 15101located in 'gimple.c'. 15102 15103 In order for the garbage collector to know the size of the structure 15104you created in 'gimple.h', you need to add a case to handle your new 15105GIMPLE statement in 'gimple_size' which is located in 'gimple.c'. 15106 15107 You will probably want to create a function to build the new gimple 15108statement in 'gimple.c'. The function should be called 15109'gimple_build_NEW-TUPLE-NAME', and should return the new tuple as a 15110pointer to the appropriate gimple subclass. 15111 15112 If your new statement requires accessors for any members or operands it 15113may have, put simple inline accessors in 'gimple.h' and any non-trivial 15114accessors in 'gimple.c' with a corresponding prototype in 'gimple.h'. 15115 15116 You should add the new statement subclass to the class hierarchy 15117diagram in 'gimple.texi'. 15118 15119 15120File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 15121 1512212.12 Statement and operand traversals 15123====================================== 15124 15125There are two functions available for walking statements and sequences: 15126'walk_gimple_stmt' and 'walk_gimple_seq', accordingly, and a third 15127function for walking the operands in a statement: 'walk_gimple_op'. 15128 15129 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 15130 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 15131 walk_stmt_info *wi) 15132 This function is used to walk the current statement in 'GSI', 15133 optionally using traversal state stored in 'WI'. If 'WI' is 15134 'NULL', no state is kept during the traversal. 15135 15136 The callback 'CALLBACK_STMT' is called. If 'CALLBACK_STMT' returns 15137 true, it means that the callback function has handled all the 15138 operands of the statement and it is not necessary to walk its 15139 operands. 15140 15141 If 'CALLBACK_STMT' is 'NULL' or it returns false, 'CALLBACK_OP' is 15142 called on each operand of the statement via 'walk_gimple_op'. If 15143 'walk_gimple_op' returns non-'NULL' for any operand, the remaining 15144 operands are not scanned. 15145 15146 The return value is that returned by the last call to 15147 'walk_gimple_op', or 'NULL_TREE' if no 'CALLBACK_OP' is specified. 15148 15149 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 15150 callback_op, struct walk_stmt_info *wi) 15151 Use this function to walk the operands of statement 'STMT'. Every 15152 operand is walked via 'walk_tree' with optional state information 15153 in 'WI'. 15154 15155 'CALLBACK_OP' is called on each operand of 'STMT' via 'walk_tree'. 15156 Additional parameters to 'walk_tree' must be stored in 'WI'. For 15157 each operand 'OP', 'walk_tree' is called as: 15158 15159 walk_tree (&OP, CALLBACK_OP, WI, PSET) 15160 15161 If 'CALLBACK_OP' returns non-'NULL' for an operand, the remaining 15162 operands are not scanned. The return value is that returned by the 15163 last call to 'walk_tree', or 'NULL_TREE' if no 'CALLBACK_OP' is 15164 specified. 15165 15166 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 15167 callback_stmt, walk_tree_fn callback_op, struct walk_stmt_info 15168 *wi) 15169 This function walks all the statements in the sequence 'SEQ' 15170 calling 'walk_gimple_stmt' on each one. 'WI' is as in 15171 'walk_gimple_stmt'. If 'walk_gimple_stmt' returns non-'NULL', the 15172 walk is stopped and the value returned. Otherwise, all the 15173 statements are walked and 'NULL_TREE' returned. 15174 15175 15176File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 15177 1517813 Analysis and Optimization of GIMPLE tuples 15179********************************************* 15180 15181GCC uses three main intermediate languages to represent the program 15182during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 15183language-independent representation generated by each front end. It is 15184used to serve as an interface between the parser and optimizer. GENERIC 15185is a common representation that is able to represent programs written in 15186all the languages supported by GCC. 15187 15188 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 15189target and language independent optimizations (e.g., inlining, constant 15190propagation, tail call elimination, redundancy elimination, etc). Much 15191like GENERIC, GIMPLE is a language independent, tree based 15192representation. However, it differs from GENERIC in that the GIMPLE 15193grammar is more restrictive: expressions contain no more than 3 operands 15194(except function calls), it has no control flow structures and 15195expressions with side effects are only allowed on the right hand side of 15196assignments. See the chapter describing GENERIC and GIMPLE for more 15197details. 15198 15199 This chapter describes the data structures and functions used in the 15200GIMPLE optimizers (also known as "tree optimizers" or "middle end"). In 15201particular, it focuses on all the macros, data structures, functions and 15202programming constructs needed to implement optimization passes for 15203GIMPLE. 15204 15205* Menu: 15206 15207* Annotations:: Attributes for variables. 15208* SSA Operands:: SSA names referenced by GIMPLE statements. 15209* SSA:: Static Single Assignment representation. 15210* Alias analysis:: Representing aliased loads and stores. 15211* Memory model:: Memory model used by the middle-end. 15212 15213 15214File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 15215 1521613.1 Annotations 15217================ 15218 15219The optimizers need to associate attributes with variables during the 15220optimization process. For instance, we need to know whether a variable 15221has aliases. All these attributes are stored in data structures called 15222annotations which are then linked to the field 'ann' in 'struct 15223tree_common'. 15224 15225 15226File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 15227 1522813.2 SSA Operands 15229================= 15230 15231Almost every GIMPLE statement will contain a reference to a variable or 15232memory location. Since statements come in different shapes and sizes, 15233their operands are going to be located at various spots inside the 15234statement's tree. To facilitate access to the statement's operands, 15235they are organized into lists associated inside each statement's 15236annotation. Each element in an operand list is a pointer to a 15237'VAR_DECL', 'PARM_DECL' or 'SSA_NAME' tree node. This provides a very 15238convenient way of examining and replacing operands. 15239 15240 Data flow analysis and optimization is done on all tree nodes 15241representing variables. Any node for which 'SSA_VAR_P' returns nonzero 15242is considered when scanning statement operands. However, not all 15243'SSA_VAR_P' variables are processed in the same way. For the purposes 15244of optimization, we need to distinguish between references to local 15245scalar variables and references to globals, statics, structures, arrays, 15246aliased variables, etc. The reason is simple, the compiler can gather 15247complete data flow information for a local scalar. On the other hand, a 15248global variable may be modified by a function call, it may not be 15249possible to keep track of all the elements of an array or the fields of 15250a structure, etc. 15251 15252 The operand scanner gathers two kinds of operands: "real" and 15253"virtual". An operand for which 'is_gimple_reg' returns true is 15254considered real, otherwise it is a virtual operand. We also distinguish 15255between uses and definitions. An operand is used if its value is loaded 15256by the statement (e.g., the operand at the RHS of an assignment). If 15257the statement assigns a new value to the operand, the operand is 15258considered a definition (e.g., the operand at the LHS of an assignment). 15259 15260 Virtual and real operands also have very different data flow 15261properties. Real operands are unambiguous references to the full object 15262that they represent. For instance, given 15263 15264 { 15265 int a, b; 15266 a = b 15267 } 15268 15269 Since 'a' and 'b' are non-aliased locals, the statement 'a = b' will 15270have one real definition and one real use because variable 'a' is 15271completely modified with the contents of variable 'b'. Real definition 15272are also known as "killing definitions". Similarly, the use of 'b' 15273reads all its bits. 15274 15275 In contrast, virtual operands are used with variables that can have a 15276partial or ambiguous reference. This includes structures, arrays, 15277globals, and aliased variables. In these cases, we have two types of 15278definitions. For globals, structures, and arrays, we can determine from 15279a statement whether a variable of these types has a killing definition. 15280If the variable does, then the statement is marked as having a "must 15281definition" of that variable. However, if a statement is only defining 15282a part of the variable (i.e. a field in a structure), or if we know that 15283a statement might define the variable but we cannot say for sure, then 15284we mark that statement as having a "may definition". For instance, 15285given 15286 15287 { 15288 int a, b, *p; 15289 15290 if (...) 15291 p = &a; 15292 else 15293 p = &b; 15294 *p = 5; 15295 return *p; 15296 } 15297 15298 The assignment '*p = 5' may be a definition of 'a' or 'b'. If we 15299cannot determine statically where 'p' is pointing to at the time of the 15300store operation, we create virtual definitions to mark that statement as 15301a potential definition site for 'a' and 'b'. Memory loads are similarly 15302marked with virtual use operands. Virtual operands are shown in tree 15303dumps right before the statement that contains them. To request a tree 15304dump with virtual operands, use the '-vops' option to '-fdump-tree': 15305 15306 { 15307 int a, b, *p; 15308 15309 if (...) 15310 p = &a; 15311 else 15312 p = &b; 15313 # a = VDEF <a> 15314 # b = VDEF <b> 15315 *p = 5; 15316 15317 # VUSE <a> 15318 # VUSE <b> 15319 return *p; 15320 } 15321 15322 Notice that 'VDEF' operands have two copies of the referenced variable. 15323This indicates that this is not a killing definition of that variable. 15324In this case we refer to it as a "may definition" or "aliased store". 15325The presence of the second copy of the variable in the 'VDEF' operand 15326will become important when the function is converted into SSA form. 15327This will be used to link all the non-killing definitions to prevent 15328optimizations from making incorrect assumptions about them. 15329 15330 Operands are updated as soon as the statement is finished via a call to 15331'update_stmt'. If statement elements are changed via 'SET_USE' or 15332'SET_DEF', then no further action is required (i.e., those macros take 15333care of updating the statement). If changes are made by manipulating 15334the statement's tree directly, then a call must be made to 'update_stmt' 15335when complete. Calling one of the 'bsi_insert' routines or 15336'bsi_replace' performs an implicit call to 'update_stmt'. 15337 1533813.2.1 Operand Iterators And Access Routines 15339-------------------------------------------- 15340 15341Operands are collected by 'tree-ssa-operands.c'. They are stored inside 15342each statement's annotation and can be accessed through either the 15343operand iterators or an access routine. 15344 15345 The following access routines are available for examining operands: 15346 15347 1. 'SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 15348 NULL unless there is exactly one operand matching the specified 15349 flags. If there is exactly one operand, the operand is returned as 15350 either a 'tree', 'def_operand_p', or 'use_operand_p'. 15351 15352 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 15353 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 15354 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 15355 15356 2. 'ZERO_SSA_OPERANDS': This macro returns true if there are no 15357 operands matching the specified flags. 15358 15359 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 15360 return; 15361 15362 3. 'NUM_SSA_OPERANDS': This macro Returns the number of operands 15363 matching 'flags'. This actually executes a loop to perform the 15364 count, so only use this if it is really needed. 15365 15366 int count = NUM_SSA_OPERANDS (stmt, flags) 15367 15368 If you wish to iterate over some or all operands, use the 15369'FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 15370all the operands for a statement: 15371 15372 void 15373 print_ops (tree stmt) 15374 { 15375 ssa_op_iter; 15376 tree var; 15377 15378 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 15379 print_generic_expr (stderr, var, TDF_SLIM); 15380 } 15381 15382 How to choose the appropriate iterator: 15383 15384 1. Determine whether you are need to see the operand pointers, or just 15385 the trees, and choose the appropriate macro: 15386 15387 Need Macro: 15388 ---- ------- 15389 use_operand_p FOR_EACH_SSA_USE_OPERAND 15390 def_operand_p FOR_EACH_SSA_DEF_OPERAND 15391 tree FOR_EACH_SSA_TREE_OPERAND 15392 15393 2. You need to declare a variable of the type you are interested in, 15394 and an ssa_op_iter structure which serves as the loop controlling 15395 variable. 15396 15397 3. Determine which operands you wish to use, and specify the flags of 15398 those you are interested in. They are documented in 15399 'tree-ssa-operands.h': 15400 15401 #define SSA_OP_USE 0x01 /* Real USE operands. */ 15402 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 15403 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 15404 #define SSA_OP_VDEF 0x08 /* VDEF operands. */ 15405 15406 /* These are commonly grouped operand flags. */ 15407 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE) 15408 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 15409 #define SSA_OP_ALL_VIRTUALS (SSA_OP_VIRTUAL_USES | SSA_OP_VIRTUAL_DEFS) 15410 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 15411 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 15412 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 15413 15414 So if you want to look at the use pointers for all the 'USE' and 'VUSE' 15415operands, you would do something like: 15416 15417 use_operand_p use_p; 15418 ssa_op_iter iter; 15419 15420 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 15421 { 15422 process_use_ptr (use_p); 15423 } 15424 15425 The 'TREE' macro is basically the same as the 'USE' and 'DEF' macros, 15426only with the use or def dereferenced via 'USE_FROM_PTR (use_p)' and 15427'DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use and 15428defs flags can be mixed. 15429 15430 tree var; 15431 ssa_op_iter iter; 15432 15433 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 15434 { 15435 print_generic_expr (stderr, var, TDF_SLIM); 15436 } 15437 15438 'VDEF's are broken into two flags, one for the 'DEF' portion 15439('SSA_OP_VDEF') and one for the USE portion ('SSA_OP_VUSE'). 15440 15441 There are many examples in the code, in addition to the documentation 15442in 'tree-ssa-operands.h' and 'ssa-iterators.h'. 15443 15444 There are also a couple of variants on the stmt iterators regarding PHI 15445nodes. 15446 15447 'FOR_EACH_PHI_ARG' Works exactly like 'FOR_EACH_SSA_USE_OPERAND', 15448except it works over 'PHI' arguments instead of statement operands. 15449 15450 /* Look at every virtual PHI use. */ 15451 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 15452 { 15453 my_code; 15454 } 15455 15456 /* Look at every real PHI use. */ 15457 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 15458 my_code; 15459 15460 /* Look at every PHI use. */ 15461 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 15462 my_code; 15463 15464 'FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 15465'FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 15466statement or a 'PHI' node. These should be used when it is appropriate 15467but they are not quite as efficient as the individual 'FOR_EACH_PHI' and 15468'FOR_EACH_SSA' routines. 15469 15470 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 15471 { 15472 my_code; 15473 } 15474 15475 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 15476 { 15477 my_code; 15478 } 15479 1548013.2.2 Immediate Uses 15481--------------------- 15482 15483Immediate use information is now always available. Using the immediate 15484use iterators, you may examine every use of any 'SSA_NAME'. For 15485instance, to change each use of 'ssa_var' to 'ssa_var2' and call 15486fold_stmt on each stmt after that is done: 15487 15488 use_operand_p imm_use_p; 15489 imm_use_iterator iterator; 15490 tree ssa_var, stmt; 15491 15492 15493 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 15494 { 15495 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 15496 SET_USE (imm_use_p, ssa_var_2); 15497 fold_stmt (stmt); 15498 } 15499 15500 There are 2 iterators which can be used. 'FOR_EACH_IMM_USE_FAST' is 15501used when the immediate uses are not changed, i.e., you are looking at 15502the uses, but not setting them. 15503 15504 If they do get changed, then care must be taken that things are not 15505changed under the iterators, so use the 'FOR_EACH_IMM_USE_STMT' and 15506'FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 15507sanity of the use list by moving all the uses for a statement into a 15508controlled position, and then iterating over those uses. Then the 15509optimization can manipulate the stmt when all the uses have been 15510processed. This is a little slower than the FAST version since it adds 15511a placeholder element and must sort through the list a bit for each 15512statement. This placeholder element must be also be removed if the loop 15513is terminated early. The macro 'BREAK_FROM_IMM_USE_STMT' is provided to 15514do this : 15515 15516 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 15517 { 15518 if (stmt == last_stmt) 15519 BREAK_FROM_IMM_USE_STMT (iterator); 15520 15521 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 15522 SET_USE (imm_use_p, ssa_var_2); 15523 fold_stmt (stmt); 15524 } 15525 15526 There are checks in 'verify_ssa' which verify that the immediate use 15527list is up to date, as well as checking that an optimization didn't 15528break from the loop without using this macro. It is safe to simply 15529'break'; from a 'FOR_EACH_IMM_USE_FAST' traverse. 15530 15531 Some useful functions and macros: 15532 1. 'has_zero_uses (ssa_var)' : Returns true if there are no uses of 15533 'ssa_var'. 15534 2. 'has_single_use (ssa_var)' : Returns true if there is only a single 15535 use of 'ssa_var'. 15536 3. 'single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 15537 Returns true if there is only a single use of 'ssa_var', and also 15538 returns the use pointer and statement it occurs in, in the second 15539 and third parameters. 15540 4. 'num_imm_uses (ssa_var)' : Returns the number of immediate uses of 15541 'ssa_var'. It is better not to use this if possible since it 15542 simply utilizes a loop to count the uses. 15543 5. 'PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a 'PHI' node, 15544 return the index number for the use. An assert is triggered if the 15545 use isn't located in a 'PHI' node. 15546 6. 'USE_STMT (use_p)' : Return the statement a use occurs in. 15547 15548 Note that uses are not put into an immediate use list until their 15549statement is actually inserted into the instruction stream via a 'bsi_*' 15550routine. 15551 15552 It is also still possible to utilize lazy updating of statements, but 15553this should be used only when absolutely required. Both alias analysis 15554and the dominator optimizations currently do this. 15555 15556 When lazy updating is being used, the immediate use information is out 15557of date and cannot be used reliably. Lazy updating is achieved by 15558simply marking statements modified via calls to 'gimple_set_modified' 15559instead of 'update_stmt'. When lazy updating is no longer required, all 15560the modified statements must have 'update_stmt' called in order to bring 15561them up to date. This must be done before the optimization is finished, 15562or 'verify_ssa' will trigger an abort. 15563 15564 This is done with a simple loop over the instruction stream: 15565 block_stmt_iterator bsi; 15566 basic_block bb; 15567 FOR_EACH_BB (bb) 15568 { 15569 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 15570 update_stmt_if_modified (bsi_stmt (bsi)); 15571 } 15572 15573 15574File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 15575 1557613.3 Static Single Assignment 15577============================= 15578 15579Most of the tree optimizers rely on the data flow information provided 15580by the Static Single Assignment (SSA) form. We implement the SSA form 15581as described in 'R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 15582Zadeck. Efficiently Computing Static Single Assignment Form and the 15583Control Dependence Graph. ACM Transactions on Programming Languages and 15584Systems, 13(4):451-490, October 1991'. 15585 15586 The SSA form is based on the premise that program variables are 15587assigned in exactly one location in the program. Multiple assignments 15588to the same variable create new versions of that variable. Naturally, 15589actual programs are seldom in SSA form initially because variables tend 15590to be assigned multiple times. The compiler modifies the program 15591representation so that every time a variable is assigned in the code, a 15592new version of the variable is created. Different versions of the same 15593variable are distinguished by subscripting the variable name with its 15594version number. Variables used in the right-hand side of expressions 15595are renamed so that their version number matches that of the most recent 15596assignment. 15597 15598 We represent variable versions using 'SSA_NAME' nodes. The renaming 15599process in 'tree-ssa.c' wraps every real and virtual operand with an 15600'SSA_NAME' node which contains the version number and the statement that 15601created the 'SSA_NAME'. Only definitions and virtual definitions may 15602create new 'SSA_NAME' nodes. 15603 15604 Sometimes, flow of control makes it impossible to determine the most 15605recent version of a variable. In these cases, the compiler inserts an 15606artificial definition for that variable called "PHI function" or "PHI 15607node". This new definition merges all the incoming versions of the 15608variable to create a new name for it. For instance, 15609 15610 if (...) 15611 a_1 = 5; 15612 else if (...) 15613 a_2 = 2; 15614 else 15615 a_3 = 13; 15616 15617 # a_4 = PHI <a_1, a_2, a_3> 15618 return a_4; 15619 15620 Since it is not possible to determine which of the three branches will 15621be taken at runtime, we don't know which of 'a_1', 'a_2' or 'a_3' to use 15622at the return statement. So, the SSA renamer creates a new version 15623'a_4' which is assigned the result of "merging" 'a_1', 'a_2' and 'a_3'. 15624Hence, PHI nodes mean "one of these operands. I don't know which". 15625 15626 The following functions can be used to examine PHI nodes 15627 15628 -- Function: gimple_phi_result (PHI) 15629 Returns the 'SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 15630 15631 -- Function: gimple_phi_num_args (PHI) 15632 Returns the number of arguments in PHI. This number is exactly the 15633 number of incoming edges to the basic block holding PHI. 15634 15635 -- Function: gimple_phi_arg (PHI, I) 15636 Returns Ith argument of PHI. 15637 15638 -- Function: gimple_phi_arg_edge (PHI, I) 15639 Returns the incoming edge for the Ith argument of PHI. 15640 15641 -- Function: gimple_phi_arg_def (PHI, I) 15642 Returns the 'SSA_NAME' for the Ith argument of PHI. 15643 1564413.3.1 Preserving the SSA form 15645------------------------------ 15646 15647Some optimization passes make changes to the function that invalidate 15648the SSA property. This can happen when a pass has added new symbols or 15649changed the program so that variables that were previously aliased 15650aren't anymore. Whenever something like this happens, the affected 15651symbols must be renamed into SSA form again. Transformations that emit 15652new code or replicate existing statements will also need to update the 15653SSA form. 15654 15655 Since GCC implements two different SSA forms for register and virtual 15656variables, keeping the SSA form up to date depends on whether you are 15657updating register or virtual names. In both cases, the general idea 15658behind incremental SSA updates is similar: when new SSA names are 15659created, they typically are meant to replace other existing names in the 15660program. 15661 15662 For instance, given the following code: 15663 15664 1 L0: 15665 2 x_1 = PHI (0, x_5) 15666 3 if (x_1 < 10) 15667 4 if (x_1 > 7) 15668 5 y_2 = 0 15669 6 else 15670 7 y_3 = x_1 + x_7 15671 8 endif 15672 9 x_5 = x_1 + 1 15673 10 goto L0; 15674 11 endif 15675 15676 Suppose that we insert new names 'x_10' and 'x_11' (lines '4' and '8'). 15677 15678 1 L0: 15679 2 x_1 = PHI (0, x_5) 15680 3 if (x_1 < 10) 15681 4 x_10 = ... 15682 5 if (x_1 > 7) 15683 6 y_2 = 0 15684 7 else 15685 8 x_11 = ... 15686 9 y_3 = x_1 + x_7 15687 10 endif 15688 11 x_5 = x_1 + 1 15689 12 goto L0; 15690 13 endif 15691 15692 We want to replace all the uses of 'x_1' with the new definitions of 15693'x_10' and 'x_11'. Note that the only uses that should be replaced are 15694those at lines '5', '9' and '11'. Also, the use of 'x_7' at line '9' 15695should _not_ be replaced (this is why we cannot just mark symbol 'x' for 15696renaming). 15697 15698 Additionally, we may need to insert a PHI node at line '11' because 15699that is a merge point for 'x_10' and 'x_11'. So the use of 'x_1' at 15700line '11' will be replaced with the new PHI node. The insertion of PHI 15701nodes is optional. They are not strictly necessary to preserve the SSA 15702form, and depending on what the caller inserted, they may not even be 15703useful for the optimizers. 15704 15705 Updating the SSA form is a two step process. First, the pass has to 15706identify which names need to be updated and/or which symbols need to be 15707renamed into SSA form for the first time. When new names are introduced 15708to replace existing names in the program, the mapping between the old 15709and the new names are registered by calling 'register_new_name_mapping' 15710(note that if your pass creates new code by duplicating basic blocks, 15711the call to 'tree_duplicate_bb' will set up the necessary mappings 15712automatically). 15713 15714 After the replacement mappings have been registered and new symbols 15715marked for renaming, a call to 'update_ssa' makes the registered 15716changes. This can be done with an explicit call or by creating 'TODO' 15717flags in the 'tree_opt_pass' structure for your pass. There are several 15718'TODO' flags that control the behavior of 'update_ssa': 15719 15720 * 'TODO_update_ssa'. Update the SSA form inserting PHI nodes for 15721 newly exposed symbols and virtual names marked for updating. When 15722 updating real names, only insert PHI nodes for a real name 'O_j' in 15723 blocks reached by all the new and old definitions for 'O_j'. If 15724 the iterated dominance frontier for 'O_j' is not pruned, we may end 15725 up inserting PHI nodes in blocks that have one or more edges with 15726 no incoming definition for 'O_j'. This would lead to uninitialized 15727 warnings for 'O_j''s symbol. 15728 15729 * 'TODO_update_ssa_no_phi'. Update the SSA form without inserting 15730 any new PHI nodes at all. This is used by passes that have either 15731 inserted all the PHI nodes themselves or passes that need only to 15732 patch use-def and def-def chains for virtuals (e.g., DCE). 15733 15734 * 'TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 15735 needed. No pruning of the IDF is done. This is used by passes 15736 that need the PHI nodes for 'O_j' even if it means that some 15737 arguments will come from the default definition of 'O_j''s symbol 15738 (e.g., 'pass_linear_transform'). 15739 15740 WARNING: If you need to use this flag, chances are that your pass 15741 may be doing something wrong. Inserting PHI nodes for an old name 15742 where not all edges carry a new replacement may lead to silent 15743 codegen errors or spurious uninitialized warnings. 15744 15745 * 'TODO_update_ssa_only_virtuals'. Passes that update the SSA form 15746 on their own may want to delegate the updating of virtual names to 15747 the generic updater. Since FUD chains are easier to maintain, this 15748 simplifies the work they need to do. NOTE: If this flag is used, 15749 any OLD->NEW mappings for real names are explicitly destroyed and 15750 only the symbols marked for renaming are processed. 15751 1575213.3.2 Examining 'SSA_NAME' nodes 15753--------------------------------- 15754 15755The following macros can be used to examine 'SSA_NAME' nodes 15756 15757 -- Macro: SSA_NAME_DEF_STMT (VAR) 15758 Returns the statement S that creates the 'SSA_NAME' VAR. If S is 15759 an empty statement (i.e., 'IS_EMPTY_STMT (S)' returns 'true'), it 15760 means that the first reference to this variable is a USE or a VUSE. 15761 15762 -- Macro: SSA_NAME_VERSION (VAR) 15763 Returns the version number of the 'SSA_NAME' object VAR. 15764 1576513.3.3 Walking the dominator tree 15766--------------------------------- 15767 15768 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 15769 15770 This function walks the dominator tree for the current CFG calling 15771 a set of callback functions defined in STRUCT DOM_WALK_DATA in 15772 'domwalk.h'. The call back functions you need to define give you 15773 hooks to execute custom code at various points during traversal: 15774 15775 1. Once to initialize any local data needed while processing BB 15776 and its children. This local data is pushed into an internal 15777 stack which is automatically pushed and popped as the walker 15778 traverses the dominator tree. 15779 15780 2. Once before traversing all the statements in the BB. 15781 15782 3. Once for every statement inside BB. 15783 15784 4. Once after traversing all the statements and before recursing 15785 into BB's dominator children. 15786 15787 5. It then recurses into all the dominator children of BB. 15788 15789 6. After recursing into all the dominator children of BB it can, 15790 optionally, traverse every statement in BB again (i.e., 15791 repeating steps 2 and 3). 15792 15793 7. Once after walking the statements in BB and BB's dominator 15794 children. At this stage, the block local data stack is 15795 popped. 15796 15797 15798File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 15799 1580013.4 Alias analysis 15801=================== 15802 15803Alias analysis in GIMPLE SSA form consists of two pieces. First the 15804virtual SSA web ties conflicting memory accesses and provides a SSA 15805use-def chain and SSA immediate-use chains for walking possibly 15806dependent memory accesses. Second an alias-oracle can be queried to 15807disambiguate explicit and implicit memory references. 15808 15809 1. Memory SSA form. 15810 15811 All statements that may use memory have exactly one accompanied use 15812 of a virtual SSA name that represents the state of memory at the 15813 given point in the IL. 15814 15815 All statements that may define memory have exactly one accompanied 15816 definition of a virtual SSA name using the previous state of memory 15817 and defining the new state of memory after the given point in the 15818 IL. 15819 15820 int i; 15821 int foo (void) 15822 { 15823 # .MEM_3 = VDEF <.MEM_2(D)> 15824 i = 1; 15825 # VUSE <.MEM_3> 15826 return i; 15827 } 15828 15829 The virtual SSA names in this case are '.MEM_2(D)' and '.MEM_3'. 15830 The store to the global variable 'i' defines '.MEM_3' invalidating 15831 '.MEM_2(D)'. The load from 'i' uses that new state '.MEM_3'. 15832 15833 The virtual SSA web serves as constraints to SSA optimizers 15834 preventing illegitimate code-motion and optimization. It also 15835 provides a way to walk related memory statements. 15836 15837 2. Points-to and escape analysis. 15838 15839 Points-to analysis builds a set of constraints from the GIMPLE SSA 15840 IL representing all pointer operations and facts we do or do not 15841 know about pointers. Solving this set of constraints yields a 15842 conservatively correct solution for each pointer variable in the 15843 program (though we are only interested in SSA name pointers) as to 15844 what it may possibly point to. 15845 15846 This points-to solution for a given SSA name pointer is stored in 15847 the 'pt_solution' sub-structure of the 'SSA_NAME_PTR_INFO' record. 15848 The following accessor functions are available: 15849 15850 * 'pt_solution_includes' 15851 * 'pt_solutions_intersect' 15852 15853 Points-to analysis also computes the solution for two special set 15854 of pointers, 'ESCAPED' and 'CALLUSED'. Those represent all memory 15855 that has escaped the scope of analysis or that is used by pure or 15856 nested const calls. 15857 15858 3. Type-based alias analysis 15859 15860 Type-based alias analysis is frontend dependent though generic 15861 support is provided by the middle-end in 'alias.c'. TBAA code is 15862 used by both tree optimizers and RTL optimizers. 15863 15864 Every language that wishes to perform language-specific alias 15865 analysis should define a function that computes, given a 'tree' 15866 node, an alias set for the node. Nodes in different alias sets are 15867 not allowed to alias. For an example, see the C front-end function 15868 'c_get_alias_set'. 15869 15870 4. Tree alias-oracle 15871 15872 The tree alias-oracle provides means to disambiguate two memory 15873 references and memory references against statements. The following 15874 queries are available: 15875 15876 * 'refs_may_alias_p' 15877 * 'ref_maybe_used_by_stmt_p' 15878 * 'stmt_may_clobber_ref_p' 15879 15880 In addition to those two kind of statement walkers are available 15881 walking statements related to a reference ref. 15882 'walk_non_aliased_vuses' walks over dominating memory defining 15883 statements and calls back if the statement does not clobber ref 15884 providing the non-aliased VUSE. The walk stops at the first 15885 clobbering statement or if asked to. 'walk_aliased_vdefs' walks 15886 over dominating memory defining statements and calls back on each 15887 statement clobbering ref providing its aliasing VDEF. The walk 15888 stops if asked to. 15889 15890 15891File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 15892 1589313.5 Memory model 15894================= 15895 15896The memory model used by the middle-end models that of the C/C++ 15897languages. The middle-end has the notion of an effective type of a 15898memory region which is used for type-based alias analysis. 15899 15900 The following is a refinement of ISO C99 6.5/6, clarifying the block 15901copy case to follow common sense and extending the concept of a dynamic 15902effective type to objects with a declared type as required for C++. 15903 15904 The effective type of an object for an access to its stored value is 15905 the declared type of the object or the effective type determined by 15906 a previous store to it. If a value is stored into an object through 15907 an lvalue having a type that is not a character type, then the 15908 type of the lvalue becomes the effective type of the object for that 15909 access and for subsequent accesses that do not modify the stored value. 15910 If a value is copied into an object using memcpy or memmove, 15911 or is copied as an array of character type, then the effective type 15912 of the modified object for that access and for subsequent accesses that 15913 do not modify the value is undetermined. For all other accesses to an 15914 object, the effective type of the object is simply the type of the 15915 lvalue used for the access. 15916 15917 15918File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 15919 1592014 RTL Representation 15921********************* 15922 15923The last part of the compiler work is done on a low-level intermediate 15924representation called Register Transfer Language. In this language, the 15925instructions to be output are described, pretty much one by one, in an 15926algebraic form that describes what the instruction does. 15927 15928 RTL is inspired by Lisp lists. It has both an internal form, made up 15929of structures that point at other structures, and a textual form that is 15930used in the machine description and in printed debugging dumps. The 15931textual form uses nested parentheses to indicate the pointers in the 15932internal form. 15933 15934* Menu: 15935 15936* RTL Objects:: Expressions vs vectors vs strings vs integers. 15937* RTL Classes:: Categories of RTL expression objects, and their structure. 15938* Accessors:: Macros to access expression operands or vector elts. 15939* Special Accessors:: Macros to access specific annotations on RTL. 15940* Flags:: Other flags in an RTL expression. 15941* Machine Modes:: Describing the size and format of a datum. 15942* Constants:: Expressions with constant values. 15943* Regs and Memory:: Expressions representing register contents or memory. 15944* Arithmetic:: Expressions representing arithmetic on other expressions. 15945* Comparisons:: Expressions representing comparison of expressions. 15946* Bit-Fields:: Expressions representing bit-fields in memory or reg. 15947* Vector Operations:: Expressions involving vector datatypes. 15948* Conversions:: Extending, truncating, floating or fixing. 15949* RTL Declarations:: Declaring volatility, constancy, etc. 15950* Side Effects:: Expressions for storing in registers, etc. 15951* Incdec:: Embedded side-effects for autoincrement addressing. 15952* Assembler:: Representing 'asm' with operands. 15953* Debug Information:: Expressions representing debugging information. 15954* Insns:: Expression types for entire insns. 15955* Calls:: RTL representation of function call insns. 15956* Sharing:: Some expressions are unique; others *must* be copied. 15957* Reading RTL:: Reading textual RTL from a file. 15958 15959 15960File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 15961 1596214.1 RTL Object Types 15963===================== 15964 15965RTL uses five kinds of objects: expressions, integers, wide integers, 15966strings and vectors. Expressions are the most important ones. An RTL 15967expression ("RTX", for short) is a C structure, but it is usually 15968referred to with a pointer; a type that is given the typedef name 'rtx'. 15969 15970 An integer is simply an 'int'; their written form uses decimal digits. 15971A wide integer is an integral object whose type is 'HOST_WIDE_INT'; 15972their written form uses decimal digits. 15973 15974 A string is a sequence of characters. In core it is represented as a 15975'char *' in usual C fashion, and it is written in C syntax as well. 15976However, strings in RTL may never be null. If you write an empty string 15977in a machine description, it is represented in core as a null pointer 15978rather than as a pointer to a null character. In certain contexts, 15979these null pointers instead of strings are valid. Within RTL code, 15980strings are most commonly found inside 'symbol_ref' expressions, but 15981they appear in other contexts in the RTL expressions that make up 15982machine descriptions. 15983 15984 In a machine description, strings are normally written with double 15985quotes, as you would in C. However, strings in machine descriptions may 15986extend over many lines, which is invalid C, and adjacent string 15987constants are not concatenated as they are in C. Any string constant 15988may be surrounded with a single set of parentheses. Sometimes this 15989makes the machine description easier to read. 15990 15991 There is also a special syntax for strings, which can be useful when C 15992code is embedded in a machine description. Wherever a string can 15993appear, it is also valid to write a C-style brace block. The entire 15994brace block, including the outermost pair of braces, is considered to be 15995the string constant. Double quote characters inside the braces are not 15996special. Therefore, if you write string constants in the C code, you 15997need not escape each quote character with a backslash. 15998 15999 A vector contains an arbitrary number of pointers to expressions. The 16000number of elements in the vector is explicitly present in the vector. 16001The written form of a vector consists of square brackets ('[...]') 16002surrounding the elements, in sequence and with whitespace separating 16003them. Vectors of length zero are not created; null pointers are used 16004instead. 16005 16006 Expressions are classified by "expression codes" (also called RTX 16007codes). The expression code is a name defined in 'rtl.def', which is 16008also (in uppercase) a C enumeration constant. The possible expression 16009codes and their meanings are machine-independent. The code of an RTX 16010can be extracted with the macro 'GET_CODE (X)' and altered with 16011'PUT_CODE (X, NEWCODE)'. 16012 16013 The expression code determines how many operands the expression 16014contains, and what kinds of objects they are. In RTL, unlike Lisp, you 16015cannot tell by looking at an operand what kind of object it is. 16016Instead, you must know from its context--from the expression code of the 16017containing expression. For example, in an expression of code 'subreg', 16018the first operand is to be regarded as an expression and the second 16019operand as a polynomial integer. In an expression of code 'plus', there 16020are two operands, both of which are to be regarded as expressions. In a 16021'symbol_ref' expression, there is one operand, which is to be regarded 16022as a string. 16023 16024 Expressions are written as parentheses containing the name of the 16025expression type, its flags and machine mode if any, and then the 16026operands of the expression (separated by spaces). 16027 16028 Expression code names in the 'md' file are written in lowercase, but 16029when they appear in C code they are written in uppercase. In this 16030manual, they are shown as follows: 'const_int'. 16031 16032 In a few contexts a null pointer is valid where an expression is 16033normally wanted. The written form of this is '(nil)'. 16034 16035 16036File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 16037 1603814.2 RTL Classes and Formats 16039============================ 16040 16041The various expression codes are divided into several "classes", which 16042are represented by single characters. You can determine the class of an 16043RTX code with the macro 'GET_RTX_CLASS (CODE)'. Currently, 'rtl.def' 16044defines these classes: 16045 16046'RTX_OBJ' 16047 An RTX code that represents an actual object, such as a register 16048 ('REG') or a memory location ('MEM', 'SYMBOL_REF'). 'LO_SUM') is 16049 also included; instead, 'SUBREG' and 'STRICT_LOW_PART' are not in 16050 this class, but in class 'RTX_EXTRA'. 16051 16052'RTX_CONST_OBJ' 16053 An RTX code that represents a constant object. 'HIGH' is also 16054 included in this class. 16055 16056'RTX_COMPARE' 16057 An RTX code for a non-symmetric comparison, such as 'GEU' or 'LT'. 16058 16059'RTX_COMM_COMPARE' 16060 An RTX code for a symmetric (commutative) comparison, such as 'EQ' 16061 or 'ORDERED'. 16062 16063'RTX_UNARY' 16064 An RTX code for a unary arithmetic operation, such as 'NEG', 'NOT', 16065 or 'ABS'. This category also includes value extension (sign or 16066 zero) and conversions between integer and floating point. 16067 16068'RTX_COMM_ARITH' 16069 An RTX code for a commutative binary operation, such as 'PLUS' or 16070 'AND'. 'NE' and 'EQ' are comparisons, so they have class 16071 'RTX_COMM_COMPARE'. 16072 16073'RTX_BIN_ARITH' 16074 An RTX code for a non-commutative binary operation, such as 16075 'MINUS', 'DIV', or 'ASHIFTRT'. 16076 16077'RTX_BITFIELD_OPS' 16078 An RTX code for a bit-field operation. Currently only 16079 'ZERO_EXTRACT' and 'SIGN_EXTRACT'. These have three inputs and are 16080 lvalues (so they can be used for insertion as well). *Note 16081 Bit-Fields::. 16082 16083'RTX_TERNARY' 16084 An RTX code for other three input operations. Currently only 16085 'IF_THEN_ELSE', 'VEC_MERGE', 'SIGN_EXTRACT', 'ZERO_EXTRACT', and 16086 'FMA'. 16087 16088'RTX_INSN' 16089 An RTX code for an entire instruction: 'INSN', 'JUMP_INSN', and 16090 'CALL_INSN'. *Note Insns::. 16091 16092'RTX_MATCH' 16093 An RTX code for something that matches in insns, such as 16094 'MATCH_DUP'. These only occur in machine descriptions. 16095 16096'RTX_AUTOINC' 16097 An RTX code for an auto-increment addressing mode, such as 16098 'POST_INC'. 'XEXP (X, 0)' gives the auto-modified register. 16099 16100'RTX_EXTRA' 16101 All other RTX codes. This category includes the remaining codes 16102 used only in machine descriptions ('DEFINE_*', etc.). It also 16103 includes all the codes describing side effects ('SET', 'USE', 16104 'CLOBBER', etc.) and the non-insns that may appear on an insn 16105 chain, such as 'NOTE', 'BARRIER', and 'CODE_LABEL'. 'SUBREG' is 16106 also part of this class. 16107 16108 For each expression code, 'rtl.def' specifies the number of contained 16109objects and their kinds using a sequence of characters called the 16110"format" of the expression code. For example, the format of 'subreg' is 16111'ep'. 16112 16113 These are the most commonly used format characters: 16114 16115'e' 16116 An expression (actually a pointer to an expression). 16117 16118'i' 16119 An integer. 16120 16121'w' 16122 A wide integer. 16123 16124's' 16125 A string. 16126 16127'E' 16128 A vector of expressions. 16129 16130 A few other format characters are used occasionally: 16131 16132'u' 16133 'u' is equivalent to 'e' except that it is printed differently in 16134 debugging dumps. It is used for pointers to insns. 16135 16136'n' 16137 'n' is equivalent to 'i' except that it is printed differently in 16138 debugging dumps. It is used for the line number or code number of 16139 a 'note' insn. 16140 16141'S' 16142 'S' indicates a string which is optional. In the RTL objects in 16143 core, 'S' is equivalent to 's', but when the object is read, from 16144 an 'md' file, the string value of this operand may be omitted. An 16145 omitted string is taken to be the null string. 16146 16147'V' 16148 'V' indicates a vector which is optional. In the RTL objects in 16149 core, 'V' is equivalent to 'E', but when the object is read from an 16150 'md' file, the vector value of this operand may be omitted. An 16151 omitted vector is effectively the same as a vector of no elements. 16152 16153'B' 16154 'B' indicates a pointer to basic block structure. 16155 16156'p' 16157 A polynomial integer. At present this is used only for 16158 'SUBREG_BYTE'. 16159 16160'0' 16161 '0' means a slot whose contents do not fit any normal category. 16162 '0' slots are not printed at all in dumps, and are often used in 16163 special ways by small parts of the compiler. 16164 16165 There are macros to get the number of operands and the format of an 16166expression code: 16167 16168'GET_RTX_LENGTH (CODE)' 16169 Number of operands of an RTX of code CODE. 16170 16171'GET_RTX_FORMAT (CODE)' 16172 The format of an RTX of code CODE, as a C string. 16173 16174 Some classes of RTX codes always have the same format. For example, it 16175is safe to assume that all comparison operations have format 'ee'. 16176 16177'RTX_UNARY' 16178 All codes of this class have format 'e'. 16179 16180'RTX_BIN_ARITH' 16181'RTX_COMM_ARITH' 16182'RTX_COMM_COMPARE' 16183'RTX_COMPARE' 16184 All codes of these classes have format 'ee'. 16185 16186'RTX_BITFIELD_OPS' 16187'RTX_TERNARY' 16188 All codes of these classes have format 'eee'. 16189 16190'RTX_INSN' 16191 All codes of this class have formats that begin with 'iuueiee'. 16192 *Note Insns::. Note that not all RTL objects linked onto an insn 16193 chain are of class 'RTX_INSN'. 16194 16195'RTX_CONST_OBJ' 16196'RTX_OBJ' 16197'RTX_MATCH' 16198'RTX_EXTRA' 16199 You can make no assumptions about the format of these codes. 16200 16201 16202File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 16203 1620414.3 Access to Operands 16205======================= 16206 16207Operands of expressions are accessed using the macros 'XEXP', 'XINT', 16208'XWINT' and 'XSTR'. Each of these macros takes two arguments: an 16209expression-pointer (RTX) and an operand number (counting from zero). 16210Thus, 16211 16212 XEXP (X, 2) 16213 16214accesses operand 2 of expression X, as an expression. 16215 16216 XINT (X, 2) 16217 16218accesses the same operand as an integer. 'XSTR', used in the same 16219fashion, would access it as a string. 16220 16221 Any operand can be accessed as an integer, as an expression or as a 16222string. You must choose the correct method of access for the kind of 16223value actually stored in the operand. You would do this based on the 16224expression code of the containing expression. That is also how you 16225would know how many operands there are. 16226 16227 For example, if X is an 'int_list' expression, you know that it has two 16228operands which can be correctly accessed as 'XINT (X, 0)' and 'XEXP (X, 162291)'. Incorrect accesses like 'XEXP (X, 0)' and 'XINT (X, 1)' would 16230compile, but would trigger an internal compiler error when rtl checking 16231is enabled. Nothing stops you from writing 'XEXP (X, 28)' either, but 16232this will access memory past the end of the expression with 16233unpredictable results. 16234 16235 Access to operands which are vectors is more complicated. You can use 16236the macro 'XVEC' to get the vector-pointer itself, or the macros 16237'XVECEXP' and 'XVECLEN' to access the elements and length of a vector. 16238 16239'XVEC (EXP, IDX)' 16240 Access the vector-pointer which is operand number IDX in EXP. 16241 16242'XVECLEN (EXP, IDX)' 16243 Access the length (number of elements) in the vector which is in 16244 operand number IDX in EXP. This value is an 'int'. 16245 16246'XVECEXP (EXP, IDX, ELTNUM)' 16247 Access element number ELTNUM in the vector which is in operand 16248 number IDX in EXP. This value is an RTX. 16249 16250 It is up to you to make sure that ELTNUM is not negative and is 16251 less than 'XVECLEN (EXP, IDX)'. 16252 16253 All the macros defined in this section expand into lvalues and 16254therefore can be used to assign the operands, lengths and vector 16255elements as well as to access them. 16256 16257 16258File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 16259 1626014.4 Access to Special Operands 16261=============================== 16262 16263Some RTL nodes have special annotations associated with them. 16264 16265'MEM' 16266 'MEM_ALIAS_SET (X)' 16267 If 0, X is not in any alias set, and may alias anything. 16268 Otherwise, X can only alias 'MEM's in a conflicting alias set. 16269 This value is set in a language-dependent manner in the 16270 front-end, and should not be altered in the back-end. In some 16271 front-ends, these numbers may correspond in some way to types, 16272 or other language-level entities, but they need not, and the 16273 back-end makes no such assumptions. These set numbers are 16274 tested with 'alias_sets_conflict_p'. 16275 16276 'MEM_EXPR (X)' 16277 If this register is known to hold the value of some user-level 16278 declaration, this is that tree node. It may also be a 16279 'COMPONENT_REF', in which case this is some field reference, 16280 and 'TREE_OPERAND (X, 0)' contains the declaration, or another 16281 'COMPONENT_REF', or null if there is no compile-time object 16282 associated with the reference. 16283 16284 'MEM_OFFSET_KNOWN_P (X)' 16285 True if the offset of the memory reference from 'MEM_EXPR' is 16286 known. 'MEM_OFFSET (X)' provides the offset if so. 16287 16288 'MEM_OFFSET (X)' 16289 The offset from the start of 'MEM_EXPR'. The value is only 16290 valid if 'MEM_OFFSET_KNOWN_P (X)' is true. 16291 16292 'MEM_SIZE_KNOWN_P (X)' 16293 True if the size of the memory reference is known. 'MEM_SIZE 16294 (X)' provides its size if so. 16295 16296 'MEM_SIZE (X)' 16297 The size in bytes of the memory reference. This is mostly 16298 relevant for 'BLKmode' references as otherwise the size is 16299 implied by the mode. The value is only valid if 16300 'MEM_SIZE_KNOWN_P (X)' is true. 16301 16302 'MEM_ALIGN (X)' 16303 The known alignment in bits of the memory reference. 16304 16305 'MEM_ADDR_SPACE (X)' 16306 The address space of the memory reference. This will commonly 16307 be zero for the generic address space. 16308 16309'REG' 16310 'ORIGINAL_REGNO (X)' 16311 This field holds the number the register "originally" had; for 16312 a pseudo register turned into a hard reg this will hold the 16313 old pseudo register number. 16314 16315 'REG_EXPR (X)' 16316 If this register is known to hold the value of some user-level 16317 declaration, this is that tree node. 16318 16319 'REG_OFFSET (X)' 16320 If this register is known to hold the value of some user-level 16321 declaration, this is the offset into that logical storage. 16322 16323'SYMBOL_REF' 16324 'SYMBOL_REF_DECL (X)' 16325 If the 'symbol_ref' X was created for a 'VAR_DECL' or a 16326 'FUNCTION_DECL', that tree is recorded here. If this value is 16327 null, then X was created by back end code generation routines, 16328 and there is no associated front end symbol table entry. 16329 16330 'SYMBOL_REF_DECL' may also point to a tree of class ''c'', 16331 that is, some sort of constant. In this case, the 16332 'symbol_ref' is an entry in the per-file constant pool; again, 16333 there is no associated front end symbol table entry. 16334 16335 'SYMBOL_REF_CONSTANT (X)' 16336 If 'CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 16337 pool entry for X. It is null otherwise. 16338 16339 'SYMBOL_REF_DATA (X)' 16340 A field of opaque type used to store 'SYMBOL_REF_DECL' or 16341 'SYMBOL_REF_CONSTANT'. 16342 16343 'SYMBOL_REF_FLAGS (X)' 16344 In a 'symbol_ref', this is used to communicate various 16345 predicates about the symbol. Some of these are common enough 16346 to be computed by common code, some are specific to the 16347 target. The common bits are: 16348 16349 'SYMBOL_FLAG_FUNCTION' 16350 Set if the symbol refers to a function. 16351 16352 'SYMBOL_FLAG_LOCAL' 16353 Set if the symbol is local to this "module". See 16354 'TARGET_BINDS_LOCAL_P'. 16355 16356 'SYMBOL_FLAG_EXTERNAL' 16357 Set if this symbol is not defined in this translation 16358 unit. Note that this is not the inverse of 16359 'SYMBOL_FLAG_LOCAL'. 16360 16361 'SYMBOL_FLAG_SMALL' 16362 Set if the symbol is located in the small data section. 16363 See 'TARGET_IN_SMALL_DATA_P'. 16364 16365 'SYMBOL_REF_TLS_MODEL (X)' 16366 This is a multi-bit field accessor that returns the 16367 'tls_model' to be used for a thread-local storage symbol. 16368 It returns zero for non-thread-local symbols. 16369 16370 'SYMBOL_FLAG_HAS_BLOCK_INFO' 16371 Set if the symbol has 'SYMBOL_REF_BLOCK' and 16372 'SYMBOL_REF_BLOCK_OFFSET' fields. 16373 16374 'SYMBOL_FLAG_ANCHOR' 16375 Set if the symbol is used as a section anchor. "Section 16376 anchors" are symbols that have a known position within an 16377 'object_block' and that can be used to access nearby 16378 members of that block. They are used to implement 16379 '-fsection-anchors'. 16380 16381 If this flag is set, then 'SYMBOL_FLAG_HAS_BLOCK_INFO' 16382 will be too. 16383 16384 Bits beginning with 'SYMBOL_FLAG_MACH_DEP' are available for 16385 the target's use. 16386 16387'SYMBOL_REF_BLOCK (X)' 16388 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the 'object_block' 16389 structure to which the symbol belongs, or 'NULL' if it has not been 16390 assigned a block. 16391 16392'SYMBOL_REF_BLOCK_OFFSET (X)' 16393 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 16394 the first object in 'SYMBOL_REF_BLOCK (X)'. The value is negative 16395 if X has not yet been assigned to a block, or it has not been given 16396 an offset within that block. 16397 16398 16399File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 16400 1640114.5 Flags in an RTL Expression 16402=============================== 16403 16404RTL expressions contain several flags (one-bit bit-fields) that are used 16405in certain types of expression. Most often they are accessed with the 16406following macros, which expand into lvalues. 16407 16408'CROSSING_JUMP_P (X)' 16409 Nonzero in a 'jump_insn' if it crosses between hot and cold 16410 sections, which could potentially be very far apart in the 16411 executable. The presence of this flag indicates to other 16412 optimizations that this branching instruction should not be 16413 "collapsed" into a simpler branching construct. It is used when 16414 the optimization to partition basic blocks into hot and cold 16415 sections is turned on. 16416 16417'CONSTANT_POOL_ADDRESS_P (X)' 16418 Nonzero in a 'symbol_ref' if it refers to part of the current 16419 function's constant pool. For most targets these addresses are in 16420 a '.rodata' section entirely separate from the function, but for 16421 some targets the addresses are close to the beginning of the 16422 function. In either case GCC assumes these addresses can be 16423 addressed directly, perhaps with the help of base registers. 16424 Stored in the 'unchanging' field and printed as '/u'. 16425 16426'INSN_ANNULLED_BRANCH_P (X)' 16427 In a 'jump_insn', 'call_insn', or 'insn' indicates that the branch 16428 is an annulling one. See the discussion under 'sequence' below. 16429 Stored in the 'unchanging' field and printed as '/u'. 16430 16431'INSN_DELETED_P (X)' 16432 In an 'insn', 'call_insn', 'jump_insn', 'code_label', 16433 'jump_table_data', 'barrier', or 'note', nonzero if the insn has 16434 been deleted. Stored in the 'volatil' field and printed as '/v'. 16435 16436'INSN_FROM_TARGET_P (X)' 16437 In an 'insn' or 'jump_insn' or 'call_insn' in a delay slot of a 16438 branch, indicates that the insn is from the target of the branch. 16439 If the branch insn has 'INSN_ANNULLED_BRANCH_P' set, this insn will 16440 only be executed if the branch is taken. For annulled branches 16441 with 'INSN_FROM_TARGET_P' clear, the insn will be executed only if 16442 the branch is not taken. When 'INSN_ANNULLED_BRANCH_P' is not set, 16443 this insn will always be executed. Stored in the 'in_struct' field 16444 and printed as '/s'. 16445 16446'LABEL_PRESERVE_P (X)' 16447 In a 'code_label' or 'note', indicates that the label is referenced 16448 by code or data not visible to the RTL of a given function. Labels 16449 referenced by a non-local goto will have this bit set. Stored in 16450 the 'in_struct' field and printed as '/s'. 16451 16452'LABEL_REF_NONLOCAL_P (X)' 16453 In 'label_ref' and 'reg_label' expressions, nonzero if this is a 16454 reference to a non-local label. Stored in the 'volatil' field and 16455 printed as '/v'. 16456 16457'MEM_KEEP_ALIAS_SET_P (X)' 16458 In 'mem' expressions, 1 if we should keep the alias set for this 16459 mem unchanged when we access a component. Set to 1, for example, 16460 when we are already in a non-addressable component of an aggregate. 16461 Stored in the 'jump' field and printed as '/j'. 16462 16463'MEM_VOLATILE_P (X)' 16464 In 'mem', 'asm_operands', and 'asm_input' expressions, nonzero for 16465 volatile memory references. Stored in the 'volatil' field and 16466 printed as '/v'. 16467 16468'MEM_NOTRAP_P (X)' 16469 In 'mem', nonzero for memory references that will not trap. Stored 16470 in the 'call' field and printed as '/c'. 16471 16472'MEM_POINTER (X)' 16473 Nonzero in a 'mem' if the memory reference holds a pointer. Stored 16474 in the 'frame_related' field and printed as '/f'. 16475 16476'MEM_READONLY_P (X)' 16477 Nonzero in a 'mem', if the memory is statically allocated and 16478 read-only. 16479 16480 Read-only in this context means never modified during the lifetime 16481 of the program, not necessarily in ROM or in write-disabled pages. 16482 A common example of the later is a shared library's global offset 16483 table. This table is initialized by the runtime loader, so the 16484 memory is technically writable, but after control is transferred 16485 from the runtime loader to the application, this memory will never 16486 be subsequently modified. 16487 16488 Stored in the 'unchanging' field and printed as '/u'. 16489 16490'PREFETCH_SCHEDULE_BARRIER_P (X)' 16491 In a 'prefetch', indicates that the prefetch is a scheduling 16492 barrier. No other INSNs will be moved over it. Stored in the 16493 'volatil' field and printed as '/v'. 16494 16495'REG_FUNCTION_VALUE_P (X)' 16496 Nonzero in a 'reg' if it is the place in which this function's 16497 value is going to be returned. (This happens only in a hard 16498 register.) Stored in the 'return_val' field and printed as '/i'. 16499 16500'REG_POINTER (X)' 16501 Nonzero in a 'reg' if the register holds a pointer. Stored in the 16502 'frame_related' field and printed as '/f'. 16503 16504'REG_USERVAR_P (X)' 16505 In a 'reg', nonzero if it corresponds to a variable present in the 16506 user's source code. Zero for temporaries generated internally by 16507 the compiler. Stored in the 'volatil' field and printed as '/v'. 16508 16509 The same hard register may be used also for collecting the values 16510 of functions called by this one, but 'REG_FUNCTION_VALUE_P' is zero 16511 in this kind of use. 16512 16513'RTL_CONST_CALL_P (X)' 16514 In a 'call_insn' indicates that the insn represents a call to a 16515 const function. Stored in the 'unchanging' field and printed as 16516 '/u'. 16517 16518'RTL_PURE_CALL_P (X)' 16519 In a 'call_insn' indicates that the insn represents a call to a 16520 pure function. Stored in the 'return_val' field and printed as 16521 '/i'. 16522 16523'RTL_CONST_OR_PURE_CALL_P (X)' 16524 In a 'call_insn', true if 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' 16525 is true. 16526 16527'RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 16528 In a 'call_insn' indicates that the insn represents a possibly 16529 infinite looping call to a const or pure function. Stored in the 16530 'call' field and printed as '/c'. Only true if one of 16531 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' is true. 16532 16533'RTX_FRAME_RELATED_P (X)' 16534 Nonzero in an 'insn', 'call_insn', 'jump_insn', 'barrier', or 'set' 16535 which is part of a function prologue and sets the stack pointer, 16536 sets the frame pointer, or saves a register. This flag should also 16537 be set on an instruction that sets up a temporary register to use 16538 in place of the frame pointer. Stored in the 'frame_related' field 16539 and printed as '/f'. 16540 16541 In particular, on RISC targets where there are limits on the sizes 16542 of immediate constants, it is sometimes impossible to reach the 16543 register save area directly from the stack pointer. In that case, 16544 a temporary register is used that is near enough to the register 16545 save area, and the Canonical Frame Address, i.e., DWARF2's logical 16546 frame pointer, register must (temporarily) be changed to be this 16547 temporary register. So, the instruction that sets this temporary 16548 register must be marked as 'RTX_FRAME_RELATED_P'. 16549 16550 If the marked instruction is overly complex (defined in terms of 16551 what 'dwarf2out_frame_debug_expr' can handle), you will also have 16552 to create a 'REG_FRAME_RELATED_EXPR' note and attach it to the 16553 instruction. This note should contain a simple expression of the 16554 computation performed by this instruction, i.e., one that 16555 'dwarf2out_frame_debug_expr' can handle. 16556 16557 This flag is required for exception handling support on targets 16558 with RTL prologues. 16559 16560'SCHED_GROUP_P (X)' 16561 During instruction scheduling, in an 'insn', 'call_insn', 16562 'jump_insn' or 'jump_table_data', indicates that the previous insn 16563 must be scheduled together with this insn. This is used to ensure 16564 that certain groups of instructions will not be split up by the 16565 instruction scheduling pass, for example, 'use' insns before a 16566 'call_insn' may not be separated from the 'call_insn'. Stored in 16567 the 'in_struct' field and printed as '/s'. 16568 16569'SET_IS_RETURN_P (X)' 16570 For a 'set', nonzero if it is for a return. Stored in the 'jump' 16571 field and printed as '/j'. 16572 16573'SIBLING_CALL_P (X)' 16574 For a 'call_insn', nonzero if the insn is a sibling call. Stored 16575 in the 'jump' field and printed as '/j'. 16576 16577'STRING_POOL_ADDRESS_P (X)' 16578 For a 'symbol_ref' expression, nonzero if it addresses this 16579 function's string constant pool. Stored in the 'frame_related' 16580 field and printed as '/f'. 16581 16582'SUBREG_PROMOTED_UNSIGNED_P (X)' 16583 Returns a value greater then zero for a 'subreg' that has 16584 'SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 16585 kept zero-extended, zero if it is kept sign-extended, and less then 16586 zero if it is extended some other way via the 'ptr_extend' 16587 instruction. Stored in the 'unchanging' field and 'volatil' field, 16588 printed as '/u' and '/v'. This macro may only be used to get the 16589 value it may not be used to change the value. Use 16590 'SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 16591 16592'SUBREG_PROMOTED_UNSIGNED_SET (X)' 16593 Set the 'unchanging' and 'volatil' fields in a 'subreg' to reflect 16594 zero, sign, or other extension. If 'volatil' is zero, then 16595 'unchanging' as nonzero means zero extension and as zero means sign 16596 extension. If 'volatil' is nonzero then some other type of 16597 extension was done via the 'ptr_extend' instruction. 16598 16599'SUBREG_PROMOTED_VAR_P (X)' 16600 Nonzero in a 'subreg' if it was made when accessing an object that 16601 was promoted to a wider mode in accord with the 'PROMOTED_MODE' 16602 machine description macro (*note Storage Layout::). In this case, 16603 the mode of the 'subreg' is the declared mode of the object and the 16604 mode of 'SUBREG_REG' is the mode of the register that holds the 16605 object. Promoted variables are always either sign- or 16606 zero-extended to the wider mode on every assignment. Stored in the 16607 'in_struct' field and printed as '/s'. 16608 16609'SYMBOL_REF_USED (X)' 16610 In a 'symbol_ref', indicates that X has been used. This is 16611 normally only used to ensure that X is only declared external once. 16612 Stored in the 'used' field. 16613 16614'SYMBOL_REF_WEAK (X)' 16615 In a 'symbol_ref', indicates that X has been declared weak. Stored 16616 in the 'return_val' field and printed as '/i'. 16617 16618'SYMBOL_REF_FLAG (X)' 16619 In a 'symbol_ref', this is used as a flag for machine-specific 16620 purposes. Stored in the 'volatil' field and printed as '/v'. 16621 16622 Most uses of 'SYMBOL_REF_FLAG' are historic and may be subsumed by 16623 'SYMBOL_REF_FLAGS'. Certainly use of 'SYMBOL_REF_FLAGS' is 16624 mandatory if the target requires more than one bit of storage. 16625 16626 These are the fields to which the above macros refer: 16627 16628'call' 16629 In a 'mem', 1 means that the memory reference will not trap. 16630 16631 In a 'call', 1 means that this pure or const call may possibly 16632 infinite loop. 16633 16634 In an RTL dump, this flag is represented as '/c'. 16635 16636'frame_related' 16637 In an 'insn' or 'set' expression, 1 means that it is part of a 16638 function prologue and sets the stack pointer, sets the frame 16639 pointer, saves a register, or sets up a temporary register to use 16640 in place of the frame pointer. 16641 16642 In 'reg' expressions, 1 means that the register holds a pointer. 16643 16644 In 'mem' expressions, 1 means that the memory reference holds a 16645 pointer. 16646 16647 In 'symbol_ref' expressions, 1 means that the reference addresses 16648 this function's string constant pool. 16649 16650 In an RTL dump, this flag is represented as '/f'. 16651 16652'in_struct' 16653 In 'reg' expressions, it is 1 if the register has its entire life 16654 contained within the test expression of some loop. 16655 16656 In 'subreg' expressions, 1 means that the 'subreg' is accessing an 16657 object that has had its mode promoted from a wider mode. 16658 16659 In 'label_ref' expressions, 1 means that the referenced label is 16660 outside the innermost loop containing the insn in which the 16661 'label_ref' was found. 16662 16663 In 'code_label' expressions, it is 1 if the label may never be 16664 deleted. This is used for labels which are the target of non-local 16665 gotos. Such a label that would have been deleted is replaced with 16666 a 'note' of type 'NOTE_INSN_DELETED_LABEL'. 16667 16668 In an 'insn' during dead-code elimination, 1 means that the insn is 16669 dead code. 16670 16671 In an 'insn' or 'jump_insn' during reorg for an insn in the delay 16672 slot of a branch, 1 means that this insn is from the target of the 16673 branch. 16674 16675 In an 'insn' during instruction scheduling, 1 means that this insn 16676 must be scheduled as part of a group together with the previous 16677 insn. 16678 16679 In an RTL dump, this flag is represented as '/s'. 16680 16681'return_val' 16682 In 'reg' expressions, 1 means the register contains the value to be 16683 returned by the current function. On machines that pass parameters 16684 in registers, the same register number may be used for parameters 16685 as well, but this flag is not set on such uses. 16686 16687 In 'symbol_ref' expressions, 1 means the referenced symbol is weak. 16688 16689 In 'call' expressions, 1 means the call is pure. 16690 16691 In an RTL dump, this flag is represented as '/i'. 16692 16693'jump' 16694 In a 'mem' expression, 1 means we should keep the alias set for 16695 this mem unchanged when we access a component. 16696 16697 In a 'set', 1 means it is for a return. 16698 16699 In a 'call_insn', 1 means it is a sibling call. 16700 16701 In a 'jump_insn', 1 means it is a crossing jump. 16702 16703 In an RTL dump, this flag is represented as '/j'. 16704 16705'unchanging' 16706 In 'reg' and 'mem' expressions, 1 means that the value of the 16707 expression never changes. 16708 16709 In 'subreg' expressions, it is 1 if the 'subreg' references an 16710 unsigned object whose mode has been promoted to a wider mode. 16711 16712 In an 'insn' or 'jump_insn' in the delay slot of a branch 16713 instruction, 1 means an annulling branch should be used. 16714 16715 In a 'symbol_ref' expression, 1 means that this symbol addresses 16716 something in the per-function constant pool. 16717 16718 In a 'call_insn' 1 means that this instruction is a call to a const 16719 function. 16720 16721 In an RTL dump, this flag is represented as '/u'. 16722 16723'used' 16724 This flag is used directly (without an access macro) at the end of 16725 RTL generation for a function, to count the number of times an 16726 expression appears in insns. Expressions that appear more than 16727 once are copied, according to the rules for shared structure (*note 16728 Sharing::). 16729 16730 For a 'reg', it is used directly (without an access macro) by the 16731 leaf register renumbering code to ensure that each register is only 16732 renumbered once. 16733 16734 In a 'symbol_ref', it indicates that an external declaration for 16735 the symbol has already been written. 16736 16737'volatil' 16738 In a 'mem', 'asm_operands', or 'asm_input' expression, it is 1 if 16739 the memory reference is volatile. Volatile memory references may 16740 not be deleted, reordered or combined. 16741 16742 In a 'symbol_ref' expression, it is used for machine-specific 16743 purposes. 16744 16745 In a 'reg' expression, it is 1 if the value is a user-level 16746 variable. 0 indicates an internal compiler temporary. 16747 16748 In an 'insn', 1 means the insn has been deleted. 16749 16750 In 'label_ref' and 'reg_label' expressions, 1 means a reference to 16751 a non-local label. 16752 16753 In 'prefetch' expressions, 1 means that the containing insn is a 16754 scheduling barrier. 16755 16756 In an RTL dump, this flag is represented as '/v'. 16757 16758 16759File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 16760 1676114.6 Machine Modes 16762================== 16763 16764A machine mode describes a size of data object and the representation 16765used for it. In the C code, machine modes are represented by an 16766enumeration type, 'machine_mode', defined in 'machmode.def'. Each RTL 16767expression has room for a machine mode and so do certain kinds of tree 16768expressions (declarations and types, to be precise). 16769 16770 In debugging dumps and machine descriptions, the machine mode of an RTL 16771expression is written after the expression code with a colon to separate 16772them. The letters 'mode' which appear at the end of each machine mode 16773name are omitted. For example, '(reg:SI 38)' is a 'reg' expression with 16774machine mode 'SImode'. If the mode is 'VOIDmode', it is not written at 16775all. 16776 16777 Here is a table of machine modes. The term "byte" below refers to an 16778object of 'BITS_PER_UNIT' bits (*note Storage Layout::). 16779 16780'BImode' 16781 "Bit" mode represents a single bit, for predicate registers. 16782 16783'QImode' 16784 "Quarter-Integer" mode represents a single byte treated as an 16785 integer. 16786 16787'HImode' 16788 "Half-Integer" mode represents a two-byte integer. 16789 16790'PSImode' 16791 "Partial Single Integer" mode represents an integer which occupies 16792 four bytes but which doesn't really use all four. On some 16793 machines, this is the right mode to use for pointers. 16794 16795'SImode' 16796 "Single Integer" mode represents a four-byte integer. 16797 16798'PDImode' 16799 "Partial Double Integer" mode represents an integer which occupies 16800 eight bytes but which doesn't really use all eight. On some 16801 machines, this is the right mode to use for certain pointers. 16802 16803'DImode' 16804 "Double Integer" mode represents an eight-byte integer. 16805 16806'TImode' 16807 "Tetra Integer" (?) mode represents a sixteen-byte integer. 16808 16809'OImode' 16810 "Octa Integer" (?) mode represents a thirty-two-byte integer. 16811 16812'XImode' 16813 "Hexadeca Integer" (?) mode represents a sixty-four-byte integer. 16814 16815'QFmode' 16816 "Quarter-Floating" mode represents a quarter-precision (single 16817 byte) floating point number. 16818 16819'HFmode' 16820 "Half-Floating" mode represents a half-precision (two byte) 16821 floating point number. 16822 16823'TQFmode' 16824 "Three-Quarter-Floating" (?) mode represents a 16825 three-quarter-precision (three byte) floating point number. 16826 16827'SFmode' 16828 "Single Floating" mode represents a four byte floating point 16829 number. In the common case, of a processor with IEEE arithmetic 16830 and 8-bit bytes, this is a single-precision IEEE floating point 16831 number; it can also be used for double-precision (on processors 16832 with 16-bit bytes) and single-precision VAX and IBM types. 16833 16834'DFmode' 16835 "Double Floating" mode represents an eight byte floating point 16836 number. In the common case, of a processor with IEEE arithmetic 16837 and 8-bit bytes, this is a double-precision IEEE floating point 16838 number. 16839 16840'XFmode' 16841 "Extended Floating" mode represents an IEEE extended floating point 16842 number. This mode only has 80 meaningful bits (ten bytes). Some 16843 processors require such numbers to be padded to twelve bytes, 16844 others to sixteen; this mode is used for either. 16845 16846'SDmode' 16847 "Single Decimal Floating" mode represents a four byte decimal 16848 floating point number (as distinct from conventional binary 16849 floating point). 16850 16851'DDmode' 16852 "Double Decimal Floating" mode represents an eight byte decimal 16853 floating point number. 16854 16855'TDmode' 16856 "Tetra Decimal Floating" mode represents a sixteen byte decimal 16857 floating point number all 128 of whose bits are meaningful. 16858 16859'TFmode' 16860 "Tetra Floating" mode represents a sixteen byte floating point 16861 number all 128 of whose bits are meaningful. One common use is the 16862 IEEE quad-precision format. 16863 16864'QQmode' 16865 "Quarter-Fractional" mode represents a single byte treated as a 16866 signed fractional number. The default format is "s.7". 16867 16868'HQmode' 16869 "Half-Fractional" mode represents a two-byte signed fractional 16870 number. The default format is "s.15". 16871 16872'SQmode' 16873 "Single Fractional" mode represents a four-byte signed fractional 16874 number. The default format is "s.31". 16875 16876'DQmode' 16877 "Double Fractional" mode represents an eight-byte signed fractional 16878 number. The default format is "s.63". 16879 16880'TQmode' 16881 "Tetra Fractional" mode represents a sixteen-byte signed fractional 16882 number. The default format is "s.127". 16883 16884'UQQmode' 16885 "Unsigned Quarter-Fractional" mode represents a single byte treated 16886 as an unsigned fractional number. The default format is ".8". 16887 16888'UHQmode' 16889 "Unsigned Half-Fractional" mode represents a two-byte unsigned 16890 fractional number. The default format is ".16". 16891 16892'USQmode' 16893 "Unsigned Single Fractional" mode represents a four-byte unsigned 16894 fractional number. The default format is ".32". 16895 16896'UDQmode' 16897 "Unsigned Double Fractional" mode represents an eight-byte unsigned 16898 fractional number. The default format is ".64". 16899 16900'UTQmode' 16901 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 16902 fractional number. The default format is ".128". 16903 16904'HAmode' 16905 "Half-Accumulator" mode represents a two-byte signed accumulator. 16906 The default format is "s8.7". 16907 16908'SAmode' 16909 "Single Accumulator" mode represents a four-byte signed 16910 accumulator. The default format is "s16.15". 16911 16912'DAmode' 16913 "Double Accumulator" mode represents an eight-byte signed 16914 accumulator. The default format is "s32.31". 16915 16916'TAmode' 16917 "Tetra Accumulator" mode represents a sixteen-byte signed 16918 accumulator. The default format is "s64.63". 16919 16920'UHAmode' 16921 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 16922 accumulator. The default format is "8.8". 16923 16924'USAmode' 16925 "Unsigned Single Accumulator" mode represents a four-byte unsigned 16926 accumulator. The default format is "16.16". 16927 16928'UDAmode' 16929 "Unsigned Double Accumulator" mode represents an eight-byte 16930 unsigned accumulator. The default format is "32.32". 16931 16932'UTAmode' 16933 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 16934 unsigned accumulator. The default format is "64.64". 16935 16936'CCmode' 16937 "Condition Code" mode represents the value of a condition code, 16938 which is a machine-specific set of bits used to represent the 16939 result of a comparison operation. Other machine-specific modes may 16940 also be used for the condition code. These modes are not used on 16941 machines that use 'cc0' (*note Condition Code::). 16942 16943'BLKmode' 16944 "Block" mode represents values that are aggregates to which none of 16945 the other modes apply. In RTL, only memory references can have 16946 this mode, and only if they appear in string-move or vector 16947 instructions. On machines which have no such instructions, 16948 'BLKmode' will not appear in RTL. 16949 16950'VOIDmode' 16951 Void mode means the absence of a mode or an unspecified mode. For 16952 example, RTL expressions of code 'const_int' have mode 'VOIDmode' 16953 because they can be taken to have whatever mode the context 16954 requires. In debugging dumps of RTL, 'VOIDmode' is expressed by 16955 the absence of any mode. 16956 16957'QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 16958 These modes stand for a complex number represented as a pair of 16959 floating point values. The floating point values are in 'QFmode', 16960 'HFmode', 'SFmode', 'DFmode', 'XFmode', and 'TFmode', respectively. 16961 16962'CQImode, CHImode, CSImode, CDImode, CTImode, COImode, CPSImode' 16963 These modes stand for a complex number represented as a pair of 16964 integer values. The integer values are in 'QImode', 'HImode', 16965 'SImode', 'DImode', 'TImode', 'OImode', and 'PSImode', 16966 respectively. 16967 16968'BND32mode BND64mode' 16969 These modes stand for bounds for pointer of 32 and 64 bit size 16970 respectively. Mode size is double pointer mode size. 16971 16972 The machine description defines 'Pmode' as a C macro which expands into 16973the machine mode used for addresses. Normally this is the mode whose 16974size is 'BITS_PER_WORD', 'SImode' on 32-bit machines. 16975 16976 The only modes which a machine description must support are 'QImode', 16977and the modes corresponding to 'BITS_PER_WORD', 'FLOAT_TYPE_SIZE' and 16978'DOUBLE_TYPE_SIZE'. The compiler will attempt to use 'DImode' for 169798-byte structures and unions, but this can be prevented by overriding 16980the definition of 'MAX_FIXED_MODE_SIZE'. Alternatively, you can have 16981the compiler use 'TImode' for 16-byte structures and unions. Likewise, 16982you can arrange for the C type 'short int' to avoid using 'HImode'. 16983 16984 Very few explicit references to machine modes remain in the compiler 16985and these few references will soon be removed. Instead, the machine 16986modes are divided into mode classes. These are represented by the 16987enumeration type 'enum mode_class' defined in 'machmode.h'. The 16988possible mode classes are: 16989 16990'MODE_INT' 16991 Integer modes. By default these are 'BImode', 'QImode', 'HImode', 16992 'SImode', 'DImode', 'TImode', and 'OImode'. 16993 16994'MODE_PARTIAL_INT' 16995 The "partial integer" modes, 'PQImode', 'PHImode', 'PSImode' and 16996 'PDImode'. 16997 16998'MODE_FLOAT' 16999 Floating point modes. By default these are 'QFmode', 'HFmode', 17000 'TQFmode', 'SFmode', 'DFmode', 'XFmode' and 'TFmode'. 17001 17002'MODE_DECIMAL_FLOAT' 17003 Decimal floating point modes. By default these are 'SDmode', 17004 'DDmode' and 'TDmode'. 17005 17006'MODE_FRACT' 17007 Signed fractional modes. By default these are 'QQmode', 'HQmode', 17008 'SQmode', 'DQmode' and 'TQmode'. 17009 17010'MODE_UFRACT' 17011 Unsigned fractional modes. By default these are 'UQQmode', 17012 'UHQmode', 'USQmode', 'UDQmode' and 'UTQmode'. 17013 17014'MODE_ACCUM' 17015 Signed accumulator modes. By default these are 'HAmode', 'SAmode', 17016 'DAmode' and 'TAmode'. 17017 17018'MODE_UACCUM' 17019 Unsigned accumulator modes. By default these are 'UHAmode', 17020 'USAmode', 'UDAmode' and 'UTAmode'. 17021 17022'MODE_COMPLEX_INT' 17023 Complex integer modes. (These are not currently implemented). 17024 17025'MODE_COMPLEX_FLOAT' 17026 Complex floating point modes. By default these are 'QCmode', 17027 'HCmode', 'SCmode', 'DCmode', 'XCmode', and 'TCmode'. 17028 17029'MODE_CC' 17030 Modes representing condition code values. These are 'CCmode' plus 17031 any 'CC_MODE' modes listed in the 'MACHINE-modes.def'. *Note Jump 17032 Patterns::, also see *note Condition Code::. 17033 17034'MODE_POINTER_BOUNDS' 17035 Pointer bounds modes. Used to represent values of pointer bounds 17036 type. Operations in these modes may be executed as NOPs depending 17037 on hardware features and environment setup. 17038 17039'MODE_RANDOM' 17040 This is a catchall mode class for modes which don't fit into the 17041 above classes. Currently 'VOIDmode' and 'BLKmode' are in 17042 'MODE_RANDOM'. 17043 17044 'machmode.h' also defines various wrapper classes that combine a 17045'machine_mode' with a static assertion that a particular condition 17046holds. The classes are: 17047 17048'scalar_int_mode' 17049 A mode that has class 'MODE_INT' or 'MODE_PARTIAL_INT'. 17050 17051'scalar_float_mode' 17052 A mode that has class 'MODE_FLOAT' or 'MODE_DECIMAL_FLOAT'. 17053 17054'scalar_mode' 17055 A mode that holds a single numerical value. In practice this means 17056 that the mode is a 'scalar_int_mode', is a 'scalar_float_mode', or 17057 has class 'MODE_FRACT', 'MODE_UFRACT', 'MODE_ACCUM', 'MODE_UACCUM' 17058 or 'MODE_POINTER_BOUNDS'. 17059 17060'complex_mode' 17061 A mode that has class 'MODE_COMPLEX_INT' or 'MODE_COMPLEX_FLOAT'. 17062 17063'fixed_size_mode' 17064 A mode whose size is known at compile time. 17065 17066 Named modes use the most constrained of the available wrapper classes, 17067if one exists, otherwise they use 'machine_mode'. For example, 'QImode' 17068is a 'scalar_int_mode', 'SFmode' is a 'scalar_float_mode' and 'BLKmode' 17069is a plain 'machine_mode'. It is possible to refer to any mode as a raw 17070'machine_mode' by adding the 'E_' prefix, where 'E' stands for 17071"enumeration". For example, the raw 'machine_mode' names of the modes 17072just mentioned are 'E_QImode', 'E_SFmode' and 'E_BLKmode' respectively. 17073 17074 The wrapper classes implicitly convert to 'machine_mode' and to any 17075wrapper class that represents a more general condition; for example 17076'scalar_int_mode' and 'scalar_float_mode' both convert to 'scalar_mode' 17077and all three convert to 'fixed_size_mode'. The classes act like 17078'machine_mode's that accept only certain named modes. 17079 17080 'machmode.h' also defines a template class 'opt_mode<T>' that holds a 17081'T' or nothing, where 'T' can be either 'machine_mode' or one of the 17082wrapper classes above. The main operations on an 'opt_mode<T>' X are as 17083follows: 17084 17085'X.exists ()' 17086 Return true if X holds a mode rather than nothing. 17087 17088'X.exists (&Y)' 17089 Return true if X holds a mode rather than nothing, storing the mode 17090 in Y if so. Y must be assignment-compatible with T. 17091 17092'X.require ()' 17093 Assert that X holds a mode rather than nothing and return that 17094 mode. 17095 17096'X = Y' 17097 Set X to Y, where Y is a T or implicitly converts to a T. 17098 17099 The default constructor sets an 'opt_mode<T>' to nothing. There is 17100also a constructor that takes an initial value of type T. 17101 17102 It is possible to use the 'is-a.h' accessors on a 'machine_mode' or 17103machine mode wrapper X: 17104 17105'is_a <T> (X)' 17106 Return true if X meets the conditions for wrapper class T. 17107 17108'is_a <T> (X, &Y)' 17109 Return true if X meets the conditions for wrapper class T, storing 17110 it in Y if so. Y must be assignment-compatible with T. 17111 17112'as_a <T> (X)' 17113 Assert that X meets the conditions for wrapper class T and return 17114 it as a T. 17115 17116'dyn_cast <T> (X)' 17117 Return an 'opt_mode<T>' that holds X if X meets the conditions for 17118 wrapper class T and that holds nothing otherwise. 17119 17120 The purpose of these wrapper classes is to give stronger static type 17121checking. For example, if a function takes a 'scalar_int_mode', a 17122caller that has a general 'machine_mode' must either check or assert 17123that the code is indeed a scalar integer first, using one of the 17124functions above. 17125 17126 The wrapper classes are normal C++ classes, with user-defined 17127constructors. Sometimes it is useful to have a POD version of the same 17128type, particularly if the type appears in a 'union'. The template class 17129'pod_mode<T>' provides a POD version of wrapper class T. It is 17130assignment-compatible with T and implicitly converts to both 17131'machine_mode' and T. 17132 17133 Here are some C macros that relate to machine modes: 17134 17135'GET_MODE (X)' 17136 Returns the machine mode of the RTX X. 17137 17138'PUT_MODE (X, NEWMODE)' 17139 Alters the machine mode of the RTX X to be NEWMODE. 17140 17141'NUM_MACHINE_MODES' 17142 Stands for the number of machine modes available on the target 17143 machine. This is one greater than the largest numeric value of any 17144 machine mode. 17145 17146'GET_MODE_NAME (M)' 17147 Returns the name of mode M as a string. 17148 17149'GET_MODE_CLASS (M)' 17150 Returns the mode class of mode M. 17151 17152'GET_MODE_WIDER_MODE (M)' 17153 Returns the next wider natural mode. For example, the expression 17154 'GET_MODE_WIDER_MODE (QImode)' returns 'HImode'. 17155 17156'GET_MODE_SIZE (M)' 17157 Returns the size in bytes of a datum of mode M. 17158 17159'GET_MODE_BITSIZE (M)' 17160 Returns the size in bits of a datum of mode M. 17161 17162'GET_MODE_IBIT (M)' 17163 Returns the number of integral bits of a datum of fixed-point mode 17164 M. 17165 17166'GET_MODE_FBIT (M)' 17167 Returns the number of fractional bits of a datum of fixed-point 17168 mode M. 17169 17170'GET_MODE_MASK (M)' 17171 Returns a bitmask containing 1 for all bits in a word that fit 17172 within mode M. This macro can only be used for modes whose bitsize 17173 is less than or equal to 'HOST_BITS_PER_INT'. 17174 17175'GET_MODE_ALIGNMENT (M)' 17176 Return the required alignment, in bits, for an object of mode M. 17177 17178'GET_MODE_UNIT_SIZE (M)' 17179 Returns the size in bytes of the subunits of a datum of mode M. 17180 This is the same as 'GET_MODE_SIZE' except in the case of complex 17181 modes. For them, the unit size is the size of the real or 17182 imaginary part. 17183 17184'GET_MODE_NUNITS (M)' 17185 Returns the number of units contained in a mode, i.e., 17186 'GET_MODE_SIZE' divided by 'GET_MODE_UNIT_SIZE'. 17187 17188'GET_CLASS_NARROWEST_MODE (C)' 17189 Returns the narrowest mode in mode class C. 17190 17191 The following 3 variables are defined on every target. They can be 17192used to allocate buffers that are guaranteed to be large enough to hold 17193any value that can be represented on the target. The first two can be 17194overridden by defining them in the target's mode.def file, however, the 17195value must be a constant that can determined very early in the 17196compilation process. The third symbol cannot be overridden. 17197 17198'BITS_PER_UNIT' 17199 The number of bits in an addressable storage unit (byte). If you 17200 do not define this, the default is 8. 17201 17202'MAX_BITSIZE_MODE_ANY_INT' 17203 The maximum bitsize of any mode that is used in integer math. This 17204 should be overridden by the target if it uses large integers as 17205 containers for larger vectors but otherwise never uses the contents 17206 to compute integer values. 17207 17208'MAX_BITSIZE_MODE_ANY_MODE' 17209 The bitsize of the largest mode on the target. The default value 17210 is the largest mode size given in the mode definition file, which 17211 is always correct for targets whose modes have a fixed size. 17212 Targets that might increase the size of a mode beyond this default 17213 should define 'MAX_BITSIZE_MODE_ANY_MODE' to the actual upper limit 17214 in 'MACHINE-modes.def'. 17215 17216 The global variables 'byte_mode' and 'word_mode' contain modes whose 17217classes are 'MODE_INT' and whose bitsizes are either 'BITS_PER_UNIT' or 17218'BITS_PER_WORD', respectively. On 32-bit machines, these are 'QImode' 17219and 'SImode', respectively. 17220 17221 17222File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 17223 1722414.7 Constant Expression Types 17225============================== 17226 17227The simplest RTL expressions are those that represent constant values. 17228 17229'(const_int I)' 17230 This type of expression represents the integer value I. I is 17231 customarily accessed with the macro 'INTVAL' as in 'INTVAL (EXP)', 17232 which is equivalent to 'XWINT (EXP, 0)'. 17233 17234 Constants generated for modes with fewer bits than in 17235 'HOST_WIDE_INT' must be sign extended to full width (e.g., with 17236 'gen_int_mode'). For constants for modes with more bits than in 17237 'HOST_WIDE_INT' the implied high order bits of that constant are 17238 copies of the top bit. Note however that values are neither 17239 inherently signed nor inherently unsigned; where necessary, 17240 signedness is determined by the rtl operation instead. 17241 17242 There is only one expression object for the integer value zero; it 17243 is the value of the variable 'const0_rtx'. Likewise, the only 17244 expression for integer value one is found in 'const1_rtx', the only 17245 expression for integer value two is found in 'const2_rtx', and the 17246 only expression for integer value negative one is found in 17247 'constm1_rtx'. Any attempt to create an expression of code 17248 'const_int' and value zero, one, two or negative one will return 17249 'const0_rtx', 'const1_rtx', 'const2_rtx' or 'constm1_rtx' as 17250 appropriate. 17251 17252 Similarly, there is only one object for the integer whose value is 17253 'STORE_FLAG_VALUE'. It is found in 'const_true_rtx'. If 17254 'STORE_FLAG_VALUE' is one, 'const_true_rtx' and 'const1_rtx' will 17255 point to the same object. If 'STORE_FLAG_VALUE' is -1, 17256 'const_true_rtx' and 'constm1_rtx' will point to the same object. 17257 17258'(const_double:M I0 I1 ...)' 17259 This represents either a floating-point constant of mode M or (on 17260 older ports that do not define 'TARGET_SUPPORTS_WIDE_INT') an 17261 integer constant too large to fit into 'HOST_BITS_PER_WIDE_INT' 17262 bits but small enough to fit within twice that number of bits. In 17263 the latter case, M will be 'VOIDmode'. For integral values 17264 constants for modes with more bits than twice the number in 17265 'HOST_WIDE_INT' the implied high order bits of that constant are 17266 copies of the top bit of 'CONST_DOUBLE_HIGH'. Note however that 17267 integral values are neither inherently signed nor inherently 17268 unsigned; where necessary, signedness is determined by the rtl 17269 operation instead. 17270 17271 On more modern ports, 'CONST_DOUBLE' only represents floating point 17272 values. New ports define 'TARGET_SUPPORTS_WIDE_INT' to make this 17273 designation. 17274 17275 If M is 'VOIDmode', the bits of the value are stored in I0 and I1. 17276 I0 is customarily accessed with the macro 'CONST_DOUBLE_LOW' and I1 17277 with 'CONST_DOUBLE_HIGH'. 17278 17279 If the constant is floating point (regardless of its precision), 17280 then the number of integers used to store the value depends on the 17281 size of 'REAL_VALUE_TYPE' (*note Floating Point::). The integers 17282 represent a floating point number, but not precisely in the target 17283 machine's or host machine's floating point format. To convert them 17284 to the precise bit pattern used by the target machine, use the 17285 macro 'REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 17286 Output::). 17287 17288'(const_wide_int:M NUNITS ELT0 ...)' 17289 This contains an array of 'HOST_WIDE_INT's that is large enough to 17290 hold any constant that can be represented on the target. This form 17291 of rtl is only used on targets that define 17292 'TARGET_SUPPORTS_WIDE_INT' to be nonzero and then 'CONST_DOUBLE's 17293 are only used to hold floating-point values. If the target leaves 17294 'TARGET_SUPPORTS_WIDE_INT' defined as 0, 'CONST_WIDE_INT's are not 17295 used and 'CONST_DOUBLE's are as they were before. 17296 17297 The values are stored in a compressed format. The higher-order 0s 17298 or -1s are not represented if they are just the logical sign 17299 extension of the number that is represented. 17300 17301'CONST_WIDE_INT_VEC (CODE)' 17302 Returns the entire array of 'HOST_WIDE_INT's that are used to store 17303 the value. This macro should be rarely used. 17304 17305'CONST_WIDE_INT_NUNITS (CODE)' 17306 The number of 'HOST_WIDE_INT's used to represent the number. Note 17307 that this generally is smaller than the number of 'HOST_WIDE_INT's 17308 implied by the mode size. 17309 17310'CONST_WIDE_INT_ELT (CODE,I)' 17311 Returns the 'i'th element of the array. Element 0 is contains the 17312 low order bits of the constant. 17313 17314'(const_fixed:M ...)' 17315 Represents a fixed-point constant of mode M. The operand is a data 17316 structure of type 'struct fixed_value' and is accessed with the 17317 macro 'CONST_FIXED_VALUE'. The high part of data is accessed with 17318 'CONST_FIXED_VALUE_HIGH'; the low part is accessed with 17319 'CONST_FIXED_VALUE_LOW'. 17320 17321'(const_poly_int:M [C0 C1 ...])' 17322 Represents a 'poly_int'-style polynomial integer with coefficients 17323 C0, C1, .... The coefficients are 'wide_int'-based integers rather 17324 than rtxes. 'CONST_POLY_INT_COEFFS' gives the values of individual 17325 coefficients (which is mostly only useful in low-level routines) 17326 and 'const_poly_int_value' gives the full 'poly_int' value. 17327 17328'(const_vector:M [X0 X1 ...])' 17329 Represents a vector constant. The values in square brackets are 17330 elements of the vector, which are always 'const_int', 17331 'const_wide_int', 'const_double' or 'const_fixed' expressions. 17332 17333 Each vector constant V is treated as a specific instance of an 17334 arbitrary-length sequence that itself contains 17335 'CONST_VECTOR_NPATTERNS (V)' interleaved patterns. Each pattern 17336 has the form: 17337 17338 { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... } 17339 17340 The first three elements in each pattern are enough to determine 17341 the values of the other elements. However, if all STEPs are zero, 17342 only the first two elements are needed. If in addition each BASE1 17343 is equal to the corresponding BASE0, only the first element in each 17344 pattern is needed. The number of determining elements per pattern 17345 is given by 'CONST_VECTOR_NELTS_PER_PATTERN (V)'. 17346 17347 For example, the constant: 17348 17349 { 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 } 17350 17351 is interpreted as an interleaving of the sequences: 17352 17353 { 0, 2, 3, 4, 5, 6, 7, 8 } 17354 { 1, 6, 8, 10, 12, 14, 16, 18 } 17355 17356 where the sequences are represented by the following patterns: 17357 17358 BASE0 == 0, BASE1 == 2, STEP == 1 17359 BASE0 == 1, BASE1 == 6, STEP == 2 17360 17361 In this case: 17362 17363 CONST_VECTOR_NPATTERNS (V) == 2 17364 CONST_VECTOR_NELTS_PER_PATTERN (V) == 3 17365 17366 Thus the first 6 elements ('{ 0, 1, 2, 6, 3, 8 }') are enough to 17367 determine the whole sequence; we refer to them as the "encoded" 17368 elements. They are the only elements present in the square 17369 brackets for variable-length 'const_vector's (i.e. for 17370 'const_vector's whose mode M has a variable number of elements). 17371 However, as a convenience to code that needs to handle both 17372 'const_vector's and 'parallel's, all elements are present in the 17373 square brackets for fixed-length 'const_vector's; the encoding 17374 scheme simply reduces the amount of work involved in processing 17375 constants that follow a regular pattern. 17376 17377 Sometimes this scheme can create two possible encodings of the same 17378 vector. For example { 0, 1 } could be seen as two patterns with 17379 one element each or one pattern with two elements (BASE0 and 17380 BASE1). The canonical encoding is always the one with the fewest 17381 patterns or (if both encodings have the same number of petterns) 17382 the one with the fewest encoded elements. 17383 17384 'const_vector_encoding_nelts (V)' gives the total number of encoded 17385 elements in V, which is 6 in the example above. 17386 'CONST_VECTOR_ENCODED_ELT (V, I)' accesses the value of encoded 17387 element I. 17388 17389 'CONST_VECTOR_DUPLICATE_P (V)' is true if V simply contains 17390 repeated instances of 'CONST_VECTOR_NPATTERNS (V)' values. This is 17391 a shorthand for testing 'CONST_VECTOR_NELTS_PER_PATTERN (V) == 1'. 17392 17393 'CONST_VECTOR_STEPPED_P (V)' is true if at least one pattern in V 17394 has a nonzero step. This is a shorthand for testing 17395 'CONST_VECTOR_NELTS_PER_PATTERN (V) == 3'. 17396 17397 'CONST_VECTOR_NUNITS (V)' gives the total number of elements in V; 17398 it is a shorthand for getting the number of units in 'GET_MODE 17399 (V)'. 17400 17401 The utility function 'const_vector_elt' gives the value of an 17402 arbitrary element as an 'rtx'. 'const_vector_int_elt' gives the 17403 same value as a 'wide_int'. 17404 17405'(const_string STR)' 17406 Represents a constant string with value STR. Currently this is 17407 used only for insn attributes (*note Insn Attributes::) since 17408 constant strings in C are placed in memory. 17409 17410'(symbol_ref:MODE SYMBOL)' 17411 Represents the value of an assembler label for data. SYMBOL is a 17412 string that describes the name of the assembler label. If it 17413 starts with a '*', the label is the rest of SYMBOL not including 17414 the '*'. Otherwise, the label is SYMBOL, usually prefixed with 17415 '_'. 17416 17417 The 'symbol_ref' contains a mode, which is usually 'Pmode'. 17418 Usually that is the only mode for which a symbol is directly valid. 17419 17420'(label_ref:MODE LABEL)' 17421 Represents the value of an assembler label for code. It contains 17422 one operand, an expression, which must be a 'code_label' or a 17423 'note' of type 'NOTE_INSN_DELETED_LABEL' that appears in the 17424 instruction sequence to identify the place where the label should 17425 go. 17426 17427 The reason for using a distinct expression type for code label 17428 references is so that jump optimization can distinguish them. 17429 17430 The 'label_ref' contains a mode, which is usually 'Pmode'. Usually 17431 that is the only mode for which a label is directly valid. 17432 17433'(const:M EXP)' 17434 Represents a constant that is the result of an assembly-time 17435 arithmetic computation. The operand, EXP, contains only 17436 'const_int', 'symbol_ref', 'label_ref' or 'unspec' expressions, 17437 combined with 'plus' and 'minus'. Any such 'unspec's are 17438 target-specific and typically represent some form of relocation 17439 operator. M should be a valid address mode. 17440 17441'(high:M EXP)' 17442 Represents the high-order bits of EXP. The number of bits is 17443 machine-dependent and is normally the number of bits specified in 17444 an instruction that initializes the high order bits of a register. 17445 It is used with 'lo_sum' to represent the typical two-instruction 17446 sequence used in RISC machines to reference large immediate values 17447 and/or link-time constants such as global memory addresses. In the 17448 latter case, M is 'Pmode' and EXP is usually a constant expression 17449 involving 'symbol_ref'. 17450 17451 The macro 'CONST0_RTX (MODE)' refers to an expression with value 0 in 17452mode MODE. If mode MODE is of mode class 'MODE_INT', it returns 17453'const0_rtx'. If mode MODE is of mode class 'MODE_FLOAT', it returns a 17454'CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 17455'CONST_VECTOR' expression in mode MODE. Similarly, the macro 17456'CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 17457and similarly for 'CONST2_RTX'. The 'CONST1_RTX' and 'CONST2_RTX' 17458macros are undefined for vector modes. 17459 17460 17461File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 17462 1746314.8 Registers and Memory 17464========================= 17465 17466Here are the RTL expression types for describing access to machine 17467registers and to main memory. 17468 17469'(reg:M N)' 17470 For small values of the integer N (those that are less than 17471 'FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 17472 register number N: a "hard register". For larger values of N, it 17473 stands for a temporary value or "pseudo register". The compiler's 17474 strategy is to generate code assuming an unlimited number of such 17475 pseudo registers, and later convert them into hard registers or 17476 into memory references. 17477 17478 M is the machine mode of the reference. It is necessary because 17479 machines can generally refer to each register in more than one 17480 mode. For example, a register may contain a full word but there 17481 may be instructions to refer to it as a half word or as a single 17482 byte, as well as instructions to refer to it as a floating point 17483 number of various precisions. 17484 17485 Even for a register that the machine can access in only one mode, 17486 the mode must always be specified. 17487 17488 The symbol 'FIRST_PSEUDO_REGISTER' is defined by the machine 17489 description, since the number of hard registers on the machine is 17490 an invariant characteristic of the machine. Note, however, that 17491 not all of the machine registers must be general registers. All 17492 the machine registers that can be used for storage of data are 17493 given hard register numbers, even those that can be used only in 17494 certain instructions or can hold only certain types of data. 17495 17496 A hard register may be accessed in various modes throughout one 17497 function, but each pseudo register is given a natural mode and is 17498 accessed only in that mode. When it is necessary to describe an 17499 access to a pseudo register using a nonnatural mode, a 'subreg' 17500 expression is used. 17501 17502 A 'reg' expression with a machine mode that specifies more than one 17503 word of data may actually stand for several consecutive registers. 17504 If in addition the register number specifies a hardware register, 17505 then it actually represents several consecutive hardware registers 17506 starting with the specified one. 17507 17508 Each pseudo register number used in a function's RTL code is 17509 represented by a unique 'reg' expression. 17510 17511 Some pseudo register numbers, those within the range of 17512 'FIRST_VIRTUAL_REGISTER' to 'LAST_VIRTUAL_REGISTER' only appear 17513 during the RTL generation phase and are eliminated before the 17514 optimization phases. These represent locations in the stack frame 17515 that cannot be determined until RTL generation for the function has 17516 been completed. The following virtual register numbers are 17517 defined: 17518 17519 'VIRTUAL_INCOMING_ARGS_REGNUM' 17520 This points to the first word of the incoming arguments passed 17521 on the stack. Normally these arguments are placed there by 17522 the caller, but the callee may have pushed some arguments that 17523 were previously passed in registers. 17524 17525 When RTL generation is complete, this virtual register is 17526 replaced by the sum of the register given by 17527 'ARG_POINTER_REGNUM' and the value of 'FIRST_PARM_OFFSET'. 17528 17529 'VIRTUAL_STACK_VARS_REGNUM' 17530 If 'FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 17531 points to immediately above the first variable on the stack. 17532 Otherwise, it points to the first variable on the stack. 17533 17534 'VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 17535 register given by 'FRAME_POINTER_REGNUM' and the value 17536 'TARGET_STARTING_FRAME_OFFSET'. 17537 17538 'VIRTUAL_STACK_DYNAMIC_REGNUM' 17539 This points to the location of dynamically allocated memory on 17540 the stack immediately after the stack pointer has been 17541 adjusted by the amount of memory desired. 17542 17543 This virtual register is replaced by the sum of the register 17544 given by 'STACK_POINTER_REGNUM' and the value 17545 'STACK_DYNAMIC_OFFSET'. 17546 17547 'VIRTUAL_OUTGOING_ARGS_REGNUM' 17548 This points to the location in the stack at which outgoing 17549 arguments should be written when the stack is pre-pushed 17550 (arguments pushed using push insns should always use 17551 'STACK_POINTER_REGNUM'). 17552 17553 This virtual register is replaced by the sum of the register 17554 given by 'STACK_POINTER_REGNUM' and the value 17555 'STACK_POINTER_OFFSET'. 17556 17557'(subreg:M1 REG:M2 BYTENUM)' 17558 17559 'subreg' expressions are used to refer to a register in a machine 17560 mode other than its natural one, or to refer to one register of a 17561 multi-part 'reg' that actually refers to several registers. 17562 17563 Each pseudo register has a natural mode. If it is necessary to 17564 operate on it in a different mode, the register must be enclosed in 17565 a 'subreg'. 17566 17567 There are currently three supported types for the first operand of 17568 a 'subreg': 17569 * pseudo registers This is the most common case. Most 'subreg's 17570 have pseudo 'reg's as their first operand. 17571 17572 * mem 'subreg's of 'mem' were common in earlier versions of GCC 17573 and are still supported. During the reload pass these are 17574 replaced by plain 'mem's. On machines that do not do 17575 instruction scheduling, use of 'subreg's of 'mem' are still 17576 used, but this is no longer recommended. Such 'subreg's are 17577 considered to be 'register_operand's rather than 17578 'memory_operand's before and during reload. Because of this, 17579 the scheduling passes cannot properly schedule instructions 17580 with 'subreg's of 'mem', so for machines that do scheduling, 17581 'subreg's of 'mem' should never be used. To support this, the 17582 combine and recog passes have explicit code to inhibit the 17583 creation of 'subreg's of 'mem' when 'INSN_SCHEDULING' is 17584 defined. 17585 17586 The use of 'subreg's of 'mem' after the reload pass is an area 17587 that is not well understood and should be avoided. There is 17588 still some code in the compiler to support this, but this code 17589 has possibly rotted. This use of 'subreg's is discouraged and 17590 will most likely not be supported in the future. 17591 17592 * hard registers It is seldom necessary to wrap hard registers 17593 in 'subreg's; such registers would normally reduce to a single 17594 'reg' rtx. This use of 'subreg's is discouraged and may not 17595 be supported in the future. 17596 17597 'subreg's of 'subreg's are not supported. Using 17598 'simplify_gen_subreg' is the recommended way to avoid this problem. 17599 17600 'subreg's come in two distinct flavors, each having its own usage 17601 and rules: 17602 17603 Paradoxical subregs 17604 When M1 is strictly wider than M2, the 'subreg' expression is 17605 called "paradoxical". The canonical test for this class of 17606 'subreg' is: 17607 17608 paradoxical_subreg_p (M1, M2) 17609 17610 Paradoxical 'subreg's can be used as both lvalues and rvalues. 17611 When used as an lvalue, the low-order bits of the source value 17612 are stored in REG and the high-order bits are discarded. When 17613 used as an rvalue, the low-order bits of the 'subreg' are 17614 taken from REG while the high-order bits may or may not be 17615 defined. 17616 17617 The high-order bits of rvalues are defined in the following 17618 circumstances: 17619 17620 * 'subreg's of 'mem' When M2 is smaller than a word, the 17621 macro 'LOAD_EXTEND_OP', can control how the high-order 17622 bits are defined. 17623 17624 * 'subreg' of 'reg's The upper bits are defined when 17625 'SUBREG_PROMOTED_VAR_P' is true. 17626 'SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 17627 bits hold. Such subregs usually represent local 17628 variables, register variables and parameter pseudo 17629 variables that have been promoted to a wider mode. 17630 17631 BYTENUM is always zero for a paradoxical 'subreg', even on 17632 big-endian targets. 17633 17634 For example, the paradoxical 'subreg': 17635 17636 (set (subreg:SI (reg:HI X) 0) Y) 17637 17638 stores the lower 2 bytes of Y in X and discards the upper 2 17639 bytes. A subsequent: 17640 17641 (set Z (subreg:SI (reg:HI X) 0)) 17642 17643 would set the lower two bytes of Z to Y and set the upper two 17644 bytes to an unknown value assuming 'SUBREG_PROMOTED_VAR_P' is 17645 false. 17646 17647 Normal subregs 17648 When M1 is at least as narrow as M2 the 'subreg' expression is 17649 called "normal". 17650 17651 Normal 'subreg's restrict consideration to certain bits of 17652 REG. For this purpose, REG is divided into 17653 individually-addressable blocks in which each block has: 17654 17655 REGMODE_NATURAL_SIZE (M2) 17656 17657 bytes. Usually the value is 'UNITS_PER_WORD'; that is, most 17658 targets usually treat each word of a register as being 17659 independently addressable. 17660 17661 There are two types of normal 'subreg'. If M1 is known to be 17662 no bigger than a block, the 'subreg' refers to the 17663 least-significant part (or "lowpart") of one block of REG. If 17664 M1 is known to be larger than a block, the 'subreg' refers to 17665 two or more complete blocks. 17666 17667 When used as an lvalue, 'subreg' is a block-based accessor. 17668 Storing to a 'subreg' modifies all the blocks of REG that 17669 overlap the 'subreg', but it leaves the other blocks of REG 17670 alone. 17671 17672 When storing to a normal 'subreg' that is smaller than a 17673 block, the other bits of the referenced block are usually left 17674 in an undefined state. This laxity makes it easier to 17675 generate efficient code for such instructions. To represent 17676 an instruction that preserves all the bits outside of those in 17677 the 'subreg', use 'strict_low_part' or 'zero_extract' around 17678 the 'subreg'. 17679 17680 BYTENUM must identify the offset of the first byte of the 17681 'subreg' from the start of REG, assuming that REG is laid out 17682 in memory order. The memory order of bytes is defined by two 17683 target macros, 'WORDS_BIG_ENDIAN' and 'BYTES_BIG_ENDIAN': 17684 17685 * 'WORDS_BIG_ENDIAN', if set to 1, says that byte number 17686 zero is part of the most significant word; otherwise, it 17687 is part of the least significant word. 17688 17689 * 'BYTES_BIG_ENDIAN', if set to 1, says that byte number 17690 zero is the most significant byte within a word; 17691 otherwise, it is the least significant byte within a 17692 word. 17693 17694 On a few targets, 'FLOAT_WORDS_BIG_ENDIAN' disagrees with 17695 'WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 17696 floating point values as if they had the same endianness as 17697 integer values. This works because they handle them solely as 17698 a collection of integer values, with no particular numerical 17699 value. Only real.c and the runtime libraries care about 17700 'FLOAT_WORDS_BIG_ENDIAN'. 17701 17702 Thus, 17703 17704 (subreg:HI (reg:SI X) 2) 17705 17706 on a 'BYTES_BIG_ENDIAN', 'UNITS_PER_WORD == 4' target is the 17707 same as 17708 17709 (subreg:HI (reg:SI X) 0) 17710 17711 on a little-endian, 'UNITS_PER_WORD == 4' target. Both 17712 'subreg's access the lower two bytes of register X. 17713 17714 Note that the byte offset is a polynomial integer; it may not 17715 be a compile-time constant on targets with variable-sized 17716 modes. However, the restrictions above mean that there are 17717 only a certain set of acceptable offsets for a given 17718 combination of M1 and M2. The compiler can always tell which 17719 blocks a valid subreg occupies, and whether the subreg is a 17720 lowpart of a block. 17721 17722 A 'MODE_PARTIAL_INT' mode behaves as if it were as wide as the 17723 corresponding 'MODE_INT' mode, except that it has an unknown number 17724 of undefined bits. For example: 17725 17726 (subreg:PSI (reg:SI 0) 0) 17727 17728 accesses the whole of '(reg:SI 0)', but the exact relationship 17729 between the 'PSImode' value and the 'SImode' value is not defined. 17730 If we assume 'REGMODE_NATURAL_SIZE (DImode) <= 4', then the 17731 following two 'subreg's: 17732 17733 (subreg:PSI (reg:DI 0) 0) 17734 (subreg:PSI (reg:DI 0) 4) 17735 17736 represent independent 4-byte accesses to the two halves of '(reg:DI 17737 0)'. Both 'subreg's have an unknown number of undefined bits. 17738 17739 If 'REGMODE_NATURAL_SIZE (PSImode) <= 2' then these two 'subreg's: 17740 17741 (subreg:HI (reg:PSI 0) 0) 17742 (subreg:HI (reg:PSI 0) 2) 17743 17744 represent independent 2-byte accesses that together span the whole 17745 of '(reg:PSI 0)'. Storing to the first 'subreg' does not affect 17746 the value of the second, and vice versa. '(reg:PSI 0)' has an 17747 unknown number of undefined bits, so the assignment: 17748 17749 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 17750 17751 does not guarantee that '(subreg:HI (reg:PSI 0) 0)' has the value 17752 '(reg:HI 4)'. 17753 17754 The rules above apply to both pseudo REGs and hard REGs. If the 17755 semantics are not correct for particular combinations of M1, M2 and 17756 hard REG, the target-specific code must ensure that those 17757 combinations are never used. For example: 17758 17759 TARGET_CAN_CHANGE_MODE_CLASS (M2, M1, CLASS) 17760 17761 must be false for every class CLASS that includes REG. 17762 17763 GCC must be able to determine at compile time whether a subreg is 17764 paradoxical, whether it occupies a whole number of blocks, or 17765 whether it is a lowpart of a block. This means that certain 17766 combinations of variable-sized mode are not permitted. For 17767 example, if M2 holds N 'SI' values, where N is greater than zero, 17768 it is not possible to form a 'DI' 'subreg' of it; such a 'subreg' 17769 would be paradoxical when N is 1 but not when N is greater than 1. 17770 17771 The first operand of a 'subreg' expression is customarily accessed 17772 with the 'SUBREG_REG' macro and the second operand is customarily 17773 accessed with the 'SUBREG_BYTE' macro. 17774 17775 It has been several years since a platform in which 17776 'BYTES_BIG_ENDIAN' not equal to 'WORDS_BIG_ENDIAN' has been tested. 17777 Anyone wishing to support such a platform in the future may be 17778 confronted with code rot. 17779 17780'(scratch:M)' 17781 This represents a scratch register that will be required for the 17782 execution of a single instruction and not used subsequently. It is 17783 converted into a 'reg' by either the local register allocator or 17784 the reload pass. 17785 17786 'scratch' is usually present inside a 'clobber' operation (*note 17787 Side Effects::). 17788 17789'(cc0)' 17790 This refers to the machine's condition code register. It has no 17791 operands and may not have a machine mode. There are two ways to 17792 use it: 17793 17794 * To stand for a complete set of condition code flags. This is 17795 best on most machines, where each comparison sets the entire 17796 series of flags. 17797 17798 With this technique, '(cc0)' may be validly used in only two 17799 contexts: as the destination of an assignment (in test and 17800 compare instructions) and in comparison operators comparing 17801 against zero ('const_int' with value zero; that is to say, 17802 'const0_rtx'). 17803 17804 * To stand for a single flag that is the result of a single 17805 condition. This is useful on machines that have only a single 17806 flag bit, and in which comparison instructions must specify 17807 the condition to test. 17808 17809 With this technique, '(cc0)' may be validly used in only two 17810 contexts: as the destination of an assignment (in test and 17811 compare instructions) where the source is a comparison 17812 operator, and as the first operand of 'if_then_else' (in a 17813 conditional branch). 17814 17815 There is only one expression object of code 'cc0'; it is the value 17816 of the variable 'cc0_rtx'. Any attempt to create an expression of 17817 code 'cc0' will return 'cc0_rtx'. 17818 17819 Instructions can set the condition code implicitly. On many 17820 machines, nearly all instructions set the condition code based on 17821 the value that they compute or store. It is not necessary to 17822 record these actions explicitly in the RTL because the machine 17823 description includes a prescription for recognizing the 17824 instructions that do so (by means of the macro 'NOTICE_UPDATE_CC'). 17825 *Note Condition Code::. Only instructions whose sole purpose is to 17826 set the condition code, and instructions that use the condition 17827 code, need mention '(cc0)'. 17828 17829 On some machines, the condition code register is given a register 17830 number and a 'reg' is used instead of '(cc0)'. This is usually the 17831 preferable approach if only a small subset of instructions modify 17832 the condition code. Other machines store condition codes in 17833 general registers; in such cases a pseudo register should be used. 17834 17835 Some machines, such as the SPARC and RS/6000, have two sets of 17836 arithmetic instructions, one that sets and one that does not set 17837 the condition code. This is best handled by normally generating 17838 the instruction that does not set the condition code, and making a 17839 pattern that both performs the arithmetic and sets the condition 17840 code register (which would not be '(cc0)' in this case). For 17841 examples, search for 'addcc' and 'andcc' in 'sparc.md'. 17842 17843'(pc)' 17844 This represents the machine's program counter. It has no operands 17845 and may not have a machine mode. '(pc)' may be validly used only 17846 in certain specific contexts in jump instructions. 17847 17848 There is only one expression object of code 'pc'; it is the value 17849 of the variable 'pc_rtx'. Any attempt to create an expression of 17850 code 'pc' will return 'pc_rtx'. 17851 17852 All instructions that do not jump alter the program counter 17853 implicitly by incrementing it, but there is no need to mention this 17854 in the RTL. 17855 17856'(mem:M ADDR ALIAS)' 17857 This RTX represents a reference to main memory at an address 17858 represented by the expression ADDR. M specifies how large a unit 17859 of memory is accessed. ALIAS specifies an alias set for the 17860 reference. In general two items are in different alias sets if 17861 they cannot reference the same memory address. 17862 17863 The construct '(mem:BLK (scratch))' is considered to alias all 17864 other memories. Thus it may be used as a memory barrier in 17865 epilogue stack deallocation patterns. 17866 17867'(concatM RTX RTX)' 17868 This RTX represents the concatenation of two other RTXs. This is 17869 used for complex values. It should only appear in the RTL attached 17870 to declarations and during RTL generation. It should not appear in 17871 the ordinary insn chain. 17872 17873'(concatnM [RTX ...])' 17874 This RTX represents the concatenation of all the RTX to make a 17875 single value. Like 'concat', this should only appear in 17876 declarations, and not in the insn chain. 17877 17878 17879File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 17880 1788114.9 RTL Expressions for Arithmetic 17882=================================== 17883 17884Unless otherwise specified, all the operands of arithmetic expressions 17885must be valid for mode M. An operand is valid for mode M if it has mode 17886M, or if it is a 'const_int' or 'const_double' and M is a mode of class 17887'MODE_INT'. 17888 17889 For commutative binary operations, constants should be placed in the 17890second operand. 17891 17892'(plus:M X Y)' 17893'(ss_plus:M X Y)' 17894'(us_plus:M X Y)' 17895 17896 These three expressions all represent the sum of the values 17897 represented by X and Y carried out in machine mode M. They differ 17898 in their behavior on overflow of integer modes. 'plus' wraps round 17899 modulo the width of M; 'ss_plus' saturates at the maximum signed 17900 value representable in M; 'us_plus' saturates at the maximum 17901 unsigned value. 17902 17903'(lo_sum:M X Y)' 17904 17905 This expression represents the sum of X and the low-order bits of 17906 Y. It is used with 'high' (*note Constants::) to represent the 17907 typical two-instruction sequence used in RISC machines to reference 17908 large immediate values and/or link-time constants such as global 17909 memory addresses. In the latter case, M is 'Pmode' and Y is 17910 usually a constant expression involving 'symbol_ref'. 17911 17912 The number of low order bits is machine-dependent but is normally 17913 the number of bits in mode M minus the number of bits set by 17914 'high'. 17915 17916'(minus:M X Y)' 17917'(ss_minus:M X Y)' 17918'(us_minus:M X Y)' 17919 17920 These three expressions represent the result of subtracting Y from 17921 X, carried out in mode M. Behavior on overflow is the same as for 17922 the three variants of 'plus' (see above). 17923 17924'(compare:M X Y)' 17925 Represents the result of subtracting Y from X for purposes of 17926 comparison. The result is computed without overflow, as if with 17927 infinite precision. 17928 17929 Of course, machines cannot really subtract with infinite precision. 17930 However, they can pretend to do so when only the sign of the result 17931 will be used, which is the case when the result is stored in the 17932 condition code. And that is the _only_ way this kind of expression 17933 may validly be used: as a value to be stored in the condition 17934 codes, either '(cc0)' or a register. *Note Comparisons::. 17935 17936 The mode M is not related to the modes of X and Y, but instead is 17937 the mode of the condition code value. If '(cc0)' is used, it is 17938 'VOIDmode'. Otherwise it is some mode in class 'MODE_CC', often 17939 'CCmode'. *Note Condition Code::. If M is 'VOIDmode' or 'CCmode', 17940 the operation returns sufficient information (in an unspecified 17941 format) so that any comparison operator can be applied to the 17942 result of the 'COMPARE' operation. For other modes in class 17943 'MODE_CC', the operation only returns a subset of this information. 17944 17945 Normally, X and Y must have the same mode. Otherwise, 'compare' is 17946 valid only if the mode of X is in class 'MODE_INT' and Y is a 17947 'const_int' or 'const_double' with mode 'VOIDmode'. The mode of X 17948 determines what mode the comparison is to be done in; thus it must 17949 not be 'VOIDmode'. 17950 17951 If one of the operands is a constant, it should be placed in the 17952 second operand and the comparison code adjusted as appropriate. 17953 17954 A 'compare' specifying two 'VOIDmode' constants is not valid since 17955 there is no way to know in what mode the comparison is to be 17956 performed; the comparison must either be folded during the 17957 compilation or the first operand must be loaded into a register 17958 while its mode is still known. 17959 17960'(neg:M X)' 17961'(ss_neg:M X)' 17962'(us_neg:M X)' 17963 These two expressions represent the negation (subtraction from 17964 zero) of the value represented by X, carried out in mode M. They 17965 differ in the behavior on overflow of integer modes. In the case 17966 of 'neg', the negation of the operand may be a number not 17967 representable in mode M, in which case it is truncated to M. 17968 'ss_neg' and 'us_neg' ensure that an out-of-bounds result saturates 17969 to the maximum or minimum signed or unsigned value. 17970 17971'(mult:M X Y)' 17972'(ss_mult:M X Y)' 17973'(us_mult:M X Y)' 17974 Represents the signed product of the values represented by X and Y 17975 carried out in machine mode M. 'ss_mult' and 'us_mult' ensure that 17976 an out-of-bounds result saturates to the maximum or minimum signed 17977 or unsigned value. 17978 17979 Some machines support a multiplication that generates a product 17980 wider than the operands. Write the pattern for this as 17981 17982 (mult:M (sign_extend:M X) (sign_extend:M Y)) 17983 17984 where M is wider than the modes of X and Y, which need not be the 17985 same. 17986 17987 For unsigned widening multiplication, use the same idiom, but with 17988 'zero_extend' instead of 'sign_extend'. 17989 17990'(fma:M X Y Z)' 17991 Represents the 'fma', 'fmaf', and 'fmal' builtin functions, which 17992 compute 'X * Y + Z' without doing an intermediate rounding step. 17993 17994'(div:M X Y)' 17995'(ss_div:M X Y)' 17996 Represents the quotient in signed division of X by Y, carried out 17997 in machine mode M. If M is a floating point mode, it represents 17998 the exact quotient; otherwise, the integerized quotient. 'ss_div' 17999 ensures that an out-of-bounds result saturates to the maximum or 18000 minimum signed value. 18001 18002 Some machines have division instructions in which the operands and 18003 quotient widths are not all the same; you should represent such 18004 instructions using 'truncate' and 'sign_extend' as in, 18005 18006 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 18007 18008'(udiv:M X Y)' 18009'(us_div:M X Y)' 18010 Like 'div' but represents unsigned division. 'us_div' ensures that 18011 an out-of-bounds result saturates to the maximum or minimum 18012 unsigned value. 18013 18014'(mod:M X Y)' 18015'(umod:M X Y)' 18016 Like 'div' and 'udiv' but represent the remainder instead of the 18017 quotient. 18018 18019'(smin:M X Y)' 18020'(smax:M X Y)' 18021 Represents the smaller (for 'smin') or larger (for 'smax') of X and 18022 Y, interpreted as signed values in mode M. When used with floating 18023 point, if both operands are zeros, or if either operand is 'NaN', 18024 then it is unspecified which of the two operands is returned as the 18025 result. 18026 18027'(umin:M X Y)' 18028'(umax:M X Y)' 18029 Like 'smin' and 'smax', but the values are interpreted as unsigned 18030 integers. 18031 18032'(not:M X)' 18033 Represents the bitwise complement of the value represented by X, 18034 carried out in mode M, which must be a fixed-point machine mode. 18035 18036'(and:M X Y)' 18037 Represents the bitwise logical-and of the values represented by X 18038 and Y, carried out in machine mode M, which must be a fixed-point 18039 machine mode. 18040 18041'(ior:M X Y)' 18042 Represents the bitwise inclusive-or of the values represented by X 18043 and Y, carried out in machine mode M, which must be a fixed-point 18044 mode. 18045 18046'(xor:M X Y)' 18047 Represents the bitwise exclusive-or of the values represented by X 18048 and Y, carried out in machine mode M, which must be a fixed-point 18049 mode. 18050 18051'(ashift:M X C)' 18052'(ss_ashift:M X C)' 18053'(us_ashift:M X C)' 18054 These three expressions represent the result of arithmetically 18055 shifting X left by C places. They differ in their behavior on 18056 overflow of integer modes. An 'ashift' operation is a plain shift 18057 with no special behavior in case of a change in the sign bit; 18058 'ss_ashift' and 'us_ashift' saturates to the minimum or maximum 18059 representable value if any of the bits shifted out differs from the 18060 final sign bit. 18061 18062 X have mode M, a fixed-point machine mode. C be a fixed-point mode 18063 or be a constant with mode 'VOIDmode'; which mode is determined by 18064 the mode called for in the machine description entry for the 18065 left-shift instruction. For example, on the VAX, the mode of C is 18066 'QImode' regardless of M. 18067 18068'(lshiftrt:M X C)' 18069'(ashiftrt:M X C)' 18070 Like 'ashift' but for right shift. Unlike the case for left shift, 18071 these two operations are distinct. 18072 18073'(rotate:M X C)' 18074'(rotatert:M X C)' 18075 Similar but represent left and right rotate. If C is a constant, 18076 use 'rotate'. 18077 18078'(abs:M X)' 18079'(ss_abs:M X)' 18080 Represents the absolute value of X, computed in mode M. 'ss_abs' 18081 ensures that an out-of-bounds result saturates to the maximum 18082 signed value. 18083 18084'(sqrt:M X)' 18085 Represents the square root of X, computed in mode M. Most often M 18086 will be a floating point mode. 18087 18088'(ffs:M X)' 18089 Represents one plus the index of the least significant 1-bit in X, 18090 represented as an integer of mode M. (The value is zero if X is 18091 zero.) The mode of X must be M or 'VOIDmode'. 18092 18093'(clrsb:M X)' 18094 Represents the number of redundant leading sign bits in X, 18095 represented as an integer of mode M, starting at the most 18096 significant bit position. This is one less than the number of 18097 leading sign bits (either 0 or 1), with no special cases. The mode 18098 of X must be M or 'VOIDmode'. 18099 18100'(clz:M X)' 18101 Represents the number of leading 0-bits in X, represented as an 18102 integer of mode M, starting at the most significant bit position. 18103 If X is zero, the value is determined by 18104 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 18105 of the few expressions that is not invariant under widening. The 18106 mode of X must be M or 'VOIDmode'. 18107 18108'(ctz:M X)' 18109 Represents the number of trailing 0-bits in X, represented as an 18110 integer of mode M, starting at the least significant bit position. 18111 If X is zero, the value is determined by 18112 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 18113 'ctz(x)' is equivalent to 'ffs(X) - 1'. The mode of X must be M or 18114 'VOIDmode'. 18115 18116'(popcount:M X)' 18117 Represents the number of 1-bits in X, represented as an integer of 18118 mode M. The mode of X must be M or 'VOIDmode'. 18119 18120'(parity:M X)' 18121 Represents the number of 1-bits modulo 2 in X, represented as an 18122 integer of mode M. The mode of X must be M or 'VOIDmode'. 18123 18124'(bswap:M X)' 18125 Represents the value X with the order of bytes reversed, carried 18126 out in mode M, which must be a fixed-point machine mode. The mode 18127 of X must be M or 'VOIDmode'. 18128 18129 18130File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 18131 1813214.10 Comparison Operations 18133=========================== 18134 18135Comparison operators test a relation on two operands and are considered 18136to represent a machine-dependent nonzero value described by, but not 18137necessarily equal to, 'STORE_FLAG_VALUE' (*note Misc::) if the relation 18138holds, or zero if it does not, for comparison operators whose results 18139have a 'MODE_INT' mode, 'FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 18140relation holds, or zero if it does not, for comparison operators that 18141return floating-point values, and a vector of either 18142'VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 18143zeros if it does not, for comparison operators that return vector 18144results. The mode of the comparison operation is independent of the 18145mode of the data being compared. If the comparison operation is being 18146tested (e.g., the first operand of an 'if_then_else'), the mode must be 18147'VOIDmode'. 18148 18149 There are two ways that comparison operations may be used. The 18150comparison operators may be used to compare the condition codes '(cc0)' 18151against zero, as in '(eq (cc0) (const_int 0))'. Such a construct 18152actually refers to the result of the preceding instruction in which the 18153condition codes were set. The instruction setting the condition code 18154must be adjacent to the instruction using the condition code; only 18155'note' insns may separate them. 18156 18157 Alternatively, a comparison operation may directly compare two data 18158objects. The mode of the comparison is determined by the operands; they 18159must both be valid for a common machine mode. A comparison with both 18160operands constant would be invalid as the machine mode could not be 18161deduced from it, but such a comparison should never exist in RTL due to 18162constant folding. 18163 18164 In the example above, if '(cc0)' were last set to '(compare X Y)', the 18165comparison operation is identical to '(eq X Y)'. Usually only one style 18166of comparisons is supported on a particular machine, but the combine 18167pass will try to merge the operations to produce the 'eq' shown in case 18168it exists in the context of the particular insn involved. 18169 18170 Inequality comparisons come in two flavors, signed and unsigned. Thus, 18171there are distinct expression codes 'gt' and 'gtu' for signed and 18172unsigned greater-than. These can produce different results for the same 18173pair of integer values: for example, 1 is signed greater-than -1 but not 18174unsigned greater-than, because -1 when regarded as unsigned is actually 18175'0xffffffff' which is greater than 1. 18176 18177 The signed comparisons are also used for floating point values. 18178Floating point comparisons are distinguished by the machine modes of the 18179operands. 18180 18181'(eq:M X Y)' 18182 'STORE_FLAG_VALUE' if the values represented by X and Y are equal, 18183 otherwise 0. 18184 18185'(ne:M X Y)' 18186 'STORE_FLAG_VALUE' if the values represented by X and Y are not 18187 equal, otherwise 0. 18188 18189'(gt:M X Y)' 18190 'STORE_FLAG_VALUE' if the X is greater than Y. If they are 18191 fixed-point, the comparison is done in a signed sense. 18192 18193'(gtu:M X Y)' 18194 Like 'gt' but does unsigned comparison, on fixed-point numbers 18195 only. 18196 18197'(lt:M X Y)' 18198'(ltu:M X Y)' 18199 Like 'gt' and 'gtu' but test for "less than". 18200 18201'(ge:M X Y)' 18202'(geu:M X Y)' 18203 Like 'gt' and 'gtu' but test for "greater than or equal". 18204 18205'(le:M X Y)' 18206'(leu:M X Y)' 18207 Like 'gt' and 'gtu' but test for "less than or equal". 18208 18209'(if_then_else COND THEN ELSE)' 18210 This is not a comparison operation but is listed here because it is 18211 always used in conjunction with a comparison operation. To be 18212 precise, COND is a comparison expression. This expression 18213 represents a choice, according to COND, between the value 18214 represented by THEN and the one represented by ELSE. 18215 18216 On most machines, 'if_then_else' expressions are valid only to 18217 express conditional jumps. 18218 18219'(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 18220 Similar to 'if_then_else', but more general. Each of TEST1, TEST2, 18221 ... is performed in turn. The result of this expression is the 18222 VALUE corresponding to the first nonzero test, or DEFAULT if none 18223 of the tests are nonzero expressions. 18224 18225 This is currently not valid for instruction patterns and is 18226 supported only for insn attributes. *Note Insn Attributes::. 18227 18228 18229File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 18230 1823114.11 Bit-Fields 18232================ 18233 18234Special expression codes exist to represent bit-field instructions. 18235 18236'(sign_extract:M LOC SIZE POS)' 18237 This represents a reference to a sign-extended bit-field contained 18238 or starting in LOC (a memory or register reference). The bit-field 18239 is SIZE bits wide and starts at bit POS. The compilation option 18240 'BITS_BIG_ENDIAN' says which end of the memory unit POS counts 18241 from. 18242 18243 If LOC is in memory, its mode must be a single-byte integer mode. 18244 If LOC is in a register, the mode to use is specified by the 18245 operand of the 'insv' or 'extv' pattern (*note Standard Names::) 18246 and is usually a full-word integer mode, which is the default if 18247 none is specified. 18248 18249 The mode of POS is machine-specific and is also specified in the 18250 'insv' or 'extv' pattern. 18251 18252 The mode M is the same as the mode that would be used for LOC if it 18253 were a register. 18254 18255 A 'sign_extract' cannot appear as an lvalue, or part thereof, in 18256 RTL. 18257 18258'(zero_extract:M LOC SIZE POS)' 18259 Like 'sign_extract' but refers to an unsigned or zero-extended 18260 bit-field. The same sequence of bits are extracted, but they are 18261 filled to an entire word with zeros instead of by sign-extension. 18262 18263 Unlike 'sign_extract', this type of expressions can be lvalues in 18264 RTL; they may appear on the left side of an assignment, indicating 18265 insertion of a value into the specified bit-field. 18266 18267 18268File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 18269 1827014.12 Vector Operations 18271======================= 18272 18273All normal RTL expressions can be used with vector modes; they are 18274interpreted as operating on each part of the vector independently. 18275Additionally, there are a few new expressions to describe specific 18276vector operations. 18277 18278'(vec_merge:M VEC1 VEC2 ITEMS)' 18279 This describes a merge operation between two vectors. The result 18280 is a vector of mode M; its elements are selected from either VEC1 18281 or VEC2. Which elements are selected is described by ITEMS, which 18282 is a bit mask represented by a 'const_int'; a zero bit indicates 18283 the corresponding element in the result vector is taken from VEC2 18284 while a set bit indicates it is taken from VEC1. 18285 18286'(vec_select:M VEC1 SELECTION)' 18287 This describes an operation that selects parts of a vector. VEC1 18288 is the source vector, and SELECTION is a 'parallel' that contains a 18289 'const_int' (or another expression, if the selection can be made at 18290 runtime) for each of the subparts of the result vector, giving the 18291 number of the source subpart that should be stored into it. The 18292 result mode M is either the submode for a single element of VEC1 18293 (if only one subpart is selected), or another vector mode with that 18294 element submode (if multiple subparts are selected). 18295 18296'(vec_concat:M X1 X2)' 18297 Describes a vector concat operation. The result is a concatenation 18298 of the vectors or scalars X1 and X2; its length is the sum of the 18299 lengths of the two inputs. 18300 18301'(vec_duplicate:M X)' 18302 This operation converts a scalar into a vector or a small vector 18303 into a larger one by duplicating the input values. The output 18304 vector mode must have the same submodes as the input vector mode or 18305 the scalar modes, and the number of output parts must be an integer 18306 multiple of the number of input parts. 18307 18308'(vec_series:M BASE STEP)' 18309 This operation creates a vector in which element I is equal to 18310 'BASE + I*STEP'. M must be a vector integer mode. 18311 18312 18313File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 18314 1831514.13 Conversions 18316================= 18317 18318All conversions between machine modes must be represented by explicit 18319conversion operations. For example, an expression which is the sum of a 18320byte and a full word cannot be written as '(plus:SI (reg:QI 34) (reg:SI 1832180))' because the 'plus' operation requires two operands of the same 18322machine mode. Therefore, the byte-sized operand is enclosed in a 18323conversion operation, as in 18324 18325 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 18326 18327 The conversion operation is not a mere placeholder, because there may 18328be more than one way of converting from a given starting mode to the 18329desired final mode. The conversion operation code says how to do it. 18330 18331 For all conversion operations, X must not be 'VOIDmode' because the 18332mode in which to do the conversion would not be known. The conversion 18333must either be done at compile-time or X must be placed into a register. 18334 18335'(sign_extend:M X)' 18336 Represents the result of sign-extending the value X to machine mode 18337 M. M must be a fixed-point mode and X a fixed-point value of a 18338 mode narrower than M. 18339 18340'(zero_extend:M X)' 18341 Represents the result of zero-extending the value X to machine mode 18342 M. M must be a fixed-point mode and X a fixed-point value of a 18343 mode narrower than M. 18344 18345'(float_extend:M X)' 18346 Represents the result of extending the value X to machine mode M. 18347 M must be a floating point mode and X a floating point value of a 18348 mode narrower than M. 18349 18350'(truncate:M X)' 18351 Represents the result of truncating the value X to machine mode M. 18352 M must be a fixed-point mode and X a fixed-point value of a mode 18353 wider than M. 18354 18355'(ss_truncate:M X)' 18356 Represents the result of truncating the value X to machine mode M, 18357 using signed saturation in the case of overflow. Both M and the 18358 mode of X must be fixed-point modes. 18359 18360'(us_truncate:M X)' 18361 Represents the result of truncating the value X to machine mode M, 18362 using unsigned saturation in the case of overflow. Both M and the 18363 mode of X must be fixed-point modes. 18364 18365'(float_truncate:M X)' 18366 Represents the result of truncating the value X to machine mode M. 18367 M must be a floating point mode and X a floating point value of a 18368 mode wider than M. 18369 18370'(float:M X)' 18371 Represents the result of converting fixed point value X, regarded 18372 as signed, to floating point mode M. 18373 18374'(unsigned_float:M X)' 18375 Represents the result of converting fixed point value X, regarded 18376 as unsigned, to floating point mode M. 18377 18378'(fix:M X)' 18379 When M is a floating-point mode, represents the result of 18380 converting floating point value X (valid for mode M) to an integer, 18381 still represented in floating point mode M, by rounding towards 18382 zero. 18383 18384 When M is a fixed-point mode, represents the result of converting 18385 floating point value X to mode M, regarded as signed. How rounding 18386 is done is not specified, so this operation may be used validly in 18387 compiling C code only for integer-valued operands. 18388 18389'(unsigned_fix:M X)' 18390 Represents the result of converting floating point value X to fixed 18391 point mode M, regarded as unsigned. How rounding is done is not 18392 specified. 18393 18394'(fract_convert:M X)' 18395 Represents the result of converting fixed-point value X to 18396 fixed-point mode M, signed integer value X to fixed-point mode M, 18397 floating-point value X to fixed-point mode M, fixed-point value X 18398 to integer mode M regarded as signed, or fixed-point value X to 18399 floating-point mode M. When overflows or underflows happen, the 18400 results are undefined. 18401 18402'(sat_fract:M X)' 18403 Represents the result of converting fixed-point value X to 18404 fixed-point mode M, signed integer value X to fixed-point mode M, 18405 or floating-point value X to fixed-point mode M. When overflows or 18406 underflows happen, the results are saturated to the maximum or the 18407 minimum. 18408 18409'(unsigned_fract_convert:M X)' 18410 Represents the result of converting fixed-point value X to integer 18411 mode M regarded as unsigned, or unsigned integer value X to 18412 fixed-point mode M. When overflows or underflows happen, the 18413 results are undefined. 18414 18415'(unsigned_sat_fract:M X)' 18416 Represents the result of converting unsigned integer value X to 18417 fixed-point mode M. When overflows or underflows happen, the 18418 results are saturated to the maximum or the minimum. 18419 18420 18421File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 18422 1842314.14 Declarations 18424================== 18425 18426Declaration expression codes do not represent arithmetic operations but 18427rather state assertions about their operands. 18428 18429'(strict_low_part (subreg:M (reg:N R) 0))' 18430 This expression code is used in only one context: as the 18431 destination operand of a 'set' expression. In addition, the 18432 operand of this expression must be a non-paradoxical 'subreg' 18433 expression. 18434 18435 The presence of 'strict_low_part' says that the part of the 18436 register which is meaningful in mode N, but is not part of mode M, 18437 is not to be altered. Normally, an assignment to such a subreg is 18438 allowed to have undefined effects on the rest of the register when 18439 M is smaller than 'REGMODE_NATURAL_SIZE (N)'. 18440 18441 18442File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 18443 1844414.15 Side Effect Expressions 18445============================= 18446 18447The expression codes described so far represent values, not actions. 18448But machine instructions never produce values; they are meaningful only 18449for their side effects on the state of the machine. Special expression 18450codes are used to represent side effects. 18451 18452 The body of an instruction is always one of these side effect codes; 18453the codes described above, which represent values, appear only as the 18454operands of these. 18455 18456'(set LVAL X)' 18457 Represents the action of storing the value of X into the place 18458 represented by LVAL. LVAL must be an expression representing a 18459 place that can be stored in: 'reg' (or 'subreg', 'strict_low_part' 18460 or 'zero_extract'), 'mem', 'pc', 'parallel', or 'cc0'. 18461 18462 If LVAL is a 'reg', 'subreg' or 'mem', it has a machine mode; then 18463 X must be valid for that mode. 18464 18465 If LVAL is a 'reg' whose machine mode is less than the full width 18466 of the register, then it means that the part of the register 18467 specified by the machine mode is given the specified value and the 18468 rest of the register receives an undefined value. Likewise, if 18469 LVAL is a 'subreg' whose machine mode is narrower than the mode of 18470 the register, the rest of the register can be changed in an 18471 undefined way. 18472 18473 If LVAL is a 'strict_low_part' of a subreg, then the part of the 18474 register specified by the machine mode of the 'subreg' is given the 18475 value X and the rest of the register is not changed. 18476 18477 If LVAL is a 'zero_extract', then the referenced part of the 18478 bit-field (a memory or register reference) specified by the 18479 'zero_extract' is given the value X and the rest of the bit-field 18480 is not changed. Note that 'sign_extract' cannot appear in LVAL. 18481 18482 If LVAL is '(cc0)', it has no machine mode, and X may be either a 18483 'compare' expression or a value that may have any mode. The latter 18484 case represents a "test" instruction. The expression '(set (cc0) 18485 (reg:M N))' is equivalent to '(set (cc0) (compare (reg:M N) 18486 (const_int 0)))'. Use the former expression to save space during 18487 the compilation. 18488 18489 If LVAL is a 'parallel', it is used to represent the case of a 18490 function returning a structure in multiple registers. Each element 18491 of the 'parallel' is an 'expr_list' whose first operand is a 'reg' 18492 and whose second operand is a 'const_int' representing the offset 18493 (in bytes) into the structure at which the data in that register 18494 corresponds. The first element may be null to indicate that the 18495 structure is also passed partly in memory. 18496 18497 If LVAL is '(pc)', we have a jump instruction, and the 18498 possibilities for X are very limited. It may be a 'label_ref' 18499 expression (unconditional jump). It may be an 'if_then_else' 18500 (conditional jump), in which case either the second or the third 18501 operand must be '(pc)' (for the case which does not jump) and the 18502 other of the two must be a 'label_ref' (for the case which does 18503 jump). X may also be a 'mem' or '(plus:SI (pc) Y)', where Y may be 18504 a 'reg' or a 'mem'; these unusual patterns are used to represent 18505 jumps through branch tables. 18506 18507 If LVAL is neither '(cc0)' nor '(pc)', the mode of LVAL must not be 18508 'VOIDmode' and the mode of X must be valid for the mode of LVAL. 18509 18510 LVAL is customarily accessed with the 'SET_DEST' macro and X with 18511 the 'SET_SRC' macro. 18512 18513'(return)' 18514 As the sole expression in a pattern, represents a return from the 18515 current function, on machines where this can be done with one 18516 instruction, such as VAXen. On machines where a multi-instruction 18517 "epilogue" must be executed in order to return from the function, 18518 returning is done by jumping to a label which precedes the 18519 epilogue, and the 'return' expression code is never used. 18520 18521 Inside an 'if_then_else' expression, represents the value to be 18522 placed in 'pc' to return to the caller. 18523 18524 Note that an insn pattern of '(return)' is logically equivalent to 18525 '(set (pc) (return))', but the latter form is never used. 18526 18527'(simple_return)' 18528 Like '(return)', but truly represents only a function return, while 18529 '(return)' may represent an insn that also performs other functions 18530 of the function epilogue. Like '(return)', this may also occur in 18531 conditional jumps. 18532 18533'(call FUNCTION NARGS)' 18534 Represents a function call. FUNCTION is a 'mem' expression whose 18535 address is the address of the function to be called. NARGS is an 18536 expression which can be used for two purposes: on some machines it 18537 represents the number of bytes of stack argument; on others, it 18538 represents the number of argument registers. 18539 18540 Each machine has a standard machine mode which FUNCTION must have. 18541 The machine description defines macro 'FUNCTION_MODE' to expand 18542 into the requisite mode name. The purpose of this mode is to 18543 specify what kind of addressing is allowed, on machines where the 18544 allowed kinds of addressing depend on the machine mode being 18545 addressed. 18546 18547'(clobber X)' 18548 Represents the storing or possible storing of an unpredictable, 18549 undescribed value into X, which must be a 'reg', 'scratch', 18550 'parallel' or 'mem' expression. 18551 18552 One place this is used is in string instructions that store 18553 standard values into particular hard registers. It may not be 18554 worth the trouble to describe the values that are stored, but it is 18555 essential to inform the compiler that the registers will be 18556 altered, lest it attempt to keep data in them across the string 18557 instruction. 18558 18559 If X is '(mem:BLK (const_int 0))' or '(mem:BLK (scratch))', it 18560 means that all memory locations must be presumed clobbered. If X 18561 is a 'parallel', it has the same meaning as a 'parallel' in a 'set' 18562 expression. 18563 18564 Note that the machine description classifies certain hard registers 18565 as "call-clobbered". All function call instructions are assumed by 18566 default to clobber these registers, so there is no need to use 18567 'clobber' expressions to indicate this fact. Also, each function 18568 call is assumed to have the potential to alter any memory location, 18569 unless the function is declared 'const'. 18570 18571 If the last group of expressions in a 'parallel' are each a 18572 'clobber' expression whose arguments are 'reg' or 'match_scratch' 18573 (*note RTL Template::) expressions, the combiner phase can add the 18574 appropriate 'clobber' expressions to an insn it has constructed 18575 when doing so will cause a pattern to be matched. 18576 18577 This feature can be used, for example, on a machine that whose 18578 multiply and add instructions don't use an MQ register but which 18579 has an add-accumulate instruction that does clobber the MQ 18580 register. Similarly, a combined instruction might require a 18581 temporary register while the constituent instructions might not. 18582 18583 When a 'clobber' expression for a register appears inside a 18584 'parallel' with other side effects, the register allocator 18585 guarantees that the register is unoccupied both before and after 18586 that insn if it is a hard register clobber. For pseudo-register 18587 clobber, the register allocator and the reload pass do not assign 18588 the same hard register to the clobber and the input operands if 18589 there is an insn alternative containing the '&' constraint (*note 18590 Modifiers::) for the clobber and the hard register is in register 18591 classes of the clobber in the alternative. You can clobber either 18592 a specific hard register, a pseudo register, or a 'scratch' 18593 expression; in the latter two cases, GCC will allocate a hard 18594 register that is available there for use as a temporary. 18595 18596 For instructions that require a temporary register, you should use 18597 'scratch' instead of a pseudo-register because this will allow the 18598 combiner phase to add the 'clobber' when required. You do this by 18599 coding ('clobber' ('match_scratch' ...)). If you do clobber a 18600 pseudo register, use one which appears nowhere else--generate a new 18601 one each time. Otherwise, you may confuse CSE. 18602 18603 There is one other known use for clobbering a pseudo register in a 18604 'parallel': when one of the input operands of the insn is also 18605 clobbered by the insn. In this case, using the same pseudo 18606 register in the clobber and elsewhere in the insn produces the 18607 expected results. 18608 18609'(use X)' 18610 Represents the use of the value of X. It indicates that the value 18611 in X at this point in the program is needed, even though it may not 18612 be apparent why this is so. Therefore, the compiler will not 18613 attempt to delete previous instructions whose only effect is to 18614 store a value in X. X must be a 'reg' expression. 18615 18616 In some situations, it may be tempting to add a 'use' of a register 18617 in a 'parallel' to describe a situation where the value of a 18618 special register will modify the behavior of the instruction. A 18619 hypothetical example might be a pattern for an addition that can 18620 either wrap around or use saturating addition depending on the 18621 value of a special control register: 18622 18623 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 18624 (reg:SI 4)] 0)) 18625 (use (reg:SI 1))]) 18626 18627 18628 This will not work, several of the optimizers only look at 18629 expressions locally; it is very likely that if you have multiple 18630 insns with identical inputs to the 'unspec', they will be optimized 18631 away even if register 1 changes in between. 18632 18633 This means that 'use' can _only_ be used to describe that the 18634 register is live. You should think twice before adding 'use' 18635 statements, more often you will want to use 'unspec' instead. The 18636 'use' RTX is most commonly useful to describe that a fixed register 18637 is implicitly used in an insn. It is also safe to use in patterns 18638 where the compiler knows for other reasons that the result of the 18639 whole pattern is variable, such as 'cpymemM' or 'call' patterns. 18640 18641 During the reload phase, an insn that has a 'use' as pattern can 18642 carry a reg_equal note. These 'use' insns will be deleted before 18643 the reload phase exits. 18644 18645 During the delayed branch scheduling phase, X may be an insn. This 18646 indicates that X previously was located at this place in the code 18647 and its data dependencies need to be taken into account. These 18648 'use' insns will be deleted before the delayed branch scheduling 18649 phase exits. 18650 18651'(parallel [X0 X1 ...])' 18652 Represents several side effects performed in parallel. The square 18653 brackets stand for a vector; the operand of 'parallel' is a vector 18654 of expressions. X0, X1 and so on are individual side effect 18655 expressions--expressions of code 'set', 'call', 'return', 18656 'simple_return', 'clobber' or 'use'. 18657 18658 "In parallel" means that first all the values used in the 18659 individual side-effects are computed, and second all the actual 18660 side-effects are performed. For example, 18661 18662 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 18663 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 18664 18665 says unambiguously that the values of hard register 1 and the 18666 memory location addressed by it are interchanged. In both places 18667 where '(reg:SI 1)' appears as a memory address it refers to the 18668 value in register 1 _before_ the execution of the insn. 18669 18670 It follows that it is _incorrect_ to use 'parallel' and expect the 18671 result of one 'set' to be available for the next one. For example, 18672 people sometimes attempt to represent a jump-if-zero instruction 18673 this way: 18674 18675 (parallel [(set (cc0) (reg:SI 34)) 18676 (set (pc) (if_then_else 18677 (eq (cc0) (const_int 0)) 18678 (label_ref ...) 18679 (pc)))]) 18680 18681 But this is incorrect, because it says that the jump condition 18682 depends on the condition code value _before_ this instruction, not 18683 on the new value that is set by this instruction. 18684 18685 Peephole optimization, which takes place together with final 18686 assembly code output, can produce insns whose patterns consist of a 18687 'parallel' whose elements are the operands needed to output the 18688 resulting assembler code--often 'reg', 'mem' or constant 18689 expressions. This would not be well-formed RTL at any other stage 18690 in compilation, but it is OK then because no further optimization 18691 remains to be done. However, the definition of the macro 18692 'NOTICE_UPDATE_CC', if any, must deal with such insns if you define 18693 any peephole optimizations. 18694 18695'(cond_exec [COND EXPR])' 18696 Represents a conditionally executed expression. The EXPR is 18697 executed only if the COND is nonzero. The COND expression must not 18698 have side-effects, but the EXPR may very well have side-effects. 18699 18700'(sequence [INSNS ...])' 18701 Represents a sequence of insns. If a 'sequence' appears in the 18702 chain of insns, then each of the INSNS that appears in the sequence 18703 must be suitable for appearing in the chain of insns, i.e. must 18704 satisfy the 'INSN_P' predicate. 18705 18706 After delay-slot scheduling is completed, an insn and all the insns 18707 that reside in its delay slots are grouped together into a 18708 'sequence'. The insn requiring the delay slot is the first insn in 18709 the vector; subsequent insns are to be placed in the delay slot. 18710 18711 'INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 18712 indicate that a branch insn should be used that will conditionally 18713 annul the effect of the insns in the delay slots. In such a case, 18714 'INSN_FROM_TARGET_P' indicates that the insn is from the target of 18715 the branch and should be executed only if the branch is taken; 18716 otherwise the insn should be executed only if the branch is not 18717 taken. *Note Delay Slots::. 18718 18719 Some back ends also use 'sequence' objects for purposes other than 18720 delay-slot groups. This is not supported in the common parts of 18721 the compiler, which treat such sequences as delay-slot groups. 18722 18723 DWARF2 Call Frame Address (CFA) adjustments are sometimes also 18724 expressed using 'sequence' objects as the value of a 18725 'RTX_FRAME_RELATED_P' note. This only happens if the CFA 18726 adjustments cannot be easily derived from the pattern of the 18727 instruction to which the note is attached. In such cases, the 18728 value of the note is used instead of best-guesing the semantics of 18729 the instruction. The back end can attach notes containing a 18730 'sequence' of 'set' patterns that express the effect of the parent 18731 instruction. 18732 18733 These expression codes appear in place of a side effect, as the body of 18734an insn, though strictly speaking they do not always describe side 18735effects as such: 18736 18737'(asm_input S)' 18738 Represents literal assembler code as described by the string S. 18739 18740'(unspec [OPERANDS ...] INDEX)' 18741'(unspec_volatile [OPERANDS ...] INDEX)' 18742 Represents a machine-specific operation on OPERANDS. INDEX selects 18743 between multiple machine-specific operations. 'unspec_volatile' is 18744 used for volatile operations and operations that may trap; 'unspec' 18745 is used for other operations. 18746 18747 These codes may appear inside a 'pattern' of an insn, inside a 18748 'parallel', or inside an expression. 18749 18750'(addr_vec:M [LR0 LR1 ...])' 18751 Represents a table of jump addresses. The vector elements LR0, 18752 etc., are 'label_ref' expressions. The mode M specifies how much 18753 space is given to each address; normally M would be 'Pmode'. 18754 18755'(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 18756 Represents a table of jump addresses expressed as offsets from 18757 BASE. The vector elements LR0, etc., are 'label_ref' expressions 18758 and so is BASE. The mode M specifies how much space is given to 18759 each address-difference. MIN and MAX are set up by branch 18760 shortening and hold a label with a minimum and a maximum address, 18761 respectively. FLAGS indicates the relative position of BASE, MIN 18762 and MAX to the containing insn and of MIN and MAX to BASE. See 18763 rtl.def for details. 18764 18765'(prefetch:M ADDR RW LOCALITY)' 18766 Represents prefetch of memory at address ADDR. Operand RW is 1 if 18767 the prefetch is for data to be written, 0 otherwise; targets that 18768 do not support write prefetches should treat this as a normal 18769 prefetch. Operand LOCALITY specifies the amount of temporal 18770 locality; 0 if there is none or 1, 2, or 3 for increasing levels of 18771 temporal locality; targets that do not support locality hints 18772 should ignore this. 18773 18774 This insn is used to minimize cache-miss latency by moving data 18775 into a cache before it is accessed. It should use only 18776 non-faulting data prefetch instructions. 18777 18778 18779File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 18780 1878114.16 Embedded Side-Effects on Addresses 18782======================================== 18783 18784Six special side-effect expression codes appear as memory addresses. 18785 18786'(pre_dec:M X)' 18787 Represents the side effect of decrementing X by a standard amount 18788 and represents also the value that X has after being decremented. 18789 X must be a 'reg' or 'mem', but most machines allow only a 'reg'. 18790 M must be the machine mode for pointers on the machine in use. The 18791 amount X is decremented by is the length in bytes of the machine 18792 mode of the containing memory reference of which this expression 18793 serves as the address. Here is an example of its use: 18794 18795 (mem:DF (pre_dec:SI (reg:SI 39))) 18796 18797 This says to decrement pseudo register 39 by the length of a 18798 'DFmode' value and use the result to address a 'DFmode' value. 18799 18800'(pre_inc:M X)' 18801 Similar, but specifies incrementing X instead of decrementing it. 18802 18803'(post_dec:M X)' 18804 Represents the same side effect as 'pre_dec' but a different value. 18805 The value represented here is the value X has before being 18806 decremented. 18807 18808'(post_inc:M X)' 18809 Similar, but specifies incrementing X instead of decrementing it. 18810 18811'(post_modify:M X Y)' 18812 18813 Represents the side effect of setting X to Y and represents X 18814 before X is modified. X must be a 'reg' or 'mem', but most 18815 machines allow only a 'reg'. M must be the machine mode for 18816 pointers on the machine in use. 18817 18818 The expression Y must be one of three forms: '(plus:M X Z)', 18819 '(minus:M X Z)', or '(plus:M X I)', where Z is an index register 18820 and I is a constant. 18821 18822 Here is an example of its use: 18823 18824 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 18825 (reg:SI 48)))) 18826 18827 This says to modify pseudo register 42 by adding the contents of 18828 pseudo register 48 to it, after the use of what ever 42 points to. 18829 18830'(pre_modify:M X EXPR)' 18831 Similar except side effects happen before the use. 18832 18833 These embedded side effect expressions must be used with care. 18834Instruction patterns may not use them. Until the 'flow' pass of the 18835compiler, they may occur only to represent pushes onto the stack. The 18836'flow' pass finds cases where registers are incremented or decremented 18837in one instruction and used as an address shortly before or after; these 18838cases are then transformed to use pre- or post-increment or -decrement. 18839 18840 If a register used as the operand of these expressions is used in 18841another address in an insn, the original value of the register is used. 18842Uses of the register outside of an address are not permitted within the 18843same insn as a use in an embedded side effect expression because such 18844insns behave differently on different machines and hence must be treated 18845as ambiguous and disallowed. 18846 18847 An instruction that can be represented with an embedded side effect 18848could also be represented using 'parallel' containing an additional 18849'set' to describe how the address register is altered. This is not done 18850because machines that allow these operations at all typically allow them 18851wherever a memory address is called for. Describing them as additional 18852parallel stores would require doubling the number of entries in the 18853machine description. 18854 18855 18856File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 18857 1885814.17 Assembler Instructions as Expressions 18859=========================================== 18860 18861The RTX code 'asm_operands' represents a value produced by a 18862user-specified assembler instruction. It is used to represent an 'asm' 18863statement with arguments. An 'asm' statement with a single output 18864operand, like this: 18865 18866 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 18867 18868is represented using a single 'asm_operands' RTX which represents the 18869value that is stored in 'outputvar': 18870 18871 (set RTX-FOR-OUTPUTVAR 18872 (asm_operands "foo %1,%2,%0" "a" 0 18873 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 18874 [(asm_input:M1 "g") 18875 (asm_input:M2 "di")])) 18876 18877Here the operands of the 'asm_operands' RTX are the assembler template 18878string, the output-operand's constraint, the index-number of the output 18879operand among the output operands specified, a vector of input operand 18880RTX's, and a vector of input-operand modes and constraints. The mode M1 18881is the mode of the sum 'x+y'; M2 is that of '*z'. 18882 18883 When an 'asm' statement has multiple output values, its insn has 18884several such 'set' RTX's inside of a 'parallel'. Each 'set' contains an 18885'asm_operands'; all of these share the same assembler template and 18886vectors, but each contains the constraint for the respective output 18887operand. They are also distinguished by the output-operand index 18888number, which is 0, 1, ... for successive output operands. 18889 18890 18891File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 18892 1889314.18 Variable Location Debug Information in RTL 18894================================================ 18895 18896Variable tracking relies on 'MEM_EXPR' and 'REG_EXPR' annotations to 18897determine what user variables memory and register references refer to. 18898 18899 Variable tracking at assignments uses these notes only when they refer 18900to variables that live at fixed locations (e.g., addressable variables, 18901global non-automatic variables). For variables whose location may vary, 18902it relies on the following types of notes. 18903 18904'(var_location:MODE VAR EXP STAT)' 18905 Binds variable 'var', a tree, to value EXP, an RTL expression. It 18906 appears only in 'NOTE_INSN_VAR_LOCATION' and 'DEBUG_INSN's, with 18907 slightly different meanings. MODE, if present, represents the mode 18908 of EXP, which is useful if it is a modeless expression. STAT is 18909 only meaningful in notes, indicating whether the variable is known 18910 to be initialized or uninitialized. 18911 18912'(debug_expr:MODE DECL)' 18913 Stands for the value bound to the 'DEBUG_EXPR_DECL' DECL, that 18914 points back to it, within value expressions in 'VAR_LOCATION' 18915 nodes. 18916 18917'(debug_implicit_ptr:MODE DECL)' 18918 Stands for the location of a DECL that is no longer addressable. 18919 18920'(entry_value:MODE DECL)' 18921 Stands for the value a DECL had at the entry point of the 18922 containing function. 18923 18924'(debug_parameter_ref:MODE DECL)' 18925 Refers to a parameter that was completely optimized out. 18926 18927'(debug_marker:MODE)' 18928 Marks a program location. With 'VOIDmode', it stands for the 18929 beginning of a statement, a recommended inspection point logically 18930 after all prior side effects, and before any subsequent side 18931 effects. With 'BLKmode', it indicates an inline entry point: the 18932 lexical block encoded in the 'INSN_LOCATION' is the enclosing block 18933 that encloses the inlined function. 18934 18935 18936File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 18937 1893814.19 Insns 18939=========== 18940 18941The RTL representation of the code for a function is a doubly-linked 18942chain of objects called "insns". Insns are expressions with special 18943codes that are used for no other purpose. Some insns are actual 18944instructions; others represent dispatch tables for 'switch' statements; 18945others represent labels to jump to or various sorts of declarative 18946information. 18947 18948 In addition to its own specific data, each insn must have a unique 18949id-number that distinguishes it from all other insns in the current 18950function (after delayed branch scheduling, copies of an insn with the 18951same id-number may be present in multiple places in a function, but 18952these copies will always be identical and will only appear inside a 18953'sequence'), and chain pointers to the preceding and following insns. 18954These three fields occupy the same position in every insn, independent 18955of the expression code of the insn. They could be accessed with 'XEXP' 18956and 'XINT', but instead three special macros are always used: 18957 18958'INSN_UID (I)' 18959 Accesses the unique id of insn I. 18960 18961'PREV_INSN (I)' 18962 Accesses the chain pointer to the insn preceding I. If I is the 18963 first insn, this is a null pointer. 18964 18965'NEXT_INSN (I)' 18966 Accesses the chain pointer to the insn following I. If I is the 18967 last insn, this is a null pointer. 18968 18969 The first insn in the chain is obtained by calling 'get_insns'; the 18970last insn is the result of calling 'get_last_insn'. Within the chain 18971delimited by these insns, the 'NEXT_INSN' and 'PREV_INSN' pointers must 18972always correspond: if INSN is not the first insn, 18973 18974 NEXT_INSN (PREV_INSN (INSN)) == INSN 18975 18976is always true and if INSN is not the last insn, 18977 18978 PREV_INSN (NEXT_INSN (INSN)) == INSN 18979 18980is always true. 18981 18982 After delay slot scheduling, some of the insns in the chain might be 18983'sequence' expressions, which contain a vector of insns. The value of 18984'NEXT_INSN' in all but the last of these insns is the next insn in the 18985vector; the value of 'NEXT_INSN' of the last insn in the vector is the 18986same as the value of 'NEXT_INSN' for the 'sequence' in which it is 18987contained. Similar rules apply for 'PREV_INSN'. 18988 18989 This means that the above invariants are not necessarily true for insns 18990inside 'sequence' expressions. Specifically, if INSN is the first insn 18991in a 'sequence', 'NEXT_INSN (PREV_INSN (INSN))' is the insn containing 18992the 'sequence' expression, as is the value of 'PREV_INSN (NEXT_INSN 18993(INSN))' if INSN is the last insn in the 'sequence' expression. You can 18994use these expressions to find the containing 'sequence' expression. 18995 18996 Every insn has one of the following expression codes: 18997 18998'insn' 18999 The expression code 'insn' is used for instructions that do not 19000 jump and do not do function calls. 'sequence' expressions are 19001 always contained in insns with code 'insn' even if one of those 19002 insns should jump or do function calls. 19003 19004 Insns with code 'insn' have four additional fields beyond the three 19005 mandatory ones listed above. These four are described in a table 19006 below. 19007 19008'jump_insn' 19009 The expression code 'jump_insn' is used for instructions that may 19010 jump (or, more generally, may contain 'label_ref' expressions to 19011 which 'pc' can be set in that instruction). If there is an 19012 instruction to return from the current function, it is recorded as 19013 a 'jump_insn'. 19014 19015 'jump_insn' insns have the same extra fields as 'insn' insns, 19016 accessed in the same way and in addition contain a field 19017 'JUMP_LABEL' which is defined once jump optimization has completed. 19018 19019 For simple conditional and unconditional jumps, this field contains 19020 the 'code_label' to which this insn will (possibly conditionally) 19021 branch. In a more complex jump, 'JUMP_LABEL' records one of the 19022 labels that the insn refers to; other jump target labels are 19023 recorded as 'REG_LABEL_TARGET' notes. The exception is 'addr_vec' 19024 and 'addr_diff_vec', where 'JUMP_LABEL' is 'NULL_RTX' and the only 19025 way to find the labels is to scan the entire body of the insn. 19026 19027 Return insns count as jumps, but their 'JUMP_LABEL' is 'RETURN' or 19028 'SIMPLE_RETURN'. 19029 19030'call_insn' 19031 The expression code 'call_insn' is used for instructions that may 19032 do function calls. It is important to distinguish these 19033 instructions because they imply that certain registers and memory 19034 locations may be altered unpredictably. 19035 19036 'call_insn' insns have the same extra fields as 'insn' insns, 19037 accessed in the same way and in addition contain a field 19038 'CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 19039 'expr_list' expressions) containing 'use', 'clobber' and sometimes 19040 'set' expressions that denote hard registers and 'mem's used or 19041 clobbered by the called function. 19042 19043 A 'mem' generally points to a stack slot in which arguments passed 19044 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 19045 Register Arguments.) are stored. If the argument is caller-copied 19046 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 19047 will be mentioned in 'clobber' and 'use' entries; if it's 19048 callee-copied, only a 'use' will appear, and the 'mem' may point to 19049 addresses that are not stack slots. 19050 19051 Registers occurring inside a 'clobber' in this list augment 19052 registers specified in 'CALL_USED_REGISTERS' (*note Register 19053 Basics::). 19054 19055 If the list contains a 'set' involving two registers, it indicates 19056 that the function returns one of its arguments. Such a 'set' may 19057 look like a no-op if the same register holds the argument and the 19058 return value. 19059 19060'code_label' 19061 A 'code_label' insn represents a label that a jump insn can jump 19062 to. It contains two special fields of data in addition to the 19063 three standard ones. 'CODE_LABEL_NUMBER' is used to hold the 19064 "label number", a number that identifies this label uniquely among 19065 all the labels in the compilation (not just in the current 19066 function). Ultimately, the label is represented in the assembler 19067 output as an assembler label, usually of the form 'LN' where N is 19068 the label number. 19069 19070 When a 'code_label' appears in an RTL expression, it normally 19071 appears within a 'label_ref' which represents the address of the 19072 label, as a number. 19073 19074 Besides as a 'code_label', a label can also be represented as a 19075 'note' of type 'NOTE_INSN_DELETED_LABEL'. 19076 19077 The field 'LABEL_NUSES' is only defined once the jump optimization 19078 phase is completed. It contains the number of times this label is 19079 referenced in the current function. 19080 19081 The field 'LABEL_KIND' differentiates four different types of 19082 labels: 'LABEL_NORMAL', 'LABEL_STATIC_ENTRY', 'LABEL_GLOBAL_ENTRY', 19083 and 'LABEL_WEAK_ENTRY'. The only labels that do not have type 19084 'LABEL_NORMAL' are "alternate entry points" to the current 19085 function. These may be static (visible only in the containing 19086 translation unit), global (exposed to all translation units), or 19087 weak (global, but can be overridden by another symbol with the same 19088 name). 19089 19090 Much of the compiler treats all four kinds of label identically. 19091 Some of it needs to know whether or not a label is an alternate 19092 entry point; for this purpose, the macro 'LABEL_ALT_ENTRY_P' is 19093 provided. It is equivalent to testing whether 'LABEL_KIND (label) 19094 == LABEL_NORMAL'. The only place that cares about the distinction 19095 between static, global, and weak alternate entry points, besides 19096 the front-end code that creates them, is the function 19097 'output_alternate_entry_point', in 'final.c'. 19098 19099 To set the kind of a label, use the 'SET_LABEL_KIND' macro. 19100 19101'jump_table_data' 19102 A 'jump_table_data' insn is a placeholder for the jump-table data 19103 of a 'casesi' or 'tablejump' insn. They are placed after a 19104 'tablejump_p' insn. A 'jump_table_data' insn is not part o a basic 19105 blockm but it is associated with the basic block that ends with the 19106 'tablejump_p' insn. The 'PATTERN' of a 'jump_table_data' is always 19107 either an 'addr_vec' or an 'addr_diff_vec', and a 'jump_table_data' 19108 insn is always preceded by a 'code_label'. The 'tablejump_p' insn 19109 refers to that 'code_label' via its 'JUMP_LABEL'. 19110 19111'barrier' 19112 Barriers are placed in the instruction stream when control cannot 19113 flow past them. They are placed after unconditional jump 19114 instructions to indicate that the jumps are unconditional and after 19115 calls to 'volatile' functions, which do not return (e.g., 'exit'). 19116 They contain no information beyond the three standard fields. 19117 19118'note' 19119 'note' insns are used to represent additional debugging and 19120 declarative information. They contain two nonstandard fields, an 19121 integer which is accessed with the macro 'NOTE_LINE_NUMBER' and a 19122 string accessed with 'NOTE_SOURCE_FILE'. 19123 19124 If 'NOTE_LINE_NUMBER' is positive, the note represents the position 19125 of a source line and 'NOTE_SOURCE_FILE' is the source file name 19126 that the line came from. These notes control generation of line 19127 number data in the assembler output. 19128 19129 Otherwise, 'NOTE_LINE_NUMBER' is not really a line number but a 19130 code with one of the following values (and 'NOTE_SOURCE_FILE' must 19131 contain a null pointer): 19132 19133 'NOTE_INSN_DELETED' 19134 Such a note is completely ignorable. Some passes of the 19135 compiler delete insns by altering them into notes of this 19136 kind. 19137 19138 'NOTE_INSN_DELETED_LABEL' 19139 This marks what used to be a 'code_label', but was not used 19140 for other purposes than taking its address and was transformed 19141 to mark that no code jumps to it. 19142 19143 'NOTE_INSN_BLOCK_BEG' 19144 'NOTE_INSN_BLOCK_END' 19145 These types of notes indicate the position of the beginning 19146 and end of a level of scoping of variable names. They control 19147 the output of debugging information. 19148 19149 'NOTE_INSN_EH_REGION_BEG' 19150 'NOTE_INSN_EH_REGION_END' 19151 These types of notes indicate the position of the beginning 19152 and end of a level of scoping for exception handling. 19153 'NOTE_EH_HANDLER' identifies which region is associated with 19154 these notes. 19155 19156 'NOTE_INSN_FUNCTION_BEG' 19157 Appears at the start of the function body, after the function 19158 prologue. 19159 19160 'NOTE_INSN_VAR_LOCATION' 19161 This note is used to generate variable location debugging 19162 information. It indicates that the user variable in its 19163 'VAR_LOCATION' operand is at the location given in the RTL 19164 expression, or holds a value that can be computed by 19165 evaluating the RTL expression from that static point in the 19166 program up to the next such note for the same user variable. 19167 19168 'NOTE_INSN_BEGIN_STMT' 19169 This note is used to generate 'is_stmt' markers in line number 19170 debuggign information. It indicates the beginning of a user 19171 statement. 19172 19173 'NOTE_INSN_INLINE_ENTRY' 19174 This note is used to generate 'entry_pc' for inlined 19175 subroutines in debugging information. It indicates an 19176 inspection point at which all arguments for the inlined 19177 function have been bound, and before its first statement. 19178 19179 These codes are printed symbolically when they appear in debugging 19180 dumps. 19181 19182'debug_insn' 19183 The expression code 'debug_insn' is used for pseudo-instructions 19184 that hold debugging information for variable tracking at 19185 assignments (see '-fvar-tracking-assignments' option). They are 19186 the RTL representation of 'GIMPLE_DEBUG' statements (*note 19187 GIMPLE_DEBUG::), with a 'VAR_LOCATION' operand that binds a user 19188 variable tree to an RTL representation of the 'value' in the 19189 corresponding statement. A 'DEBUG_EXPR' in it stands for the value 19190 bound to the corresponding 'DEBUG_EXPR_DECL'. 19191 19192 'GIMPLE_DEBUG_BEGIN_STMT' and 'GIMPLE_DEBUG_INLINE_ENTRY' are 19193 expanded to RTL as a 'DEBUG_INSN' with a 'DEBUG_MARKER' 'PATTERN'; 19194 the difference is the RTL mode: the former's 'DEBUG_MARKER' is 19195 'VOIDmode', whereas the latter is 'BLKmode'; information about the 19196 inlined function can be taken from the lexical block encoded in the 19197 'INSN_LOCATION'. These 'DEBUG_INSN's, that do not carry 19198 'VAR_LOCATION' information, just 'DEBUG_MARKER's, can be detected 19199 by testing 'DEBUG_MARKER_INSN_P', whereas those that do can be 19200 recognized as 'DEBUG_BIND_INSN_P'. 19201 19202 Throughout optimization passes, 'DEBUG_INSN's are not reordered 19203 with respect to each other, particularly during scheduling. 19204 Binding information is kept in pseudo-instruction form, so that, 19205 unlike notes, it gets the same treatment and adjustments that 19206 regular instructions would. It is the variable tracking pass that 19207 turns these pseudo-instructions into 'NOTE_INSN_VAR_LOCATION', 19208 'NOTE_INSN_BEGIN_STMT' and 'NOTE_INSN_INLINE_ENTRY' notes, 19209 analyzing control flow, value equivalences and changes to registers 19210 and memory referenced in value expressions, propagating the values 19211 of debug temporaries and determining expressions that can be used 19212 to compute the value of each user variable at as many points 19213 (ranges, actually) in the program as possible. 19214 19215 Unlike 'NOTE_INSN_VAR_LOCATION', the value expression in an 19216 'INSN_VAR_LOCATION' denotes a value at that specific point in the 19217 program, rather than an expression that can be evaluated at any 19218 later point before an overriding 'VAR_LOCATION' is encountered. 19219 E.g., if a user variable is bound to a 'REG' and then a subsequent 19220 insn modifies the 'REG', the note location would keep mapping the 19221 user variable to the register across the insn, whereas the insn 19222 location would keep the variable bound to the value, so that the 19223 variable tracking pass would emit another location note for the 19224 variable at the point in which the register is modified. 19225 19226 The machine mode of an insn is normally 'VOIDmode', but some phases use 19227the mode for various purposes. 19228 19229 The common subexpression elimination pass sets the mode of an insn to 19230'QImode' when it is the first insn in a block that has already been 19231processed. 19232 19233 The second Haifa scheduling pass, for targets that can multiple issue, 19234sets the mode of an insn to 'TImode' when it is believed that the 19235instruction begins an issue group. That is, when the instruction cannot 19236issue simultaneously with the previous. This may be relied on by later 19237passes, in particular machine-dependent reorg. 19238 19239 Here is a table of the extra fields of 'insn', 'jump_insn' and 19240'call_insn' insns: 19241 19242'PATTERN (I)' 19243 An expression for the side effect performed by this insn. This 19244 must be one of the following codes: 'set', 'call', 'use', 19245 'clobber', 'return', 'simple_return', 'asm_input', 'asm_output', 19246 'addr_vec', 'addr_diff_vec', 'trap_if', 'unspec', 19247 'unspec_volatile', 'parallel', 'cond_exec', or 'sequence'. If it 19248 is a 'parallel', each element of the 'parallel' must be one these 19249 codes, except that 'parallel' expressions cannot be nested and 19250 'addr_vec' and 'addr_diff_vec' are not permitted inside a 19251 'parallel' expression. 19252 19253'INSN_CODE (I)' 19254 An integer that says which pattern in the machine description 19255 matches this insn, or -1 if the matching has not yet been 19256 attempted. 19257 19258 Such matching is never attempted and this field remains -1 on an 19259 insn whose pattern consists of a single 'use', 'clobber', 19260 'asm_input', 'addr_vec' or 'addr_diff_vec' expression. 19261 19262 Matching is also never attempted on insns that result from an 'asm' 19263 statement. These contain at least one 'asm_operands' expression. 19264 The function 'asm_noperands' returns a non-negative value for such 19265 insns. 19266 19267 In the debugging output, this field is printed as a number followed 19268 by a symbolic representation that locates the pattern in the 'md' 19269 file as some small positive or negative offset from a named 19270 pattern. 19271 19272'LOG_LINKS (I)' 19273 A list (chain of 'insn_list' expressions) giving information about 19274 dependencies between instructions within a basic block. Neither a 19275 jump nor a label may come between the related insns. These are 19276 only used by the schedulers and by combine. This is a deprecated 19277 data structure. Def-use and use-def chains are now preferred. 19278 19279'REG_NOTES (I)' 19280 A list (chain of 'expr_list', 'insn_list' and 'int_list' 19281 expressions) giving miscellaneous information about the insn. It 19282 is often information pertaining to the registers used in this insn. 19283 19284 The 'LOG_LINKS' field of an insn is a chain of 'insn_list' expressions. 19285Each of these has two operands: the first is an insn, and the second is 19286another 'insn_list' expression (the next one in the chain). The last 19287'insn_list' in the chain has a null pointer as second operand. The 19288significant thing about the chain is which insns appear in it (as first 19289operands of 'insn_list' expressions). Their order is not significant. 19290 19291 This list is originally set up by the flow analysis pass; it is a null 19292pointer until then. Flow only adds links for those data dependencies 19293which can be used for instruction combination. For each insn, the flow 19294analysis pass adds a link to insns which store into registers values 19295that are used for the first time in this insn. 19296 19297 The 'REG_NOTES' field of an insn is a chain similar to the 'LOG_LINKS' 19298field but it includes 'expr_list' and 'int_list' expressions in addition 19299to 'insn_list' expressions. There are several kinds of register notes, 19300which are distinguished by the machine mode, which in a register note is 19301really understood as being an 'enum reg_note'. The first operand OP of 19302the note is data whose meaning depends on the kind of note. 19303 19304 The macro 'REG_NOTE_KIND (X)' returns the kind of register note. Its 19305counterpart, the macro 'PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 19306register note type of X to be NEWKIND. 19307 19308 Register notes are of three classes: They may say something about an 19309input to an insn, they may say something about an output of an insn, or 19310they may create a linkage between two insns. There are also a set of 19311values that are only used in 'LOG_LINKS'. 19312 19313 These register notes annotate inputs to an insn: 19314 19315'REG_DEAD' 19316 The value in OP dies in this insn; that is to say, altering the 19317 value immediately after this insn would not affect the future 19318 behavior of the program. 19319 19320 It does not follow that the register OP has no useful value after 19321 this insn since OP is not necessarily modified by this insn. 19322 Rather, no subsequent instruction uses the contents of OP. 19323 19324'REG_UNUSED' 19325 The register OP being set by this insn will not be used in a 19326 subsequent insn. This differs from a 'REG_DEAD' note, which 19327 indicates that the value in an input will not be used subsequently. 19328 These two notes are independent; both may be present for the same 19329 register. 19330 19331'REG_INC' 19332 The register OP is incremented (or decremented; at this level there 19333 is no distinction) by an embedded side effect inside this insn. 19334 This means it appears in a 'post_inc', 'pre_inc', 'post_dec' or 19335 'pre_dec' expression. 19336 19337'REG_NONNEG' 19338 The register OP is known to have a nonnegative value when this insn 19339 is reached. This is used by special looping instructions that 19340 terminate when the register goes negative. 19341 19342 The 'REG_NONNEG' note is added only to 'doloop_end' insns, if its 19343 pattern uses a 'ge' condition. 19344 19345'REG_LABEL_OPERAND' 19346 This insn uses OP, a 'code_label' or a 'note' of type 19347 'NOTE_INSN_DELETED_LABEL', but is not a 'jump_insn', or it is a 19348 'jump_insn' that refers to the operand as an ordinary operand. The 19349 label may still eventually be a jump target, but if so in an 19350 indirect jump in a subsequent insn. The presence of this note 19351 allows jump optimization to be aware that OP is, in fact, being 19352 used, and flow optimization to build an accurate flow graph. 19353 19354'REG_LABEL_TARGET' 19355 This insn is a 'jump_insn' but not an 'addr_vec' or 19356 'addr_diff_vec'. It uses OP, a 'code_label' as a direct or 19357 indirect jump target. Its purpose is similar to that of 19358 'REG_LABEL_OPERAND'. This note is only present if the insn has 19359 multiple targets; the last label in the insn (in the highest 19360 numbered insn-field) goes into the 'JUMP_LABEL' field and does not 19361 have a 'REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 19362 19363'REG_SETJMP' 19364 Appears attached to each 'CALL_INSN' to 'setjmp' or a related 19365 function. 19366 19367 The following notes describe attributes of outputs of an insn: 19368 19369'REG_EQUIV' 19370'REG_EQUAL' 19371 This note is only valid on an insn that sets only one register and 19372 indicates that that register will be equal to OP at run time; the 19373 scope of this equivalence differs between the two types of notes. 19374 The value which the insn explicitly copies into the register may 19375 look different from OP, but they will be equal at run time. If the 19376 output of the single 'set' is a 'strict_low_part' or 'zero_extract' 19377 expression, the note refers to the register that is contained in 19378 its first operand. 19379 19380 For 'REG_EQUIV', the register is equivalent to OP throughout the 19381 entire function, and could validly be replaced in all its 19382 occurrences by OP. ("Validly" here refers to the data flow of the 19383 program; simple replacement may make some insns invalid.) For 19384 example, when a constant is loaded into a register that is never 19385 assigned any other value, this kind of note is used. 19386 19387 When a parameter is copied into a pseudo-register at entry to a 19388 function, a note of this kind records that the register is 19389 equivalent to the stack slot where the parameter was passed. 19390 Although in this case the register may be set by other insns, it is 19391 still valid to replace the register by the stack slot throughout 19392 the function. 19393 19394 A 'REG_EQUIV' note is also used on an instruction which copies a 19395 register parameter into a pseudo-register at entry to a function, 19396 if there is a stack slot where that parameter could be stored. 19397 Although other insns may set the pseudo-register, it is valid for 19398 the compiler to replace the pseudo-register by stack slot 19399 throughout the function, provided the compiler ensures that the 19400 stack slot is properly initialized by making the replacement in the 19401 initial copy instruction as well. This is used on machines for 19402 which the calling convention allocates stack space for register 19403 parameters. See 'REG_PARM_STACK_SPACE' in *note Stack Arguments::. 19404 19405 In the case of 'REG_EQUAL', the register that is set by this insn 19406 will be equal to OP at run time at the end of this insn but not 19407 necessarily elsewhere in the function. In this case, OP is 19408 typically an arithmetic expression. For example, when a sequence 19409 of insns such as a library call is used to perform an arithmetic 19410 operation, this kind of note is attached to the insn that produces 19411 or copies the final value. 19412 19413 These two notes are used in different ways by the compiler passes. 19414 'REG_EQUAL' is used by passes prior to register allocation (such as 19415 common subexpression elimination and loop optimization) to tell 19416 them how to think of that value. 'REG_EQUIV' notes are used by 19417 register allocation to indicate that there is an available 19418 substitute expression (either a constant or a 'mem' expression for 19419 the location of a parameter on the stack) that may be used in place 19420 of a register if insufficient registers are available. 19421 19422 Except for stack homes for parameters, which are indicated by a 19423 'REG_EQUIV' note and are not useful to the early optimization 19424 passes and pseudo registers that are equivalent to a memory 19425 location throughout their entire life, which is not detected until 19426 later in the compilation, all equivalences are initially indicated 19427 by an attached 'REG_EQUAL' note. In the early stages of register 19428 allocation, a 'REG_EQUAL' note is changed into a 'REG_EQUIV' note 19429 if OP is a constant and the insn represents the only set of its 19430 destination register. 19431 19432 Thus, compiler passes prior to register allocation need only check 19433 for 'REG_EQUAL' notes and passes subsequent to register allocation 19434 need only check for 'REG_EQUIV' notes. 19435 19436 These notes describe linkages between insns. They occur in pairs: one 19437insn has one of a pair of notes that points to a second insn, which has 19438the inverse note pointing back to the first insn. 19439 19440'REG_CC_SETTER' 19441'REG_CC_USER' 19442 On machines that use 'cc0', the insns which set and use 'cc0' set 19443 and use 'cc0' are adjacent. However, when branch delay slot 19444 filling is done, this may no longer be true. In this case a 19445 'REG_CC_USER' note will be placed on the insn setting 'cc0' to 19446 point to the insn using 'cc0' and a 'REG_CC_SETTER' note will be 19447 placed on the insn using 'cc0' to point to the insn setting 'cc0'. 19448 19449 These values are only used in the 'LOG_LINKS' field, and indicate the 19450type of dependency that each link represents. Links which indicate a 19451data dependence (a read after write dependence) do not use any code, 19452they simply have mode 'VOIDmode', and are printed without any 19453descriptive text. 19454 19455'REG_DEP_TRUE' 19456 This indicates a true dependence (a read after write dependence). 19457 19458'REG_DEP_OUTPUT' 19459 This indicates an output dependence (a write after write 19460 dependence). 19461 19462'REG_DEP_ANTI' 19463 This indicates an anti dependence (a write after read dependence). 19464 19465 These notes describe information gathered from gcov profile data. They 19466are stored in the 'REG_NOTES' field of an insn. 19467 19468'REG_BR_PROB' 19469 This is used to specify the ratio of branches to non-branches of a 19470 branch insn according to the profile data. The note is represented 19471 as an 'int_list' expression whose integer value is an encoding of 19472 'profile_probability' type. 'profile_probability' provide member 19473 function 'from_reg_br_prob_note' and 'to_reg_br_prob_note' to 19474 extract and store the probability into the RTL encoding. 19475 19476'REG_BR_PRED' 19477 These notes are found in JUMP insns after delayed branch scheduling 19478 has taken place. They indicate both the direction and the 19479 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 19480 values. 19481 19482'REG_FRAME_RELATED_EXPR' 19483 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 19484 expression is used in place of the actual insn pattern. This is 19485 done in cases where the pattern is either complex or misleading. 19486 19487 The note 'REG_CALL_NOCF_CHECK' is used in conjunction with the 19488'-fcf-protection=branch' option. The note is set if a 'nocf_check' 19489attribute is specified for a function type or a pointer to function 19490type. The note is stored in the 'REG_NOTES' field of an insn. 19491 19492'REG_CALL_NOCF_CHECK' 19493 Users have control through the 'nocf_check' attribute to identify 19494 which calls to a function should be skipped from control-flow 19495 instrumentation when the option '-fcf-protection=branch' is 19496 specified. The compiler puts a 'REG_CALL_NOCF_CHECK' note on each 19497 'CALL_INSN' instruction that has a function type marked with a 19498 'nocf_check' attribute. 19499 19500 For convenience, the machine mode in an 'insn_list' or 'expr_list' is 19501printed using these symbolic codes in debugging dumps. 19502 19503 The only difference between the expression codes 'insn_list' and 19504'expr_list' is that the first operand of an 'insn_list' is assumed to be 19505an insn and is printed in debugging dumps as the insn's unique id; the 19506first operand of an 'expr_list' is printed in the ordinary way as an 19507expression. 19508 19509 19510File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 19511 1951214.20 RTL Representation of Function-Call Insns 19513=============================================== 19514 19515Insns that call subroutines have the RTL expression code 'call_insn'. 19516These insns must satisfy special rules, and their bodies must use a 19517special RTL expression code, 'call'. 19518 19519 A 'call' expression has two operands, as follows: 19520 19521 (call (mem:FM ADDR) NBYTES) 19522 19523Here NBYTES is an operand that represents the number of bytes of 19524argument data being passed to the subroutine, FM is a machine mode 19525(which must equal as the definition of the 'FUNCTION_MODE' macro in the 19526machine description) and ADDR represents the address of the subroutine. 19527 19528 For a subroutine that returns no value, the 'call' expression as shown 19529above is the entire body of the insn, except that the insn might also 19530contain 'use' or 'clobber' expressions. 19531 19532 For a subroutine that returns a value whose mode is not 'BLKmode', the 19533value is returned in a hard register. If this register's number is R, 19534then the body of the call insn looks like this: 19535 19536 (set (reg:M R) 19537 (call (mem:FM ADDR) NBYTES)) 19538 19539This RTL expression makes it clear (to the optimizer passes) that the 19540appropriate register receives a useful value in this insn. 19541 19542 When a subroutine returns a 'BLKmode' value, it is handled by passing 19543to the subroutine the address of a place to store the value. So the 19544call insn itself does not "return" any value, and it has the same RTL 19545form as a call that returns nothing. 19546 19547 On some machines, the call instruction itself clobbers some register, 19548for example to contain the return address. 'call_insn' insns on these 19549machines should have a body which is a 'parallel' that contains both the 19550'call' expression and 'clobber' expressions that indicate which 19551registers are destroyed. Similarly, if the call instruction requires 19552some register other than the stack pointer that is not explicitly 19553mentioned in its RTL, a 'use' subexpression should mention that 19554register. 19555 19556 Functions that are called are assumed to modify all registers listed in 19557the configuration macro 'CALL_USED_REGISTERS' (*note Register Basics::) 19558and, with the exception of 'const' functions and library calls, to 19559modify all of memory. 19560 19561 Insns containing just 'use' expressions directly precede the 19562'call_insn' insn to indicate which registers contain inputs to the 19563function. Similarly, if registers other than those in 19564'CALL_USED_REGISTERS' are clobbered by the called function, insns 19565containing a single 'clobber' follow immediately after the call to 19566indicate which registers. 19567 19568 19569File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 19570 1957114.21 Structure Sharing Assumptions 19572=================================== 19573 19574The compiler assumes that certain kinds of RTL expressions are unique; 19575there do not exist two distinct objects representing the same value. In 19576other cases, it makes an opposite assumption: that no RTL expression 19577object of a certain kind appears in more than one place in the 19578containing structure. 19579 19580 These assumptions refer to a single function; except for the RTL 19581objects that describe global variables and external functions, and a few 19582standard objects such as small integer constants, no RTL objects are 19583common to two functions. 19584 19585 * Each pseudo-register has only a single 'reg' object to represent 19586 it, and therefore only a single machine mode. 19587 19588 * For any symbolic label, there is only one 'symbol_ref' object 19589 referring to it. 19590 19591 * All 'const_int' expressions with equal values are shared. 19592 19593 * All 'const_poly_int' expressions with equal modes and values are 19594 shared. 19595 19596 * There is only one 'pc' expression. 19597 19598 * There is only one 'cc0' expression. 19599 19600 * There is only one 'const_double' expression with value 0 for each 19601 floating point mode. Likewise for values 1 and 2. 19602 19603 * There is only one 'const_vector' expression with value 0 for each 19604 vector mode, be it an integer or a double constant vector. 19605 19606 * No 'label_ref' or 'scratch' appears in more than one place in the 19607 RTL structure; in other words, it is safe to do a tree-walk of all 19608 the insns in the function and assume that each time a 'label_ref' 19609 or 'scratch' is seen it is distinct from all others that are seen. 19610 19611 * Only one 'mem' object is normally created for each static variable 19612 or stack slot, so these objects are frequently shared in all the 19613 places they appear. However, separate but equal objects for these 19614 variables are occasionally made. 19615 19616 * When a single 'asm' statement has multiple output operands, a 19617 distinct 'asm_operands' expression is made for each output operand. 19618 However, these all share the vector which contains the sequence of 19619 input operands. This sharing is used later on to test whether two 19620 'asm_operands' expressions come from the same statement, so all 19621 optimizations must carefully preserve the sharing if they copy the 19622 vector at all. 19623 19624 * No RTL object appears in more than one place in the RTL structure 19625 except as described above. Many passes of the compiler rely on 19626 this by assuming that they can modify RTL objects in place without 19627 unwanted side-effects on other insns. 19628 19629 * During initial RTL generation, shared structure is freely 19630 introduced. After all the RTL for a function has been generated, 19631 all shared structure is copied by 'unshare_all_rtl' in 19632 'emit-rtl.c', after which the above rules are guaranteed to be 19633 followed. 19634 19635 * During the combiner pass, shared structure within an insn can exist 19636 temporarily. However, the shared structure is copied before the 19637 combiner is finished with the insn. This is done by calling 19638 'copy_rtx_if_shared', which is a subroutine of 'unshare_all_rtl'. 19639 19640 19641File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 19642 1964314.22 Reading RTL 19644================= 19645 19646To read an RTL object from a file, call 'read_rtx'. It takes one 19647argument, a stdio stream, and returns a single RTL object. This routine 19648is defined in 'read-rtl.c'. It is not available in the compiler itself, 19649only the various programs that generate the compiler back end from the 19650machine description. 19651 19652 People frequently have the idea of using RTL stored as text in a file 19653as an interface between a language front end and the bulk of GCC. This 19654idea is not feasible. 19655 19656 GCC was designed to use RTL internally only. Correct RTL for a given 19657program is very dependent on the particular target machine. And the RTL 19658does not contain all the information about the program. 19659 19660 The proper way to interface GCC to a new language front end is with the 19661"tree" data structure, described in the files 'tree.h' and 'tree.def'. 19662The documentation for this structure (*note GENERIC::) is incomplete. 19663 19664 19665File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 19666 1966715 Control Flow Graph 19668********************* 19669 19670A control flow graph (CFG) is a data structure built on top of the 19671intermediate code representation (the RTL or 'GIMPLE' instruction 19672stream) abstracting the control flow behavior of a function that is 19673being compiled. The CFG is a directed graph where the vertices 19674represent basic blocks and edges represent possible transfer of control 19675flow from one basic block to another. The data structures used to 19676represent the control flow graph are defined in 'basic-block.h'. 19677 19678 In GCC, the representation of control flow is maintained throughout the 19679compilation process, from constructing the CFG early in 'pass_build_cfg' 19680to 'pass_free_cfg' (see 'passes.def'). The CFG takes various different 19681modes and may undergo extensive manipulations, but the graph is always 19682valid between its construction and its release. This way, transfer of 19683information such as data flow, a measured profile, or the loop tree, can 19684be propagated through the passes pipeline, and even from 'GIMPLE' to 19685'RTL'. 19686 19687 Often the CFG may be better viewed as integral part of instruction 19688chain, than structure built on the top of it. Updating the compiler's 19689intermediate representation for instructions cannot be easily done 19690without proper maintenance of the CFG simultaneously. 19691 19692* Menu: 19693 19694* Basic Blocks:: The definition and representation of basic blocks. 19695* Edges:: Types of edges and their representation. 19696* Profile information:: Representation of frequencies and probabilities. 19697* Maintaining the CFG:: Keeping the control flow graph and up to date. 19698* Liveness information:: Using and maintaining liveness information. 19699 19700 19701File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 19702 1970315.1 Basic Blocks 19704================= 19705 19706A basic block is a straight-line sequence of code with only one entry 19707point and only one exit. In GCC, basic blocks are represented using the 19708'basic_block' data type. 19709 19710 Special basic blocks represent possible entry and exit points of a 19711function. These blocks are called 'ENTRY_BLOCK_PTR' and 19712'EXIT_BLOCK_PTR'. These blocks do not contain any code. 19713 19714 The 'BASIC_BLOCK' array contains all basic blocks in an unspecified 19715order. Each 'basic_block' structure has a field that holds a unique 19716integer identifier 'index' that is the index of the block in the 19717'BASIC_BLOCK' array. The total number of basic blocks in the function 19718is 'n_basic_blocks'. Both the basic block indices and the total number 19719of basic blocks may vary during the compilation process, as passes 19720reorder, create, duplicate, and destroy basic blocks. The index for any 19721block should never be greater than 'last_basic_block'. The indices 0 19722and 1 are special codes reserved for 'ENTRY_BLOCK' and 'EXIT_BLOCK', the 19723indices of 'ENTRY_BLOCK_PTR' and 'EXIT_BLOCK_PTR'. 19724 19725 Two pointer members of the 'basic_block' structure are the pointers 19726'next_bb' and 'prev_bb'. These are used to keep doubly linked chain of 19727basic blocks in the same order as the underlying instruction stream. 19728The chain of basic blocks is updated transparently by the provided API 19729for manipulating the CFG. The macro 'FOR_EACH_BB' can be used to visit 19730all the basic blocks in lexicographical order, except 'ENTRY_BLOCK' and 19731'EXIT_BLOCK'. The macro 'FOR_ALL_BB' also visits all basic blocks in 19732lexicographical order, including 'ENTRY_BLOCK' and 'EXIT_BLOCK'. 19733 19734 The functions 'post_order_compute' and 'inverted_post_order_compute' 19735can be used to compute topological orders of the CFG. The orders are 19736stored as vectors of basic block indices. The 'BASIC_BLOCK' array can 19737be used to iterate each basic block by index. Dominator traversals are 19738also possible using 'walk_dominator_tree'. Given two basic blocks A and 19739B, block A dominates block B if A is _always_ executed before B. 19740 19741 Each 'basic_block' also contains pointers to the first instruction (the 19742"head") and the last instruction (the "tail") or "end" of the 19743instruction stream contained in a basic block. In fact, since the 19744'basic_block' data type is used to represent blocks in both major 19745intermediate representations of GCC ('GIMPLE' and RTL), there are 19746pointers to the head and end of a basic block for both representations, 19747stored in intermediate representation specific data in the 'il' field of 19748'struct basic_block_def'. 19749 19750 For RTL, these pointers are 'BB_HEAD' and 'BB_END'. 19751 19752 In the RTL representation of a function, the instruction stream 19753contains not only the "real" instructions, but also "notes" or "insn 19754notes" (to distinguish them from "reg notes"). Any function that moves 19755or duplicates the basic blocks needs to take care of updating of these 19756notes. Many of these notes expect that the instruction stream consists 19757of linear regions, so updating can sometimes be tedious. All types of 19758insn notes are defined in 'insn-notes.def'. 19759 19760 In the RTL function representation, the instructions contained in a 19761basic block always follow a 'NOTE_INSN_BASIC_BLOCK', but zero or more 19762'CODE_LABEL' nodes can precede the block note. A basic block ends with 19763a control flow instruction or with the last instruction before the next 19764'CODE_LABEL' or 'NOTE_INSN_BASIC_BLOCK'. By definition, a 'CODE_LABEL' 19765cannot appear in the middle of the instruction stream of a basic block. 19766 19767 In addition to notes, the jump table vectors are also represented as 19768"pseudo-instructions" inside the insn stream. These vectors never 19769appear in the basic block and should always be placed just after the 19770table jump instructions referencing them. After removing the table-jump 19771it is often difficult to eliminate the code computing the address and 19772referencing the vector, so cleaning up these vectors is postponed until 19773after liveness analysis. Thus the jump table vectors may appear in the 19774insn stream unreferenced and without any purpose. Before any edge is 19775made "fall-thru", the existence of such construct in the way needs to be 19776checked by calling 'can_fallthru' function. 19777 19778 For the 'GIMPLE' representation, the PHI nodes and statements contained 19779in a basic block are in a 'gimple_seq' pointed to by the basic block 19780intermediate language specific pointers. Abstract containers and 19781iterators are used to access the PHI nodes and statements in a basic 19782blocks. These iterators are called "GIMPLE statement iterators" (GSIs). 19783Grep for '^gsi' in the various 'gimple-*' and 'tree-*' files. There is 19784a 'gimple_stmt_iterator' type for iterating over all kinds of statement, 19785and a 'gphi_iterator' subclass for iterating over PHI nodes. The 19786following snippet will pretty-print all PHI nodes the statements of the 19787current function in the GIMPLE representation. 19788 19789 basic_block bb; 19790 19791 FOR_EACH_BB (bb) 19792 { 19793 gphi_iterator pi; 19794 gimple_stmt_iterator si; 19795 19796 for (pi = gsi_start_phis (bb); !gsi_end_p (pi); gsi_next (&pi)) 19797 { 19798 gphi *phi = pi.phi (); 19799 print_gimple_stmt (dump_file, phi, 0, TDF_SLIM); 19800 } 19801 for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si)) 19802 { 19803 gimple stmt = gsi_stmt (si); 19804 print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM); 19805 } 19806 } 19807 19808 19809File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 19810 1981115.2 Edges 19812========== 19813 19814Edges represent possible control flow transfers from the end of some 19815basic block A to the head of another basic block B. We say that A is a 19816predecessor of B, and B is a successor of A. Edges are represented in 19817GCC with the 'edge' data type. Each 'edge' acts as a link between two 19818basic blocks: The 'src' member of an edge points to the predecessor 19819basic block of the 'dest' basic block. The members 'preds' and 'succs' 19820of the 'basic_block' data type point to type-safe vectors of edges to 19821the predecessors and successors of the block. 19822 19823 When walking the edges in an edge vector, "edge iterators" should be 19824used. Edge iterators are constructed using the 'edge_iterator' data 19825structure and several methods are available to operate on them: 19826 19827'ei_start' 19828 This function initializes an 'edge_iterator' that points to the 19829 first edge in a vector of edges. 19830 19831'ei_last' 19832 This function initializes an 'edge_iterator' that points to the 19833 last edge in a vector of edges. 19834 19835'ei_end_p' 19836 This predicate is 'true' if an 'edge_iterator' represents the last 19837 edge in an edge vector. 19838 19839'ei_one_before_end_p' 19840 This predicate is 'true' if an 'edge_iterator' represents the 19841 second last edge in an edge vector. 19842 19843'ei_next' 19844 This function takes a pointer to an 'edge_iterator' and makes it 19845 point to the next edge in the sequence. 19846 19847'ei_prev' 19848 This function takes a pointer to an 'edge_iterator' and makes it 19849 point to the previous edge in the sequence. 19850 19851'ei_edge' 19852 This function returns the 'edge' currently pointed to by an 19853 'edge_iterator'. 19854 19855'ei_safe_safe' 19856 This function returns the 'edge' currently pointed to by an 19857 'edge_iterator', but returns 'NULL' if the iterator is pointing at 19858 the end of the sequence. This function has been provided for 19859 existing code makes the assumption that a 'NULL' edge indicates the 19860 end of the sequence. 19861 19862 The convenience macro 'FOR_EACH_EDGE' can be used to visit all of the 19863edges in a sequence of predecessor or successor edges. It must not be 19864used when an element might be removed during the traversal, otherwise 19865elements will be missed. Here is an example of how to use the macro: 19866 19867 edge e; 19868 edge_iterator ei; 19869 19870 FOR_EACH_EDGE (e, ei, bb->succs) 19871 { 19872 if (e->flags & EDGE_FALLTHRU) 19873 break; 19874 } 19875 19876 There are various reasons why control flow may transfer from one block 19877to another. One possibility is that some instruction, for example a 19878'CODE_LABEL', in a linearized instruction stream just always starts a 19879new basic block. In this case a "fall-thru" edge links the basic block 19880to the first following basic block. But there are several other reasons 19881why edges may be created. The 'flags' field of the 'edge' data type is 19882used to store information about the type of edge we are dealing with. 19883Each edge is of one of the following types: 19884 19885_jump_ 19886 No type flags are set for edges corresponding to jump instructions. 19887 These edges are used for unconditional or conditional jumps and in 19888 RTL also for table jumps. They are the easiest to manipulate as 19889 they may be freely redirected when the flow graph is not in SSA 19890 form. 19891 19892_fall-thru_ 19893 Fall-thru edges are present in case where the basic block may 19894 continue execution to the following one without branching. These 19895 edges have the 'EDGE_FALLTHRU' flag set. Unlike other types of 19896 edges, these edges must come into the basic block immediately 19897 following in the instruction stream. The function 19898 'force_nonfallthru' is available to insert an unconditional jump in 19899 the case that redirection is needed. Note that this may require 19900 creation of a new basic block. 19901 19902_exception handling_ 19903 Exception handling edges represent possible control transfers from 19904 a trapping instruction to an exception handler. The definition of 19905 "trapping" varies. In C++, only function calls can throw, but for 19906 Ada exceptions like division by zero or segmentation fault are 19907 defined and thus each instruction possibly throwing this kind of 19908 exception needs to be handled as control flow instruction. 19909 Exception edges have the 'EDGE_ABNORMAL' and 'EDGE_EH' flags set. 19910 19911 When updating the instruction stream it is easy to change possibly 19912 trapping instruction to non-trapping, by simply removing the 19913 exception edge. The opposite conversion is difficult, but should 19914 not happen anyway. The edges can be eliminated via 19915 'purge_dead_edges' call. 19916 19917 In the RTL representation, the destination of an exception edge is 19918 specified by 'REG_EH_REGION' note attached to the insn. In case of 19919 a trapping call the 'EDGE_ABNORMAL_CALL' flag is set too. In the 19920 'GIMPLE' representation, this extra flag is not set. 19921 19922 In the RTL representation, the predicate 'may_trap_p' may be used 19923 to check whether instruction still may trap or not. For the tree 19924 representation, the 'tree_could_trap_p' predicate is available, but 19925 this predicate only checks for possible memory traps, as in 19926 dereferencing an invalid pointer location. 19927 19928_sibling calls_ 19929 Sibling calls or tail calls terminate the function in a 19930 non-standard way and thus an edge to the exit must be present. 19931 'EDGE_SIBCALL' and 'EDGE_ABNORMAL' are set in such case. These 19932 edges only exist in the RTL representation. 19933 19934_computed jumps_ 19935 Computed jumps contain edges to all labels in the function 19936 referenced from the code. All those edges have 'EDGE_ABNORMAL' 19937 flag set. The edges used to represent computed jumps often cause 19938 compile time performance problems, since functions consisting of 19939 many taken labels and many computed jumps may have _very_ dense 19940 flow graphs, so these edges need to be handled with special care. 19941 During the earlier stages of the compilation process, GCC tries to 19942 avoid such dense flow graphs by factoring computed jumps. For 19943 example, given the following series of jumps, 19944 19945 goto *x; 19946 [ ... ] 19947 19948 goto *x; 19949 [ ... ] 19950 19951 goto *x; 19952 [ ... ] 19953 19954 factoring the computed jumps results in the following code sequence 19955 which has a much simpler flow graph: 19956 19957 goto y; 19958 [ ... ] 19959 19960 goto y; 19961 [ ... ] 19962 19963 goto y; 19964 [ ... ] 19965 19966 y: 19967 goto *x; 19968 19969 However, the classic problem with this transformation is that it 19970 has a runtime cost in there resulting code: An extra jump. 19971 Therefore, the computed jumps are un-factored in the later passes 19972 of the compiler (in the pass called 19973 'pass_duplicate_computed_gotos'). Be aware of that when you work 19974 on passes in that area. There have been numerous examples already 19975 where the compile time for code with unfactored computed jumps 19976 caused some serious headaches. 19977 19978_nonlocal goto handlers_ 19979 GCC allows nested functions to return into caller using a 'goto' to 19980 a label passed to as an argument to the callee. The labels passed 19981 to nested functions contain special code to cleanup after function 19982 call. Such sections of code are referred to as "nonlocal goto 19983 receivers". If a function contains such nonlocal goto receivers, 19984 an edge from the call to the label is created with the 19985 'EDGE_ABNORMAL' and 'EDGE_ABNORMAL_CALL' flags set. 19986 19987_function entry points_ 19988 By definition, execution of function starts at basic block 0, so 19989 there is always an edge from the 'ENTRY_BLOCK_PTR' to basic block 19990 0. There is no 'GIMPLE' representation for alternate entry points 19991 at this moment. In RTL, alternate entry points are specified by 19992 'CODE_LABEL' with 'LABEL_ALTERNATE_NAME' defined. This feature is 19993 currently used for multiple entry point prologues and is limited to 19994 post-reload passes only. This can be used by back-ends to emit 19995 alternate prologues for functions called from different contexts. 19996 In future full support for multiple entry functions defined by 19997 Fortran 90 needs to be implemented. 19998 19999_function exits_ 20000 In the pre-reload representation a function terminates after the 20001 last instruction in the insn chain and no explicit return 20002 instructions are used. This corresponds to the fall-thru edge into 20003 exit block. After reload, optimal RTL epilogues are used that use 20004 explicit (conditional) return instructions that are represented by 20005 edges with no flags set. 20006 20007 20008File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 20009 2001015.3 Profile information 20011======================== 20012 20013In many cases a compiler must make a choice whether to trade speed in 20014one part of code for speed in another, or to trade code size for code 20015speed. In such cases it is useful to know information about how often 20016some given block will be executed. That is the purpose for maintaining 20017profile within the flow graph. GCC can handle profile information 20018obtained through "profile feedback", but it can also estimate branch 20019probabilities based on statics and heuristics. 20020 20021 The feedback based profile is produced by compiling the program with 20022instrumentation, executing it on a train run and reading the numbers of 20023executions of basic blocks and edges back to the compiler while 20024re-compiling the program to produce the final executable. This method 20025provides very accurate information about where a program spends most of 20026its time on the train run. Whether it matches the average run of course 20027depends on the choice of train data set, but several studies have shown 20028that the behavior of a program usually changes just marginally over 20029different data sets. 20030 20031 When profile feedback is not available, the compiler may be asked to 20032attempt to predict the behavior of each branch in the program using a 20033set of heuristics (see 'predict.def' for details) and compute estimated 20034frequencies of each basic block by propagating the probabilities over 20035the graph. 20036 20037 Each 'basic_block' contains two integer fields to represent profile 20038information: 'frequency' and 'count'. The 'frequency' is an estimation 20039how often is basic block executed within a function. It is represented 20040as an integer scaled in the range from 0 to 'BB_FREQ_BASE'. The most 20041frequently executed basic block in function is initially set to 20042'BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 20043During optimization, the frequency of the most frequent basic block can 20044both decrease (for instance by loop unrolling) or grow (for instance by 20045cross-jumping optimization), so scaling sometimes has to be performed 20046multiple times. 20047 20048 The 'count' contains hard-counted numbers of execution measured during 20049training runs and is nonzero only when profile feedback is available. 20050This value is represented as the host's widest integer (typically a 64 20051bit integer) of the special type 'gcov_type'. 20052 20053 Most optimization passes can use only the frequency information of a 20054basic block, but a few passes may want to know hard execution counts. 20055The frequencies should always match the counts after scaling, however 20056during updating of the profile information numerical error may 20057accumulate into quite large errors. 20058 20059 Each edge also contains a branch probability field: an integer in the 20060range from 0 to 'REG_BR_PROB_BASE'. It represents probability of 20061passing control from the end of the 'src' basic block to the 'dest' 20062basic block, i.e. the probability that control will flow along this 20063edge. The 'EDGE_FREQUENCY' macro is available to compute how frequently 20064a given edge is taken. There is a 'count' field for each edge as well, 20065representing same information as for a basic block. 20066 20067 The basic block frequencies are not represented in the instruction 20068stream, but in the RTL representation the edge frequencies are 20069represented for conditional jumps (via the 'REG_BR_PROB' macro) since 20070they are used when instructions are output to the assembly file and the 20071flow graph is no longer maintained. 20072 20073 The probability that control flow arrives via a given edge to its 20074destination basic block is called "reverse probability" and is not 20075directly represented, but it may be easily computed from frequencies of 20076basic blocks. 20077 20078 Updating profile information is a delicate task that can unfortunately 20079not be easily integrated with the CFG manipulation API. Many of the 20080functions and hooks to modify the CFG, such as 20081'redirect_edge_and_branch', do not have enough information to easily 20082update the profile, so updating it is in the majority of cases left up 20083to the caller. It is difficult to uncover bugs in the profile updating 20084code, because they manifest themselves only by producing worse code, and 20085checking profile consistency is not possible because of numeric error 20086accumulation. Hence special attention needs to be given to this issue 20087in each pass that modifies the CFG. 20088 20089 It is important to point out that 'REG_BR_PROB_BASE' and 'BB_FREQ_BASE' 20090are both set low enough to be possible to compute second power of any 20091frequency or probability in the flow graph, it is not possible to even 20092square the 'count' field, as modern CPUs are fast enough to execute 20093$2^32$ operations quickly. 20094 20095 20096File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 20097 2009815.4 Maintaining the CFG 20099======================== 20100 20101An important task of each compiler pass is to keep both the control flow 20102graph and all profile information up-to-date. Reconstruction of the 20103control flow graph after each pass is not an option, since it may be 20104very expensive and lost profile information cannot be reconstructed at 20105all. 20106 20107 GCC has two major intermediate representations, and both use the 20108'basic_block' and 'edge' data types to represent control flow. Both 20109representations share as much of the CFG maintenance code as possible. 20110For each representation, a set of "hooks" is defined so that each 20111representation can provide its own implementation of CFG manipulation 20112routines when necessary. These hooks are defined in 'cfghooks.h'. 20113There are hooks for almost all common CFG manipulations, including block 20114splitting and merging, edge redirection and creating and deleting basic 20115blocks. These hooks should provide everything you need to maintain and 20116manipulate the CFG in both the RTL and 'GIMPLE' representation. 20117 20118 At the moment, the basic block boundaries are maintained transparently 20119when modifying instructions, so there rarely is a need to move them 20120manually (such as in case someone wants to output instruction outside 20121basic block explicitly). 20122 20123 In the RTL representation, each instruction has a 'BLOCK_FOR_INSN' 20124value that represents pointer to the basic block that contains the 20125instruction. In the 'GIMPLE' representation, the function 'gimple_bb' 20126returns a pointer to the basic block containing the queried statement. 20127 20128 When changes need to be applied to a function in its 'GIMPLE' 20129representation, "GIMPLE statement iterators" should be used. These 20130iterators provide an integrated abstraction of the flow graph and the 20131instruction stream. Block statement iterators are constructed using the 20132'gimple_stmt_iterator' data structure and several modifiers are 20133available, including the following: 20134 20135'gsi_start' 20136 This function initializes a 'gimple_stmt_iterator' that points to 20137 the first non-empty statement in a basic block. 20138 20139'gsi_last' 20140 This function initializes a 'gimple_stmt_iterator' that points to 20141 the last statement in a basic block. 20142 20143'gsi_end_p' 20144 This predicate is 'true' if a 'gimple_stmt_iterator' represents the 20145 end of a basic block. 20146 20147'gsi_next' 20148 This function takes a 'gimple_stmt_iterator' and makes it point to 20149 its successor. 20150 20151'gsi_prev' 20152 This function takes a 'gimple_stmt_iterator' and makes it point to 20153 its predecessor. 20154 20155'gsi_insert_after' 20156 This function inserts a statement after the 'gimple_stmt_iterator' 20157 passed in. The final parameter determines whether the statement 20158 iterator is updated to point to the newly inserted statement, or 20159 left pointing to the original statement. 20160 20161'gsi_insert_before' 20162 This function inserts a statement before the 'gimple_stmt_iterator' 20163 passed in. The final parameter determines whether the statement 20164 iterator is updated to point to the newly inserted statement, or 20165 left pointing to the original statement. 20166 20167'gsi_remove' 20168 This function removes the 'gimple_stmt_iterator' passed in and 20169 rechains the remaining statements in a basic block, if any. 20170 20171 In the RTL representation, the macros 'BB_HEAD' and 'BB_END' may be 20172used to get the head and end 'rtx' of a basic block. No abstract 20173iterators are defined for traversing the insn chain, but you can just 20174use 'NEXT_INSN' and 'PREV_INSN' instead. *Note Insns::. 20175 20176 Usually a code manipulating pass simplifies the instruction stream and 20177the flow of control, possibly eliminating some edges. This may for 20178example happen when a conditional jump is replaced with an unconditional 20179jump. Updating of edges is not transparent and each optimization pass 20180is required to do so manually. However only few cases occur in 20181practice. The pass may call 'purge_dead_edges' on a given basic block 20182to remove superfluous edges, if any. 20183 20184 Another common scenario is redirection of branch instructions, but this 20185is best modeled as redirection of edges in the control flow graph and 20186thus use of 'redirect_edge_and_branch' is preferred over more low level 20187functions, such as 'redirect_jump' that operate on RTL chain only. The 20188CFG hooks defined in 'cfghooks.h' should provide the complete API 20189required for manipulating and maintaining the CFG. 20190 20191 It is also possible that a pass has to insert control flow instruction 20192into the middle of a basic block, thus creating an entry point in the 20193middle of the basic block, which is impossible by definition: The block 20194must be split to make sure it only has one entry point, i.e. the head of 20195the basic block. The CFG hook 'split_block' may be used when an 20196instruction in the middle of a basic block has to become the target of a 20197jump or branch instruction. 20198 20199 For a global optimizer, a common operation is to split edges in the 20200flow graph and insert instructions on them. In the RTL representation, 20201this can be easily done using the 'insert_insn_on_edge' function that 20202emits an instruction "on the edge", caching it for a later 20203'commit_edge_insertions' call that will take care of moving the inserted 20204instructions off the edge into the instruction stream contained in a 20205basic block. This includes the creation of new basic blocks where 20206needed. In the 'GIMPLE' representation, the equivalent functions are 20207'gsi_insert_on_edge' which inserts a block statement iterator on an 20208edge, and 'gsi_commit_edge_inserts' which flushes the instruction to 20209actual instruction stream. 20210 20211 While debugging the optimization pass, the 'verify_flow_info' function 20212may be useful to find bugs in the control flow graph updating code. 20213 20214 20215File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 20216 2021715.5 Liveness information 20218========================= 20219 20220Liveness information is useful to determine whether some register is 20221"live" at given point of program, i.e. that it contains a value that may 20222be used at a later point in the program. This information is used, for 20223instance, during register allocation, as the pseudo registers only need 20224to be assigned to a unique hard register or to a stack slot if they are 20225live. The hard registers and stack slots may be freely reused for other 20226values when a register is dead. 20227 20228 Liveness information is available in the back end starting with 20229'pass_df_initialize' and ending with 'pass_df_finish'. Three flavors of 20230live analysis are available: With 'LR', it is possible to determine at 20231any point 'P' in the function if the register may be used on some path 20232from 'P' to the end of the function. With 'UR', it is possible to 20233determine if there is a path from the beginning of the function to 'P' 20234that defines the variable. 'LIVE' is the intersection of the 'LR' and 20235'UR' and a variable is live at 'P' if there is both an assignment that 20236reaches it from the beginning of the function and a use that can be 20237reached on some path from 'P' to the end of the function. 20238 20239 In general 'LIVE' is the most useful of the three. The macros 20240'DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 20241macros take a basic block number and return a bitmap that is indexed by 20242the register number. This information is only guaranteed to be up to 20243date after calls are made to 'df_analyze'. See the file 'df-core.c' for 20244details on using the dataflow. 20245 20246 The liveness information is stored partly in the RTL instruction stream 20247and partly in the flow graph. Local information is stored in the 20248instruction stream: Each instruction may contain 'REG_DEAD' notes 20249representing that the value of a given register is no longer needed, or 20250'REG_UNUSED' notes representing that the value computed by the 20251instruction is never used. The second is useful for instructions 20252computing multiple values at once. 20253 20254 20255File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 20256 2025716 Analysis and Representation of Loops 20258*************************************** 20259 20260GCC provides extensive infrastructure for work with natural loops, i.e., 20261strongly connected components of CFG with only one entry block. This 20262chapter describes representation of loops in GCC, both on GIMPLE and in 20263RTL, as well as the interfaces to loop-related analyses (induction 20264variable analysis and number of iterations analysis). 20265 20266* Menu: 20267 20268* Loop representation:: Representation and analysis of loops. 20269* Loop querying:: Getting information about loops. 20270* Loop manipulation:: Loop manipulation functions. 20271* LCSSA:: Loop-closed SSA form. 20272* Scalar evolutions:: Induction variables on GIMPLE. 20273* loop-iv:: Induction variables on RTL. 20274* Number of iterations:: Number of iterations analysis. 20275* Dependency analysis:: Data dependency analysis. 20276 20277 20278File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 20279 2028016.1 Loop representation 20281======================== 20282 20283This chapter describes the representation of loops in GCC, and functions 20284that can be used to build, modify and analyze this representation. Most 20285of the interfaces and data structures are declared in 'cfgloop.h'. Loop 20286structures are analyzed and this information disposed or updated at the 20287discretion of individual passes. Still most of the generic CFG 20288manipulation routines are aware of loop structures and try to keep them 20289up-to-date. By this means an increasing part of the compilation 20290pipeline is setup to maintain loop structure across passes to allow 20291attaching meta information to individual loops for consumption by later 20292passes. 20293 20294 In general, a natural loop has one entry block (header) and possibly 20295several back edges (latches) leading to the header from the inside of 20296the loop. Loops with several latches may appear if several loops share 20297a single header, or if there is a branching in the middle of the loop. 20298The representation of loops in GCC however allows only loops with a 20299single latch. During loop analysis, headers of such loops are split and 20300forwarder blocks are created in order to disambiguate their structures. 20301Heuristic based on profile information and structure of the induction 20302variables in the loops is used to determine whether the latches 20303correspond to sub-loops or to control flow in a single loop. This means 20304that the analysis sometimes changes the CFG, and if you run it in the 20305middle of an optimization pass, you must be able to deal with the new 20306blocks. You may avoid CFG changes by passing 20307'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 20308however that most other loop manipulation functions will not work 20309correctly for loops with multiple latch edges (the functions that only 20310query membership of blocks to loops and subloop relationships, or 20311enumerate and test loop exits, can be expected to work). 20312 20313 Body of the loop is the set of blocks that are dominated by its header, 20314and reachable from its latch against the direction of edges in CFG. The 20315loops are organized in a containment hierarchy (tree) such that all the 20316loops immediately contained inside loop L are the children of L in the 20317tree. This tree is represented by the 'struct loops' structure. The 20318root of this tree is a fake loop that contains all blocks in the 20319function. Each of the loops is represented in a 'struct loop' 20320structure. Each loop is assigned an index ('num' field of the 'struct 20321loop' structure), and the pointer to the loop is stored in the 20322corresponding field of the 'larray' vector in the loops structure. The 20323indices do not have to be continuous, there may be empty ('NULL') 20324entries in the 'larray' created by deleting loops. Also, there is no 20325guarantee on the relative order of a loop and its subloops in the 20326numbering. The index of a loop never changes. 20327 20328 The entries of the 'larray' field should not be accessed directly. The 20329function 'get_loop' returns the loop description for a loop with the 20330given index. 'number_of_loops' function returns number of loops in the 20331function. To traverse all loops, use 'FOR_EACH_LOOP' macro. The 20332'flags' argument of the macro is used to determine the direction of 20333traversal and the set of loops visited. Each loop is guaranteed to be 20334visited exactly once, regardless of the changes to the loop tree, and 20335the loops may be removed during the traversal. The newly created loops 20336are never traversed, if they need to be visited, this must be done 20337separately after their creation. 20338 20339 Each basic block contains the reference to the innermost loop it 20340belongs to ('loop_father'). For this reason, it is only possible to 20341have one 'struct loops' structure initialized at the same time for each 20342CFG. The global variable 'current_loops' contains the 'struct loops' 20343structure. Many of the loop manipulation functions assume that 20344dominance information is up-to-date. 20345 20346 The loops are analyzed through 'loop_optimizer_init' function. The 20347argument of this function is a set of flags represented in an integer 20348bitmask. These flags specify what other properties of the loop 20349structures should be calculated/enforced and preserved later: 20350 20351 * 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 20352 to CFG will be performed in the loop analysis, in particular, loops 20353 with multiple latch edges will not be disambiguated. If a loop has 20354 multiple latches, its latch block is set to NULL. Most of the loop 20355 manipulation functions will not work for loops in this shape. No 20356 other flags that require CFG changes can be passed to 20357 loop_optimizer_init. 20358 * 'LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a way 20359 that each loop has only one entry edge, and additionally, the 20360 source block of this entry edge has only one successor. This 20361 creates a natural place where the code can be moved out of the 20362 loop, and ensures that the entry edge of the loop leads from its 20363 immediate super-loop. 20364 * 'LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 20365 the latch block of each loop to have only one successor. This 20366 ensures that the latch of the loop does not belong to any of its 20367 sub-loops, and makes manipulation with the loops significantly 20368 easier. Most of the loop manipulation functions assume that the 20369 loops are in this shape. Note that with this flag, the "normal" 20370 loop without any control flow inside and with one exit consists of 20371 two basic blocks. 20372 * 'LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 20373 the strongly connected components that are not natural loops (have 20374 more than one entry block) are marked with 'BB_IRREDUCIBLE_LOOP' 20375 and 'EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 20376 and edges that belong to natural loops that are in such an 20377 irreducible region (but it is set for the entry and exit edges of 20378 such a loop, if they lead to/from this region). 20379 * 'LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 20380 updated for each loop. This makes some functions (e.g., 20381 'get_loop_exit_edges') more efficient. Some functions (e.g., 20382 'single_exit') can be used only if the lists of exits are recorded. 20383 20384 These properties may also be computed/enforced later, using functions 20385'create_preheaders', 'force_single_succ_latches', 20386'mark_irreducible_loops' and 'record_loop_exits'. The properties can be 20387queried using 'loops_state_satisfies_p'. 20388 20389 The memory occupied by the loops structures should be freed with 20390'loop_optimizer_finalize' function. When loop structures are setup to 20391be preserved across passes this function reduces the information to be 20392kept up-to-date to a minimum (only 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' 20393set). 20394 20395 The CFG manipulation functions in general do not update loop 20396structures. Specialized versions that additionally do so are provided 20397for the most common tasks. On GIMPLE, 'cleanup_tree_cfg_loop' function 20398can be used to cleanup CFG while updating the loops structures if 20399'current_loops' is set. 20400 20401 At the moment loop structure is preserved from the start of GIMPLE loop 20402optimizations until the end of RTL loop optimizations. During this time 20403a loop can be tracked by its 'struct loop' and number. 20404 20405 20406File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 20407 2040816.2 Loop querying 20409================== 20410 20411The functions to query the information about loops are declared in 20412'cfgloop.h'. Some of the information can be taken directly from the 20413structures. 'loop_father' field of each basic block contains the 20414innermost loop to that the block belongs. The most useful fields of 20415loop structure (that are kept up-to-date at all times) are: 20416 20417 * 'header', 'latch': Header and latch basic blocks of the loop. 20418 * 'num_nodes': Number of basic blocks in the loop (including the 20419 basic blocks of the sub-loops). 20420 * 'outer', 'inner', 'next': The super-loop, the first sub-loop, and 20421 the sibling of the loop in the loops tree. 20422 20423 There are other fields in the loop structures, many of them used only 20424by some of the passes, or not updated during CFG changes; in general, 20425they should not be accessed directly. 20426 20427 The most important functions to query loop structures are: 20428 20429 * 'loop_depth': The depth of the loop in the loops tree, i.e., the 20430 number of super-loops of the loop. 20431 * 'flow_loops_dump': Dumps the information about loops to a file. 20432 * 'verify_loop_structure': Checks consistency of the loop structures. 20433 * 'loop_latch_edge': Returns the latch edge of a loop. 20434 * 'loop_preheader_edge': If loops have preheaders, returns the 20435 preheader edge of a loop. 20436 * 'flow_loop_nested_p': Tests whether loop is a sub-loop of another 20437 loop. 20438 * 'flow_bb_inside_loop_p': Tests whether a basic block belongs to a 20439 loop (including its sub-loops). 20440 * 'find_common_loop': Finds the common super-loop of two loops. 20441 * 'superloop_at_depth': Returns the super-loop of a loop with the 20442 given depth. 20443 * 'tree_num_loop_insns', 'num_loop_insns': Estimates the number of 20444 insns in the loop, on GIMPLE and on RTL. 20445 * 'loop_exit_edge_p': Tests whether edge is an exit from a loop. 20446 * 'mark_loop_exit_edges': Marks all exit edges of all loops with 20447 'EDGE_LOOP_EXIT' flag. 20448 * 'get_loop_body', 'get_loop_body_in_dom_order', 20449 'get_loop_body_in_bfs_order': Enumerates the basic blocks in the 20450 loop in depth-first search order in reversed CFG, ordered by 20451 dominance relation, and breath-first search order, respectively. 20452 * 'single_exit': Returns the single exit edge of the loop, or 'NULL' 20453 if the loop has more than one exit. You can only use this function 20454 if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 20455 * 'get_loop_exit_edges': Enumerates the exit edges of a loop. 20456 * 'just_once_each_iteration_p': Returns true if the basic block is 20457 executed exactly once during each iteration of a loop (that is, it 20458 does not belong to a sub-loop, and it dominates the latch of the 20459 loop). 20460 20461 20462File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 20463 2046416.3 Loop manipulation 20465====================== 20466 20467The loops tree can be manipulated using the following functions: 20468 20469 * 'flow_loop_tree_node_add': Adds a node to the tree. 20470 * 'flow_loop_tree_node_remove': Removes a node from the tree. 20471 * 'add_bb_to_loop': Adds a basic block to a loop. 20472 * 'remove_bb_from_loops': Removes a basic block from loops. 20473 20474 Most low-level CFG functions update loops automatically. The following 20475functions handle some more complicated cases of CFG manipulations: 20476 20477 * 'remove_path': Removes an edge and all blocks it dominates. 20478 * 'split_loop_exit_edge': Splits exit edge of the loop, ensuring that 20479 PHI node arguments remain in the loop (this ensures that 20480 loop-closed SSA form is preserved). Only useful on GIMPLE. 20481 20482 Finally, there are some higher-level loop transformations implemented. 20483While some of them are written so that they should work on non-innermost 20484loops, they are mostly untested in that case, and at the moment, they 20485are only reliable for the innermost loops: 20486 20487 * 'create_iv': Creates a new induction variable. Only works on 20488 GIMPLE. 'standard_iv_increment_position' can be used to find a 20489 suitable place for the iv increment. 20490 * 'duplicate_loop_to_header_edge', 20491 'tree_duplicate_loop_to_header_edge': These functions (on RTL and 20492 on GIMPLE) duplicate the body of the loop prescribed number of 20493 times on one of the edges entering loop header, thus performing 20494 either loop unrolling or loop peeling. 'can_duplicate_loop_p' 20495 ('can_unroll_loop_p' on GIMPLE) must be true for the duplicated 20496 loop. 20497 * 'loop_version': This function creates a copy of a loop, and a 20498 branch before them that selects one of them depending on the 20499 prescribed condition. This is useful for optimizations that need 20500 to verify some assumptions in runtime (one of the copies of the 20501 loop is usually left unchanged, while the other one is transformed 20502 in some way). 20503 * 'tree_unroll_loop': Unrolls the loop, including peeling the extra 20504 iterations to make the number of iterations divisible by unroll 20505 factor, updating the exit condition, and removing the exits that 20506 now cannot be taken. Works only on GIMPLE. 20507 20508 20509File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 20510 2051116.4 Loop-closed SSA form 20512========================= 20513 20514Throughout the loop optimizations on tree level, one extra condition is 20515enforced on the SSA form: No SSA name is used outside of the loop in 20516that it is defined. The SSA form satisfying this condition is called 20517"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 20518created at the exits of the loops for the SSA names that are used 20519outside of them. Only the real operands (not virtual SSA names) are 20520held in LCSSA, in order to save memory. 20521 20522 There are various benefits of LCSSA: 20523 20524 * Many optimizations (value range analysis, final value replacement) 20525 are interested in the values that are defined in the loop and used 20526 outside of it, i.e., exactly those for that we create new PHI 20527 nodes. 20528 * In induction variable analysis, it is not necessary to specify the 20529 loop in that the analysis should be performed - the scalar 20530 evolution analysis always returns the results with respect to the 20531 loop in that the SSA name is defined. 20532 * It makes updating of SSA form during loop transformations simpler. 20533 Without LCSSA, operations like loop unrolling may force creation of 20534 PHI nodes arbitrarily far from the loop, while in LCSSA, the SSA 20535 form can be updated locally. However, since we only keep real 20536 operands in LCSSA, we cannot use this advantage (we could have 20537 local updating of real operands, but it is not much more efficient 20538 than to use generic SSA form updating for it as well; the amount of 20539 changes to SSA is the same). 20540 20541 However, it also means LCSSA must be updated. This is usually 20542straightforward, unless you create a new value in loop and use it 20543outside, or unless you manipulate loop exit edges (functions are 20544provided to make these manipulations simple). 20545'rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, and 20546'verify_loop_closed_ssa' to check that the invariant of LCSSA is 20547preserved. 20548 20549 20550File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 20551 2055216.5 Scalar evolutions 20553====================== 20554 20555Scalar evolutions (SCEV) are used to represent results of induction 20556variable analysis on GIMPLE. They enable us to represent variables with 20557complicated behavior in a simple and consistent way (we only use it to 20558express values of polynomial induction variables, but it is possible to 20559extend it). The interfaces to SCEV analysis are declared in 20560'tree-scalar-evolution.h'. To use scalar evolutions analysis, 20561'scev_initialize' must be used. To stop using SCEV, 'scev_finalize' 20562should be used. SCEV analysis caches results in order to save time and 20563memory. This cache however is made invalid by most of the loop 20564transformations, including removal of code. If such a transformation is 20565performed, 'scev_reset' must be called to clean the caches. 20566 20567 Given an SSA name, its behavior in loops can be analyzed using the 20568'analyze_scalar_evolution' function. The returned SCEV however does not 20569have to be fully analyzed and it may contain references to other SSA 20570names defined in the loop. To resolve these (potentially recursive) 20571references, 'instantiate_parameters' or 'resolve_mixers' functions must 20572be used. 'instantiate_parameters' is useful when you use the results of 20573SCEV only for some analysis, and when you work with whole nest of loops 20574at once. It will try replacing all SSA names by their SCEV in all 20575loops, including the super-loops of the current loop, thus providing a 20576complete information about the behavior of the variable in the loop 20577nest. 'resolve_mixers' is useful if you work with only one loop at a 20578time, and if you possibly need to create code based on the value of the 20579induction variable. It will only resolve the SSA names defined in the 20580current loop, leaving the SSA names defined outside unchanged, even if 20581their evolution in the outer loops is known. 20582 20583 The SCEV is a normal tree expression, except for the fact that it may 20584contain several special tree nodes. One of them is 'SCEV_NOT_KNOWN', 20585used for SSA names whose value cannot be expressed. The other one is 20586'POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 20587and loop (both base and step may contain further polynomial chrecs). 20588Type of the expression and of base and step must be the same. A 20589variable has evolution 'POLYNOMIAL_CHREC(base, step, loop)' if it is (in 20590the specified loop) equivalent to 'x_1' in the following example 20591 20592 while (...) 20593 { 20594 x_1 = phi (base, x_2); 20595 x_2 = x_1 + step; 20596 } 20597 20598 Note that this includes the language restrictions on the operations. 20599For example, if we compile C code and 'x' has signed type, then the 20600overflow in addition would cause undefined behavior, and we may assume 20601that this does not happen. Hence, the value with this SCEV cannot 20602overflow (which restricts the number of iterations of such a loop). 20603 20604 In many cases, one wants to restrict the attention just to affine 20605induction variables. In this case, the extra expressive power of SCEV 20606is not useful, and may complicate the optimizations. In this case, 20607'simple_iv' function may be used to analyze a value - the result is a 20608loop-invariant base and step. 20609 20610 20611File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 20612 2061316.6 IV analysis on RTL 20614======================= 20615 20616The induction variable on RTL is simple and only allows analysis of 20617affine induction variables, and only in one loop at once. The interface 20618is declared in 'cfgloop.h'. Before analyzing induction variables in a 20619loop L, 'iv_analysis_loop_init' function must be called on L. After the 20620analysis (possibly calling 'iv_analysis_loop_init' for several loops) is 20621finished, 'iv_analysis_done' should be called. The following functions 20622can be used to access the results of the analysis: 20623 20624 * 'iv_analyze': Analyzes a single register used in the given insn. 20625 If no use of the register in this insn is found, the following 20626 insns are scanned, so that this function can be called on the insn 20627 returned by get_condition. 20628 * 'iv_analyze_result': Analyzes result of the assignment in the given 20629 insn. 20630 * 'iv_analyze_expr': Analyzes a more complicated expression. All its 20631 operands are analyzed by 'iv_analyze', and hence they must be used 20632 in the specified insn or one of the following insns. 20633 20634 The description of the induction variable is provided in 'struct 20635rtx_iv'. In order to handle subregs, the representation is a bit 20636complicated; if the value of the 'extend' field is not 'UNKNOWN', the 20637value of the induction variable in the i-th iteration is 20638 20639 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 20640 20641 with the following exception: if 'first_special' is true, then the 20642value in the first iteration (when 'i' is zero) is 'delta + mult * 20643base'. However, if 'extend' is equal to 'UNKNOWN', then 'first_special' 20644must be false, 'delta' 0, 'mult' 1 and the value in the i-th iteration 20645is 20646 20647 subreg_{mode} (base + i * step) 20648 20649 The function 'get_iv_value' can be used to perform these calculations. 20650 20651 20652File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 20653 2065416.7 Number of iterations analysis 20655================================== 20656 20657Both on GIMPLE and on RTL, there are functions available to determine 20658the number of iterations of a loop, with a similar interface. The 20659number of iterations of a loop in GCC is defined as the number of 20660executions of the loop latch. In many cases, it is not possible to 20661determine the number of iterations unconditionally - the determined 20662number is correct only if some assumptions are satisfied. The analysis 20663tries to verify these conditions using the information contained in the 20664program; if it fails, the conditions are returned together with the 20665result. The following information and conditions are provided by the 20666analysis: 20667 20668 * 'assumptions': If this condition is false, the rest of the 20669 information is invalid. 20670 * 'noloop_assumptions' on RTL, 'may_be_zero' on GIMPLE: If this 20671 condition is true, the loop exits in the first iteration. 20672 * 'infinite': If this condition is true, the loop is infinite. This 20673 condition is only available on RTL. On GIMPLE, conditions for 20674 finiteness of the loop are included in 'assumptions'. 20675 * 'niter_expr' on RTL, 'niter' on GIMPLE: The expression that gives 20676 number of iterations. The number of iterations is defined as the 20677 number of executions of the loop latch. 20678 20679 Both on GIMPLE and on RTL, it necessary for the induction variable 20680analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 20681On GIMPLE, the results are stored to 'struct tree_niter_desc' structure. 20682Number of iterations before the loop is exited through a given exit can 20683be determined using 'number_of_iterations_exit' function. On RTL, the 20684results are returned in 'struct niter_desc' structure. The 20685corresponding function is named 'check_simple_exit'. There are also 20686functions that pass through all the exits of a loop and try to find one 20687with easy to determine number of iterations - 'find_loop_niter' on 20688GIMPLE and 'find_simple_exit' on RTL. Finally, there are functions that 20689provide the same information, but additionally cache it, so that 20690repeated calls to number of iterations are not so costly - 20691'number_of_latch_executions' on GIMPLE and 'get_simple_loop_desc' on 20692RTL. 20693 20694 Note that some of these functions may behave slightly differently than 20695others - some of them return only the expression for the number of 20696iterations, and fail if there are some assumptions. The function 20697'number_of_latch_executions' works only for single-exit loops. The 20698function 'number_of_cond_exit_executions' can be used to determine 20699number of executions of the exit condition of a single-exit loop (i.e., 20700the 'number_of_latch_executions' increased by one). 20701 20702 On GIMPLE, below constraint flags affect semantics of some APIs of 20703number of iterations analyzer: 20704 20705 * 'LOOP_C_INFINITE': If this constraint flag is set, the loop is 20706 known to be infinite. APIs like 'number_of_iterations_exit' can 20707 return false directly without doing any analysis. 20708 * 'LOOP_C_FINITE': If this constraint flag is set, the loop is known 20709 to be finite, in other words, loop's number of iterations can be 20710 computed with 'assumptions' be true. 20711 20712 Generally, the constraint flags are set/cleared by consumers which are 20713loop optimizers. It's also the consumers' responsibility to set/clear 20714constraints correctly. Failing to do that might result in hard to track 20715down bugs in scev/niter consumers. One typical use case is vectorizer: 20716it drives number of iterations analyzer by setting 'LOOP_C_FINITE' and 20717vectorizes possibly infinite loop by versioning loop with analysis 20718result. In return, constraints set by consumers can also help number of 20719iterations analyzer in following optimizers. For example, 'niter' of a 20720loop versioned under 'assumptions' is valid unconditionally. 20721 20722 Other constraints may be added in the future, for example, a constraint 20723indicating that loops' latch must roll thus 'may_be_zero' would be false 20724unconditionally. 20725 20726 20727File: gccint.info, Node: Dependency analysis, Prev: Number of iterations, Up: Loop Analysis and Representation 20728 2072916.8 Data Dependency Analysis 20730============================= 20731 20732The code for the data dependence analysis can be found in 20733'tree-data-ref.c' and its interface and data structures are described in 20734'tree-data-ref.h'. The function that computes the data dependences for 20735all the array and pointer references for a given loop is 20736'compute_data_dependences_for_loop'. This function is currently used by 20737the linear loop transform and the vectorization passes. Before calling 20738this function, one has to allocate two vectors: a first vector will 20739contain the set of data references that are contained in the analyzed 20740loop body, and the second vector will contain the dependence relations 20741between the data references. Thus if the vector of data references is 20742of size 'n', the vector containing the dependence relations will contain 20743'n*n' elements. However if the analyzed loop contains side effects, 20744such as calls that potentially can interfere with the data references in 20745the current analyzed loop, the analysis stops while scanning the loop 20746body for data references, and inserts a single 'chrec_dont_know' in the 20747dependence relation array. 20748 20749 The data references are discovered in a particular order during the 20750scanning of the loop body: the loop body is analyzed in execution order, 20751and the data references of each statement are pushed at the end of the 20752data reference array. Two data references syntactically occur in the 20753program in the same order as in the array of data references. This 20754syntactic order is important in some classical data dependence tests, 20755and mapping this order to the elements of this array avoids costly 20756queries to the loop body representation. 20757 20758 Three types of data references are currently handled: ARRAY_REF, 20759INDIRECT_REF and COMPONENT_REF. The data structure for the data 20760reference is 'data_reference', where 'data_reference_p' is a name of a 20761pointer to the data reference structure. The structure contains the 20762following elements: 20763 20764 * 'base_object_info': Provides information about the base object of 20765 the data reference and its access functions. These access 20766 functions represent the evolution of the data reference in the loop 20767 relative to its base, in keeping with the classical meaning of the 20768 data reference access function for the support of arrays. For 20769 example, for a reference 'a.b[i][j]', the base object is 'a.b' and 20770 the access functions, one for each array subscript, are: '{i_init, 20771 + i_step}_1, {j_init, +, j_step}_2'. 20772 20773 * 'first_location_in_loop': Provides information about the first 20774 location accessed by the data reference in the loop and about the 20775 access function used to represent evolution relative to this 20776 location. This data is used to support pointers, and is not used 20777 for arrays (for which we have base objects). Pointer accesses are 20778 represented as a one-dimensional access that starts from the first 20779 location accessed in the loop. For example: 20780 20781 for1 i 20782 for2 j 20783 *((int *)p + i + j) = a[i][j]; 20784 20785 The access function of the pointer access is '{0, + 4B}_for2' 20786 relative to 'p + i'. The access functions of the array are 20787 '{i_init, + i_step}_for1' and '{j_init, +, j_step}_for2' relative 20788 to 'a'. 20789 20790 Usually, the object the pointer refers to is either unknown, or we 20791 cannot prove that the access is confined to the boundaries of a 20792 certain object. 20793 20794 Two data references can be compared only if at least one of these 20795 two representations has all its fields filled for both data 20796 references. 20797 20798 The current strategy for data dependence tests is as follows: If 20799 both 'a' and 'b' are represented as arrays, compare 'a.base_object' 20800 and 'b.base_object'; if they are equal, apply dependence tests (use 20801 access functions based on base_objects). Else if both 'a' and 'b' 20802 are represented as pointers, compare 'a.first_location' and 20803 'b.first_location'; if they are equal, apply dependence tests (use 20804 access functions based on first location). However, if 'a' and 'b' 20805 are represented differently, only try to prove that the bases are 20806 definitely different. 20807 20808 * Aliasing information. 20809 * Alignment information. 20810 20811 The structure describing the relation between two data references is 20812'data_dependence_relation' and the shorter name for a pointer to such a 20813structure is 'ddr_p'. This structure contains: 20814 20815 * a pointer to each data reference, 20816 * a tree node 'are_dependent' that is set to 'chrec_known' if the 20817 analysis has proved that there is no dependence between these two 20818 data references, 'chrec_dont_know' if the analysis was not able to 20819 determine any useful result and potentially there could exist a 20820 dependence between these data references, and 'are_dependent' is 20821 set to 'NULL_TREE' if there exist a dependence relation between the 20822 data references, and the description of this dependence relation is 20823 given in the 'subscripts', 'dir_vects', and 'dist_vects' arrays, 20824 * a boolean that determines whether the dependence relation can be 20825 represented by a classical distance vector, 20826 * an array 'subscripts' that contains a description of each subscript 20827 of the data references. Given two array accesses a subscript is 20828 the tuple composed of the access functions for a given dimension. 20829 For example, given 'A[f1][f2][f3]' and 'B[g1][g2][g3]', there are 20830 three subscripts: '(f1, g1), (f2, g2), (f3, g3)'. 20831 * two arrays 'dir_vects' and 'dist_vects' that contain classical 20832 representations of the data dependences under the form of direction 20833 and distance dependence vectors, 20834 * an array of loops 'loop_nest' that contains the loops to which the 20835 distance and direction vectors refer to. 20836 20837 Several functions for pretty printing the information extracted by the 20838data dependence analysis are available: 'dump_ddrs' prints with a 20839maximum verbosity the details of a data dependence relations array, 20840'dump_dist_dir_vectors' prints only the classical distance and direction 20841vectors for a data dependence relations array, and 20842'dump_data_references' prints the details of the data references 20843contained in a data reference array. 20844 20845 20846File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 20847 2084817 Machine Descriptions 20849*********************** 20850 20851A machine description has two parts: a file of instruction patterns 20852('.md' file) and a C header file of macro definitions. 20853 20854 The '.md' file for a target machine contains a pattern for each 20855instruction that the target machine supports (or at least each 20856instruction that is worth telling the compiler about). It may also 20857contain comments. A semicolon causes the rest of the line to be a 20858comment, unless the semicolon is inside a quoted string. 20859 20860 See the next chapter for information on the C header file. 20861 20862* Menu: 20863 20864* Overview:: How the machine description is used. 20865* Patterns:: How to write instruction patterns. 20866* Example:: An explained example of a 'define_insn' pattern. 20867* RTL Template:: The RTL template defines what insns match a pattern. 20868* Output Template:: The output template says how to make assembler code 20869 from such an insn. 20870* Output Statement:: For more generality, write C code to output 20871 the assembler code. 20872* Predicates:: Controlling what kinds of operands can be used 20873 for an insn. 20874* Constraints:: Fine-tuning operand selection. 20875* Standard Names:: Names mark patterns to use for code generation. 20876* Pattern Ordering:: When the order of patterns makes a difference. 20877* Dependent Patterns:: Having one pattern may make you need another. 20878* Jump Patterns:: Special considerations for patterns for jump insns. 20879* Looping Patterns:: How to define patterns for special looping insns. 20880* Insn Canonicalizations::Canonicalization of Instructions 20881* Expander Definitions::Generating a sequence of several RTL insns 20882 for a standard operation. 20883* Insn Splitting:: Splitting Instructions into Multiple Instructions. 20884* Including Patterns:: Including Patterns in Machine Descriptions. 20885* Peephole Definitions::Defining machine-specific peephole optimizations. 20886* Insn Attributes:: Specifying the value of attributes for generated insns. 20887* Conditional Execution::Generating 'define_insn' patterns for 20888 predication. 20889* Define Subst:: Generating 'define_insn' and 'define_expand' 20890 patterns from other patterns. 20891* Constant Definitions::Defining symbolic constants that can be used in the 20892 md file. 20893* Iterators:: Using iterators to generate patterns from a template. 20894 20895 20896File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 20897 2089817.1 Overview of How the Machine Description is Used 20899==================================================== 20900 20901There are three main conversions that happen in the compiler: 20902 20903 1. The front end reads the source code and builds a parse tree. 20904 20905 2. The parse tree is used to generate an RTL insn list based on named 20906 instruction patterns. 20907 20908 3. The insn list is matched against the RTL templates to produce 20909 assembler code. 20910 20911 For the generate pass, only the names of the insns matter, from either 20912a named 'define_insn' or a 'define_expand'. The compiler will choose 20913the pattern with the right name and apply the operands according to the 20914documentation later in this chapter, without regard for the RTL template 20915or operand constraints. Note that the names the compiler looks for are 20916hard-coded in the compiler--it will ignore unnamed patterns and patterns 20917with names it doesn't know about, but if you don't provide a named 20918pattern it needs, it will abort. 20919 20920 If a 'define_insn' is used, the template given is inserted into the 20921insn list. If a 'define_expand' is used, one of three things happens, 20922based on the condition logic. The condition logic may manually create 20923new insns for the insn list, say via 'emit_insn()', and invoke 'DONE'. 20924For certain named patterns, it may invoke 'FAIL' to tell the compiler to 20925use an alternate way of performing that task. If it invokes neither 20926'DONE' nor 'FAIL', the template given in the pattern is inserted, as if 20927the 'define_expand' were a 'define_insn'. 20928 20929 Once the insn list is generated, various optimization passes convert, 20930replace, and rearrange the insns in the insn list. This is where the 20931'define_split' and 'define_peephole' patterns get used, for example. 20932 20933 Finally, the insn list's RTL is matched up with the RTL templates in 20934the 'define_insn' patterns, and those patterns are used to emit the 20935final assembly code. For this purpose, each named 'define_insn' acts 20936like it's unnamed, since the names are ignored. 20937 20938 20939File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 20940 2094117.2 Everything about Instruction Patterns 20942========================================== 20943 20944A 'define_insn' expression is used to define instruction patterns to 20945which insns may be matched. A 'define_insn' expression contains an 20946incomplete RTL expression, with pieces to be filled in later, operand 20947constraints that restrict how the pieces can be filled in, and an output 20948template or C code to generate the assembler output. 20949 20950 A 'define_insn' is an RTL expression containing four or five operands: 20951 20952 1. An optional name N. When a name is present, the compiler 20953 automically generates a C++ function 'gen_N' that takes the 20954 operands of the instruction as arguments and returns the 20955 instruction's rtx pattern. The compiler also assigns the 20956 instruction a unique code 'CODE_FOR_N', with all such codes 20957 belonging to an enum called 'insn_code'. 20958 20959 These names serve one of two purposes. The first is to indicate 20960 that the instruction performs a certain standard job for the 20961 RTL-generation pass of the compiler, such as a move, an addition, 20962 or a conditional jump. The second is to help the target generate 20963 certain target-specific operations, such as when implementing 20964 target-specific intrinsic functions. 20965 20966 It is better to prefix target-specific names with the name of the 20967 target, to avoid any clash with current or future standard names. 20968 20969 The absence of a name is indicated by writing an empty string where 20970 the name should go. Nameless instruction patterns are never used 20971 for generating RTL code, but they may permit several simpler insns 20972 to be combined later on. 20973 20974 For the purpose of debugging the compiler, you may also specify a 20975 name beginning with the '*' character. Such a name is used only 20976 for identifying the instruction in RTL dumps; it is equivalent to 20977 having a nameless pattern for all other purposes. Names beginning 20978 with the '*' character are not required to be unique. 20979 20980 The name may also have the form '@N'. This has the same effect as 20981 a name 'N', but in addition tells the compiler to generate further 20982 helper functions; see *note Parameterized Names:: for details. 20983 20984 2. The "RTL template": This is a vector of incomplete RTL expressions 20985 which describe the semantics of the instruction (*note RTL 20986 Template::). It is incomplete because it may contain 20987 'match_operand', 'match_operator', and 'match_dup' expressions that 20988 stand for operands of the instruction. 20989 20990 If the vector has multiple elements, the RTL template is treated as 20991 a 'parallel' expression. 20992 20993 3. The condition: This is a string which contains a C expression. 20994 When the compiler attempts to match RTL against a pattern, the 20995 condition is evaluated. If the condition evaluates to 'true', the 20996 match is permitted. The condition may be an empty string, which is 20997 treated as always 'true'. 20998 20999 For a named pattern, the condition may not depend on the data in 21000 the insn being matched, but only the target-machine-type flags. 21001 The compiler needs to test these conditions during initialization 21002 in order to learn exactly which named instructions are available in 21003 a particular run. 21004 21005 For nameless patterns, the condition is applied only when matching 21006 an individual insn, and only after the insn has matched the 21007 pattern's recognition template. The insn's operands may be found 21008 in the vector 'operands'. 21009 21010 An instruction condition cannot become more restrictive as 21011 compilation progresses. If the condition accepts a particular RTL 21012 instruction at one stage of compilation, it must continue to accept 21013 that instruction until the final pass. For example, 21014 '!reload_completed' and 'can_create_pseudo_p ()' are both invalid 21015 instruction conditions, because they are true during the earlier 21016 RTL passes and false during the later ones. For the same reason, 21017 if a condition accepts an instruction before register allocation, 21018 it cannot later try to control register allocation by excluding 21019 certain register or value combinations. 21020 21021 Although a condition cannot become more restrictive as compilation 21022 progresses, the condition for a nameless pattern _can_ become more 21023 permissive. For example, a nameless instruction can require 21024 'reload_completed' to be true, in which case it only matches after 21025 register allocation. 21026 21027 4. The "output template" or "output statement": This is either a 21028 string, or a fragment of C code which returns a string. 21029 21030 When simple substitution isn't general enough, you can specify a 21031 piece of C code to compute the output. *Note Output Statement::. 21032 21033 5. The "insn attributes": This is an optional vector containing the 21034 values of attributes for insns matching this pattern (*note Insn 21035 Attributes::). 21036 21037 21038File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 21039 2104017.3 Example of 'define_insn' 21041============================= 21042 21043Here is an example of an instruction pattern, taken from the machine 21044description for the 68000/68020. 21045 21046 (define_insn "tstsi" 21047 [(set (cc0) 21048 (match_operand:SI 0 "general_operand" "rm"))] 21049 "" 21050 "* 21051 { 21052 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 21053 return \"tstl %0\"; 21054 return \"cmpl #0,%0\"; 21055 }") 21056 21057This can also be written using braced strings: 21058 21059 (define_insn "tstsi" 21060 [(set (cc0) 21061 (match_operand:SI 0 "general_operand" "rm"))] 21062 "" 21063 { 21064 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 21065 return "tstl %0"; 21066 return "cmpl #0,%0"; 21067 }) 21068 21069 This describes an instruction which sets the condition codes based on 21070the value of a general operand. It has no condition, so any insn with 21071an RTL description of the form shown may be matched to this pattern. 21072The name 'tstsi' means "test a 'SImode' value" and tells the RTL 21073generation pass that, when it is necessary to test such a value, an insn 21074to do so can be constructed using this pattern. 21075 21076 The output control string is a piece of C code which chooses which 21077output template to return based on the kind of operand and the specific 21078type of CPU for which code is being generated. 21079 21080 '"rm"' is an operand constraint. Its meaning is explained below. 21081 21082 21083File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 21084 2108517.4 RTL Template 21086================= 21087 21088The RTL template is used to define which insns match the particular 21089pattern and how to find their operands. For named patterns, the RTL 21090template also says how to construct an insn from specified operands. 21091 21092 Construction involves substituting specified operands into a copy of 21093the template. Matching involves determining the values that serve as 21094the operands in the insn being matched. Both of these activities are 21095controlled by special expression types that direct matching and 21096substitution of the operands. 21097 21098'(match_operand:M N PREDICATE CONSTRAINT)' 21099 This expression is a placeholder for operand number N of the insn. 21100 When constructing an insn, operand number N will be substituted at 21101 this point. When matching an insn, whatever appears at this 21102 position in the insn will be taken as operand number N; but it must 21103 satisfy PREDICATE or this instruction pattern will not match at 21104 all. 21105 21106 Operand numbers must be chosen consecutively counting from zero in 21107 each instruction pattern. There may be only one 'match_operand' 21108 expression in the pattern for each operand number. Usually 21109 operands are numbered in the order of appearance in 'match_operand' 21110 expressions. In the case of a 'define_expand', any operand numbers 21111 used only in 'match_dup' expressions have higher values than all 21112 other operand numbers. 21113 21114 PREDICATE is a string that is the name of a function that accepts 21115 two arguments, an expression and a machine mode. *Note 21116 Predicates::. During matching, the function will be called with 21117 the putative operand as the expression and M as the mode argument 21118 (if M is not specified, 'VOIDmode' will be used, which normally 21119 causes PREDICATE to accept any mode). If it returns zero, this 21120 instruction pattern fails to match. PREDICATE may be an empty 21121 string; then it means no test is to be done on the operand, so 21122 anything which occurs in this position is valid. 21123 21124 Most of the time, PREDICATE will reject modes other than M--but not 21125 always. For example, the predicate 'address_operand' uses M as the 21126 mode of memory ref that the address should be valid for. Many 21127 predicates accept 'const_int' nodes even though their mode is 21128 'VOIDmode'. 21129 21130 CONSTRAINT controls reloading and the choice of the best register 21131 class to use for a value, as explained later (*note Constraints::). 21132 If the constraint would be an empty string, it can be omitted. 21133 21134 People are often unclear on the difference between the constraint 21135 and the predicate. The predicate helps decide whether a given insn 21136 matches the pattern. The constraint plays no role in this 21137 decision; instead, it controls various decisions in the case of an 21138 insn which does match. 21139 21140'(match_scratch:M N CONSTRAINT)' 21141 This expression is also a placeholder for operand number N and 21142 indicates that operand must be a 'scratch' or 'reg' expression. 21143 21144 When matching patterns, this is equivalent to 21145 21146 (match_operand:M N "scratch_operand" CONSTRAINT) 21147 21148 but, when generating RTL, it produces a ('scratch':M) expression. 21149 21150 If the last few expressions in a 'parallel' are 'clobber' 21151 expressions whose operands are either a hard register or 21152 'match_scratch', the combiner can add or delete them when 21153 necessary. *Note Side Effects::. 21154 21155'(match_dup N)' 21156 This expression is also a placeholder for operand number N. It is 21157 used when the operand needs to appear more than once in the insn. 21158 21159 In construction, 'match_dup' acts just like 'match_operand': the 21160 operand is substituted into the insn being constructed. But in 21161 matching, 'match_dup' behaves differently. It assumes that operand 21162 number N has already been determined by a 'match_operand' appearing 21163 earlier in the recognition template, and it matches only an 21164 identical-looking expression. 21165 21166 Note that 'match_dup' should not be used to tell the compiler that 21167 a particular register is being used for two operands (example: 21168 'add' that adds one register to another; the second register is 21169 both an input operand and the output operand). Use a matching 21170 constraint (*note Simple Constraints::) for those. 'match_dup' is 21171 for the cases where one operand is used in two places in the 21172 template, such as an instruction that computes both a quotient and 21173 a remainder, where the opcode takes two input operands but the RTL 21174 template has to refer to each of those twice; once for the quotient 21175 pattern and once for the remainder pattern. 21176 21177'(match_operator:M N PREDICATE [OPERANDS...])' 21178 This pattern is a kind of placeholder for a variable RTL expression 21179 code. 21180 21181 When constructing an insn, it stands for an RTL expression whose 21182 expression code is taken from that of operand N, and whose operands 21183 are constructed from the patterns OPERANDS. 21184 21185 When matching an expression, it matches an expression if the 21186 function PREDICATE returns nonzero on that expression _and_ the 21187 patterns OPERANDS match the operands of the expression. 21188 21189 Suppose that the function 'commutative_operator' is defined as 21190 follows, to match any expression whose operator is one of the 21191 commutative arithmetic operators of RTL and whose mode is MODE: 21192 21193 int 21194 commutative_integer_operator (x, mode) 21195 rtx x; 21196 machine_mode mode; 21197 { 21198 enum rtx_code code = GET_CODE (x); 21199 if (GET_MODE (x) != mode) 21200 return 0; 21201 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 21202 || code == EQ || code == NE); 21203 } 21204 21205 Then the following pattern will match any RTL expression consisting 21206 of a commutative operator applied to two general operands: 21207 21208 (match_operator:SI 3 "commutative_operator" 21209 [(match_operand:SI 1 "general_operand" "g") 21210 (match_operand:SI 2 "general_operand" "g")]) 21211 21212 Here the vector '[OPERANDS...]' contains two patterns because the 21213 expressions to be matched all contain two operands. 21214 21215 When this pattern does match, the two operands of the commutative 21216 operator are recorded as operands 1 and 2 of the insn. (This is 21217 done by the two instances of 'match_operand'.) Operand 3 of the 21218 insn will be the entire commutative expression: use 'GET_CODE 21219 (operands[3])' to see which commutative operator was used. 21220 21221 The machine mode M of 'match_operator' works like that of 21222 'match_operand': it is passed as the second argument to the 21223 predicate function, and that function is solely responsible for 21224 deciding whether the expression to be matched "has" that mode. 21225 21226 When constructing an insn, argument 3 of the gen-function will 21227 specify the operation (i.e. the expression code) for the expression 21228 to be made. It should be an RTL expression, whose expression code 21229 is copied into a new expression whose operands are arguments 1 and 21230 2 of the gen-function. The subexpressions of argument 3 are not 21231 used; only its expression code matters. 21232 21233 When 'match_operator' is used in a pattern for matching an insn, it 21234 usually best if the operand number of the 'match_operator' is 21235 higher than that of the actual operands of the insn. This improves 21236 register allocation because the register allocator often looks at 21237 operands 1 and 2 of insns to see if it can do register tying. 21238 21239 There is no way to specify constraints in 'match_operator'. The 21240 operand of the insn which corresponds to the 'match_operator' never 21241 has any constraints because it is never reloaded as a whole. 21242 However, if parts of its OPERANDS are matched by 'match_operand' 21243 patterns, those parts may have constraints of their own. 21244 21245'(match_op_dup:M N[OPERANDS...])' 21246 Like 'match_dup', except that it applies to operators instead of 21247 operands. When constructing an insn, operand number N will be 21248 substituted at this point. But in matching, 'match_op_dup' behaves 21249 differently. It assumes that operand number N has already been 21250 determined by a 'match_operator' appearing earlier in the 21251 recognition template, and it matches only an identical-looking 21252 expression. 21253 21254'(match_parallel N PREDICATE [SUBPAT...])' 21255 This pattern is a placeholder for an insn that consists of a 21256 'parallel' expression with a variable number of elements. This 21257 expression should only appear at the top level of an insn pattern. 21258 21259 When constructing an insn, operand number N will be substituted at 21260 this point. When matching an insn, it matches if the body of the 21261 insn is a 'parallel' expression with at least as many elements as 21262 the vector of SUBPAT expressions in the 'match_parallel', if each 21263 SUBPAT matches the corresponding element of the 'parallel', _and_ 21264 the function PREDICATE returns nonzero on the 'parallel' that is 21265 the body of the insn. It is the responsibility of the predicate to 21266 validate elements of the 'parallel' beyond those listed in the 21267 'match_parallel'. 21268 21269 A typical use of 'match_parallel' is to match load and store 21270 multiple expressions, which can contain a variable number of 21271 elements in a 'parallel'. For example, 21272 21273 (define_insn "" 21274 [(match_parallel 0 "load_multiple_operation" 21275 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 21276 (match_operand:SI 2 "memory_operand" "m")) 21277 (use (reg:SI 179)) 21278 (clobber (reg:SI 179))])] 21279 "" 21280 "loadm 0,0,%1,%2") 21281 21282 This example comes from 'a29k.md'. The function 21283 'load_multiple_operation' is defined in 'a29k.c' and checks that 21284 subsequent elements in the 'parallel' are the same as the 'set' in 21285 the pattern, except that they are referencing subsequent registers 21286 and memory locations. 21287 21288 An insn that matches this pattern might look like: 21289 21290 (parallel 21291 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 21292 (use (reg:SI 179)) 21293 (clobber (reg:SI 179)) 21294 (set (reg:SI 21) 21295 (mem:SI (plus:SI (reg:SI 100) 21296 (const_int 4)))) 21297 (set (reg:SI 22) 21298 (mem:SI (plus:SI (reg:SI 100) 21299 (const_int 8))))]) 21300 21301'(match_par_dup N [SUBPAT...])' 21302 Like 'match_op_dup', but for 'match_parallel' instead of 21303 'match_operator'. 21304 21305 21306File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 21307 2130817.5 Output Templates and Operand Substitution 21309============================================== 21310 21311The "output template" is a string which specifies how to output the 21312assembler code for an instruction pattern. Most of the template is a 21313fixed string which is output literally. The character '%' is used to 21314specify where to substitute an operand; it can also be used to identify 21315places where different variants of the assembler require different 21316syntax. 21317 21318 In the simplest case, a '%' followed by a digit N says to output 21319operand N at that point in the string. 21320 21321 '%' followed by a letter and a digit says to output an operand in an 21322alternate fashion. Four letters have standard, built-in meanings 21323described below. The machine description macro 'PRINT_OPERAND' can 21324define additional letters with nonstandard meanings. 21325 21326 '%cDIGIT' can be used to substitute an operand that is a constant value 21327without the syntax that normally indicates an immediate operand. 21328 21329 '%nDIGIT' is like '%cDIGIT' except that the value of the constant is 21330negated before printing. 21331 21332 '%aDIGIT' can be used to substitute an operand as if it were a memory 21333reference, with the actual operand treated as the address. This may be 21334useful when outputting a "load address" instruction, because often the 21335assembler syntax for such an instruction requires you to write the 21336operand as if it were a memory reference. 21337 21338 '%lDIGIT' is used to substitute a 'label_ref' into a jump instruction. 21339 21340 '%=' outputs a number which is unique to each instruction in the entire 21341compilation. This is useful for making local labels to be referred to 21342more than once in a single template that generates multiple assembler 21343instructions. 21344 21345 '%' followed by a punctuation character specifies a substitution that 21346does not use an operand. Only one case is standard: '%%' outputs a '%' 21347into the assembler code. Other nonstandard cases can be defined in the 21348'PRINT_OPERAND' macro. You must also define which punctuation 21349characters are valid with the 'PRINT_OPERAND_PUNCT_VALID_P' macro. 21350 21351 The template may generate multiple assembler instructions. Write the 21352text for the instructions, with '\;' between them. 21353 21354 When the RTL contains two operands which are required by constraint to 21355match each other, the output template must refer only to the 21356lower-numbered operand. Matching operands are not always identical, and 21357the rest of the compiler arranges to put the proper RTL expression for 21358printing into the lower-numbered operand. 21359 21360 One use of nonstandard letters or punctuation following '%' is to 21361distinguish between different assembler languages for the same machine; 21362for example, Motorola syntax versus MIT syntax for the 68000. Motorola 21363syntax requires periods in most opcode names, while MIT syntax does not. 21364For example, the opcode 'movel' in MIT syntax is 'move.l' in Motorola 21365syntax. The same file of patterns is used for both kinds of output 21366syntax, but the character sequence '%.' is used in each place where 21367Motorola syntax wants a period. The 'PRINT_OPERAND' macro for Motorola 21368syntax defines the sequence to output a period; the macro for MIT syntax 21369defines it to do nothing. 21370 21371 As a special case, a template consisting of the single character '#' 21372instructs the compiler to first split the insn, and then output the 21373resulting instructions separately. This helps eliminate redundancy in 21374the output templates. If you have a 'define_insn' that needs to emit 21375multiple assembler instructions, and there is a matching 'define_split' 21376already defined, then you can simply use '#' as the output template 21377instead of writing an output template that emits the multiple assembler 21378instructions. 21379 21380 Note that '#' only has an effect while generating assembly code; it 21381does not affect whether a split occurs earlier. An associated 21382'define_split' must exist and it must be suitable for use after register 21383allocation. 21384 21385 If the macro 'ASSEMBLER_DIALECT' is defined, you can use construct of 21386the form '{option0|option1|option2}' in the templates. These describe 21387multiple variants of assembler language syntax. *Note Instruction 21388Output::. 21389 21390 21391File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 21392 2139317.6 C Statements for Assembler Output 21394====================================== 21395 21396Often a single fixed template string cannot produce correct and 21397efficient assembler code for all the cases that are recognized by a 21398single instruction pattern. For example, the opcodes may depend on the 21399kinds of operands; or some unfortunate combinations of operands may 21400require extra machine instructions. 21401 21402 If the output control string starts with a '@', then it is actually a 21403series of templates, each on a separate line. (Blank lines and leading 21404spaces and tabs are ignored.) The templates correspond to the pattern's 21405constraint alternatives (*note Multi-Alternative::). For example, if a 21406target machine has a two-address add instruction 'addr' to add into a 21407register and another 'addm' to add a register to memory, you might write 21408this pattern: 21409 21410 (define_insn "addsi3" 21411 [(set (match_operand:SI 0 "general_operand" "=r,m") 21412 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 21413 (match_operand:SI 2 "general_operand" "g,r")))] 21414 "" 21415 "@ 21416 addr %2,%0 21417 addm %2,%0") 21418 21419 If the output control string starts with a '*', then it is not an 21420output template but rather a piece of C program that should compute a 21421template. It should execute a 'return' statement to return the 21422template-string you want. Most such templates use C string literals, 21423which require doublequote characters to delimit them. To include these 21424doublequote characters in the string, prefix each one with '\'. 21425 21426 If the output control string is written as a brace block instead of a 21427double-quoted string, it is automatically assumed to be C code. In that 21428case, it is not necessary to put in a leading asterisk, or to escape the 21429doublequotes surrounding C string literals. 21430 21431 The operands may be found in the array 'operands', whose C data type is 21432'rtx []'. 21433 21434 It is very common to select different ways of generating assembler code 21435based on whether an immediate operand is within a certain range. Be 21436careful when doing this, because the result of 'INTVAL' is an integer on 21437the host machine. If the host machine has more bits in an 'int' than 21438the target machine has in the mode in which the constant will be used, 21439then some of the bits you get from 'INTVAL' will be superfluous. For 21440proper results, you must carefully disregard the values of those bits. 21441 21442 It is possible to output an assembler instruction and then go on to 21443output or compute more of them, using the subroutine 'output_asm_insn'. 21444This receives two arguments: a template-string and a vector of operands. 21445The vector may be 'operands', or it may be another array of 'rtx' that 21446you declare locally and initialize yourself. 21447 21448 When an insn pattern has multiple alternatives in its constraints, 21449often the appearance of the assembler code is determined mostly by which 21450alternative was matched. When this is so, the C code can test the 21451variable 'which_alternative', which is the ordinal number of the 21452alternative that was actually satisfied (0 for the first, 1 for the 21453second alternative, etc.). 21454 21455 For example, suppose there are two opcodes for storing zero, 'clrreg' 21456for registers and 'clrmem' for memory locations. Here is how a pattern 21457could use 'which_alternative' to choose between them: 21458 21459 (define_insn "" 21460 [(set (match_operand:SI 0 "general_operand" "=r,m") 21461 (const_int 0))] 21462 "" 21463 { 21464 return (which_alternative == 0 21465 ? "clrreg %0" : "clrmem %0"); 21466 }) 21467 21468 The example above, where the assembler code to generate was _solely_ 21469determined by the alternative, could also have been specified as 21470follows, having the output control string start with a '@': 21471 21472 (define_insn "" 21473 [(set (match_operand:SI 0 "general_operand" "=r,m") 21474 (const_int 0))] 21475 "" 21476 "@ 21477 clrreg %0 21478 clrmem %0") 21479 21480 If you just need a little bit of C code in one (or a few) alternatives, 21481you can use '*' inside of a '@' multi-alternative template: 21482 21483 (define_insn "" 21484 [(set (match_operand:SI 0 "general_operand" "=r,<,m") 21485 (const_int 0))] 21486 "" 21487 "@ 21488 clrreg %0 21489 * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\"; 21490 clrmem %0") 21491 21492 21493File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 21494 2149517.7 Predicates 21496=============== 21497 21498A predicate determines whether a 'match_operand' or 'match_operator' 21499expression matches, and therefore whether the surrounding instruction 21500pattern will be used for that combination of operands. GCC has a number 21501of machine-independent predicates, and you can define machine-specific 21502predicates as needed. By convention, predicates used with 21503'match_operand' have names that end in '_operand', and those used with 21504'match_operator' have names that end in '_operator'. 21505 21506 All predicates are boolean functions (in the mathematical sense) of two 21507arguments: the RTL expression that is being considered at that position 21508in the instruction pattern, and the machine mode that the 21509'match_operand' or 'match_operator' specifies. In this section, the 21510first argument is called OP and the second argument MODE. Predicates 21511can be called from C as ordinary two-argument functions; this can be 21512useful in output templates or other machine-specific code. 21513 21514 Operand predicates can allow operands that are not actually acceptable 21515to the hardware, as long as the constraints give reload the ability to 21516fix them up (*note Constraints::). However, GCC will usually generate 21517better code if the predicates specify the requirements of the machine 21518instructions as closely as possible. Reload cannot fix up operands that 21519must be constants ("immediate operands"); you must use a predicate that 21520allows only constants, or else enforce the requirement in the extra 21521condition. 21522 21523 Most predicates handle their MODE argument in a uniform manner. If 21524MODE is 'VOIDmode' (unspecified), then OP can have any mode. If MODE is 21525anything else, then OP must have the same mode, unless OP is a 21526'CONST_INT' or integer 'CONST_DOUBLE'. These RTL expressions always 21527have 'VOIDmode', so it would be counterproductive to check that their 21528mode matches. Instead, predicates that accept 'CONST_INT' and/or 21529integer 'CONST_DOUBLE' check that the value stored in the constant will 21530fit in the requested mode. 21531 21532 Predicates with this behavior are called "normal". 'genrecog' can 21533optimize the instruction recognizer based on knowledge of how normal 21534predicates treat modes. It can also diagnose certain kinds of common 21535errors in the use of normal predicates; for instance, it is almost 21536always an error to use a normal predicate without specifying a mode. 21537 21538 Predicates that do something different with their MODE argument are 21539called "special". The generic predicates 'address_operand' and 21540'pmode_register_operand' are special predicates. 'genrecog' does not do 21541any optimizations or diagnosis when special predicates are used. 21542 21543* Menu: 21544 21545* Machine-Independent Predicates:: Predicates available to all back ends. 21546* Defining Predicates:: How to write machine-specific predicate 21547 functions. 21548 21549 21550File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 21551 2155217.7.1 Machine-Independent Predicates 21553------------------------------------- 21554 21555These are the generic predicates available to all back ends. They are 21556defined in 'recog.c'. The first category of predicates allow only 21557constant, or "immediate", operands. 21558 21559 -- Function: immediate_operand 21560 This predicate allows any sort of constant that fits in MODE. It 21561 is an appropriate choice for instructions that take operands that 21562 must be constant. 21563 21564 -- Function: const_int_operand 21565 This predicate allows any 'CONST_INT' expression that fits in MODE. 21566 It is an appropriate choice for an immediate operand that does not 21567 allow a symbol or label. 21568 21569 -- Function: const_double_operand 21570 This predicate accepts any 'CONST_DOUBLE' expression that has 21571 exactly MODE. If MODE is 'VOIDmode', it will also accept 21572 'CONST_INT'. It is intended for immediate floating point 21573 constants. 21574 21575The second category of predicates allow only some kind of machine 21576register. 21577 21578 -- Function: register_operand 21579 This predicate allows any 'REG' or 'SUBREG' expression that is 21580 valid for MODE. It is often suitable for arithmetic instruction 21581 operands on a RISC machine. 21582 21583 -- Function: pmode_register_operand 21584 This is a slight variant on 'register_operand' which works around a 21585 limitation in the machine-description reader. 21586 21587 (match_operand N "pmode_register_operand" CONSTRAINT) 21588 21589 means exactly what 21590 21591 (match_operand:P N "register_operand" CONSTRAINT) 21592 21593 would mean, if the machine-description reader accepted ':P' mode 21594 suffixes. Unfortunately, it cannot, because 'Pmode' is an alias 21595 for some other mode, and might vary with machine-specific options. 21596 *Note Misc::. 21597 21598 -- Function: scratch_operand 21599 This predicate allows hard registers and 'SCRATCH' expressions, but 21600 not pseudo-registers. It is used internally by 'match_scratch'; it 21601 should not be used directly. 21602 21603The third category of predicates allow only some kind of memory 21604reference. 21605 21606 -- Function: memory_operand 21607 This predicate allows any valid reference to a quantity of mode 21608 MODE in memory, as determined by the weak form of 21609 'GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 21610 21611 -- Function: address_operand 21612 This predicate is a little unusual; it allows any operand that is a 21613 valid expression for the _address_ of a quantity of mode MODE, 21614 again determined by the weak form of 'GO_IF_LEGITIMATE_ADDRESS'. 21615 To first order, if '(mem:MODE (EXP))' is acceptable to 21616 'memory_operand', then EXP is acceptable to 'address_operand'. 21617 Note that EXP does not necessarily have the mode MODE. 21618 21619 -- Function: indirect_operand 21620 This is a stricter form of 'memory_operand' which allows only 21621 memory references with a 'general_operand' as the address 21622 expression. New uses of this predicate are discouraged, because 21623 'general_operand' is very permissive, so it's hard to tell what an 21624 'indirect_operand' does or does not allow. If a target has 21625 different requirements for memory operands for different 21626 instructions, it is better to define target-specific predicates 21627 which enforce the hardware's requirements explicitly. 21628 21629 -- Function: push_operand 21630 This predicate allows a memory reference suitable for pushing a 21631 value onto the stack. This will be a 'MEM' which refers to 21632 'stack_pointer_rtx', with a side effect in its address expression 21633 (*note Incdec::); which one is determined by the 'STACK_PUSH_CODE' 21634 macro (*note Frame Layout::). 21635 21636 -- Function: pop_operand 21637 This predicate allows a memory reference suitable for popping a 21638 value off the stack. Again, this will be a 'MEM' referring to 21639 'stack_pointer_rtx', with a side effect in its address expression. 21640 However, this time 'STACK_POP_CODE' is expected. 21641 21642The fourth category of predicates allow some combination of the above 21643operands. 21644 21645 -- Function: nonmemory_operand 21646 This predicate allows any immediate or register operand valid for 21647 MODE. 21648 21649 -- Function: nonimmediate_operand 21650 This predicate allows any register or memory operand valid for 21651 MODE. 21652 21653 -- Function: general_operand 21654 This predicate allows any immediate, register, or memory operand 21655 valid for MODE. 21656 21657Finally, there are two generic operator predicates. 21658 21659 -- Function: comparison_operator 21660 This predicate matches any expression which performs an arithmetic 21661 comparison in MODE; that is, 'COMPARISON_P' is true for the 21662 expression code. 21663 21664 -- Function: ordered_comparison_operator 21665 This predicate matches any expression which performs an arithmetic 21666 comparison in MODE and whose expression code is valid for integer 21667 modes; that is, the expression code will be one of 'eq', 'ne', 21668 'lt', 'ltu', 'le', 'leu', 'gt', 'gtu', 'ge', 'geu'. 21669 21670 21671File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 21672 2167317.7.2 Defining Machine-Specific Predicates 21674------------------------------------------- 21675 21676Many machines have requirements for their operands that cannot be 21677expressed precisely using the generic predicates. You can define 21678additional predicates using 'define_predicate' and 21679'define_special_predicate' expressions. These expressions have three 21680operands: 21681 21682 * The name of the predicate, as it will be referred to in 21683 'match_operand' or 'match_operator' expressions. 21684 21685 * An RTL expression which evaluates to true if the predicate allows 21686 the operand OP, false if it does not. This expression can only use 21687 the following RTL codes: 21688 21689 'MATCH_OPERAND' 21690 When written inside a predicate expression, a 'MATCH_OPERAND' 21691 expression evaluates to true if the predicate it names would 21692 allow OP. The operand number and constraint are ignored. Due 21693 to limitations in 'genrecog', you can only refer to generic 21694 predicates and predicates that have already been defined. 21695 21696 'MATCH_CODE' 21697 This expression evaluates to true if OP or a specified 21698 subexpression of OP has one of a given list of RTX codes. 21699 21700 The first operand of this expression is a string constant 21701 containing a comma-separated list of RTX code names (in lower 21702 case). These are the codes for which the 'MATCH_CODE' will be 21703 true. 21704 21705 The second operand is a string constant which indicates what 21706 subexpression of OP to examine. If it is absent or the empty 21707 string, OP itself is examined. Otherwise, the string constant 21708 must be a sequence of digits and/or lowercase letters. Each 21709 character indicates a subexpression to extract from the 21710 current expression; for the first character this is OP, for 21711 the second and subsequent characters it is the result of the 21712 previous character. A digit N extracts 'XEXP (E, N)'; a 21713 letter L extracts 'XVECEXP (E, 0, N)' where N is the 21714 alphabetic ordinal of L (0 for 'a', 1 for 'b', and so on). 21715 The 'MATCH_CODE' then examines the RTX code of the 21716 subexpression extracted by the complete string. It is not 21717 possible to extract components of an 'rtvec' that is not at 21718 position 0 within its RTX object. 21719 21720 'MATCH_TEST' 21721 This expression has one operand, a string constant containing 21722 a C expression. The predicate's arguments, OP and MODE, are 21723 available with those names in the C expression. The 21724 'MATCH_TEST' evaluates to true if the C expression evaluates 21725 to a nonzero value. 'MATCH_TEST' expressions must not have 21726 side effects. 21727 21728 'AND' 21729 'IOR' 21730 'NOT' 21731 'IF_THEN_ELSE' 21732 The basic 'MATCH_' expressions can be combined using these 21733 logical operators, which have the semantics of the C operators 21734 '&&', '||', '!', and '? :' respectively. As in Common Lisp, 21735 you may give an 'AND' or 'IOR' expression an arbitrary number 21736 of arguments; this has exactly the same effect as writing a 21737 chain of two-argument 'AND' or 'IOR' expressions. 21738 21739 * An optional block of C code, which should execute 'return true' if 21740 the predicate is found to match and 'return false' if it does not. 21741 It must not have any side effects. The predicate arguments, OP and 21742 MODE, are available with those names. 21743 21744 If a code block is present in a predicate definition, then the RTL 21745 expression must evaluate to true _and_ the code block must execute 21746 'return true' for the predicate to allow the operand. The RTL 21747 expression is evaluated first; do not re-check anything in the code 21748 block that was checked in the RTL expression. 21749 21750 The program 'genrecog' scans 'define_predicate' and 21751'define_special_predicate' expressions to determine which RTX codes are 21752possibly allowed. You should always make this explicit in the RTL 21753predicate expression, using 'MATCH_OPERAND' and 'MATCH_CODE'. 21754 21755 Here is an example of a simple predicate definition, from the IA64 21756machine description: 21757 21758 ;; True if OP is a 'SYMBOL_REF' which refers to the sdata section. 21759 (define_predicate "small_addr_symbolic_operand" 21760 (and (match_code "symbol_ref") 21761 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 21762 21763And here is another, showing the use of the C block. 21764 21765 ;; True if OP is a register operand that is (or could be) a GR reg. 21766 (define_predicate "gr_register_operand" 21767 (match_operand 0 "register_operand") 21768 { 21769 unsigned int regno; 21770 if (GET_CODE (op) == SUBREG) 21771 op = SUBREG_REG (op); 21772 21773 regno = REGNO (op); 21774 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 21775 }) 21776 21777 Predicates written with 'define_predicate' automatically include a test 21778that MODE is 'VOIDmode', or OP has the same mode as MODE, or OP is a 21779'CONST_INT' or 'CONST_DOUBLE'. They do _not_ check specifically for 21780integer 'CONST_DOUBLE', nor do they test that the value of either kind 21781of constant fits in the requested mode. This is because target-specific 21782predicates that take constants usually have to do more stringent value 21783checks anyway. If you need the exact same treatment of 'CONST_INT' or 21784'CONST_DOUBLE' that the generic predicates provide, use a 21785'MATCH_OPERAND' subexpression to call 'const_int_operand', 21786'const_double_operand', or 'immediate_operand'. 21787 21788 Predicates written with 'define_special_predicate' do not get any 21789automatic mode checks, and are treated as having special mode handling 21790by 'genrecog'. 21791 21792 The program 'genpreds' is responsible for generating code to test 21793predicates. It also writes a header file containing function 21794declarations for all machine-specific predicates. It is not necessary 21795to declare these predicates in 'CPU-protos.h'. 21796 21797 21798File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 21799 2180017.8 Operand Constraints 21801======================== 21802 21803Each 'match_operand' in an instruction pattern can specify constraints 21804for the operands allowed. The constraints allow you to fine-tune 21805matching within the set of operands allowed by the predicate. 21806 21807 Constraints can say whether an operand may be in a register, and which 21808kinds of register; whether the operand can be a memory reference, and 21809which kinds of address; whether the operand may be an immediate 21810constant, and which possible values it may have. Constraints can also 21811require two operands to match. Side-effects aren't allowed in operands 21812of inline 'asm', unless '<' or '>' constraints are used, because there 21813is no guarantee that the side effects will happen exactly once in an 21814instruction that can update the addressing register. 21815 21816* Menu: 21817 21818* Simple Constraints:: Basic use of constraints. 21819* Multi-Alternative:: When an insn has two alternative constraint-patterns. 21820* Class Preferences:: Constraints guide which hard register to put things in. 21821* Modifiers:: More precise control over effects of constraints. 21822* Machine Constraints:: Existing constraints for some particular machines. 21823* Disable Insn Alternatives:: Disable insn alternatives using attributes. 21824* Define Constraints:: How to define machine-specific constraints. 21825* C Constraint Interface:: How to test constraints from C code. 21826 21827 21828File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 21829 2183017.8.1 Simple Constraints 21831------------------------- 21832 21833The simplest kind of constraint is a string full of letters, each of 21834which describes one kind of operand that is permitted. Here are the 21835letters that are allowed: 21836 21837whitespace 21838 Whitespace characters are ignored and can be inserted at any 21839 position except the first. This enables each alternative for 21840 different operands to be visually aligned in the machine 21841 description even if they have different number of constraints and 21842 modifiers. 21843 21844'm' 21845 A memory operand is allowed, with any kind of address that the 21846 machine supports in general. Note that the letter used for the 21847 general memory constraint can be re-defined by a back end using the 21848 'TARGET_MEM_CONSTRAINT' macro. 21849 21850'o' 21851 A memory operand is allowed, but only if the address is 21852 "offsettable". This means that adding a small integer (actually, 21853 the width in bytes of the operand, as determined by its machine 21854 mode) may be added to the address and the result is also a valid 21855 memory address. 21856 21857 For example, an address which is constant is offsettable; so is an 21858 address that is the sum of a register and a constant (as long as a 21859 slightly larger constant is also within the range of 21860 address-offsets supported by the machine); but an autoincrement or 21861 autodecrement address is not offsettable. More complicated 21862 indirect/indexed addresses may or may not be offsettable depending 21863 on the other addressing modes that the machine supports. 21864 21865 Note that in an output operand which can be matched by another 21866 operand, the constraint letter 'o' is valid only when accompanied 21867 by both '<' (if the target machine has predecrement addressing) and 21868 '>' (if the target machine has preincrement addressing). 21869 21870'V' 21871 A memory operand that is not offsettable. In other words, anything 21872 that would fit the 'm' constraint but not the 'o' constraint. 21873 21874'<' 21875 A memory operand with autodecrement addressing (either predecrement 21876 or postdecrement) is allowed. In inline 'asm' this constraint is 21877 only allowed if the operand is used exactly once in an instruction 21878 that can handle the side effects. Not using an operand with '<' in 21879 constraint string in the inline 'asm' pattern at all or using it in 21880 multiple instructions isn't valid, because the side effects 21881 wouldn't be performed or would be performed more than once. 21882 Furthermore, on some targets the operand with '<' in constraint 21883 string must be accompanied by special instruction suffixes like 21884 '%U0' instruction suffix on PowerPC or '%P0' on IA-64. 21885 21886'>' 21887 A memory operand with autoincrement addressing (either preincrement 21888 or postincrement) is allowed. In inline 'asm' the same 21889 restrictions as for '<' apply. 21890 21891'r' 21892 A register operand is allowed provided that it is in a general 21893 register. 21894 21895'i' 21896 An immediate integer operand (one with constant value) is allowed. 21897 This includes symbolic constants whose values will be known only at 21898 assembly time or later. 21899 21900'n' 21901 An immediate integer operand with a known numeric value is allowed. 21902 Many systems cannot support assembly-time constants for operands 21903 less than a word wide. Constraints for these operands should use 21904 'n' rather than 'i'. 21905 21906'I', 'J', 'K', ... 'P' 21907 Other letters in the range 'I' through 'P' may be defined in a 21908 machine-dependent fashion to permit immediate integer operands with 21909 explicit integer values in specified ranges. For example, on the 21910 68000, 'I' is defined to stand for the range of values 1 to 8. 21911 This is the range permitted as a shift count in the shift 21912 instructions. 21913 21914'E' 21915 An immediate floating operand (expression code 'const_double') is 21916 allowed, but only if the target floating point format is the same 21917 as that of the host machine (on which the compiler is running). 21918 21919'F' 21920 An immediate floating operand (expression code 'const_double' or 21921 'const_vector') is allowed. 21922 21923'G', 'H' 21924 'G' and 'H' may be defined in a machine-dependent fashion to permit 21925 immediate floating operands in particular ranges of values. 21926 21927's' 21928 An immediate integer operand whose value is not an explicit integer 21929 is allowed. 21930 21931 This might appear strange; if an insn allows a constant operand 21932 with a value not known at compile time, it certainly must allow any 21933 known value. So why use 's' instead of 'i'? Sometimes it allows 21934 better code to be generated. 21935 21936 For example, on the 68000 in a fullword instruction it is possible 21937 to use an immediate operand; but if the immediate value is between 21938 -128 and 127, better code results from loading the value into a 21939 register and using the register. This is because the load into the 21940 register can be done with a 'moveq' instruction. We arrange for 21941 this to happen by defining the letter 'K' to mean "any integer 21942 outside the range -128 to 127", and then specifying 'Ks' in the 21943 operand constraints. 21944 21945'g' 21946 Any register, memory or immediate integer operand is allowed, 21947 except for registers that are not general registers. 21948 21949'X' 21950 Any operand whatsoever is allowed, even if it does not satisfy 21951 'general_operand'. This is normally used in the constraint of a 21952 'match_scratch' when certain alternatives will not actually require 21953 a scratch register. 21954 21955'0', '1', '2', ... '9' 21956 An operand that matches the specified operand number is allowed. 21957 If a digit is used together with letters within the same 21958 alternative, the digit should come last. 21959 21960 This number is allowed to be more than a single digit. If multiple 21961 digits are encountered consecutively, they are interpreted as a 21962 single decimal integer. There is scant chance for ambiguity, since 21963 to-date it has never been desirable that '10' be interpreted as 21964 matching either operand 1 _or_ operand 0. Should this be desired, 21965 one can use multiple alternatives instead. 21966 21967 This is called a "matching constraint" and what it really means is 21968 that the assembler has only a single operand that fills two roles 21969 considered separate in the RTL insn. For example, an add insn has 21970 two input operands and one output operand in the RTL, but on most 21971 CISC machines an add instruction really has only two operands, one 21972 of them an input-output operand: 21973 21974 addl #35,r12 21975 21976 Matching constraints are used in these circumstances. More 21977 precisely, the two operands that match must include one input-only 21978 operand and one output-only operand. Moreover, the digit must be a 21979 smaller number than the number of the operand that uses it in the 21980 constraint. 21981 21982 For operands to match in a particular case usually means that they 21983 are identical-looking RTL expressions. But in a few special cases 21984 specific kinds of dissimilarity are allowed. For example, '*x' as 21985 an input operand will match '*x++' as an output operand. For 21986 proper results in such cases, the output template should always use 21987 the output-operand's number when printing the operand. 21988 21989'p' 21990 An operand that is a valid memory address is allowed. This is for 21991 "load address" and "push address" instructions. 21992 21993 'p' in the constraint must be accompanied by 'address_operand' as 21994 the predicate in the 'match_operand'. This predicate interprets 21995 the mode specified in the 'match_operand' as the mode of the memory 21996 reference for which the address would be valid. 21997 21998OTHER-LETTERS 21999 Other letters can be defined in machine-dependent fashion to stand 22000 for particular classes of registers or other arbitrary operand 22001 types. 'd', 'a' and 'f' are defined on the 68000/68020 to stand 22002 for data, address and floating point registers. 22003 22004 In order to have valid assembler code, each operand must satisfy its 22005constraint. But a failure to do so does not prevent the pattern from 22006applying to an insn. Instead, it directs the compiler to modify the 22007code so that the constraint will be satisfied. Usually this is done by 22008copying an operand into a register. 22009 22010 Contrast, therefore, the two instruction patterns that follow: 22011 22012 (define_insn "" 22013 [(set (match_operand:SI 0 "general_operand" "=r") 22014 (plus:SI (match_dup 0) 22015 (match_operand:SI 1 "general_operand" "r")))] 22016 "" 22017 "...") 22018 22019which has two operands, one of which must appear in two places, and 22020 22021 (define_insn "" 22022 [(set (match_operand:SI 0 "general_operand" "=r") 22023 (plus:SI (match_operand:SI 1 "general_operand" "0") 22024 (match_operand:SI 2 "general_operand" "r")))] 22025 "" 22026 "...") 22027 22028which has three operands, two of which are required by a constraint to 22029be identical. If we are considering an insn of the form 22030 22031 (insn N PREV NEXT 22032 (set (reg:SI 3) 22033 (plus:SI (reg:SI 6) (reg:SI 109))) 22034 ...) 22035 22036the first pattern would not apply at all, because this insn does not 22037contain two identical subexpressions in the right place. The pattern 22038would say, "That does not look like an add instruction; try other 22039patterns". The second pattern would say, "Yes, that's an add 22040instruction, but there is something wrong with it". It would direct the 22041reload pass of the compiler to generate additional insns to make the 22042constraint true. The results might look like this: 22043 22044 (insn N2 PREV N 22045 (set (reg:SI 3) (reg:SI 6)) 22046 ...) 22047 22048 (insn N N2 NEXT 22049 (set (reg:SI 3) 22050 (plus:SI (reg:SI 3) (reg:SI 109))) 22051 ...) 22052 22053 It is up to you to make sure that each operand, in each pattern, has 22054constraints that can handle any RTL expression that could be present for 22055that operand. (When multiple alternatives are in use, each pattern 22056must, for each possible combination of operand expressions, have at 22057least one alternative which can handle that combination of operands.) 22058The constraints don't need to _allow_ any possible operand--when this is 22059the case, they do not constrain--but they must at least point the way to 22060reloading any possible operand so that it will fit. 22061 22062 * If the constraint accepts whatever operands the predicate permits, 22063 there is no problem: reloading is never necessary for this operand. 22064 22065 For example, an operand whose constraints permit everything except 22066 registers is safe provided its predicate rejects registers. 22067 22068 An operand whose predicate accepts only constant values is safe 22069 provided its constraints include the letter 'i'. If any possible 22070 constant value is accepted, then nothing less than 'i' will do; if 22071 the predicate is more selective, then the constraints may also be 22072 more selective. 22073 22074 * Any operand expression can be reloaded by copying it into a 22075 register. So if an operand's constraints allow some kind of 22076 register, it is certain to be safe. It need not permit all classes 22077 of registers; the compiler knows how to copy a register into 22078 another register of the proper class in order to make an 22079 instruction valid. 22080 22081 * A nonoffsettable memory reference can be reloaded by copying the 22082 address into a register. So if the constraint uses the letter 'o', 22083 all memory references are taken care of. 22084 22085 * A constant operand can be reloaded by allocating space in memory to 22086 hold it as preinitialized data. Then the memory reference can be 22087 used in place of the constant. So if the constraint uses the 22088 letters 'o' or 'm', constant operands are not a problem. 22089 22090 * If the constraint permits a constant and a pseudo register used in 22091 an insn was not allocated to a hard register and is equivalent to a 22092 constant, the register will be replaced with the constant. If the 22093 predicate does not permit a constant and the insn is re-recognized 22094 for some reason, the compiler will crash. Thus the predicate must 22095 always recognize any objects allowed by the constraint. 22096 22097 If the operand's predicate can recognize registers, but the constraint 22098does not permit them, it can make the compiler crash. When this operand 22099happens to be a register, the reload pass will be stymied, because it 22100does not know how to copy a register temporarily into memory. 22101 22102 If the predicate accepts a unary operator, the constraint applies to 22103the operand. For example, the MIPS processor at ISA level 3 supports an 22104instruction which adds two registers in 'SImode' to produce a 'DImode' 22105result, but only if the registers are correctly sign extended. This 22106predicate for the input operands accepts a 'sign_extend' of an 'SImode' 22107register. Write the constraint to indicate the type of register that is 22108required for the operand of the 'sign_extend'. 22109 22110 22111File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 22112 2211317.8.2 Multiple Alternative Constraints 22114--------------------------------------- 22115 22116Sometimes a single instruction has multiple alternative sets of possible 22117operands. For example, on the 68000, a logical-or instruction can 22118combine register or an immediate value into memory, or it can combine 22119any kind of operand into a register; but it cannot combine one memory 22120location into another. 22121 22122 These constraints are represented as multiple alternatives. An 22123alternative can be described by a series of letters for each operand. 22124The overall constraint for an operand is made from the letters for this 22125operand from the first alternative, a comma, the letters for this 22126operand from the second alternative, a comma, and so on until the last 22127alternative. All operands for a single instruction must have the same 22128number of alternatives. Here is how it is done for fullword logical-or 22129on the 68000: 22130 22131 (define_insn "iorsi3" 22132 [(set (match_operand:SI 0 "general_operand" "=m,d") 22133 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 22134 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 22135 ...) 22136 22137 The first alternative has 'm' (memory) for operand 0, '0' for operand 1 22138(meaning it must match operand 0), and 'dKs' for operand 2. The second 22139alternative has 'd' (data register) for operand 0, '0' for operand 1, 22140and 'dmKs' for operand 2. The '=' and '%' in the constraints apply to 22141all the alternatives; their meaning is explained in the next section 22142(*note Class Preferences::). 22143 22144 If all the operands fit any one alternative, the instruction is valid. 22145Otherwise, for each alternative, the compiler counts how many 22146instructions must be added to copy the operands so that that alternative 22147applies. The alternative requiring the least copying is chosen. If two 22148alternatives need the same amount of copying, the one that comes first 22149is chosen. These choices can be altered with the '?' and '!' 22150characters: 22151 22152'?' 22153 Disparage slightly the alternative that the '?' appears in, as a 22154 choice when no alternative applies exactly. The compiler regards 22155 this alternative as one unit more costly for each '?' that appears 22156 in it. 22157 22158'!' 22159 Disparage severely the alternative that the '!' appears in. This 22160 alternative can still be used if it fits without reloading, but if 22161 reloading is needed, some other alternative will be used. 22162 22163'^' 22164 This constraint is analogous to '?' but it disparages slightly the 22165 alternative only if the operand with the '^' needs a reload. 22166 22167'$' 22168 This constraint is analogous to '!' but it disparages severely the 22169 alternative only if the operand with the '$' needs a reload. 22170 22171 When an insn pattern has multiple alternatives in its constraints, 22172often the appearance of the assembler code is determined mostly by which 22173alternative was matched. When this is so, the C code for writing the 22174assembler code can use the variable 'which_alternative', which is the 22175ordinal number of the alternative that was actually satisfied (0 for the 22176first, 1 for the second alternative, etc.). *Note Output Statement::. 22177 22178 22179File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 22180 2218117.8.3 Register Class Preferences 22182--------------------------------- 22183 22184The operand constraints have another function: they enable the compiler 22185to decide which kind of hardware register a pseudo register is best 22186allocated to. The compiler examines the constraints that apply to the 22187insns that use the pseudo register, looking for the machine-dependent 22188letters such as 'd' and 'a' that specify classes of registers. The 22189pseudo register is put in whichever class gets the most "votes". The 22190constraint letters 'g' and 'r' also vote: they vote in favor of a 22191general register. The machine description says which registers are 22192considered general. 22193 22194 Of course, on some machines all registers are equivalent, and no 22195register classes are defined. Then none of this complexity is relevant. 22196 22197 22198File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 22199 2220017.8.4 Constraint Modifier Characters 22201------------------------------------- 22202 22203Here are constraint modifier characters. 22204 22205'=' 22206 Means that this operand is written to by this instruction: the 22207 previous value is discarded and replaced by new data. 22208 22209'+' 22210 Means that this operand is both read and written by the 22211 instruction. 22212 22213 When the compiler fixes up the operands to satisfy the constraints, 22214 it needs to know which operands are read by the instruction and 22215 which are written by it. '=' identifies an operand which is only 22216 written; '+' identifies an operand that is both read and written; 22217 all other operands are assumed to only be read. 22218 22219 If you specify '=' or '+' in a constraint, you put it in the first 22220 character of the constraint string. 22221 22222'&' 22223 Means (in a particular alternative) that this operand is an 22224 "earlyclobber" operand, which is written before the instruction is 22225 finished using the input operands. Therefore, this operand may not 22226 lie in a register that is read by the instruction or as part of any 22227 memory address. 22228 22229 '&' applies only to the alternative in which it is written. In 22230 constraints with multiple alternatives, sometimes one alternative 22231 requires '&' while others do not. See, for example, the 'movdf' 22232 insn of the 68000. 22233 22234 A operand which is read by the instruction can be tied to an 22235 earlyclobber operand if its only use as an input occurs before the 22236 early result is written. Adding alternatives of this form often 22237 allows GCC to produce better code when only some of the read 22238 operands can be affected by the earlyclobber. See, for example, 22239 the 'mulsi3' insn of the ARM. 22240 22241 Furthermore, if the "earlyclobber" operand is also a read/write 22242 operand, then that operand is written only after it's used. 22243 22244 '&' does not obviate the need to write '=' or '+'. As 22245 "earlyclobber" operands are always written, a read-only 22246 "earlyclobber" operand is ill-formed and will be rejected by the 22247 compiler. 22248 22249'%' 22250 Declares the instruction to be commutative for this operand and the 22251 following operand. This means that the compiler may interchange 22252 the two operands if that is the cheapest way to make all operands 22253 fit the constraints. '%' applies to all alternatives and must 22254 appear as the first character in the constraint. Only read-only 22255 operands can use '%'. 22256 22257 This is often used in patterns for addition instructions that 22258 really have only two operands: the result must go in one of the 22259 arguments. Here for example, is how the 68000 halfword-add 22260 instruction is defined: 22261 22262 (define_insn "addhi3" 22263 [(set (match_operand:HI 0 "general_operand" "=m,r") 22264 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 22265 (match_operand:HI 2 "general_operand" "di,g")))] 22266 ...) 22267 GCC can only handle one commutative pair in an asm; if you use 22268 more, the compiler may fail. Note that you need not use the 22269 modifier if the two alternatives are strictly identical; this would 22270 only waste time in the reload pass. The modifier is not 22271 operational after register allocation, so the result of 22272 'define_peephole2' and 'define_split's performed after reload 22273 cannot rely on '%' to make the intended insn match. 22274 22275'#' 22276 Says that all following characters, up to the next comma, are to be 22277 ignored as a constraint. They are significant only for choosing 22278 register preferences. 22279 22280'*' 22281 Says that the following character should be ignored when choosing 22282 register preferences. '*' has no effect on the meaning of the 22283 constraint as a constraint, and no effect on reloading. For LRA 22284 '*' additionally disparages slightly the alternative if the 22285 following character matches the operand. 22286 22287 Here is an example: the 68000 has an instruction to sign-extend a 22288 halfword in a data register, and can also sign-extend a value by 22289 copying it into an address register. While either kind of register 22290 is acceptable, the constraints on an address-register destination 22291 are less strict, so it is best if register allocation makes an 22292 address register its goal. Therefore, '*' is used so that the 'd' 22293 constraint letter (for data register) is ignored when computing 22294 register preferences. 22295 22296 (define_insn "extendhisi2" 22297 [(set (match_operand:SI 0 "general_operand" "=*d,a") 22298 (sign_extend:SI 22299 (match_operand:HI 1 "general_operand" "0,g")))] 22300 ...) 22301 22302 22303File: gccint.info, Node: Machine Constraints, Next: Disable Insn Alternatives, Prev: Modifiers, Up: Constraints 22304 2230517.8.5 Constraints for Particular Machines 22306------------------------------------------ 22307 22308Whenever possible, you should use the general-purpose constraint letters 22309in 'asm' arguments, since they will convey meaning more readily to 22310people reading your code. Failing that, use the constraint letters that 22311usually have very similar meanings across architectures. The most 22312commonly used constraints are 'm' and 'r' (for memory and 22313general-purpose registers respectively; *note Simple Constraints::), and 22314'I', usually the letter indicating the most common immediate-constant 22315format. 22316 22317 Each architecture defines additional constraints. These constraints 22318are used by the compiler itself for instruction generation, as well as 22319for 'asm' statements; therefore, some of the constraints are not 22320particularly useful for 'asm'. Here is a summary of some of the 22321machine-dependent constraints available on some particular machines; it 22322includes both constraints that are useful for 'asm' and constraints that 22323aren't. The compiler source file mentioned in the table heading for 22324each architecture is the definitive reference for the meanings of that 22325architecture's constraints. 22326 22327_AArch64 family--'config/aarch64/constraints.md'_ 22328 'k' 22329 The stack pointer register ('SP') 22330 22331 'w' 22332 Floating point register, Advanced SIMD vector register or SVE 22333 vector register 22334 22335 'x' 22336 Like 'w', but restricted to registers 0 to 15 inclusive. 22337 22338 'y' 22339 Like 'w', but restricted to registers 0 to 7 inclusive. 22340 22341 'Upl' 22342 One of the low eight SVE predicate registers ('P0' to 'P7') 22343 22344 'Upa' 22345 Any of the SVE predicate registers ('P0' to 'P15') 22346 22347 'I' 22348 Integer constant that is valid as an immediate operand in an 22349 'ADD' instruction 22350 22351 'J' 22352 Integer constant that is valid as an immediate operand in a 22353 'SUB' instruction (once negated) 22354 22355 'K' 22356 Integer constant that can be used with a 32-bit logical 22357 instruction 22358 22359 'L' 22360 Integer constant that can be used with a 64-bit logical 22361 instruction 22362 22363 'M' 22364 Integer constant that is valid as an immediate operand in a 22365 32-bit 'MOV' pseudo instruction. The 'MOV' may be assembled 22366 to one of several different machine instructions depending on 22367 the value 22368 22369 'N' 22370 Integer constant that is valid as an immediate operand in a 22371 64-bit 'MOV' pseudo instruction 22372 22373 'S' 22374 An absolute symbolic address or a label reference 22375 22376 'Y' 22377 Floating point constant zero 22378 22379 'Z' 22380 Integer constant zero 22381 22382 'Ush' 22383 The high part (bits 12 and upwards) of the pc-relative address 22384 of a symbol within 4GB of the instruction 22385 22386 'Q' 22387 A memory address which uses a single base register with no 22388 offset 22389 22390 'Ump' 22391 A memory address suitable for a load/store pair instruction in 22392 SI, DI, SF and DF modes 22393 22394_AMD GCN --'config/gcn/constraints.md'_ 22395 'I' 22396 Immediate integer in the range -16 to 64 22397 22398 'J' 22399 Immediate 16-bit signed integer 22400 22401 'Kf' 22402 Immediate constant -1 22403 22404 'L' 22405 Immediate 15-bit unsigned integer 22406 22407 'A' 22408 Immediate constant that can be inlined in an instruction 22409 encoding: integer -16..64, or float 0.0, +/-0.5, +/-1.0, 22410 +/-2.0, +/-4.0, 1.0/(2.0*PI) 22411 22412 'B' 22413 Immediate 32-bit signed integer that can be attached to an 22414 instruction encoding 22415 22416 'C' 22417 Immediate 32-bit integer in range -16..4294967295 (i.e. 22418 32-bit unsigned integer or 'A' constraint) 22419 22420 'DA' 22421 Immediate 64-bit constant that can be split into two 'A' 22422 constants 22423 22424 'DB' 22425 Immediate 64-bit constant that can be split into two 'B' 22426 constants 22427 22428 'U' 22429 Any 'unspec' 22430 22431 'Y' 22432 Any 'symbol_ref' or 'label_ref' 22433 22434 'v' 22435 VGPR register 22436 22437 'Sg' 22438 SGPR register 22439 22440 'SD' 22441 SGPR registers valid for instruction destinations, including 22442 VCC, M0 and EXEC 22443 22444 'SS' 22445 SGPR registers valid for instruction sources, including VCC, 22446 M0, EXEC and SCC 22447 22448 'Sm' 22449 SGPR registers valid as a source for scalar memory 22450 instructions (excludes M0 and EXEC) 22451 22452 'Sv' 22453 SGPR registers valid as a source or destination for vector 22454 instructions (excludes EXEC) 22455 22456 'ca' 22457 All condition registers: SCC, VCCZ, EXECZ 22458 22459 'cs' 22460 Scalar condition register: SCC 22461 22462 'cV' 22463 Vector condition register: VCC, VCC_LO, VCC_HI 22464 22465 'e' 22466 EXEC register (EXEC_LO and EXEC_HI) 22467 22468 'RB' 22469 Memory operand with address space suitable for 'buffer_*' 22470 instructions 22471 22472 'RF' 22473 Memory operand with address space suitable for 'flat_*' 22474 instructions 22475 22476 'RS' 22477 Memory operand with address space suitable for 's_*' 22478 instructions 22479 22480 'RL' 22481 Memory operand with address space suitable for 'ds_*' LDS 22482 instructions 22483 22484 'RG' 22485 Memory operand with address space suitable for 'ds_*' GDS 22486 instructions 22487 22488 'RD' 22489 Memory operand with address space suitable for any 'ds_*' 22490 instructions 22491 22492 'RM' 22493 Memory operand with address space suitable for 'global_*' 22494 instructions 22495 22496_ARC --'config/arc/constraints.md'_ 22497 'q' 22498 Registers usable in ARCompact 16-bit instructions: 'r0'-'r3', 22499 'r12'-'r15'. This constraint can only match when the '-mq' 22500 option is in effect. 22501 22502 'e' 22503 Registers usable as base-regs of memory addresses in ARCompact 22504 16-bit memory instructions: 'r0'-'r3', 'r12'-'r15', 'sp'. 22505 This constraint can only match when the '-mq' option is in 22506 effect. 22507 'D' 22508 ARC FPX (dpfp) 64-bit registers. 'D0', 'D1'. 22509 22510 'I' 22511 A signed 12-bit integer constant. 22512 22513 'Cal' 22514 constant for arithmetic/logical operations. This might be any 22515 constant that can be put into a long immediate by the assmbler 22516 or linker without involving a PIC relocation. 22517 22518 'K' 22519 A 3-bit unsigned integer constant. 22520 22521 'L' 22522 A 6-bit unsigned integer constant. 22523 22524 'CnL' 22525 One's complement of a 6-bit unsigned integer constant. 22526 22527 'CmL' 22528 Two's complement of a 6-bit unsigned integer constant. 22529 22530 'M' 22531 A 5-bit unsigned integer constant. 22532 22533 'O' 22534 A 7-bit unsigned integer constant. 22535 22536 'P' 22537 A 8-bit unsigned integer constant. 22538 22539 'H' 22540 Any const_double value. 22541 22542_ARM family--'config/arm/constraints.md'_ 22543 22544 'h' 22545 In Thumb state, the core registers 'r8'-'r15'. 22546 22547 'k' 22548 The stack pointer register. 22549 22550 'l' 22551 In Thumb State the core registers 'r0'-'r7'. In ARM state 22552 this is an alias for the 'r' constraint. 22553 22554 't' 22555 VFP floating-point registers 's0'-'s31'. Used for 32 bit 22556 values. 22557 22558 'w' 22559 VFP floating-point registers 'd0'-'d31' and the appropriate 22560 subset 'd0'-'d15' based on command line options. Used for 64 22561 bit values only. Not valid for Thumb1. 22562 22563 'y' 22564 The iWMMX co-processor registers. 22565 22566 'z' 22567 The iWMMX GR registers. 22568 22569 'G' 22570 The floating-point constant 0.0 22571 22572 'I' 22573 Integer that is valid as an immediate operand in a data 22574 processing instruction. That is, an integer in the range 0 to 22575 255 rotated by a multiple of 2 22576 22577 'J' 22578 Integer in the range -4095 to 4095 22579 22580 'K' 22581 Integer that satisfies constraint 'I' when inverted (ones 22582 complement) 22583 22584 'L' 22585 Integer that satisfies constraint 'I' when negated (twos 22586 complement) 22587 22588 'M' 22589 Integer in the range 0 to 32 22590 22591 'Q' 22592 A memory reference where the exact address is in a single 22593 register (''m'' is preferable for 'asm' statements) 22594 22595 'R' 22596 An item in the constant pool 22597 22598 'S' 22599 A symbol in the text segment of the current file 22600 22601 'Uv' 22602 A memory reference suitable for VFP load/store insns 22603 (reg+constant offset) 22604 22605 'Uy' 22606 A memory reference suitable for iWMMXt load/store 22607 instructions. 22608 22609 'Uq' 22610 A memory reference suitable for the ARMv4 ldrsb instruction. 22611 22612_AVR family--'config/avr/constraints.md'_ 22613 'l' 22614 Registers from r0 to r15 22615 22616 'a' 22617 Registers from r16 to r23 22618 22619 'd' 22620 Registers from r16 to r31 22621 22622 'w' 22623 Registers from r24 to r31. These registers can be used in 22624 'adiw' command 22625 22626 'e' 22627 Pointer register (r26-r31) 22628 22629 'b' 22630 Base pointer register (r28-r31) 22631 22632 'q' 22633 Stack pointer register (SPH:SPL) 22634 22635 't' 22636 Temporary register r0 22637 22638 'x' 22639 Register pair X (r27:r26) 22640 22641 'y' 22642 Register pair Y (r29:r28) 22643 22644 'z' 22645 Register pair Z (r31:r30) 22646 22647 'I' 22648 Constant greater than -1, less than 64 22649 22650 'J' 22651 Constant greater than -64, less than 1 22652 22653 'K' 22654 Constant integer 2 22655 22656 'L' 22657 Constant integer 0 22658 22659 'M' 22660 Constant that fits in 8 bits 22661 22662 'N' 22663 Constant integer -1 22664 22665 'O' 22666 Constant integer 8, 16, or 24 22667 22668 'P' 22669 Constant integer 1 22670 22671 'G' 22672 A floating point constant 0.0 22673 22674 'Q' 22675 A memory address based on Y or Z pointer with displacement. 22676 22677_Blackfin family--'config/bfin/constraints.md'_ 22678 'a' 22679 P register 22680 22681 'd' 22682 D register 22683 22684 'z' 22685 A call clobbered P register. 22686 22687 'qN' 22688 A single register. If N is in the range 0 to 7, the 22689 corresponding D register. If it is 'A', then the register P0. 22690 22691 'D' 22692 Even-numbered D register 22693 22694 'W' 22695 Odd-numbered D register 22696 22697 'e' 22698 Accumulator register. 22699 22700 'A' 22701 Even-numbered accumulator register. 22702 22703 'B' 22704 Odd-numbered accumulator register. 22705 22706 'b' 22707 I register 22708 22709 'v' 22710 B register 22711 22712 'f' 22713 M register 22714 22715 'c' 22716 Registers used for circular buffering, i.e. I, B, or L 22717 registers. 22718 22719 'C' 22720 The CC register. 22721 22722 't' 22723 LT0 or LT1. 22724 22725 'k' 22726 LC0 or LC1. 22727 22728 'u' 22729 LB0 or LB1. 22730 22731 'x' 22732 Any D, P, B, M, I or L register. 22733 22734 'y' 22735 Additional registers typically used only in prologues and 22736 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 22737 USP. 22738 22739 'w' 22740 Any register except accumulators or CC. 22741 22742 'Ksh' 22743 Signed 16 bit integer (in the range -32768 to 32767) 22744 22745 'Kuh' 22746 Unsigned 16 bit integer (in the range 0 to 65535) 22747 22748 'Ks7' 22749 Signed 7 bit integer (in the range -64 to 63) 22750 22751 'Ku7' 22752 Unsigned 7 bit integer (in the range 0 to 127) 22753 22754 'Ku5' 22755 Unsigned 5 bit integer (in the range 0 to 31) 22756 22757 'Ks4' 22758 Signed 4 bit integer (in the range -8 to 7) 22759 22760 'Ks3' 22761 Signed 3 bit integer (in the range -3 to 4) 22762 22763 'Ku3' 22764 Unsigned 3 bit integer (in the range 0 to 7) 22765 22766 'PN' 22767 Constant N, where N is a single-digit constant in the range 0 22768 to 4. 22769 22770 'PA' 22771 An integer equal to one of the MACFLAG_XXX constants that is 22772 suitable for use with either accumulator. 22773 22774 'PB' 22775 An integer equal to one of the MACFLAG_XXX constants that is 22776 suitable for use only with accumulator A1. 22777 22778 'M1' 22779 Constant 255. 22780 22781 'M2' 22782 Constant 65535. 22783 22784 'J' 22785 An integer constant with exactly a single bit set. 22786 22787 'L' 22788 An integer constant with all bits set except exactly one. 22789 22790 'H' 22791 22792 'Q' 22793 Any SYMBOL_REF. 22794 22795_CR16 Architecture--'config/cr16/cr16.h'_ 22796 22797 'b' 22798 Registers from r0 to r14 (registers without stack pointer) 22799 22800 't' 22801 Register from r0 to r11 (all 16-bit registers) 22802 22803 'p' 22804 Register from r12 to r15 (all 32-bit registers) 22805 22806 'I' 22807 Signed constant that fits in 4 bits 22808 22809 'J' 22810 Signed constant that fits in 5 bits 22811 22812 'K' 22813 Signed constant that fits in 6 bits 22814 22815 'L' 22816 Unsigned constant that fits in 4 bits 22817 22818 'M' 22819 Signed constant that fits in 32 bits 22820 22821 'N' 22822 Check for 64 bits wide constants for add/sub instructions 22823 22824 'G' 22825 Floating point constant that is legal for store immediate 22826 22827_C-SKY--'config/csky/constraints.md'_ 22828 22829 'a' 22830 The mini registers r0 - r7. 22831 22832 'b' 22833 The low registers r0 - r15. 22834 22835 'c' 22836 C register. 22837 22838 'y' 22839 HI and LO registers. 22840 22841 'l' 22842 LO register. 22843 22844 'h' 22845 HI register. 22846 22847 'v' 22848 Vector registers. 22849 22850 'z' 22851 Stack pointer register (SP). 22852 22853 The C-SKY back end supports a large set of additional constraints 22854 that are only useful for instruction selection or splitting rather 22855 than inline asm, such as constraints representing constant integer 22856 ranges accepted by particular instruction encodings. Refer to the 22857 source code for details. 22858 22859_Epiphany--'config/epiphany/constraints.md'_ 22860 'U16' 22861 An unsigned 16-bit constant. 22862 22863 'K' 22864 An unsigned 5-bit constant. 22865 22866 'L' 22867 A signed 11-bit constant. 22868 22869 'Cm1' 22870 A signed 11-bit constant added to -1. Can only match when the 22871 '-m1reg-REG' option is active. 22872 22873 'Cl1' 22874 Left-shift of -1, i.e., a bit mask with a block of leading 22875 ones, the rest being a block of trailing zeroes. Can only 22876 match when the '-m1reg-REG' option is active. 22877 22878 'Cr1' 22879 Right-shift of -1, i.e., a bit mask with a trailing block of 22880 ones, the rest being zeroes. Or to put it another way, one 22881 less than a power of two. Can only match when the 22882 '-m1reg-REG' option is active. 22883 22884 'Cal' 22885 Constant for arithmetic/logical operations. This is like 'i', 22886 except that for position independent code, no symbols / 22887 expressions needing relocations are allowed. 22888 22889 'Csy' 22890 Symbolic constant for call/jump instruction. 22891 22892 'Rcs' 22893 The register class usable in short insns. This is a register 22894 class constraint, and can thus drive register allocation. 22895 This constraint won't match unless '-mprefer-short-insn-regs' 22896 is in effect. 22897 22898 'Rsc' 22899 The the register class of registers that can be used to hold a 22900 sibcall call address. I.e., a caller-saved register. 22901 22902 'Rct' 22903 Core control register class. 22904 22905 'Rgs' 22906 The register group usable in short insns. This constraint 22907 does not use a register class, so that it only passively 22908 matches suitable registers, and doesn't drive register 22909 allocation. 22910 22911 'Car' 22912 Constant suitable for the addsi3_r pattern. This is a valid 22913 offset For byte, halfword, or word addressing. 22914 22915 'Rra' 22916 Matches the return address if it can be replaced with the link 22917 register. 22918 22919 'Rcc' 22920 Matches the integer condition code register. 22921 22922 'Sra' 22923 Matches the return address if it is in a stack slot. 22924 22925 'Cfm' 22926 Matches control register values to switch fp mode, which are 22927 encapsulated in 'UNSPEC_FP_MODE'. 22928 22929_FRV--'config/frv/frv.h'_ 22930 'a' 22931 Register in the class 'ACC_REGS' ('acc0' to 'acc7'). 22932 22933 'b' 22934 Register in the class 'EVEN_ACC_REGS' ('acc0' to 'acc7'). 22935 22936 'c' 22937 Register in the class 'CC_REGS' ('fcc0' to 'fcc3' and 'icc0' 22938 to 'icc3'). 22939 22940 'd' 22941 Register in the class 'GPR_REGS' ('gr0' to 'gr63'). 22942 22943 'e' 22944 Register in the class 'EVEN_REGS' ('gr0' to 'gr63'). Odd 22945 registers are excluded not in the class but through the use of 22946 a machine mode larger than 4 bytes. 22947 22948 'f' 22949 Register in the class 'FPR_REGS' ('fr0' to 'fr63'). 22950 22951 'h' 22952 Register in the class 'FEVEN_REGS' ('fr0' to 'fr63'). Odd 22953 registers are excluded not in the class but through the use of 22954 a machine mode larger than 4 bytes. 22955 22956 'l' 22957 Register in the class 'LR_REG' (the 'lr' register). 22958 22959 'q' 22960 Register in the class 'QUAD_REGS' ('gr2' to 'gr63'). Register 22961 numbers not divisible by 4 are excluded not in the class but 22962 through the use of a machine mode larger than 8 bytes. 22963 22964 't' 22965 Register in the class 'ICC_REGS' ('icc0' to 'icc3'). 22966 22967 'u' 22968 Register in the class 'FCC_REGS' ('fcc0' to 'fcc3'). 22969 22970 'v' 22971 Register in the class 'ICR_REGS' ('cc4' to 'cc7'). 22972 22973 'w' 22974 Register in the class 'FCR_REGS' ('cc0' to 'cc3'). 22975 22976 'x' 22977 Register in the class 'QUAD_FPR_REGS' ('fr0' to 'fr63'). 22978 Register numbers not divisible by 4 are excluded not in the 22979 class but through the use of a machine mode larger than 8 22980 bytes. 22981 22982 'z' 22983 Register in the class 'SPR_REGS' ('lcr' and 'lr'). 22984 22985 'A' 22986 Register in the class 'QUAD_ACC_REGS' ('acc0' to 'acc7'). 22987 22988 'B' 22989 Register in the class 'ACCG_REGS' ('accg0' to 'accg7'). 22990 22991 'C' 22992 Register in the class 'CR_REGS' ('cc0' to 'cc7'). 22993 22994 'G' 22995 Floating point constant zero 22996 22997 'I' 22998 6-bit signed integer constant 22999 23000 'J' 23001 10-bit signed integer constant 23002 23003 'L' 23004 16-bit signed integer constant 23005 23006 'M' 23007 16-bit unsigned integer constant 23008 23009 'N' 23010 12-bit signed integer constant that is negative--i.e. in the 23011 range of -2048 to -1 23012 23013 'O' 23014 Constant zero 23015 23016 'P' 23017 12-bit signed integer constant that is greater than zero--i.e. 23018 in the range of 1 to 2047. 23019 23020_FT32--'config/ft32/constraints.md'_ 23021 'A' 23022 An absolute address 23023 23024 'B' 23025 An offset address 23026 23027 'W' 23028 A register indirect memory operand 23029 23030 'e' 23031 An offset address. 23032 23033 'f' 23034 An offset address. 23035 23036 'O' 23037 The constant zero or one 23038 23039 'I' 23040 A 16-bit signed constant (-32768 ... 32767) 23041 23042 'w' 23043 A bitfield mask suitable for bext or bins 23044 23045 'x' 23046 An inverted bitfield mask suitable for bext or bins 23047 23048 'L' 23049 A 16-bit unsigned constant, multiple of 4 (0 ... 65532) 23050 23051 'S' 23052 A 20-bit signed constant (-524288 ... 524287) 23053 23054 'b' 23055 A constant for a bitfield width (1 ... 16) 23056 23057 'KA' 23058 A 10-bit signed constant (-512 ... 511) 23059 23060_Hewlett-Packard PA-RISC--'config/pa/pa.h'_ 23061 'a' 23062 General register 1 23063 23064 'f' 23065 Floating point register 23066 23067 'q' 23068 Shift amount register 23069 23070 'x' 23071 Floating point register (deprecated) 23072 23073 'y' 23074 Upper floating point register (32-bit), floating point 23075 register (64-bit) 23076 23077 'Z' 23078 Any register 23079 23080 'I' 23081 Signed 11-bit integer constant 23082 23083 'J' 23084 Signed 14-bit integer constant 23085 23086 'K' 23087 Integer constant that can be deposited with a 'zdepi' 23088 instruction 23089 23090 'L' 23091 Signed 5-bit integer constant 23092 23093 'M' 23094 Integer constant 0 23095 23096 'N' 23097 Integer constant that can be loaded with a 'ldil' instruction 23098 23099 'O' 23100 Integer constant whose value plus one is a power of 2 23101 23102 'P' 23103 Integer constant that can be used for 'and' operations in 23104 'depi' and 'extru' instructions 23105 23106 'S' 23107 Integer constant 31 23108 23109 'U' 23110 Integer constant 63 23111 23112 'G' 23113 Floating-point constant 0.0 23114 23115 'A' 23116 A 'lo_sum' data-linkage-table memory operand 23117 23118 'Q' 23119 A memory operand that can be used as the destination operand 23120 of an integer store instruction 23121 23122 'R' 23123 A scaled or unscaled indexed memory operand 23124 23125 'T' 23126 A memory operand for floating-point loads and stores 23127 23128 'W' 23129 A register indirect memory operand 23130 23131_Intel IA-64--'config/ia64/ia64.h'_ 23132 'a' 23133 General register 'r0' to 'r3' for 'addl' instruction 23134 23135 'b' 23136 Branch register 23137 23138 'c' 23139 Predicate register ('c' as in "conditional") 23140 23141 'd' 23142 Application register residing in M-unit 23143 23144 'e' 23145 Application register residing in I-unit 23146 23147 'f' 23148 Floating-point register 23149 23150 'm' 23151 Memory operand. If used together with '<' or '>', the operand 23152 can have postincrement and postdecrement which require 23153 printing with '%Pn' on IA-64. 23154 23155 'G' 23156 Floating-point constant 0.0 or 1.0 23157 23158 'I' 23159 14-bit signed integer constant 23160 23161 'J' 23162 22-bit signed integer constant 23163 23164 'K' 23165 8-bit signed integer constant for logical instructions 23166 23167 'L' 23168 8-bit adjusted signed integer constant for compare pseudo-ops 23169 23170 'M' 23171 6-bit unsigned integer constant for shift counts 23172 23173 'N' 23174 9-bit signed integer constant for load and store 23175 postincrements 23176 23177 'O' 23178 The constant zero 23179 23180 'P' 23181 0 or -1 for 'dep' instruction 23182 23183 'Q' 23184 Non-volatile memory for floating-point loads and stores 23185 23186 'R' 23187 Integer constant in the range 1 to 4 for 'shladd' instruction 23188 23189 'S' 23190 Memory operand except postincrement and postdecrement. This 23191 is now roughly the same as 'm' when not used together with '<' 23192 or '>'. 23193 23194_M32C--'config/m32c/m32c.c'_ 23195 'Rsp' 23196 'Rfb' 23197 'Rsb' 23198 '$sp', '$fb', '$sb'. 23199 23200 'Rcr' 23201 Any control register, when they're 16 bits wide (nothing if 23202 control registers are 24 bits wide) 23203 23204 'Rcl' 23205 Any control register, when they're 24 bits wide. 23206 23207 'R0w' 23208 'R1w' 23209 'R2w' 23210 'R3w' 23211 $r0, $r1, $r2, $r3. 23212 23213 'R02' 23214 $r0 or $r2, or $r2r0 for 32 bit values. 23215 23216 'R13' 23217 $r1 or $r3, or $r3r1 for 32 bit values. 23218 23219 'Rdi' 23220 A register that can hold a 64 bit value. 23221 23222 'Rhl' 23223 $r0 or $r1 (registers with addressable high/low bytes) 23224 23225 'R23' 23226 $r2 or $r3 23227 23228 'Raa' 23229 Address registers 23230 23231 'Raw' 23232 Address registers when they're 16 bits wide. 23233 23234 'Ral' 23235 Address registers when they're 24 bits wide. 23236 23237 'Rqi' 23238 Registers that can hold QI values. 23239 23240 'Rad' 23241 Registers that can be used with displacements ($a0, $a1, $sb). 23242 23243 'Rsi' 23244 Registers that can hold 32 bit values. 23245 23246 'Rhi' 23247 Registers that can hold 16 bit values. 23248 23249 'Rhc' 23250 Registers chat can hold 16 bit values, including all control 23251 registers. 23252 23253 'Rra' 23254 $r0 through R1, plus $a0 and $a1. 23255 23256 'Rfl' 23257 The flags register. 23258 23259 'Rmm' 23260 The memory-based pseudo-registers $mem0 through $mem15. 23261 23262 'Rpi' 23263 Registers that can hold pointers (16 bit registers for r8c, 23264 m16c; 24 bit registers for m32cm, m32c). 23265 23266 'Rpa' 23267 Matches multiple registers in a PARALLEL to form a larger 23268 register. Used to match function return values. 23269 23270 'Is3' 23271 -8 ... 7 23272 23273 'IS1' 23274 -128 ... 127 23275 23276 'IS2' 23277 -32768 ... 32767 23278 23279 'IU2' 23280 0 ... 65535 23281 23282 'In4' 23283 -8 ... -1 or 1 ... 8 23284 23285 'In5' 23286 -16 ... -1 or 1 ... 16 23287 23288 'In6' 23289 -32 ... -1 or 1 ... 32 23290 23291 'IM2' 23292 -65536 ... -1 23293 23294 'Ilb' 23295 An 8 bit value with exactly one bit set. 23296 23297 'Ilw' 23298 A 16 bit value with exactly one bit set. 23299 23300 'Sd' 23301 The common src/dest memory addressing modes. 23302 23303 'Sa' 23304 Memory addressed using $a0 or $a1. 23305 23306 'Si' 23307 Memory addressed with immediate addresses. 23308 23309 'Ss' 23310 Memory addressed using the stack pointer ($sp). 23311 23312 'Sf' 23313 Memory addressed using the frame base register ($fb). 23314 23315 'Ss' 23316 Memory addressed using the small base register ($sb). 23317 23318 'S1' 23319 $r1h 23320 23321_MicroBlaze--'config/microblaze/constraints.md'_ 23322 'd' 23323 A general register ('r0' to 'r31'). 23324 23325 'z' 23326 A status register ('rmsr', '$fcc1' to '$fcc7'). 23327 23328_MIPS--'config/mips/constraints.md'_ 23329 'd' 23330 A general-purpose register. This is equivalent to 'r' unless 23331 generating MIPS16 code, in which case the MIPS16 register set 23332 is used. 23333 23334 'f' 23335 A floating-point register (if available). 23336 23337 'h' 23338 Formerly the 'hi' register. This constraint is no longer 23339 supported. 23340 23341 'l' 23342 The 'lo' register. Use this register to store values that are 23343 no bigger than a word. 23344 23345 'x' 23346 The concatenated 'hi' and 'lo' registers. Use this register 23347 to store doubleword values. 23348 23349 'c' 23350 A register suitable for use in an indirect jump. This will 23351 always be '$25' for '-mabicalls'. 23352 23353 'v' 23354 Register '$3'. Do not use this constraint in new code; it is 23355 retained only for compatibility with glibc. 23356 23357 'y' 23358 Equivalent to 'r'; retained for backwards compatibility. 23359 23360 'z' 23361 A floating-point condition code register. 23362 23363 'I' 23364 A signed 16-bit constant (for arithmetic instructions). 23365 23366 'J' 23367 Integer zero. 23368 23369 'K' 23370 An unsigned 16-bit constant (for logic instructions). 23371 23372 'L' 23373 A signed 32-bit constant in which the lower 16 bits are zero. 23374 Such constants can be loaded using 'lui'. 23375 23376 'M' 23377 A constant that cannot be loaded using 'lui', 'addiu' or 23378 'ori'. 23379 23380 'N' 23381 A constant in the range -65535 to -1 (inclusive). 23382 23383 'O' 23384 A signed 15-bit constant. 23385 23386 'P' 23387 A constant in the range 1 to 65535 (inclusive). 23388 23389 'G' 23390 Floating-point zero. 23391 23392 'R' 23393 An address that can be used in a non-macro load or store. 23394 23395 'ZC' 23396 A memory operand whose address is formed by a base register 23397 and offset that is suitable for use in instructions with the 23398 same addressing mode as 'll' and 'sc'. 23399 23400 'ZD' 23401 An address suitable for a 'prefetch' instruction, or for any 23402 other instruction with the same addressing mode as 'prefetch'. 23403 23404_Motorola 680x0--'config/m68k/constraints.md'_ 23405 'a' 23406 Address register 23407 23408 'd' 23409 Data register 23410 23411 'f' 23412 68881 floating-point register, if available 23413 23414 'I' 23415 Integer in the range 1 to 8 23416 23417 'J' 23418 16-bit signed number 23419 23420 'K' 23421 Signed number whose magnitude is greater than 0x80 23422 23423 'L' 23424 Integer in the range -8 to -1 23425 23426 'M' 23427 Signed number whose magnitude is greater than 0x100 23428 23429 'N' 23430 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 23431 23432 'O' 23433 16 (for rotate using swap) 23434 23435 'P' 23436 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 23437 23438 'R' 23439 Numbers that mov3q can handle 23440 23441 'G' 23442 Floating point constant that is not a 68881 constant 23443 23444 'S' 23445 Operands that satisfy 'm' when -mpcrel is in effect 23446 23447 'T' 23448 Operands that satisfy 's' when -mpcrel is not in effect 23449 23450 'Q' 23451 Address register indirect addressing mode 23452 23453 'U' 23454 Register offset addressing 23455 23456 'W' 23457 const_call_operand 23458 23459 'Cs' 23460 symbol_ref or const 23461 23462 'Ci' 23463 const_int 23464 23465 'C0' 23466 const_int 0 23467 23468 'Cj' 23469 Range of signed numbers that don't fit in 16 bits 23470 23471 'Cmvq' 23472 Integers valid for mvq 23473 23474 'Capsw' 23475 Integers valid for a moveq followed by a swap 23476 23477 'Cmvz' 23478 Integers valid for mvz 23479 23480 'Cmvs' 23481 Integers valid for mvs 23482 23483 'Ap' 23484 push_operand 23485 23486 'Ac' 23487 Non-register operands allowed in clr 23488 23489_Moxie--'config/moxie/constraints.md'_ 23490 'A' 23491 An absolute address 23492 23493 'B' 23494 An offset address 23495 23496 'W' 23497 A register indirect memory operand 23498 23499 'I' 23500 A constant in the range of 0 to 255. 23501 23502 'N' 23503 A constant in the range of 0 to -255. 23504 23505_MSP430-'config/msp430/constraints.md'_ 23506 23507 'R12' 23508 Register R12. 23509 23510 'R13' 23511 Register R13. 23512 23513 'K' 23514 Integer constant 1. 23515 23516 'L' 23517 Integer constant -1^20..1^19. 23518 23519 'M' 23520 Integer constant 1-4. 23521 23522 'Ya' 23523 Memory references which do not require an extended MOVX 23524 instruction. 23525 23526 'Yl' 23527 Memory reference, labels only. 23528 23529 'Ys' 23530 Memory reference, stack only. 23531 23532_NDS32--'config/nds32/constraints.md'_ 23533 'w' 23534 LOW register class $r0 to $r7 constraint for V3/V3M ISA. 23535 'l' 23536 LOW register class $r0 to $r7. 23537 'd' 23538 MIDDLE register class $r0 to $r11, $r16 to $r19. 23539 'h' 23540 HIGH register class $r12 to $r14, $r20 to $r31. 23541 't' 23542 Temporary assist register $ta (i.e. $r15). 23543 'k' 23544 Stack register $sp. 23545 'Iu03' 23546 Unsigned immediate 3-bit value. 23547 'In03' 23548 Negative immediate 3-bit value in the range of -7-0. 23549 'Iu04' 23550 Unsigned immediate 4-bit value. 23551 'Is05' 23552 Signed immediate 5-bit value. 23553 'Iu05' 23554 Unsigned immediate 5-bit value. 23555 'In05' 23556 Negative immediate 5-bit value in the range of -31-0. 23557 'Ip05' 23558 Unsigned immediate 5-bit value for movpi45 instruction with 23559 range 16-47. 23560 'Iu06' 23561 Unsigned immediate 6-bit value constraint for addri36.sp 23562 instruction. 23563 'Iu08' 23564 Unsigned immediate 8-bit value. 23565 'Iu09' 23566 Unsigned immediate 9-bit value. 23567 'Is10' 23568 Signed immediate 10-bit value. 23569 'Is11' 23570 Signed immediate 11-bit value. 23571 'Is15' 23572 Signed immediate 15-bit value. 23573 'Iu15' 23574 Unsigned immediate 15-bit value. 23575 'Ic15' 23576 A constant which is not in the range of imm15u but ok for bclr 23577 instruction. 23578 'Ie15' 23579 A constant which is not in the range of imm15u but ok for bset 23580 instruction. 23581 'It15' 23582 A constant which is not in the range of imm15u but ok for btgl 23583 instruction. 23584 'Ii15' 23585 A constant whose compliment value is in the range of imm15u 23586 and ok for bitci instruction. 23587 'Is16' 23588 Signed immediate 16-bit value. 23589 'Is17' 23590 Signed immediate 17-bit value. 23591 'Is19' 23592 Signed immediate 19-bit value. 23593 'Is20' 23594 Signed immediate 20-bit value. 23595 'Ihig' 23596 The immediate value that can be simply set high 20-bit. 23597 'Izeb' 23598 The immediate value 0xff. 23599 'Izeh' 23600 The immediate value 0xffff. 23601 'Ixls' 23602 The immediate value 0x01. 23603 'Ix11' 23604 The immediate value 0x7ff. 23605 'Ibms' 23606 The immediate value with power of 2. 23607 'Ifex' 23608 The immediate value with power of 2 minus 1. 23609 'U33' 23610 Memory constraint for 333 format. 23611 'U45' 23612 Memory constraint for 45 format. 23613 'U37' 23614 Memory constraint for 37 format. 23615 23616_Nios II family--'config/nios2/constraints.md'_ 23617 23618 'I' 23619 Integer that is valid as an immediate operand in an 23620 instruction taking a signed 16-bit number. Range -32768 to 23621 32767. 23622 23623 'J' 23624 Integer that is valid as an immediate operand in an 23625 instruction taking an unsigned 16-bit number. Range 0 to 23626 65535. 23627 23628 'K' 23629 Integer that is valid as an immediate operand in an 23630 instruction taking only the upper 16-bits of a 32-bit number. 23631 Range 32-bit numbers with the lower 16-bits being 0. 23632 23633 'L' 23634 Integer that is valid as an immediate operand for a shift 23635 instruction. Range 0 to 31. 23636 23637 'M' 23638 Integer that is valid as an immediate operand for only the 23639 value 0. Can be used in conjunction with the format modifier 23640 'z' to use 'r0' instead of '0' in the assembly output. 23641 23642 'N' 23643 Integer that is valid as an immediate operand for a custom 23644 instruction opcode. Range 0 to 255. 23645 23646 'P' 23647 An immediate operand for R2 andchi/andci instructions. 23648 23649 'S' 23650 Matches immediates which are addresses in the small data 23651 section and therefore can be added to 'gp' as a 16-bit 23652 immediate to re-create their 32-bit value. 23653 23654 'U' 23655 Matches constants suitable as an operand for the rdprs and 23656 cache instructions. 23657 23658 'v' 23659 A memory operand suitable for Nios II R2 load/store exclusive 23660 instructions. 23661 23662 'w' 23663 A memory operand suitable for load/store IO and cache 23664 instructions. 23665 23666 'T' 23667 A 'const' wrapped 'UNSPEC' expression, representing a 23668 supported PIC or TLS relocation. 23669 23670_OpenRISC--'config/or1k/constraints.md'_ 23671 'I' 23672 Integer that is valid as an immediate operand in an 23673 instruction taking a signed 16-bit number. Range -32768 to 23674 32767. 23675 23676 'K' 23677 Integer that is valid as an immediate operand in an 23678 instruction taking an unsigned 16-bit number. Range 0 to 23679 65535. 23680 23681 'M' 23682 Signed 16-bit constant shifted left 16 bits. (Used with 23683 'l.movhi') 23684 23685 'O' 23686 Zero 23687 23688 'c' 23689 Register usable for sibcalls. 23690 23691_PDP-11--'config/pdp11/constraints.md'_ 23692 'a' 23693 Floating point registers AC0 through AC3. These can be loaded 23694 from/to memory with a single instruction. 23695 23696 'd' 23697 Odd numbered general registers (R1, R3, R5). These are used 23698 for 16-bit multiply operations. 23699 23700 'D' 23701 A memory reference that is encoded within the opcode, but not 23702 auto-increment or auto-decrement. 23703 23704 'f' 23705 Any of the floating point registers (AC0 through AC5). 23706 23707 'G' 23708 Floating point constant 0. 23709 23710 'h' 23711 Floating point registers AC4 and AC5. These cannot be loaded 23712 from/to memory with a single instruction. 23713 23714 'I' 23715 An integer constant that fits in 16 bits. 23716 23717 'J' 23718 An integer constant whose low order 16 bits are zero. 23719 23720 'K' 23721 An integer constant that does not meet the constraints for 23722 codes 'I' or 'J'. 23723 23724 'L' 23725 The integer constant 1. 23726 23727 'M' 23728 The integer constant -1. 23729 23730 'N' 23731 The integer constant 0. 23732 23733 'O' 23734 Integer constants 0 through 3; shifts by these amounts are 23735 handled as multiple single-bit shifts rather than a single 23736 variable-length shift. 23737 23738 'Q' 23739 A memory reference which requires an additional word (address 23740 or offset) after the opcode. 23741 23742 'R' 23743 A memory reference that is encoded within the opcode. 23744 23745_PowerPC and IBM RS6000--'config/rs6000/constraints.md'_ 23746 'r' 23747 A general purpose register (GPR), 'r0'...'r31'. 23748 23749 'b' 23750 A base register. Like 'r', but 'r0' is not allowed, so 23751 'r1'...'r31'. 23752 23753 'f' 23754 A floating point register (FPR), 'f0'...'f31'. 23755 23756 'd' 23757 A floating point register. This is the same as 'f' nowadays; 23758 historically 'f' was for single-precision and 'd' was for 23759 double-precision floating point. 23760 23761 'v' 23762 An Altivec vector register (VR), 'v0'...'v31'. 23763 23764 'wa' 23765 A VSX register (VSR), 'vs0'...'vs63'. This is either an FPR 23766 ('vs0'...'vs31' are 'f0'...'f31') or a VR ('vs32'...'vs63' are 23767 'v0'...'v31'). 23768 23769 When using 'wa', you should use the '%x' output modifier, so 23770 that the correct register number is printed. For example: 23771 23772 asm ("xvadddp %x0,%x1,%x2" 23773 : "=wa" (v1) 23774 : "wa" (v2), "wa" (v3)); 23775 23776 You should not use '%x' for 'v' operands: 23777 23778 asm ("xsaddqp %0,%1,%2" 23779 : "=v" (v1) 23780 : "v" (v2), "v" (v3)); 23781 23782 'h' 23783 A special register ('vrsave', 'ctr', or 'lr'). 23784 23785 'c' 23786 The count register, 'ctr'. 23787 23788 'l' 23789 The link register, 'lr'. 23790 23791 'x' 23792 Condition register field 0, 'cr0'. 23793 23794 'y' 23795 Any condition register field, 'cr0'...'cr7'. 23796 23797 'z' 23798 The carry bit, 'XER[CA]'. 23799 23800 'we' 23801 Like 'wa', if '-mpower9-vector' and '-m64' are used; 23802 otherwise, 'NO_REGS'. 23803 23804 'wn' 23805 No register ('NO_REGS'). 23806 23807 'wr' 23808 Like 'r', if '-mpowerpc64' is used; otherwise, 'NO_REGS'. 23809 23810 'wx' 23811 Like 'd', if '-mpowerpc-gfxopt' is used; otherwise, 'NO_REGS'. 23812 23813 'wA' 23814 Like 'b', if '-mpowerpc64' is used; otherwise, 'NO_REGS'. 23815 23816 'wB' 23817 Signed 5-bit constant integer that can be loaded into an 23818 Altivec register. 23819 23820 'wD' 23821 Int constant that is the element number of the 64-bit scalar 23822 in a vector. 23823 23824 'wE' 23825 Vector constant that can be loaded with the XXSPLTIB 23826 instruction. 23827 23828 'wF' 23829 Memory operand suitable for power8 GPR load fusion. 23830 23831 'wL' 23832 Int constant that is the element number mfvsrld accesses in a 23833 vector. 23834 23835 'wM' 23836 Match vector constant with all 1's if the XXLORC instruction 23837 is available. 23838 23839 'wO' 23840 Memory operand suitable for the ISA 3.0 vector d-form 23841 instructions. 23842 23843 'wQ' 23844 Memory operand suitable for the load/store quad instructions. 23845 23846 'wS' 23847 Vector constant that can be loaded with XXSPLTIB & sign 23848 extension. 23849 23850 'wY' 23851 A memory operand for a DS-form instruction. 23852 23853 'wZ' 23854 An indexed or indirect memory operand, ignoring the bottom 4 23855 bits. 23856 23857 'I' 23858 A signed 16-bit constant. 23859 23860 'J' 23861 An unsigned 16-bit constant shifted left 16 bits (use 'L' 23862 instead for 'SImode' constants). 23863 23864 'K' 23865 An unsigned 16-bit constant. 23866 23867 'L' 23868 A signed 16-bit constant shifted left 16 bits. 23869 23870 'M' 23871 An integer constant greater than 31. 23872 23873 'N' 23874 An exact power of 2. 23875 23876 'O' 23877 The integer constant zero. 23878 23879 'P' 23880 A constant whose negation is a signed 16-bit constant. 23881 23882 'eI' 23883 A signed 34-bit integer constant if prefixed instructions are 23884 supported. 23885 23886 'G' 23887 A floating point constant that can be loaded into a register 23888 with one instruction per word. 23889 23890 'H' 23891 A floating point constant that can be loaded into a register 23892 using three instructions. 23893 23894 'm' 23895 A memory operand. Normally, 'm' does not allow addresses that 23896 update the base register. If the '<' or '>' constraint is 23897 also used, they are allowed and therefore on PowerPC targets 23898 in that case it is only safe to use 'm<>' in an 'asm' 23899 statement if that 'asm' statement accesses the operand exactly 23900 once. The 'asm' statement must also use '%U<OPNO>' as a 23901 placeholder for the "update" flag in the corresponding load or 23902 store instruction. For example: 23903 23904 asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); 23905 23906 is correct but: 23907 23908 asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); 23909 23910 is not. 23911 23912 'es' 23913 A "stable" memory operand; that is, one which does not include 23914 any automodification of the base register. This used to be 23915 useful when 'm' allowed automodification of the base register, 23916 but as those are now only allowed when '<' or '>' is used, 23917 'es' is basically the same as 'm' without '<' and '>'. 23918 23919 'Q' 23920 A memory operand addressed by just a base register. 23921 23922 'Y' 23923 A memory operand for a DQ-form instruction. 23924 23925 'Z' 23926 A memory operand accessed with indexed or indirect addressing. 23927 23928 'R' 23929 An AIX TOC entry. 23930 23931 'a' 23932 An indexed or indirect address. 23933 23934 'U' 23935 A V.4 small data reference. 23936 23937 'W' 23938 A vector constant that does not require memory. 23939 23940 'j' 23941 The zero vector constant. 23942 23943_PRU--'config/pru/constraints.md'_ 23944 'I' 23945 An unsigned 8-bit integer constant. 23946 23947 'J' 23948 An unsigned 16-bit integer constant. 23949 23950 'L' 23951 An unsigned 5-bit integer constant (for shift counts). 23952 23953 'T' 23954 A text segment (program memory) constant label. 23955 23956 'Z' 23957 Integer constant zero. 23958 23959_RL78--'config/rl78/constraints.md'_ 23960 23961 'Int3' 23962 An integer constant in the range 1 ... 7. 23963 'Int8' 23964 An integer constant in the range 0 ... 255. 23965 'J' 23966 An integer constant in the range -255 ... 0 23967 'K' 23968 The integer constant 1. 23969 'L' 23970 The integer constant -1. 23971 'M' 23972 The integer constant 0. 23973 'N' 23974 The integer constant 2. 23975 'O' 23976 The integer constant -2. 23977 'P' 23978 An integer constant in the range 1 ... 15. 23979 'Qbi' 23980 The built-in compare types-eq, ne, gtu, ltu, geu, and leu. 23981 'Qsc' 23982 The synthetic compare types-gt, lt, ge, and le. 23983 'Wab' 23984 A memory reference with an absolute address. 23985 'Wbc' 23986 A memory reference using 'BC' as a base register, with an 23987 optional offset. 23988 'Wca' 23989 A memory reference using 'AX', 'BC', 'DE', or 'HL' for the 23990 address, for calls. 23991 'Wcv' 23992 A memory reference using any 16-bit register pair for the 23993 address, for calls. 23994 'Wd2' 23995 A memory reference using 'DE' as a base register, with an 23996 optional offset. 23997 'Wde' 23998 A memory reference using 'DE' as a base register, without any 23999 offset. 24000 'Wfr' 24001 Any memory reference to an address in the far address space. 24002 'Wh1' 24003 A memory reference using 'HL' as a base register, with an 24004 optional one-byte offset. 24005 'Whb' 24006 A memory reference using 'HL' as a base register, with 'B' or 24007 'C' as the index register. 24008 'Whl' 24009 A memory reference using 'HL' as a base register, without any 24010 offset. 24011 'Ws1' 24012 A memory reference using 'SP' as a base register, with an 24013 optional one-byte offset. 24014 'Y' 24015 Any memory reference to an address in the near address space. 24016 'A' 24017 The 'AX' register. 24018 'B' 24019 The 'BC' register. 24020 'D' 24021 The 'DE' register. 24022 'R' 24023 'A' through 'L' registers. 24024 'S' 24025 The 'SP' register. 24026 'T' 24027 The 'HL' register. 24028 'Z08W' 24029 The 16-bit 'R8' register. 24030 'Z10W' 24031 The 16-bit 'R10' register. 24032 'Zint' 24033 The registers reserved for interrupts ('R24' to 'R31'). 24034 'a' 24035 The 'A' register. 24036 'b' 24037 The 'B' register. 24038 'c' 24039 The 'C' register. 24040 'd' 24041 The 'D' register. 24042 'e' 24043 The 'E' register. 24044 'h' 24045 The 'H' register. 24046 'l' 24047 The 'L' register. 24048 'v' 24049 The virtual registers. 24050 'w' 24051 The 'PSW' register. 24052 'x' 24053 The 'X' register. 24054 24055_RISC-V--'config/riscv/constraints.md'_ 24056 24057 'f' 24058 A floating-point register (if available). 24059 24060 'I' 24061 An I-type 12-bit signed immediate. 24062 24063 'J' 24064 Integer zero. 24065 24066 'K' 24067 A 5-bit unsigned immediate for CSR access instructions. 24068 24069 'A' 24070 An address that is held in a general-purpose register. 24071 24072_RX--'config/rx/constraints.md'_ 24073 'Q' 24074 An address which does not involve register indirect addressing 24075 or pre/post increment/decrement addressing. 24076 24077 'Symbol' 24078 A symbol reference. 24079 24080 'Int08' 24081 A constant in the range -256 to 255, inclusive. 24082 24083 'Sint08' 24084 A constant in the range -128 to 127, inclusive. 24085 24086 'Sint16' 24087 A constant in the range -32768 to 32767, inclusive. 24088 24089 'Sint24' 24090 A constant in the range -8388608 to 8388607, inclusive. 24091 24092 'Uint04' 24093 A constant in the range 0 to 15, inclusive. 24094 24095_S/390 and zSeries--'config/s390/s390.h'_ 24096 'a' 24097 Address register (general purpose register except r0) 24098 24099 'c' 24100 Condition code register 24101 24102 'd' 24103 Data register (arbitrary general purpose register) 24104 24105 'f' 24106 Floating-point register 24107 24108 'I' 24109 Unsigned 8-bit constant (0-255) 24110 24111 'J' 24112 Unsigned 12-bit constant (0-4095) 24113 24114 'K' 24115 Signed 16-bit constant (-32768-32767) 24116 24117 'L' 24118 Value appropriate as displacement. 24119 '(0..4095)' 24120 for short displacement 24121 '(-524288..524287)' 24122 for long displacement 24123 24124 'M' 24125 Constant integer with a value of 0x7fffffff. 24126 24127 'N' 24128 Multiple letter constraint followed by 4 parameter letters. 24129 '0..9:' 24130 number of the part counting from most to least 24131 significant 24132 'H,Q:' 24133 mode of the part 24134 'D,S,H:' 24135 mode of the containing operand 24136 '0,F:' 24137 value of the other parts (F--all bits set) 24138 The constraint matches if the specified part of a constant has 24139 a value different from its other parts. 24140 24141 'Q' 24142 Memory reference without index register and with short 24143 displacement. 24144 24145 'R' 24146 Memory reference with index register and short displacement. 24147 24148 'S' 24149 Memory reference without index register but with long 24150 displacement. 24151 24152 'T' 24153 Memory reference with index register and long displacement. 24154 24155 'U' 24156 Pointer with short displacement. 24157 24158 'W' 24159 Pointer with long displacement. 24160 24161 'Y' 24162 Shift count operand. 24163 24164_SPARC--'config/sparc/sparc.h'_ 24165 'f' 24166 Floating-point register on the SPARC-V8 architecture and lower 24167 floating-point register on the SPARC-V9 architecture. 24168 24169 'e' 24170 Floating-point register. It is equivalent to 'f' on the 24171 SPARC-V8 architecture and contains both lower and upper 24172 floating-point registers on the SPARC-V9 architecture. 24173 24174 'c' 24175 Floating-point condition code register. 24176 24177 'd' 24178 Lower floating-point register. It is only valid on the 24179 SPARC-V9 architecture when the Visual Instruction Set is 24180 available. 24181 24182 'b' 24183 Floating-point register. It is only valid on the SPARC-V9 24184 architecture when the Visual Instruction Set is available. 24185 24186 'h' 24187 64-bit global or out register for the SPARC-V8+ architecture. 24188 24189 'C' 24190 The constant all-ones, for floating-point. 24191 24192 'A' 24193 Signed 5-bit constant 24194 24195 'D' 24196 A vector constant 24197 24198 'I' 24199 Signed 13-bit constant 24200 24201 'J' 24202 Zero 24203 24204 'K' 24205 32-bit constant with the low 12 bits clear (a constant that 24206 can be loaded with the 'sethi' instruction) 24207 24208 'L' 24209 A constant in the range supported by 'movcc' instructions 24210 (11-bit signed immediate) 24211 24212 'M' 24213 A constant in the range supported by 'movrcc' instructions 24214 (10-bit signed immediate) 24215 24216 'N' 24217 Same as 'K', except that it verifies that bits that are not in 24218 the lower 32-bit range are all zero. Must be used instead of 24219 'K' for modes wider than 'SImode' 24220 24221 'O' 24222 The constant 4096 24223 24224 'G' 24225 Floating-point zero 24226 24227 'H' 24228 Signed 13-bit constant, sign-extended to 32 or 64 bits 24229 24230 'P' 24231 The constant -1 24232 24233 'Q' 24234 Floating-point constant whose integral representation can be 24235 moved into an integer register using a single sethi 24236 instruction 24237 24238 'R' 24239 Floating-point constant whose integral representation can be 24240 moved into an integer register using a single mov instruction 24241 24242 'S' 24243 Floating-point constant whose integral representation can be 24244 moved into an integer register using a high/lo_sum instruction 24245 sequence 24246 24247 'T' 24248 Memory address aligned to an 8-byte boundary 24249 24250 'U' 24251 Even register 24252 24253 'W' 24254 Memory address for 'e' constraint registers 24255 24256 'w' 24257 Memory address with only a base register 24258 24259 'Y' 24260 Vector zero 24261 24262_TI C6X family--'config/c6x/constraints.md'_ 24263 'a' 24264 Register file A (A0-A31). 24265 24266 'b' 24267 Register file B (B0-B31). 24268 24269 'A' 24270 Predicate registers in register file A (A0-A2 on C64X and 24271 higher, A1 and A2 otherwise). 24272 24273 'B' 24274 Predicate registers in register file B (B0-B2). 24275 24276 'C' 24277 A call-used register in register file B (B0-B9, B16-B31). 24278 24279 'Da' 24280 Register file A, excluding predicate registers (A3-A31, plus 24281 A0 if not C64X or higher). 24282 24283 'Db' 24284 Register file B, excluding predicate registers (B3-B31). 24285 24286 'Iu4' 24287 Integer constant in the range 0 ... 15. 24288 24289 'Iu5' 24290 Integer constant in the range 0 ... 31. 24291 24292 'In5' 24293 Integer constant in the range -31 ... 0. 24294 24295 'Is5' 24296 Integer constant in the range -16 ... 15. 24297 24298 'I5x' 24299 Integer constant that can be the operand of an ADDA or a SUBA 24300 insn. 24301 24302 'IuB' 24303 Integer constant in the range 0 ... 65535. 24304 24305 'IsB' 24306 Integer constant in the range -32768 ... 32767. 24307 24308 'IsC' 24309 Integer constant in the range -2^{20} ... 2^{20} - 1. 24310 24311 'Jc' 24312 Integer constant that is a valid mask for the clr instruction. 24313 24314 'Js' 24315 Integer constant that is a valid mask for the set instruction. 24316 24317 'Q' 24318 Memory location with A base register. 24319 24320 'R' 24321 Memory location with B base register. 24322 24323 'S0' 24324 On C64x+ targets, a GP-relative small data reference. 24325 24326 'S1' 24327 Any kind of 'SYMBOL_REF', for use in a call address. 24328 24329 'Si' 24330 Any kind of immediate operand, unless it matches the S0 24331 constraint. 24332 24333 'T' 24334 Memory location with B base register, but not using a long 24335 offset. 24336 24337 'W' 24338 A memory operand with an address that cannot be used in an 24339 unaligned access. 24340 24341 'Z' 24342 Register B14 (aka DP). 24343 24344_TILE-Gx--'config/tilegx/constraints.md'_ 24345 'R00' 24346 'R01' 24347 'R02' 24348 'R03' 24349 'R04' 24350 'R05' 24351 'R06' 24352 'R07' 24353 'R08' 24354 'R09' 24355 'R10' 24356 Each of these represents a register constraint for an 24357 individual register, from r0 to r10. 24358 24359 'I' 24360 Signed 8-bit integer constant. 24361 24362 'J' 24363 Signed 16-bit integer constant. 24364 24365 'K' 24366 Unsigned 16-bit integer constant. 24367 24368 'L' 24369 Integer constant that fits in one signed byte when incremented 24370 by one (-129 ... 126). 24371 24372 'm' 24373 Memory operand. If used together with '<' or '>', the operand 24374 can have postincrement which requires printing with '%In' and 24375 '%in' on TILE-Gx. For example: 24376 24377 asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val)); 24378 24379 'M' 24380 A bit mask suitable for the BFINS instruction. 24381 24382 'N' 24383 Integer constant that is a byte tiled out eight times. 24384 24385 'O' 24386 The integer zero constant. 24387 24388 'P' 24389 Integer constant that is a sign-extended byte tiled out as 24390 four shorts. 24391 24392 'Q' 24393 Integer constant that fits in one signed byte when incremented 24394 (-129 ... 126), but excluding -1. 24395 24396 'S' 24397 Integer constant that has all 1 bits consecutive and starting 24398 at bit 0. 24399 24400 'T' 24401 A 16-bit fragment of a got, tls, or pc-relative reference. 24402 24403 'U' 24404 Memory operand except postincrement. This is roughly the same 24405 as 'm' when not used together with '<' or '>'. 24406 24407 'W' 24408 An 8-element vector constant with identical elements. 24409 24410 'Y' 24411 A 4-element vector constant with identical elements. 24412 24413 'Z0' 24414 The integer constant 0xffffffff. 24415 24416 'Z1' 24417 The integer constant 0xffffffff00000000. 24418 24419_TILEPro--'config/tilepro/constraints.md'_ 24420 'R00' 24421 'R01' 24422 'R02' 24423 'R03' 24424 'R04' 24425 'R05' 24426 'R06' 24427 'R07' 24428 'R08' 24429 'R09' 24430 'R10' 24431 Each of these represents a register constraint for an 24432 individual register, from r0 to r10. 24433 24434 'I' 24435 Signed 8-bit integer constant. 24436 24437 'J' 24438 Signed 16-bit integer constant. 24439 24440 'K' 24441 Nonzero integer constant with low 16 bits zero. 24442 24443 'L' 24444 Integer constant that fits in one signed byte when incremented 24445 by one (-129 ... 126). 24446 24447 'm' 24448 Memory operand. If used together with '<' or '>', the operand 24449 can have postincrement which requires printing with '%In' and 24450 '%in' on TILEPro. For example: 24451 24452 asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val)); 24453 24454 'M' 24455 A bit mask suitable for the MM instruction. 24456 24457 'N' 24458 Integer constant that is a byte tiled out four times. 24459 24460 'O' 24461 The integer zero constant. 24462 24463 'P' 24464 Integer constant that is a sign-extended byte tiled out as two 24465 shorts. 24466 24467 'Q' 24468 Integer constant that fits in one signed byte when incremented 24469 (-129 ... 126), but excluding -1. 24470 24471 'T' 24472 A symbolic operand, or a 16-bit fragment of a got, tls, or 24473 pc-relative reference. 24474 24475 'U' 24476 Memory operand except postincrement. This is roughly the same 24477 as 'm' when not used together with '<' or '>'. 24478 24479 'W' 24480 A 4-element vector constant with identical elements. 24481 24482 'Y' 24483 A 2-element vector constant with identical elements. 24484 24485_Visium--'config/visium/constraints.md'_ 24486 'b' 24487 EAM register 'mdb' 24488 24489 'c' 24490 EAM register 'mdc' 24491 24492 'f' 24493 Floating point register 24494 24495 'k' 24496 Register for sibcall optimization 24497 24498 'l' 24499 General register, but not 'r29', 'r30' and 'r31' 24500 24501 't' 24502 Register 'r1' 24503 24504 'u' 24505 Register 'r2' 24506 24507 'v' 24508 Register 'r3' 24509 24510 'G' 24511 Floating-point constant 0.0 24512 24513 'J' 24514 Integer constant in the range 0 .. 65535 (16-bit immediate) 24515 24516 'K' 24517 Integer constant in the range 1 .. 31 (5-bit immediate) 24518 24519 'L' 24520 Integer constant in the range -65535 .. -1 (16-bit negative 24521 immediate) 24522 24523 'M' 24524 Integer constant -1 24525 24526 'O' 24527 Integer constant 0 24528 24529 'P' 24530 Integer constant 32 24531 24532_x86 family--'config/i386/constraints.md'_ 24533 'R' 24534 Legacy register--the eight integer registers available on all 24535 i386 processors ('a', 'b', 'c', 'd', 'si', 'di', 'bp', 'sp'). 24536 24537 'q' 24538 Any register accessible as 'Rl'. In 32-bit mode, 'a', 'b', 24539 'c', and 'd'; in 64-bit mode, any integer register. 24540 24541 'Q' 24542 Any register accessible as 'Rh': 'a', 'b', 'c', and 'd'. 24543 24544 'l' 24545 Any register that can be used as the index in a base+index 24546 memory access: that is, any general register except the stack 24547 pointer. 24548 24549 'a' 24550 The 'a' register. 24551 24552 'b' 24553 The 'b' register. 24554 24555 'c' 24556 The 'c' register. 24557 24558 'd' 24559 The 'd' register. 24560 24561 'S' 24562 The 'si' register. 24563 24564 'D' 24565 The 'di' register. 24566 24567 'A' 24568 The 'a' and 'd' registers. This class is used for 24569 instructions that return double word results in the 'ax:dx' 24570 register pair. Single word values will be allocated either in 24571 'ax' or 'dx'. For example on i386 the following implements 24572 'rdtsc': 24573 24574 unsigned long long rdtsc (void) 24575 { 24576 unsigned long long tick; 24577 __asm__ __volatile__("rdtsc":"=A"(tick)); 24578 return tick; 24579 } 24580 24581 This is not correct on x86-64 as it would allocate tick in 24582 either 'ax' or 'dx'. You have to use the following variant 24583 instead: 24584 24585 unsigned long long rdtsc (void) 24586 { 24587 unsigned int tickl, tickh; 24588 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); 24589 return ((unsigned long long)tickh << 32)|tickl; 24590 } 24591 24592 'U' 24593 The call-clobbered integer registers. 24594 24595 'f' 24596 Any 80387 floating-point (stack) register. 24597 24598 't' 24599 Top of 80387 floating-point stack ('%st(0)'). 24600 24601 'u' 24602 Second from top of 80387 floating-point stack ('%st(1)'). 24603 24604 'Yk' 24605 Any mask register that can be used as a predicate, i.e. 24606 'k1-k7'. 24607 24608 'k' 24609 Any mask register. 24610 24611 'y' 24612 Any MMX register. 24613 24614 'x' 24615 Any SSE register. 24616 24617 'v' 24618 Any EVEX encodable SSE register ('%xmm0-%xmm31'). 24619 24620 'w' 24621 Any bound register. 24622 24623 'Yz' 24624 First SSE register ('%xmm0'). 24625 24626 'Yi' 24627 Any SSE register, when SSE2 and inter-unit moves are enabled. 24628 24629 'Yj' 24630 Any SSE register, when SSE2 and inter-unit moves from vector 24631 registers are enabled. 24632 24633 'Ym' 24634 Any MMX register, when inter-unit moves are enabled. 24635 24636 'Yn' 24637 Any MMX register, when inter-unit moves from vector registers 24638 are enabled. 24639 24640 'Yp' 24641 Any integer register when 'TARGET_PARTIAL_REG_STALL' is 24642 disabled. 24643 24644 'Ya' 24645 Any integer register when zero extensions with 'AND' are 24646 disabled. 24647 24648 'Yb' 24649 Any register that can be used as the GOT base when calling 24650 '___tls_get_addr': that is, any general register except 'a' 24651 and 'sp' registers, for '-fno-plt' if linker supports it. 24652 Otherwise, 'b' register. 24653 24654 'Yf' 24655 Any x87 register when 80387 floating-point arithmetic is 24656 enabled. 24657 24658 'Yr' 24659 Lower SSE register when avoiding REX prefix and all SSE 24660 registers otherwise. 24661 24662 'Yv' 24663 For AVX512VL, any EVEX-encodable SSE register 24664 ('%xmm0-%xmm31'), otherwise any SSE register. 24665 24666 'Yh' 24667 Any EVEX-encodable SSE register, that has number factor of 24668 four. 24669 24670 'Bf' 24671 Flags register operand. 24672 24673 'Bg' 24674 GOT memory operand. 24675 24676 'Bm' 24677 Vector memory operand. 24678 24679 'Bc' 24680 Constant memory operand. 24681 24682 'Bn' 24683 Memory operand without REX prefix. 24684 24685 'Bs' 24686 Sibcall memory operand. 24687 24688 'Bw' 24689 Call memory operand. 24690 24691 'Bz' 24692 Constant call address operand. 24693 24694 'BC' 24695 SSE constant -1 operand. 24696 24697 'I' 24698 Integer constant in the range 0 ... 31, for 32-bit shifts. 24699 24700 'J' 24701 Integer constant in the range 0 ... 63, for 64-bit shifts. 24702 24703 'K' 24704 Signed 8-bit integer constant. 24705 24706 'L' 24707 '0xFF' or '0xFFFF', for andsi as a zero-extending move. 24708 24709 'M' 24710 0, 1, 2, or 3 (shifts for the 'lea' instruction). 24711 24712 'N' 24713 Unsigned 8-bit integer constant (for 'in' and 'out' 24714 instructions). 24715 24716 'O' 24717 Integer constant in the range 0 ... 127, for 128-bit shifts. 24718 24719 'G' 24720 Standard 80387 floating point constant. 24721 24722 'C' 24723 SSE constant zero operand. 24724 24725 'e' 24726 32-bit signed integer constant, or a symbolic reference known 24727 to fit that range (for immediate operands in sign-extending 24728 x86-64 instructions). 24729 24730 'We' 24731 32-bit signed integer constant, or a symbolic reference known 24732 to fit that range (for sign-extending conversion operations 24733 that require non-'VOIDmode' immediate operands). 24734 24735 'Wz' 24736 32-bit unsigned integer constant, or a symbolic reference 24737 known to fit that range (for zero-extending conversion 24738 operations that require non-'VOIDmode' immediate operands). 24739 24740 'Wd' 24741 128-bit integer constant where both the high and low 64-bit 24742 word satisfy the 'e' constraint. 24743 24744 'Z' 24745 32-bit unsigned integer constant, or a symbolic reference 24746 known to fit that range (for immediate operands in 24747 zero-extending x86-64 instructions). 24748 24749 'Tv' 24750 VSIB address operand. 24751 24752 'Ts' 24753 Address operand without segment register. 24754 24755_Xstormy16--'config/stormy16/stormy16.h'_ 24756 'a' 24757 Register r0. 24758 24759 'b' 24760 Register r1. 24761 24762 'c' 24763 Register r2. 24764 24765 'd' 24766 Register r8. 24767 24768 'e' 24769 Registers r0 through r7. 24770 24771 't' 24772 Registers r0 and r1. 24773 24774 'y' 24775 The carry register. 24776 24777 'z' 24778 Registers r8 and r9. 24779 24780 'I' 24781 A constant between 0 and 3 inclusive. 24782 24783 'J' 24784 A constant that has exactly one bit set. 24785 24786 'K' 24787 A constant that has exactly one bit clear. 24788 24789 'L' 24790 A constant between 0 and 255 inclusive. 24791 24792 'M' 24793 A constant between -255 and 0 inclusive. 24794 24795 'N' 24796 A constant between -3 and 0 inclusive. 24797 24798 'O' 24799 A constant between 1 and 4 inclusive. 24800 24801 'P' 24802 A constant between -4 and -1 inclusive. 24803 24804 'Q' 24805 A memory reference that is a stack push. 24806 24807 'R' 24808 A memory reference that is a stack pop. 24809 24810 'S' 24811 A memory reference that refers to a constant address of known 24812 value. 24813 24814 'T' 24815 The register indicated by Rx (not implemented yet). 24816 24817 'U' 24818 A constant that is not between 2 and 15 inclusive. 24819 24820 'Z' 24821 The constant 0. 24822 24823_Xtensa--'config/xtensa/constraints.md'_ 24824 'a' 24825 General-purpose 32-bit register 24826 24827 'b' 24828 One-bit boolean register 24829 24830 'A' 24831 MAC16 40-bit accumulator register 24832 24833 'I' 24834 Signed 12-bit integer constant, for use in MOVI instructions 24835 24836 'J' 24837 Signed 8-bit integer constant, for use in ADDI instructions 24838 24839 'K' 24840 Integer constant valid for BccI instructions 24841 24842 'L' 24843 Unsigned constant valid for BccUI instructions 24844 24845 24846File: gccint.info, Node: Disable Insn Alternatives, Next: Define Constraints, Prev: Machine Constraints, Up: Constraints 24847 2484817.8.6 Disable insn alternatives using the 'enabled' attribute 24849-------------------------------------------------------------- 24850 24851There are three insn attributes that may be used to selectively disable 24852instruction alternatives: 24853 24854'enabled' 24855 Says whether an alternative is available on the current subtarget. 24856 24857'preferred_for_size' 24858 Says whether an enabled alternative should be used in code that is 24859 optimized for size. 24860 24861'preferred_for_speed' 24862 Says whether an enabled alternative should be used in code that is 24863 optimized for speed. 24864 24865 All these attributes should use '(const_int 1)' to allow an alternative 24866or '(const_int 0)' to disallow it. The attributes must be a static 24867property of the subtarget; they cannot for example depend on the current 24868operands, on the current optimization level, on the location of the insn 24869within the body of a loop, on whether register allocation has finished, 24870or on the current compiler pass. 24871 24872 The 'enabled' attribute is a correctness property. It tells GCC to act 24873as though the disabled alternatives were never defined in the first 24874place. This is useful when adding new instructions to an existing 24875pattern in cases where the new instructions are only available for 24876certain cpu architecture levels (typically mapped to the '-march=' 24877command-line option). 24878 24879 In contrast, the 'preferred_for_size' and 'preferred_for_speed' 24880attributes are strong optimization hints rather than correctness 24881properties. 'preferred_for_size' tells GCC which alternatives to 24882consider when adding or modifying an instruction that GCC wants to 24883optimize for size. 'preferred_for_speed' does the same thing for speed. 24884Note that things like code motion can lead to cases where code optimized 24885for size uses alternatives that are not preferred for size, and 24886similarly for speed. 24887 24888 Although 'define_insn's can in principle specify the 'enabled' 24889attribute directly, it is often clearer to have subsiduary attributes 24890for each architectural feature of interest. The 'define_insn's can then 24891use these subsiduary attributes to say which alternatives require which 24892features. The example below does this for 'cpu_facility'. 24893 24894 E.g. the following two patterns could easily be merged using the 24895'enabled' attribute: 24896 24897 24898 (define_insn "*movdi_old" 24899 [(set (match_operand:DI 0 "register_operand" "=d") 24900 (match_operand:DI 1 "register_operand" " d"))] 24901 "!TARGET_NEW" 24902 "lgr %0,%1") 24903 24904 (define_insn "*movdi_new" 24905 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 24906 (match_operand:DI 1 "register_operand" " d,d,f"))] 24907 "TARGET_NEW" 24908 "@ 24909 lgr %0,%1 24910 ldgr %0,%1 24911 lgdr %0,%1") 24912 24913 24914 to: 24915 24916 24917 (define_insn "*movdi_combined" 24918 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 24919 (match_operand:DI 1 "register_operand" " d,d,f"))] 24920 "" 24921 "@ 24922 lgr %0,%1 24923 ldgr %0,%1 24924 lgdr %0,%1" 24925 [(set_attr "cpu_facility" "*,new,new")]) 24926 24927 24928 with the 'enabled' attribute defined like this: 24929 24930 24931 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 24932 24933 (define_attr "enabled" "" 24934 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 24935 (and (eq_attr "cpu_facility" "new") 24936 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 24937 (const_int 1)] 24938 (const_int 0))) 24939 24940 24941 24942File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Disable Insn Alternatives, Up: Constraints 24943 2494417.8.7 Defining Machine-Specific Constraints 24945-------------------------------------------- 24946 24947Machine-specific constraints fall into two categories: register and 24948non-register constraints. Within the latter category, constraints which 24949allow subsets of all possible memory or address operands should be 24950specially marked, to give 'reload' more information. 24951 24952 Machine-specific constraints can be given names of arbitrary length, 24953but they must be entirely composed of letters, digits, underscores 24954('_'), and angle brackets ('< >'). Like C identifiers, they must begin 24955with a letter or underscore. 24956 24957 In order to avoid ambiguity in operand constraint strings, no 24958constraint can have a name that begins with any other constraint's name. 24959For example, if 'x' is defined as a constraint name, 'xy' may not be, 24960and vice versa. As a consequence of this rule, no constraint may begin 24961with one of the generic constraint letters: 'E F V X g i m n o p r s'. 24962 24963 Register constraints correspond directly to register classes. *Note 24964Register Classes::. There is thus not much flexibility in their 24965definitions. 24966 24967 -- MD Expression: define_register_constraint name regclass docstring 24968 All three arguments are string constants. NAME is the name of the 24969 constraint, as it will appear in 'match_operand' expressions. If 24970 NAME is a multi-letter constraint its length shall be the same for 24971 all constraints starting with the same letter. REGCLASS can be 24972 either the name of the corresponding register class (*note Register 24973 Classes::), or a C expression which evaluates to the appropriate 24974 register class. If it is an expression, it must have no side 24975 effects, and it cannot look at the operand. The usual use of 24976 expressions is to map some register constraints to 'NO_REGS' when 24977 the register class is not available on a given subarchitecture. 24978 24979 DOCSTRING is a sentence documenting the meaning of the constraint. 24980 Docstrings are explained further below. 24981 24982 Non-register constraints are more like predicates: the constraint 24983definition gives a boolean expression which indicates whether the 24984constraint matches. 24985 24986 -- MD Expression: define_constraint name docstring exp 24987 The NAME and DOCSTRING arguments are the same as for 24988 'define_register_constraint', but note that the docstring comes 24989 immediately after the name for these expressions. EXP is an RTL 24990 expression, obeying the same rules as the RTL expressions in 24991 predicate definitions. *Note Defining Predicates::, for details. 24992 If it evaluates true, the constraint matches; if it evaluates 24993 false, it doesn't. Constraint expressions should indicate which 24994 RTL codes they might match, just like predicate expressions. 24995 24996 'match_test' C expressions have access to the following variables: 24997 24998 OP 24999 The RTL object defining the operand. 25000 MODE 25001 The machine mode of OP. 25002 IVAL 25003 'INTVAL (OP)', if OP is a 'const_int'. 25004 HVAL 25005 'CONST_DOUBLE_HIGH (OP)', if OP is an integer 'const_double'. 25006 LVAL 25007 'CONST_DOUBLE_LOW (OP)', if OP is an integer 'const_double'. 25008 RVAL 25009 'CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 25010 'const_double'. 25011 25012 The *VAL variables should only be used once another piece of the 25013 expression has verified that OP is the appropriate kind of RTL 25014 object. 25015 25016 Most non-register constraints should be defined with 25017'define_constraint'. The remaining two definition expressions are only 25018appropriate for constraints that should be handled specially by 'reload' 25019if they fail to match. 25020 25021 -- MD Expression: define_memory_constraint name docstring exp 25022 Use this expression for constraints that match a subset of all 25023 memory operands: that is, 'reload' can make them match by 25024 converting the operand to the form '(mem (reg X))', where X is a 25025 base register (from the register class specified by 25026 'BASE_REG_CLASS', *note Register Classes::). 25027 25028 For example, on the S/390, some instructions do not accept 25029 arbitrary memory references, but only those that do not make use of 25030 an index register. The constraint letter 'Q' is defined to 25031 represent a memory address of this type. If 'Q' is defined with 25032 'define_memory_constraint', a 'Q' constraint can handle any memory 25033 operand, because 'reload' knows it can simply copy the memory 25034 address into a base register if required. This is analogous to the 25035 way an 'o' constraint can handle any memory operand. 25036 25037 The syntax and semantics are otherwise identical to 25038 'define_constraint'. 25039 25040 -- MD Expression: define_special_memory_constraint name docstring exp 25041 Use this expression for constraints that match a subset of all 25042 memory operands: that is, 'reload' cannot make them match by 25043 reloading the address as it is described for 25044 'define_memory_constraint' or such address reload is undesirable 25045 with the performance point of view. 25046 25047 For example, 'define_special_memory_constraint' can be useful if 25048 specifically aligned memory is necessary or desirable for some insn 25049 operand. 25050 25051 The syntax and semantics are otherwise identical to 25052 'define_constraint'. 25053 25054 -- MD Expression: define_address_constraint name docstring exp 25055 Use this expression for constraints that match a subset of all 25056 address operands: that is, 'reload' can make the constraint match 25057 by converting the operand to the form '(reg X)', again with X a 25058 base register. 25059 25060 Constraints defined with 'define_address_constraint' can only be 25061 used with the 'address_operand' predicate, or machine-specific 25062 predicates that work the same way. They are treated analogously to 25063 the generic 'p' constraint. 25064 25065 The syntax and semantics are otherwise identical to 25066 'define_constraint'. 25067 25068 For historical reasons, names beginning with the letters 'G H' are 25069reserved for constraints that match only 'const_double's, and names 25070beginning with the letters 'I J K L M N O P' are reserved for 25071constraints that match only 'const_int's. This may change in the 25072future. For the time being, constraints with these names must be 25073written in a stylized form, so that 'genpreds' can tell you did it 25074correctly: 25075 25076 (define_constraint "[GHIJKLMNOP]..." 25077 "DOC..." 25078 (and (match_code "const_int") ; 'const_double' for G/H 25079 CONDITION...)) ; usually a 'match_test' 25080 25081 It is fine to use names beginning with other letters for constraints 25082that match 'const_double's or 'const_int's. 25083 25084 Each docstring in a constraint definition should be one or more 25085complete sentences, marked up in Texinfo format. _They are currently 25086unused._ In the future they will be copied into the GCC manual, in 25087*note Machine Constraints::, replacing the hand-maintained tables 25088currently found in that section. Also, in the future the compiler may 25089use this to give more helpful diagnostics when poor choice of 'asm' 25090constraints causes a reload failure. 25091 25092 If you put the pseudo-Texinfo directive '@internal' at the beginning of 25093a docstring, then (in the future) it will appear only in the internals 25094manual's version of the machine-specific constraint tables. Use this 25095for constraints that should not appear in 'asm' statements. 25096 25097 25098File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 25099 2510017.8.8 Testing constraints from C 25101--------------------------------- 25102 25103It is occasionally useful to test a constraint from C code rather than 25104implicitly via the constraint string in a 'match_operand'. The 25105generated file 'tm_p.h' declares a few interfaces for working with 25106constraints. At present these are defined for all constraints except 25107'g' (which is equivalent to 'general_operand'). 25108 25109 Some valid constraint names are not valid C identifiers, so there is a 25110mangling scheme for referring to them from C. Constraint names that do 25111not contain angle brackets or underscores are left unchanged. 25112Underscores are doubled, each '<' is replaced with '_l', and each '>' 25113with '_g'. Here are some examples: 25114 25115 *Original* *Mangled* 25116 x x 25117 P42x P42x 25118 P4_x P4__x 25119 P4>x P4_gx 25120 P4>> P4_g_g 25121 P4_g> P4__g_g 25122 25123 Throughout this section, the variable C is either a constraint in the 25124abstract sense, or a constant from 'enum constraint_num'; the variable M 25125is a mangled constraint name (usually as part of a larger identifier). 25126 25127 -- Enum: constraint_num 25128 For each constraint except 'g', there is a corresponding 25129 enumeration constant: 'CONSTRAINT_' plus the mangled name of the 25130 constraint. Functions that take an 'enum constraint_num' as an 25131 argument expect one of these constants. 25132 25133 -- Function: inline bool satisfies_constraint_M (rtx EXP) 25134 For each non-register constraint M except 'g', there is one of 25135 these functions; it returns 'true' if EXP satisfies the constraint. 25136 These functions are only visible if 'rtl.h' was included before 25137 'tm_p.h'. 25138 25139 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 25140 C) 25141 Like the 'satisfies_constraint_M' functions, but the constraint to 25142 test is given as an argument, C. If C specifies a register 25143 constraint, this function will always return 'false'. 25144 25145 -- Function: enum reg_class reg_class_for_constraint (enum 25146 constraint_num C) 25147 Returns the register class associated with C. If C is not a 25148 register constraint, or those registers are not available for the 25149 currently selected subtarget, returns 'NO_REGS'. 25150 25151 Here is an example use of 'satisfies_constraint_M'. In peephole 25152optimizations (*note Peephole Definitions::), operand constraint strings 25153are ignored, so if there are relevant constraints, they must be tested 25154in the C condition. In the example, the optimization is applied if 25155operand 2 does _not_ satisfy the 'K' constraint. (This is a simplified 25156version of a peephole definition from the i386 machine description.) 25157 25158 (define_peephole2 25159 [(match_scratch:SI 3 "r") 25160 (set (match_operand:SI 0 "register_operand" "") 25161 (mult:SI (match_operand:SI 1 "memory_operand" "") 25162 (match_operand:SI 2 "immediate_operand" "")))] 25163 25164 "!satisfies_constraint_K (operands[2])" 25165 25166 [(set (match_dup 3) (match_dup 1)) 25167 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 25168 25169 "") 25170 25171 25172File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 25173 2517417.9 Standard Pattern Names For Generation 25175========================================== 25176 25177Here is a table of the instruction names that are meaningful in the RTL 25178generation pass of the compiler. Giving one of these names to an 25179instruction pattern tells the RTL generation pass that it can use the 25180pattern to accomplish a certain task. 25181 25182'movM' 25183 Here M stands for a two-letter machine mode name, in lowercase. 25184 This instruction pattern moves data with that machine mode from 25185 operand 1 to operand 0. For example, 'movsi' moves full-word data. 25186 25187 If operand 0 is a 'subreg' with mode M of a register whose own mode 25188 is wider than M, the effect of this instruction is to store the 25189 specified value in the part of the register that corresponds to 25190 mode M. Bits outside of M, but which are within the same target 25191 word as the 'subreg' are undefined. Bits which are outside the 25192 target word are left unchanged. 25193 25194 This class of patterns is special in several ways. First of all, 25195 each of these names up to and including full word size _must_ be 25196 defined, because there is no other way to copy a datum from one 25197 place to another. If there are patterns accepting operands in 25198 larger modes, 'movM' must be defined for integer modes of those 25199 sizes. 25200 25201 Second, these patterns are not used solely in the RTL generation 25202 pass. Even the reload pass can generate move insns to copy values 25203 from stack slots into temporary registers. When it does so, one of 25204 the operands is a hard register and the other is an operand that 25205 can need to be reloaded into a register. 25206 25207 Therefore, when given such a pair of operands, the pattern must 25208 generate RTL which needs no reloading and needs no temporary 25209 registers--no registers other than the operands. For example, if 25210 you support the pattern with a 'define_expand', then in such a case 25211 the 'define_expand' mustn't call 'force_reg' or any other such 25212 function which might generate new pseudo registers. 25213 25214 This requirement exists even for subword modes on a RISC machine 25215 where fetching those modes from memory normally requires several 25216 insns and some temporary registers. 25217 25218 During reload a memory reference with an invalid address may be 25219 passed as an operand. Such an address will be replaced with a 25220 valid address later in the reload pass. In this case, nothing may 25221 be done with the address except to use it as it stands. If it is 25222 copied, it will not be replaced with a valid address. No attempt 25223 should be made to make such an address into a valid address and no 25224 routine (such as 'change_address') that will do so may be called. 25225 Note that 'general_operand' will fail when applied to such an 25226 address. 25227 25228 The global variable 'reload_in_progress' (which must be explicitly 25229 declared if required) can be used to determine whether such special 25230 handling is required. 25231 25232 The variety of operands that have reloads depends on the rest of 25233 the machine description, but typically on a RISC machine these can 25234 only be pseudo registers that did not get hard registers, while on 25235 other machines explicit memory references will get optional 25236 reloads. 25237 25238 If a scratch register is required to move an object to or from 25239 memory, it can be allocated using 'gen_reg_rtx' prior to life 25240 analysis. 25241 25242 If there are cases which need scratch registers during or after 25243 reload, you must provide an appropriate secondary_reload target 25244 hook. 25245 25246 The macro 'can_create_pseudo_p' can be used to determine if it is 25247 unsafe to create new pseudo registers. If this variable is 25248 nonzero, then it is unsafe to call 'gen_reg_rtx' to allocate a new 25249 pseudo. 25250 25251 The constraints on a 'movM' must permit moving any hard register to 25252 any other hard register provided that 'TARGET_HARD_REGNO_MODE_OK' 25253 permits mode M in both registers and 'TARGET_REGISTER_MOVE_COST' 25254 applied to their classes returns a value of 2. 25255 25256 It is obligatory to support floating point 'movM' instructions into 25257 and out of any registers that can hold fixed point values, because 25258 unions and structures (which have modes 'SImode' or 'DImode') can 25259 be in those registers and they may have floating point members. 25260 25261 There may also be a need to support fixed point 'movM' instructions 25262 in and out of floating point registers. Unfortunately, I have 25263 forgotten why this was so, and I don't know whether it is still 25264 true. If 'TARGET_HARD_REGNO_MODE_OK' rejects fixed point values in 25265 floating point registers, then the constraints of the fixed point 25266 'movM' instructions must be designed to avoid ever trying to reload 25267 into a floating point register. 25268 25269'reload_inM' 25270'reload_outM' 25271 These named patterns have been obsoleted by the target hook 25272 'secondary_reload'. 25273 25274 Like 'movM', but used when a scratch register is required to move 25275 between operand 0 and operand 1. Operand 2 describes the scratch 25276 register. See the discussion of the 'SECONDARY_RELOAD_CLASS' macro 25277 in *note Register Classes::. 25278 25279 There are special restrictions on the form of the 'match_operand's 25280 used in these patterns. First, only the predicate for the reload 25281 operand is examined, i.e., 'reload_in' examines operand 1, but not 25282 the predicates for operand 0 or 2. Second, there may be only one 25283 alternative in the constraints. Third, only a single register 25284 class letter may be used for the constraint; subsequent constraint 25285 letters are ignored. As a special exception, an empty constraint 25286 string matches the 'ALL_REGS' register class. This may relieve 25287 ports of the burden of defining an 'ALL_REGS' constraint letter 25288 just for these patterns. 25289 25290'movstrictM' 25291 Like 'movM' except that if operand 0 is a 'subreg' with mode M of a 25292 register whose natural mode is wider, the 'movstrictM' instruction 25293 is guaranteed not to alter any of the register except the part 25294 which belongs to mode M. 25295 25296'movmisalignM' 25297 This variant of a move pattern is designed to load or store a value 25298 from a memory address that is not naturally aligned for its mode. 25299 For a store, the memory will be in operand 0; for a load, the 25300 memory will be in operand 1. The other operand is guaranteed not 25301 to be a memory, so that it's easy to tell whether this is a load or 25302 store. 25303 25304 This pattern is used by the autovectorizer, and when expanding a 25305 'MISALIGNED_INDIRECT_REF' expression. 25306 25307'load_multiple' 25308 Load several consecutive memory locations into consecutive 25309 registers. Operand 0 is the first of the consecutive registers, 25310 operand 1 is the first memory location, and operand 2 is a 25311 constant: the number of consecutive registers. 25312 25313 Define this only if the target machine really has such an 25314 instruction; do not define this if the most efficient way of 25315 loading consecutive registers from memory is to do them one at a 25316 time. 25317 25318 On some machines, there are restrictions as to which consecutive 25319 registers can be stored into memory, such as particular starting or 25320 ending register numbers or only a range of valid counts. For those 25321 machines, use a 'define_expand' (*note Expander Definitions::) and 25322 make the pattern fail if the restrictions are not met. 25323 25324 Write the generated insn as a 'parallel' with elements being a 25325 'set' of one register from the appropriate memory location (you may 25326 also need 'use' or 'clobber' elements). Use a 'match_parallel' 25327 (*note RTL Template::) to recognize the insn. See 'rs6000.md' for 25328 examples of the use of this insn pattern. 25329 25330'store_multiple' 25331 Similar to 'load_multiple', but store several consecutive registers 25332 into consecutive memory locations. Operand 0 is the first of the 25333 consecutive memory locations, operand 1 is the first register, and 25334 operand 2 is a constant: the number of consecutive registers. 25335 25336'vec_load_lanesMN' 25337 Perform an interleaved load of several vectors from memory operand 25338 1 into register operand 0. Both operands have mode M. The 25339 register operand is viewed as holding consecutive vectors of mode 25340 N, while the memory operand is a flat array that contains the same 25341 number of elements. The operation is equivalent to: 25342 25343 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 25344 for (j = 0; j < GET_MODE_NUNITS (N); j++) 25345 for (i = 0; i < c; i++) 25346 operand0[i][j] = operand1[j * c + i]; 25347 25348 For example, 'vec_load_lanestiv4hi' loads 8 16-bit values from 25349 memory into a register of mode 'TI'. The register contains two 25350 consecutive vectors of mode 'V4HI'. 25351 25352 This pattern can only be used if: 25353 TARGET_ARRAY_MODE_SUPPORTED_P (N, C) 25354 is true. GCC assumes that, if a target supports this kind of 25355 instruction for some mode N, it also supports unaligned loads for 25356 vectors of mode N. 25357 25358 This pattern is not allowed to 'FAIL'. 25359 25360'vec_mask_load_lanesMN' 25361 Like 'vec_load_lanesMN', but takes an additional mask operand 25362 (operand 2) that specifies which elements of the destination 25363 vectors should be loaded. Other elements of the destination 25364 vectors are set to zero. The operation is equivalent to: 25365 25366 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 25367 for (j = 0; j < GET_MODE_NUNITS (N); j++) 25368 if (operand2[j]) 25369 for (i = 0; i < c; i++) 25370 operand0[i][j] = operand1[j * c + i]; 25371 else 25372 for (i = 0; i < c; i++) 25373 operand0[i][j] = 0; 25374 25375 This pattern is not allowed to 'FAIL'. 25376 25377'vec_store_lanesMN' 25378 Equivalent to 'vec_load_lanesMN', with the memory and register 25379 operands reversed. That is, the instruction is equivalent to: 25380 25381 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 25382 for (j = 0; j < GET_MODE_NUNITS (N); j++) 25383 for (i = 0; i < c; i++) 25384 operand0[j * c + i] = operand1[i][j]; 25385 25386 for a memory operand 0 and register operand 1. 25387 25388 This pattern is not allowed to 'FAIL'. 25389 25390'vec_mask_store_lanesMN' 25391 Like 'vec_store_lanesMN', but takes an additional mask operand 25392 (operand 2) that specifies which elements of the source vectors 25393 should be stored. The operation is equivalent to: 25394 25395 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 25396 for (j = 0; j < GET_MODE_NUNITS (N); j++) 25397 if (operand2[j]) 25398 for (i = 0; i < c; i++) 25399 operand0[j * c + i] = operand1[i][j]; 25400 25401 This pattern is not allowed to 'FAIL'. 25402 25403'gather_loadMN' 25404 Load several separate memory locations into a vector of mode M. 25405 Operand 1 is a scalar base address and operand 2 is a vector of 25406 mode N containing offsets from that base. Operand 0 is a 25407 destination vector with the same number of elements as N. For each 25408 element index I: 25409 25410 * extend the offset element I to address width, using zero 25411 extension if operand 3 is 1 and sign extension if operand 3 is 25412 zero; 25413 * multiply the extended offset by operand 4; 25414 * add the result to the base; and 25415 * load the value at that address into element I of operand 0. 25416 25417 The value of operand 3 does not matter if the offsets are already 25418 address width. 25419 25420'mask_gather_loadMN' 25421 Like 'gather_loadMN', but takes an extra mask operand as operand 5. 25422 Bit I of the mask is set if element I of the result should be 25423 loaded from memory and clear if element I of the result should be 25424 set to zero. 25425 25426'scatter_storeMN' 25427 Store a vector of mode M into several distinct memory locations. 25428 Operand 0 is a scalar base address and operand 1 is a vector of 25429 mode N containing offsets from that base. Operand 4 is the vector 25430 of values that should be stored, which has the same number of 25431 elements as N. For each element index I: 25432 25433 * extend the offset element I to address width, using zero 25434 extension if operand 2 is 1 and sign extension if operand 2 is 25435 zero; 25436 * multiply the extended offset by operand 3; 25437 * add the result to the base; and 25438 * store element I of operand 4 to that address. 25439 25440 The value of operand 2 does not matter if the offsets are already 25441 address width. 25442 25443'mask_scatter_storeMN' 25444 Like 'scatter_storeMN', but takes an extra mask operand as operand 25445 5. Bit I of the mask is set if element I of the result should be 25446 stored to memory. 25447 25448'vec_setM' 25449 Set given field in the vector value. Operand 0 is the vector to 25450 modify, operand 1 is new value of field and operand 2 specify the 25451 field index. 25452 25453'vec_extractMN' 25454 Extract given field from the vector value. Operand 1 is the 25455 vector, operand 2 specify field index and operand 0 place to store 25456 value into. The N mode is the mode of the field or vector of 25457 fields that should be extracted, should be either element mode of 25458 the vector mode M, or a vector mode with the same element mode and 25459 smaller number of elements. If N is a vector mode, the index is 25460 counted in units of that mode. 25461 25462'vec_initMN' 25463 Initialize the vector to given values. Operand 0 is the vector to 25464 initialize and operand 1 is parallel containing values for 25465 individual fields. The N mode is the mode of the elements, should 25466 be either element mode of the vector mode M, or a vector mode with 25467 the same element mode and smaller number of elements. 25468 25469'vec_duplicateM' 25470 Initialize vector output operand 0 so that each element has the 25471 value given by scalar input operand 1. The vector has mode M and 25472 the scalar has the mode appropriate for one element of M. 25473 25474 This pattern only handles duplicates of non-constant inputs. 25475 Constant vectors go through the 'movM' pattern instead. 25476 25477 This pattern is not allowed to 'FAIL'. 25478 25479'vec_seriesM' 25480 Initialize vector output operand 0 so that element I is equal to 25481 operand 1 plus I times operand 2. In other words, create a linear 25482 series whose base value is operand 1 and whose step is operand 2. 25483 25484 The vector output has mode M and the scalar inputs have the mode 25485 appropriate for one element of M. This pattern is not used for 25486 floating-point vectors, in order to avoid having to specify the 25487 rounding behavior for I > 1. 25488 25489 This pattern is not allowed to 'FAIL'. 25490 25491'while_ultMN' 25492 Set operand 0 to a mask that is true while incrementing operand 1 25493 gives a value that is less than operand 2. Operand 0 has mode N 25494 and operands 1 and 2 are scalar integers of mode M. The operation 25495 is equivalent to: 25496 25497 operand0[0] = operand1 < operand2; 25498 for (i = 1; i < GET_MODE_NUNITS (N); i++) 25499 operand0[i] = operand0[i - 1] && (operand1 + i < operand2); 25500 25501'check_raw_ptrsM' 25502 Check whether, given two pointers A and B and a length LEN, a write 25503 of LEN bytes at A followed by a read of LEN bytes at B can be split 25504 into interleaved byte accesses 'A[0], B[0], A[1], B[1], ...' 25505 without affecting the dependencies between the bytes. Set operand 25506 0 to true if the split is possible and false otherwise. 25507 25508 Operands 1, 2 and 3 provide the values of A, B and LEN 25509 respectively. Operand 4 is a constant integer that provides the 25510 known common alignment of A and B. All inputs have mode M. 25511 25512 This split is possible if: 25513 25514 A == B || A + LEN <= B || B + LEN <= A 25515 25516 You should only define this pattern if the target has a way of 25517 accelerating the test without having to do the individual 25518 comparisons. 25519 25520'check_war_ptrsM' 25521 Like 'check_raw_ptrsM', but with the read and write swapped round. 25522 The split is possible in this case if: 25523 25524 B <= A || A + LEN <= B 25525 25526'vec_cmpMN' 25527 Output a vector comparison. Operand 0 of mode N is the destination 25528 for predicate in operand 1 which is a signed vector comparison with 25529 operands of mode M in operands 2 and 3. Predicate is computed by 25530 element-wise evaluation of the vector comparison with a truth value 25531 of all-ones and a false value of all-zeros. 25532 25533'vec_cmpuMN' 25534 Similar to 'vec_cmpMN' but perform unsigned vector comparison. 25535 25536'vec_cmpeqMN' 25537 Similar to 'vec_cmpMN' but perform equality or non-equality vector 25538 comparison only. If 'vec_cmpMN' or 'vec_cmpuMN' instruction 25539 pattern is supported, it will be preferred over 'vec_cmpeqMN', so 25540 there is no need to define this instruction pattern if the others 25541 are supported. 25542 25543'vcondMN' 25544 Output a conditional vector move. Operand 0 is the destination to 25545 receive a combination of operand 1 and operand 2, which are of mode 25546 M, dependent on the outcome of the predicate in operand 3 which is 25547 a signed vector comparison with operands of mode N in operands 4 25548 and 5. The modes M and N should have the same size. Operand 0 25549 will be set to the value OP1 & MSK | OP2 & ~MSK where MSK is 25550 computed by element-wise evaluation of the vector comparison with a 25551 truth value of all-ones and a false value of all-zeros. 25552 25553'vconduMN' 25554 Similar to 'vcondMN' but performs unsigned vector comparison. 25555 25556'vcondeqMN' 25557 Similar to 'vcondMN' but performs equality or non-equality vector 25558 comparison only. If 'vcondMN' or 'vconduMN' instruction pattern is 25559 supported, it will be preferred over 'vcondeqMN', so there is no 25560 need to define this instruction pattern if the others are 25561 supported. 25562 25563'vcond_mask_MN' 25564 Similar to 'vcondMN' but operand 3 holds a pre-computed result of 25565 vector comparison. 25566 25567'maskloadMN' 25568 Perform a masked load of vector from memory operand 1 of mode M 25569 into register operand 0. Mask is provided in register operand 2 of 25570 mode N. 25571 25572 This pattern is not allowed to 'FAIL'. 25573 25574'maskstoreMN' 25575 Perform a masked store of vector from register operand 1 of mode M 25576 into memory operand 0. Mask is provided in register operand 2 of 25577 mode N. 25578 25579 This pattern is not allowed to 'FAIL'. 25580 25581'vec_permM' 25582 Output a (variable) vector permutation. Operand 0 is the 25583 destination to receive elements from operand 1 and operand 2, which 25584 are of mode M. Operand 3 is the "selector". It is an integral 25585 mode vector of the same width and number of elements as mode M. 25586 25587 The input elements are numbered from 0 in operand 1 through 2*N-1 25588 in operand 2. The elements of the selector must be computed modulo 25589 2*N. Note that if 'rtx_equal_p(operand1, operand2)', this can be 25590 implemented with just operand 1 and selector elements modulo N. 25591 25592 In order to make things easy for a number of targets, if there is 25593 no 'vec_perm' pattern for mode M, but there is for mode Q where Q 25594 is a vector of 'QImode' of the same width as M, the middle-end will 25595 lower the mode M 'VEC_PERM_EXPR' to mode Q. 25596 25597 See also 'TARGET_VECTORIZER_VEC_PERM_CONST', which performs the 25598 analogous operation for constant selectors. 25599 25600'pushM1' 25601 Output a push instruction. Operand 0 is value to push. Used only 25602 when 'PUSH_ROUNDING' is defined. For historical reason, this 25603 pattern may be missing and in such case an 'mov' expander is used 25604 instead, with a 'MEM' expression forming the push operation. The 25605 'mov' expander method is deprecated. 25606 25607'addM3' 25608 Add operand 2 and operand 1, storing the result in operand 0. All 25609 operands must have mode M. This can be used even on two-address 25610 machines, by means of constraints requiring operands 1 and 0 to be 25611 the same location. 25612 25613'ssaddM3', 'usaddM3' 25614'subM3', 'sssubM3', 'ussubM3' 25615'mulM3', 'ssmulM3', 'usmulM3' 25616'divM3', 'ssdivM3' 25617'udivM3', 'usdivM3' 25618'modM3', 'umodM3' 25619'uminM3', 'umaxM3' 25620'andM3', 'iorM3', 'xorM3' 25621 Similar, for other arithmetic operations. 25622 25623'addvM4' 25624 Like 'addM3' but takes a 'code_label' as operand 3 and emits code 25625 to jump to it if signed overflow occurs during the addition. This 25626 pattern is used to implement the built-in functions performing 25627 signed integer addition with overflow checking. 25628 25629'subvM4', 'mulvM4' 25630 Similar, for other signed arithmetic operations. 25631 25632'uaddvM4' 25633 Like 'addvM4' but for unsigned addition. That is to say, the 25634 operation is the same as signed addition but the jump is taken only 25635 on unsigned overflow. 25636 25637'usubvM4', 'umulvM4' 25638 Similar, for other unsigned arithmetic operations. 25639 25640'addptrM3' 25641 Like 'addM3' but is guaranteed to only be used for address 25642 calculations. The expanded code is not allowed to clobber the 25643 condition code. It only needs to be defined if 'addM3' sets the 25644 condition code. If adds used for address calculations and normal 25645 adds are not compatible it is required to expand a distinct pattern 25646 (e.g. using an unspec). The pattern is used by LRA to emit address 25647 calculations. 'addM3' is used if 'addptrM3' is not defined. 25648 25649'fmaM4' 25650 Multiply operand 2 and operand 1, then add operand 3, storing the 25651 result in operand 0 without doing an intermediate rounding step. 25652 All operands must have mode M. This pattern is used to implement 25653 the 'fma', 'fmaf', and 'fmal' builtin functions from the ISO C99 25654 standard. 25655 25656'fmsM4' 25657 Like 'fmaM4', except operand 3 subtracted from the product instead 25658 of added to the product. This is represented in the rtl as 25659 25660 (fma:M OP1 OP2 (neg:M OP3)) 25661 25662'fnmaM4' 25663 Like 'fmaM4' except that the intermediate product is negated before 25664 being added to operand 3. This is represented in the rtl as 25665 25666 (fma:M (neg:M OP1) OP2 OP3) 25667 25668'fnmsM4' 25669 Like 'fmsM4' except that the intermediate product is negated before 25670 subtracting operand 3. This is represented in the rtl as 25671 25672 (fma:M (neg:M OP1) OP2 (neg:M OP3)) 25673 25674'sminM3', 'smaxM3' 25675 Signed minimum and maximum operations. When used with floating 25676 point, if both operands are zeros, or if either operand is 'NaN', 25677 then it is unspecified which of the two operands is returned as the 25678 result. 25679 25680'fminM3', 'fmaxM3' 25681 IEEE-conformant minimum and maximum operations. If one operand is 25682 a quiet 'NaN', then the other operand is returned. If both 25683 operands are quiet 'NaN', then a quiet 'NaN' is returned. In the 25684 case when gcc supports signaling 'NaN' (-fsignaling-nans) an 25685 invalid floating point exception is raised and a quiet 'NaN' is 25686 returned. 25687 25688 All operands have mode M, which is a scalar or vector 25689 floating-point mode. These patterns are not allowed to 'FAIL'. 25690 25691'reduc_smin_scal_M', 'reduc_smax_scal_M' 25692 Find the signed minimum/maximum of the elements of a vector. The 25693 vector is operand 1, and operand 0 is the scalar result, with mode 25694 equal to the mode of the elements of the input vector. 25695 25696'reduc_umin_scal_M', 'reduc_umax_scal_M' 25697 Find the unsigned minimum/maximum of the elements of a vector. The 25698 vector is operand 1, and operand 0 is the scalar result, with mode 25699 equal to the mode of the elements of the input vector. 25700 25701'reduc_plus_scal_M' 25702 Compute the sum of the elements of a vector. The vector is operand 25703 1, and operand 0 is the scalar result, with mode equal to the mode 25704 of the elements of the input vector. 25705 25706'reduc_and_scal_M' 25707'reduc_ior_scal_M' 25708'reduc_xor_scal_M' 25709 Compute the bitwise 'AND'/'IOR'/'XOR' reduction of the elements of 25710 a vector of mode M. Operand 1 is the vector input and operand 0 is 25711 the scalar result. The mode of the scalar result is the same as 25712 one element of M. 25713 25714'extract_last_M' 25715 Find the last set bit in mask operand 1 and extract the associated 25716 element of vector operand 2. Store the result in scalar operand 0. 25717 Operand 2 has vector mode M while operand 0 has the mode 25718 appropriate for one element of M. Operand 1 has the usual mask 25719 mode for vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'. 25720 25721'fold_extract_last_M' 25722 If any bits of mask operand 2 are set, find the last set bit, 25723 extract the associated element from vector operand 3, and store the 25724 result in operand 0. Store operand 1 in operand 0 otherwise. 25725 Operand 3 has mode M and operands 0 and 1 have the mode appropriate 25726 for one element of M. Operand 2 has the usual mask mode for 25727 vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'. 25728 25729'fold_left_plus_M' 25730 Take scalar operand 1 and successively add each element from vector 25731 operand 2. Store the result in scalar operand 0. The vector has 25732 mode M and the scalars have the mode appropriate for one element of 25733 M. The operation is strictly in-order: there is no reassociation. 25734 25735'mask_fold_left_plus_M' 25736 Like 'fold_left_plus_M', but takes an additional mask operand 25737 (operand 3) that specifies which elements of the source vector 25738 should be added. 25739 25740'sdot_prodM' 25741'udot_prodM' 25742 Compute the sum of the products of two signed/unsigned elements. 25743 Operand 1 and operand 2 are of the same mode. Their product, which 25744 is of a wider mode, is computed and added to operand 3. Operand 3 25745 is of a mode equal or wider than the mode of the product. The 25746 result is placed in operand 0, which is of the same mode as operand 25747 3. 25748 25749'ssadM' 25750'usadM' 25751 Compute the sum of absolute differences of two signed/unsigned 25752 elements. Operand 1 and operand 2 are of the same mode. Their 25753 absolute difference, which is of a wider mode, is computed and 25754 added to operand 3. Operand 3 is of a mode equal or wider than the 25755 mode of the absolute difference. The result is placed in operand 25756 0, which is of the same mode as operand 3. 25757 25758'widen_ssumM3' 25759'widen_usumM3' 25760 Operands 0 and 2 are of the same mode, which is wider than the mode 25761 of operand 1. Add operand 1 to operand 2 and place the widened 25762 result in operand 0. (This is used express accumulation of 25763 elements into an accumulator of a wider mode.) 25764 25765'smulhsM3' 25766'umulhsM3' 25767 Signed/unsigned multiply high with scale. This is equivalent to 25768 the C code: 25769 narrow op0, op1, op2; 25770 ... 25771 op0 = (narrow) (((wide) op1 * (wide) op2) >> (N / 2 - 1)); 25772 where the sign of 'narrow' determines whether this is a signed or 25773 unsigned operation, and N is the size of 'wide' in bits. 25774 25775'smulhrsM3' 25776'umulhrsM3' 25777 Signed/unsigned multiply high with round and scale. This is 25778 equivalent to the C code: 25779 narrow op0, op1, op2; 25780 ... 25781 op0 = (narrow) (((((wide) op1 * (wide) op2) >> (N / 2 - 2)) + 1) >> 1); 25782 where the sign of 'narrow' determines whether this is a signed or 25783 unsigned operation, and N is the size of 'wide' in bits. 25784 25785'sdiv_pow2M3' 25786'sdiv_pow2M3' 25787 Signed division by power-of-2 immediate. Equivalent to: 25788 signed op0, op1; 25789 ... 25790 op0 = op1 / (1 << imm); 25791 25792'vec_shl_insert_M' 25793 Shift the elements in vector input operand 1 left one element (i.e. 25794 away from element 0) and fill the vacated element 0 with the scalar 25795 in operand 2. Store the result in vector output operand 0. 25796 Operands 0 and 1 have mode M and operand 2 has the mode appropriate 25797 for one element of M. 25798 25799'vec_shl_M' 25800 Whole vector left shift in bits, i.e. away from element 0. Operand 25801 1 is a vector to be shifted. Operand 2 is an integer shift amount 25802 in bits. Operand 0 is where the resulting shifted vector is 25803 stored. The output and input vectors should have the same modes. 25804 25805'vec_shr_M' 25806 Whole vector right shift in bits, i.e. towards element 0. Operand 25807 1 is a vector to be shifted. Operand 2 is an integer shift amount 25808 in bits. Operand 0 is where the resulting shifted vector is 25809 stored. The output and input vectors should have the same modes. 25810 25811'vec_pack_trunc_M' 25812 Narrow (demote) and merge the elements of two vectors. Operands 1 25813 and 2 are vectors of the same mode having N integral or floating 25814 point elements of size S. Operand 0 is the resulting vector in 25815 which 2*N elements of size S/2 are concatenated after narrowing 25816 them down using truncation. 25817 25818'vec_pack_sbool_trunc_M' 25819 Narrow and merge the elements of two vectors. Operands 1 and 2 are 25820 vectors of the same type having N boolean elements. Operand 0 is 25821 the resulting vector in which 2*N elements are concatenated. The 25822 last operand (operand 3) is the number of elements in the output 25823 vector 2*N as a 'CONST_INT'. This instruction pattern is used when 25824 all the vector input and output operands have the same scalar mode 25825 M and thus using 'vec_pack_trunc_M' would be ambiguous. 25826 25827'vec_pack_ssat_M', 'vec_pack_usat_M' 25828 Narrow (demote) and merge the elements of two vectors. Operands 1 25829 and 2 are vectors of the same mode having N integral elements of 25830 size S. Operand 0 is the resulting vector in which the elements of 25831 the two input vectors are concatenated after narrowing them down 25832 using signed/unsigned saturating arithmetic. 25833 25834'vec_pack_sfix_trunc_M', 'vec_pack_ufix_trunc_M' 25835 Narrow, convert to signed/unsigned integral type and merge the 25836 elements of two vectors. Operands 1 and 2 are vectors of the same 25837 mode having N floating point elements of size S. Operand 0 is the 25838 resulting vector in which 2*N elements of size S/2 are 25839 concatenated. 25840 25841'vec_packs_float_M', 'vec_packu_float_M' 25842 Narrow, convert to floating point type and merge the elements of 25843 two vectors. Operands 1 and 2 are vectors of the same mode having 25844 N signed/unsigned integral elements of size S. Operand 0 is the 25845 resulting vector in which 2*N elements of size S/2 are 25846 concatenated. 25847 25848'vec_unpacks_hi_M', 'vec_unpacks_lo_M' 25849 Extract and widen (promote) the high/low part of a vector of signed 25850 integral or floating point elements. The input vector (operand 1) 25851 has N elements of size S. Widen (promote) the high/low elements of 25852 the vector using signed or floating point extension and place the 25853 resulting N/2 values of size 2*S in the output vector (operand 0). 25854 25855'vec_unpacku_hi_M', 'vec_unpacku_lo_M' 25856 Extract and widen (promote) the high/low part of a vector of 25857 unsigned integral elements. The input vector (operand 1) has N 25858 elements of size S. Widen (promote) the high/low elements of the 25859 vector using zero extension and place the resulting N/2 values of 25860 size 2*S in the output vector (operand 0). 25861 25862'vec_unpacks_sbool_hi_M', 'vec_unpacks_sbool_lo_M' 25863 Extract the high/low part of a vector of boolean elements that have 25864 scalar mode M. The input vector (operand 1) has N elements, the 25865 output vector (operand 0) has N/2 elements. The last operand 25866 (operand 2) is the number of elements of the input vector N as a 25867 'CONST_INT'. These patterns are used if both the input and output 25868 vectors have the same scalar mode M and thus using 25869 'vec_unpacks_hi_M' or 'vec_unpacks_lo_M' would be ambiguous. 25870 25871'vec_unpacks_float_hi_M', 'vec_unpacks_float_lo_M' 25872'vec_unpacku_float_hi_M', 'vec_unpacku_float_lo_M' 25873 Extract, convert to floating point type and widen the high/low part 25874 of a vector of signed/unsigned integral elements. The input vector 25875 (operand 1) has N elements of size S. Convert the high/low 25876 elements of the vector using floating point conversion and place 25877 the resulting N/2 values of size 2*S in the output vector (operand 25878 0). 25879 25880'vec_unpack_sfix_trunc_hi_M', 25881'vec_unpack_sfix_trunc_lo_M' 25882'vec_unpack_ufix_trunc_hi_M' 25883'vec_unpack_ufix_trunc_lo_M' 25884 Extract, convert to signed/unsigned integer type and widen the 25885 high/low part of a vector of floating point elements. The input 25886 vector (operand 1) has N elements of size S. Convert the high/low 25887 elements of the vector to integers and place the resulting N/2 25888 values of size 2*S in the output vector (operand 0). 25889 25890'vec_widen_umult_hi_M', 'vec_widen_umult_lo_M' 25891'vec_widen_smult_hi_M', 'vec_widen_smult_lo_M' 25892'vec_widen_umult_even_M', 'vec_widen_umult_odd_M' 25893'vec_widen_smult_even_M', 'vec_widen_smult_odd_M' 25894 Signed/Unsigned widening multiplication. The two inputs (operands 25895 1 and 2) are vectors with N signed/unsigned elements of size S. 25896 Multiply the high/low or even/odd elements of the two vectors, and 25897 put the N/2 products of size 2*S in the output vector (operand 0). 25898 A target shouldn't implement even/odd pattern pair if it is less 25899 efficient than lo/hi one. 25900 25901'vec_widen_ushiftl_hi_M', 'vec_widen_ushiftl_lo_M' 25902'vec_widen_sshiftl_hi_M', 'vec_widen_sshiftl_lo_M' 25903 Signed/Unsigned widening shift left. The first input (operand 1) 25904 is a vector with N signed/unsigned elements of size S. Operand 2 25905 is a constant. Shift the high/low elements of operand 1, and put 25906 the N/2 results of size 2*S in the output vector (operand 0). 25907 25908'mulhisi3' 25909 Multiply operands 1 and 2, which have mode 'HImode', and store a 25910 'SImode' product in operand 0. 25911 25912'mulqihi3', 'mulsidi3' 25913 Similar widening-multiplication instructions of other widths. 25914 25915'umulqihi3', 'umulhisi3', 'umulsidi3' 25916 Similar widening-multiplication instructions that do unsigned 25917 multiplication. 25918 25919'usmulqihi3', 'usmulhisi3', 'usmulsidi3' 25920 Similar widening-multiplication instructions that interpret the 25921 first operand as unsigned and the second operand as signed, then do 25922 a signed multiplication. 25923 25924'smulM3_highpart' 25925 Perform a signed multiplication of operands 1 and 2, which have 25926 mode M, and store the most significant half of the product in 25927 operand 0. The least significant half of the product is discarded. 25928 25929'umulM3_highpart' 25930 Similar, but the multiplication is unsigned. 25931 25932'maddMN4' 25933 Multiply operands 1 and 2, sign-extend them to mode N, add operand 25934 3, and store the result in operand 0. Operands 1 and 2 have mode M 25935 and operands 0 and 3 have mode N. Both modes must be integer or 25936 fixed-point modes and N must be twice the size of M. 25937 25938 In other words, 'maddMN4' is like 'mulMN3' except that it also adds 25939 operand 3. 25940 25941 These instructions are not allowed to 'FAIL'. 25942 25943'umaddMN4' 25944 Like 'maddMN4', but zero-extend the multiplication operands instead 25945 of sign-extending them. 25946 25947'ssmaddMN4' 25948 Like 'maddMN4', but all involved operations must be 25949 signed-saturating. 25950 25951'usmaddMN4' 25952 Like 'umaddMN4', but all involved operations must be 25953 unsigned-saturating. 25954 25955'msubMN4' 25956 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 25957 result from operand 3, and store the result in operand 0. Operands 25958 1 and 2 have mode M and operands 0 and 3 have mode N. Both modes 25959 must be integer or fixed-point modes and N must be twice the size 25960 of M. 25961 25962 In other words, 'msubMN4' is like 'mulMN3' except that it also 25963 subtracts the result from operand 3. 25964 25965 These instructions are not allowed to 'FAIL'. 25966 25967'umsubMN4' 25968 Like 'msubMN4', but zero-extend the multiplication operands instead 25969 of sign-extending them. 25970 25971'ssmsubMN4' 25972 Like 'msubMN4', but all involved operations must be 25973 signed-saturating. 25974 25975'usmsubMN4' 25976 Like 'umsubMN4', but all involved operations must be 25977 unsigned-saturating. 25978 25979'divmodM4' 25980 Signed division that produces both a quotient and a remainder. 25981 Operand 1 is divided by operand 2 to produce a quotient stored in 25982 operand 0 and a remainder stored in operand 3. 25983 25984 For machines with an instruction that produces both a quotient and 25985 a remainder, provide a pattern for 'divmodM4' but do not provide 25986 patterns for 'divM3' and 'modM3'. This allows optimization in the 25987 relatively common case when both the quotient and remainder are 25988 computed. 25989 25990 If an instruction that just produces a quotient or just a remainder 25991 exists and is more efficient than the instruction that produces 25992 both, write the output routine of 'divmodM4' to call 25993 'find_reg_note' and look for a 'REG_UNUSED' note on the quotient or 25994 remainder and generate the appropriate instruction. 25995 25996'udivmodM4' 25997 Similar, but does unsigned division. 25998 25999'ashlM3', 'ssashlM3', 'usashlM3' 26000 Arithmetic-shift operand 1 left by a number of bits specified by 26001 operand 2, and store the result in operand 0. Here M is the mode 26002 of operand 0 and operand 1; operand 2's mode is specified by the 26003 instruction pattern, and the compiler will convert the operand to 26004 that mode before generating the instruction. The shift or rotate 26005 expander or instruction pattern should explicitly specify the mode 26006 of the operand 2, it should never be 'VOIDmode'. The meaning of 26007 out-of-range shift counts can optionally be specified by 26008 'TARGET_SHIFT_TRUNCATION_MASK'. *Note 26009 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 26010 26011'ashrM3', 'lshrM3', 'rotlM3', 'rotrM3' 26012 Other shift and rotate instructions, analogous to the 'ashlM3' 26013 instructions. Operand 2 is always a scalar type. 26014 26015'vashlM3', 'vashrM3', 'vlshrM3', 'vrotlM3', 'vrotrM3' 26016 Vector shift and rotate instructions that take vectors as operand 2 26017 instead of a scalar type. 26018 26019'avgM3_floor' 26020'uavgM3_floor' 26021 Signed and unsigned average instructions. These instructions add 26022 operands 1 and 2 without truncation, divide the result by 2, round 26023 towards -Inf, and store the result in operand 0. This is 26024 equivalent to the C code: 26025 narrow op0, op1, op2; 26026 ... 26027 op0 = (narrow) (((wide) op1 + (wide) op2) >> 1); 26028 where the sign of 'narrow' determines whether this is a signed or 26029 unsigned operation. 26030 26031'avgM3_ceil' 26032'uavgM3_ceil' 26033 Like 'avgM3_floor' and 'uavgM3_floor', but round towards +Inf. 26034 This is equivalent to the C code: 26035 narrow op0, op1, op2; 26036 ... 26037 op0 = (narrow) (((wide) op1 + (wide) op2 + 1) >> 1); 26038 26039'bswapM2' 26040 Reverse the order of bytes of operand 1 and store the result in 26041 operand 0. 26042 26043'negM2', 'ssnegM2', 'usnegM2' 26044 Negate operand 1 and store the result in operand 0. 26045 26046'negvM3' 26047 Like 'negM2' but takes a 'code_label' as operand 2 and emits code 26048 to jump to it if signed overflow occurs during the negation. 26049 26050'absM2' 26051 Store the absolute value of operand 1 into operand 0. 26052 26053'sqrtM2' 26054 Store the square root of operand 1 into operand 0. Both operands 26055 have mode M, which is a scalar or vector floating-point mode. 26056 26057 This pattern is not allowed to 'FAIL'. 26058 26059'rsqrtM2' 26060 Store the reciprocal of the square root of operand 1 into operand 26061 0. Both operands have mode M, which is a scalar or vector 26062 floating-point mode. 26063 26064 On most architectures this pattern is only approximate, so either 26065 its C condition or the 'TARGET_OPTAB_SUPPORTED_P' hook should check 26066 for the appropriate math flags. (Using the C condition is more 26067 direct, but using 'TARGET_OPTAB_SUPPORTED_P' can be useful if a 26068 target-specific built-in also uses the 'rsqrtM2' pattern.) 26069 26070 This pattern is not allowed to 'FAIL'. 26071 26072'fmodM3' 26073 Store the remainder of dividing operand 1 by operand 2 into operand 26074 0, rounded towards zero to an integer. All operands have mode M, 26075 which is a scalar or vector floating-point mode. 26076 26077 This pattern is not allowed to 'FAIL'. 26078 26079'remainderM3' 26080 Store the remainder of dividing operand 1 by operand 2 into operand 26081 0, rounded to the nearest integer. All operands have mode M, which 26082 is a scalar or vector floating-point mode. 26083 26084 This pattern is not allowed to 'FAIL'. 26085 26086'scalbM3' 26087 Raise 'FLT_RADIX' to the power of operand 2, multiply it by operand 26088 1, and store the result in operand 0. All operands have mode M, 26089 which is a scalar or vector floating-point mode. 26090 26091 This pattern is not allowed to 'FAIL'. 26092 26093'ldexpM3' 26094 Raise 2 to the power of operand 2, multiply it by operand 1, and 26095 store the result in operand 0. Operands 0 and 1 have mode M, which 26096 is a scalar or vector floating-point mode. Operand 2's mode has 26097 the same number of elements as M and each element is wide enough to 26098 store an 'int'. The integers are signed. 26099 26100 This pattern is not allowed to 'FAIL'. 26101 26102'cosM2' 26103 Store the cosine of operand 1 into operand 0. Both operands have 26104 mode M, which is a scalar or vector floating-point mode. 26105 26106 This pattern is not allowed to 'FAIL'. 26107 26108'sinM2' 26109 Store the sine of operand 1 into operand 0. Both operands have 26110 mode M, which is a scalar or vector floating-point mode. 26111 26112 This pattern is not allowed to 'FAIL'. 26113 26114'sincosM3' 26115 Store the cosine of operand 2 into operand 0 and the sine of 26116 operand 2 into operand 1. All operands have mode M, which is a 26117 scalar or vector floating-point mode. 26118 26119 Targets that can calculate the sine and cosine simultaneously can 26120 implement this pattern as opposed to implementing individual 26121 'sinM2' and 'cosM2' patterns. The 'sin' and 'cos' built-in 26122 functions will then be expanded to the 'sincosM3' pattern, with one 26123 of the output values left unused. 26124 26125'tanM2' 26126 Store the tangent of operand 1 into operand 0. Both operands have 26127 mode M, which is a scalar or vector floating-point mode. 26128 26129 This pattern is not allowed to 'FAIL'. 26130 26131'asinM2' 26132 Store the arc sine of operand 1 into operand 0. Both operands have 26133 mode M, which is a scalar or vector floating-point mode. 26134 26135 This pattern is not allowed to 'FAIL'. 26136 26137'acosM2' 26138 Store the arc cosine of operand 1 into operand 0. Both operands 26139 have mode M, which is a scalar or vector floating-point mode. 26140 26141 This pattern is not allowed to 'FAIL'. 26142 26143'atanM2' 26144 Store the arc tangent of operand 1 into operand 0. Both operands 26145 have mode M, which is a scalar or vector floating-point mode. 26146 26147 This pattern is not allowed to 'FAIL'. 26148 26149'expM2' 26150 Raise e (the base of natural logarithms) to the power of operand 1 26151 and store the result in operand 0. Both operands have mode M, 26152 which is a scalar or vector floating-point mode. 26153 26154 This pattern is not allowed to 'FAIL'. 26155 26156'expm1M2' 26157 Raise e (the base of natural logarithms) to the power of operand 1, 26158 subtract 1, and store the result in operand 0. Both operands have 26159 mode M, which is a scalar or vector floating-point mode. 26160 26161 For inputs close to zero, the pattern is expected to be more 26162 accurate than a separate 'expM2' and 'subM3' would be. 26163 26164 This pattern is not allowed to 'FAIL'. 26165 26166'exp10M2' 26167 Raise 10 to the power of operand 1 and store the result in operand 26168 0. Both operands have mode M, which is a scalar or vector 26169 floating-point mode. 26170 26171 This pattern is not allowed to 'FAIL'. 26172 26173'exp2M2' 26174 Raise 2 to the power of operand 1 and store the result in operand 26175 0. Both operands have mode M, which is a scalar or vector 26176 floating-point mode. 26177 26178 This pattern is not allowed to 'FAIL'. 26179 26180'logM2' 26181 Store the natural logarithm of operand 1 into operand 0. Both 26182 operands have mode M, which is a scalar or vector floating-point 26183 mode. 26184 26185 This pattern is not allowed to 'FAIL'. 26186 26187'log1pM2' 26188 Add 1 to operand 1, compute the natural logarithm, and store the 26189 result in operand 0. Both operands have mode M, which is a scalar 26190 or vector floating-point mode. 26191 26192 For inputs close to zero, the pattern is expected to be more 26193 accurate than a separate 'addM3' and 'logM2' would be. 26194 26195 This pattern is not allowed to 'FAIL'. 26196 26197'log10M2' 26198 Store the base-10 logarithm of operand 1 into operand 0. Both 26199 operands have mode M, which is a scalar or vector floating-point 26200 mode. 26201 26202 This pattern is not allowed to 'FAIL'. 26203 26204'log2M2' 26205 Store the base-2 logarithm of operand 1 into operand 0. Both 26206 operands have mode M, which is a scalar or vector floating-point 26207 mode. 26208 26209 This pattern is not allowed to 'FAIL'. 26210 26211'logbM2' 26212 Store the base-'FLT_RADIX' logarithm of operand 1 into operand 0. 26213 Both operands have mode M, which is a scalar or vector 26214 floating-point mode. 26215 26216 This pattern is not allowed to 'FAIL'. 26217 26218'significandM2' 26219 Store the significand of floating-point operand 1 in operand 0. 26220 Both operands have mode M, which is a scalar or vector 26221 floating-point mode. 26222 26223 This pattern is not allowed to 'FAIL'. 26224 26225'powM3' 26226 Store the value of operand 1 raised to the exponent operand 2 into 26227 operand 0. All operands have mode M, which is a scalar or vector 26228 floating-point mode. 26229 26230 This pattern is not allowed to 'FAIL'. 26231 26232'atan2M3' 26233 Store the arc tangent (inverse tangent) of operand 1 divided by 26234 operand 2 into operand 0, using the signs of both arguments to 26235 determine the quadrant of the result. All operands have mode M, 26236 which is a scalar or vector floating-point mode. 26237 26238 This pattern is not allowed to 'FAIL'. 26239 26240'floorM2' 26241 Store the largest integral value not greater than operand 1 in 26242 operand 0. Both operands have mode M, which is a scalar or vector 26243 floating-point mode. If '-ffp-int-builtin-inexact' is in effect, 26244 the "inexact" exception may be raised for noninteger operands; 26245 otherwise, it may not. 26246 26247 This pattern is not allowed to 'FAIL'. 26248 26249'btruncM2' 26250 Round operand 1 to an integer, towards zero, and store the result 26251 in operand 0. Both operands have mode M, which is a scalar or 26252 vector floating-point mode. If '-ffp-int-builtin-inexact' is in 26253 effect, the "inexact" exception may be raised for noninteger 26254 operands; otherwise, it may not. 26255 26256 This pattern is not allowed to 'FAIL'. 26257 26258'roundM2' 26259 Round operand 1 to the nearest integer, rounding away from zero in 26260 the event of a tie, and store the result in operand 0. Both 26261 operands have mode M, which is a scalar or vector floating-point 26262 mode. If '-ffp-int-builtin-inexact' is in effect, the "inexact" 26263 exception may be raised for noninteger operands; otherwise, it may 26264 not. 26265 26266 This pattern is not allowed to 'FAIL'. 26267 26268'ceilM2' 26269 Store the smallest integral value not less than operand 1 in 26270 operand 0. Both operands have mode M, which is a scalar or vector 26271 floating-point mode. If '-ffp-int-builtin-inexact' is in effect, 26272 the "inexact" exception may be raised for noninteger operands; 26273 otherwise, it may not. 26274 26275 This pattern is not allowed to 'FAIL'. 26276 26277'nearbyintM2' 26278 Round operand 1 to an integer, using the current rounding mode, and 26279 store the result in operand 0. Do not raise an inexact condition 26280 when the result is different from the argument. Both operands have 26281 mode M, which is a scalar or vector floating-point mode. 26282 26283 This pattern is not allowed to 'FAIL'. 26284 26285'rintM2' 26286 Round operand 1 to an integer, using the current rounding mode, and 26287 store the result in operand 0. Raise an inexact condition when the 26288 result is different from the argument. Both operands have mode M, 26289 which is a scalar or vector floating-point mode. 26290 26291 This pattern is not allowed to 'FAIL'. 26292 26293'lrintMN2' 26294 Convert operand 1 (valid for floating point mode M) to fixed point 26295 mode N as a signed number according to the current rounding mode 26296 and store in operand 0 (which has mode N). 26297 26298'lroundMN2' 26299 Convert operand 1 (valid for floating point mode M) to fixed point 26300 mode N as a signed number rounding to nearest and away from zero 26301 and store in operand 0 (which has mode N). 26302 26303'lfloorMN2' 26304 Convert operand 1 (valid for floating point mode M) to fixed point 26305 mode N as a signed number rounding down and store in operand 0 26306 (which has mode N). 26307 26308'lceilMN2' 26309 Convert operand 1 (valid for floating point mode M) to fixed point 26310 mode N as a signed number rounding up and store in operand 0 (which 26311 has mode N). 26312 26313'copysignM3' 26314 Store a value with the magnitude of operand 1 and the sign of 26315 operand 2 into operand 0. All operands have mode M, which is a 26316 scalar or vector floating-point mode. 26317 26318 This pattern is not allowed to 'FAIL'. 26319 26320'xorsignM3' 26321 Equivalent to 'op0 = op1 * copysign (1.0, op2)': store a value with 26322 the magnitude of operand 1 and the sign of operand 2 into operand 26323 0. All operands have mode M, which is a scalar or vector 26324 floating-point mode. 26325 26326 This pattern is not allowed to 'FAIL'. 26327 26328'ffsM2' 26329 Store into operand 0 one plus the index of the least significant 26330 1-bit of operand 1. If operand 1 is zero, store zero. 26331 26332 M is either a scalar or vector integer mode. When it is a scalar, 26333 operand 1 has mode M but operand 0 can have whatever scalar integer 26334 mode is suitable for the target. The compiler will insert 26335 conversion instructions as necessary (typically to convert the 26336 result to the same width as 'int'). When M is a vector, both 26337 operands must have mode M. 26338 26339 This pattern is not allowed to 'FAIL'. 26340 26341'clrsbM2' 26342 Count leading redundant sign bits. Store into operand 0 the number 26343 of redundant sign bits in operand 1, starting at the most 26344 significant bit position. A redundant sign bit is defined as any 26345 sign bit after the first. As such, this count will be one less 26346 than the count of leading sign bits. 26347 26348 M is either a scalar or vector integer mode. When it is a scalar, 26349 operand 1 has mode M but operand 0 can have whatever scalar integer 26350 mode is suitable for the target. The compiler will insert 26351 conversion instructions as necessary (typically to convert the 26352 result to the same width as 'int'). When M is a vector, both 26353 operands must have mode M. 26354 26355 This pattern is not allowed to 'FAIL'. 26356 26357'clzM2' 26358 Store into operand 0 the number of leading 0-bits in operand 1, 26359 starting at the most significant bit position. If operand 1 is 0, 26360 the 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 26361 result is undefined or has a useful value. 26362 26363 M is either a scalar or vector integer mode. When it is a scalar, 26364 operand 1 has mode M but operand 0 can have whatever scalar integer 26365 mode is suitable for the target. The compiler will insert 26366 conversion instructions as necessary (typically to convert the 26367 result to the same width as 'int'). When M is a vector, both 26368 operands must have mode M. 26369 26370 This pattern is not allowed to 'FAIL'. 26371 26372'ctzM2' 26373 Store into operand 0 the number of trailing 0-bits in operand 1, 26374 starting at the least significant bit position. If operand 1 is 0, 26375 the 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 26376 result is undefined or has a useful value. 26377 26378 M is either a scalar or vector integer mode. When it is a scalar, 26379 operand 1 has mode M but operand 0 can have whatever scalar integer 26380 mode is suitable for the target. The compiler will insert 26381 conversion instructions as necessary (typically to convert the 26382 result to the same width as 'int'). When M is a vector, both 26383 operands must have mode M. 26384 26385 This pattern is not allowed to 'FAIL'. 26386 26387'popcountM2' 26388 Store into operand 0 the number of 1-bits in operand 1. 26389 26390 M is either a scalar or vector integer mode. When it is a scalar, 26391 operand 1 has mode M but operand 0 can have whatever scalar integer 26392 mode is suitable for the target. The compiler will insert 26393 conversion instructions as necessary (typically to convert the 26394 result to the same width as 'int'). When M is a vector, both 26395 operands must have mode M. 26396 26397 This pattern is not allowed to 'FAIL'. 26398 26399'parityM2' 26400 Store into operand 0 the parity of operand 1, i.e. the number of 26401 1-bits in operand 1 modulo 2. 26402 26403 M is either a scalar or vector integer mode. When it is a scalar, 26404 operand 1 has mode M but operand 0 can have whatever scalar integer 26405 mode is suitable for the target. The compiler will insert 26406 conversion instructions as necessary (typically to convert the 26407 result to the same width as 'int'). When M is a vector, both 26408 operands must have mode M. 26409 26410 This pattern is not allowed to 'FAIL'. 26411 26412'one_cmplM2' 26413 Store the bitwise-complement of operand 1 into operand 0. 26414 26415'cpymemM' 26416 Block copy instruction. The destination and source blocks of 26417 memory are the first two operands, and both are 'mem:BLK's with an 26418 address in mode 'Pmode'. 26419 26420 The number of bytes to copy is the third operand, in mode M. 26421 Usually, you specify 'Pmode' for M. However, if you can generate 26422 better code knowing the range of valid lengths is smaller than 26423 those representable in a full Pmode pointer, you should provide a 26424 pattern with a mode corresponding to the range of values you can 26425 handle efficiently (e.g., 'QImode' for values in the range 0-127; 26426 note we avoid numbers that appear negative) and also a pattern with 26427 'Pmode'. 26428 26429 The fourth operand is the known shared alignment of the source and 26430 destination, in the form of a 'const_int' rtx. Thus, if the 26431 compiler knows that both source and destination are word-aligned, 26432 it may provide the value 4 for this operand. 26433 26434 Optional operands 5 and 6 specify expected alignment and size of 26435 block respectively. The expected alignment differs from alignment 26436 in operand 4 in a way that the blocks are not required to be 26437 aligned according to it in all cases. This expected alignment is 26438 also in bytes, just like operand 4. Expected size, when unknown, 26439 is set to '(const_int -1)'. 26440 26441 Descriptions of multiple 'cpymemM' patterns can only be beneficial 26442 if the patterns for smaller modes have fewer restrictions on their 26443 first, second and fourth operands. Note that the mode M in 26444 'cpymemM' does not impose any restriction on the mode of 26445 individually copied data units in the block. 26446 26447 The 'cpymemM' patterns need not give special consideration to the 26448 possibility that the source and destination strings might overlap. 26449 These patterns are used to do inline expansion of 26450 '__builtin_memcpy'. 26451 26452'movmemM' 26453 Block move instruction. The destination and source blocks of 26454 memory are the first two operands, and both are 'mem:BLK's with an 26455 address in mode 'Pmode'. 26456 26457 The number of bytes to copy is the third operand, in mode M. 26458 Usually, you specify 'Pmode' for M. However, if you can generate 26459 better code knowing the range of valid lengths is smaller than 26460 those representable in a full Pmode pointer, you should provide a 26461 pattern with a mode corresponding to the range of values you can 26462 handle efficiently (e.g., 'QImode' for values in the range 0-127; 26463 note we avoid numbers that appear negative) and also a pattern with 26464 'Pmode'. 26465 26466 The fourth operand is the known shared alignment of the source and 26467 destination, in the form of a 'const_int' rtx. Thus, if the 26468 compiler knows that both source and destination are word-aligned, 26469 it may provide the value 4 for this operand. 26470 26471 Optional operands 5 and 6 specify expected alignment and size of 26472 block respectively. The expected alignment differs from alignment 26473 in operand 4 in a way that the blocks are not required to be 26474 aligned according to it in all cases. This expected alignment is 26475 also in bytes, just like operand 4. Expected size, when unknown, 26476 is set to '(const_int -1)'. 26477 26478 Descriptions of multiple 'movmemM' patterns can only be beneficial 26479 if the patterns for smaller modes have fewer restrictions on their 26480 first, second and fourth operands. Note that the mode M in 26481 'movmemM' does not impose any restriction on the mode of 26482 individually copied data units in the block. 26483 26484 The 'movmemM' patterns must correctly handle the case where the 26485 source and destination strings overlap. These patterns are used to 26486 do inline expansion of '__builtin_memmove'. 26487 26488'movstr' 26489 String copy instruction, with 'stpcpy' semantics. Operand 0 is an 26490 output operand in mode 'Pmode'. The addresses of the destination 26491 and source strings are operands 1 and 2, and both are 'mem:BLK's 26492 with addresses in mode 'Pmode'. The execution of the expansion of 26493 this pattern should store in operand 0 the address in which the 26494 'NUL' terminator was stored in the destination string. 26495 26496 This pattern has also several optional operands that are same as in 26497 'setmem'. 26498 26499'setmemM' 26500 Block set instruction. The destination string is the first 26501 operand, given as a 'mem:BLK' whose address is in mode 'Pmode'. 26502 The number of bytes to set is the second operand, in mode M. The 26503 value to initialize the memory with is the third operand. Targets 26504 that only support the clearing of memory should reject any value 26505 that is not the constant 0. See 'cpymemM' for a discussion of the 26506 choice of mode. 26507 26508 The fourth operand is the known alignment of the destination, in 26509 the form of a 'const_int' rtx. Thus, if the compiler knows that 26510 the destination is word-aligned, it may provide the value 4 for 26511 this operand. 26512 26513 Optional operands 5 and 6 specify expected alignment and size of 26514 block respectively. The expected alignment differs from alignment 26515 in operand 4 in a way that the blocks are not required to be 26516 aligned according to it in all cases. This expected alignment is 26517 also in bytes, just like operand 4. Expected size, when unknown, 26518 is set to '(const_int -1)'. Operand 7 is the minimal size of the 26519 block and operand 8 is the maximal size of the block (NULL if it 26520 cannot be represented as CONST_INT). Operand 9 is the probable 26521 maximal size (i.e. we cannot rely on it for correctness, but it can 26522 be used for choosing proper code sequence for a given size). 26523 26524 The use for multiple 'setmemM' is as for 'cpymemM'. 26525 26526'cmpstrnM' 26527 String compare instruction, with five operands. Operand 0 is the 26528 output; it has mode M. The remaining four operands are like the 26529 operands of 'cpymemM'. The two memory blocks specified are 26530 compared byte by byte in lexicographic order starting at the 26531 beginning of each string. The instruction is not allowed to 26532 prefetch more than one byte at a time since either string may end 26533 in the first byte and reading past that may access an invalid page 26534 or segment and cause a fault. The comparison terminates early if 26535 the fetched bytes are different or if they are equal to zero. The 26536 effect of the instruction is to store a value in operand 0 whose 26537 sign indicates the result of the comparison. 26538 26539'cmpstrM' 26540 String compare instruction, without known maximum length. Operand 26541 0 is the output; it has mode M. The second and third operand are 26542 the blocks of memory to be compared; both are 'mem:BLK' with an 26543 address in mode 'Pmode'. 26544 26545 The fourth operand is the known shared alignment of the source and 26546 destination, in the form of a 'const_int' rtx. Thus, if the 26547 compiler knows that both source and destination are word-aligned, 26548 it may provide the value 4 for this operand. 26549 26550 The two memory blocks specified are compared byte by byte in 26551 lexicographic order starting at the beginning of each string. The 26552 instruction is not allowed to prefetch more than one byte at a time 26553 since either string may end in the first byte and reading past that 26554 may access an invalid page or segment and cause a fault. The 26555 comparison will terminate when the fetched bytes are different or 26556 if they are equal to zero. The effect of the instruction is to 26557 store a value in operand 0 whose sign indicates the result of the 26558 comparison. 26559 26560'cmpmemM' 26561 Block compare instruction, with five operands like the operands of 26562 'cmpstrM'. The two memory blocks specified are compared byte by 26563 byte in lexicographic order starting at the beginning of each 26564 block. Unlike 'cmpstrM' the instruction can prefetch any bytes in 26565 the two memory blocks. Also unlike 'cmpstrM' the comparison will 26566 not stop if both bytes are zero. The effect of the instruction is 26567 to store a value in operand 0 whose sign indicates the result of 26568 the comparison. 26569 26570'strlenM' 26571 Compute the length of a string, with three operands. Operand 0 is 26572 the result (of mode M), operand 1 is a 'mem' referring to the first 26573 character of the string, operand 2 is the character to search for 26574 (normally zero), and operand 3 is a constant describing the known 26575 alignment of the beginning of the string. 26576 26577'floatMN2' 26578 Convert signed integer operand 1 (valid for fixed point mode M) to 26579 floating point mode N and store in operand 0 (which has mode N). 26580 26581'floatunsMN2' 26582 Convert unsigned integer operand 1 (valid for fixed point mode M) 26583 to floating point mode N and store in operand 0 (which has mode N). 26584 26585'fixMN2' 26586 Convert operand 1 (valid for floating point mode M) to fixed point 26587 mode N as a signed number and store in operand 0 (which has mode 26588 N). This instruction's result is defined only when the value of 26589 operand 1 is an integer. 26590 26591 If the machine description defines this pattern, it also needs to 26592 define the 'ftrunc' pattern. 26593 26594'fixunsMN2' 26595 Convert operand 1 (valid for floating point mode M) to fixed point 26596 mode N as an unsigned number and store in operand 0 (which has mode 26597 N). This instruction's result is defined only when the value of 26598 operand 1 is an integer. 26599 26600'ftruncM2' 26601 Convert operand 1 (valid for floating point mode M) to an integer 26602 value, still represented in floating point mode M, and store it in 26603 operand 0 (valid for floating point mode M). 26604 26605'fix_truncMN2' 26606 Like 'fixMN2' but works for any floating point value of mode M by 26607 converting the value to an integer. 26608 26609'fixuns_truncMN2' 26610 Like 'fixunsMN2' but works for any floating point value of mode M 26611 by converting the value to an integer. 26612 26613'truncMN2' 26614 Truncate operand 1 (valid for mode M) to mode N and store in 26615 operand 0 (which has mode N). Both modes must be fixed point or 26616 both floating point. 26617 26618'extendMN2' 26619 Sign-extend operand 1 (valid for mode M) to mode N and store in 26620 operand 0 (which has mode N). Both modes must be fixed point or 26621 both floating point. 26622 26623'zero_extendMN2' 26624 Zero-extend operand 1 (valid for mode M) to mode N and store in 26625 operand 0 (which has mode N). Both modes must be fixed point. 26626 26627'fractMN2' 26628 Convert operand 1 of mode M to mode N and store in operand 0 (which 26629 has mode N). Mode M and mode N could be fixed-point to 26630 fixed-point, signed integer to fixed-point, fixed-point to signed 26631 integer, floating-point to fixed-point, or fixed-point to 26632 floating-point. When overflows or underflows happen, the results 26633 are undefined. 26634 26635'satfractMN2' 26636 Convert operand 1 of mode M to mode N and store in operand 0 (which 26637 has mode N). Mode M and mode N could be fixed-point to 26638 fixed-point, signed integer to fixed-point, or floating-point to 26639 fixed-point. When overflows or underflows happen, the instruction 26640 saturates the results to the maximum or the minimum. 26641 26642'fractunsMN2' 26643 Convert operand 1 of mode M to mode N and store in operand 0 (which 26644 has mode N). Mode M and mode N could be unsigned integer to 26645 fixed-point, or fixed-point to unsigned integer. When overflows or 26646 underflows happen, the results are undefined. 26647 26648'satfractunsMN2' 26649 Convert unsigned integer operand 1 of mode M to fixed-point mode N 26650 and store in operand 0 (which has mode N). When overflows or 26651 underflows happen, the instruction saturates the results to the 26652 maximum or the minimum. 26653 26654'extvM' 26655 Extract a bit-field from register operand 1, sign-extend it, and 26656 store it in operand 0. Operand 2 specifies the width of the field 26657 in bits and operand 3 the starting bit, which counts from the most 26658 significant bit if 'BITS_BIG_ENDIAN' is true and from the least 26659 significant bit otherwise. 26660 26661 Operands 0 and 1 both have mode M. Operands 2 and 3 have a 26662 target-specific mode. 26663 26664'extvmisalignM' 26665 Extract a bit-field from memory operand 1, sign extend it, and 26666 store it in operand 0. Operand 2 specifies the width in bits and 26667 operand 3 the starting bit. The starting bit is always somewhere 26668 in the first byte of operand 1; it counts from the most significant 26669 bit if 'BITS_BIG_ENDIAN' is true and from the least significant bit 26670 otherwise. 26671 26672 Operand 0 has mode M while operand 1 has 'BLK' mode. Operands 2 26673 and 3 have a target-specific mode. 26674 26675 The instruction must not read beyond the last byte of the 26676 bit-field. 26677 26678'extzvM' 26679 Like 'extvM' except that the bit-field value is zero-extended. 26680 26681'extzvmisalignM' 26682 Like 'extvmisalignM' except that the bit-field value is 26683 zero-extended. 26684 26685'insvM' 26686 Insert operand 3 into a bit-field of register operand 0. Operand 1 26687 specifies the width of the field in bits and operand 2 the starting 26688 bit, which counts from the most significant bit if 26689 'BITS_BIG_ENDIAN' is true and from the least significant bit 26690 otherwise. 26691 26692 Operands 0 and 3 both have mode M. Operands 1 and 2 have a 26693 target-specific mode. 26694 26695'insvmisalignM' 26696 Insert operand 3 into a bit-field of memory operand 0. Operand 1 26697 specifies the width of the field in bits and operand 2 the starting 26698 bit. The starting bit is always somewhere in the first byte of 26699 operand 0; it counts from the most significant bit if 26700 'BITS_BIG_ENDIAN' is true and from the least significant bit 26701 otherwise. 26702 26703 Operand 3 has mode M while operand 0 has 'BLK' mode. Operands 1 26704 and 2 have a target-specific mode. 26705 26706 The instruction must not read or write beyond the last byte of the 26707 bit-field. 26708 26709'extv' 26710 Extract a bit-field from operand 1 (a register or memory operand), 26711 where operand 2 specifies the width in bits and operand 3 the 26712 starting bit, and store it in operand 0. Operand 0 must have mode 26713 'word_mode'. Operand 1 may have mode 'byte_mode' or 'word_mode'; 26714 often 'word_mode' is allowed only for registers. Operands 2 and 3 26715 must be valid for 'word_mode'. 26716 26717 The RTL generation pass generates this instruction only with 26718 constants for operands 2 and 3 and the constant is never zero for 26719 operand 2. 26720 26721 The bit-field value is sign-extended to a full word integer before 26722 it is stored in operand 0. 26723 26724 This pattern is deprecated; please use 'extvM' and 'extvmisalignM' 26725 instead. 26726 26727'extzv' 26728 Like 'extv' except that the bit-field value is zero-extended. 26729 26730 This pattern is deprecated; please use 'extzvM' and 26731 'extzvmisalignM' instead. 26732 26733'insv' 26734 Store operand 3 (which must be valid for 'word_mode') into a 26735 bit-field in operand 0, where operand 1 specifies the width in bits 26736 and operand 2 the starting bit. Operand 0 may have mode 26737 'byte_mode' or 'word_mode'; often 'word_mode' is allowed only for 26738 registers. Operands 1 and 2 must be valid for 'word_mode'. 26739 26740 The RTL generation pass generates this instruction only with 26741 constants for operands 1 and 2 and the constant is never zero for 26742 operand 1. 26743 26744 This pattern is deprecated; please use 'insvM' and 'insvmisalignM' 26745 instead. 26746 26747'movMODEcc' 26748 Conditionally move operand 2 or operand 3 into operand 0 according 26749 to the comparison in operand 1. If the comparison is true, operand 26750 2 is moved into operand 0, otherwise operand 3 is moved. 26751 26752 The mode of the operands being compared need not be the same as the 26753 operands being moved. Some machines, sparc64 for example, have 26754 instructions that conditionally move an integer value based on the 26755 floating point condition codes and vice versa. 26756 26757 If the machine does not have conditional move instructions, do not 26758 define these patterns. 26759 26760'addMODEcc' 26761 Similar to 'movMODEcc' but for conditional addition. Conditionally 26762 move operand 2 or (operands 2 + operand 3) into operand 0 according 26763 to the comparison in operand 1. If the comparison is false, 26764 operand 2 is moved into operand 0, otherwise (operand 2 + operand 26765 3) is moved. 26766 26767'cond_addMODE' 26768'cond_subMODE' 26769'cond_mulMODE' 26770'cond_divMODE' 26771'cond_udivMODE' 26772'cond_modMODE' 26773'cond_umodMODE' 26774'cond_andMODE' 26775'cond_iorMODE' 26776'cond_xorMODE' 26777'cond_sminMODE' 26778'cond_smaxMODE' 26779'cond_uminMODE' 26780'cond_umaxMODE' 26781 When operand 1 is true, perform an operation on operands 2 and 3 26782 and store the result in operand 0, otherwise store operand 4 in 26783 operand 0. The operation works elementwise if the operands are 26784 vectors. 26785 26786 The scalar case is equivalent to: 26787 26788 op0 = op1 ? op2 OP op3 : op4; 26789 26790 while the vector case is equivalent to: 26791 26792 for (i = 0; i < GET_MODE_NUNITS (M); i++) 26793 op0[i] = op1[i] ? op2[i] OP op3[i] : op4[i]; 26794 26795 where, for example, OP is '+' for 'cond_addMODE'. 26796 26797 When defined for floating-point modes, the contents of 'op3[i]' are 26798 not interpreted if 'op1[i]' is false, just like they would not be 26799 in a normal C '?:' condition. 26800 26801 Operands 0, 2, 3 and 4 all have mode M. Operand 1 is a scalar 26802 integer if M is scalar, otherwise it has the mode returned by 26803 'TARGET_VECTORIZE_GET_MASK_MODE'. 26804 26805'cond_fmaMODE' 26806'cond_fmsMODE' 26807'cond_fnmaMODE' 26808'cond_fnmsMODE' 26809 Like 'cond_addM', except that the conditional operation takes 3 26810 operands rather than two. For example, the vector form of 26811 'cond_fmaMODE' is equivalent to: 26812 26813 for (i = 0; i < GET_MODE_NUNITS (M); i++) 26814 op0[i] = op1[i] ? fma (op2[i], op3[i], op4[i]) : op5[i]; 26815 26816'negMODEcc' 26817 Similar to 'movMODEcc' but for conditional negation. Conditionally 26818 move the negation of operand 2 or the unchanged operand 3 into 26819 operand 0 according to the comparison in operand 1. If the 26820 comparison is true, the negation of operand 2 is moved into operand 26821 0, otherwise operand 3 is moved. 26822 26823'notMODEcc' 26824 Similar to 'negMODEcc' but for conditional complement. 26825 Conditionally move the bitwise complement of operand 2 or the 26826 unchanged operand 3 into operand 0 according to the comparison in 26827 operand 1. If the comparison is true, the complement of operand 2 26828 is moved into operand 0, otherwise operand 3 is moved. 26829 26830'cstoreMODE4' 26831 Store zero or nonzero in operand 0 according to whether a 26832 comparison is true. Operand 1 is a comparison operator. Operand 2 26833 and operand 3 are the first and second operand of the comparison, 26834 respectively. You specify the mode that operand 0 must have when 26835 you write the 'match_operand' expression. The compiler 26836 automatically sees which mode you have used and supplies an operand 26837 of that mode. 26838 26839 The value stored for a true condition must have 1 as its low bit, 26840 or else must be negative. Otherwise the instruction is not 26841 suitable and you should omit it from the machine description. You 26842 describe to the compiler exactly which value is stored by defining 26843 the macro 'STORE_FLAG_VALUE' (*note Misc::). If a description 26844 cannot be found that can be used for all the possible comparison 26845 operators, you should pick one and use a 'define_expand' to map all 26846 results onto the one you chose. 26847 26848 These operations may 'FAIL', but should do so only in relatively 26849 uncommon cases; if they would 'FAIL' for common cases involving 26850 integer comparisons, it is best to restrict the predicates to not 26851 allow these operands. Likewise if a given comparison operator will 26852 always fail, independent of the operands (for floating-point modes, 26853 the 'ordered_comparison_operator' predicate is often useful in this 26854 case). 26855 26856 If this pattern is omitted, the compiler will generate a 26857 conditional branch--for example, it may copy a constant one to the 26858 target and branching around an assignment of zero to the target--or 26859 a libcall. If the predicate for operand 1 only rejects some 26860 operators, it will also try reordering the operands and/or 26861 inverting the result value (e.g. by an exclusive OR). These 26862 possibilities could be cheaper or equivalent to the instructions 26863 used for the 'cstoreMODE4' pattern followed by those required to 26864 convert a positive result from 'STORE_FLAG_VALUE' to 1; in this 26865 case, you can and should make operand 1's predicate reject some 26866 operators in the 'cstoreMODE4' pattern, or remove the pattern 26867 altogether from the machine description. 26868 26869'cbranchMODE4' 26870 Conditional branch instruction combined with a compare instruction. 26871 Operand 0 is a comparison operator. Operand 1 and operand 2 are 26872 the first and second operands of the comparison, respectively. 26873 Operand 3 is the 'code_label' to jump to. 26874 26875'jump' 26876 A jump inside a function; an unconditional branch. Operand 0 is 26877 the 'code_label' to jump to. This pattern name is mandatory on all 26878 machines. 26879 26880'call' 26881 Subroutine call instruction returning no value. Operand 0 is the 26882 function to call; operand 1 is the number of bytes of arguments 26883 pushed as a 'const_int'; operand 2 is the number of registers used 26884 as operands. 26885 26886 On most machines, operand 2 is not actually stored into the RTL 26887 pattern. It is supplied for the sake of some RISC machines which 26888 need to put this information into the assembler code; they can put 26889 it in the RTL instead of operand 1. 26890 26891 Operand 0 should be a 'mem' RTX whose address is the address of the 26892 function. Note, however, that this address can be a 'symbol_ref' 26893 expression even if it would not be a legitimate memory address on 26894 the target machine. If it is also not a valid argument for a call 26895 instruction, the pattern for this operation should be a 26896 'define_expand' (*note Expander Definitions::) that places the 26897 address into a register and uses that register in the call 26898 instruction. 26899 26900'call_value' 26901 Subroutine call instruction returning a value. Operand 0 is the 26902 hard register in which the value is returned. There are three more 26903 operands, the same as the three operands of the 'call' instruction 26904 (but with numbers increased by one). 26905 26906 Subroutines that return 'BLKmode' objects use the 'call' insn. 26907 26908'call_pop', 'call_value_pop' 26909 Similar to 'call' and 'call_value', except used if defined and if 26910 'RETURN_POPS_ARGS' is nonzero. They should emit a 'parallel' that 26911 contains both the function call and a 'set' to indicate the 26912 adjustment made to the frame pointer. 26913 26914 For machines where 'RETURN_POPS_ARGS' can be nonzero, the use of 26915 these patterns increases the number of functions for which the 26916 frame pointer can be eliminated, if desired. 26917 26918'untyped_call' 26919 Subroutine call instruction returning a value of any type. Operand 26920 0 is the function to call; operand 1 is a memory location where the 26921 result of calling the function is to be stored; operand 2 is a 26922 'parallel' expression where each element is a 'set' expression that 26923 indicates the saving of a function return value into the result 26924 block. 26925 26926 This instruction pattern should be defined to support 26927 '__builtin_apply' on machines where special instructions are needed 26928 to call a subroutine with arbitrary arguments or to save the value 26929 returned. This instruction pattern is required on machines that 26930 have multiple registers that can hold a return value (i.e. 26931 'FUNCTION_VALUE_REGNO_P' is true for more than one register). 26932 26933'return' 26934 Subroutine return instruction. This instruction pattern name 26935 should be defined only if a single instruction can do all the work 26936 of returning from a function. 26937 26938 Like the 'movM' patterns, this pattern is also used after the RTL 26939 generation phase. In this case it is to support machines where 26940 multiple instructions are usually needed to return from a function, 26941 but some class of functions only requires one instruction to 26942 implement a return. Normally, the applicable functions are those 26943 which do not need to save any registers or allocate stack space. 26944 26945 It is valid for this pattern to expand to an instruction using 26946 'simple_return' if no epilogue is required. 26947 26948'simple_return' 26949 Subroutine return instruction. This instruction pattern name 26950 should be defined only if a single instruction can do all the work 26951 of returning from a function on a path where no epilogue is 26952 required. This pattern is very similar to the 'return' instruction 26953 pattern, but it is emitted only by the shrink-wrapping optimization 26954 on paths where the function prologue has not been executed, and a 26955 function return should occur without any of the effects of the 26956 epilogue. Additional uses may be introduced on paths where both 26957 the prologue and the epilogue have executed. 26958 26959 For such machines, the condition specified in this pattern should 26960 only be true when 'reload_completed' is nonzero and the function's 26961 epilogue would only be a single instruction. For machines with 26962 register windows, the routine 'leaf_function_p' may be used to 26963 determine if a register window push is required. 26964 26965 Machines that have conditional return instructions should define 26966 patterns such as 26967 26968 (define_insn "" 26969 [(set (pc) 26970 (if_then_else (match_operator 26971 0 "comparison_operator" 26972 [(cc0) (const_int 0)]) 26973 (return) 26974 (pc)))] 26975 "CONDITION" 26976 "...") 26977 26978 where CONDITION would normally be the same condition specified on 26979 the named 'return' pattern. 26980 26981'untyped_return' 26982 Untyped subroutine return instruction. This instruction pattern 26983 should be defined to support '__builtin_return' on machines where 26984 special instructions are needed to return a value of any type. 26985 26986 Operand 0 is a memory location where the result of calling a 26987 function with '__builtin_apply' is stored; operand 1 is a 26988 'parallel' expression where each element is a 'set' expression that 26989 indicates the restoring of a function return value from the result 26990 block. 26991 26992'nop' 26993 No-op instruction. This instruction pattern name should always be 26994 defined to output a no-op in assembler code. '(const_int 0)' will 26995 do as an RTL pattern. 26996 26997'indirect_jump' 26998 An instruction to jump to an address which is operand zero. This 26999 pattern name is mandatory on all machines. 27000 27001'casesi' 27002 Instruction to jump through a dispatch table, including bounds 27003 checking. This instruction takes five operands: 27004 27005 1. The index to dispatch on, which has mode 'SImode'. 27006 27007 2. The lower bound for indices in the table, an integer constant. 27008 27009 3. The total range of indices in the table--the largest index 27010 minus the smallest one (both inclusive). 27011 27012 4. A label that precedes the table itself. 27013 27014 5. A label to jump to if the index has a value outside the 27015 bounds. 27016 27017 The table is an 'addr_vec' or 'addr_diff_vec' inside of a 27018 'jump_table_data'. The number of elements in the table is one plus 27019 the difference between the upper bound and the lower bound. 27020 27021'tablejump' 27022 Instruction to jump to a variable address. This is a low-level 27023 capability which can be used to implement a dispatch table when 27024 there is no 'casesi' pattern. 27025 27026 This pattern requires two operands: the address or offset, and a 27027 label which should immediately precede the jump table. If the 27028 macro 'CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 27029 the first operand is an offset which counts from the address of the 27030 table; otherwise, it is an absolute address to jump to. In either 27031 case, the first operand has mode 'Pmode'. 27032 27033 The 'tablejump' insn is always the last insn before the jump table 27034 it uses. Its assembler code normally has no need to use the second 27035 operand, but you should incorporate it in the RTL pattern so that 27036 the jump optimizer will not delete the table as unreachable code. 27037 27038'doloop_end' 27039 Conditional branch instruction that decrements a register and jumps 27040 if the register is nonzero. Operand 0 is the register to decrement 27041 and test; operand 1 is the label to jump to if the register is 27042 nonzero. *Note Looping Patterns::. 27043 27044 This optional instruction pattern should be defined for machines 27045 with low-overhead looping instructions as the loop optimizer will 27046 try to modify suitable loops to utilize it. The target hook 27047 'TARGET_CAN_USE_DOLOOP_P' controls the conditions under which 27048 low-overhead loops can be used. 27049 27050'doloop_begin' 27051 Companion instruction to 'doloop_end' required for machines that 27052 need to perform some initialization, such as loading a special 27053 counter register. Operand 1 is the associated 'doloop_end' pattern 27054 and operand 0 is the register that it decrements. 27055 27056 If initialization insns do not always need to be emitted, use a 27057 'define_expand' (*note Expander Definitions::) and make it fail. 27058 27059'canonicalize_funcptr_for_compare' 27060 Canonicalize the function pointer in operand 1 and store the result 27061 into operand 0. 27062 27063 Operand 0 is always a 'reg' and has mode 'Pmode'; operand 1 may be 27064 a 'reg', 'mem', 'symbol_ref', 'const_int', etc and also has mode 27065 'Pmode'. 27066 27067 Canonicalization of a function pointer usually involves computing 27068 the address of the function which would be called if the function 27069 pointer were used in an indirect call. 27070 27071 Only define this pattern if function pointers on the target machine 27072 can have different values but still call the same function when 27073 used in an indirect call. 27074 27075'save_stack_block' 27076'save_stack_function' 27077'save_stack_nonlocal' 27078'restore_stack_block' 27079'restore_stack_function' 27080'restore_stack_nonlocal' 27081 Most machines save and restore the stack pointer by copying it to 27082 or from an object of mode 'Pmode'. Do not define these patterns on 27083 such machines. 27084 27085 Some machines require special handling for stack pointer saves and 27086 restores. On those machines, define the patterns corresponding to 27087 the non-standard cases by using a 'define_expand' (*note Expander 27088 Definitions::) that produces the required insns. The three types 27089 of saves and restores are: 27090 27091 1. 'save_stack_block' saves the stack pointer at the start of a 27092 block that allocates a variable-sized object, and 27093 'restore_stack_block' restores the stack pointer when the 27094 block is exited. 27095 27096 2. 'save_stack_function' and 'restore_stack_function' do a 27097 similar job for the outermost block of a function and are used 27098 when the function allocates variable-sized objects or calls 27099 'alloca'. Only the epilogue uses the restored stack pointer, 27100 allowing a simpler save or restore sequence on some machines. 27101 27102 3. 'save_stack_nonlocal' is used in functions that contain labels 27103 branched to by nested functions. It saves the stack pointer 27104 in such a way that the inner function can use 27105 'restore_stack_nonlocal' to restore the stack pointer. The 27106 compiler generates code to restore the frame and argument 27107 pointer registers, but some machines require saving and 27108 restoring additional data such as register window information 27109 or stack backchains. Place insns in these patterns to save 27110 and restore any such required data. 27111 27112 When saving the stack pointer, operand 0 is the save area and 27113 operand 1 is the stack pointer. The mode used to allocate the save 27114 area defaults to 'Pmode' but you can override that choice by 27115 defining the 'STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 27116 You must specify an integral mode, or 'VOIDmode' if no save area is 27117 needed for a particular type of save (either because no save is 27118 needed or because a machine-specific save area can be used). 27119 Operand 0 is the stack pointer and operand 1 is the save area for 27120 restore operations. If 'save_stack_block' is defined, operand 0 27121 must not be 'VOIDmode' since these saves can be arbitrarily nested. 27122 27123 A save area is a 'mem' that is at a constant offset from 27124 'virtual_stack_vars_rtx' when the stack pointer is saved for use by 27125 nonlocal gotos and a 'reg' in the other two cases. 27126 27127'allocate_stack' 27128 Subtract (or add if 'STACK_GROWS_DOWNWARD' is undefined) operand 1 27129 from the stack pointer to create space for dynamically allocated 27130 data. 27131 27132 Store the resultant pointer to this space into operand 0. If you 27133 are allocating space from the main stack, do this by emitting a 27134 move insn to copy 'virtual_stack_dynamic_rtx' to operand 0. If you 27135 are allocating the space elsewhere, generate code to copy the 27136 location of the space to operand 0. In the latter case, you must 27137 ensure this space gets freed when the corresponding space on the 27138 main stack is free. 27139 27140 Do not define this pattern if all that must be done is the 27141 subtraction. Some machines require other operations such as stack 27142 probes or maintaining the back chain. Define this pattern to emit 27143 those operations in addition to updating the stack pointer. 27144 27145'check_stack' 27146 If stack checking (*note Stack Checking::) cannot be done on your 27147 system by probing the stack, define this pattern to perform the 27148 needed check and signal an error if the stack has overflowed. The 27149 single operand is the address in the stack farthest from the 27150 current stack pointer that you need to validate. Normally, on 27151 platforms where this pattern is needed, you would obtain the stack 27152 limit from a global or thread-specific variable or register. 27153 27154'probe_stack_address' 27155 If stack checking (*note Stack Checking::) can be done on your 27156 system by probing the stack but without the need to actually access 27157 it, define this pattern and signal an error if the stack has 27158 overflowed. The single operand is the memory address in the stack 27159 that needs to be probed. 27160 27161'probe_stack' 27162 If stack checking (*note Stack Checking::) can be done on your 27163 system by probing the stack but doing it with a "store zero" 27164 instruction is not valid or optimal, define this pattern to do the 27165 probing differently and signal an error if the stack has 27166 overflowed. The single operand is the memory reference in the 27167 stack that needs to be probed. 27168 27169'nonlocal_goto' 27170 Emit code to generate a non-local goto, e.g., a jump from one 27171 function to a label in an outer function. This pattern has four 27172 arguments, each representing a value to be used in the jump. The 27173 first argument is to be loaded into the frame pointer, the second 27174 is the address to branch to (code to dispatch to the actual label), 27175 the third is the address of a location where the stack is saved, 27176 and the last is the address of the label, to be placed in the 27177 location for the incoming static chain. 27178 27179 On most machines you need not define this pattern, since GCC will 27180 already generate the correct code, which is to load the frame 27181 pointer and static chain, restore the stack (using the 27182 'restore_stack_nonlocal' pattern, if defined), and jump indirectly 27183 to the dispatcher. You need only define this pattern if this code 27184 will not work on your machine. 27185 27186'nonlocal_goto_receiver' 27187 This pattern, if defined, contains code needed at the target of a 27188 nonlocal goto after the code already generated by GCC. You will 27189 not normally need to define this pattern. A typical reason why you 27190 might need this pattern is if some value, such as a pointer to a 27191 global table, must be restored when the frame pointer is restored. 27192 Note that a nonlocal goto only occurs within a unit-of-translation, 27193 so a global table pointer that is shared by all functions of a 27194 given module need not be restored. There are no arguments. 27195 27196'exception_receiver' 27197 This pattern, if defined, contains code needed at the site of an 27198 exception handler that isn't needed at the site of a nonlocal goto. 27199 You will not normally need to define this pattern. A typical 27200 reason why you might need this pattern is if some value, such as a 27201 pointer to a global table, must be restored after control flow is 27202 branched to the handler of an exception. There are no arguments. 27203 27204'builtin_setjmp_setup' 27205 This pattern, if defined, contains additional code needed to 27206 initialize the 'jmp_buf'. You will not normally need to define 27207 this pattern. A typical reason why you might need this pattern is 27208 if some value, such as a pointer to a global table, must be 27209 restored. Though it is preferred that the pointer value be 27210 recalculated if possible (given the address of a label for 27211 instance). The single argument is a pointer to the 'jmp_buf'. 27212 Note that the buffer is five words long and that the first three 27213 are normally used by the generic mechanism. 27214 27215'builtin_setjmp_receiver' 27216 This pattern, if defined, contains code needed at the site of a 27217 built-in setjmp that isn't needed at the site of a nonlocal goto. 27218 You will not normally need to define this pattern. A typical 27219 reason why you might need this pattern is if some value, such as a 27220 pointer to a global table, must be restored. It takes one 27221 argument, which is the label to which builtin_longjmp transferred 27222 control; this pattern may be emitted at a small offset from that 27223 label. 27224 27225'builtin_longjmp' 27226 This pattern, if defined, performs the entire action of the 27227 longjmp. You will not normally need to define this pattern unless 27228 you also define 'builtin_setjmp_setup'. The single argument is a 27229 pointer to the 'jmp_buf'. 27230 27231'eh_return' 27232 This pattern, if defined, affects the way '__builtin_eh_return', 27233 and thence the call frame exception handling library routines, are 27234 built. It is intended to handle non-trivial actions needed along 27235 the abnormal return path. 27236 27237 The address of the exception handler to which the function should 27238 return is passed as operand to this pattern. It will normally need 27239 to copied by the pattern to some special register or memory 27240 location. If the pattern needs to determine the location of the 27241 target call frame in order to do so, it may use 27242 'EH_RETURN_STACKADJ_RTX', if defined; it will have already been 27243 assigned. 27244 27245 If this pattern is not defined, the default action will be to 27246 simply copy the return address to 'EH_RETURN_HANDLER_RTX'. Either 27247 that macro or this pattern needs to be defined if call frame 27248 exception handling is to be used. 27249 27250'prologue' 27251 This pattern, if defined, emits RTL for entry to a function. The 27252 function entry is responsible for setting up the stack frame, 27253 initializing the frame pointer register, saving callee saved 27254 registers, etc. 27255 27256 Using a prologue pattern is generally preferred over defining 27257 'TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 27258 prologue. 27259 27260 The 'prologue' pattern is particularly useful for targets which 27261 perform instruction scheduling. 27262 27263'window_save' 27264 This pattern, if defined, emits RTL for a register window save. It 27265 should be defined if the target machine has register windows but 27266 the window events are decoupled from calls to subroutines. The 27267 canonical example is the SPARC architecture. 27268 27269'epilogue' 27270 This pattern emits RTL for exit from a function. The function exit 27271 is responsible for deallocating the stack frame, restoring callee 27272 saved registers and emitting the return instruction. 27273 27274 Using an epilogue pattern is generally preferred over defining 27275 'TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 27276 epilogue. 27277 27278 The 'epilogue' pattern is particularly useful for targets which 27279 perform instruction scheduling or which have delay slots for their 27280 return instruction. 27281 27282'sibcall_epilogue' 27283 This pattern, if defined, emits RTL for exit from a function 27284 without the final branch back to the calling function. This 27285 pattern will be emitted before any sibling call (aka tail call) 27286 sites. 27287 27288 The 'sibcall_epilogue' pattern must not clobber any arguments used 27289 for parameter passing or any stack slots for arguments passed to 27290 the current function. 27291 27292'trap' 27293 This pattern, if defined, signals an error, typically by causing 27294 some kind of signal to be raised. 27295 27296'ctrapMM4' 27297 Conditional trap instruction. Operand 0 is a piece of RTL which 27298 performs a comparison, and operands 1 and 2 are the arms of the 27299 comparison. Operand 3 is the trap code, an integer. 27300 27301 A typical 'ctrap' pattern looks like 27302 27303 (define_insn "ctrapsi4" 27304 [(trap_if (match_operator 0 "trap_operator" 27305 [(match_operand 1 "register_operand") 27306 (match_operand 2 "immediate_operand")]) 27307 (match_operand 3 "const_int_operand" "i"))] 27308 "" 27309 "...") 27310 27311'prefetch' 27312 This pattern, if defined, emits code for a non-faulting data 27313 prefetch instruction. Operand 0 is the address of the memory to 27314 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 27315 for a write to the memory address, or a constant 0 otherwise. 27316 Operand 2 is the expected degree of temporal locality of the data 27317 and is a value between 0 and 3, inclusive; 0 means that the data 27318 has no temporal locality, so it need not be left in the cache after 27319 the access; 3 means that the data has a high degree of temporal 27320 locality and should be left in all levels of cache possible; 1 and 27321 2 mean, respectively, a low or moderate degree of temporal 27322 locality. 27323 27324 Targets that do not support write prefetches or locality hints can 27325 ignore the values of operands 1 and 2. 27326 27327'blockage' 27328 This pattern defines a pseudo insn that prevents the instruction 27329 scheduler and other passes from moving instructions and using 27330 register equivalences across the boundary defined by the blockage 27331 insn. This needs to be an UNSPEC_VOLATILE pattern or a volatile 27332 ASM. 27333 27334'memory_blockage' 27335 This pattern, if defined, represents a compiler memory barrier, and 27336 will be placed at points across which RTL passes may not propagate 27337 memory accesses. This instruction needs to read and write volatile 27338 BLKmode memory. It does not need to generate any machine 27339 instruction. If this pattern is not defined, the compiler falls 27340 back to emitting an instruction corresponding to 'asm volatile ("" 27341 ::: "memory")'. 27342 27343'memory_barrier' 27344 If the target memory model is not fully synchronous, then this 27345 pattern should be defined to an instruction that orders both loads 27346 and stores before the instruction with respect to loads and stores 27347 after the instruction. This pattern has no operands. 27348 27349'speculation_barrier' 27350 If the target can support speculative execution, then this pattern 27351 should be defined to an instruction that will block subsequent 27352 execution until any prior speculation conditions has been resolved. 27353 The pattern must also ensure that the compiler cannot move memory 27354 operations past the barrier, so it needs to be an UNSPEC_VOLATILE 27355 pattern. The pattern has no operands. 27356 27357 If this pattern is not defined then the default expansion of 27358 '__builtin_speculation_safe_value' will emit a warning. You can 27359 suppress this warning by defining this pattern with a final 27360 condition of '0' (zero), which tells the compiler that a 27361 speculation barrier is not needed for this target. 27362 27363'sync_compare_and_swapMODE' 27364 This pattern, if defined, emits code for an atomic compare-and-swap 27365 operation. Operand 1 is the memory on which the atomic operation 27366 is performed. Operand 2 is the "old" value to be compared against 27367 the current contents of the memory location. Operand 3 is the 27368 "new" value to store in the memory if the compare succeeds. 27369 Operand 0 is the result of the operation; it should contain the 27370 contents of the memory before the operation. If the compare 27371 succeeds, this should obviously be a copy of operand 2. 27372 27373 This pattern must show that both operand 0 and operand 1 are 27374 modified. 27375 27376 This pattern must issue any memory barrier instructions such that 27377 all memory operations before the atomic operation occur before the 27378 atomic operation and all memory operations after the atomic 27379 operation occur after the atomic operation. 27380 27381 For targets where the success or failure of the compare-and-swap 27382 operation is available via the status flags, it is possible to 27383 avoid a separate compare operation and issue the subsequent branch 27384 or store-flag operation immediately after the compare-and-swap. To 27385 this end, GCC will look for a 'MODE_CC' set in the output of 27386 'sync_compare_and_swapMODE'; if the machine description includes 27387 such a set, the target should also define special 'cbranchcc4' 27388 and/or 'cstorecc4' instructions. GCC will then be able to take the 27389 destination of the 'MODE_CC' set and pass it to the 'cbranchcc4' or 27390 'cstorecc4' pattern as the first operand of the comparison (the 27391 second will be '(const_int 0)'). 27392 27393 For targets where the operating system may provide support for this 27394 operation via library calls, the 'sync_compare_and_swap_optab' may 27395 be initialized to a function with the same interface as the 27396 '__sync_val_compare_and_swap_N' built-in. If the entire set of 27397 __SYNC builtins are supported via library calls, the target can 27398 initialize all of the optabs at once with 'init_sync_libfuncs'. 27399 For the purposes of C++11 'std::atomic::is_lock_free', it is 27400 assumed that these library calls do _not_ use any kind of 27401 interruptable locking. 27402 27403'sync_addMODE', 'sync_subMODE' 27404'sync_iorMODE', 'sync_andMODE' 27405'sync_xorMODE', 'sync_nandMODE' 27406 These patterns emit code for an atomic operation on memory. 27407 Operand 0 is the memory on which the atomic operation is performed. 27408 Operand 1 is the second operand to the binary operator. 27409 27410 This pattern must issue any memory barrier instructions such that 27411 all memory operations before the atomic operation occur before the 27412 atomic operation and all memory operations after the atomic 27413 operation occur after the atomic operation. 27414 27415 If these patterns are not defined, the operation will be 27416 constructed from a compare-and-swap operation, if defined. 27417 27418'sync_old_addMODE', 'sync_old_subMODE' 27419'sync_old_iorMODE', 'sync_old_andMODE' 27420'sync_old_xorMODE', 'sync_old_nandMODE' 27421 These patterns emit code for an atomic operation on memory, and 27422 return the value that the memory contained before the operation. 27423 Operand 0 is the result value, operand 1 is the memory on which the 27424 atomic operation is performed, and operand 2 is the second operand 27425 to the binary operator. 27426 27427 This pattern must issue any memory barrier instructions such that 27428 all memory operations before the atomic operation occur before the 27429 atomic operation and all memory operations after the atomic 27430 operation occur after the atomic operation. 27431 27432 If these patterns are not defined, the operation will be 27433 constructed from a compare-and-swap operation, if defined. 27434 27435'sync_new_addMODE', 'sync_new_subMODE' 27436'sync_new_iorMODE', 'sync_new_andMODE' 27437'sync_new_xorMODE', 'sync_new_nandMODE' 27438 These patterns are like their 'sync_old_OP' counterparts, except 27439 that they return the value that exists in the memory location after 27440 the operation, rather than before the operation. 27441 27442'sync_lock_test_and_setMODE' 27443 This pattern takes two forms, based on the capabilities of the 27444 target. In either case, operand 0 is the result of the operand, 27445 operand 1 is the memory on which the atomic operation is performed, 27446 and operand 2 is the value to set in the lock. 27447 27448 In the ideal case, this operation is an atomic exchange operation, 27449 in which the previous value in memory operand is copied into the 27450 result operand, and the value operand is stored in the memory 27451 operand. 27452 27453 For less capable targets, any value operand that is not the 27454 constant 1 should be rejected with 'FAIL'. In this case the target 27455 may use an atomic test-and-set bit operation. The result operand 27456 should contain 1 if the bit was previously set and 0 if the bit was 27457 previously clear. The true contents of the memory operand are 27458 implementation defined. 27459 27460 This pattern must issue any memory barrier instructions such that 27461 the pattern as a whole acts as an acquire barrier, that is all 27462 memory operations after the pattern do not occur until the lock is 27463 acquired. 27464 27465 If this pattern is not defined, the operation will be constructed 27466 from a compare-and-swap operation, if defined. 27467 27468'sync_lock_releaseMODE' 27469 This pattern, if defined, releases a lock set by 27470 'sync_lock_test_and_setMODE'. Operand 0 is the memory that 27471 contains the lock; operand 1 is the value to store in the lock. 27472 27473 If the target doesn't implement full semantics for 27474 'sync_lock_test_and_setMODE', any value operand which is not the 27475 constant 0 should be rejected with 'FAIL', and the true contents of 27476 the memory operand are implementation defined. 27477 27478 This pattern must issue any memory barrier instructions such that 27479 the pattern as a whole acts as a release barrier, that is the lock 27480 is released only after all previous memory operations have 27481 completed. 27482 27483 If this pattern is not defined, then a 'memory_barrier' pattern 27484 will be emitted, followed by a store of the value to the memory 27485 operand. 27486 27487'atomic_compare_and_swapMODE' 27488 This pattern, if defined, emits code for an atomic compare-and-swap 27489 operation with memory model semantics. Operand 2 is the memory on 27490 which the atomic operation is performed. Operand 0 is an output 27491 operand which is set to true or false based on whether the 27492 operation succeeded. Operand 1 is an output operand which is set 27493 to the contents of the memory before the operation was attempted. 27494 Operand 3 is the value that is expected to be in memory. Operand 4 27495 is the value to put in memory if the expected value is found there. 27496 Operand 5 is set to 1 if this compare and swap is to be treated as 27497 a weak operation. Operand 6 is the memory model to be used if the 27498 operation is a success. Operand 7 is the memory model to be used 27499 if the operation fails. 27500 27501 If memory referred to in operand 2 contains the value in operand 3, 27502 then operand 4 is stored in memory pointed to by operand 2 and 27503 fencing based on the memory model in operand 6 is issued. 27504 27505 If memory referred to in operand 2 does not contain the value in 27506 operand 3, then fencing based on the memory model in operand 7 is 27507 issued. 27508 27509 If a target does not support weak compare-and-swap operations, or 27510 the port elects not to implement weak operations, the argument in 27511 operand 5 can be ignored. Note a strong implementation must be 27512 provided. 27513 27514 If this pattern is not provided, the '__atomic_compare_exchange' 27515 built-in functions will utilize the legacy 'sync_compare_and_swap' 27516 pattern with an '__ATOMIC_SEQ_CST' memory model. 27517 27518'atomic_loadMODE' 27519 This pattern implements an atomic load operation with memory model 27520 semantics. Operand 1 is the memory address being loaded from. 27521 Operand 0 is the result of the load. Operand 2 is the memory model 27522 to be used for the load operation. 27523 27524 If not present, the '__atomic_load' built-in function will either 27525 resort to a normal load with memory barriers, or a compare-and-swap 27526 operation if a normal load would not be atomic. 27527 27528'atomic_storeMODE' 27529 This pattern implements an atomic store operation with memory model 27530 semantics. Operand 0 is the memory address being stored to. 27531 Operand 1 is the value to be written. Operand 2 is the memory 27532 model to be used for the operation. 27533 27534 If not present, the '__atomic_store' built-in function will attempt 27535 to perform a normal store and surround it with any required memory 27536 fences. If the store would not be atomic, then an 27537 '__atomic_exchange' is attempted with the result being ignored. 27538 27539'atomic_exchangeMODE' 27540 This pattern implements an atomic exchange operation with memory 27541 model semantics. Operand 1 is the memory location the operation is 27542 performed on. Operand 0 is an output operand which is set to the 27543 original value contained in the memory pointed to by operand 1. 27544 Operand 2 is the value to be stored. Operand 3 is the memory model 27545 to be used. 27546 27547 If this pattern is not present, the built-in function 27548 '__atomic_exchange' will attempt to preform the operation with a 27549 compare and swap loop. 27550 27551'atomic_addMODE', 'atomic_subMODE' 27552'atomic_orMODE', 'atomic_andMODE' 27553'atomic_xorMODE', 'atomic_nandMODE' 27554 These patterns emit code for an atomic operation on memory with 27555 memory model semantics. Operand 0 is the memory on which the 27556 atomic operation is performed. Operand 1 is the second operand to 27557 the binary operator. Operand 2 is the memory model to be used by 27558 the operation. 27559 27560 If these patterns are not defined, attempts will be made to use 27561 legacy 'sync' patterns, or equivalent patterns which return a 27562 result. If none of these are available a compare-and-swap loop 27563 will be used. 27564 27565'atomic_fetch_addMODE', 'atomic_fetch_subMODE' 27566'atomic_fetch_orMODE', 'atomic_fetch_andMODE' 27567'atomic_fetch_xorMODE', 'atomic_fetch_nandMODE' 27568 These patterns emit code for an atomic operation on memory with 27569 memory model semantics, and return the original value. Operand 0 27570 is an output operand which contains the value of the memory 27571 location before the operation was performed. Operand 1 is the 27572 memory on which the atomic operation is performed. Operand 2 is 27573 the second operand to the binary operator. Operand 3 is the memory 27574 model to be used by the operation. 27575 27576 If these patterns are not defined, attempts will be made to use 27577 legacy 'sync' patterns. If none of these are available a 27578 compare-and-swap loop will be used. 27579 27580'atomic_add_fetchMODE', 'atomic_sub_fetchMODE' 27581'atomic_or_fetchMODE', 'atomic_and_fetchMODE' 27582'atomic_xor_fetchMODE', 'atomic_nand_fetchMODE' 27583 These patterns emit code for an atomic operation on memory with 27584 memory model semantics and return the result after the operation is 27585 performed. Operand 0 is an output operand which contains the value 27586 after the operation. Operand 1 is the memory on which the atomic 27587 operation is performed. Operand 2 is the second operand to the 27588 binary operator. Operand 3 is the memory model to be used by the 27589 operation. 27590 27591 If these patterns are not defined, attempts will be made to use 27592 legacy 'sync' patterns, or equivalent patterns which return the 27593 result before the operation followed by the arithmetic operation 27594 required to produce the result. If none of these are available a 27595 compare-and-swap loop will be used. 27596 27597'atomic_test_and_set' 27598 This pattern emits code for '__builtin_atomic_test_and_set'. 27599 Operand 0 is an output operand which is set to true if the previous 27600 previous contents of the byte was "set", and false otherwise. 27601 Operand 1 is the 'QImode' memory to be modified. Operand 2 is the 27602 memory model to be used. 27603 27604 The specific value that defines "set" is implementation defined, 27605 and is normally based on what is performed by the native atomic 27606 test and set instruction. 27607 27608'atomic_bit_test_and_setMODE' 27609'atomic_bit_test_and_complementMODE' 27610'atomic_bit_test_and_resetMODE' 27611 These patterns emit code for an atomic bitwise operation on memory 27612 with memory model semantics, and return the original value of the 27613 specified bit. Operand 0 is an output operand which contains the 27614 value of the specified bit from the memory location before the 27615 operation was performed. Operand 1 is the memory on which the 27616 atomic operation is performed. Operand 2 is the bit within the 27617 operand, starting with least significant bit. Operand 3 is the 27618 memory model to be used by the operation. Operand 4 is a flag - it 27619 is 'const1_rtx' if operand 0 should contain the original value of 27620 the specified bit in the least significant bit of the operand, and 27621 'const0_rtx' if the bit should be in its original position in the 27622 operand. 'atomic_bit_test_and_setMODE' atomically sets the 27623 specified bit after remembering its original value, 27624 'atomic_bit_test_and_complementMODE' inverts the specified bit and 27625 'atomic_bit_test_and_resetMODE' clears the specified bit. 27626 27627 If these patterns are not defined, attempts will be made to use 27628 'atomic_fetch_orMODE', 'atomic_fetch_xorMODE' or 27629 'atomic_fetch_andMODE' instruction patterns, or their 'sync' 27630 counterparts. If none of these are available a compare-and-swap 27631 loop will be used. 27632 27633'mem_thread_fence' 27634 This pattern emits code required to implement a thread fence with 27635 memory model semantics. Operand 0 is the memory model to be used. 27636 27637 For the '__ATOMIC_RELAXED' model no instructions need to be issued 27638 and this expansion is not invoked. 27639 27640 The compiler always emits a compiler memory barrier regardless of 27641 what expanding this pattern produced. 27642 27643 If this pattern is not defined, the compiler falls back to 27644 expanding the 'memory_barrier' pattern, then to emitting 27645 '__sync_synchronize' library call, and finally to just placing a 27646 compiler memory barrier. 27647 27648'get_thread_pointerMODE' 27649'set_thread_pointerMODE' 27650 These patterns emit code that reads/sets the TLS thread pointer. 27651 Currently, these are only needed if the target needs to support the 27652 '__builtin_thread_pointer' and '__builtin_set_thread_pointer' 27653 builtins. 27654 27655 The get/set patterns have a single output/input operand 27656 respectively, with MODE intended to be 'Pmode'. 27657 27658'stack_protect_combined_set' 27659 This pattern, if defined, moves a 'ptr_mode' value from an address 27660 whose declaration RTX is given in operand 1 to the memory in 27661 operand 0 without leaving the value in a register afterward. If 27662 several instructions are needed by the target to perform the 27663 operation (eg. to load the address from a GOT entry then load the 27664 'ptr_mode' value and finally store it), it is the backend's 27665 responsibility to ensure no intermediate result gets spilled. This 27666 is to avoid leaking the value some place that an attacker might use 27667 to rewrite the stack guard slot after having clobbered it. 27668 27669 If this pattern is not defined, then the address declaration is 27670 expanded first in the standard way and a 'stack_protect_set' 27671 pattern is then generated to move the value from that address to 27672 the address in operand 0. 27673 27674'stack_protect_set' 27675 This pattern, if defined, moves a 'ptr_mode' value from the valid 27676 memory location in operand 1 to the memory in operand 0 without 27677 leaving the value in a register afterward. This is to avoid 27678 leaking the value some place that an attacker might use to rewrite 27679 the stack guard slot after having clobbered it. 27680 27681 Note: on targets where the addressing modes do not allow to load 27682 directly from stack guard address, the address is expanded in a 27683 standard way first which could cause some spills. 27684 27685 If this pattern is not defined, then a plain move pattern is 27686 generated. 27687 27688'stack_protect_combined_test' 27689 This pattern, if defined, compares a 'ptr_mode' value from an 27690 address whose declaration RTX is given in operand 1 with the memory 27691 in operand 0 without leaving the value in a register afterward and 27692 branches to operand 2 if the values were equal. If several 27693 instructions are needed by the target to perform the operation (eg. 27694 to load the address from a GOT entry then load the 'ptr_mode' value 27695 and finally store it), it is the backend's responsibility to ensure 27696 no intermediate result gets spilled. This is to avoid leaking the 27697 value some place that an attacker might use to rewrite the stack 27698 guard slot after having clobbered it. 27699 27700 If this pattern is not defined, then the address declaration is 27701 expanded first in the standard way and a 'stack_protect_test' 27702 pattern is then generated to compare the value from that address to 27703 the value at the memory in operand 0. 27704 27705'stack_protect_test' 27706 This pattern, if defined, compares a 'ptr_mode' value from the 27707 valid memory location in operand 1 with the memory in operand 0 27708 without leaving the value in a register afterward and branches to 27709 operand 2 if the values were equal. 27710 27711 If this pattern is not defined, then a plain compare pattern and 27712 conditional branch pattern is used. 27713 27714'clear_cache' 27715 This pattern, if defined, flushes the instruction cache for a 27716 region of memory. The region is bounded to by the Pmode pointers 27717 in operand 0 inclusive and operand 1 exclusive. 27718 27719 If this pattern is not defined, a call to the library function 27720 '__clear_cache' is used. 27721 27722 27723File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 27724 2772517.10 When the Order of Patterns Matters 27726======================================== 27727 27728Sometimes an insn can match more than one instruction pattern. Then the 27729pattern that appears first in the machine description is the one used. 27730Therefore, more specific patterns (patterns that will match fewer 27731things) and faster instructions (those that will produce better code 27732when they do match) should usually go first in the description. 27733 27734 In some cases the effect of ordering the patterns can be used to hide a 27735pattern when it is not valid. For example, the 68000 has an instruction 27736for converting a fullword to floating point and another for converting a 27737byte to floating point. An instruction converting an integer to 27738floating point could match either one. We put the pattern to convert 27739the fullword first to make sure that one will be used rather than the 27740other. (Otherwise a large integer might be generated as a single-byte 27741immediate quantity, which would not work.) Instead of using this 27742pattern ordering it would be possible to make the pattern for 27743convert-a-byte smart enough to deal properly with any constant value. 27744 27745 27746File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 27747 2774817.11 Interdependence of Patterns 27749================================= 27750 27751In some cases machines support instructions identical except for the 27752machine mode of one or more operands. For example, there may be 27753"sign-extend halfword" and "sign-extend byte" instructions whose 27754patterns are 27755 27756 (set (match_operand:SI 0 ...) 27757 (extend:SI (match_operand:HI 1 ...))) 27758 27759 (set (match_operand:SI 0 ...) 27760 (extend:SI (match_operand:QI 1 ...))) 27761 27762Constant integers do not specify a machine mode, so an instruction to 27763extend a constant value could match either pattern. The pattern it 27764actually will match is the one that appears first in the file. For 27765correct results, this must be the one for the widest possible mode 27766('HImode', here). If the pattern matches the 'QImode' instruction, the 27767results will be incorrect if the constant value does not actually fit 27768that mode. 27769 27770 Such instructions to extend constants are rarely generated because they 27771are optimized away, but they do occasionally happen in nonoptimized 27772compilations. 27773 27774 If a constraint in a pattern allows a constant, the reload pass may 27775replace a register with a constant permitted by the constraint in some 27776cases. Similarly for memory references. Because of this substitution, 27777you should not provide separate patterns for increment and decrement 27778instructions. Instead, they should be generated from the same pattern 27779that supports register-register add insns by examining the operands and 27780generating the appropriate machine instruction. 27781 27782 27783File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 27784 2778517.12 Defining Jump Instruction Patterns 27786======================================== 27787 27788GCC does not assume anything about how the machine realizes jumps. The 27789machine description should define a single pattern, usually a 27790'define_expand', which expands to all the required insns. 27791 27792 Usually, this would be a comparison insn to set the condition code and 27793a separate branch insn testing the condition code and branching or not 27794according to its value. For many machines, however, separating compares 27795and branches is limiting, which is why the more flexible approach with 27796one 'define_expand' is used in GCC. The machine description becomes 27797clearer for architectures that have compare-and-branch instructions but 27798no condition code. It also works better when different sets of 27799comparison operators are supported by different kinds of conditional 27800branches (e.g. integer vs. floating-point), or by conditional branches 27801with respect to conditional stores. 27802 27803 Two separate insns are always used if the machine description 27804represents a condition code register using the legacy RTL expression 27805'(cc0)', and on most machines that use a separate condition code 27806register (*note Condition Code::). For machines that use '(cc0)', in 27807fact, the set and use of the condition code must be separate and 27808adjacent(1), thus allowing flags in 'cc_status' to be used (*note 27809Condition Code::) and so that the comparison and branch insns could be 27810located from each other by using the functions 'prev_cc0_setter' and 27811'next_cc0_user'. 27812 27813 Even in this case having a single entry point for conditional branches 27814is advantageous, because it handles equally well the case where a single 27815comparison instruction records the results of both signed and unsigned 27816comparison of the given operands (with the branch insns coming in 27817distinct signed and unsigned flavors) as in the x86 or SPARC, and the 27818case where there are distinct signed and unsigned compare instructions 27819and only one set of conditional branch instructions as in the PowerPC. 27820 27821 ---------- Footnotes ---------- 27822 27823 (1) 'note' insns can separate them, though. 27824 27825 27826File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 27827 2782817.13 Defining Looping Instruction Patterns 27829=========================================== 27830 27831Some machines have special jump instructions that can be utilized to 27832make loops more efficient. A common example is the 68000 'dbra' 27833instruction which performs a decrement of a register and a branch if the 27834result was greater than zero. Other machines, in particular digital 27835signal processors (DSPs), have special block repeat instructions to 27836provide low-overhead loop support. For example, the TI TMS320C3x/C4x 27837DSPs have a block repeat instruction that loads special registers to 27838mark the top and end of a loop and to count the number of loop 27839iterations. This avoids the need for fetching and executing a 27840'dbra'-like instruction and avoids pipeline stalls associated with the 27841jump. 27842 27843 GCC has two special named patterns to support low overhead looping. 27844They are 'doloop_begin' and 'doloop_end'. These are emitted by the loop 27845optimizer for certain well-behaved loops with a finite number of loop 27846iterations using information collected during strength reduction. 27847 27848 The 'doloop_end' pattern describes the actual looping instruction (or 27849the implicit looping operation) and the 'doloop_begin' pattern is an 27850optional companion pattern that can be used for initialization needed 27851for some low-overhead looping instructions. 27852 27853 Note that some machines require the actual looping instruction to be 27854emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 27855the true RTL for a looping instruction at the top of the loop can cause 27856problems with flow analysis. So instead, a dummy 'doloop' insn is 27857emitted at the end of the loop. The machine dependent reorg pass checks 27858for the presence of this 'doloop' insn and then searches back to the top 27859of the loop, where it inserts the true looping insn (provided there are 27860no instructions in the loop which would cause problems). Any additional 27861labels can be emitted at this point. In addition, if the desired 27862special iteration counter register was not allocated, this machine 27863dependent reorg pass could emit a traditional compare and jump 27864instruction pair. 27865 27866 For the 'doloop_end' pattern, the loop optimizer allocates an 27867additional pseudo register as an iteration counter. This pseudo 27868register cannot be used within the loop (i.e., general induction 27869variables cannot be derived from it), however, in many cases the loop 27870induction variable may become redundant and removed by the flow pass. 27871 27872 The 'doloop_end' pattern must have a specific structure to be handled 27873correctly by GCC. The example below is taken (slightly simplified) from 27874the PDP-11 target: 27875 27876 (define_expand "doloop_end" 27877 [(parallel [(set (pc) 27878 (if_then_else 27879 (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m") 27880 (const_int 1)) 27881 (label_ref (match_operand 1 "" "")) 27882 (pc))) 27883 (set (match_dup 0) 27884 (plus:HI (match_dup 0) 27885 (const_int -1)))])] 27886 "" 27887 "{ 27888 if (GET_MODE (operands[0]) != HImode) 27889 FAIL; 27890 }") 27891 27892 (define_insn "doloop_end_insn" 27893 [(set (pc) 27894 (if_then_else 27895 (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m") 27896 (const_int 1)) 27897 (label_ref (match_operand 1 "" "")) 27898 (pc))) 27899 (set (match_dup 0) 27900 (plus:HI (match_dup 0) 27901 (const_int -1)))] 27902 "" 27903 27904 { 27905 if (which_alternative == 0) 27906 return "sob %0,%l1"; 27907 27908 /* emulate sob */ 27909 output_asm_insn ("dec %0", operands); 27910 return "bne %l1"; 27911 }) 27912 27913 The first part of the pattern describes the branch condition. GCC 27914supports three cases for the way the target machine handles the loop 27915counter: 27916 * Loop terminates when the loop register decrements to zero. This is 27917 represented by a 'ne' comparison of the register (its old value) 27918 with constant 1 (as in the example above). 27919 * Loop terminates when the loop register decrements to -1. This is 27920 represented by a 'ne' comparison of the register with constant 27921 zero. 27922 * Loop terminates when the loop register decrements to a negative 27923 value. This is represented by a 'ge' comparison of the register 27924 with constant zero. For this case, GCC will attach a 'REG_NONNEG' 27925 note to the 'doloop_end' insn if it can determine that the register 27926 will be non-negative. 27927 27928 Since the 'doloop_end' insn is a jump insn that also has an output, the 27929reload pass does not handle the output operand. Therefore, the 27930constraint must allow for that operand to be in memory rather than a 27931register. In the example shown above, that is handled (in the 27932'doloop_end_insn' pattern) by using a loop instruction sequence that can 27933handle memory operands when the memory alternative appears. 27934 27935 GCC does not check the mode of the loop register operand when 27936generating the 'doloop_end' pattern. If the pattern is only valid for 27937some modes but not others, the pattern should be a 'define_expand' 27938pattern that checks the operand mode in the preparation code, and issues 27939'FAIL' if an unsupported mode is found. The example above does this, 27940since the machine instruction to be used only exists for 'HImode'. 27941 27942 If the 'doloop_end' pattern is a 'define_expand', there must also be a 27943'define_insn' or 'define_insn_and_split' matching the generated pattern. 27944Otherwise, the compiler will fail during loop optimization. 27945 27946 27947File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 27948 2794917.14 Canonicalization of Instructions 27950====================================== 27951 27952There are often cases where multiple RTL expressions could represent an 27953operation performed by a single machine instruction. This situation is 27954most commonly encountered with logical, branch, and multiply-accumulate 27955instructions. In such cases, the compiler attempts to convert these 27956multiple RTL expressions into a single canonical form to reduce the 27957number of insn patterns required. 27958 27959 In addition to algebraic simplifications, following canonicalizations 27960are performed: 27961 27962 * For commutative and comparison operators, a constant is always made 27963 the second operand. If a machine only supports a constant as the 27964 second operand, only patterns that match a constant in the second 27965 operand need be supplied. 27966 27967 * For associative operators, a sequence of operators will always 27968 chain to the left; for instance, only the left operand of an 27969 integer 'plus' can itself be a 'plus'. 'and', 'ior', 'xor', 27970 'plus', 'mult', 'smin', 'smax', 'umin', and 'umax' are associative 27971 when applied to integers, and sometimes to floating-point. 27972 27973 * For these operators, if only one operand is a 'neg', 'not', 'mult', 27974 'plus', or 'minus' expression, it will be the first operand. 27975 27976 * In combinations of 'neg', 'mult', 'plus', and 'minus', the 'neg' 27977 operations (if any) will be moved inside the operations as far as 27978 possible. For instance, '(neg (mult A B))' is canonicalized as 27979 '(mult (neg A) B)', but '(plus (mult (neg B) C) A)' is 27980 canonicalized as '(minus A (mult B C))'. 27981 27982 * For the 'compare' operator, a constant is always the second operand 27983 if the first argument is a condition code register or '(cc0)'. 27984 27985 * For instructions that inherently set a condition code register, the 27986 'compare' operator is always written as the first RTL expression of 27987 the 'parallel' instruction pattern. For example, 27988 27989 (define_insn "" 27990 [(set (reg:CCZ FLAGS_REG) 27991 (compare:CCZ 27992 (plus:SI 27993 (match_operand:SI 1 "register_operand" "%r") 27994 (match_operand:SI 2 "register_operand" "r")) 27995 (const_int 0))) 27996 (set (match_operand:SI 0 "register_operand" "=r") 27997 (plus:SI (match_dup 1) (match_dup 2)))] 27998 "" 27999 "addl %0, %1, %2") 28000 28001 * An operand of 'neg', 'not', 'mult', 'plus', or 'minus' is made the 28002 first operand under the same conditions as above. 28003 28004 * '(ltu (plus A B) B)' is converted to '(ltu (plus A B) A)'. 28005 Likewise with 'geu' instead of 'ltu'. 28006 28007 * '(minus X (const_int N))' is converted to '(plus X (const_int 28008 -N))'. 28009 28010 * Within address computations (i.e., inside 'mem'), a left shift is 28011 converted into the appropriate multiplication by a power of two. 28012 28013 * De Morgan's Law is used to move bitwise negation inside a bitwise 28014 logical-and or logical-or operation. If this results in only one 28015 operand being a 'not' expression, it will be the first one. 28016 28017 A machine that has an instruction that performs a bitwise 28018 logical-and of one operand with the bitwise negation of the other 28019 should specify the pattern for that instruction as 28020 28021 (define_insn "" 28022 [(set (match_operand:M 0 ...) 28023 (and:M (not:M (match_operand:M 1 ...)) 28024 (match_operand:M 2 ...)))] 28025 "..." 28026 "...") 28027 28028 Similarly, a pattern for a "NAND" instruction should be written 28029 28030 (define_insn "" 28031 [(set (match_operand:M 0 ...) 28032 (ior:M (not:M (match_operand:M 1 ...)) 28033 (not:M (match_operand:M 2 ...))))] 28034 "..." 28035 "...") 28036 28037 In both cases, it is not necessary to include patterns for the many 28038 logically equivalent RTL expressions. 28039 28040 * The only possible RTL expressions involving both bitwise 28041 exclusive-or and bitwise negation are '(xor:M X Y)' and '(not:M 28042 (xor:M X Y))'. 28043 28044 * The sum of three items, one of which is a constant, will only 28045 appear in the form 28046 28047 (plus:M (plus:M X Y) CONSTANT) 28048 28049 * Equality comparisons of a group of bits (usually a single bit) with 28050 zero will be written using 'zero_extract' rather than the 28051 equivalent 'and' or 'sign_extract' operations. 28052 28053 * '(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))' 28054 is converted to '(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))', 28055 and likewise for 'zero_extend'. 28056 28057 * '(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))' 28058 is converted to '(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S)) 28059 (sign_extend:M1 Y))', and likewise for patterns using 'zero_extend' 28060 and 'lshiftrt'. If the second operand of 'mult' is also a shift, 28061 then that is extended also. This transformation is only applied 28062 when it can be proven that the original operation had sufficient 28063 precision to prevent overflow. 28064 28065 Further canonicalization rules are defined in the function 28066'commutative_operand_precedence' in 'gcc/rtlanal.c'. 28067 28068 28069File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 28070 2807117.15 Defining RTL Sequences for Code Generation 28072================================================ 28073 28074On some target machines, some standard pattern names for RTL generation 28075cannot be handled with single insn, but a sequence of RTL insns can 28076represent them. For these target machines, you can write a 28077'define_expand' to specify how to generate the sequence of RTL. 28078 28079 A 'define_expand' is an RTL expression that looks almost like a 28080'define_insn'; but, unlike the latter, a 'define_expand' is used only 28081for RTL generation and it can produce more than one RTL insn. 28082 28083 A 'define_expand' RTX has four operands: 28084 28085 * The name. Each 'define_expand' must have a name, since the only 28086 use for it is to refer to it by name. 28087 28088 * The RTL template. This is a vector of RTL expressions representing 28089 a sequence of separate instructions. Unlike 'define_insn', there 28090 is no implicit surrounding 'PARALLEL'. 28091 28092 * The condition, a string containing a C expression. This expression 28093 is used to express how the availability of this pattern depends on 28094 subclasses of target machine, selected by command-line options when 28095 GCC is run. This is just like the condition of a 'define_insn' 28096 that has a standard name. Therefore, the condition (if present) 28097 may not depend on the data in the insn being matched, but only the 28098 target-machine-type flags. The compiler needs to test these 28099 conditions during initialization in order to learn exactly which 28100 named instructions are available in a particular run. 28101 28102 * The preparation statements, a string containing zero or more C 28103 statements which are to be executed before RTL code is generated 28104 from the RTL template. 28105 28106 Usually these statements prepare temporary registers for use as 28107 internal operands in the RTL template, but they can also generate 28108 RTL insns directly by calling routines such as 'emit_insn', etc. 28109 Any such insns precede the ones that come from the RTL template. 28110 28111 * Optionally, a vector containing the values of attributes. *Note 28112 Insn Attributes::. 28113 28114 Every RTL insn emitted by a 'define_expand' must match some 28115'define_insn' in the machine description. Otherwise, the compiler will 28116crash when trying to generate code for the insn or trying to optimize 28117it. 28118 28119 The RTL template, in addition to controlling generation of RTL insns, 28120also describes the operands that need to be specified when this pattern 28121is used. In particular, it gives a predicate for each operand. 28122 28123 A true operand, which needs to be specified in order to generate RTL 28124from the pattern, should be described with a 'match_operand' in its 28125first occurrence in the RTL template. This enters information on the 28126operand's predicate into the tables that record such things. GCC uses 28127the information to preload the operand into a register if that is 28128required for valid RTL code. If the operand is referred to more than 28129once, subsequent references should use 'match_dup'. 28130 28131 The RTL template may also refer to internal "operands" which are 28132temporary registers or labels used only within the sequence made by the 28133'define_expand'. Internal operands are substituted into the RTL 28134template with 'match_dup', never with 'match_operand'. The values of 28135the internal operands are not passed in as arguments by the compiler 28136when it requests use of this pattern. Instead, they are computed within 28137the pattern, in the preparation statements. These statements compute 28138the values and store them into the appropriate elements of 'operands' so 28139that 'match_dup' can find them. 28140 28141 There are two special macros defined for use in the preparation 28142statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 28143a statement. 28144 28145'DONE' 28146 Use the 'DONE' macro to end RTL generation for the pattern. The 28147 only RTL insns resulting from the pattern on this occasion will be 28148 those already emitted by explicit calls to 'emit_insn' within the 28149 preparation statements; the RTL template will not be generated. 28150 28151'FAIL' 28152 Make the pattern fail on this occasion. When a pattern fails, it 28153 means that the pattern was not truly available. The calling 28154 routines in the compiler will try other strategies for code 28155 generation using other patterns. 28156 28157 Failure is currently supported only for binary (addition, 28158 multiplication, shifting, etc.) and bit-field ('extv', 'extzv', 28159 and 'insv') operations. 28160 28161 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 28162then the 'define_expand' acts like a 'define_insn' in that the RTL 28163template is used to generate the insn. 28164 28165 The RTL template is not used for matching, only for generating the 28166initial insn list. If the preparation statement always invokes 'DONE' 28167or 'FAIL', the RTL template may be reduced to a simple list of operands, 28168such as this example: 28169 28170 (define_expand "addsi3" 28171 [(match_operand:SI 0 "register_operand" "") 28172 (match_operand:SI 1 "register_operand" "") 28173 (match_operand:SI 2 "register_operand" "")] 28174 "" 28175 " 28176 { 28177 handle_add (operands[0], operands[1], operands[2]); 28178 DONE; 28179 }") 28180 28181 Here is an example, the definition of left-shift for the SPUR chip: 28182 28183 (define_expand "ashlsi3" 28184 [(set (match_operand:SI 0 "register_operand" "") 28185 (ashift:SI 28186 (match_operand:SI 1 "register_operand" "") 28187 (match_operand:SI 2 "nonmemory_operand" "")))] 28188 "" 28189 " 28190 28191 { 28192 if (GET_CODE (operands[2]) != CONST_INT 28193 || (unsigned) INTVAL (operands[2]) > 3) 28194 FAIL; 28195 }") 28196 28197This example uses 'define_expand' so that it can generate an RTL insn 28198for shifting when the shift-count is in the supported range of 0 to 3 28199but fail in other cases where machine insns aren't available. When it 28200fails, the compiler tries another strategy using different patterns 28201(such as, a library call). 28202 28203 If the compiler were able to handle nontrivial condition-strings in 28204patterns with names, then it would be possible to use a 'define_insn' in 28205that case. Here is another case (zero-extension on the 68000) which 28206makes more use of the power of 'define_expand': 28207 28208 (define_expand "zero_extendhisi2" 28209 [(set (match_operand:SI 0 "general_operand" "") 28210 (const_int 0)) 28211 (set (strict_low_part 28212 (subreg:HI 28213 (match_dup 0) 28214 0)) 28215 (match_operand:HI 1 "general_operand" ""))] 28216 "" 28217 "operands[1] = make_safe_from (operands[1], operands[0]);") 28218 28219Here two RTL insns are generated, one to clear the entire output operand 28220and the other to copy the input operand into its low half. This 28221sequence is incorrect if the input operand refers to [the old value of] 28222the output operand, so the preparation statement makes sure this isn't 28223so. The function 'make_safe_from' copies the 'operands[1]' into a 28224temporary register if it refers to 'operands[0]'. It does this by 28225emitting another RTL insn. 28226 28227 Finally, a third example shows the use of an internal operand. 28228Zero-extension on the SPUR chip is done by 'and'-ing the result against 28229a halfword mask. But this mask cannot be represented by a 'const_int' 28230because the constant value is too large to be legitimate on this 28231machine. So it must be copied into a register with 'force_reg' and then 28232the register used in the 'and'. 28233 28234 (define_expand "zero_extendhisi2" 28235 [(set (match_operand:SI 0 "register_operand" "") 28236 (and:SI (subreg:SI 28237 (match_operand:HI 1 "register_operand" "") 28238 0) 28239 (match_dup 2)))] 28240 "" 28241 "operands[2] 28242 = force_reg (SImode, GEN_INT (65535)); ") 28243 28244 _Note:_ If the 'define_expand' is used to serve a standard binary or 28245unary arithmetic operation or a bit-field operation, then the last insn 28246it generates must not be a 'code_label', 'barrier' or 'note'. It must 28247be an 'insn', 'jump_insn' or 'call_insn'. If you don't need a real insn 28248at the end, emit an insn to copy the result of the operation into 28249itself. Such an insn will generate no code, but it can avoid problems 28250in the compiler. 28251 28252 28253File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 28254 2825517.16 Defining How to Split Instructions 28256======================================== 28257 28258There are two cases where you should specify how to split a pattern into 28259multiple insns. On machines that have instructions requiring delay 28260slots (*note Delay Slots::) or that have instructions whose output is 28261not available for multiple cycles (*note Processor pipeline 28262description::), the compiler phases that optimize these cases need to be 28263able to move insns into one-instruction delay slots. However, some 28264insns may generate more than one machine instruction. These insns 28265cannot be placed into a delay slot. 28266 28267 Often you can rewrite the single insn as a list of individual insns, 28268each corresponding to one machine instruction. The disadvantage of 28269doing so is that it will cause the compilation to be slower and require 28270more space. If the resulting insns are too complex, it may also 28271suppress some optimizations. The compiler splits the insn if there is a 28272reason to believe that it might improve instruction or delay slot 28273scheduling. 28274 28275 The insn combiner phase also splits putative insns. If three insns are 28276merged into one insn with a complex expression that cannot be matched by 28277some 'define_insn' pattern, the combiner phase attempts to split the 28278complex pattern into two insns that are recognized. Usually it can 28279break the complex pattern into two patterns by splitting out some 28280subexpression. However, in some other cases, such as performing an 28281addition of a large constant in two insns on a RISC machine, the way to 28282split the addition into two insns is machine-dependent. 28283 28284 The 'define_split' definition tells the compiler how to split a complex 28285insn into several simpler insns. It looks like this: 28286 28287 (define_split 28288 [INSN-PATTERN] 28289 "CONDITION" 28290 [NEW-INSN-PATTERN-1 28291 NEW-INSN-PATTERN-2 28292 ...] 28293 "PREPARATION-STATEMENTS") 28294 28295 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 28296final condition to be tested, as in a 'define_insn'. When an insn 28297matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 28298in the insn list with the insns given by NEW-INSN-PATTERN-1, 28299NEW-INSN-PATTERN-2, etc. 28300 28301 The PREPARATION-STATEMENTS are similar to those statements that are 28302specified for 'define_expand' (*note Expander Definitions::) and are 28303executed before the new RTL is generated to prepare for the generated 28304code or emit some insns whose pattern is not fixed. Unlike those in 28305'define_expand', however, these statements must not generate any new 28306pseudo-registers. Once reload has completed, they also must not 28307allocate any space in the stack frame. 28308 28309 There are two special macros defined for use in the preparation 28310statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 28311a statement. 28312 28313'DONE' 28314 Use the 'DONE' macro to end RTL generation for the splitter. The 28315 only RTL insns generated as replacement for the matched input insn 28316 will be those already emitted by explicit calls to 'emit_insn' 28317 within the preparation statements; the replacement pattern is not 28318 used. 28319 28320'FAIL' 28321 Make the 'define_split' fail on this occasion. When a 28322 'define_split' fails, it means that the splitter was not truly 28323 available for the inputs it was given, and the input insn will not 28324 be split. 28325 28326 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 28327then the 'define_split' uses the replacement template. 28328 28329 Patterns are matched against INSN-PATTERN in two different 28330circumstances. If an insn needs to be split for delay slot scheduling 28331or insn scheduling, the insn is already known to be valid, which means 28332that it must have been matched by some 'define_insn' and, if 28333'reload_completed' is nonzero, is known to satisfy the constraints of 28334that 'define_insn'. In that case, the new insn patterns must also be 28335insns that are matched by some 'define_insn' and, if 'reload_completed' 28336is nonzero, must also satisfy the constraints of those definitions. 28337 28338 As an example of this usage of 'define_split', consider the following 28339example from 'a29k.md', which splits a 'sign_extend' from 'HImode' to 28340'SImode' into a pair of shift insns: 28341 28342 (define_split 28343 [(set (match_operand:SI 0 "gen_reg_operand" "") 28344 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 28345 "" 28346 [(set (match_dup 0) 28347 (ashift:SI (match_dup 1) 28348 (const_int 16))) 28349 (set (match_dup 0) 28350 (ashiftrt:SI (match_dup 0) 28351 (const_int 16)))] 28352 " 28353 { operands[1] = gen_lowpart (SImode, operands[1]); }") 28354 28355 When the combiner phase tries to split an insn pattern, it is always 28356the case that the pattern is _not_ matched by any 'define_insn'. The 28357combiner pass first tries to split a single 'set' expression and then 28358the same 'set' expression inside a 'parallel', but followed by a 28359'clobber' of a pseudo-reg to use as a scratch register. In these cases, 28360the combiner expects exactly one or two new insn patterns to be 28361generated. It will verify that these patterns match some 'define_insn' 28362definitions, so you need not do this test in the 'define_split' (of 28363course, there is no point in writing a 'define_split' that will never 28364produce insns that match). 28365 28366 Here is an example of this use of 'define_split', taken from 28367'rs6000.md': 28368 28369 (define_split 28370 [(set (match_operand:SI 0 "gen_reg_operand" "") 28371 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 28372 (match_operand:SI 2 "non_add_cint_operand" "")))] 28373 "" 28374 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 28375 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 28376 " 28377 { 28378 int low = INTVAL (operands[2]) & 0xffff; 28379 int high = (unsigned) INTVAL (operands[2]) >> 16; 28380 28381 if (low & 0x8000) 28382 high++, low |= 0xffff0000; 28383 28384 operands[3] = GEN_INT (high << 16); 28385 operands[4] = GEN_INT (low); 28386 }") 28387 28388 Here the predicate 'non_add_cint_operand' matches any 'const_int' that 28389is _not_ a valid operand of a single add insn. The add with the smaller 28390displacement is written so that it can be substituted into the address 28391of a subsequent operation. 28392 28393 An example that uses a scratch register, from the same file, generates 28394an equality comparison of a register and a large constant: 28395 28396 (define_split 28397 [(set (match_operand:CC 0 "cc_reg_operand" "") 28398 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 28399 (match_operand:SI 2 "non_short_cint_operand" ""))) 28400 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 28401 "find_single_use (operands[0], insn, 0) 28402 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 28403 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 28404 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 28405 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 28406 " 28407 { 28408 /* Get the constant we are comparing against, C, and see what it 28409 looks like sign-extended to 16 bits. Then see what constant 28410 could be XOR'ed with C to get the sign-extended value. */ 28411 28412 int c = INTVAL (operands[2]); 28413 int sextc = (c << 16) >> 16; 28414 int xorv = c ^ sextc; 28415 28416 operands[4] = GEN_INT (xorv); 28417 operands[5] = GEN_INT (sextc); 28418 }") 28419 28420 To avoid confusion, don't write a single 'define_split' that accepts 28421some insns that match some 'define_insn' as well as some insns that 28422don't. Instead, write two separate 'define_split' definitions, one for 28423the insns that are valid and one for the insns that are not valid. 28424 28425 The splitter is allowed to split jump instructions into sequence of 28426jumps or create new jumps in while splitting non-jump instructions. As 28427the control flow graph and branch prediction information needs to be 28428updated, several restriction apply. 28429 28430 Splitting of jump instruction into sequence that over by another jump 28431instruction is always valid, as compiler expect identical behavior of 28432new jump. When new sequence contains multiple jump instructions or new 28433labels, more assistance is needed. Splitter is required to create only 28434unconditional jumps, or simple conditional jump instructions. 28435Additionally it must attach a 'REG_BR_PROB' note to each conditional 28436jump. A global variable 'split_branch_probability' holds the 28437probability of the original branch in case it was a simple conditional 28438jump, -1 otherwise. To simplify recomputing of edge frequencies, the 28439new sequence is required to have only forward jumps to the newly created 28440labels. 28441 28442 For the common case where the pattern of a define_split exactly matches 28443the pattern of a define_insn, use 'define_insn_and_split'. It looks 28444like this: 28445 28446 (define_insn_and_split 28447 [INSN-PATTERN] 28448 "CONDITION" 28449 "OUTPUT-TEMPLATE" 28450 "SPLIT-CONDITION" 28451 [NEW-INSN-PATTERN-1 28452 NEW-INSN-PATTERN-2 28453 ...] 28454 "PREPARATION-STATEMENTS" 28455 [INSN-ATTRIBUTES]) 28456 28457 28458 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 28459as in 'define_insn'. The NEW-INSN-PATTERN vector and the 28460PREPARATION-STATEMENTS are used as in a 'define_split'. The 28461SPLIT-CONDITION is also used as in 'define_split', with the additional 28462behavior that if the condition starts with '&&', the condition used for 28463the split will be the constructed as a logical "and" of the split 28464condition with the insn condition. For example, from i386.md: 28465 28466 (define_insn_and_split "zero_extendhisi2_and" 28467 [(set (match_operand:SI 0 "register_operand" "=r") 28468 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 28469 (clobber (reg:CC 17))] 28470 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 28471 "#" 28472 "&& reload_completed" 28473 [(parallel [(set (match_dup 0) 28474 (and:SI (match_dup 0) (const_int 65535))) 28475 (clobber (reg:CC 17))])] 28476 "" 28477 [(set_attr "type" "alu1")]) 28478 28479 28480 In this case, the actual split condition will be 28481'TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 28482 28483 The 'define_insn_and_split' construction provides exactly the same 28484functionality as two separate 'define_insn' and 'define_split' patterns. 28485It exists for compactness, and as a maintenance tool to prevent having 28486to ensure the two patterns' templates match. 28487 28488 It is sometimes useful to have a 'define_insn_and_split' that replaces 28489specific operands of an instruction but leaves the rest of the 28490instruction pattern unchanged. You can do this directly with a 28491'define_insn_and_split', but it requires a NEW-INSN-PATTERN-1 that 28492repeats most of the original INSN-PATTERN. There is also the 28493complication that an implicit 'parallel' in INSN-PATTERN must become an 28494explicit 'parallel' in NEW-INSN-PATTERN-1, which is easy to overlook. A 28495simpler alternative is to use 'define_insn_and_rewrite', which is a form 28496of 'define_insn_and_split' that automatically generates 28497NEW-INSN-PATTERN-1 by replacing each 'match_operand' in INSN-PATTERN 28498with a corresponding 'match_dup', and each 'match_operator' in the 28499pattern with a corresponding 'match_op_dup'. The arguments are 28500otherwise identical to 'define_insn_and_split': 28501 28502 (define_insn_and_rewrite 28503 [INSN-PATTERN] 28504 "CONDITION" 28505 "OUTPUT-TEMPLATE" 28506 "SPLIT-CONDITION" 28507 "PREPARATION-STATEMENTS" 28508 [INSN-ATTRIBUTES]) 28509 28510 The 'match_dup's and 'match_op_dup's in the new instruction pattern use 28511any new operand values that the PREPARATION-STATEMENTS store in the 28512'operands' array, as for a normal 'define_insn_and_split'. 28513PREPARATION-STATEMENTS can also emit additional instructions before the 28514new instruction. They can even emit an entirely different sequence of 28515instructions and use 'DONE' to avoid emitting a new form of the original 28516instruction. 28517 28518 The split in a 'define_insn_and_rewrite' is only intended to apply to 28519existing instructions that match INSN-PATTERN. SPLIT-CONDITION must 28520therefore start with '&&', so that the split condition applies on top of 28521CONDITION. 28522 28523 Here is an example from the AArch64 SVE port, in which operand 1 is 28524known to be equivalent to an all-true constant and isn't used by the 28525output template: 28526 28527 (define_insn_and_rewrite "*while_ult<GPI:mode><PRED_ALL:mode>_cc" 28528 [(set (reg:CC CC_REGNUM) 28529 (compare:CC 28530 (unspec:SI [(match_operand:PRED_ALL 1) 28531 (unspec:PRED_ALL 28532 [(match_operand:GPI 2 "aarch64_reg_or_zero" "rZ") 28533 (match_operand:GPI 3 "aarch64_reg_or_zero" "rZ")] 28534 UNSPEC_WHILE_LO)] 28535 UNSPEC_PTEST_PTRUE) 28536 (const_int 0))) 28537 (set (match_operand:PRED_ALL 0 "register_operand" "=Upa") 28538 (unspec:PRED_ALL [(match_dup 2) 28539 (match_dup 3)] 28540 UNSPEC_WHILE_LO))] 28541 "TARGET_SVE" 28542 "whilelo\t%0.<PRED_ALL:Vetype>, %<w>2, %<w>3" 28543 ;; Force the compiler to drop the unused predicate operand, so that we 28544 ;; don't have an unnecessary PTRUE. 28545 "&& !CONSTANT_P (operands[1])" 28546 { 28547 operands[1] = CONSTM1_RTX (<MODE>mode); 28548 } 28549 ) 28550 28551 The splitter in this case simply replaces operand 1 with the constant 28552value that it is known to have. The equivalent 'define_insn_and_split' 28553would be: 28554 28555 (define_insn_and_split "*while_ult<GPI:mode><PRED_ALL:mode>_cc" 28556 [(set (reg:CC CC_REGNUM) 28557 (compare:CC 28558 (unspec:SI [(match_operand:PRED_ALL 1) 28559 (unspec:PRED_ALL 28560 [(match_operand:GPI 2 "aarch64_reg_or_zero" "rZ") 28561 (match_operand:GPI 3 "aarch64_reg_or_zero" "rZ")] 28562 UNSPEC_WHILE_LO)] 28563 UNSPEC_PTEST_PTRUE) 28564 (const_int 0))) 28565 (set (match_operand:PRED_ALL 0 "register_operand" "=Upa") 28566 (unspec:PRED_ALL [(match_dup 2) 28567 (match_dup 3)] 28568 UNSPEC_WHILE_LO))] 28569 "TARGET_SVE" 28570 "whilelo\t%0.<PRED_ALL:Vetype>, %<w>2, %<w>3" 28571 ;; Force the compiler to drop the unused predicate operand, so that we 28572 ;; don't have an unnecessary PTRUE. 28573 "&& !CONSTANT_P (operands[1])" 28574 [(parallel 28575 [(set (reg:CC CC_REGNUM) 28576 (compare:CC 28577 (unspec:SI [(match_dup 1) 28578 (unspec:PRED_ALL [(match_dup 2) 28579 (match_dup 3)] 28580 UNSPEC_WHILE_LO)] 28581 UNSPEC_PTEST_PTRUE) 28582 (const_int 0))) 28583 (set (match_dup 0) 28584 (unspec:PRED_ALL [(match_dup 2) 28585 (match_dup 3)] 28586 UNSPEC_WHILE_LO))])] 28587 { 28588 operands[1] = CONSTM1_RTX (<MODE>mode); 28589 } 28590 ) 28591 28592 28593File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 28594 2859517.17 Including Patterns in Machine Descriptions. 28596================================================= 28597 28598The 'include' pattern tells the compiler tools where to look for 28599patterns that are in files other than in the file '.md'. This is used 28600only at build time and there is no preprocessing allowed. 28601 28602 It looks like: 28603 28604 28605 (include 28606 PATHNAME) 28607 28608 For example: 28609 28610 28611 (include "filestuff") 28612 28613 28614 Where PATHNAME is a string that specifies the location of the file, 28615specifies the include file to be in 'gcc/config/target/filestuff'. The 28616directory 'gcc/config/target' is regarded as the default directory. 28617 28618 Machine descriptions may be split up into smaller more manageable 28619subsections and placed into subdirectories. 28620 28621 By specifying: 28622 28623 28624 (include "BOGUS/filestuff") 28625 28626 28627 the include file is specified to be in 28628'gcc/config/TARGET/BOGUS/filestuff'. 28629 28630 Specifying an absolute path for the include file such as; 28631 28632 (include "/u2/BOGUS/filestuff") 28633 28634 is permitted but is not encouraged. 28635 2863617.17.1 RTL Generation Tool Options for Directory Search 28637-------------------------------------------------------- 28638 28639The '-IDIR' option specifies directories to search for machine 28640descriptions. For example: 28641 28642 28643 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 28644 28645 28646 Add the directory DIR to the head of the list of directories to be 28647searched for header files. This can be used to override a system 28648machine definition file, substituting your own version, since these 28649directories are searched before the default machine description file 28650directories. If you use more than one '-I' option, the directories are 28651scanned in left-to-right order; the standard default directory come 28652after. 28653 28654 28655File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 28656 2865717.18 Machine-Specific Peephole Optimizers 28658========================================== 28659 28660In addition to instruction patterns the 'md' file may contain 28661definitions of machine-specific peephole optimizations. 28662 28663 The combiner does not notice certain peephole optimizations when the 28664data flow in the program does not suggest that it should try them. For 28665example, sometimes two consecutive insns related in purpose can be 28666combined even though the second one does not appear to use a register 28667computed in the first one. A machine-specific peephole optimizer can 28668detect such opportunities. 28669 28670 There are two forms of peephole definitions that may be used. The 28671original 'define_peephole' is run at assembly output time to match insns 28672and substitute assembly text. Use of 'define_peephole' is deprecated. 28673 28674 A newer 'define_peephole2' matches insns and substitutes new insns. 28675The 'peephole2' pass is run after register allocation but before 28676scheduling, which may result in much better code for targets that do 28677scheduling. 28678 28679* Menu: 28680 28681* define_peephole:: RTL to Text Peephole Optimizers 28682* define_peephole2:: RTL to RTL Peephole Optimizers 28683 28684 28685File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 28686 2868717.18.1 RTL to Text Peephole Optimizers 28688--------------------------------------- 28689 28690A definition looks like this: 28691 28692 (define_peephole 28693 [INSN-PATTERN-1 28694 INSN-PATTERN-2 28695 ...] 28696 "CONDITION" 28697 "TEMPLATE" 28698 "OPTIONAL-INSN-ATTRIBUTES") 28699 28700The last string operand may be omitted if you are not using any 28701machine-specific information in this machine description. If present, 28702it must obey the same rules as in a 'define_insn'. 28703 28704 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 28705consecutive insns. The optimization applies to a sequence of insns when 28706INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 28707and so on. 28708 28709 Each of the insns matched by a peephole must also match a 28710'define_insn'. Peepholes are checked only at the last stage just before 28711code generation, and only optionally. Therefore, any insn which would 28712match a peephole but no 'define_insn' will cause a crash in code 28713generation in an unoptimized compilation, or at various optimization 28714stages. 28715 28716 The operands of the insns are matched with 'match_operands', 28717'match_operator', and 'match_dup', as usual. What is not usual is that 28718the operand numbers apply to all the insn patterns in the definition. 28719So, you can check for identical operands in two insns by using 28720'match_operand' in one insn and 'match_dup' in the other. 28721 28722 The operand constraints used in 'match_operand' patterns do not have 28723any direct effect on the applicability of the peephole, but they will be 28724validated afterward, so make sure your constraints are general enough to 28725apply whenever the peephole matches. If the peephole matches but the 28726constraints are not satisfied, the compiler will crash. 28727 28728 It is safe to omit constraints in all the operands of the peephole; or 28729you can write constraints which serve as a double-check on the criteria 28730previously tested. 28731 28732 Once a sequence of insns matches the patterns, the CONDITION is 28733checked. This is a C expression which makes the final decision whether 28734to perform the optimization (we do so if the expression is nonzero). If 28735CONDITION is omitted (in other words, the string is empty) then the 28736optimization is applied to every sequence of insns that matches the 28737patterns. 28738 28739 The defined peephole optimizations are applied after register 28740allocation is complete. Therefore, the peephole definition can check 28741which operands have ended up in which kinds of registers, just by 28742looking at the operands. 28743 28744 The way to refer to the operands in CONDITION is to write 'operands[I]' 28745for operand number I (as matched by '(match_operand I ...)'). Use the 28746variable 'insn' to refer to the last of the insns being matched; use 28747'prev_active_insn' to find the preceding insns. 28748 28749 When optimizing computations with intermediate results, you can use 28750CONDITION to match only when the intermediate results are not used 28751elsewhere. Use the C expression 'dead_or_set_p (INSN, OP)', where INSN 28752is the insn in which you expect the value to be used for the last time 28753(from the value of 'insn', together with use of 'prev_nonnote_insn'), 28754and OP is the intermediate value (from 'operands[I]'). 28755 28756 Applying the optimization means replacing the sequence of insns with 28757one new insn. The TEMPLATE controls ultimate output of assembler code 28758for this combined insn. It works exactly like the template of a 28759'define_insn'. Operand numbers in this template are the same ones used 28760in matching the original sequence of insns. 28761 28762 The result of a defined peephole optimizer does not need to match any 28763of the insn patterns in the machine description; it does not even have 28764an opportunity to match them. The peephole optimizer definition itself 28765serves as the insn pattern to control how the insn is output. 28766 28767 Defined peephole optimizers are run as assembler code is being output, 28768so the insns they produce are never combined or rearranged in any way. 28769 28770 Here is an example, taken from the 68000 machine description: 28771 28772 (define_peephole 28773 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 28774 (set (match_operand:DF 0 "register_operand" "=f") 28775 (match_operand:DF 1 "register_operand" "ad"))] 28776 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 28777 { 28778 rtx xoperands[2]; 28779 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 28780 #ifdef MOTOROLA 28781 output_asm_insn ("move.l %1,(sp)", xoperands); 28782 output_asm_insn ("move.l %1,-(sp)", operands); 28783 return "fmove.d (sp)+,%0"; 28784 #else 28785 output_asm_insn ("movel %1,sp@", xoperands); 28786 output_asm_insn ("movel %1,sp@-", operands); 28787 return "fmoved sp@+,%0"; 28788 #endif 28789 }) 28790 28791 The effect of this optimization is to change 28792 28793 jbsr _foobar 28794 addql #4,sp 28795 movel d1,sp@- 28796 movel d0,sp@- 28797 fmoved sp@+,fp0 28798 28799into 28800 28801 jbsr _foobar 28802 movel d1,sp@ 28803 movel d0,sp@- 28804 fmoved sp@+,fp0 28805 28806 INSN-PATTERN-1 and so on look _almost_ like the second operand of 28807'define_insn'. There is one important difference: the second operand of 28808'define_insn' consists of one or more RTX's enclosed in square brackets. 28809Usually, there is only one: then the same action can be written as an 28810element of a 'define_peephole'. But when there are multiple actions in 28811a 'define_insn', they are implicitly enclosed in a 'parallel'. Then you 28812must explicitly write the 'parallel', and the square brackets within it, 28813in the 'define_peephole'. Thus, if an insn pattern looks like this, 28814 28815 (define_insn "divmodsi4" 28816 [(set (match_operand:SI 0 "general_operand" "=d") 28817 (div:SI (match_operand:SI 1 "general_operand" "0") 28818 (match_operand:SI 2 "general_operand" "dmsK"))) 28819 (set (match_operand:SI 3 "general_operand" "=d") 28820 (mod:SI (match_dup 1) (match_dup 2)))] 28821 "TARGET_68020" 28822 "divsl%.l %2,%3:%0") 28823 28824then the way to mention this insn in a peephole is as follows: 28825 28826 (define_peephole 28827 [... 28828 (parallel 28829 [(set (match_operand:SI 0 "general_operand" "=d") 28830 (div:SI (match_operand:SI 1 "general_operand" "0") 28831 (match_operand:SI 2 "general_operand" "dmsK"))) 28832 (set (match_operand:SI 3 "general_operand" "=d") 28833 (mod:SI (match_dup 1) (match_dup 2)))]) 28834 ...] 28835 ...) 28836 28837 28838File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 28839 2884017.18.2 RTL to RTL Peephole Optimizers 28841-------------------------------------- 28842 28843The 'define_peephole2' definition tells the compiler how to substitute 28844one sequence of instructions for another sequence, what additional 28845scratch registers may be needed and what their lifetimes must be. 28846 28847 (define_peephole2 28848 [INSN-PATTERN-1 28849 INSN-PATTERN-2 28850 ...] 28851 "CONDITION" 28852 [NEW-INSN-PATTERN-1 28853 NEW-INSN-PATTERN-2 28854 ...] 28855 "PREPARATION-STATEMENTS") 28856 28857 The definition is almost identical to 'define_split' (*note Insn 28858Splitting::) except that the pattern to match is not a single 28859instruction, but a sequence of instructions. 28860 28861 It is possible to request additional scratch registers for use in the 28862output template. If appropriate registers are not free, the pattern 28863will simply not match. 28864 28865 Scratch registers are requested with a 'match_scratch' pattern at the 28866top level of the input pattern. The allocated register (initially) will 28867be dead at the point requested within the original sequence. If the 28868scratch is used at more than a single point, a 'match_dup' pattern at 28869the top level of the input pattern marks the last position in the input 28870sequence at which the register must be available. 28871 28872 Here is an example from the IA-32 machine description: 28873 28874 (define_peephole2 28875 [(match_scratch:SI 2 "r") 28876 (parallel [(set (match_operand:SI 0 "register_operand" "") 28877 (match_operator:SI 3 "arith_or_logical_operator" 28878 [(match_dup 0) 28879 (match_operand:SI 1 "memory_operand" "")])) 28880 (clobber (reg:CC 17))])] 28881 "! optimize_size && ! TARGET_READ_MODIFY" 28882 [(set (match_dup 2) (match_dup 1)) 28883 (parallel [(set (match_dup 0) 28884 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 28885 (clobber (reg:CC 17))])] 28886 "") 28887 28888This pattern tries to split a load from its use in the hopes that we'll 28889be able to schedule around the memory load latency. It allocates a 28890single 'SImode' register of class 'GENERAL_REGS' ('"r"') that needs to 28891be live only at the point just before the arithmetic. 28892 28893 A real example requiring extended scratch lifetimes is harder to come 28894by, so here's a silly made-up example: 28895 28896 (define_peephole2 28897 [(match_scratch:SI 4 "r") 28898 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 28899 (set (match_operand:SI 2 "" "") (match_dup 1)) 28900 (match_dup 4) 28901 (set (match_operand:SI 3 "" "") (match_dup 1))] 28902 "/* determine 1 does not overlap 0 and 2 */" 28903 [(set (match_dup 4) (match_dup 1)) 28904 (set (match_dup 0) (match_dup 4)) 28905 (set (match_dup 2) (match_dup 4)) 28906 (set (match_dup 3) (match_dup 4))] 28907 "") 28908 28909 There are two special macros defined for use in the preparation 28910statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 28911a statement. 28912 28913'DONE' 28914 Use the 'DONE' macro to end RTL generation for the peephole. The 28915 only RTL insns generated as replacement for the matched input insn 28916 will be those already emitted by explicit calls to 'emit_insn' 28917 within the preparation statements; the replacement pattern is not 28918 used. 28919 28920'FAIL' 28921 Make the 'define_peephole2' fail on this occasion. When a 28922 'define_peephole2' fails, it means that the replacement was not 28923 truly available for the particular inputs it was given. In that 28924 case, GCC may still apply a later 'define_peephole2' that also 28925 matches the given insn pattern. (Note that this is different from 28926 'define_split', where 'FAIL' prevents the input insn from being 28927 split at all.) 28928 28929 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 28930then the 'define_peephole2' uses the replacement template. 28931 28932If we had not added the '(match_dup 4)' in the middle of the input 28933sequence, it might have been the case that the register we chose at the 28934beginning of the sequence is killed by the first or second 'set'. 28935 28936 28937File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 28938 2893917.19 Instruction Attributes 28940============================ 28941 28942In addition to describing the instruction supported by the target 28943machine, the 'md' file also defines a group of "attributes" and a set of 28944values for each. Every generated insn is assigned a value for each 28945attribute. One possible attribute would be the effect that the insn has 28946on the machine's condition code. This attribute can then be used by 28947'NOTICE_UPDATE_CC' to track the condition codes. 28948 28949* Menu: 28950 28951* Defining Attributes:: Specifying attributes and their values. 28952* Expressions:: Valid expressions for attribute values. 28953* Tagging Insns:: Assigning attribute values to insns. 28954* Attr Example:: An example of assigning attributes. 28955* Insn Lengths:: Computing the length of insns. 28956* Constant Attributes:: Defining attributes that are constant. 28957* Mnemonic Attribute:: Obtain the instruction mnemonic as attribute value. 28958* Delay Slots:: Defining delay slots required for a machine. 28959* Processor pipeline description:: Specifying information for insn scheduling. 28960 28961 28962File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 28963 2896417.19.1 Defining Attributes and their Values 28965-------------------------------------------- 28966 28967The 'define_attr' expression is used to define each attribute required 28968by the target machine. It looks like: 28969 28970 (define_attr NAME LIST-OF-VALUES DEFAULT) 28971 28972 NAME is a string specifying the name of the attribute being defined. 28973Some attributes are used in a special way by the rest of the compiler. 28974The 'enabled' attribute can be used to conditionally enable or disable 28975insn alternatives (*note Disable Insn Alternatives::). The 'predicable' 28976attribute, together with a suitable 'define_cond_exec' (*note 28977Conditional Execution::), can be used to automatically generate 28978conditional variants of instruction patterns. The 'mnemonic' attribute 28979can be used to check for the instruction mnemonic (*note Mnemonic 28980Attribute::). The compiler internally uses the names 'ce_enabled' and 28981'nonce_enabled', so they should not be used elsewhere as alternative 28982names. 28983 28984 LIST-OF-VALUES is either a string that specifies a comma-separated list 28985of values that can be assigned to the attribute, or a null string to 28986indicate that the attribute takes numeric values. 28987 28988 DEFAULT is an attribute expression that gives the value of this 28989attribute for insns that match patterns whose definition does not 28990include an explicit value for this attribute. *Note Attr Example::, for 28991more information on the handling of defaults. *Note Constant 28992Attributes::, for information on attributes that do not depend on any 28993particular insn. 28994 28995 For each defined attribute, a number of definitions are written to the 28996'insn-attr.h' file. For cases where an explicit set of values is 28997specified for an attribute, the following are defined: 28998 28999 * A '#define' is written for the symbol 'HAVE_ATTR_NAME'. 29000 29001 * An enumerated class is defined for 'attr_NAME' with elements of the 29002 form 'UPPER-NAME_UPPER-VALUE' where the attribute name and value 29003 are first converted to uppercase. 29004 29005 * A function 'get_attr_NAME' is defined that is passed an insn and 29006 returns the attribute value for that insn. 29007 29008 For example, if the following is present in the 'md' file: 29009 29010 (define_attr "type" "branch,fp,load,store,arith" ...) 29011 29012the following lines will be written to the file 'insn-attr.h'. 29013 29014 #define HAVE_ATTR_type 1 29015 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 29016 TYPE_STORE, TYPE_ARITH}; 29017 extern enum attr_type get_attr_type (); 29018 29019 If the attribute takes numeric values, no 'enum' type will be defined 29020and the function to obtain the attribute's value will return 'int'. 29021 29022 There are attributes which are tied to a specific meaning. These 29023attributes are not free to use for other purposes: 29024 29025'length' 29026 The 'length' attribute is used to calculate the length of emitted 29027 code chunks. This is especially important when verifying branch 29028 distances. *Note Insn Lengths::. 29029 29030'enabled' 29031 The 'enabled' attribute can be defined to prevent certain 29032 alternatives of an insn definition from being used during code 29033 generation. *Note Disable Insn Alternatives::. 29034 29035'mnemonic' 29036 The 'mnemonic' attribute can be defined to implement instruction 29037 specific checks in e.g. the pipeline description. *Note Mnemonic 29038 Attribute::. 29039 29040 For each of these special attributes, the corresponding 29041'HAVE_ATTR_NAME' '#define' is also written when the attribute is not 29042defined; in that case, it is defined as '0'. 29043 29044 Another way of defining an attribute is to use: 29045 29046 (define_enum_attr "ATTR" "ENUM" DEFAULT) 29047 29048 This works in just the same way as 'define_attr', except that the list 29049of values is taken from a separate enumeration called ENUM (*note 29050define_enum::). This form allows you to use the same list of values for 29051several attributes without having to repeat the list each time. For 29052example: 29053 29054 (define_enum "processor" [ 29055 model_a 29056 model_b 29057 ... 29058 ]) 29059 (define_enum_attr "arch" "processor" 29060 (const (symbol_ref "target_arch"))) 29061 (define_enum_attr "tune" "processor" 29062 (const (symbol_ref "target_tune"))) 29063 29064 defines the same attributes as: 29065 29066 (define_attr "arch" "model_a,model_b,..." 29067 (const (symbol_ref "target_arch"))) 29068 (define_attr "tune" "model_a,model_b,..." 29069 (const (symbol_ref "target_tune"))) 29070 29071 but without duplicating the processor list. The second example defines 29072two separate C enums ('attr_arch' and 'attr_tune') whereas the first 29073defines a single C enum ('processor'). 29074 29075 29076File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 29077 2907817.19.2 Attribute Expressions 29079----------------------------- 29080 29081RTL expressions used to define attributes use the codes described above 29082plus a few specific to attribute definitions, to be discussed below. 29083Attribute value expressions must have one of the following forms: 29084 29085'(const_int I)' 29086 The integer I specifies the value of a numeric attribute. I must 29087 be non-negative. 29088 29089 The value of a numeric attribute can be specified either with a 29090 'const_int', or as an integer represented as a string in 29091 'const_string', 'eq_attr' (see below), 'attr', 'symbol_ref', simple 29092 arithmetic expressions, and 'set_attr' overrides on specific 29093 instructions (*note Tagging Insns::). 29094 29095'(const_string VALUE)' 29096 The string VALUE specifies a constant attribute value. If VALUE is 29097 specified as '"*"', it means that the default value of the 29098 attribute is to be used for the insn containing this expression. 29099 '"*"' obviously cannot be used in the DEFAULT expression of a 29100 'define_attr'. 29101 29102 If the attribute whose value is being specified is numeric, VALUE 29103 must be a string containing a non-negative integer (normally 29104 'const_int' would be used in this case). Otherwise, it must 29105 contain one of the valid values for the attribute. 29106 29107'(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 29108 TEST specifies an attribute test, whose format is defined below. 29109 The value of this expression is TRUE-VALUE if TEST is true, 29110 otherwise it is FALSE-VALUE. 29111 29112'(cond [TEST1 VALUE1 ...] DEFAULT)' 29113 The first operand of this expression is a vector containing an even 29114 number of expressions and consisting of pairs of TEST and VALUE 29115 expressions. The value of the 'cond' expression is that of the 29116 VALUE corresponding to the first true TEST expression. If none of 29117 the TEST expressions are true, the value of the 'cond' expression 29118 is that of the DEFAULT expression. 29119 29120 TEST expressions can have one of the following forms: 29121 29122'(const_int I)' 29123 This test is true if I is nonzero and false otherwise. 29124 29125'(not TEST)' 29126'(ior TEST1 TEST2)' 29127'(and TEST1 TEST2)' 29128 These tests are true if the indicated logical function is true. 29129 29130'(match_operand:M N PRED CONSTRAINTS)' 29131 This test is true if operand N of the insn whose attribute value is 29132 being determined has mode M (this part of the test is ignored if M 29133 is 'VOIDmode') and the function specified by the string PRED 29134 returns a nonzero value when passed operand N and mode M (this part 29135 of the test is ignored if PRED is the null string). 29136 29137 The CONSTRAINTS operand is ignored and should be the null string. 29138 29139'(match_test C-EXPR)' 29140 The test is true if C expression C-EXPR is true. In non-constant 29141 attributes, C-EXPR has access to the following variables: 29142 29143 INSN 29144 The rtl instruction under test. 29145 WHICH_ALTERNATIVE 29146 The 'define_insn' alternative that INSN matches. *Note Output 29147 Statement::. 29148 OPERANDS 29149 An array of INSN's rtl operands. 29150 29151 C-EXPR behaves like the condition in a C 'if' statement, so there 29152 is no need to explicitly convert the expression into a boolean 0 or 29153 1 value. For example, the following two tests are equivalent: 29154 29155 (match_test "x & 2") 29156 (match_test "(x & 2) != 0") 29157 29158'(le ARITH1 ARITH2)' 29159'(leu ARITH1 ARITH2)' 29160'(lt ARITH1 ARITH2)' 29161'(ltu ARITH1 ARITH2)' 29162'(gt ARITH1 ARITH2)' 29163'(gtu ARITH1 ARITH2)' 29164'(ge ARITH1 ARITH2)' 29165'(geu ARITH1 ARITH2)' 29166'(ne ARITH1 ARITH2)' 29167'(eq ARITH1 ARITH2)' 29168 These tests are true if the indicated comparison of the two 29169 arithmetic expressions is true. Arithmetic expressions are formed 29170 with 'plus', 'minus', 'mult', 'div', 'mod', 'abs', 'neg', 'and', 29171 'ior', 'xor', 'not', 'ashift', 'lshiftrt', and 'ashiftrt' 29172 expressions. 29173 29174 'const_int' and 'symbol_ref' are always valid terms (*note Insn 29175 Lengths::,for additional forms). 'symbol_ref' is a string denoting 29176 a C expression that yields an 'int' when evaluated by the 29177 'get_attr_...' routine. It should normally be a global variable. 29178 29179'(eq_attr NAME VALUE)' 29180 NAME is a string specifying the name of an attribute. 29181 29182 VALUE is a string that is either a valid value for attribute NAME, 29183 a comma-separated list of values, or '!' followed by a value or 29184 list. If VALUE does not begin with a '!', this test is true if the 29185 value of the NAME attribute of the current insn is in the list 29186 specified by VALUE. If VALUE begins with a '!', this test is true 29187 if the attribute's value is _not_ in the specified list. 29188 29189 For example, 29190 29191 (eq_attr "type" "load,store") 29192 29193 is equivalent to 29194 29195 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 29196 29197 If NAME specifies an attribute of 'alternative', it refers to the 29198 value of the compiler variable 'which_alternative' (*note Output 29199 Statement::) and the values must be small integers. For example, 29200 29201 (eq_attr "alternative" "2,3") 29202 29203 is equivalent to 29204 29205 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 29206 (eq (symbol_ref "which_alternative") (const_int 3))) 29207 29208 Note that, for most attributes, an 'eq_attr' test is simplified in 29209 cases where the value of the attribute being tested is known for 29210 all insns matching a particular pattern. This is by far the most 29211 common case. 29212 29213'(attr_flag NAME)' 29214 The value of an 'attr_flag' expression is true if the flag 29215 specified by NAME is true for the 'insn' currently being scheduled. 29216 29217 NAME is a string specifying one of a fixed set of flags to test. 29218 Test the flags 'forward' and 'backward' to determine the direction 29219 of a conditional branch. 29220 29221 This example describes a conditional branch delay slot which can be 29222 nullified for forward branches that are taken (annul-true) or for 29223 backward branches which are not taken (annul-false). 29224 29225 (define_delay (eq_attr "type" "cbranch") 29226 [(eq_attr "in_branch_delay" "true") 29227 (and (eq_attr "in_branch_delay" "true") 29228 (attr_flag "forward")) 29229 (and (eq_attr "in_branch_delay" "true") 29230 (attr_flag "backward"))]) 29231 29232 The 'forward' and 'backward' flags are false if the current 'insn' 29233 being scheduled is not a conditional branch. 29234 29235 'attr_flag' is only used during delay slot scheduling and has no 29236 meaning to other passes of the compiler. 29237 29238'(attr NAME)' 29239 The value of another attribute is returned. This is most useful 29240 for numeric attributes, as 'eq_attr' and 'attr_flag' produce more 29241 efficient code for non-numeric attributes. 29242 29243 29244File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 29245 2924617.19.3 Assigning Attribute Values to Insns 29247------------------------------------------- 29248 29249The value assigned to an attribute of an insn is primarily determined by 29250which pattern is matched by that insn (or which 'define_peephole' 29251generated it). Every 'define_insn' and 'define_peephole' can have an 29252optional last argument to specify the values of attributes for matching 29253insns. The value of any attribute not specified in a particular insn is 29254set to the default value for that attribute, as specified in its 29255'define_attr'. Extensive use of default values for attributes permits 29256the specification of the values for only one or two attributes in the 29257definition of most insn patterns, as seen in the example in the next 29258section. 29259 29260 The optional last argument of 'define_insn' and 'define_peephole' is a 29261vector of expressions, each of which defines the value for a single 29262attribute. The most general way of assigning an attribute's value is to 29263use a 'set' expression whose first operand is an 'attr' expression 29264giving the name of the attribute being set. The second operand of the 29265'set' is an attribute expression (*note Expressions::) giving the value 29266of the attribute. 29267 29268 When the attribute value depends on the 'alternative' attribute (i.e., 29269which is the applicable alternative in the constraint of the insn), the 29270'set_attr_alternative' expression can be used. It allows the 29271specification of a vector of attribute expressions, one for each 29272alternative. 29273 29274 When the generality of arbitrary attribute expressions is not required, 29275the simpler 'set_attr' expression can be used, which allows specifying a 29276string giving either a single attribute value or a list of attribute 29277values, one for each alternative. 29278 29279 The form of each of the above specifications is shown below. In each 29280case, NAME is a string specifying the attribute to be set. 29281 29282'(set_attr NAME VALUE-STRING)' 29283 VALUE-STRING is either a string giving the desired attribute value, 29284 or a string containing a comma-separated list giving the values for 29285 succeeding alternatives. The number of elements must match the 29286 number of alternatives in the constraint of the insn pattern. 29287 29288 Note that it may be useful to specify '*' for some alternative, in 29289 which case the attribute will assume its default value for insns 29290 matching that alternative. 29291 29292'(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 29293 Depending on the alternative of the insn, the value will be one of 29294 the specified values. This is a shorthand for using a 'cond' with 29295 tests on the 'alternative' attribute. 29296 29297'(set (attr NAME) VALUE)' 29298 The first operand of this 'set' must be the special RTL expression 29299 'attr', whose sole operand is a string giving the name of the 29300 attribute being set. VALUE is the value of the attribute. 29301 29302 The following shows three different ways of representing the same 29303attribute value specification: 29304 29305 (set_attr "type" "load,store,arith") 29306 29307 (set_attr_alternative "type" 29308 [(const_string "load") (const_string "store") 29309 (const_string "arith")]) 29310 29311 (set (attr "type") 29312 (cond [(eq_attr "alternative" "1") (const_string "load") 29313 (eq_attr "alternative" "2") (const_string "store")] 29314 (const_string "arith"))) 29315 29316 The 'define_asm_attributes' expression provides a mechanism to specify 29317the attributes assigned to insns produced from an 'asm' statement. It 29318has the form: 29319 29320 (define_asm_attributes [ATTR-SETS]) 29321 29322where ATTR-SETS is specified the same as for both the 'define_insn' and 29323the 'define_peephole' expressions. 29324 29325 These values will typically be the "worst case" attribute values. For 29326example, they might indicate that the condition code will be clobbered. 29327 29328 A specification for a 'length' attribute is handled specially. The way 29329to compute the length of an 'asm' insn is to multiply the length 29330specified in the expression 'define_asm_attributes' by the number of 29331machine instructions specified in the 'asm' statement, determined by 29332counting the number of semicolons and newlines in the string. 29333Therefore, the value of the 'length' attribute specified in a 29334'define_asm_attributes' should be the maximum possible length of a 29335single machine instruction. 29336 29337 29338File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 29339 2934017.19.4 Example of Attribute Specifications 29341------------------------------------------- 29342 29343The judicious use of defaulting is important in the efficient use of 29344insn attributes. Typically, insns are divided into "types" and an 29345attribute, customarily called 'type', is used to represent this value. 29346This attribute is normally used only to define the default value for 29347other attributes. An example will clarify this usage. 29348 29349 Assume we have a RISC machine with a condition code and in which only 29350full-word operations are performed in registers. Let us assume that we 29351can divide all insns into loads, stores, (integer) arithmetic 29352operations, floating point operations, and branches. 29353 29354 Here we will concern ourselves with determining the effect of an insn 29355on the condition code and will limit ourselves to the following possible 29356effects: The condition code can be set unpredictably (clobbered), not be 29357changed, be set to agree with the results of the operation, or only 29358changed if the item previously set into the condition code has been 29359modified. 29360 29361 Here is part of a sample 'md' file for such a machine: 29362 29363 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 29364 29365 (define_attr "cc" "clobber,unchanged,set,change0" 29366 (cond [(eq_attr "type" "load") 29367 (const_string "change0") 29368 (eq_attr "type" "store,branch") 29369 (const_string "unchanged") 29370 (eq_attr "type" "arith") 29371 (if_then_else (match_operand:SI 0 "" "") 29372 (const_string "set") 29373 (const_string "clobber"))] 29374 (const_string "clobber"))) 29375 29376 (define_insn "" 29377 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 29378 (match_operand:SI 1 "general_operand" "r,m,r"))] 29379 "" 29380 "@ 29381 move %0,%1 29382 load %0,%1 29383 store %0,%1" 29384 [(set_attr "type" "arith,load,store")]) 29385 29386 Note that we assume in the above example that arithmetic operations 29387performed on quantities smaller than a machine word clobber the 29388condition code since they will set the condition code to a value 29389corresponding to the full-word result. 29390 29391 29392File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 29393 2939417.19.5 Computing the Length of an Insn 29395--------------------------------------- 29396 29397For many machines, multiple types of branch instructions are provided, 29398each for different length branch displacements. In most cases, the 29399assembler will choose the correct instruction to use. However, when the 29400assembler cannot do so, GCC can when a special attribute, the 'length' 29401attribute, is defined. This attribute must be defined to have numeric 29402values by specifying a null string in its 'define_attr'. 29403 29404 In the case of the 'length' attribute, two additional forms of 29405arithmetic terms are allowed in test expressions: 29406 29407'(match_dup N)' 29408 This refers to the address of operand N of the current insn, which 29409 must be a 'label_ref'. 29410 29411'(pc)' 29412 For non-branch instructions and backward branch instructions, this 29413 refers to the address of the current insn. But for forward branch 29414 instructions, this refers to the address of the next insn, because 29415 the length of the current insn is to be computed. 29416 29417 For normal insns, the length will be determined by value of the 29418'length' attribute. In the case of 'addr_vec' and 'addr_diff_vec' insn 29419patterns, the length is computed as the number of vectors multiplied by 29420the size of each vector. 29421 29422 Lengths are measured in addressable storage units (bytes). 29423 29424 Note that it is possible to call functions via the 'symbol_ref' 29425mechanism to compute the length of an insn. However, if you use this 29426mechanism you must provide dummy clauses to express the maximum length 29427without using the function call. You can an example of this in the 'pa' 29428machine description for the 'call_symref' pattern. 29429 29430 The following macros can be used to refine the length computation: 29431 29432'ADJUST_INSN_LENGTH (INSN, LENGTH)' 29433 If defined, modifies the length assigned to instruction INSN as a 29434 function of the context in which it is used. LENGTH is an lvalue 29435 that contains the initially computed length of the insn and should 29436 be updated with the correct length of the insn. 29437 29438 This macro will normally not be required. A case in which it is 29439 required is the ROMP. On this machine, the size of an 'addr_vec' 29440 insn must be increased by two to compensate for the fact that 29441 alignment may be required. 29442 29443 The routine that returns 'get_attr_length' (the value of the 'length' 29444attribute) can be used by the output routine to determine the form of 29445the branch instruction to be written, as the example below illustrates. 29446 29447 As an example of the specification of variable-length branches, 29448consider the IBM 360. If we adopt the convention that a register will 29449be set to the starting address of a function, we can jump to labels 29450within 4k of the start using a four-byte instruction. Otherwise, we 29451need a six-byte sequence to load the address from memory and then branch 29452to it. 29453 29454 On such a machine, a pattern for a branch instruction might be 29455specified as follows: 29456 29457 (define_insn "jump" 29458 [(set (pc) 29459 (label_ref (match_operand 0 "" "")))] 29460 "" 29461 { 29462 return (get_attr_length (insn) == 4 29463 ? "b %l0" : "l r15,=a(%l0); br r15"); 29464 } 29465 [(set (attr "length") 29466 (if_then_else (lt (match_dup 0) (const_int 4096)) 29467 (const_int 4) 29468 (const_int 6)))]) 29469 29470 29471File: gccint.info, Node: Constant Attributes, Next: Mnemonic Attribute, Prev: Insn Lengths, Up: Insn Attributes 29472 2947317.19.6 Constant Attributes 29474--------------------------- 29475 29476A special form of 'define_attr', where the expression for the default 29477value is a 'const' expression, indicates an attribute that is constant 29478for a given run of the compiler. Constant attributes may be used to 29479specify which variety of processor is used. For example, 29480 29481 (define_attr "cpu" "m88100,m88110,m88000" 29482 (const 29483 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 29484 (symbol_ref "TARGET_88110") (const_string "m88110")] 29485 (const_string "m88000")))) 29486 29487 (define_attr "memory" "fast,slow" 29488 (const 29489 (if_then_else (symbol_ref "TARGET_FAST_MEM") 29490 (const_string "fast") 29491 (const_string "slow")))) 29492 29493 The routine generated for constant attributes has no parameters as it 29494does not depend on any particular insn. RTL expressions used to define 29495the value of a constant attribute may use the 'symbol_ref' form, but may 29496not use either the 'match_operand' form or 'eq_attr' forms involving 29497insn attributes. 29498 29499 29500File: gccint.info, Node: Mnemonic Attribute, Next: Delay Slots, Prev: Constant Attributes, Up: Insn Attributes 29501 2950217.19.7 Mnemonic Attribute 29503-------------------------- 29504 29505The 'mnemonic' attribute is a string type attribute holding the 29506instruction mnemonic for an insn alternative. The attribute values will 29507automatically be generated by the machine description parser if there is 29508an attribute definition in the md file: 29509 29510 (define_attr "mnemonic" "unknown" (const_string "unknown")) 29511 29512 The default value can be freely chosen as long as it does not collide 29513with any of the instruction mnemonics. This value will be used whenever 29514the machine description parser is not able to determine the mnemonic 29515string. This might be the case for output templates containing more 29516than a single instruction as in '"mvcle\t%0,%1,0\;jo\t.-4"'. 29517 29518 The 'mnemonic' attribute set is not generated automatically if the 29519instruction string is generated via C code. 29520 29521 An existing 'mnemonic' attribute set in an insn definition will not be 29522overriden by the md file parser. That way it is possible to manually 29523set the instruction mnemonics for the cases where the md file parser 29524fails to determine it automatically. 29525 29526 The 'mnemonic' attribute is useful for dealing with instruction 29527specific properties in the pipeline description without defining 29528additional insn attributes. 29529 29530 (define_attr "ooo_expanded" "" 29531 (cond [(eq_attr "mnemonic" "dlr,dsgr,d,dsgf,stam,dsgfr,dlgr") 29532 (const_int 1)] 29533 (const_int 0))) 29534 29535 29536File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Mnemonic Attribute, Up: Insn Attributes 29537 2953817.19.8 Delay Slot Scheduling 29539----------------------------- 29540 29541The insn attribute mechanism can be used to specify the requirements for 29542delay slots, if any, on a target machine. An instruction is said to 29543require a "delay slot" if some instructions that are physically after 29544the instruction are executed as if they were located before it. Classic 29545examples are branch and call instructions, which often execute the 29546following instruction before the branch or call is performed. 29547 29548 On some machines, conditional branch instructions can optionally 29549"annul" instructions in the delay slot. This means that the instruction 29550will not be executed for certain branch outcomes. Both instructions 29551that annul if the branch is true and instructions that annul if the 29552branch is false are supported. 29553 29554 Delay slot scheduling differs from instruction scheduling in that 29555determining whether an instruction needs a delay slot is dependent only 29556on the type of instruction being generated, not on data flow between the 29557instructions. See the next section for a discussion of data-dependent 29558instruction scheduling. 29559 29560 The requirement of an insn needing one or more delay slots is indicated 29561via the 'define_delay' expression. It has the following form: 29562 29563 (define_delay TEST 29564 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 29565 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 29566 ...]) 29567 29568 TEST is an attribute test that indicates whether this 'define_delay' 29569applies to a particular insn. If so, the number of required delay slots 29570is determined by the length of the vector specified as the second 29571argument. An insn placed in delay slot N must satisfy attribute test 29572DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 29573may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 29574specifies which insns in the delay slot may be annulled if the branch is 29575false. If annulling is not supported for that delay slot, '(nil)' 29576should be coded. 29577 29578 For example, in the common case where branch and call insns require a 29579single delay slot, which may contain any insn other than a branch or 29580call, the following would be placed in the 'md' file: 29581 29582 (define_delay (eq_attr "type" "branch,call") 29583 [(eq_attr "type" "!branch,call") (nil) (nil)]) 29584 29585 Multiple 'define_delay' expressions may be specified. In this case, 29586each such expression specifies different delay slot requirements and 29587there must be no insn for which tests in two 'define_delay' expressions 29588are both true. 29589 29590 For example, if we have a machine that requires one delay slot for 29591branches but two for calls, no delay slot can contain a branch or call 29592insn, and any valid insn in the delay slot for the branch can be 29593annulled if the branch is true, we might represent this as follows: 29594 29595 (define_delay (eq_attr "type" "branch") 29596 [(eq_attr "type" "!branch,call") 29597 (eq_attr "type" "!branch,call") 29598 (nil)]) 29599 29600 (define_delay (eq_attr "type" "call") 29601 [(eq_attr "type" "!branch,call") (nil) (nil) 29602 (eq_attr "type" "!branch,call") (nil) (nil)]) 29603 29604 29605File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 29606 2960717.19.9 Specifying processor pipeline description 29608------------------------------------------------- 29609 29610To achieve better performance, most modern processors (super-pipelined, 29611superscalar RISC, and VLIW processors) have many "functional units" on 29612which several instructions can be executed simultaneously. An 29613instruction starts execution if its issue conditions are satisfied. If 29614not, the instruction is stalled until its conditions are satisfied. 29615Such "interlock (pipeline) delay" causes interruption of the fetching of 29616successor instructions (or demands nop instructions, e.g. for some MIPS 29617processors). 29618 29619 There are two major kinds of interlock delays in modern processors. 29620The first one is a data dependence delay determining "instruction 29621latency time". The instruction execution is not started until all 29622source data have been evaluated by prior instructions (there are more 29623complex cases when the instruction execution starts even when the data 29624are not available but will be ready in given time after the instruction 29625execution start). Taking the data dependence delays into account is 29626simple. The data dependence (true, output, and anti-dependence) delay 29627between two instructions is given by a constant. In most cases this 29628approach is adequate. The second kind of interlock delays is a 29629reservation delay. The reservation delay means that two instructions 29630under execution will be in need of shared processors resources, i.e. 29631buses, internal registers, and/or functional units, which are reserved 29632for some time. Taking this kind of delay into account is complex 29633especially for modern RISC processors. 29634 29635 The task of exploiting more processor parallelism is solved by an 29636instruction scheduler. For a better solution to this problem, the 29637instruction scheduler has to have an adequate description of the 29638processor parallelism (or "pipeline description"). GCC machine 29639descriptions describe processor parallelism and functional unit 29640reservations for groups of instructions with the aid of "regular 29641expressions". 29642 29643 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 29644figure out the possibility of the instruction issue by the processor on 29645a given simulated processor cycle. The pipeline hazard recognizer is 29646automatically generated from the processor pipeline description. The 29647pipeline hazard recognizer generated from the machine description is 29648based on a deterministic finite state automaton (DFA): the instruction 29649issue is possible if there is a transition from one automaton state to 29650another one. This algorithm is very fast, and furthermore, its speed is 29651not dependent on processor complexity(1). 29652 29653 The rest of this section describes the directives that constitute an 29654automaton-based processor pipeline description. The order of these 29655constructions within the machine description file is not important. 29656 29657 The following optional construction describes names of automata 29658generated and used for the pipeline hazards recognition. Sometimes the 29659generated finite state automaton used by the pipeline hazard recognizer 29660is large. If we use more than one automaton and bind functional units 29661to the automata, the total size of the automata is usually less than the 29662size of the single automaton. If there is no one such construction, 29663only one finite state automaton is generated. 29664 29665 (define_automaton AUTOMATA-NAMES) 29666 29667 AUTOMATA-NAMES is a string giving names of the automata. The names are 29668separated by commas. All the automata should have unique names. The 29669automaton name is used in the constructions 'define_cpu_unit' and 29670'define_query_cpu_unit'. 29671 29672 Each processor functional unit used in the description of instruction 29673reservations should be described by the following construction. 29674 29675 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 29676 29677 UNIT-NAMES is a string giving the names of the functional units 29678separated by commas. Don't use name 'nothing', it is reserved for other 29679goals. 29680 29681 AUTOMATON-NAME is a string giving the name of the automaton with which 29682the unit is bound. The automaton should be described in construction 29683'define_automaton'. You should give "automaton-name", if there is a 29684defined automaton. 29685 29686 The assignment of units to automata are constrained by the uses of the 29687units in insn reservations. The most important constraint is: if a unit 29688reservation is present on a particular cycle of an alternative for an 29689insn reservation, then some unit from the same automaton must be present 29690on the same cycle for the other alternatives of the insn reservation. 29691The rest of the constraints are mentioned in the description of the 29692subsequent constructions. 29693 29694 The following construction describes CPU functional units analogously 29695to 'define_cpu_unit'. The reservation of such units can be queried for 29696an automaton state. The instruction scheduler never queries reservation 29697of functional units for given automaton state. So as a rule, you don't 29698need this construction. This construction could be used for future code 29699generation goals (e.g. to generate VLIW insn templates). 29700 29701 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 29702 29703 UNIT-NAMES is a string giving names of the functional units separated 29704by commas. 29705 29706 AUTOMATON-NAME is a string giving the name of the automaton with which 29707the unit is bound. 29708 29709 The following construction is the major one to describe pipeline 29710characteristics of an instruction. 29711 29712 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 29713 CONDITION REGEXP) 29714 29715 DEFAULT_LATENCY is a number giving latency time of the instruction. 29716There is an important difference between the old description and the 29717automaton based pipeline description. The latency time is used for all 29718dependencies when we use the old description. In the automaton based 29719pipeline description, the given latency time is only used for true 29720dependencies. The cost of anti-dependencies is always zero and the cost 29721of output dependencies is the difference between latency times of the 29722producing and consuming insns (if the difference is negative, the cost 29723is considered to be zero). You can always change the default costs for 29724any description by using the target hook 'TARGET_SCHED_ADJUST_COST' 29725(*note Scheduling::). 29726 29727 INSN-NAME is a string giving the internal name of the insn. The 29728internal names are used in constructions 'define_bypass' and in the 29729automaton description file generated for debugging. The internal name 29730has nothing in common with the names in 'define_insn'. It is a good 29731practice to use insn classes described in the processor manual. 29732 29733 CONDITION defines what RTL insns are described by this construction. 29734You should remember that you will be in trouble if CONDITION for two or 29735more different 'define_insn_reservation' constructions is TRUE for an 29736insn. In this case what reservation will be used for the insn is not 29737defined. Such cases are not checked during generation of the pipeline 29738hazards recognizer because in general recognizing that two conditions 29739may have the same value is quite difficult (especially if the conditions 29740contain 'symbol_ref'). It is also not checked during the pipeline 29741hazard recognizer work because it would slow down the recognizer 29742considerably. 29743 29744 REGEXP is a string describing the reservation of the cpu's functional 29745units by the instruction. The reservations are described by a regular 29746expression according to the following syntax: 29747 29748 regexp = regexp "," oneof 29749 | oneof 29750 29751 oneof = oneof "|" allof 29752 | allof 29753 29754 allof = allof "+" repeat 29755 | repeat 29756 29757 repeat = element "*" number 29758 | element 29759 29760 element = cpu_function_unit_name 29761 | reservation_name 29762 | result_name 29763 | "nothing" 29764 | "(" regexp ")" 29765 29766 * ',' is used for describing the start of the next cycle in the 29767 reservation. 29768 29769 * '|' is used for describing a reservation described by the first 29770 regular expression *or* a reservation described by the second 29771 regular expression *or* etc. 29772 29773 * '+' is used for describing a reservation described by the first 29774 regular expression *and* a reservation described by the second 29775 regular expression *and* etc. 29776 29777 * '*' is used for convenience and simply means a sequence in which 29778 the regular expression are repeated NUMBER times with cycle 29779 advancing (see ','). 29780 29781 * 'cpu_function_unit_name' denotes reservation of the named 29782 functional unit. 29783 29784 * 'reservation_name' -- see description of construction 29785 'define_reservation'. 29786 29787 * 'nothing' denotes no unit reservations. 29788 29789 Sometimes unit reservations for different insns contain common parts. 29790In such case, you can simplify the pipeline description by describing 29791the common part by the following construction 29792 29793 (define_reservation RESERVATION-NAME REGEXP) 29794 29795 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 29796names and reservation names are in the same name space. So the 29797reservation names should be different from the functional unit names and 29798cannot be the reserved name 'nothing'. 29799 29800 The following construction is used to describe exceptions in the 29801latency time for given instruction pair. This is so called bypasses. 29802 29803 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 29804 [GUARD]) 29805 29806 NUMBER defines when the result generated by the instructions given in 29807string OUT_INSN_NAMES will be ready for the instructions given in string 29808IN_INSN_NAMES. Each of these strings is a comma-separated list of 29809filename-style globs and they refer to the names of 29810'define_insn_reservation's. For example: 29811 (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") 29812 defines a bypass between instructions that start with 'cpu1_load_' or 29813'cpu1_store_' and those that start with 'cpu1_load_'. 29814 29815 GUARD is an optional string giving the name of a C function which 29816defines an additional guard for the bypass. The function will get the 29817two insns as parameters. If the function returns zero the bypass will 29818be ignored for this case. The additional guard is necessary to 29819recognize complicated bypasses, e.g. when the consumer is only an 29820address of insn 'store' (not a stored value). 29821 29822 If there are more one bypass with the same output and input insns, the 29823chosen bypass is the first bypass with a guard in description whose 29824guard function returns nonzero. If there is no such bypass, then bypass 29825without the guard function is chosen. 29826 29827 The following five constructions are usually used to describe VLIW 29828processors, or more precisely, to describe a placement of small 29829instructions into VLIW instruction slots. They can be used for RISC 29830processors, too. 29831 29832 (exclusion_set UNIT-NAMES UNIT-NAMES) 29833 (presence_set UNIT-NAMES PATTERNS) 29834 (final_presence_set UNIT-NAMES PATTERNS) 29835 (absence_set UNIT-NAMES PATTERNS) 29836 (final_absence_set UNIT-NAMES PATTERNS) 29837 29838 UNIT-NAMES is a string giving names of functional units separated by 29839commas. 29840 29841 PATTERNS is a string giving patterns of functional units separated by 29842comma. Currently pattern is one unit or units separated by 29843white-spaces. 29844 29845 The first construction ('exclusion_set') means that each functional 29846unit in the first string cannot be reserved simultaneously with a unit 29847whose name is in the second string and vice versa. For example, the 29848construction is useful for describing processors (e.g. some SPARC 29849processors) with a fully pipelined floating point functional unit which 29850can execute simultaneously only single floating point insns or only 29851double floating point insns. 29852 29853 The second construction ('presence_set') means that each functional 29854unit in the first string cannot be reserved unless at least one of 29855pattern of units whose names are in the second string is reserved. This 29856is an asymmetric relation. For example, it is useful for description 29857that VLIW 'slot1' is reserved after 'slot0' reservation. We could 29858describe it by the following construction 29859 29860 (presence_set "slot1" "slot0") 29861 29862 Or 'slot1' is reserved only after 'slot0' and unit 'b0' reservation. 29863In this case we could write 29864 29865 (presence_set "slot1" "slot0 b0") 29866 29867 The third construction ('final_presence_set') is analogous to 29868'presence_set'. The difference between them is when checking is done. 29869When an instruction is issued in given automaton state reflecting all 29870current and planned unit reservations, the automaton state is changed. 29871The first state is a source state, the second one is a result state. 29872Checking for 'presence_set' is done on the source state reservation, 29873checking for 'final_presence_set' is done on the result reservation. 29874This construction is useful to describe a reservation which is actually 29875two subsequent reservations. For example, if we use 29876 29877 (presence_set "slot1" "slot0") 29878 29879 the following insn will be never issued (because 'slot1' requires 29880'slot0' which is absent in the source state). 29881 29882 (define_reservation "insn_and_nop" "slot0 + slot1") 29883 29884 but it can be issued if we use analogous 'final_presence_set'. 29885 29886 The forth construction ('absence_set') means that each functional unit 29887in the first string can be reserved only if each pattern of units whose 29888names are in the second string is not reserved. This is an asymmetric 29889relation (actually 'exclusion_set' is analogous to this one but it is 29890symmetric). For example it might be useful in a VLIW description to say 29891that 'slot0' cannot be reserved after either 'slot1' or 'slot2' have 29892been reserved. This can be described as: 29893 29894 (absence_set "slot0" "slot1, slot2") 29895 29896 Or 'slot2' cannot be reserved if 'slot0' and unit 'b0' are reserved or 29897'slot1' and unit 'b1' are reserved. In this case we could write 29898 29899 (absence_set "slot2" "slot0 b0, slot1 b1") 29900 29901 All functional units mentioned in a set should belong to the same 29902automaton. 29903 29904 The last construction ('final_absence_set') is analogous to 29905'absence_set' but checking is done on the result (state) reservation. 29906See comments for 'final_presence_set'. 29907 29908 You can control the generator of the pipeline hazard recognizer with 29909the following construction. 29910 29911 (automata_option OPTIONS) 29912 29913 OPTIONS is a string giving options which affect the generated code. 29914Currently there are the following options: 29915 29916 * "no-minimization" makes no minimization of the automaton. This is 29917 only worth to do when we are debugging the description and need to 29918 look more accurately at reservations of states. 29919 29920 * "time" means printing time statistics about the generation of 29921 automata. 29922 29923 * "stats" means printing statistics about the generated automata such 29924 as the number of DFA states, NDFA states and arcs. 29925 29926 * "v" means a generation of the file describing the result automata. 29927 The file has suffix '.dfa' and can be used for the description 29928 verification and debugging. 29929 29930 * "w" means a generation of warning instead of error for non-critical 29931 errors. 29932 29933 * "no-comb-vect" prevents the automaton generator from generating two 29934 data structures and comparing them for space efficiency. Using a 29935 comb vector to represent transitions may be better, but it can be 29936 very expensive to construct. This option is useful if the build 29937 process spends an unacceptably long time in genautomata. 29938 29939 * "ndfa" makes nondeterministic finite state automata. This affects 29940 the treatment of operator '|' in the regular expressions. The 29941 usual treatment of the operator is to try the first alternative 29942 and, if the reservation is not possible, the second alternative. 29943 The nondeterministic treatment means trying all alternatives, some 29944 of them may be rejected by reservations in the subsequent insns. 29945 29946 * "collapse-ndfa" modifies the behavior of the generator when 29947 producing an automaton. An additional state transition to collapse 29948 a nondeterministic NDFA state to a deterministic DFA state is 29949 generated. It can be triggered by passing 'const0_rtx' to 29950 state_transition. In such an automaton, cycle advance transitions 29951 are available only for these collapsed states. This option is 29952 useful for ports that want to use the 'ndfa' option, but also want 29953 to use 'define_query_cpu_unit' to assign units to insns issued in a 29954 cycle. 29955 29956 * "progress" means output of a progress bar showing how many states 29957 were generated so far for automaton being processed. This is 29958 useful during debugging a DFA description. If you see too many 29959 generated states, you could interrupt the generator of the pipeline 29960 hazard recognizer and try to figure out a reason for generation of 29961 the huge automaton. 29962 29963 As an example, consider a superscalar RISC machine which can issue 29964three insns (two integer insns and one floating point insn) on the cycle 29965but can finish only two insns. To describe this, we define the 29966following functional units. 29967 29968 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 29969 (define_cpu_unit "port0, port1") 29970 29971 All simple integer insns can be executed in any integer pipeline and 29972their result is ready in two cycles. The simple integer insns are 29973issued into the first pipeline unless it is reserved, otherwise they are 29974issued into the second pipeline. Integer division and multiplication 29975insns can be executed only in the second integer pipeline and their 29976results are ready correspondingly in 9 and 4 cycles. The integer 29977division is not pipelined, i.e. the subsequent integer division insn 29978cannot be issued until the current division insn finished. Floating 29979point insns are fully pipelined and their results are ready in 3 cycles. 29980Where the result of a floating point insn is used by an integer insn, an 29981additional delay of one cycle is incurred. To describe all of this we 29982could specify 29983 29984 (define_cpu_unit "div") 29985 29986 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 29987 "(i0_pipeline | i1_pipeline), (port0 | port1)") 29988 29989 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 29990 "i1_pipeline, nothing*2, (port0 | port1)") 29991 29992 (define_insn_reservation "div" 9 (eq_attr "type" "div") 29993 "i1_pipeline, div*7, div + (port0 | port1)") 29994 29995 (define_insn_reservation "float" 3 (eq_attr "type" "float") 29996 "f_pipeline, nothing, (port0 | port1)) 29997 29998 (define_bypass 4 "float" "simple,mult,div") 29999 30000 To simplify the description we could describe the following reservation 30001 30002 (define_reservation "finish" "port0|port1") 30003 30004 and use it in all 'define_insn_reservation' as in the following 30005construction 30006 30007 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 30008 "(i0_pipeline | i1_pipeline), finish") 30009 30010 ---------- Footnotes ---------- 30011 30012 (1) However, the size of the automaton depends on processor 30013complexity. To limit this effect, machine descriptions can split 30014orthogonal parts of the machine description among several automata: but 30015then, since each of these must be stepped independently, this does cause 30016a small decrease in the algorithm's performance. 30017 30018 30019File: gccint.info, Node: Conditional Execution, Next: Define Subst, Prev: Insn Attributes, Up: Machine Desc 30020 3002117.20 Conditional Execution 30022=========================== 30023 30024A number of architectures provide for some form of conditional 30025execution, or predication. The hallmark of this feature is the ability 30026to nullify most of the instructions in the instruction set. When the 30027instruction set is large and not entirely symmetric, it can be quite 30028tedious to describe these forms directly in the '.md' file. An 30029alternative is the 'define_cond_exec' template. 30030 30031 (define_cond_exec 30032 [PREDICATE-PATTERN] 30033 "CONDITION" 30034 "OUTPUT-TEMPLATE" 30035 "OPTIONAL-INSN-ATTRIBUES") 30036 30037 PREDICATE-PATTERN is the condition that must be true for the insn to be 30038executed at runtime and should match a relational operator. One can use 30039'match_operator' to match several relational operators at once. Any 30040'match_operand' operands must have no more than one alternative. 30041 30042 CONDITION is a C expression that must be true for the generated pattern 30043to match. 30044 30045 OUTPUT-TEMPLATE is a string similar to the 'define_insn' output 30046template (*note Output Template::), except that the '*' and '@' special 30047cases do not apply. This is only useful if the assembly text for the 30048predicate is a simple prefix to the main insn. In order to handle the 30049general case, there is a global variable 'current_insn_predicate' that 30050will contain the entire predicate if the current insn is predicated, and 30051will otherwise be 'NULL'. 30052 30053 OPTIONAL-INSN-ATTRIBUTES is an optional vector of attributes that gets 30054appended to the insn attributes of the produced cond_exec rtx. It can 30055be used to add some distinguishing attribute to cond_exec rtxs produced 30056that way. An example usage would be to use this attribute in 30057conjunction with attributes on the main pattern to disable particular 30058alternatives under certain conditions. 30059 30060 When 'define_cond_exec' is used, an implicit reference to the 30061'predicable' instruction attribute is made. *Note Insn Attributes::. 30062This attribute must be a boolean (i.e. have exactly two elements in its 30063LIST-OF-VALUES), with the possible values being 'no' and 'yes'. The 30064default and all uses in the insns must be a simple constant, not a 30065complex expressions. It may, however, depend on the alternative, by 30066using a comma-separated list of values. If that is the case, the port 30067should also define an 'enabled' attribute (*note Disable Insn 30068Alternatives::), which should also allow only 'no' and 'yes' as its 30069values. 30070 30071 For each 'define_insn' for which the 'predicable' attribute is true, a 30072new 'define_insn' pattern will be generated that matches a predicated 30073version of the instruction. For example, 30074 30075 (define_insn "addsi" 30076 [(set (match_operand:SI 0 "register_operand" "r") 30077 (plus:SI (match_operand:SI 1 "register_operand" "r") 30078 (match_operand:SI 2 "register_operand" "r")))] 30079 "TEST1" 30080 "add %2,%1,%0") 30081 30082 (define_cond_exec 30083 [(ne (match_operand:CC 0 "register_operand" "c") 30084 (const_int 0))] 30085 "TEST2" 30086 "(%0)") 30087 30088generates a new pattern 30089 30090 (define_insn "" 30091 [(cond_exec 30092 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 30093 (set (match_operand:SI 0 "register_operand" "r") 30094 (plus:SI (match_operand:SI 1 "register_operand" "r") 30095 (match_operand:SI 2 "register_operand" "r"))))] 30096 "(TEST2) && (TEST1)" 30097 "(%3) add %2,%1,%0") 30098 30099 30100File: gccint.info, Node: Define Subst, Next: Constant Definitions, Prev: Conditional Execution, Up: Machine Desc 30101 3010217.21 RTL Templates Transformations 30103=================================== 30104 30105For some hardware architectures there are common cases when the RTL 30106templates for the instructions can be derived from the other RTL 30107templates using simple transformations. E.g., 'i386.md' contains an RTL 30108template for the ordinary 'sub' instruction-- '*subsi_1', and for the 30109'sub' instruction with subsequent zero-extension--'*subsi_1_zext'. Such 30110cases can be easily implemented by a single meta-template capable of 30111generating a modified case based on the initial one: 30112 30113 (define_subst "NAME" 30114 [INPUT-TEMPLATE] 30115 "CONDITION" 30116 [OUTPUT-TEMPLATE]) 30117 INPUT-TEMPLATE is a pattern describing the source RTL template, which 30118will be transformed. 30119 30120 CONDITION is a C expression that is conjunct with the condition from 30121the input-template to generate a condition to be used in the 30122output-template. 30123 30124 OUTPUT-TEMPLATE is a pattern that will be used in the resulting 30125template. 30126 30127 'define_subst' mechanism is tightly coupled with the notion of the 30128subst attribute (*note Subst Iterators::). The use of 'define_subst' is 30129triggered by a reference to a subst attribute in the transforming RTL 30130template. This reference initiates duplication of the source RTL 30131template and substitution of the attributes with their values. The 30132source RTL template is left unchanged, while the copy is transformed by 30133'define_subst'. This transformation can fail in the case when the 30134source RTL template is not matched against the input-template of the 30135'define_subst'. In such case the copy is deleted. 30136 30137 'define_subst' can be used only in 'define_insn' and 'define_expand', 30138it cannot be used in other expressions (e.g. in 30139'define_insn_and_split'). 30140 30141* Menu: 30142 30143* Define Subst Example:: Example of 'define_subst' work. 30144* Define Subst Pattern Matching:: Process of template comparison. 30145* Define Subst Output Template:: Generation of output template. 30146 30147 30148File: gccint.info, Node: Define Subst Example, Next: Define Subst Pattern Matching, Up: Define Subst 30149 3015017.21.1 'define_subst' Example 30151------------------------------ 30152 30153To illustrate how 'define_subst' works, let us examine a simple template 30154transformation. 30155 30156 Suppose there are two kinds of instructions: one that touches flags and 30157the other that does not. The instructions of the second type could be 30158generated with the following 'define_subst': 30159 30160 (define_subst "add_clobber_subst" 30161 [(set (match_operand:SI 0 "" "") 30162 (match_operand:SI 1 "" ""))] 30163 "" 30164 [(set (match_dup 0) 30165 (match_dup 1)) 30166 (clobber (reg:CC FLAGS_REG))]) 30167 30168 This 'define_subst' can be applied to any RTL pattern containing 'set' 30169of mode SI and generates a copy with clobber when it is applied. 30170 30171 Assume there is an RTL template for a 'max' instruction to be used in 30172'define_subst' mentioned above: 30173 30174 (define_insn "maxsi" 30175 [(set (match_operand:SI 0 "register_operand" "=r") 30176 (max:SI 30177 (match_operand:SI 1 "register_operand" "r") 30178 (match_operand:SI 2 "register_operand" "r")))] 30179 "" 30180 "max\t{%2, %1, %0|%0, %1, %2}" 30181 [...]) 30182 30183 To mark the RTL template for 'define_subst' application, 30184subst-attributes are used. They should be declared in advance: 30185 30186 (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber") 30187 30188 Here 'add_clobber_name' is the attribute name, 'add_clobber_subst' is 30189the name of the corresponding 'define_subst', the third argument 30190('_noclobber') is the attribute value that would be substituted into the 30191unchanged version of the source RTL template, and the last argument 30192('_clobber') is the value that would be substituted into the second, 30193transformed, version of the RTL template. 30194 30195 Once the subst-attribute has been defined, it should be used in RTL 30196templates which need to be processed by the 'define_subst'. So, the 30197original RTL template should be changed: 30198 30199 (define_insn "maxsi<add_clobber_name>" 30200 [(set (match_operand:SI 0 "register_operand" "=r") 30201 (max:SI 30202 (match_operand:SI 1 "register_operand" "r") 30203 (match_operand:SI 2 "register_operand" "r")))] 30204 "" 30205 "max\t{%2, %1, %0|%0, %1, %2}" 30206 [...]) 30207 30208 The result of the 'define_subst' usage would look like the following: 30209 30210 (define_insn "maxsi_noclobber" 30211 [(set (match_operand:SI 0 "register_operand" "=r") 30212 (max:SI 30213 (match_operand:SI 1 "register_operand" "r") 30214 (match_operand:SI 2 "register_operand" "r")))] 30215 "" 30216 "max\t{%2, %1, %0|%0, %1, %2}" 30217 [...]) 30218 (define_insn "maxsi_clobber" 30219 [(set (match_operand:SI 0 "register_operand" "=r") 30220 (max:SI 30221 (match_operand:SI 1 "register_operand" "r") 30222 (match_operand:SI 2 "register_operand" "r"))) 30223 (clobber (reg:CC FLAGS_REG))] 30224 "" 30225 "max\t{%2, %1, %0|%0, %1, %2}" 30226 [...]) 30227 30228 30229File: gccint.info, Node: Define Subst Pattern Matching, Next: Define Subst Output Template, Prev: Define Subst Example, Up: Define Subst 30230 3023117.21.2 Pattern Matching in 'define_subst' 30232------------------------------------------ 30233 30234All expressions, allowed in 'define_insn' or 'define_expand', are 30235allowed in the input-template of 'define_subst', except 'match_par_dup', 30236'match_scratch', 'match_parallel'. The meanings of expressions in the 30237input-template were changed: 30238 30239 'match_operand' matches any expression (possibly, a subtree in 30240RTL-template), if modes of the 'match_operand' and this expression are 30241the same, or mode of the 'match_operand' is 'VOIDmode', or this 30242expression is 'match_dup', 'match_op_dup'. If the expression is 30243'match_operand' too, and predicate of 'match_operand' from the input 30244pattern is not empty, then the predicates are compared. That can be 30245used for more accurate filtering of accepted RTL-templates. 30246 30247 'match_operator' matches common operators (like 'plus', 'minus'), 30248'unspec', 'unspec_volatile' operators and 'match_operator's from the 30249original pattern if the modes match and 'match_operator' from the input 30250pattern has the same number of operands as the operator from the 30251original pattern. 30252 30253 30254File: gccint.info, Node: Define Subst Output Template, Prev: Define Subst Pattern Matching, Up: Define Subst 30255 3025617.21.3 Generation of output template in 'define_subst' 30257------------------------------------------------------- 30258 30259If all necessary checks for 'define_subst' application pass, a new 30260RTL-pattern, based on the output-template, is created to replace the old 30261template. Like in input-patterns, meanings of some RTL expressions are 30262changed when they are used in output-patterns of a 'define_subst'. 30263Thus, 'match_dup' is used for copying the whole expression from the 30264original pattern, which matched corresponding 'match_operand' from the 30265input pattern. 30266 30267 'match_dup N' is used in the output template to be replaced with the 30268expression from the original pattern, which matched 'match_operand N' 30269from the input pattern. As a consequence, 'match_dup' cannot be used to 30270point to 'match_operand's from the output pattern, it should always 30271refer to a 'match_operand' from the input pattern. If a 'match_dup N' 30272occurs more than once in the output template, its first occurrence is 30273replaced with the expression from the original pattern, and the 30274subsequent expressions are replaced with 'match_dup N', i.e., a 30275reference to the first expression. 30276 30277 In the output template one can refer to the expressions from the 30278original pattern and create new ones. For instance, some operands could 30279be added by means of standard 'match_operand'. 30280 30281 After replacing 'match_dup' with some RTL-subtree from the original 30282pattern, it could happen that several 'match_operand's in the output 30283pattern have the same indexes. It is unknown, how many and what indexes 30284would be used in the expression which would replace 'match_dup', so such 30285conflicts in indexes are inevitable. To overcome this issue, 30286'match_operands' and 'match_operators', which were introduced into the 30287output pattern, are renumerated when all 'match_dup's are replaced. 30288 30289 Number of alternatives in 'match_operand's introduced into the output 30290template 'M' could differ from the number of alternatives in the 30291original pattern 'N', so in the resultant pattern there would be 'N*M' 30292alternatives. Thus, constraints from the original pattern would be 30293duplicated 'N' times, constraints from the output pattern would be 30294duplicated 'M' times, producing all possible combinations. 30295 30296 30297File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Define Subst, Up: Machine Desc 30298 3029917.22 Constant Definitions 30300========================== 30301 30302Using literal constants inside instruction patterns reduces legibility 30303and can be a maintenance problem. 30304 30305 To overcome this problem, you may use the 'define_constants' 30306expression. It contains a vector of name-value pairs. From that point 30307on, wherever any of the names appears in the MD file, it is as if the 30308corresponding value had been written instead. You may use 30309'define_constants' multiple times; each appearance adds more constants 30310to the table. It is an error to redefine a constant with a different 30311value. 30312 30313 To come back to the a29k load multiple example, instead of 30314 30315 (define_insn "" 30316 [(match_parallel 0 "load_multiple_operation" 30317 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 30318 (match_operand:SI 2 "memory_operand" "m")) 30319 (use (reg:SI 179)) 30320 (clobber (reg:SI 179))])] 30321 "" 30322 "loadm 0,0,%1,%2") 30323 30324 You could write: 30325 30326 (define_constants [ 30327 (R_BP 177) 30328 (R_FC 178) 30329 (R_CR 179) 30330 (R_Q 180) 30331 ]) 30332 30333 (define_insn "" 30334 [(match_parallel 0 "load_multiple_operation" 30335 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 30336 (match_operand:SI 2 "memory_operand" "m")) 30337 (use (reg:SI R_CR)) 30338 (clobber (reg:SI R_CR))])] 30339 "" 30340 "loadm 0,0,%1,%2") 30341 30342 The constants that are defined with a define_constant are also output 30343in the insn-codes.h header file as #defines. 30344 30345 You can also use the machine description file to define enumerations. 30346Like the constants defined by 'define_constant', these enumerations are 30347visible to both the machine description file and the main C code. 30348 30349 The syntax is as follows: 30350 30351 (define_c_enum "NAME" [ 30352 VALUE0 30353 VALUE1 30354 ... 30355 VALUEN 30356 ]) 30357 30358 This definition causes the equivalent of the following C code to appear 30359in 'insn-constants.h': 30360 30361 enum NAME { 30362 VALUE0 = 0, 30363 VALUE1 = 1, 30364 ... 30365 VALUEN = N 30366 }; 30367 #define NUM_CNAME_VALUES (N + 1) 30368 30369 where CNAME is the capitalized form of NAME. It also makes each VALUEI 30370available in the machine description file, just as if it had been 30371declared with: 30372 30373 (define_constants [(VALUEI I)]) 30374 30375 Each VALUEI is usually an upper-case identifier and usually begins with 30376CNAME. 30377 30378 You can split the enumeration definition into as many statements as you 30379like. The above example is directly equivalent to: 30380 30381 (define_c_enum "NAME" [VALUE0]) 30382 (define_c_enum "NAME" [VALUE1]) 30383 ... 30384 (define_c_enum "NAME" [VALUEN]) 30385 30386 Splitting the enumeration helps to improve the modularity of each 30387individual '.md' file. For example, if a port defines its 30388synchronization instructions in a separate 'sync.md' file, it is 30389convenient to define all synchronization-specific enumeration values in 30390'sync.md' rather than in the main '.md' file. 30391 30392 Some enumeration names have special significance to GCC: 30393 30394'unspecv' 30395 If an enumeration called 'unspecv' is defined, GCC will use it when 30396 printing out 'unspec_volatile' expressions. For example: 30397 30398 (define_c_enum "unspecv" [ 30399 UNSPECV_BLOCKAGE 30400 ]) 30401 30402 causes GCC to print '(unspec_volatile ... 0)' as: 30403 30404 (unspec_volatile ... UNSPECV_BLOCKAGE) 30405 30406'unspec' 30407 If an enumeration called 'unspec' is defined, GCC will use it when 30408 printing out 'unspec' expressions. GCC will also use it when 30409 printing out 'unspec_volatile' expressions unless an 'unspecv' 30410 enumeration is also defined. You can therefore decide whether to 30411 keep separate enumerations for volatile and non-volatile 30412 expressions or whether to use the same enumeration for both. 30413 30414 Another way of defining an enumeration is to use 'define_enum': 30415 30416 (define_enum "NAME" [ 30417 VALUE0 30418 VALUE1 30419 ... 30420 VALUEN 30421 ]) 30422 30423 This directive implies: 30424 30425 (define_c_enum "NAME" [ 30426 CNAME_CVALUE0 30427 CNAME_CVALUE1 30428 ... 30429 CNAME_CVALUEN 30430 ]) 30431 30432 where CVALUEI is the capitalized form of VALUEI. However, unlike 30433'define_c_enum', the enumerations defined by 'define_enum' can be used 30434in attribute specifications (*note define_enum_attr::). 30435 30436 30437File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 30438 3043917.23 Iterators 30440=============== 30441 30442Ports often need to define similar patterns for more than one machine 30443mode or for more than one rtx code. GCC provides some simple iterator 30444facilities to make this process easier. 30445 30446* Menu: 30447 30448* Mode Iterators:: Generating variations of patterns for different modes. 30449* Code Iterators:: Doing the same for codes. 30450* Int Iterators:: Doing the same for integers. 30451* Subst Iterators:: Generating variations of patterns for define_subst. 30452* Parameterized Names:: Specifying iterator values in C++ code. 30453 30454 30455File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 30456 3045717.23.1 Mode Iterators 30458---------------------- 30459 30460Ports often need to define similar patterns for two or more different 30461modes. For example: 30462 30463 * If a processor has hardware support for both single and double 30464 floating-point arithmetic, the 'SFmode' patterns tend to be very 30465 similar to the 'DFmode' ones. 30466 30467 * If a port uses 'SImode' pointers in one configuration and 'DImode' 30468 pointers in another, it will usually have very similar 'SImode' and 30469 'DImode' patterns for manipulating pointers. 30470 30471 Mode iterators allow several patterns to be instantiated from one '.md' 30472file template. They can be used with any type of rtx-based construct, 30473such as a 'define_insn', 'define_split', or 'define_peephole2'. 30474 30475* Menu: 30476 30477* Defining Mode Iterators:: Defining a new mode iterator. 30478* Substitutions:: Combining mode iterators with substitutions 30479* Examples:: Examples 30480 30481 30482File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 30483 3048417.23.1.1 Defining Mode Iterators 30485................................. 30486 30487The syntax for defining a mode iterator is: 30488 30489 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 30490 30491 This allows subsequent '.md' file constructs to use the mode suffix 30492':NAME'. Every construct that does so will be expanded N times, once 30493with every use of ':NAME' replaced by ':MODE1', once with every use 30494replaced by ':MODE2', and so on. In the expansion for a particular 30495MODEI, every C condition will also require that CONDI be true. 30496 30497 For example: 30498 30499 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 30500 30501 defines a new mode suffix ':P'. Every construct that uses ':P' will be 30502expanded twice, once with every ':P' replaced by ':SI' and once with 30503every ':P' replaced by ':DI'. The ':SI' version will only apply if 30504'Pmode == SImode' and the ':DI' version will only apply if 'Pmode == 30505DImode'. 30506 30507 As with other '.md' conditions, an empty string is treated as "always 30508true". '(MODE "")' can also be abbreviated to 'MODE'. For example: 30509 30510 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 30511 30512 means that the ':DI' expansion only applies if 'TARGET_64BIT' but that 30513the ':SI' expansion has no such constraint. 30514 30515 Iterators are applied in the order they are defined. This can be 30516significant if two iterators are used in a construct that requires 30517substitutions. *Note Substitutions::. 30518 30519 30520File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 30521 3052217.23.1.2 Substitution in Mode Iterators 30523........................................ 30524 30525If an '.md' file construct uses mode iterators, each version of the 30526construct will often need slightly different strings or modes. For 30527example: 30528 30529 * When a 'define_expand' defines several 'addM3' patterns (*note 30530 Standard Names::), each expander will need to use the appropriate 30531 mode name for M. 30532 30533 * When a 'define_insn' defines several instruction patterns, each 30534 instruction will often use a different assembler mnemonic. 30535 30536 * When a 'define_insn' requires operands with different modes, using 30537 an iterator for one of the operand modes usually requires a 30538 specific mode for the other operand(s). 30539 30540 GCC supports such variations through a system of "mode attributes". 30541There are two standard attributes: 'mode', which is the name of the mode 30542in lower case, and 'MODE', which is the same thing in upper case. You 30543can define other attributes using: 30544 30545 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 30546 30547 where NAME is the name of the attribute and VALUEI is the value 30548associated with MODEI. 30549 30550 When GCC replaces some :ITERATOR with :MODE, it will scan each string 30551and mode in the pattern for sequences of the form '<ITERATOR:ATTR>', 30552where ATTR is the name of a mode attribute. If the attribute is defined 30553for MODE, the whole '<...>' sequence will be replaced by the appropriate 30554attribute value. 30555 30556 For example, suppose an '.md' file has: 30557 30558 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 30559 (define_mode_attr load [(SI "lw") (DI "ld")]) 30560 30561 If one of the patterns that uses ':P' contains the string 30562'"<P:load>\t%0,%1"', the 'SI' version of that pattern will use 30563'"lw\t%0,%1"' and the 'DI' version will use '"ld\t%0,%1"'. 30564 30565 Here is an example of using an attribute for a mode: 30566 30567 (define_mode_iterator LONG [SI DI]) 30568 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 30569 (define_insn ... 30570 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 30571 30572 The 'ITERATOR:' prefix may be omitted, in which case the substitution 30573will be attempted for every iterator expansion. 30574 30575 30576File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 30577 3057817.23.1.3 Mode Iterator Examples 30579................................ 30580 30581Here is an example from the MIPS port. It defines the following modes 30582and attributes (among others): 30583 30584 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 30585 (define_mode_attr d [(SI "") (DI "d")]) 30586 30587 and uses the following template to define both 'subsi3' and 'subdi3': 30588 30589 (define_insn "sub<mode>3" 30590 [(set (match_operand:GPR 0 "register_operand" "=d") 30591 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 30592 (match_operand:GPR 2 "register_operand" "d")))] 30593 "" 30594 "<d>subu\t%0,%1,%2" 30595 [(set_attr "type" "arith") 30596 (set_attr "mode" "<MODE>")]) 30597 30598 This is exactly equivalent to: 30599 30600 (define_insn "subsi3" 30601 [(set (match_operand:SI 0 "register_operand" "=d") 30602 (minus:SI (match_operand:SI 1 "register_operand" "d") 30603 (match_operand:SI 2 "register_operand" "d")))] 30604 "" 30605 "subu\t%0,%1,%2" 30606 [(set_attr "type" "arith") 30607 (set_attr "mode" "SI")]) 30608 30609 (define_insn "subdi3" 30610 [(set (match_operand:DI 0 "register_operand" "=d") 30611 (minus:DI (match_operand:DI 1 "register_operand" "d") 30612 (match_operand:DI 2 "register_operand" "d")))] 30613 "" 30614 "dsubu\t%0,%1,%2" 30615 [(set_attr "type" "arith") 30616 (set_attr "mode" "DI")]) 30617 30618 30619File: gccint.info, Node: Code Iterators, Next: Int Iterators, Prev: Mode Iterators, Up: Iterators 30620 3062117.23.2 Code Iterators 30622---------------------- 30623 30624Code iterators operate in a similar way to mode iterators. *Note Mode 30625Iterators::. 30626 30627 The construct: 30628 30629 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 30630 30631 defines a pseudo rtx code NAME that can be instantiated as CODEI if 30632condition CONDI is true. Each CODEI must have the same rtx format. 30633*Note RTL Classes::. 30634 30635 As with mode iterators, each pattern that uses NAME will be expanded N 30636times, once with all uses of NAME replaced by CODE1, once with all uses 30637replaced by CODE2, and so on. *Note Defining Mode Iterators::. 30638 30639 It is possible to define attributes for codes as well as for modes. 30640There are two standard code attributes: 'code', the name of the code in 30641lower case, and 'CODE', the name of the code in upper case. Other 30642attributes are defined using: 30643 30644 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 30645 30646 Instruction patterns can use code attributes as rtx codes, which can be 30647useful if two sets of codes act in tandem. For example, the following 30648'define_insn' defines two patterns, one calculating a signed absolute 30649difference and another calculating an unsigned absolute difference: 30650 30651 (define_code_iterator any_max [smax umax]) 30652 (define_code_attr paired_min [(smax "smin") (umax "umin")]) 30653 (define_insn ... 30654 [(set (match_operand:SI 0 ...) 30655 (minus:SI (any_max:SI (match_operand:SI 1 ...) 30656 (match_operand:SI 2 ...)) 30657 (<paired_min>:SI (match_dup 1) (match_dup 2))))] 30658 ...) 30659 30660 The signed version of the instruction uses 'smax' and 'smin' while the 30661unsigned version uses 'umax' and 'umin'. There are no versions that 30662pair 'smax' with 'umin' or 'umax' with 'smin'. 30663 30664 Here's an example of code iterators in action, taken from the MIPS 30665port: 30666 30667 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 30668 eq ne gt ge lt le gtu geu ltu leu]) 30669 30670 (define_expand "b<code>" 30671 [(set (pc) 30672 (if_then_else (any_cond:CC (cc0) 30673 (const_int 0)) 30674 (label_ref (match_operand 0 "")) 30675 (pc)))] 30676 "" 30677 { 30678 gen_conditional_branch (operands, <CODE>); 30679 DONE; 30680 }) 30681 30682 This is equivalent to: 30683 30684 (define_expand "bunordered" 30685 [(set (pc) 30686 (if_then_else (unordered:CC (cc0) 30687 (const_int 0)) 30688 (label_ref (match_operand 0 "")) 30689 (pc)))] 30690 "" 30691 { 30692 gen_conditional_branch (operands, UNORDERED); 30693 DONE; 30694 }) 30695 30696 (define_expand "bordered" 30697 [(set (pc) 30698 (if_then_else (ordered:CC (cc0) 30699 (const_int 0)) 30700 (label_ref (match_operand 0 "")) 30701 (pc)))] 30702 "" 30703 { 30704 gen_conditional_branch (operands, ORDERED); 30705 DONE; 30706 }) 30707 30708 ... 30709 30710 30711File: gccint.info, Node: Int Iterators, Next: Subst Iterators, Prev: Code Iterators, Up: Iterators 30712 3071317.23.3 Int Iterators 30714--------------------- 30715 30716Int iterators operate in a similar way to code iterators. *Note Code 30717Iterators::. 30718 30719 The construct: 30720 30721 (define_int_iterator NAME [(INT1 "COND1") ... (INTN "CONDN")]) 30722 30723 defines a pseudo integer constant NAME that can be instantiated as INTI 30724if condition CONDI is true. Each INT must have the same rtx format. 30725*Note RTL Classes::. Int iterators can appear in only those rtx fields 30726that have 'i' as the specifier. This means that each INT has to be a 30727constant defined using define_constant or define_c_enum. 30728 30729 As with mode and code iterators, each pattern that uses NAME will be 30730expanded N times, once with all uses of NAME replaced by INT1, once with 30731all uses replaced by INT2, and so on. *Note Defining Mode Iterators::. 30732 30733 It is possible to define attributes for ints as well as for codes and 30734modes. Attributes are defined using: 30735 30736 (define_int_attr NAME [(INT1 "VALUE1") ... (INTN "VALUEN")]) 30737 30738 Here's an example of int iterators in action, taken from the ARM port: 30739 30740 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 30741 30742 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 30743 30744 (define_insn "neon_vq<absneg><mode>" 30745 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 30746 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 30747 (match_operand:SI 2 "immediate_operand" "i")] 30748 QABSNEG))] 30749 "TARGET_NEON" 30750 "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 30751 [(set_attr "type" "neon_vqneg_vqabs")] 30752 ) 30753 30754 30755 This is equivalent to: 30756 30757 (define_insn "neon_vqabs<mode>" 30758 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 30759 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 30760 (match_operand:SI 2 "immediate_operand" "i")] 30761 UNSPEC_VQABS))] 30762 "TARGET_NEON" 30763 "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 30764 [(set_attr "type" "neon_vqneg_vqabs")] 30765 ) 30766 30767 (define_insn "neon_vqneg<mode>" 30768 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 30769 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 30770 (match_operand:SI 2 "immediate_operand" "i")] 30771 UNSPEC_VQNEG))] 30772 "TARGET_NEON" 30773 "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 30774 [(set_attr "type" "neon_vqneg_vqabs")] 30775 ) 30776 30777 30778 30779File: gccint.info, Node: Subst Iterators, Next: Parameterized Names, Prev: Int Iterators, Up: Iterators 30780 3078117.23.4 Subst Iterators 30782----------------------- 30783 30784Subst iterators are special type of iterators with the following 30785restrictions: they could not be declared explicitly, they always have 30786only two values, and they do not have explicit dedicated name. 30787Subst-iterators are triggered only when corresponding subst-attribute is 30788used in RTL-pattern. 30789 30790 Subst iterators transform templates in the following way: the templates 30791are duplicated, the subst-attributes in these templates are replaced 30792with the corresponding values, and a new attribute is implicitly added 30793to the given 'define_insn'/'define_expand'. The name of the added 30794attribute matches the name of 'define_subst'. Such attributes are 30795declared implicitly, and it is not allowed to have a 'define_attr' named 30796as a 'define_subst'. 30797 30798 Each subst iterator is linked to a 'define_subst'. It is declared 30799implicitly by the first appearance of the corresponding 30800'define_subst_attr', and it is not allowed to define it explicitly. 30801 30802 Declarations of subst-attributes have the following syntax: 30803 30804 (define_subst_attr "NAME" 30805 "SUBST-NAME" 30806 "NO-SUBST-VALUE" 30807 "SUBST-APPLIED-VALUE") 30808 30809 NAME is a string with which the given subst-attribute could be referred 30810to. 30811 30812 SUBST-NAME shows which 'define_subst' should be applied to an 30813RTL-template if the given subst-attribute is present in the 30814RTL-template. 30815 30816 NO-SUBST-VALUE is a value with which subst-attribute would be replaced 30817in the first copy of the original RTL-template. 30818 30819 SUBST-APPLIED-VALUE is a value with which subst-attribute would be 30820replaced in the second copy of the original RTL-template. 30821 30822 30823File: gccint.info, Node: Parameterized Names, Prev: Subst Iterators, Up: Iterators 30824 3082517.23.5 Parameterized Names 30826--------------------------- 30827 30828Ports sometimes need to apply iterators using C++ code, in order to get 30829the code or RTL pattern for a specific instruction. For example, 30830suppose we have the 'neon_vq<absneg><mode>' pattern given above: 30831 30832 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 30833 30834 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 30835 30836 (define_insn "neon_vq<absneg><mode>" 30837 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 30838 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 30839 (match_operand:SI 2 "immediate_operand" "i")] 30840 QABSNEG))] 30841 ... 30842 ) 30843 30844 A port might need to generate this pattern for a variable 'QABSNEG' 30845value and a variable 'VDQIW' mode. There are two ways of doing this. 30846The first is to build the rtx for the pattern directly from C++ code; 30847this is a valid technique and avoids any risk of combinatorial 30848explosion. The second is to prefix the instruction name with the 30849special character '@', which tells GCC to generate the four additional 30850functions below. In each case, NAME is the name of the instruction 30851without the leading '@' character, without the '<...>' placeholders, and 30852with any underscore before a '<...>' placeholder removed if keeping it 30853would lead to a double or trailing underscore. 30854 30855'insn_code maybe_code_for_NAME (I1, I2, ...)' 30856 See whether replacing the first '<...>' placeholder with iterator 30857 value I1, the second with iterator value I2, and so on, gives a 30858 valid instruction. Return its code if so, otherwise return 30859 'CODE_FOR_nothing'. 30860 30861'insn_code code_for_NAME (I1, I2, ...)' 30862 Same, but abort the compiler if the requested instruction does not 30863 exist. 30864 30865'rtx maybe_gen_NAME (I1, I2, ..., OP0, OP1, ...)' 30866 Check for a valid instruction in the same way as 30867 'maybe_code_for_NAME'. If the instruction exists, generate an 30868 instance of it using the operand values given by OP0, OP1, and so 30869 on, otherwise return null. 30870 30871'rtx gen_NAME (I1, I2, ..., OP0, OP1, ...)' 30872 Same, but abort the compiler if the requested instruction does not 30873 exist, or if the instruction generator invoked the 'FAIL' macro. 30874 30875 For example, changing the pattern above to: 30876 30877 (define_insn "@neon_vq<absneg><mode>" 30878 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 30879 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 30880 (match_operand:SI 2 "immediate_operand" "i")] 30881 QABSNEG))] 30882 ... 30883 ) 30884 30885 would define the same patterns as before, but in addition would 30886generate the four functions below: 30887 30888 insn_code maybe_code_for_neon_vq (int, machine_mode); 30889 insn_code code_for_neon_vq (int, machine_mode); 30890 rtx maybe_gen_neon_vq (int, machine_mode, rtx, rtx, rtx); 30891 rtx gen_neon_vq (int, machine_mode, rtx, rtx, rtx); 30892 30893 Calling 'code_for_neon_vq (UNSPEC_VQABS, V8QImode)' would then give 30894'CODE_FOR_neon_vqabsv8qi'. 30895 30896 It is possible to have multiple '@' patterns with the same name and 30897same types of iterator. For example: 30898 30899 (define_insn "@some_arithmetic_op<mode>" 30900 [(set (match_operand:INTEGER_MODES 0 "register_operand") ...)] 30901 ... 30902 ) 30903 30904 (define_insn "@some_arithmetic_op<mode>" 30905 [(set (match_operand:FLOAT_MODES 0 "register_operand") ...)] 30906 ... 30907 ) 30908 30909 would produce a single set of functions that handles both 30910'INTEGER_MODES' and 'FLOAT_MODES'. 30911 30912 It is also possible for these '@' patterns to have different numbers of 30913operands from each other. For example, patterns with a binary rtl code 30914might take three operands (one output and two inputs) while patterns 30915with a ternary rtl code might take four operands (one output and three 30916inputs). This combination would produce separate 'maybe_gen_NAME' and 30917'gen_NAME' functions for each operand count, but it would still produce 30918a single 'maybe_code_for_NAME' and a single 'code_for_NAME'. 30919 30920 30921File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 30922 3092318 Target Description Macros and Functions 30924****************************************** 30925 30926In addition to the file 'MACHINE.md', a machine description includes a C 30927header file conventionally given the name 'MACHINE.h' and a C source 30928file named 'MACHINE.c'. The header file defines numerous macros that 30929convey the information about the target machine that does not fit into 30930the scheme of the '.md' file. The file 'tm.h' should be a link to 30931'MACHINE.h'. The header file 'config.h' includes 'tm.h' and most 30932compiler source files include 'config.h'. The source file defines a 30933variable 'targetm', which is a structure containing pointers to 30934functions and data relating to the target machine. 'MACHINE.c' should 30935also contain their definitions, if they are not defined elsewhere in 30936GCC, and other functions called through the macros defined in the '.h' 30937file. 30938 30939* Menu: 30940 30941* Target Structure:: The 'targetm' variable. 30942* Driver:: Controlling how the driver runs the compilation passes. 30943* Run-time Target:: Defining '-m' options like '-m68000' and '-m68020'. 30944* Per-Function Data:: Defining data structures for per-function information. 30945* Storage Layout:: Defining sizes and alignments of data. 30946* Type Layout:: Defining sizes and properties of basic user data types. 30947* Registers:: Naming and describing the hardware registers. 30948* Register Classes:: Defining the classes of hardware registers. 30949* Stack and Calling:: Defining which way the stack grows and by how much. 30950* Varargs:: Defining the varargs macros. 30951* Trampolines:: Code set up at run time to enter a nested function. 30952* Library Calls:: Controlling how library routines are implicitly called. 30953* Addressing Modes:: Defining addressing modes valid for memory operands. 30954* Anchored Addresses:: Defining how '-fsection-anchors' should work. 30955* Condition Code:: Defining how insns update the condition code. 30956* Costs:: Defining relative costs of different operations. 30957* Scheduling:: Adjusting the behavior of the instruction scheduler. 30958* Sections:: Dividing storage into text, data, and other sections. 30959* PIC:: Macros for position independent code. 30960* Assembler Format:: Defining how to write insns and pseudo-ops to output. 30961* Debugging Info:: Defining the format of debugging output. 30962* Floating Point:: Handling floating point for cross-compilers. 30963* Mode Switching:: Insertion of mode-switching instructions. 30964* Target Attributes:: Defining target-specific uses of '__attribute__'. 30965* Emulated TLS:: Emulated TLS support. 30966* MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 30967* PCH Target:: Validity checking for precompiled headers. 30968* C++ ABI:: Controlling C++ ABI changes. 30969* D Language and ABI:: Controlling D ABI changes. 30970* Named Address Spaces:: Adding support for named address spaces 30971* Misc:: Everything else. 30972 30973 30974File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 30975 3097618.1 The Global 'targetm' Variable 30977================================== 30978 30979 -- Variable: struct gcc_target targetm 30980 The target '.c' file must define the global 'targetm' variable 30981 which contains pointers to functions and data relating to the 30982 target machine. The variable is declared in 'target.h'; 30983 'target-def.h' defines the macro 'TARGET_INITIALIZER' which is used 30984 to initialize the variable, and macros for the default initializers 30985 for elements of the structure. The '.c' file should override those 30986 macros for which the default definition is inappropriate. For 30987 example: 30988 #include "target.h" 30989 #include "target-def.h" 30990 30991 /* Initialize the GCC target structure. */ 30992 30993 #undef TARGET_COMP_TYPE_ATTRIBUTES 30994 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 30995 30996 struct gcc_target targetm = TARGET_INITIALIZER; 30997 30998 Where a macro should be defined in the '.c' file in this manner to form 30999part of the 'targetm' structure, it is documented below as a "Target 31000Hook" with a prototype. Many macros will change in future from being 31001defined in the '.h' file to being part of the 'targetm' structure. 31002 31003 Similarly, there is a 'targetcm' variable for hooks that are specific 31004to front ends for C-family languages, documented as "C Target Hook". 31005This is declared in 'c-family/c-target.h', the initializer 31006'TARGETCM_INITIALIZER' in 'c-family/c-target-def.h'. If targets 31007initialize 'targetcm' themselves, they should set 31008'target_has_targetcm=yes' in 'config.gcc'; otherwise a default 31009definition is used. 31010 31011 Similarly, there is a 'targetm_common' variable for hooks that are 31012shared between the compiler driver and the compilers proper, documented 31013as "Common Target Hook". This is declared in 'common/common-target.h', 31014the initializer 'TARGETM_COMMON_INITIALIZER' in 31015'common/common-target-def.h'. If targets initialize 'targetm_common' 31016themselves, they should set 'target_has_targetm_common=yes' in 31017'config.gcc'; otherwise a default definition is used. 31018 31019 Similarly, there is a 'targetdm' variable for hooks that are specific 31020to the D language front end, documented as "D Target Hook". This is 31021declared in 'd/d-target.h', the initializer 'TARGETDM_INITIALIZER' in 31022'd/d-target-def.h'. If targets initialize 'targetdm' themselves, they 31023should set 'target_has_targetdm=yes' in 'config.gcc'; otherwise a 31024default definition is used. 31025 31026 31027File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 31028 3102918.2 Controlling the Compilation Driver, 'gcc' 31030============================================== 31031 31032You can control the compilation driver. 31033 31034 -- Macro: DRIVER_SELF_SPECS 31035 A list of specs for the driver itself. It should be a suitable 31036 initializer for an array of strings, with no surrounding braces. 31037 31038 The driver applies these specs to its own command line between 31039 loading default 'specs' files (but not command-line specified ones) 31040 and choosing the multilib directory or running any subcommands. It 31041 applies them in the order given, so each spec can depend on the 31042 options added by earlier ones. It is also possible to remove 31043 options using '%<OPTION' in the usual way. 31044 31045 This macro can be useful when a port has several interdependent 31046 target options. It provides a way of standardizing the command 31047 line so that the other specs are easier to write. 31048 31049 Do not define this macro if it does not need to do anything. 31050 31051 -- Macro: OPTION_DEFAULT_SPECS 31052 A list of specs used to support configure-time default options 31053 (i.e. '--with' options) in the driver. It should be a suitable 31054 initializer for an array of structures, each containing two 31055 strings, without the outermost pair of surrounding braces. 31056 31057 The first item in the pair is the name of the default. This must 31058 match the code in 'config.gcc' for the target. The second item is 31059 a spec to apply if a default with this name was specified. The 31060 string '%(VALUE)' in the spec will be replaced by the value of the 31061 default everywhere it occurs. 31062 31063 The driver will apply these specs to its own command line between 31064 loading default 'specs' files and processing 'DRIVER_SELF_SPECS', 31065 using the same mechanism as 'DRIVER_SELF_SPECS'. 31066 31067 Do not define this macro if it does not need to do anything. 31068 31069 -- Macro: CPP_SPEC 31070 A C string constant that tells the GCC driver program options to 31071 pass to CPP. It can also specify how to translate options you give 31072 to GCC into options for GCC to pass to the CPP. 31073 31074 Do not define this macro if it does not need to do anything. 31075 31076 -- Macro: CPLUSPLUS_CPP_SPEC 31077 This macro is just like 'CPP_SPEC', but is used for C++, rather 31078 than C. If you do not define this macro, then the value of 31079 'CPP_SPEC' (if any) will be used instead. 31080 31081 -- Macro: CC1_SPEC 31082 A C string constant that tells the GCC driver program options to 31083 pass to 'cc1', 'cc1plus', 'f771', and the other language front 31084 ends. It can also specify how to translate options you give to GCC 31085 into options for GCC to pass to front ends. 31086 31087 Do not define this macro if it does not need to do anything. 31088 31089 -- Macro: CC1PLUS_SPEC 31090 A C string constant that tells the GCC driver program options to 31091 pass to 'cc1plus'. It can also specify how to translate options 31092 you give to GCC into options for GCC to pass to the 'cc1plus'. 31093 31094 Do not define this macro if it does not need to do anything. Note 31095 that everything defined in CC1_SPEC is already passed to 'cc1plus' 31096 so there is no need to duplicate the contents of CC1_SPEC in 31097 CC1PLUS_SPEC. 31098 31099 -- Macro: ASM_SPEC 31100 A C string constant that tells the GCC driver program options to 31101 pass to the assembler. It can also specify how to translate 31102 options you give to GCC into options for GCC to pass to the 31103 assembler. See the file 'sun3.h' for an example of this. 31104 31105 Do not define this macro if it does not need to do anything. 31106 31107 -- Macro: ASM_FINAL_SPEC 31108 A C string constant that tells the GCC driver program how to run 31109 any programs which cleanup after the normal assembler. Normally, 31110 this is not needed. See the file 'mips.h' for an example of this. 31111 31112 Do not define this macro if it does not need to do anything. 31113 31114 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 31115 Define this macro, with no value, if the driver should give the 31116 assembler an argument consisting of a single dash, '-', to instruct 31117 it to read from its standard input (which will be a pipe connected 31118 to the output of the compiler proper). This argument is given 31119 after any '-o' option specifying the name of the output file. 31120 31121 If you do not define this macro, the assembler is assumed to read 31122 its standard input if given no non-option arguments. If your 31123 assembler cannot read standard input at all, use a '%{pipe:%e}' 31124 construct; see 'mips.h' for instance. 31125 31126 -- Macro: LINK_SPEC 31127 A C string constant that tells the GCC driver program options to 31128 pass to the linker. It can also specify how to translate options 31129 you give to GCC into options for GCC to pass to the linker. 31130 31131 Do not define this macro if it does not need to do anything. 31132 31133 -- Macro: LIB_SPEC 31134 Another C string constant used much like 'LINK_SPEC'. The 31135 difference between the two is that 'LIB_SPEC' is used at the end of 31136 the command given to the linker. 31137 31138 If this macro is not defined, a default is provided that loads the 31139 standard C library from the usual place. See 'gcc.c'. 31140 31141 -- Macro: LIBGCC_SPEC 31142 Another C string constant that tells the GCC driver program how and 31143 when to place a reference to 'libgcc.a' into the linker command 31144 line. This constant is placed both before and after the value of 31145 'LIB_SPEC'. 31146 31147 If this macro is not defined, the GCC driver provides a default 31148 that passes the string '-lgcc' to the linker. 31149 31150 -- Macro: REAL_LIBGCC_SPEC 31151 By default, if 'ENABLE_SHARED_LIBGCC' is defined, the 'LIBGCC_SPEC' 31152 is not directly used by the driver program but is instead modified 31153 to refer to different versions of 'libgcc.a' depending on the 31154 values of the command line flags '-static', '-shared', 31155 '-static-libgcc', and '-shared-libgcc'. On targets where these 31156 modifications are inappropriate, define 'REAL_LIBGCC_SPEC' instead. 31157 'REAL_LIBGCC_SPEC' tells the driver how to place a reference to 31158 'libgcc' on the link command line, but, unlike 'LIBGCC_SPEC', it is 31159 used unmodified. 31160 31161 -- Macro: USE_LD_AS_NEEDED 31162 A macro that controls the modifications to 'LIBGCC_SPEC' mentioned 31163 in 'REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 31164 uses '--as-needed' or equivalent options and the shared 'libgcc' in 31165 place of the static exception handler library, when linking without 31166 any of '-static', '-static-libgcc', or '-shared-libgcc'. 31167 31168 -- Macro: LINK_EH_SPEC 31169 If defined, this C string constant is added to 'LINK_SPEC'. When 31170 'USE_LD_AS_NEEDED' is zero or undefined, it also affects the 31171 modifications to 'LIBGCC_SPEC' mentioned in 'REAL_LIBGCC_SPEC'. 31172 31173 -- Macro: STARTFILE_SPEC 31174 Another C string constant used much like 'LINK_SPEC'. The 31175 difference between the two is that 'STARTFILE_SPEC' is used at the 31176 very beginning of the command given to the linker. 31177 31178 If this macro is not defined, a default is provided that loads the 31179 standard C startup file from the usual place. See 'gcc.c'. 31180 31181 -- Macro: ENDFILE_SPEC 31182 Another C string constant used much like 'LINK_SPEC'. The 31183 difference between the two is that 'ENDFILE_SPEC' is used at the 31184 very end of the command given to the linker. 31185 31186 Do not define this macro if it does not need to do anything. 31187 31188 -- Macro: THREAD_MODEL_SPEC 31189 GCC '-v' will print the thread model GCC was configured to use. 31190 However, this doesn't work on platforms that are multilibbed on 31191 thread models, such as AIX 4.3. On such platforms, define 31192 'THREAD_MODEL_SPEC' such that it evaluates to a string without 31193 blanks that names one of the recognized thread models. '%*', the 31194 default value of this macro, will expand to the value of 31195 'thread_file' set in 'config.gcc'. 31196 31197 -- Macro: SYSROOT_SUFFIX_SPEC 31198 Define this macro to add a suffix to the target sysroot when GCC is 31199 configured with a sysroot. This will cause GCC to search for 31200 usr/lib, et al, within sysroot+suffix. 31201 31202 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 31203 Define this macro to add a headers_suffix to the target sysroot 31204 when GCC is configured with a sysroot. This will cause GCC to pass 31205 the updated sysroot+headers_suffix to CPP, causing it to search for 31206 usr/include, et al, within sysroot+headers_suffix. 31207 31208 -- Macro: EXTRA_SPECS 31209 Define this macro to provide additional specifications to put in 31210 the 'specs' file that can be used in various specifications like 31211 'CC1_SPEC'. 31212 31213 The definition should be an initializer for an array of structures, 31214 containing a string constant, that defines the specification name, 31215 and a string constant that provides the specification. 31216 31217 Do not define this macro if it does not need to do anything. 31218 31219 'EXTRA_SPECS' is useful when an architecture contains several 31220 related targets, which have various '..._SPECS' which are similar 31221 to each other, and the maintainer would like one central place to 31222 keep these definitions. 31223 31224 For example, the PowerPC System V.4 targets use 'EXTRA_SPECS' to 31225 define either '_CALL_SYSV' when the System V calling sequence is 31226 used or '_CALL_AIX' when the older AIX-based calling sequence is 31227 used. 31228 31229 The 'config/rs6000/rs6000.h' target file defines: 31230 31231 #define EXTRA_SPECS \ 31232 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 31233 31234 #define CPP_SYS_DEFAULT "" 31235 31236 The 'config/rs6000/sysv.h' target file defines: 31237 #undef CPP_SPEC 31238 #define CPP_SPEC \ 31239 "%{posix: -D_POSIX_SOURCE } \ 31240 %{mcall-sysv: -D_CALL_SYSV } \ 31241 %{!mcall-sysv: %(cpp_sysv_default) } \ 31242 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 31243 31244 #undef CPP_SYSV_DEFAULT 31245 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 31246 31247 while the 'config/rs6000/eabiaix.h' target file defines 31248 'CPP_SYSV_DEFAULT' as: 31249 31250 #undef CPP_SYSV_DEFAULT 31251 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 31252 31253 -- Macro: LINK_LIBGCC_SPECIAL_1 31254 Define this macro if the driver program should find the library 31255 'libgcc.a'. If you do not define this macro, the driver program 31256 will pass the argument '-lgcc' to tell the linker to do the search. 31257 31258 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 31259 The sequence in which libgcc and libc are specified to the linker. 31260 By default this is '%G %L %G'. 31261 31262 -- Macro: POST_LINK_SPEC 31263 Define this macro to add additional steps to be executed after 31264 linker. The default value of this macro is empty string. 31265 31266 -- Macro: LINK_COMMAND_SPEC 31267 A C string constant giving the complete command line need to 31268 execute the linker. When you do this, you will need to update your 31269 port each time a change is made to the link command line within 31270 'gcc.c'. Therefore, define this macro only if you need to 31271 completely redefine the command line for invoking the linker and 31272 there is no other way to accomplish the effect you need. 31273 Overriding this macro may be avoidable by overriding 31274 'LINK_GCC_C_SEQUENCE_SPEC' instead. 31275 31276 -- Common Target Hook: bool TARGET_ALWAYS_STRIP_DOTDOT 31277 True if '..' components should always be removed from directory 31278 names computed relative to GCC's internal directories, false 31279 (default) if such components should be preserved and directory 31280 names containing them passed to other tools such as the linker. 31281 31282 -- Macro: MULTILIB_DEFAULTS 31283 Define this macro as a C expression for the initializer of an array 31284 of string to tell the driver program which options are defaults for 31285 this target and thus do not need to be handled specially when using 31286 'MULTILIB_OPTIONS'. 31287 31288 Do not define this macro if 'MULTILIB_OPTIONS' is not defined in 31289 the target makefile fragment or if none of the options listed in 31290 'MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 31291 31292 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 31293 Define this macro to tell 'gcc' that it should only translate a 31294 '-B' prefix into a '-L' linker option if the prefix indicates an 31295 absolute file name. 31296 31297 -- Macro: MD_EXEC_PREFIX 31298 If defined, this macro is an additional prefix to try after 31299 'STANDARD_EXEC_PREFIX'. 'MD_EXEC_PREFIX' is not searched when the 31300 compiler is built as a cross compiler. If you define 31301 'MD_EXEC_PREFIX', then be sure to add it to the list of directories 31302 used to find the assembler in 'configure.ac'. 31303 31304 -- Macro: STANDARD_STARTFILE_PREFIX 31305 Define this macro as a C string constant if you wish to override 31306 the standard choice of 'libdir' as the default prefix to try when 31307 searching for startup files such as 'crt0.o'. 31308 'STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 31309 built as a cross compiler. 31310 31311 -- Macro: STANDARD_STARTFILE_PREFIX_1 31312 Define this macro as a C string constant if you wish to override 31313 the standard choice of '/lib' as a prefix to try after the default 31314 prefix when searching for startup files such as 'crt0.o'. 31315 'STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 31316 built as a cross compiler. 31317 31318 -- Macro: STANDARD_STARTFILE_PREFIX_2 31319 Define this macro as a C string constant if you wish to override 31320 the standard choice of '/lib' as yet another prefix to try after 31321 the default prefix when searching for startup files such as 31322 'crt0.o'. 'STANDARD_STARTFILE_PREFIX_2' is not searched when the 31323 compiler is built as a cross compiler. 31324 31325 -- Macro: MD_STARTFILE_PREFIX 31326 If defined, this macro supplies an additional prefix to try after 31327 the standard prefixes. 'MD_EXEC_PREFIX' is not searched when the 31328 compiler is built as a cross compiler. 31329 31330 -- Macro: MD_STARTFILE_PREFIX_1 31331 If defined, this macro supplies yet another prefix to try after the 31332 standard prefixes. It is not searched when the compiler is built 31333 as a cross compiler. 31334 31335 -- Macro: INIT_ENVIRONMENT 31336 Define this macro as a C string constant if you wish to set 31337 environment variables for programs called by the driver, such as 31338 the assembler and loader. The driver passes the value of this 31339 macro to 'putenv' to initialize the necessary environment 31340 variables. 31341 31342 -- Macro: LOCAL_INCLUDE_DIR 31343 Define this macro as a C string constant if you wish to override 31344 the standard choice of '/usr/local/include' as the default prefix 31345 to try when searching for local header files. 'LOCAL_INCLUDE_DIR' 31346 comes before 'NATIVE_SYSTEM_HEADER_DIR' (set in 'config.gcc', 31347 normally '/usr/include') in the search order. 31348 31349 Cross compilers do not search either '/usr/local/include' or its 31350 replacement. 31351 31352 -- Macro: NATIVE_SYSTEM_HEADER_COMPONENT 31353 The "component" corresponding to 'NATIVE_SYSTEM_HEADER_DIR'. See 31354 'INCLUDE_DEFAULTS', below, for the description of components. If 31355 you do not define this macro, no component is used. 31356 31357 -- Macro: INCLUDE_DEFAULTS 31358 Define this macro if you wish to override the entire default search 31359 path for include files. For a native compiler, the default search 31360 path usually consists of 'GCC_INCLUDE_DIR', 'LOCAL_INCLUDE_DIR', 31361 'GPLUSPLUS_INCLUDE_DIR', and 'NATIVE_SYSTEM_HEADER_DIR'. In 31362 addition, 'GPLUSPLUS_INCLUDE_DIR' and 'GCC_INCLUDE_DIR' are defined 31363 automatically by 'Makefile', and specify private search areas for 31364 GCC. The directory 'GPLUSPLUS_INCLUDE_DIR' is used only for C++ 31365 programs. 31366 31367 The definition should be an initializer for an array of structures. 31368 Each array element should have four elements: the directory name (a 31369 string constant), the component name (also a string constant), a 31370 flag for C++-only directories, and a flag showing that the includes 31371 in the directory don't need to be wrapped in 'extern 'C'' when 31372 compiling C++. Mark the end of the array with a null element. 31373 31374 The component name denotes what GNU package the include file is 31375 part of, if any, in all uppercase letters. For example, it might 31376 be 'GCC' or 'BINUTILS'. If the package is part of a 31377 vendor-supplied operating system, code the component name as '0'. 31378 31379 For example, here is the definition used for VAX/VMS: 31380 31381 #define INCLUDE_DEFAULTS \ 31382 { \ 31383 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 31384 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 31385 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 31386 { ".", 0, 0, 0}, \ 31387 { 0, 0, 0, 0} \ 31388 } 31389 31390 Here is the order of prefixes tried for exec files: 31391 31392 1. Any prefixes specified by the user with '-B'. 31393 31394 2. The environment variable 'GCC_EXEC_PREFIX' or, if 'GCC_EXEC_PREFIX' 31395 is not set and the compiler has not been installed in the 31396 configure-time PREFIX, the location in which the compiler has 31397 actually been installed. 31398 31399 3. The directories specified by the environment variable 31400 'COMPILER_PATH'. 31401 31402 4. The macro 'STANDARD_EXEC_PREFIX', if the compiler has been 31403 installed in the configured-time PREFIX. 31404 31405 5. The location '/usr/libexec/gcc/', but only if this is a native 31406 compiler. 31407 31408 6. The location '/usr/lib/gcc/', but only if this is a native 31409 compiler. 31410 31411 7. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 31412 native compiler. 31413 31414 Here is the order of prefixes tried for startfiles: 31415 31416 1. Any prefixes specified by the user with '-B'. 31417 31418 2. The environment variable 'GCC_EXEC_PREFIX' or its automatically 31419 determined value based on the installed toolchain location. 31420 31421 3. The directories specified by the environment variable 31422 'LIBRARY_PATH' (or port-specific name; native only, cross compilers 31423 do not use this). 31424 31425 4. The macro 'STANDARD_EXEC_PREFIX', but only if the toolchain is 31426 installed in the configured PREFIX or this is a native compiler. 31427 31428 5. The location '/usr/lib/gcc/', but only if this is a native 31429 compiler. 31430 31431 6. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 31432 native compiler. 31433 31434 7. The macro 'MD_STARTFILE_PREFIX', if defined, but only if this is a 31435 native compiler, or we have a target system root. 31436 31437 8. The macro 'MD_STARTFILE_PREFIX_1', if defined, but only if this is 31438 a native compiler, or we have a target system root. 31439 31440 9. The macro 'STANDARD_STARTFILE_PREFIX', with any sysroot 31441 modifications. If this path is relative it will be prefixed by 31442 'GCC_EXEC_PREFIX' and the machine suffix or 'STANDARD_EXEC_PREFIX' 31443 and the machine suffix. 31444 31445 10. The macro 'STANDARD_STARTFILE_PREFIX_1', but only if this is a 31446 native compiler, or we have a target system root. The default for 31447 this macro is '/lib/'. 31448 31449 11. The macro 'STANDARD_STARTFILE_PREFIX_2', but only if this is a 31450 native compiler, or we have a target system root. The default for 31451 this macro is '/usr/lib/'. 31452 31453 31454File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 31455 3145618.3 Run-time Target Specification 31457================================== 31458 31459Here are run-time target specifications. 31460 31461 -- Macro: TARGET_CPU_CPP_BUILTINS () 31462 This function-like macro expands to a block of code that defines 31463 built-in preprocessor macros and assertions for the target CPU, 31464 using the functions 'builtin_define', 'builtin_define_std' and 31465 'builtin_assert'. When the front end calls this macro it provides 31466 a trailing semicolon, and since it has finished command line option 31467 processing your code can use those results freely. 31468 31469 'builtin_assert' takes a string in the form you pass to the 31470 command-line option '-A', such as 'cpu=mips', and creates the 31471 assertion. 'builtin_define' takes a string in the form accepted by 31472 option '-D' and unconditionally defines the macro. 31473 31474 'builtin_define_std' takes a string representing the name of an 31475 object-like macro. If it doesn't lie in the user's namespace, 31476 'builtin_define_std' defines it unconditionally. Otherwise, it 31477 defines a version with two leading underscores, and another version 31478 with two leading and trailing underscores, and defines the original 31479 only if an ISO standard was not requested on the command line. For 31480 example, passing 'unix' defines '__unix', '__unix__' and possibly 31481 'unix'; passing '_mips' defines '__mips', '__mips__' and possibly 31482 '_mips', and passing '_ABI64' defines only '_ABI64'. 31483 31484 You can also test for the C dialect being compiled. The variable 31485 'c_language' is set to one of 'clk_c', 'clk_cplusplus' or 31486 'clk_objective_c'. Note that if we are preprocessing assembler, 31487 this variable will be 'clk_c' but the function-like macro 31488 'preprocessing_asm_p()' will return true, so you might want to 31489 check for that first. If you need to check for strict ANSI, the 31490 variable 'flag_iso' can be used. The function-like macro 31491 'preprocessing_trad_p()' can be used to check for traditional 31492 preprocessing. 31493 31494 -- Macro: TARGET_OS_CPP_BUILTINS () 31495 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 31496 and is used for the target operating system instead. 31497 31498 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 31499 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 31500 and is used for the target object format. 'elfos.h' uses this 31501 macro to define '__ELF__', so you probably do not need to define it 31502 yourself. 31503 31504 -- Variable: extern int target_flags 31505 This variable is declared in 'options.h', which is included before 31506 any target-specific headers. 31507 31508 -- Common Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 31509 This variable specifies the initial value of 'target_flags'. Its 31510 default setting is 0. 31511 31512 -- Common Target Hook: bool TARGET_HANDLE_OPTION (struct gcc_options 31513 *OPTS, struct gcc_options *OPTS_SET, const struct 31514 cl_decoded_option *DECODED, location_t LOC) 31515 This hook is called whenever the user specifies one of the 31516 target-specific options described by the '.opt' definition files 31517 (*note Options::). It has the opportunity to do some 31518 option-specific processing and should return true if the option is 31519 valid. The default definition does nothing but return true. 31520 31521 DECODED specifies the option and its arguments. OPTS and OPTS_SET 31522 are the 'gcc_options' structures to be used for storing option 31523 state, and LOC is the location at which the option was passed 31524 ('UNKNOWN_LOCATION' except for options passed via attributes). 31525 31526 -- C Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 31527 *ARG, int VALUE) 31528 This target hook is called whenever the user specifies one of the 31529 target-specific C language family options described by the '.opt' 31530 definition files(*note Options::). It has the opportunity to do 31531 some option-specific processing and should return true if the 31532 option is valid. The arguments are like for 31533 'TARGET_HANDLE_OPTION'. The default definition does nothing but 31534 return false. 31535 31536 In general, you should use 'TARGET_HANDLE_OPTION' to handle 31537 options. However, if processing an option requires routines that 31538 are only available in the C (and related language) front ends, then 31539 you should use 'TARGET_HANDLE_C_OPTION' instead. 31540 31541 -- C Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree 31542 STRING) 31543 Targets may provide a string object type that can be used within 31544 and between C, C++ and their respective Objective-C dialects. A 31545 string object might, for example, embed encoding and length 31546 information. These objects are considered opaque to the compiler 31547 and handled as references. An ideal implementation makes the 31548 composition of the string object match that of the Objective-C 31549 'NSString' ('NXString' for GNUStep), allowing efficient 31550 interworking between C-only and Objective-C code. If a target 31551 implements string objects then this hook should return a reference 31552 to such an object constructed from the normal 'C' string 31553 representation provided in STRING. At present, the hook is used by 31554 Objective-C only, to obtain a common-format string object when the 31555 target provides one. 31556 31557 -- C Target Hook: void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE 31558 (const char *CLASSNAME) 31559 Declare that Objective C class CLASSNAME is referenced by the 31560 current TU. 31561 31562 -- C Target Hook: void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const char 31563 *CLASSNAME) 31564 Declare that Objective C class CLASSNAME is defined by the current 31565 TU. 31566 31567 -- C Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 31568 STRINGREF) 31569 If a target implements string objects then this hook should return 31570 'true' if STRINGREF is a valid reference to such an object. 31571 31572 -- C Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree 31573 FORMAT_ARG, tree ARGS_LIST) 31574 If a target implements string objects then this hook should should 31575 provide a facility to check the function arguments in ARGS_LIST 31576 against the format specifiers in FORMAT_ARG where the type of 31577 FORMAT_ARG is one recognized as a valid string reference type. 31578 31579 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 31580 This target function is similar to the hook 31581 'TARGET_OPTION_OVERRIDE' but is called when the optimize level is 31582 changed via an attribute or pragma or when it is reset at the end 31583 of the code affected by the attribute or pragma. It is not called 31584 at the beginning of compilation when 'TARGET_OPTION_OVERRIDE' is 31585 called so if you want to perform these actions then, you should 31586 have 'TARGET_OPTION_OVERRIDE' call 31587 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 31588 31589 -- Macro: C_COMMON_OVERRIDE_OPTIONS 31590 This is similar to the 'TARGET_OPTION_OVERRIDE' hook but is only 31591 used in the C language frontends (C, Objective-C, C++, 31592 Objective-C++) and so can be used to alter option flag variables 31593 which only exist in those frontends. 31594 31595 -- Common Target Hook: const struct default_options * 31596 TARGET_OPTION_OPTIMIZATION_TABLE 31597 Some machines may desire to change what optimizations are performed 31598 for various optimization levels. This variable, if defined, 31599 describes options to enable at particular sets of optimization 31600 levels. These options are processed once just after the 31601 optimization level is determined and before the remainder of the 31602 command options have been parsed, so may be overridden by other 31603 options passed explicitly. 31604 31605 This processing is run once at program startup and when the 31606 optimization options are changed via '#pragma GCC optimize' or by 31607 using the 'optimize' attribute. 31608 31609 -- Common Target Hook: void TARGET_OPTION_INIT_STRUCT (struct 31610 gcc_options *OPTS) 31611 Set target-dependent initial values of fields in OPTS. 31612 31613 -- Macro: SWITCHABLE_TARGET 31614 Some targets need to switch between substantially different 31615 subtargets during compilation. For example, the MIPS target has 31616 one subtarget for the traditional MIPS architecture and another for 31617 MIPS16. Source code can switch between these two subarchitectures 31618 using the 'mips16' and 'nomips16' attributes. 31619 31620 Such subtargets can differ in things like the set of available 31621 registers, the set of available instructions, the costs of various 31622 operations, and so on. GCC caches a lot of this type of 31623 information in global variables, and recomputing them for each 31624 subtarget takes a significant amount of time. The compiler 31625 therefore provides a facility for maintaining several versions of 31626 the global variables and quickly switching between them; see 31627 'target-globals.h' for details. 31628 31629 Define this macro to 1 if your target needs this facility. The 31630 default is 0. 31631 31632 -- Target Hook: bool TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P 31633 (void) 31634 Returns true if the target supports IEEE 754 floating-point 31635 exceptions and rounding modes, false otherwise. This is intended 31636 to relate to the 'float' and 'double' types, but not necessarily 31637 'long double'. By default, returns true if the 'adddf3' 31638 instruction pattern is available and false otherwise, on the 31639 assumption that hardware floating point supports exceptions and 31640 rounding modes but software floating point does not. 31641 31642 31643File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 31644 3164518.4 Defining data structures for per-function information. 31646=========================================================== 31647 31648If the target needs to store information on a per-function basis, GCC 31649provides a macro and a couple of variables to allow this. Note, just 31650using statics to store the information is a bad idea, since GCC supports 31651nested functions, so you can be halfway through encoding one function 31652when another one comes along. 31653 31654 GCC defines a data structure called 'struct function' which contains 31655all of the data specific to an individual function. This structure 31656contains a field called 'machine' whose type is 'struct machine_function 31657*', which can be used by targets to point to their own specific data. 31658 31659 If a target needs per-function specific data it should define the type 31660'struct machine_function' and also the macro 'INIT_EXPANDERS'. This 31661macro should be used to initialize the function pointer 31662'init_machine_status'. This pointer is explained below. 31663 31664 One typical use of per-function, target specific data is to create an 31665RTX to hold the register containing the function's return address. This 31666RTX can then be used to implement the '__builtin_return_address' 31667function, for level 0. 31668 31669 Note--earlier implementations of GCC used a single data area to hold 31670all of the per-function information. Thus when processing of a nested 31671function began the old per-function data had to be pushed onto a stack, 31672and when the processing was finished, it had to be popped off the stack. 31673GCC used to provide function pointers called 'save_machine_status' and 31674'restore_machine_status' to handle the saving and restoring of the 31675target specific information. Since the single data area approach is no 31676longer used, these pointers are no longer supported. 31677 31678 -- Macro: INIT_EXPANDERS 31679 Macro called to initialize any target specific information. This 31680 macro is called once per function, before generation of any RTL has 31681 begun. The intention of this macro is to allow the initialization 31682 of the function pointer 'init_machine_status'. 31683 31684 -- Variable: void (*)(struct function *) init_machine_status 31685 If this function pointer is non-'NULL' it will be called once per 31686 function, before function compilation starts, in order to allow the 31687 target to perform any target specific initialization of the 'struct 31688 function' structure. It is intended that this would be used to 31689 initialize the 'machine' of that structure. 31690 31691 'struct machine_function' structures are expected to be freed by 31692 GC. Generally, any memory that they reference must be allocated by 31693 using GC allocation, including the structure itself. 31694 31695 31696File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 31697 3169818.5 Storage Layout 31699=================== 31700 31701Note that the definitions of the macros in this table which are sizes or 31702alignments measured in bits do not need to be constant. They can be C 31703expressions that refer to static variables, such as the 'target_flags'. 31704*Note Run-time Target::. 31705 31706 -- Macro: BITS_BIG_ENDIAN 31707 Define this macro to have the value 1 if the most significant bit 31708 in a byte has the lowest number; otherwise define it to have the 31709 value zero. This means that bit-field instructions count from the 31710 most significant bit. If the machine has no bit-field 31711 instructions, then this must still be defined, but it doesn't 31712 matter which value it is defined to. This macro need not be a 31713 constant. 31714 31715 This macro does not affect the way structure fields are packed into 31716 bytes or words; that is controlled by 'BYTES_BIG_ENDIAN'. 31717 31718 -- Macro: BYTES_BIG_ENDIAN 31719 Define this macro to have the value 1 if the most significant byte 31720 in a word has the lowest number. This macro need not be a 31721 constant. 31722 31723 -- Macro: WORDS_BIG_ENDIAN 31724 Define this macro to have the value 1 if, in a multiword object, 31725 the most significant word has the lowest number. This applies to 31726 both memory locations and registers; see 'REG_WORDS_BIG_ENDIAN' if 31727 the order of words in memory is not the same as the order in 31728 registers. This macro need not be a constant. 31729 31730 -- Macro: REG_WORDS_BIG_ENDIAN 31731 On some machines, the order of words in a multiword object differs 31732 between registers in memory. In such a situation, define this 31733 macro to describe the order of words in a register. The macro 31734 'WORDS_BIG_ENDIAN' controls the order of words in memory. 31735 31736 -- Macro: FLOAT_WORDS_BIG_ENDIAN 31737 Define this macro to have the value 1 if 'DFmode', 'XFmode' or 31738 'TFmode' floating point numbers are stored in memory with the word 31739 containing the sign bit at the lowest address; otherwise define it 31740 to have the value 0. This macro need not be a constant. 31741 31742 You need not define this macro if the ordering is the same as for 31743 multi-word integers. 31744 31745 -- Macro: BITS_PER_WORD 31746 Number of bits in a word. If you do not define this macro, the 31747 default is 'BITS_PER_UNIT * UNITS_PER_WORD'. 31748 31749 -- Macro: MAX_BITS_PER_WORD 31750 Maximum number of bits in a word. If this is undefined, the 31751 default is 'BITS_PER_WORD'. Otherwise, it is the constant value 31752 that is the largest value that 'BITS_PER_WORD' can have at 31753 run-time. 31754 31755 -- Macro: UNITS_PER_WORD 31756 Number of storage units in a word; normally the size of a 31757 general-purpose register, a power of two from 1 or 8. 31758 31759 -- Macro: MIN_UNITS_PER_WORD 31760 Minimum number of units in a word. If this is undefined, the 31761 default is 'UNITS_PER_WORD'. Otherwise, it is the constant value 31762 that is the smallest value that 'UNITS_PER_WORD' can have at 31763 run-time. 31764 31765 -- Macro: POINTER_SIZE 31766 Width of a pointer, in bits. You must specify a value no wider 31767 than the width of 'Pmode'. If it is not equal to the width of 31768 'Pmode', you must define 'POINTERS_EXTEND_UNSIGNED'. If you do not 31769 specify a value the default is 'BITS_PER_WORD'. 31770 31771 -- Macro: POINTERS_EXTEND_UNSIGNED 31772 A C expression that determines how pointers should be extended from 31773 'ptr_mode' to either 'Pmode' or 'word_mode'. It is greater than 31774 zero if pointers should be zero-extended, zero if they should be 31775 sign-extended, and negative if some other sort of conversion is 31776 needed. In the last case, the extension is done by the target's 31777 'ptr_extend' instruction. 31778 31779 You need not define this macro if the 'ptr_mode', 'Pmode' and 31780 'word_mode' are all the same width. 31781 31782 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 31783 A macro to update M and UNSIGNEDP when an object whose type is TYPE 31784 and which has the specified mode and signedness is to be stored in 31785 a register. This macro is only called when TYPE is a scalar type. 31786 31787 On most RISC machines, which only have operations that operate on a 31788 full register, define this macro to set M to 'word_mode' if M is an 31789 integer mode narrower than 'BITS_PER_WORD'. In most cases, only 31790 integer modes should be widened because wider-precision 31791 floating-point operations are usually more expensive than their 31792 narrower counterparts. 31793 31794 For most machines, the macro definition does not change UNSIGNEDP. 31795 However, some machines, have instructions that preferentially 31796 handle either signed or unsigned quantities of certain modes. For 31797 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 31798 instructions sign-extend the result to 64 bits. On such machines, 31799 set UNSIGNEDP according to which kind of extension is more 31800 efficient. 31801 31802 Do not define this macro if it would never modify M. 31803 31804 -- Target Hook: enum flt_eval_method TARGET_C_EXCESS_PRECISION (enum 31805 excess_precision_type TYPE) 31806 Return a value, with the same meaning as the C99 macro 31807 'FLT_EVAL_METHOD' that describes which excess precision should be 31808 applied. TYPE is either 'EXCESS_PRECISION_TYPE_IMPLICIT', 31809 'EXCESS_PRECISION_TYPE_FAST', or 'EXCESS_PRECISION_TYPE_STANDARD'. 31810 For 'EXCESS_PRECISION_TYPE_IMPLICIT', the target should return 31811 which precision and range operations will be implictly evaluated in 31812 regardless of the excess precision explicitly added. For 31813 'EXCESS_PRECISION_TYPE_STANDARD' and 'EXCESS_PRECISION_TYPE_FAST', 31814 the target should return the explicit excess precision that should 31815 be added depending on the value set for 31816 '-fexcess-precision=[standard|fast]'. Note that unpredictable 31817 explicit excess precision does not make sense, so a target should 31818 never return 'FLT_EVAL_METHOD_UNPREDICTABLE' when TYPE is 31819 'EXCESS_PRECISION_TYPE_STANDARD' or 'EXCESS_PRECISION_TYPE_FAST'. 31820 31821 -- Target Hook: machine_mode TARGET_PROMOTE_FUNCTION_MODE (const_tree 31822 TYPE, machine_mode MODE, int *PUNSIGNEDP, const_tree FUNTYPE, 31823 int FOR_RETURN) 31824 Like 'PROMOTE_MODE', but it is applied to outgoing function 31825 arguments or function return values. The target hook should return 31826 the new mode and possibly change '*PUNSIGNEDP' if the promotion 31827 should change signedness. This function is called only for scalar 31828 _or pointer_ types. 31829 31830 FOR_RETURN allows to distinguish the promotion of arguments and 31831 return values. If it is '1', a return value is being promoted and 31832 'TARGET_FUNCTION_VALUE' must perform the same promotions done here. 31833 If it is '2', the returned mode should be that of the register in 31834 which an incoming parameter is copied, or the outgoing result is 31835 computed; then the hook should return the same mode as 31836 'promote_mode', though the signedness may be different. 31837 31838 TYPE can be NULL when promoting function arguments of libcalls. 31839 31840 The default is to not promote arguments and return values. You can 31841 also define the hook to 31842 'default_promote_function_mode_always_promote' if you would like to 31843 apply the same rules given by 'PROMOTE_MODE'. 31844 31845 -- Macro: PARM_BOUNDARY 31846 Normal alignment required for function parameters on the stack, in 31847 bits. All stack parameters receive at least this much alignment 31848 regardless of data type. On most machines, this is the same as the 31849 size of an integer. 31850 31851 -- Macro: STACK_BOUNDARY 31852 Define this macro to the minimum alignment enforced by hardware for 31853 the stack pointer on this machine. The definition is a C 31854 expression for the desired alignment (measured in bits). This 31855 value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not 31856 defined. On most machines, this should be the same as 31857 'PARM_BOUNDARY'. 31858 31859 -- Macro: PREFERRED_STACK_BOUNDARY 31860 Define this macro if you wish to preserve a certain alignment for 31861 the stack pointer, greater than what the hardware enforces. The 31862 definition is a C expression for the desired alignment (measured in 31863 bits). This macro must evaluate to a value equal to or larger than 31864 'STACK_BOUNDARY'. 31865 31866 -- Macro: INCOMING_STACK_BOUNDARY 31867 Define this macro if the incoming stack boundary may be different 31868 from 'PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 31869 value equal to or larger than 'STACK_BOUNDARY'. 31870 31871 -- Macro: FUNCTION_BOUNDARY 31872 Alignment required for a function entry point, in bits. 31873 31874 -- Macro: BIGGEST_ALIGNMENT 31875 Biggest alignment that any data type can require on this machine, 31876 in bits. Note that this is not the biggest alignment that is 31877 supported, just the biggest alignment that, when violated, may 31878 cause a fault. 31879 31880 -- Target Hook: HOST_WIDE_INT TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 31881 If defined, this target hook specifies the absolute biggest 31882 alignment that a type or variable can have on this machine, 31883 otherwise, 'BIGGEST_ALIGNMENT' is used. 31884 31885 -- Macro: MALLOC_ABI_ALIGNMENT 31886 Alignment, in bits, a C conformant malloc implementation has to 31887 provide. If not defined, the default value is 'BITS_PER_WORD'. 31888 31889 -- Macro: ATTRIBUTE_ALIGNED_VALUE 31890 Alignment used by the '__attribute__ ((aligned))' construct. If 31891 not defined, the default value is 'BIGGEST_ALIGNMENT'. 31892 31893 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 31894 If defined, the smallest alignment, in bits, that can be given to 31895 an object that can be referenced in one operation, without 31896 disturbing any nearby object. Normally, this is 'BITS_PER_UNIT', 31897 but may be larger on machines that don't have byte or half-word 31898 store operations. 31899 31900 -- Macro: BIGGEST_FIELD_ALIGNMENT 31901 Biggest alignment that any structure or union field can require on 31902 this machine, in bits. If defined, this overrides 31903 'BIGGEST_ALIGNMENT' for structure and union fields only, unless the 31904 field alignment has been set by the '__attribute__ ((aligned (N)))' 31905 construct. 31906 31907 -- Macro: ADJUST_FIELD_ALIGN (FIELD, TYPE, COMPUTED) 31908 An expression for the alignment of a structure field FIELD of type 31909 TYPE if the alignment computed in the usual way (including applying 31910 of 'BIGGEST_ALIGNMENT' and 'BIGGEST_FIELD_ALIGNMENT' to the 31911 alignment) is COMPUTED. It overrides alignment only if the field 31912 alignment has not been set by the '__attribute__ ((aligned (N)))' 31913 construct. Note that FIELD may be 'NULL_TREE' in case we just 31914 query for the minimum alignment of a field of type TYPE in 31915 structure context. 31916 31917 -- Macro: MAX_STACK_ALIGNMENT 31918 Biggest stack alignment guaranteed by the backend. Use this macro 31919 to specify the maximum alignment of a variable on stack. 31920 31921 If not defined, the default value is 'STACK_BOUNDARY'. 31922 31923 -- Macro: MAX_OFILE_ALIGNMENT 31924 Biggest alignment supported by the object file format of this 31925 machine. Use this macro to limit the alignment which can be 31926 specified using the '__attribute__ ((aligned (N)))' construct for 31927 functions and objects with static storage duration. The alignment 31928 of automatic objects may exceed the object file format maximum up 31929 to the maximum supported by GCC. If not defined, the default value 31930 is 'BIGGEST_ALIGNMENT'. 31931 31932 On systems that use ELF, the default (in 'config/elfos.h') is the 31933 largest supported 32-bit ELF section alignment representable on a 31934 32-bit host e.g. '(((uint64_t) 1 << 28) * 8)'. On 32-bit ELF the 31935 largest supported section alignment in bits is '(0x80000000 * 8)', 31936 but this is not representable on 32-bit hosts. 31937 31938 -- Target Hook: HOST_WIDE_INT TARGET_STATIC_RTX_ALIGNMENT (machine_mode 31939 MODE) 31940 This hook returns the preferred alignment in bits for a 31941 statically-allocated rtx, such as a constant pool entry. MODE is 31942 the mode of the rtx. The default implementation returns 31943 'GET_MODE_ALIGNMENT (MODE)'. 31944 31945 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 31946 If defined, a C expression to compute the alignment for a variable 31947 in the static store. TYPE is the data type, and BASIC-ALIGN is the 31948 alignment that the object would ordinarily have. The value of this 31949 macro is used instead of that alignment to align the object. 31950 31951 If this macro is not defined, then BASIC-ALIGN is used. 31952 31953 One use of this macro is to increase alignment of medium-size data 31954 to make it all fit in fewer cache lines. Another is to cause 31955 character arrays to be word-aligned so that 'strcpy' calls that 31956 copy constants to character arrays can be done inline. 31957 31958 -- Macro: DATA_ABI_ALIGNMENT (TYPE, BASIC-ALIGN) 31959 Similar to 'DATA_ALIGNMENT', but for the cases where the ABI 31960 mandates some alignment increase, instead of optimization only 31961 purposes. E.g. AMD x86-64 psABI says that variables with array 31962 type larger than 15 bytes must be aligned to 16 byte boundaries. 31963 31964 If this macro is not defined, then BASIC-ALIGN is used. 31965 31966 -- Target Hook: HOST_WIDE_INT TARGET_CONSTANT_ALIGNMENT (const_tree 31967 CONSTANT, HOST_WIDE_INT BASIC_ALIGN) 31968 This hook returns the alignment in bits of a constant that is being 31969 placed in memory. CONSTANT is the constant and BASIC_ALIGN is the 31970 alignment that the object would ordinarily have. 31971 31972 The default definition just returns BASIC_ALIGN. 31973 31974 The typical use of this hook is to increase alignment for string 31975 constants to be word aligned so that 'strcpy' calls that copy 31976 constants can be done inline. The function 31977 'constant_alignment_word_strings' provides such a definition. 31978 31979 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 31980 If defined, a C expression to compute the alignment for a variable 31981 in the local store. TYPE is the data type, and BASIC-ALIGN is the 31982 alignment that the object would ordinarily have. The value of this 31983 macro is used instead of that alignment to align the object. 31984 31985 If this macro is not defined, then BASIC-ALIGN is used. 31986 31987 One use of this macro is to increase alignment of medium-size data 31988 to make it all fit in fewer cache lines. 31989 31990 If the value of this macro has a type, it should be an unsigned 31991 type. 31992 31993 -- Target Hook: HOST_WIDE_INT TARGET_VECTOR_ALIGNMENT (const_tree TYPE) 31994 This hook can be used to define the alignment for a vector of type 31995 TYPE, in order to comply with a platform ABI. The default is to 31996 require natural alignment for vector types. The alignment returned 31997 by this hook must be a power-of-two multiple of the default 31998 alignment of the vector element type. 31999 32000 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 32001 If defined, a C expression to compute the alignment for stack slot. 32002 TYPE is the data type, MODE is the widest mode available, and 32003 BASIC-ALIGN is the alignment that the slot would ordinarily have. 32004 The value of this macro is used instead of that alignment to align 32005 the slot. 32006 32007 If this macro is not defined, then BASIC-ALIGN is used when TYPE is 32008 'NULL'. Otherwise, 'LOCAL_ALIGNMENT' will be used. 32009 32010 This macro is to set alignment of stack slot to the maximum 32011 alignment of all possible modes which the slot may have. 32012 32013 If the value of this macro has a type, it should be an unsigned 32014 type. 32015 32016 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 32017 If defined, a C expression to compute the alignment for a local 32018 variable DECL. 32019 32020 If this macro is not defined, then 'LOCAL_ALIGNMENT (TREE_TYPE 32021 (DECL), DECL_ALIGN (DECL))' is used. 32022 32023 One use of this macro is to increase alignment of medium-size data 32024 to make it all fit in fewer cache lines. 32025 32026 If the value of this macro has a type, it should be an unsigned 32027 type. 32028 32029 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 32030 If defined, a C expression to compute the minimum required 32031 alignment for dynamic stack realignment purposes for EXP (a type or 32032 decl), MODE, assuming normal alignment ALIGN. 32033 32034 If this macro is not defined, then ALIGN will be used. 32035 32036 -- Macro: EMPTY_FIELD_BOUNDARY 32037 Alignment in bits to be given to a structure bit-field that follows 32038 an empty field such as 'int : 0;'. 32039 32040 If 'PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 32041 32042 -- Macro: STRUCTURE_SIZE_BOUNDARY 32043 Number of bits which any structure or union's size must be a 32044 multiple of. Each structure or union's size is rounded up to a 32045 multiple of this. 32046 32047 If you do not define this macro, the default is the same as 32048 'BITS_PER_UNIT'. 32049 32050 -- Macro: STRICT_ALIGNMENT 32051 Define this macro to be the value 1 if instructions will fail to 32052 work if given data not on the nominal alignment. If instructions 32053 will merely go slower in that case, define this macro as 0. 32054 32055 -- Macro: PCC_BITFIELD_TYPE_MATTERS 32056 Define this if you wish to imitate the way many other C compilers 32057 handle alignment of bit-fields and the structures that contain 32058 them. 32059 32060 The behavior is that the type written for a named bit-field ('int', 32061 'short', or other integer type) imposes an alignment for the entire 32062 structure, as if the structure really did contain an ordinary field 32063 of that type. In addition, the bit-field is placed within the 32064 structure so that it would fit within such a field, not crossing a 32065 boundary for it. 32066 32067 Thus, on most machines, a named bit-field whose type is written as 32068 'int' would not cross a four-byte boundary, and would force 32069 four-byte alignment for the whole structure. (The alignment used 32070 may not be four bytes; it is controlled by the other alignment 32071 parameters.) 32072 32073 An unnamed bit-field will not affect the alignment of the 32074 containing structure. 32075 32076 If the macro is defined, its definition should be a C expression; a 32077 nonzero value for the expression enables this behavior. 32078 32079 Note that if this macro is not defined, or its value is zero, some 32080 bit-fields may cross more than one alignment boundary. The 32081 compiler can support such references if there are 'insv', 'extv', 32082 and 'extzv' insns that can directly reference memory. 32083 32084 The other known way of making bit-fields work is to define 32085 'STRUCTURE_SIZE_BOUNDARY' as large as 'BIGGEST_ALIGNMENT'. Then 32086 every structure can be accessed with fullwords. 32087 32088 Unless the machine has bit-field instructions or you define 32089 'STRUCTURE_SIZE_BOUNDARY' that way, you must define 32090 'PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 32091 32092 If your aim is to make GCC use the same conventions for laying out 32093 bit-fields as are used by another compiler, here is how to 32094 investigate what the other compiler does. Compile and run this 32095 program: 32096 32097 struct foo1 32098 { 32099 char x; 32100 char :0; 32101 char y; 32102 }; 32103 32104 struct foo2 32105 { 32106 char x; 32107 int :0; 32108 char y; 32109 }; 32110 32111 main () 32112 { 32113 printf ("Size of foo1 is %d\n", 32114 sizeof (struct foo1)); 32115 printf ("Size of foo2 is %d\n", 32116 sizeof (struct foo2)); 32117 exit (0); 32118 } 32119 32120 If this prints 2 and 5, then the compiler's behavior is what you 32121 would get from 'PCC_BITFIELD_TYPE_MATTERS'. 32122 32123 -- Macro: BITFIELD_NBYTES_LIMITED 32124 Like 'PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 32125 to aligning a bit-field within the structure. 32126 32127 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 32128 When 'PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 32129 whether unnamed bitfields affect the alignment of the containing 32130 structure. The hook should return true if the structure should 32131 inherit the alignment requirements of an unnamed bitfield's type. 32132 32133 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 32134 This target hook should return 'true' if accesses to volatile 32135 bitfields should use the narrowest mode possible. It should return 32136 'false' if these accesses should use the bitfield container type. 32137 32138 The default is 'false'. 32139 32140 -- Target Hook: bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree FIELD, 32141 machine_mode MODE) 32142 Return true if a structure, union or array containing FIELD should 32143 be accessed using 'BLKMODE'. 32144 32145 If FIELD is the only field in the structure, MODE is its mode, 32146 otherwise MODE is VOIDmode. MODE is provided in the case where 32147 structures of one field would require the structure's mode to 32148 retain the field's mode. 32149 32150 Normally, this is not needed. 32151 32152 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 32153 Define this macro as an expression for the alignment of a type 32154 (given by TYPE as a tree node) if the alignment computed in the 32155 usual way is COMPUTED and the alignment explicitly specified was 32156 SPECIFIED. 32157 32158 The default is to use SPECIFIED if it is larger; otherwise, use the 32159 smaller of COMPUTED and 'BIGGEST_ALIGNMENT' 32160 32161 -- Macro: MAX_FIXED_MODE_SIZE 32162 An integer expression for the size in bits of the largest integer 32163 machine mode that should actually be used. All integer machine 32164 modes of this size or smaller can be used for structures and unions 32165 with the appropriate sizes. If this macro is undefined, 32166 'GET_MODE_BITSIZE (DImode)' is assumed. 32167 32168 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 32169 If defined, an expression of type 'machine_mode' that specifies the 32170 mode of the save area operand of a 'save_stack_LEVEL' named pattern 32171 (*note Standard Names::). SAVE_LEVEL is one of 'SAVE_BLOCK', 32172 'SAVE_FUNCTION', or 'SAVE_NONLOCAL' and selects which of the three 32173 named patterns is having its mode specified. 32174 32175 You need not define this macro if it always returns 'Pmode'. You 32176 would most commonly define this macro if the 'save_stack_LEVEL' 32177 patterns need to support both a 32- and a 64-bit mode. 32178 32179 -- Macro: STACK_SIZE_MODE 32180 If defined, an expression of type 'machine_mode' that specifies the 32181 mode of the size increment operand of an 'allocate_stack' named 32182 pattern (*note Standard Names::). 32183 32184 You need not define this macro if it always returns 'word_mode'. 32185 You would most commonly define this macro if the 'allocate_stack' 32186 pattern needs to support both a 32- and a 64-bit mode. 32187 32188 -- Target Hook: scalar_int_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 32189 This target hook should return the mode to be used for the return 32190 value of compare instructions expanded to libgcc calls. If not 32191 defined 'word_mode' is returned which is the right choice for a 32192 majority of targets. 32193 32194 -- Target Hook: scalar_int_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 32195 This target hook should return the mode to be used for the shift 32196 count operand of shift instructions expanded to libgcc calls. If 32197 not defined 'word_mode' is returned which is the right choice for a 32198 majority of targets. 32199 32200 -- Target Hook: scalar_int_mode TARGET_UNWIND_WORD_MODE (void) 32201 Return machine mode to be used for '_Unwind_Word' type. The 32202 default is to use 'word_mode'. 32203 32204 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 32205 RECORD_TYPE) 32206 This target hook returns 'true' if bit-fields in the given 32207 RECORD_TYPE are to be laid out following the rules of Microsoft 32208 Visual C/C++, namely: (i) a bit-field won't share the same storage 32209 unit with the previous bit-field if their underlying types have 32210 different sizes, and the bit-field will be aligned to the highest 32211 alignment of the underlying types of itself and of the previous 32212 bit-field; (ii) a zero-sized bit-field will affect the alignment of 32213 the whole enclosing structure, even if it is unnamed; except that 32214 (iii) a zero-sized bit-field will be disregarded unless it follows 32215 another bit-field of nonzero size. If this hook returns 'true', 32216 other macros that control bit-field layout are ignored. 32217 32218 When a bit-field is inserted into a packed record, the whole size 32219 of the underlying type is used by one or more same-size adjacent 32220 bit-fields (that is, if its long:3, 32 bits is used in the record, 32221 and any additional adjacent long bit-fields are packed into the 32222 same chunk of 32 bits. However, if the size changes, a new field 32223 of that size is allocated). In an unpacked record, this is the 32224 same as using alignment, but not equivalent when packing. 32225 32226 If both MS bit-fields and '__attribute__((packed))' are used, the 32227 latter will take precedence. If '__attribute__((packed))' is used 32228 on a single field when MS bit-fields are in use, it will take 32229 precedence for that field, but the alignment of the rest of the 32230 structure may affect its placement. 32231 32232 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 32233 Returns true if the target supports decimal floating point. 32234 32235 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 32236 Returns true if the target supports fixed-point arithmetic. 32237 32238 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 32239 This hook is called just before expansion into rtl, allowing the 32240 target to perform additional initializations or analysis before the 32241 expansion. For example, the rs6000 port uses it to allocate a 32242 scratch stack slot for use in copying SDmode values between memory 32243 and floating point registers whenever the function being expanded 32244 has any SDmode usage. 32245 32246 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 32247 This hook allows the backend to perform additional instantiations 32248 on rtl that are not actually in any insns yet, but will be later. 32249 32250 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 32251 If your target defines any fundamental types, or any types your 32252 target uses should be mangled differently from the default, define 32253 this hook to return the appropriate encoding for these types as 32254 part of a C++ mangled name. The TYPE argument is the tree 32255 structure representing the type to be mangled. The hook may be 32256 applied to trees which are not target-specific fundamental types; 32257 it should return 'NULL' for all such types, as well as arguments it 32258 does not recognize. If the return value is not 'NULL', it must 32259 point to a statically-allocated string constant. 32260 32261 Target-specific fundamental types might be new fundamental types or 32262 qualified versions of ordinary fundamental types. Encode new 32263 fundamental types as 'u N NAME', where NAME is the name used for 32264 the type in source code, and N is the length of NAME in decimal. 32265 Encode qualified versions of ordinary types as 'U N NAME CODE', 32266 where NAME is the name used for the type qualifier in source code, 32267 N is the length of NAME as above, and CODE is the code used to 32268 represent the unqualified version of this type. (See 32269 'write_builtin_type' in 'cp/mangle.c' for the list of codes.) In 32270 both cases the spaces are for clarity; do not include any spaces in 32271 your string. 32272 32273 This hook is applied to types prior to typedef resolution. If the 32274 mangled name for a particular type depends only on that type's main 32275 variant, you can perform typedef resolution yourself using 32276 'TYPE_MAIN_VARIANT' before mangling. 32277 32278 The default version of this hook always returns 'NULL', which is 32279 appropriate for a target that does not define any new fundamental 32280 types. 32281 32282 32283File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 32284 3228518.6 Layout of Source Language Data Types 32286========================================= 32287 32288These macros define the sizes and other characteristics of the standard 32289basic data types used in programs being compiled. Unlike the macros in 32290the previous section, these apply to specific features of C and related 32291languages, rather than to fundamental aspects of storage layout. 32292 32293 -- Macro: INT_TYPE_SIZE 32294 A C expression for the size in bits of the type 'int' on the target 32295 machine. If you don't define this, the default is one word. 32296 32297 -- Macro: SHORT_TYPE_SIZE 32298 A C expression for the size in bits of the type 'short' on the 32299 target machine. If you don't define this, the default is half a 32300 word. (If this would be less than one storage unit, it is rounded 32301 up to one unit.) 32302 32303 -- Macro: LONG_TYPE_SIZE 32304 A C expression for the size in bits of the type 'long' on the 32305 target machine. If you don't define this, the default is one word. 32306 32307 -- Macro: ADA_LONG_TYPE_SIZE 32308 On some machines, the size used for the Ada equivalent of the type 32309 'long' by a native Ada compiler differs from that used by C. In 32310 that situation, define this macro to be a C expression to be used 32311 for the size of that type. If you don't define this, the default 32312 is the value of 'LONG_TYPE_SIZE'. 32313 32314 -- Macro: LONG_LONG_TYPE_SIZE 32315 A C expression for the size in bits of the type 'long long' on the 32316 target machine. If you don't define this, the default is two 32317 words. If you want to support GNU Ada on your machine, the value 32318 of this macro must be at least 64. 32319 32320 -- Macro: CHAR_TYPE_SIZE 32321 A C expression for the size in bits of the type 'char' on the 32322 target machine. If you don't define this, the default is 32323 'BITS_PER_UNIT'. 32324 32325 -- Macro: BOOL_TYPE_SIZE 32326 A C expression for the size in bits of the C++ type 'bool' and C99 32327 type '_Bool' on the target machine. If you don't define this, and 32328 you probably shouldn't, the default is 'CHAR_TYPE_SIZE'. 32329 32330 -- Macro: FLOAT_TYPE_SIZE 32331 A C expression for the size in bits of the type 'float' on the 32332 target machine. If you don't define this, the default is one word. 32333 32334 -- Macro: DOUBLE_TYPE_SIZE 32335 A C expression for the size in bits of the type 'double' on the 32336 target machine. If you don't define this, the default is two 32337 words. 32338 32339 -- Macro: LONG_DOUBLE_TYPE_SIZE 32340 A C expression for the size in bits of the type 'long double' on 32341 the target machine. If you don't define this, the default is two 32342 words. 32343 32344 -- Macro: SHORT_FRACT_TYPE_SIZE 32345 A C expression for the size in bits of the type 'short _Fract' on 32346 the target machine. If you don't define this, the default is 32347 'BITS_PER_UNIT'. 32348 32349 -- Macro: FRACT_TYPE_SIZE 32350 A C expression for the size in bits of the type '_Fract' on the 32351 target machine. If you don't define this, the default is 32352 'BITS_PER_UNIT * 2'. 32353 32354 -- Macro: LONG_FRACT_TYPE_SIZE 32355 A C expression for the size in bits of the type 'long _Fract' on 32356 the target machine. If you don't define this, the default is 32357 'BITS_PER_UNIT * 4'. 32358 32359 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 32360 A C expression for the size in bits of the type 'long long _Fract' 32361 on the target machine. If you don't define this, the default is 32362 'BITS_PER_UNIT * 8'. 32363 32364 -- Macro: SHORT_ACCUM_TYPE_SIZE 32365 A C expression for the size in bits of the type 'short _Accum' on 32366 the target machine. If you don't define this, the default is 32367 'BITS_PER_UNIT * 2'. 32368 32369 -- Macro: ACCUM_TYPE_SIZE 32370 A C expression for the size in bits of the type '_Accum' on the 32371 target machine. If you don't define this, the default is 32372 'BITS_PER_UNIT * 4'. 32373 32374 -- Macro: LONG_ACCUM_TYPE_SIZE 32375 A C expression for the size in bits of the type 'long _Accum' on 32376 the target machine. If you don't define this, the default is 32377 'BITS_PER_UNIT * 8'. 32378 32379 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 32380 A C expression for the size in bits of the type 'long long _Accum' 32381 on the target machine. If you don't define this, the default is 32382 'BITS_PER_UNIT * 16'. 32383 32384 -- Macro: LIBGCC2_GNU_PREFIX 32385 This macro corresponds to the 'TARGET_LIBFUNC_GNU_PREFIX' target 32386 hook and should be defined if that hook is overriden to be true. 32387 It causes function names in libgcc to be changed to use a '__gnu_' 32388 prefix for their name rather than the default '__'. A port which 32389 uses this macro should also arrange to use 't-gnu-prefix' in the 32390 libgcc 'config.host'. 32391 32392 -- Macro: WIDEST_HARDWARE_FP_SIZE 32393 A C expression for the size in bits of the widest floating-point 32394 format supported by the hardware. If you define this macro, you 32395 must specify a value less than or equal to the value of 32396 'LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 32397 value of 'LONG_DOUBLE_TYPE_SIZE' is the default. 32398 32399 -- Macro: DEFAULT_SIGNED_CHAR 32400 An expression whose value is 1 or 0, according to whether the type 32401 'char' should be signed or unsigned by default. The user can 32402 always override this default with the options '-fsigned-char' and 32403 '-funsigned-char'. 32404 32405 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 32406 This target hook should return true if the compiler should give an 32407 'enum' type only as many bytes as it takes to represent the range 32408 of possible values of that type. It should return false if all 32409 'enum' types should be allocated like 'int'. 32410 32411 The default is to return false. 32412 32413 -- Macro: SIZE_TYPE 32414 A C expression for a string describing the name of the data type to 32415 use for size values. The typedef name 'size_t' is defined using 32416 the contents of the string. 32417 32418 The string can contain more than one keyword. If so, separate them 32419 with spaces, and write first any length keyword, then 'unsigned' if 32420 appropriate, and finally 'int'. The string must exactly match one 32421 of the data type names defined in the function 32422 'c_common_nodes_and_builtins' in the file 'c-family/c-common.c'. 32423 You may not omit 'int' or change the order--that would cause the 32424 compiler to crash on startup. 32425 32426 If you don't define this macro, the default is '"long unsigned 32427 int"'. 32428 32429 -- Macro: SIZETYPE 32430 GCC defines internal types ('sizetype', 'ssizetype', 'bitsizetype' 32431 and 'sbitsizetype') for expressions dealing with size. This macro 32432 is a C expression for a string describing the name of the data type 32433 from which the precision of 'sizetype' is extracted. 32434 32435 The string has the same restrictions as 'SIZE_TYPE' string. 32436 32437 If you don't define this macro, the default is 'SIZE_TYPE'. 32438 32439 -- Macro: PTRDIFF_TYPE 32440 A C expression for a string describing the name of the data type to 32441 use for the result of subtracting two pointers. The typedef name 32442 'ptrdiff_t' is defined using the contents of the string. See 32443 'SIZE_TYPE' above for more information. 32444 32445 If you don't define this macro, the default is '"long int"'. 32446 32447 -- Macro: WCHAR_TYPE 32448 A C expression for a string describing the name of the data type to 32449 use for wide characters. The typedef name 'wchar_t' is defined 32450 using the contents of the string. See 'SIZE_TYPE' above for more 32451 information. 32452 32453 If you don't define this macro, the default is '"int"'. 32454 32455 -- Macro: WCHAR_TYPE_SIZE 32456 A C expression for the size in bits of the data type for wide 32457 characters. This is used in 'cpp', which cannot make use of 32458 'WCHAR_TYPE'. 32459 32460 -- Macro: WINT_TYPE 32461 A C expression for a string describing the name of the data type to 32462 use for wide characters passed to 'printf' and returned from 32463 'getwc'. The typedef name 'wint_t' is defined using the contents 32464 of the string. See 'SIZE_TYPE' above for more information. 32465 32466 If you don't define this macro, the default is '"unsigned int"'. 32467 32468 -- Macro: INTMAX_TYPE 32469 A C expression for a string describing the name of the data type 32470 that can represent any value of any standard or extended signed 32471 integer type. The typedef name 'intmax_t' is defined using the 32472 contents of the string. See 'SIZE_TYPE' above for more 32473 information. 32474 32475 If you don't define this macro, the default is the first of 32476 '"int"', '"long int"', or '"long long int"' that has as much 32477 precision as 'long long int'. 32478 32479 -- Macro: UINTMAX_TYPE 32480 A C expression for a string describing the name of the data type 32481 that can represent any value of any standard or extended unsigned 32482 integer type. The typedef name 'uintmax_t' is defined using the 32483 contents of the string. See 'SIZE_TYPE' above for more 32484 information. 32485 32486 If you don't define this macro, the default is the first of 32487 '"unsigned int"', '"long unsigned int"', or '"long long unsigned 32488 int"' that has as much precision as 'long long unsigned int'. 32489 32490 -- Macro: SIG_ATOMIC_TYPE 32491 -- Macro: INT8_TYPE 32492 -- Macro: INT16_TYPE 32493 -- Macro: INT32_TYPE 32494 -- Macro: INT64_TYPE 32495 -- Macro: UINT8_TYPE 32496 -- Macro: UINT16_TYPE 32497 -- Macro: UINT32_TYPE 32498 -- Macro: UINT64_TYPE 32499 -- Macro: INT_LEAST8_TYPE 32500 -- Macro: INT_LEAST16_TYPE 32501 -- Macro: INT_LEAST32_TYPE 32502 -- Macro: INT_LEAST64_TYPE 32503 -- Macro: UINT_LEAST8_TYPE 32504 -- Macro: UINT_LEAST16_TYPE 32505 -- Macro: UINT_LEAST32_TYPE 32506 -- Macro: UINT_LEAST64_TYPE 32507 -- Macro: INT_FAST8_TYPE 32508 -- Macro: INT_FAST16_TYPE 32509 -- Macro: INT_FAST32_TYPE 32510 -- Macro: INT_FAST64_TYPE 32511 -- Macro: UINT_FAST8_TYPE 32512 -- Macro: UINT_FAST16_TYPE 32513 -- Macro: UINT_FAST32_TYPE 32514 -- Macro: UINT_FAST64_TYPE 32515 -- Macro: INTPTR_TYPE 32516 -- Macro: UINTPTR_TYPE 32517 C expressions for the standard types 'sig_atomic_t', 'int8_t', 32518 'int16_t', 'int32_t', 'int64_t', 'uint8_t', 'uint16_t', 'uint32_t', 32519 'uint64_t', 'int_least8_t', 'int_least16_t', 'int_least32_t', 32520 'int_least64_t', 'uint_least8_t', 'uint_least16_t', 32521 'uint_least32_t', 'uint_least64_t', 'int_fast8_t', 'int_fast16_t', 32522 'int_fast32_t', 'int_fast64_t', 'uint_fast8_t', 'uint_fast16_t', 32523 'uint_fast32_t', 'uint_fast64_t', 'intptr_t', and 'uintptr_t'. See 32524 'SIZE_TYPE' above for more information. 32525 32526 If any of these macros evaluates to a null pointer, the 32527 corresponding type is not supported; if GCC is configured to 32528 provide '<stdint.h>' in such a case, the header provided may not 32529 conform to C99, depending on the type in question. The defaults 32530 for all of these macros are null pointers. 32531 32532 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 32533 The C++ compiler represents a pointer-to-member-function with a 32534 struct that looks like: 32535 32536 struct { 32537 union { 32538 void (*fn)(); 32539 ptrdiff_t vtable_index; 32540 }; 32541 ptrdiff_t delta; 32542 }; 32543 32544 The C++ compiler must use one bit to indicate whether the function 32545 that will be called through a pointer-to-member-function is 32546 virtual. Normally, we assume that the low-order bit of a function 32547 pointer must always be zero. Then, by ensuring that the 32548 vtable_index is odd, we can distinguish which variant of the union 32549 is in use. But, on some platforms function pointers can be odd, 32550 and so this doesn't work. In that case, we use the low-order bit 32551 of the 'delta' field, and shift the remainder of the 'delta' field 32552 to the left. 32553 32554 GCC will automatically make the right selection about where to 32555 store this bit using the 'FUNCTION_BOUNDARY' setting for your 32556 platform. However, some platforms such as ARM/Thumb have 32557 'FUNCTION_BOUNDARY' set such that functions always start at even 32558 addresses, but the lowest bit of pointers to functions indicate 32559 whether the function at that address is in ARM or Thumb mode. If 32560 this is the case of your architecture, you should define this macro 32561 to 'ptrmemfunc_vbit_in_delta'. 32562 32563 In general, you should not have to define this macro. On 32564 architectures in which function addresses are always even, 32565 according to 'FUNCTION_BOUNDARY', GCC will automatically define 32566 this macro to 'ptrmemfunc_vbit_in_pfn'. 32567 32568 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 32569 Normally, the C++ compiler uses function pointers in vtables. This 32570 macro allows the target to change to use "function descriptors" 32571 instead. Function descriptors are found on targets for whom a 32572 function pointer is actually a small data structure. Normally the 32573 data structure consists of the actual code address plus a data 32574 pointer to which the function's data is relative. 32575 32576 If vtables are used, the value of this macro should be the number 32577 of words that the function descriptor occupies. 32578 32579 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 32580 By default, the vtable entries are void pointers, the so the 32581 alignment is the same as pointer alignment. The value of this 32582 macro specifies the alignment of the vtable entry in bits. It 32583 should be defined only when special alignment is necessary. */ 32584 32585 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 32586 There are a few non-descriptor entries in the vtable at offsets 32587 below zero. If these entries must be padded (say, to preserve the 32588 alignment specified by 'TARGET_VTABLE_ENTRY_ALIGN'), set this to 32589 the number of words in each data entry. 32590 32591 32592File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 32593 3259418.7 Register Usage 32595=================== 32596 32597This section explains how to describe what registers the target machine 32598has, and how (in general) they can be used. 32599 32600 The description of which registers a specific instruction can use is 32601done with register classes; see *note Register Classes::. For 32602information on using registers to access a stack frame, see *note Frame 32603Registers::. For passing values in registers, see *note Register 32604Arguments::. For returning values in registers, see *note Scalar 32605Return::. 32606 32607* Menu: 32608 32609* Register Basics:: Number and kinds of registers. 32610* Allocation Order:: Order in which registers are allocated. 32611* Values in Registers:: What kinds of values each reg can hold. 32612* Leaf Functions:: Renumbering registers for leaf functions. 32613* Stack Registers:: Handling a register stack such as 80387. 32614 32615 32616File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 32617 3261818.7.1 Basic Characteristics of Registers 32619----------------------------------------- 32620 32621Registers have various characteristics. 32622 32623 -- Macro: FIRST_PSEUDO_REGISTER 32624 Number of hardware registers known to the compiler. They receive 32625 numbers 0 through 'FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo 32626 register's number really is assigned the number 32627 'FIRST_PSEUDO_REGISTER'. 32628 32629 -- Macro: FIXED_REGISTERS 32630 An initializer that says which registers are used for fixed 32631 purposes all throughout the compiled code and are therefore not 32632 available for general allocation. These would include the stack 32633 pointer, the frame pointer (except on machines where that can be 32634 used as a general register when no frame pointer is needed), the 32635 program counter on machines where that is considered one of the 32636 addressable registers, and any other numbered register with a 32637 standard use. 32638 32639 This information is expressed as a sequence of numbers, separated 32640 by commas and surrounded by braces. The Nth number is 1 if 32641 register N is fixed, 0 otherwise. 32642 32643 The table initialized from this macro, and the table initialized by 32644 the following one, may be overridden at run time either 32645 automatically, by the actions of the macro 32646 'CONDITIONAL_REGISTER_USAGE', or by the user with the command 32647 options '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG'. 32648 32649 -- Macro: CALL_USED_REGISTERS 32650 Like 'FIXED_REGISTERS' but has 1 for each register that is 32651 clobbered (in general) by function calls as well as for fixed 32652 registers. This macro therefore identifies the registers that are 32653 not available for general allocation of values that must live 32654 across function calls. 32655 32656 If a register has 0 in 'CALL_USED_REGISTERS', the compiler 32657 automatically saves it on function entry and restores it on 32658 function exit, if the register is used within the function. 32659 32660 Exactly one of 'CALL_USED_REGISTERS' and 32661 'CALL_REALLY_USED_REGISTERS' must be defined. Modern ports should 32662 define 'CALL_REALLY_USED_REGISTERS'. 32663 32664 -- Macro: CALL_REALLY_USED_REGISTERS 32665 Like 'CALL_USED_REGISTERS' except this macro doesn't require that 32666 the entire set of 'FIXED_REGISTERS' be included. 32667 ('CALL_USED_REGISTERS' must be a superset of 'FIXED_REGISTERS'). 32668 32669 Exactly one of 'CALL_USED_REGISTERS' and 32670 'CALL_REALLY_USED_REGISTERS' must be defined. Modern ports should 32671 define 'CALL_REALLY_USED_REGISTERS'. 32672 32673 -- Target Hook: const predefined_function_abi & TARGET_FNTYPE_ABI 32674 (const_tree TYPE) 32675 Return the ABI used by a function with type TYPE; see the 32676 definition of 'predefined_function_abi' for details of the ABI 32677 descriptor. Targets only need to define this hook if they support 32678 interoperability between several ABIs in the same translation unit. 32679 32680 -- Target Hook: const predefined_function_abi & TARGET_INSN_CALLEE_ABI 32681 (const rtx_insn *INSN) 32682 This hook returns a description of the ABI used by the target of 32683 call instruction INSN; see the definition of 32684 'predefined_function_abi' for details of the ABI descriptor. Only 32685 the global function 'insn_callee_abi' should call this hook 32686 directly. 32687 32688 Targets only need to define this hook if they support 32689 interoperability between several ABIs in the same translation unit. 32690 32691 -- Target Hook: bool TARGET_HARD_REGNO_CALL_PART_CLOBBERED (unsigned 32692 int ABI_ID, unsigned int REGNO, machine_mode MODE) 32693 ABIs usually specify that calls must preserve the full contents of 32694 a particular register, or that calls can alter any part of a 32695 particular register. This information is captured by the target 32696 macro 'CALL_REALLY_USED_REGISTERS'. However, some ABIs specify 32697 that calls must preserve certain bits of a particular register but 32698 can alter others. This hook should return true if this applies to 32699 at least one of the registers in '(reg:MODE REGNO)', and if as a 32700 result the call would alter part of the MODE value. For example, 32701 if a call preserves the low 32 bits of a 64-bit hard register REGNO 32702 but can clobber the upper 32 bits, this hook should return true for 32703 a 64-bit mode but false for a 32-bit mode. 32704 32705 The value of ABI_ID comes from the 'predefined_function_abi' 32706 structure that describes the ABI of the call; see the definition of 32707 the structure for more details. If (as is usual) the target uses 32708 the same ABI for all functions in a translation unit, ABI_ID is 32709 always 0. 32710 32711 The default implementation returns false, which is correct for 32712 targets that don't have partly call-clobbered registers. 32713 32714 -- Target Hook: const char * TARGET_GET_MULTILIB_ABI_NAME (void) 32715 This hook returns name of multilib ABI name. 32716 32717 -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void) 32718 This hook may conditionally modify five variables 'fixed_regs', 32719 'call_used_regs', 'global_regs', 'reg_names', and 32720 'reg_class_contents', to take into account any dependence of these 32721 register sets on target flags. The first three of these are of 32722 type 'char []' (interpreted as boolean vectors). 'global_regs' is 32723 a 'const char *[]', and 'reg_class_contents' is a 'HARD_REG_SET'. 32724 Before the macro is called, 'fixed_regs', 'call_used_regs', 32725 'reg_class_contents', and 'reg_names' have been initialized from 32726 'FIXED_REGISTERS', 'CALL_USED_REGISTERS', 'REG_CLASS_CONTENTS', and 32727 'REGISTER_NAMES', respectively. 'global_regs' has been cleared, 32728 and any '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG' 32729 command options have been applied. 32730 32731 If the usage of an entire class of registers depends on the target 32732 flags, you may indicate this to GCC by using this macro to modify 32733 'fixed_regs' and 'call_used_regs' to 1 for each of the registers in 32734 the classes which should not be used by GCC. Also make 32735 'define_register_constraint's return 'NO_REGS' for constraints that 32736 shouldn't be used. 32737 32738 (However, if this class is not included in 'GENERAL_REGS' and all 32739 of the insn patterns whose constraints permit this class are 32740 controlled by target switches, then GCC will automatically avoid 32741 using these registers when the target switches are opposed to 32742 them.) 32743 32744 -- Macro: INCOMING_REGNO (OUT) 32745 Define this macro if the target machine has register windows. This 32746 C expression returns the register number as seen by the called 32747 function corresponding to the register number OUT as seen by the 32748 calling function. Return OUT if register number OUT is not an 32749 outbound register. 32750 32751 -- Macro: OUTGOING_REGNO (IN) 32752 Define this macro if the target machine has register windows. This 32753 C expression returns the register number as seen by the calling 32754 function corresponding to the register number IN as seen by the 32755 called function. Return IN if register number IN is not an inbound 32756 register. 32757 32758 -- Macro: LOCAL_REGNO (REGNO) 32759 Define this macro if the target machine has register windows. This 32760 C expression returns true if the register is call-saved but is in 32761 the register window. Unlike most call-saved registers, such 32762 registers need not be explicitly restored on function exit or 32763 during non-local gotos. 32764 32765 -- Macro: PC_REGNUM 32766 If the program counter has a register number, define this as that 32767 register number. Otherwise, do not define it. 32768 32769 32770File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 32771 3277218.7.2 Order of Allocation of Registers 32773--------------------------------------- 32774 32775Registers are allocated in order. 32776 32777 -- Macro: REG_ALLOC_ORDER 32778 If defined, an initializer for a vector of integers, containing the 32779 numbers of hard registers in the order in which GCC should prefer 32780 to use them (from most preferred to least). 32781 32782 If this macro is not defined, registers are used lowest numbered 32783 first (all else being equal). 32784 32785 One use of this macro is on machines where the highest numbered 32786 registers must always be saved and the save-multiple-registers 32787 instruction supports only sequences of consecutive registers. On 32788 such machines, define 'REG_ALLOC_ORDER' to be an initializer that 32789 lists the highest numbered allocable register first. 32790 32791 -- Macro: ADJUST_REG_ALLOC_ORDER 32792 A C statement (sans semicolon) to choose the order in which to 32793 allocate hard registers for pseudo-registers local to a basic 32794 block. 32795 32796 Store the desired register order in the array 'reg_alloc_order'. 32797 Element 0 should be the register to allocate first; element 1, the 32798 next register; and so on. 32799 32800 The macro body should not assume anything about the contents of 32801 'reg_alloc_order' before execution of the macro. 32802 32803 On most machines, it is not necessary to define this macro. 32804 32805 -- Macro: HONOR_REG_ALLOC_ORDER 32806 Normally, IRA tries to estimate the costs for saving a register in 32807 the prologue and restoring it in the epilogue. This discourages it 32808 from using call-saved registers. If a machine wants to ensure that 32809 IRA allocates registers in the order given by REG_ALLOC_ORDER even 32810 if some call-saved registers appear earlier than call-used ones, 32811 then define this macro as a C expression to nonzero. Default is 0. 32812 32813 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 32814 In some case register allocation order is not enough for the 32815 Integrated Register Allocator (IRA) to generate a good code. If 32816 this macro is defined, it should return a floating point value 32817 based on REGNO. The cost of using REGNO for a pseudo will be 32818 increased by approximately the pseudo's usage frequency times the 32819 value returned by this macro. Not defining this macro is 32820 equivalent to having it always return '0.0'. 32821 32822 On most machines, it is not necessary to define this macro. 32823 32824 32825File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 32826 3282718.7.3 How Values Fit in Registers 32828---------------------------------- 32829 32830This section discusses the macros that describe which kinds of values 32831(specifically, which machine modes) each register can hold, and how many 32832consecutive registers are needed for a given mode. 32833 32834 -- Target Hook: unsigned int TARGET_HARD_REGNO_NREGS (unsigned int 32835 REGNO, machine_mode MODE) 32836 This hook returns the number of consecutive hard registers, 32837 starting at register number REGNO, required to hold a value of mode 32838 MODE. This hook must never return zero, even if a register cannot 32839 hold the requested mode - indicate that with 32840 'TARGET_HARD_REGNO_MODE_OK' and/or 'TARGET_CAN_CHANGE_MODE_CLASS' 32841 instead. 32842 32843 The default definition returns the number of words in MODE. 32844 32845 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 32846 A C expression that is nonzero if a value of mode MODE, stored in 32847 memory, ends with padding that causes it to take up more space than 32848 in registers starting at register number REGNO (as determined by 32849 multiplying GCC's notion of the size of the register when 32850 containing this mode by the number of registers returned by 32851 'TARGET_HARD_REGNO_NREGS'). By default this is zero. 32852 32853 For example, if a floating-point value is stored in three 32-bit 32854 registers but takes up 128 bits in memory, then this would be 32855 nonzero. 32856 32857 This macros only needs to be defined if there are cases where 32858 'subreg_get_info' would otherwise wrongly determine that a 'subreg' 32859 can be represented by an offset to the register number, when in 32860 fact such a 'subreg' would contain some of the padding not stored 32861 in registers and so not be representable. 32862 32863 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 32864 For values of REGNO and MODE for which 32865 'HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 32866 returning the greater number of registers required to hold the 32867 value including any padding. In the example above, the value would 32868 be four. 32869 32870 -- Macro: REGMODE_NATURAL_SIZE (MODE) 32871 Define this macro if the natural size of registers that hold values 32872 of mode MODE is not the word size. It is a C expression that 32873 should give the natural size in bytes for the specified mode. It 32874 is used by the register allocator to try to optimize its results. 32875 This happens for example on SPARC 64-bit where the natural size of 32876 floating-point registers is still 32-bit. 32877 32878 -- Target Hook: bool TARGET_HARD_REGNO_MODE_OK (unsigned int REGNO, 32879 machine_mode MODE) 32880 This hook returns true if it is permissible to store a value of 32881 mode MODE in hard register number REGNO (or in several registers 32882 starting with that one). The default definition returns true 32883 unconditionally. 32884 32885 You need not include code to check for the numbers of fixed 32886 registers, because the allocation mechanism considers them to be 32887 always occupied. 32888 32889 On some machines, double-precision values must be kept in even/odd 32890 register pairs. You can implement that by defining this hook to 32891 reject odd register numbers for such modes. 32892 32893 The minimum requirement for a mode to be OK in a register is that 32894 the 'movMODE' instruction pattern support moves between the 32895 register and other hard register in the same class and that moving 32896 a value into the register and back out not alter it. 32897 32898 Since the same instruction used to move 'word_mode' will work for 32899 all narrower integer modes, it is not necessary on any machine for 32900 this hook to distinguish between these modes, provided you define 32901 patterns 'movhi', etc., to take advantage of this. This is useful 32902 because of the interaction between 'TARGET_HARD_REGNO_MODE_OK' and 32903 'TARGET_MODES_TIEABLE_P'; it is very desirable for all integer 32904 modes to be tieable. 32905 32906 Many machines have special registers for floating point arithmetic. 32907 Often people assume that floating point machine modes are allowed 32908 only in floating point registers. This is not true. Any registers 32909 that can hold integers can safely _hold_ a floating point machine 32910 mode, whether or not floating arithmetic can be done on it in those 32911 registers. Integer move instructions can be used to move the 32912 values. 32913 32914 On some machines, though, the converse is true: fixed-point machine 32915 modes may not go in floating registers. This is true if the 32916 floating registers normalize any value stored in them, because 32917 storing a non-floating value there would garble it. In this case, 32918 'TARGET_HARD_REGNO_MODE_OK' should reject fixed-point machine modes 32919 in floating registers. But if the floating registers do not 32920 automatically normalize, if you can store any bit pattern in one 32921 and retrieve it unchanged without a trap, then any machine mode may 32922 go in a floating register, so you can define this hook to say so. 32923 32924 The primary significance of special floating registers is rather 32925 that they are the registers acceptable in floating point arithmetic 32926 instructions. However, this is of no concern to 32927 'TARGET_HARD_REGNO_MODE_OK'. You handle it by writing the proper 32928 constraints for those instructions. 32929 32930 On some machines, the floating registers are especially slow to 32931 access, so that it is better to store a value in a stack frame than 32932 in such a register if floating point arithmetic is not being done. 32933 As long as the floating registers are not in class 'GENERAL_REGS', 32934 they will not be used unless some pattern's constraint asks for 32935 one. 32936 32937 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 32938 A C expression that is nonzero if it is OK to rename a hard 32939 register FROM to another hard register TO. 32940 32941 One common use of this macro is to prevent renaming of a register 32942 to another register that is not saved by a prologue in an interrupt 32943 handler. 32944 32945 The default is always nonzero. 32946 32947 -- Target Hook: bool TARGET_MODES_TIEABLE_P (machine_mode MODE1, 32948 machine_mode MODE2) 32949 This hook returns true if a value of mode MODE1 is accessible in 32950 mode MODE2 without copying. 32951 32952 If 'TARGET_HARD_REGNO_MODE_OK (R, MODE1)' and 32953 'TARGET_HARD_REGNO_MODE_OK (R, MODE2)' are always the same for any 32954 R, then 'TARGET_MODES_TIEABLE_P (MODE1, MODE2)' should be true. If 32955 they differ for any R, you should define this hook to return false 32956 unless some other mechanism ensures the accessibility of the value 32957 in a narrower mode. 32958 32959 You should define this hook to return true in as many cases as 32960 possible since doing so will allow GCC to perform better register 32961 allocation. The default definition returns true unconditionally. 32962 32963 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 32964 This target hook should return 'true' if it is OK to use a hard 32965 register REGNO as scratch reg in peephole2. 32966 32967 One common use of this macro is to prevent using of a register that 32968 is not saved by a prologue in an interrupt handler. 32969 32970 The default version of this hook always returns 'true'. 32971 32972 -- Macro: AVOID_CCMODE_COPIES 32973 Define this macro if the compiler should avoid copies to/from 32974 'CCmode' registers. You should only define this macro if support 32975 for copying to/from 'CCmode' is incomplete. 32976 32977 32978File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 32979 3298018.7.4 Handling Leaf Functions 32981------------------------------ 32982 32983On some machines, a leaf function (i.e., one which makes no calls) can 32984run more efficiently if it does not make its own register window. Often 32985this means it is required to receive its arguments in the registers 32986where they are passed by the caller, instead of the registers where they 32987would normally arrive. 32988 32989 The special treatment for leaf functions generally applies only when 32990other conditions are met; for example, often they may use only those 32991registers for its own variables and temporaries. We use the term "leaf 32992function" to mean a function that is suitable for this special handling, 32993so that functions with no calls are not necessarily "leaf functions". 32994 32995 GCC assigns register numbers before it knows whether the function is 32996suitable for leaf function treatment. So it needs to renumber the 32997registers in order to output a leaf function. The following macros 32998accomplish this. 32999 33000 -- Macro: LEAF_REGISTERS 33001 Name of a char vector, indexed by hard register number, which 33002 contains 1 for a register that is allowable in a candidate for leaf 33003 function treatment. 33004 33005 If leaf function treatment involves renumbering the registers, then 33006 the registers marked here should be the ones before 33007 renumbering--those that GCC would ordinarily allocate. The 33008 registers which will actually be used in the assembler code, after 33009 renumbering, should not be marked with 1 in this vector. 33010 33011 Define this macro only if the target machine offers a way to 33012 optimize the treatment of leaf functions. 33013 33014 -- Macro: LEAF_REG_REMAP (REGNO) 33015 A C expression whose value is the register number to which REGNO 33016 should be renumbered, when a function is treated as a leaf 33017 function. 33018 33019 If REGNO is a register number which should not appear in a leaf 33020 function before renumbering, then the expression should yield -1, 33021 which will cause the compiler to abort. 33022 33023 Define this macro only if the target machine offers a way to 33024 optimize the treatment of leaf functions, and registers need to be 33025 renumbered to do this. 33026 33027 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' must 33028usually treat leaf functions specially. They can test the C variable 33029'current_function_is_leaf' which is nonzero for leaf functions. 33030'current_function_is_leaf' is set prior to local register allocation and 33031is valid for the remaining compiler passes. They can also test the C 33032variable 'current_function_uses_only_leaf_regs' which is nonzero for 33033leaf functions which only use leaf registers. 33034'current_function_uses_only_leaf_regs' is valid after all passes that 33035modify the instructions have been run and is only useful if 33036'LEAF_REGISTERS' is defined. 33037 33038 33039File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 33040 3304118.7.5 Registers That Form a Stack 33042---------------------------------- 33043 33044There are special features to handle computers where some of the 33045"registers" form a stack. Stack registers are normally written by 33046pushing onto the stack, and are numbered relative to the top of the 33047stack. 33048 33049 Currently, GCC can only handle one group of stack-like registers, and 33050they must be consecutively numbered. Furthermore, the existing support 33051for stack-like registers is specific to the 80387 floating point 33052coprocessor. If you have a new architecture that uses stack-like 33053registers, you will need to do substantial work on 'reg-stack.c' and 33054write your machine description to cooperate with it, as well as defining 33055these macros. 33056 33057 -- Macro: STACK_REGS 33058 Define this if the machine has any stack-like registers. 33059 33060 -- Macro: STACK_REG_COVER_CLASS 33061 This is a cover class containing the stack registers. Define this 33062 if the machine has any stack-like registers. 33063 33064 -- Macro: FIRST_STACK_REG 33065 The number of the first stack-like register. This one is the top 33066 of the stack. 33067 33068 -- Macro: LAST_STACK_REG 33069 The number of the last stack-like register. This one is the bottom 33070 of the stack. 33071 33072 33073File: gccint.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros 33074 3307518.8 Register Classes 33076===================== 33077 33078On many machines, the numbered registers are not all equivalent. For 33079example, certain registers may not be allowed for indexed addressing; 33080certain registers may not be allowed in some instructions. These 33081machine restrictions are described to the compiler using "register 33082classes". 33083 33084 You define a number of register classes, giving each one a name and 33085saying which of the registers belong to it. Then you can specify 33086register classes that are allowed as operands to particular instruction 33087patterns. 33088 33089 In general, each register will belong to several classes. In fact, one 33090class must be named 'ALL_REGS' and contain all the registers. Another 33091class must be named 'NO_REGS' and contain no registers. Often the union 33092of two classes will be another class; however, this is not required. 33093 33094 One of the classes must be named 'GENERAL_REGS'. There is nothing 33095terribly special about the name, but the operand constraint letters 'r' 33096and 'g' specify this class. If 'GENERAL_REGS' is the same as 33097'ALL_REGS', just define it as a macro which expands to 'ALL_REGS'. 33098 33099 Order the classes so that if class X is contained in class Y then X has 33100a lower class number than Y. 33101 33102 The way classes other than 'GENERAL_REGS' are specified in operand 33103constraints is through machine-dependent operand constraint letters. 33104You can define such letters to correspond to various classes, then use 33105them in operand constraints. 33106 33107 You must define the narrowest register classes for allocatable 33108registers, so that each class either has no subclasses, or that for some 33109mode, the move cost between registers within the class is cheaper than 33110moving a register in the class to or from memory (*note Costs::). 33111 33112 You should define a class for the union of two classes whenever some 33113instruction allows both classes. For example, if an instruction allows 33114either a floating point (coprocessor) register or a general register for 33115a certain operand, you should define a class 'FLOAT_OR_GENERAL_REGS' 33116which includes both of them. Otherwise you will get suboptimal code, or 33117even internal compiler errors when reload cannot find a register in the 33118class computed via 'reg_class_subunion'. 33119 33120 You must also specify certain redundant information about the register 33121classes: for each class, which classes contain it and which ones are 33122contained in it; for each pair of classes, the largest class contained 33123in their union. 33124 33125 When a value occupying several consecutive registers is expected in a 33126certain class, all the registers used must belong to that class. 33127Therefore, register classes cannot be used to enforce a requirement for 33128a register pair to start with an even-numbered register. The way to 33129specify this requirement is with 'TARGET_HARD_REGNO_MODE_OK'. 33130 33131 Register classes used for input-operands of bitwise-and or shift 33132instructions have a special requirement: each such class must have, for 33133each fixed-point machine mode, a subclass whose registers can transfer 33134that mode to or from memory. For example, on some machines, the 33135operations for single-byte values ('QImode') are limited to certain 33136registers. When this is so, each register class that is used in a 33137bitwise-and or shift instruction must have a subclass consisting of 33138registers from which single-byte values can be loaded or stored. This 33139is so that 'PREFERRED_RELOAD_CLASS' can always have a possible value to 33140return. 33141 33142 -- Data type: enum reg_class 33143 An enumerated type that must be defined with all the register class 33144 names as enumerated values. 'NO_REGS' must be first. 'ALL_REGS' 33145 must be the last register class, followed by one more enumerated 33146 value, 'LIM_REG_CLASSES', which is not a register class but rather 33147 tells how many classes there are. 33148 33149 Each register class has a number, which is the value of casting the 33150 class name to type 'int'. The number serves as an index in many of 33151 the tables described below. 33152 33153 -- Macro: N_REG_CLASSES 33154 The number of distinct register classes, defined as follows: 33155 33156 #define N_REG_CLASSES (int) LIM_REG_CLASSES 33157 33158 -- Macro: REG_CLASS_NAMES 33159 An initializer containing the names of the register classes as C 33160 string constants. These names are used in writing some of the 33161 debugging dumps. 33162 33163 -- Macro: REG_CLASS_CONTENTS 33164 An initializer containing the contents of the register classes, as 33165 integers which are bit masks. The Nth integer specifies the 33166 contents of class N. The way the integer MASK is interpreted is 33167 that register R is in the class if 'MASK & (1 << R)' is 1. 33168 33169 When the machine has more than 32 registers, an integer does not 33170 suffice. Then the integers are replaced by sub-initializers, 33171 braced groupings containing several integers. Each sub-initializer 33172 must be suitable as an initializer for the type 'HARD_REG_SET' 33173 which is defined in 'hard-reg-set.h'. In this situation, the first 33174 integer in each sub-initializer corresponds to registers 0 through 33175 31, the second integer to registers 32 through 63, and so on. 33176 33177 -- Macro: REGNO_REG_CLASS (REGNO) 33178 A C expression whose value is a register class containing hard 33179 register REGNO. In general there is more than one such class; 33180 choose a class which is "minimal", meaning that no smaller class 33181 also contains the register. 33182 33183 -- Macro: BASE_REG_CLASS 33184 A macro whose definition is the name of the class to which a valid 33185 base register must belong. A base register is one used in an 33186 address which is the register value plus a displacement. 33187 33188 -- Macro: MODE_BASE_REG_CLASS (MODE) 33189 This is a variation of the 'BASE_REG_CLASS' macro which allows the 33190 selection of a base register in a mode dependent manner. If MODE 33191 is VOIDmode then it should return the same value as 33192 'BASE_REG_CLASS'. 33193 33194 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 33195 A C expression whose value is the register class to which a valid 33196 base register must belong in order to be used in a base plus index 33197 register address. You should define this macro if base plus index 33198 addresses have different requirements than other base register 33199 uses. 33200 33201 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, ADDRESS_SPACE, OUTER_CODE, 33202 INDEX_CODE) 33203 A C expression whose value is the register class to which a valid 33204 base register for a memory reference in mode MODE to address space 33205 ADDRESS_SPACE must belong. OUTER_CODE and INDEX_CODE define the 33206 context in which the base register occurs. OUTER_CODE is the code 33207 of the immediately enclosing expression ('MEM' for the top level of 33208 an address, 'ADDRESS' for something that occurs in an 33209 'address_operand'). INDEX_CODE is the code of the corresponding 33210 index expression if OUTER_CODE is 'PLUS'; 'SCRATCH' otherwise. 33211 33212 -- Macro: INDEX_REG_CLASS 33213 A macro whose definition is the name of the class to which a valid 33214 index register must belong. An index register is one used in an 33215 address where its value is either multiplied by a scale factor or 33216 added to another register (as well as added to a displacement). 33217 33218 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 33219 A C expression which is nonzero if register number NUM is suitable 33220 for use as a base register in operand addresses. 33221 33222 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 33223 A C expression that is just like 'REGNO_OK_FOR_BASE_P', except that 33224 that expression may examine the mode of the memory reference in 33225 MODE. You should define this macro if the mode of the memory 33226 reference affects whether a register may be used as a base 33227 register. If you define this macro, the compiler will use it 33228 instead of 'REGNO_OK_FOR_BASE_P'. The mode may be 'VOIDmode' for 33229 addresses that appear outside a 'MEM', i.e., as an 33230 'address_operand'. 33231 33232 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 33233 A C expression which is nonzero if register number NUM is suitable 33234 for use as a base register in base plus index operand addresses, 33235 accessing memory in mode MODE. It may be either a suitable hard 33236 register or a pseudo register that has been allocated such a hard 33237 register. You should define this macro if base plus index 33238 addresses have different requirements than other base register 33239 uses. 33240 33241 Use of this macro is deprecated; please use the more general 33242 'REGNO_MODE_CODE_OK_FOR_BASE_P'. 33243 33244 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE, 33245 OUTER_CODE, INDEX_CODE) 33246 A C expression which is nonzero if register number NUM is suitable 33247 for use as a base register in operand addresses, accessing memory 33248 in mode MODE in address space ADDRESS_SPACE. This is similar to 33249 'REGNO_MODE_OK_FOR_BASE_P', except that that expression may examine 33250 the context in which the register appears in the memory reference. 33251 OUTER_CODE is the code of the immediately enclosing expression 33252 ('MEM' if at the top level of the address, 'ADDRESS' for something 33253 that occurs in an 'address_operand'). INDEX_CODE is the code of 33254 the corresponding index expression if OUTER_CODE is 'PLUS'; 33255 'SCRATCH' otherwise. The mode may be 'VOIDmode' for addresses that 33256 appear outside a 'MEM', i.e., as an 'address_operand'. 33257 33258 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 33259 A C expression which is nonzero if register number NUM is suitable 33260 for use as an index register in operand addresses. It may be 33261 either a suitable hard register or a pseudo register that has been 33262 allocated such a hard register. 33263 33264 The difference between an index register and a base register is 33265 that the index register may be scaled. If an address involves the 33266 sum of two registers, neither one of them scaled, then either one 33267 may be labeled the "base" and the other the "index"; but whichever 33268 labeling is used must fit the machine's constraints of which 33269 registers may serve in each capacity. The compiler will try both 33270 labelings, looking for one that is valid, and will reload one or 33271 both registers only if neither labeling works. 33272 33273 -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t 33274 RCLASS) 33275 A target hook that places additional preference on the register 33276 class to use when it is necessary to rename a register in class 33277 RCLASS to another class, or perhaps NO_REGS, if no preferred 33278 register class is found or hook 'preferred_rename_class' is not 33279 implemented. Sometimes returning a more restrictive class makes 33280 better code. For example, on ARM, thumb-2 instructions using 33281 'LO_REGS' may be smaller than instructions using 'GENERIC_REGS'. 33282 By returning 'LO_REGS' from 'preferred_rename_class', code size can 33283 be reduced. 33284 33285 -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X, 33286 reg_class_t RCLASS) 33287 A target hook that places additional restrictions on the register 33288 class to use when it is necessary to copy value X into a register 33289 in class RCLASS. The value is a register class; perhaps RCLASS, or 33290 perhaps another, smaller class. 33291 33292 The default version of this hook always returns value of 'rclass' 33293 argument. 33294 33295 Sometimes returning a more restrictive class makes better code. 33296 For example, on the 68000, when X is an integer constant that is in 33297 range for a 'moveq' instruction, the value of this macro is always 33298 'DATA_REGS' as long as RCLASS includes the data registers. 33299 Requiring a data register guarantees that a 'moveq' will be used. 33300 33301 One case where 'TARGET_PREFERRED_RELOAD_CLASS' must not return 33302 RCLASS is if X is a legitimate constant which cannot be loaded into 33303 some register class. By returning 'NO_REGS' you can force X into a 33304 memory location. For example, rs6000 can load immediate values 33305 into general-purpose registers, but does not have an instruction 33306 for loading an immediate value into a floating-point register, so 33307 'TARGET_PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 33308 floating-point constant. If the constant can't be loaded into any 33309 kind of register, code generation will be better if 33310 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 33311 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 33312 33313 If an insn has pseudos in it after register allocation, reload will 33314 go through the alternatives and call repeatedly 33315 'TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning 33316 'NO_REGS', in this case, makes reload add a '!' in front of the 33317 constraint: the x86 back-end uses this feature to discourage usage 33318 of 387 registers when math is done in the SSE registers (and vice 33319 versa). 33320 33321 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 33322 A C expression that places additional restrictions on the register 33323 class to use when it is necessary to copy value X into a register 33324 in class CLASS. The value is a register class; perhaps CLASS, or 33325 perhaps another, smaller class. On many machines, the following 33326 definition is safe: 33327 33328 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 33329 33330 Sometimes returning a more restrictive class makes better code. 33331 For example, on the 68000, when X is an integer constant that is in 33332 range for a 'moveq' instruction, the value of this macro is always 33333 'DATA_REGS' as long as CLASS includes the data registers. 33334 Requiring a data register guarantees that a 'moveq' will be used. 33335 33336 One case where 'PREFERRED_RELOAD_CLASS' must not return CLASS is if 33337 X is a legitimate constant which cannot be loaded into some 33338 register class. By returning 'NO_REGS' you can force X into a 33339 memory location. For example, rs6000 can load immediate values 33340 into general-purpose registers, but does not have an instruction 33341 for loading an immediate value into a floating-point register, so 33342 'PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 33343 floating-point constant. If the constant cannot be loaded into any 33344 kind of register, code generation will be better if 33345 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 33346 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 33347 33348 If an insn has pseudos in it after register allocation, reload will 33349 go through the alternatives and call repeatedly 33350 'PREFERRED_RELOAD_CLASS' to find the best one. Returning 33351 'NO_REGS', in this case, makes reload add a '!' in front of the 33352 constraint: the x86 back-end uses this feature to discourage usage 33353 of 387 registers when math is done in the SSE registers (and vice 33354 versa). 33355 33356 -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx 33357 X, reg_class_t RCLASS) 33358 Like 'TARGET_PREFERRED_RELOAD_CLASS', but for output reloads 33359 instead of input reloads. 33360 33361 The default version of this hook always returns value of 'rclass' 33362 argument. 33363 33364 You can also use 'TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to 33365 discourage reload from using some alternatives, like 33366 'TARGET_PREFERRED_RELOAD_CLASS'. 33367 33368 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 33369 A C expression that places additional restrictions on the register 33370 class to use when it is necessary to be able to hold a value of 33371 mode MODE in a reload register for which class CLASS would 33372 ordinarily be used. 33373 33374 Unlike 'PREFERRED_RELOAD_CLASS', this macro should be used when 33375 there are certain modes that simply cannot go in certain reload 33376 classes. 33377 33378 The value is a register class; perhaps CLASS, or perhaps another, 33379 smaller class. 33380 33381 Don't define this macro unless the target machine has limitations 33382 which require the macro to do something nontrivial. 33383 33384 -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X, 33385 reg_class_t RELOAD_CLASS, machine_mode RELOAD_MODE, 33386 secondary_reload_info *SRI) 33387 Many machines have some registers that cannot be copied directly to 33388 or from memory or even from other types of registers. An example 33389 is the 'MQ' register, which on most machines, can only be copied to 33390 or from general registers, but not memory. Below, we shall be 33391 using the term 'intermediate register' when a move operation cannot 33392 be performed directly, but has to be done by copying the source 33393 into the intermediate register first, and then copying the 33394 intermediate register to the destination. An intermediate register 33395 always has the same mode as source and destination. Since it holds 33396 the actual value being copied, reload might apply optimizations to 33397 re-use an intermediate register and eliding the copy from the 33398 source when it can determine that the intermediate register still 33399 holds the required value. 33400 33401 Another kind of secondary reload is required on some machines which 33402 allow copying all registers to and from memory, but require a 33403 scratch register for stores to some memory locations (e.g., those 33404 with symbolic address on the RT, and those with certain symbolic 33405 address on the SPARC when compiling PIC). Scratch registers need 33406 not have the same mode as the value being copied, and usually hold 33407 a different value than that being copied. Special patterns in the 33408 md file are needed to describe how the copy is performed with the 33409 help of the scratch register; these patterns also describe the 33410 number, register class(es) and mode(s) of the scratch register(s). 33411 33412 In some cases, both an intermediate and a scratch register are 33413 required. 33414 33415 For input reloads, this target hook is called with nonzero IN_P, 33416 and X is an rtx that needs to be copied to a register of class 33417 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 33418 is called with zero IN_P, and a register of class RELOAD_CLASS 33419 needs to be copied to rtx X in RELOAD_MODE. 33420 33421 If copying a register of RELOAD_CLASS from/to X requires an 33422 intermediate register, the hook 'secondary_reload' should return 33423 the register class required for this intermediate register. If no 33424 intermediate register is required, it should return NO_REGS. If 33425 more than one intermediate register is required, describe the one 33426 that is closest in the copy chain to the reload register. 33427 33428 If scratch registers are needed, you also have to describe how to 33429 perform the copy from/to the reload register to/from this closest 33430 intermediate register. Or if no intermediate register is required, 33431 but still a scratch register is needed, describe the copy from/to 33432 the reload register to/from the reload operand X. 33433 33434 You do this by setting 'sri->icode' to the instruction code of a 33435 pattern in the md file which performs the move. Operands 0 and 1 33436 are the output and input of this copy, respectively. Operands from 33437 operand 2 onward are for scratch operands. These scratch operands 33438 must have a mode, and a single-register-class output constraint. 33439 33440 When an intermediate register is used, the 'secondary_reload' hook 33441 will be called again to determine how to copy the intermediate 33442 register to/from the reload operand X, so your hook must also have 33443 code to handle the register class of the intermediate operand. 33444 33445 X might be a pseudo-register or a 'subreg' of a pseudo-register, 33446 which could either be in a hard register or in memory. Use 33447 'true_regnum' to find out; it will return -1 if the pseudo is in 33448 memory and the hard register number if it is in a register. 33449 33450 Scratch operands in memory (constraint '"=m"' / '"=&m"') are 33451 currently not supported. For the time being, you will have to 33452 continue to use 'TARGET_SECONDARY_MEMORY_NEEDED' for that purpose. 33453 33454 'copy_cost' also uses this target hook to find out how values are 33455 copied. If you want it to include some extra cost for the need to 33456 allocate (a) scratch register(s), set 'sri->extra_cost' to the 33457 additional cost. Or if two dependent moves are supposed to have a 33458 lower cost than the sum of the individual moves due to expected 33459 fortuitous scheduling and/or special forwarding logic, you can set 33460 'sri->extra_cost' to a negative amount. 33461 33462 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 33463 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 33464 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 33465 These macros are obsolete, new ports should use the target hook 33466 'TARGET_SECONDARY_RELOAD' instead. 33467 33468 These are obsolete macros, replaced by the 33469 'TARGET_SECONDARY_RELOAD' target hook. Older ports still define 33470 these macros to indicate to the reload phase that it may need to 33471 allocate at least one register for a reload in addition to the 33472 register to contain the data. Specifically, if copying X to a 33473 register CLASS in MODE requires an intermediate register, you were 33474 supposed to define 'SECONDARY_INPUT_RELOAD_CLASS' to return the 33475 largest register class all of whose registers can be used as 33476 intermediate registers or scratch registers. 33477 33478 If copying a register CLASS in MODE to X requires an intermediate 33479 or scratch register, 'SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 33480 to be defined be defined to return the largest register class 33481 required. If the requirements for input and output reloads were 33482 the same, the macro 'SECONDARY_RELOAD_CLASS' should have been used 33483 instead of defining both macros identically. 33484 33485 The values returned by these macros are often 'GENERAL_REGS'. 33486 Return 'NO_REGS' if no spare register is needed; i.e., if X can be 33487 directly copied to or from a register of CLASS in MODE without 33488 requiring a scratch register. Do not define this macro if it would 33489 always return 'NO_REGS'. 33490 33491 If a scratch register is required (either with or without an 33492 intermediate register), you were supposed to define patterns for 33493 'reload_inM' or 'reload_outM', as required (*note Standard Names::. 33494 These patterns, which were normally implemented with a 33495 'define_expand', should be similar to the 'movM' patterns, except 33496 that operand 2 is the scratch register. 33497 33498 These patterns need constraints for the reload register and scratch 33499 register that contain a single register class. If the original 33500 reload register (whose class is CLASS) can meet the constraint 33501 given in the pattern, the value returned by these macros is used 33502 for the class of the scratch register. Otherwise, two additional 33503 reload registers are required. Their classes are obtained from the 33504 constraints in the insn pattern. 33505 33506 X might be a pseudo-register or a 'subreg' of a pseudo-register, 33507 which could either be in a hard register or in memory. Use 33508 'true_regnum' to find out; it will return -1 if the pseudo is in 33509 memory and the hard register number if it is in a register. 33510 33511 These macros should not be used in the case where a particular 33512 class of registers can only be copied to memory and not to another 33513 class of registers. In that case, secondary reload registers are 33514 not needed and would not be helpful. Instead, a stack location 33515 must be used to perform the copy and the 'movM' pattern should use 33516 memory as an intermediate storage. This case often occurs between 33517 floating-point and general registers. 33518 33519 -- Target Hook: bool TARGET_SECONDARY_MEMORY_NEEDED (machine_mode MODE, 33520 reg_class_t CLASS1, reg_class_t CLASS2) 33521 Certain machines have the property that some registers cannot be 33522 copied to some other registers without using memory. Define this 33523 hook on those machines to return true if objects of mode M in 33524 registers of CLASS1 can only be copied to registers of class CLASS2 33525 by storing a register of CLASS1 into memory and loading that memory 33526 location into a register of CLASS2. The default definition returns 33527 false for all inputs. 33528 33529 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 33530 Normally when 'TARGET_SECONDARY_MEMORY_NEEDED' is defined, the 33531 compiler allocates a stack slot for a memory location needed for 33532 register copies. If this macro is defined, the compiler instead 33533 uses the memory location defined by this macro. 33534 33535 Do not define this macro if you do not define 33536 'TARGET_SECONDARY_MEMORY_NEEDED'. 33537 33538 -- Target Hook: machine_mode TARGET_SECONDARY_MEMORY_NEEDED_MODE 33539 (machine_mode MODE) 33540 If 'TARGET_SECONDARY_MEMORY_NEEDED' tells the compiler to use 33541 memory when moving between two particular registers of mode MODE, 33542 this hook specifies the mode that the memory should have. 33543 33544 The default depends on 'TARGET_LRA_P'. Without LRA, the default is 33545 to use a word-sized mode for integral modes that are smaller than a 33546 a word. This is right thing to do on most machines because it 33547 ensures that all bits of the register are copied and prevents 33548 accesses to the registers in a narrower mode, which some machines 33549 prohibit for floating-point registers. 33550 33551 However, this default behavior is not correct on some machines, 33552 such as the DEC Alpha, that store short integers in floating-point 33553 registers differently than in integer registers. On those 33554 machines, the default widening will not work correctly and you must 33555 define this hook to suppress that widening in some cases. See the 33556 file 'alpha.c' for details. 33557 33558 With LRA, the default is to use MODE unmodified. 33559 33560 -- Target Hook: void TARGET_SELECT_EARLY_REMAT_MODES (sbitmap MODES) 33561 On some targets, certain modes cannot be held in registers around a 33562 standard ABI call and are relatively expensive to spill to the 33563 stack. The early rematerialization pass can help in such cases by 33564 aggressively recomputing values after calls, so that they don't 33565 need to be spilled. 33566 33567 This hook returns the set of such modes by setting the associated 33568 bits in MODES. The default implementation selects no modes, which 33569 has the effect of disabling the early rematerialization pass. 33570 33571 -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS) 33572 A target hook which returns 'true' if pseudos that have been 33573 assigned to registers of class RCLASS would likely be spilled 33574 because registers of RCLASS are needed for spill registers. 33575 33576 The default version of this target hook returns 'true' if RCLASS 33577 has exactly one register and 'false' otherwise. On most machines, 33578 this default should be used. For generally register-starved 33579 machines, such as i386, or machines with right register 33580 constraints, such as SH, this hook can be used to avoid excessive 33581 spilling. 33582 33583 This hook is also used by some of the global intra-procedural code 33584 transformations to throtle code motion, to avoid increasing 33585 register pressure. 33586 33587 -- Target Hook: unsigned char TARGET_CLASS_MAX_NREGS (reg_class_t 33588 RCLASS, machine_mode MODE) 33589 A target hook returns the maximum number of consecutive registers 33590 of class RCLASS needed to hold a value of mode MODE. 33591 33592 This is closely related to the macro 'TARGET_HARD_REGNO_NREGS'. In 33593 fact, the value returned by 'TARGET_CLASS_MAX_NREGS (RCLASS, MODE)' 33594 target hook should be the maximum value of 'TARGET_HARD_REGNO_NREGS 33595 (REGNO, MODE)' for all REGNO values in the class RCLASS. 33596 33597 This target hook helps control the handling of multiple-word values 33598 in the reload pass. 33599 33600 The default version of this target hook returns the size of MODE in 33601 words. 33602 33603 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 33604 A C expression for the maximum number of consecutive registers of 33605 class CLASS needed to hold a value of mode MODE. 33606 33607 This is closely related to the macro 'TARGET_HARD_REGNO_NREGS'. In 33608 fact, the value of the macro 'CLASS_MAX_NREGS (CLASS, MODE)' should 33609 be the maximum value of 'TARGET_HARD_REGNO_NREGS (REGNO, MODE)' for 33610 all REGNO values in the class CLASS. 33611 33612 This macro helps control the handling of multiple-word values in 33613 the reload pass. 33614 33615 -- Target Hook: bool TARGET_CAN_CHANGE_MODE_CLASS (machine_mode FROM, 33616 machine_mode TO, reg_class_t RCLASS) 33617 This hook returns true if it is possible to bitcast values held in 33618 registers of class RCLASS from mode FROM to mode TO and if doing so 33619 preserves the low-order bits that are common to both modes. The 33620 result is only meaningful if RCLASS has registers that can hold 33621 both 'from' and 'to'. The default implementation returns true. 33622 33623 As an example of when such bitcasting is invalid, loading 32-bit 33624 integer or floating-point objects into floating-point registers on 33625 Alpha extends them to 64 bits. Therefore loading a 64-bit object 33626 and then storing it as a 32-bit object does not store the low-order 33627 32 bits, as would be the case for a normal register. Therefore, 33628 'alpha.h' defines 'TARGET_CAN_CHANGE_MODE_CLASS' to return: 33629 33630 (GET_MODE_SIZE (from) == GET_MODE_SIZE (to) 33631 || !reg_classes_intersect_p (FLOAT_REGS, rclass)) 33632 33633 Even if storing from a register in mode TO would be valid, if both 33634 FROM and 'raw_reg_mode' for RCLASS are wider than 'word_mode', then 33635 we must prevent TO narrowing the mode. This happens when the 33636 middle-end assumes that it can load or store pieces of an N-word 33637 pseudo, and that the pseudo will eventually be allocated to N 33638 'word_mode' hard registers. Failure to prevent this kind of mode 33639 change will result in the entire 'raw_reg_mode' being modified 33640 instead of the partial value that the middle-end intended. 33641 33642 -- Target Hook: reg_class_t TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS 33643 (int, REG_CLASS_T, REG_CLASS_T) 33644 A target hook which can change allocno class for given pseudo from 33645 allocno and best class calculated by IRA. 33646 33647 The default version of this target hook always returns given class. 33648 33649 -- Target Hook: bool TARGET_LRA_P (void) 33650 A target hook which returns true if we use LRA instead of reload 33651 pass. The default version of this target hook returns true. New 33652 ports should use LRA, and existing ports are encouraged to convert. 33653 33654 -- Target Hook: int TARGET_REGISTER_PRIORITY (int) 33655 A target hook which returns the register priority number to which 33656 the register HARD_REGNO belongs to. The bigger the number, the 33657 more preferable the hard register usage (when all other conditions 33658 are the same). This hook can be used to prefer some hard register 33659 over others in LRA. For example, some x86-64 register usage needs 33660 additional prefix which makes instructions longer. The hook can 33661 return lower priority number for such registers make them less 33662 favorable and as result making the generated code smaller. The 33663 default version of this target hook returns always zero. 33664 33665 -- Target Hook: bool TARGET_REGISTER_USAGE_LEVELING_P (void) 33666 A target hook which returns true if we need register usage 33667 leveling. That means if a few hard registers are equally good for 33668 the assignment, we choose the least used hard register. The 33669 register usage leveling may be profitable for some targets. Don't 33670 use the usage leveling for targets with conditional execution or 33671 targets with big register files as it hurts if-conversion and 33672 cross-jumping optimizations. The default version of this target 33673 hook returns always false. 33674 33675 -- Target Hook: bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void) 33676 A target hook which returns true if an address with the same 33677 structure can have different maximal legitimate displacement. For 33678 example, the displacement can depend on memory mode or on operand 33679 combinations in the insn. The default version of this target hook 33680 returns always false. 33681 33682 -- Target Hook: bool TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P (rtx SUBST) 33683 A target hook which returns 'true' if SUBST can't substitute safely 33684 pseudos with equivalent memory values during register allocation. 33685 The default version of this target hook returns 'false'. On most 33686 machines, this default should be used. For generally machines with 33687 non orthogonal register usage for addressing, such as SH, this hook 33688 can be used to avoid excessive spilling. 33689 33690 -- Target Hook: bool TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT (rtx 33691 *OFFSET1, rtx *OFFSET2, poly_int64 ORIG_OFFSET, machine_mode 33692 MODE) 33693 This hook tries to split address offset ORIG_OFFSET into two parts: 33694 one that should be added to the base address to create a local 33695 anchor point, and an additional offset that can be applied to the 33696 anchor to address a value of mode MODE. The idea is that the local 33697 anchor could be shared by other accesses to nearby locations. 33698 33699 The hook returns true if it succeeds, storing the offset of the 33700 anchor from the base in OFFSET1 and the offset of the final address 33701 from the anchor in OFFSET2. The default implementation returns 33702 false. 33703 33704 -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t, 33705 MACHINE_MODE) 33706 This hook defines a class of registers which could be used for 33707 spilling pseudos of the given mode and class, or 'NO_REGS' if only 33708 memory should be used. Not defining this hook is equivalent to 33709 returning 'NO_REGS' for all inputs. 33710 33711 -- Target Hook: bool TARGET_ADDITIONAL_ALLOCNO_CLASS_P (reg_class_t) 33712 This hook should return 'true' if given class of registers should 33713 be an allocno class in any way. Usually RA uses only one register 33714 class from all classes containing the same register set. In some 33715 complicated cases, you need to have two or more such classes as 33716 allocno ones for RA correct work. Not defining this hook is 33717 equivalent to returning 'false' for all inputs. 33718 33719 -- Target Hook: scalar_int_mode TARGET_CSTORE_MODE (enum insn_code 33720 ICODE) 33721 This hook defines the machine mode to use for the boolean result of 33722 conditional store patterns. The ICODE argument is the instruction 33723 code for the cstore being performed. Not definiting this hook is 33724 the same as accepting the mode encoded into operand 0 of the cstore 33725 expander patterns. 33726 33727 -- Target Hook: int TARGET_COMPUTE_PRESSURE_CLASSES (enum reg_class 33728 *PRESSURE_CLASSES) 33729 A target hook which lets a backend compute the set of pressure 33730 classes to be used by those optimization passes which take register 33731 pressure into account, as opposed to letting IRA compute them. It 33732 returns the number of register classes stored in the array 33733 PRESSURE_CLASSES. 33734 33735 33736File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros 33737 3373818.9 Stack Layout and Calling Conventions 33739========================================= 33740 33741This describes the stack layout and calling conventions. 33742 33743* Menu: 33744 33745* Frame Layout:: 33746* Exception Handling:: 33747* Stack Checking:: 33748* Frame Registers:: 33749* Elimination:: 33750* Stack Arguments:: 33751* Register Arguments:: 33752* Scalar Return:: 33753* Aggregate Return:: 33754* Caller Saves:: 33755* Function Entry:: 33756* Profiling:: 33757* Tail Calls:: 33758* Shrink-wrapping separate components:: 33759* Stack Smashing Protection:: 33760* Miscellaneous Register Hooks:: 33761 33762 33763File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 33764 3376518.9.1 Basic Stack Layout 33766------------------------- 33767 33768Here is the basic stack layout. 33769 33770 -- Macro: STACK_GROWS_DOWNWARD 33771 Define this macro to be true if pushing a word onto the stack moves 33772 the stack pointer to a smaller address, and false otherwise. 33773 33774 -- Macro: STACK_PUSH_CODE 33775 This macro defines the operation used when something is pushed on 33776 the stack. In RTL, a push operation will be '(set (mem 33777 (STACK_PUSH_CODE (reg sp))) ...)' 33778 33779 The choices are 'PRE_DEC', 'POST_DEC', 'PRE_INC', and 'POST_INC'. 33780 Which of these is correct depends on the stack direction and on 33781 whether the stack pointer points to the last item on the stack or 33782 whether it points to the space for the next item on the stack. 33783 33784 The default is 'PRE_DEC' when 'STACK_GROWS_DOWNWARD' is true, which 33785 is almost always right, and 'PRE_INC' otherwise, which is often 33786 wrong. 33787 33788 -- Macro: FRAME_GROWS_DOWNWARD 33789 Define this macro to nonzero value if the addresses of local 33790 variable slots are at negative offsets from the frame pointer. 33791 33792 -- Macro: ARGS_GROW_DOWNWARD 33793 Define this macro if successive arguments to a function occupy 33794 decreasing addresses on the stack. 33795 33796 -- Target Hook: HOST_WIDE_INT TARGET_STARTING_FRAME_OFFSET (void) 33797 This hook returns the offset from the frame pointer to the first 33798 local variable slot to be allocated. If 'FRAME_GROWS_DOWNWARD', it 33799 is the offset to _end_ of the first slot allocated, otherwise it is 33800 the offset to _beginning_ of the first slot allocated. The default 33801 implementation returns 0. 33802 33803 -- Macro: STACK_ALIGNMENT_NEEDED 33804 Define to zero to disable final alignment of the stack during 33805 reload. The nonzero default for this macro is suitable for most 33806 ports. 33807 33808 On ports where 'TARGET_STARTING_FRAME_OFFSET' is nonzero or where 33809 there is a register save block following the local block that 33810 doesn't require alignment to 'STACK_BOUNDARY', it may be beneficial 33811 to disable stack alignment and do it in the backend. 33812 33813 -- Macro: STACK_POINTER_OFFSET 33814 Offset from the stack pointer register to the first location at 33815 which outgoing arguments are placed. If not specified, the default 33816 value of zero is used. This is the proper value for most machines. 33817 33818 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 33819 the first location at which outgoing arguments are placed. 33820 33821 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 33822 Offset from the argument pointer register to the first argument's 33823 address. On some machines it may depend on the data type of the 33824 function. 33825 33826 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 33827 the first argument's address. 33828 33829 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 33830 Offset from the stack pointer register to an item dynamically 33831 allocated on the stack, e.g., by 'alloca'. 33832 33833 The default value for this macro is 'STACK_POINTER_OFFSET' plus the 33834 length of the outgoing arguments. The default is correct for most 33835 machines. See 'function.c' for details. 33836 33837 -- Macro: INITIAL_FRAME_ADDRESS_RTX 33838 A C expression whose value is RTL representing the address of the 33839 initial stack frame. This address is passed to 'RETURN_ADDR_RTX' 33840 and 'DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 33841 reasonable default value will be used. Define this macro in order 33842 to make frame pointer elimination work in the presence of 33843 '__builtin_frame_address (count)' and '__builtin_return_address 33844 (count)' for 'count' not equal to zero. 33845 33846 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 33847 A C expression whose value is RTL representing the address in a 33848 stack frame where the pointer to the caller's frame is stored. 33849 Assume that FRAMEADDR is an RTL expression for the address of the 33850 stack frame itself. 33851 33852 If you don't define this macro, the default is to return the value 33853 of FRAMEADDR--that is, the stack frame address is also the address 33854 of the stack word that points to the previous frame. 33855 33856 -- Macro: SETUP_FRAME_ADDRESSES 33857 A C expression that produces the machine-specific code to setup the 33858 stack so that arbitrary frames can be accessed. For example, on 33859 the SPARC, we must flush all of the register windows to the stack 33860 before we can access arbitrary stack frames. You will seldom need 33861 to define this macro. The default is to do nothing. 33862 33863 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 33864 This target hook should return an rtx that is used to store the 33865 address of the current frame into the built in 'setjmp' buffer. 33866 The default value, 'virtual_stack_vars_rtx', is correct for most 33867 machines. One reason you may need to define this target hook is if 33868 'hard_frame_pointer_rtx' is the appropriate value on your machine. 33869 33870 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 33871 A C expression whose value is RTL representing the value of the 33872 frame address for the current frame. FRAMEADDR is the frame 33873 pointer of the current frame. This is used for 33874 __builtin_frame_address. You need only define this macro if the 33875 frame address is not the same as the frame pointer. Most machines 33876 do not need to define it. 33877 33878 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 33879 A C expression whose value is RTL representing the value of the 33880 return address for the frame COUNT steps up from the current frame, 33881 after the prologue. FRAMEADDR is the frame pointer of the COUNT 33882 frame, or the frame pointer of the COUNT - 1 frame if 33883 'RETURN_ADDR_IN_PREVIOUS_FRAME' is nonzero. 33884 33885 The value of the expression must always be the correct address when 33886 COUNT is zero, but may be 'NULL_RTX' if there is no way to 33887 determine the return address of other frames. 33888 33889 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 33890 Define this macro to nonzero value if the return address of a 33891 particular stack frame is accessed from the frame pointer of the 33892 previous stack frame. The zero default for this macro is suitable 33893 for most ports. 33894 33895 -- Macro: INCOMING_RETURN_ADDR_RTX 33896 A C expression whose value is RTL representing the location of the 33897 incoming return address at the beginning of any function, before 33898 the prologue. This RTL is either a 'REG', indicating that the 33899 return value is saved in 'REG', or a 'MEM' representing a location 33900 in the stack. 33901 33902 You only need to define this macro if you want to support call 33903 frame debugging information like that provided by DWARF 2. 33904 33905 If this RTL is a 'REG', you should also define 33906 'DWARF_FRAME_RETURN_COLUMN' to 'DWARF_FRAME_REGNUM (REGNO)'. 33907 33908 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 33909 A C expression whose value is an integer giving a DWARF 2 column 33910 number that may be used as an alternative return column. The 33911 column must not correspond to any gcc hard register (that is, it 33912 must not be in the range of 'DWARF_FRAME_REGNUM'). 33913 33914 This macro can be useful if 'DWARF_FRAME_RETURN_COLUMN' is set to a 33915 general register, but an alternative column needs to be used for 33916 signal frames. Some targets have also used different frame return 33917 columns over time. 33918 33919 -- Macro: DWARF_ZERO_REG 33920 A C expression whose value is an integer giving a DWARF 2 register 33921 number that is considered to always have the value zero. This 33922 should only be defined if the target has an architected zero 33923 register, and someone decided it was a good idea to use that 33924 register number to terminate the stack backtrace. New ports should 33925 avoid this. 33926 33927 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 33928 *LABEL, rtx PATTERN, int INDEX) 33929 This target hook allows the backend to emit frame-related insns 33930 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 33931 debugging info engine will invoke it on insns of the form 33932 (set (reg) (unspec [...] UNSPEC_INDEX)) 33933 and 33934 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 33935 to let the backend emit the call frame instructions. LABEL is the 33936 CFI label attached to the insn, PATTERN is the pattern of the insn 33937 and INDEX is 'UNSPEC_INDEX' or 'UNSPECV_INDEX'. 33938 33939 -- Target Hook: unsigned int TARGET_DWARF_POLY_INDETERMINATE_VALUE 33940 (unsigned int I, unsigned int *FACTOR, int *OFFSET) 33941 Express the value of 'poly_int' indeterminate I as a DWARF 33942 expression, with I counting from 1. Return the number of a DWARF 33943 register R and set '*FACTOR' and '*OFFSET' such that the value of 33944 the indeterminate is: 33945 value_of(R) / FACTOR - OFFSET 33946 33947 A target only needs to define this hook if it sets 33948 'NUM_POLY_INT_COEFFS' to a value greater than 1. 33949 33950 -- Macro: INCOMING_FRAME_SP_OFFSET 33951 A C expression whose value is an integer giving the offset, in 33952 bytes, from the value of the stack pointer register to the top of 33953 the stack frame at the beginning of any function, before the 33954 prologue. The top of the frame is defined to be the value of the 33955 stack pointer in the previous frame, just before the call 33956 instruction. 33957 33958 You only need to define this macro if you want to support call 33959 frame debugging information like that provided by DWARF 2. 33960 33961 -- Macro: DEFAULT_INCOMING_FRAME_SP_OFFSET 33962 Like 'INCOMING_FRAME_SP_OFFSET', but must be the same for all 33963 functions of the same ABI, and when using GAS '.cfi_*' directives 33964 must also agree with the default CFI GAS emits. Define this macro 33965 only if 'INCOMING_FRAME_SP_OFFSET' can have different values 33966 between different functions of the same ABI or when 33967 'INCOMING_FRAME_SP_OFFSET' does not agree with GAS default CFI. 33968 33969 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 33970 A C expression whose value is an integer giving the offset, in 33971 bytes, from the argument pointer to the canonical frame address 33972 (cfa). The final value should coincide with that calculated by 33973 'INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 33974 during virtual register instantiation. 33975 33976 The default value for this macro is 'FIRST_PARM_OFFSET (fundecl) + 33977 crtl->args.pretend_args_size', which is correct for most machines; 33978 in general, the arguments are found immediately before the stack 33979 frame. Note that this is not the case on some targets that save 33980 registers into the caller's frame, such as SPARC and rs6000, and so 33981 such targets need to define this macro. 33982 33983 You only need to define this macro if the default is incorrect, and 33984 you want to support call frame debugging information like that 33985 provided by DWARF 2. 33986 33987 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 33988 If defined, a C expression whose value is an integer giving the 33989 offset in bytes from the frame pointer to the canonical frame 33990 address (cfa). The final value should coincide with that 33991 calculated by 'INCOMING_FRAME_SP_OFFSET'. 33992 33993 Normally the CFA is calculated as an offset from the argument 33994 pointer, via 'ARG_POINTER_CFA_OFFSET', but if the argument pointer 33995 is variable due to the ABI, this may not be possible. If this 33996 macro is defined, it implies that the virtual register 33997 instantiation should be based on the frame pointer instead of the 33998 argument pointer. Only one of 'FRAME_POINTER_CFA_OFFSET' and 33999 'ARG_POINTER_CFA_OFFSET' should be defined. 34000 34001 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 34002 If defined, a C expression whose value is an integer giving the 34003 offset in bytes from the canonical frame address (cfa) to the frame 34004 base used in DWARF 2 debug information. The default is zero. A 34005 different value may reduce the size of debug information on some 34006 ports. 34007 34008 34009File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 34010 3401118.9.2 Exception Handling Support 34012--------------------------------- 34013 34014 -- Macro: EH_RETURN_DATA_REGNO (N) 34015 A C expression whose value is the Nth register number used for data 34016 by exception handlers, or 'INVALID_REGNUM' if fewer than N 34017 registers are usable. 34018 34019 The exception handling library routines communicate with the 34020 exception handlers via a set of agreed upon registers. Ideally 34021 these registers should be call-clobbered; it is possible to use 34022 call-saved registers, but may negatively impact code size. The 34023 target must support at least 2 data registers, but should define 4 34024 if there are enough free registers. 34025 34026 You must define this macro if you want to support call frame 34027 exception handling like that provided by DWARF 2. 34028 34029 -- Macro: EH_RETURN_STACKADJ_RTX 34030 A C expression whose value is RTL representing a location in which 34031 to store a stack adjustment to be applied before function return. 34032 This is used to unwind the stack to an exception handler's call 34033 frame. It will be assigned zero on code paths that return 34034 normally. 34035 34036 Typically this is a call-clobbered hard register that is otherwise 34037 untouched by the epilogue, but could also be a stack slot. 34038 34039 Do not define this macro if the stack pointer is saved and restored 34040 by the regular prolog and epilog code in the call frame itself; in 34041 this case, the exception handling library routines will update the 34042 stack location to be restored in place. Otherwise, you must define 34043 this macro if you want to support call frame exception handling 34044 like that provided by DWARF 2. 34045 34046 -- Macro: EH_RETURN_HANDLER_RTX 34047 A C expression whose value is RTL representing a location in which 34048 to store the address of an exception handler to which we should 34049 return. It will not be assigned on code paths that return 34050 normally. 34051 34052 Typically this is the location in the call frame at which the 34053 normal return address is stored. For targets that return by 34054 popping an address off the stack, this might be a memory address 34055 just below the _target_ call frame rather than inside the current 34056 call frame. If defined, 'EH_RETURN_STACKADJ_RTX' will have already 34057 been assigned, so it may be used to calculate the location of the 34058 target call frame. 34059 34060 Some targets have more complex requirements than storing to an 34061 address calculable during initial code generation. In that case 34062 the 'eh_return' instruction pattern should be used instead. 34063 34064 If you want to support call frame exception handling, you must 34065 define either this macro or the 'eh_return' instruction pattern. 34066 34067 -- Macro: RETURN_ADDR_OFFSET 34068 If defined, an integer-valued C expression for which rtl will be 34069 generated to add it to the exception handler address before it is 34070 searched in the exception handling tables, and to subtract it again 34071 from the address before using it to return to the exception 34072 handler. 34073 34074 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 34075 This macro chooses the encoding of pointers embedded in the 34076 exception handling sections. If at all possible, this should be 34077 defined such that the exception handling section will not require 34078 dynamic relocations, and so may be read-only. 34079 34080 CODE is 0 for data, 1 for code labels, 2 for function pointers. 34081 GLOBAL is true if the symbol may be affected by dynamic 34082 relocations. The macro should return a combination of the 34083 'DW_EH_PE_*' defines as found in 'dwarf2.h'. 34084 34085 If this macro is not defined, pointers will not be encoded but 34086 represented directly. 34087 34088 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 34089 ADDR, DONE) 34090 This macro allows the target to emit whatever special magic is 34091 required to represent the encoding chosen by 34092 'ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 34093 pc-relative and indirect encodings; this must be defined if the 34094 target uses text-relative or data-relative encodings. 34095 34096 This is a C statement that branches to DONE if the format was 34097 handled. ENCODING is the format chosen, SIZE is the number of 34098 bytes that the format occupies, ADDR is the 'SYMBOL_REF' to be 34099 emitted. 34100 34101 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 34102 This macro allows the target to add CPU and operating system 34103 specific code to the call-frame unwinder for use when there is no 34104 unwind data available. The most common reason to implement this 34105 macro is to unwind through signal frames. 34106 34107 This macro is called from 'uw_frame_state_for' in 'unwind-dw2.c', 34108 'unwind-dw2-xtensa.c' and 'unwind-ia64.c'. CONTEXT is an 34109 '_Unwind_Context'; FS is an '_Unwind_FrameState'. Examine 34110 'context->ra' for the address of the code being executed and 34111 'context->cfa' for the stack pointer value. If the frame can be 34112 decoded, the register save addresses should be updated in FS and 34113 the macro should evaluate to '_URC_NO_REASON'. If the frame cannot 34114 be decoded, the macro should evaluate to '_URC_END_OF_STACK'. 34115 34116 For proper signal handling in Java this macro is accompanied by 34117 'MAKE_THROW_FRAME', defined in 'libjava/include/*-signal.h' 34118 headers. 34119 34120 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 34121 This macro allows the target to add operating system specific code 34122 to the call-frame unwinder to handle the IA-64 '.unwabi' unwinding 34123 directive, usually used for signal or interrupt frames. 34124 34125 This macro is called from 'uw_update_context' in libgcc's 34126 'unwind-ia64.c'. CONTEXT is an '_Unwind_Context'; FS is an 34127 '_Unwind_FrameState'. Examine 'fs->unwabi' for the abi and context 34128 in the '.unwabi' directive. If the '.unwabi' directive can be 34129 handled, the register save addresses should be updated in FS. 34130 34131 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 34132 A C expression that evaluates to true if the target requires unwind 34133 info to be given comdat linkage. Define it to be '1' if comdat 34134 linkage is necessary. The default is '0'. 34135 34136 34137File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 34138 3413918.9.3 Specifying How Stack Checking is Done 34140-------------------------------------------- 34141 34142GCC will check that stack references are within the boundaries of the 34143stack, if the option '-fstack-check' is specified, in one of three ways: 34144 34145 1. If the value of the 'STACK_CHECK_BUILTIN' macro is nonzero, GCC 34146 will assume that you have arranged for full stack checking to be 34147 done at appropriate places in the configuration files. GCC will 34148 not do other special processing. 34149 34150 2. If 'STACK_CHECK_BUILTIN' is zero and the value of the 34151 'STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume that 34152 you have arranged for static stack checking (checking of the static 34153 stack frame of functions) to be done at appropriate places in the 34154 configuration files. GCC will only emit code to do dynamic stack 34155 checking (checking on dynamic stack allocations) using the third 34156 approach below. 34157 34158 3. If neither of the above are true, GCC will generate code to 34159 periodically "probe" the stack pointer using the values of the 34160 macros defined below. 34161 34162 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 34163defined, GCC will change its allocation strategy for large objects if 34164the option '-fstack-check' is specified: they will always be allocated 34165dynamically if their size exceeds 'STACK_CHECK_MAX_VAR_SIZE' bytes. 34166 34167 -- Macro: STACK_CHECK_BUILTIN 34168 A nonzero value if stack checking is done by the configuration 34169 files in a machine-dependent manner. You should define this macro 34170 if stack checking is required by the ABI of your machine or if you 34171 would like to do stack checking in some more efficient way than the 34172 generic approach. The default value of this macro is zero. 34173 34174 -- Macro: STACK_CHECK_STATIC_BUILTIN 34175 A nonzero value if static stack checking is done by the 34176 configuration files in a machine-dependent manner. You should 34177 define this macro if you would like to do static stack checking in 34178 some more efficient way than the generic approach. The default 34179 value of this macro is zero. 34180 34181 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 34182 An integer specifying the interval at which GCC must generate stack 34183 probe instructions, defined as 2 raised to this integer. You will 34184 normally define this macro so that the interval be no larger than 34185 the size of the "guard pages" at the end of a stack area. The 34186 default value of 12 (4096-byte interval) is suitable for most 34187 systems. 34188 34189 -- Macro: STACK_CHECK_MOVING_SP 34190 An integer which is nonzero if GCC should move the stack pointer 34191 page by page when doing probes. This can be necessary on systems 34192 where the stack pointer contains the bottom address of the memory 34193 area accessible to the executing thread at any point in time. In 34194 this situation an alternate signal stack is required in order to be 34195 able to recover from a stack overflow. The default value of this 34196 macro is zero. 34197 34198 -- Macro: STACK_CHECK_PROTECT 34199 The number of bytes of stack needed to recover from a stack 34200 overflow, for languages where such a recovery is supported. The 34201 default value of 4KB/8KB with the 'setjmp'/'longjmp'-based 34202 exception handling mechanism and 8KB/12KB with other exception 34203 handling mechanisms should be adequate for most architectures and 34204 operating systems. 34205 34206 The following macros are relevant only if neither STACK_CHECK_BUILTIN 34207nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 34208in the opposite case. 34209 34210 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 34211 The maximum size of a stack frame, in bytes. GCC will generate 34212 probe instructions in non-leaf functions to ensure at least this 34213 many bytes of stack are available. If a stack frame is larger than 34214 this size, stack checking will not be reliable and GCC will issue a 34215 warning. The default is chosen so that GCC only generates one 34216 instruction on most systems. You should normally not change the 34217 default value of this macro. 34218 34219 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 34220 GCC uses this value to generate the above warning message. It 34221 represents the amount of fixed frame used by a function, not 34222 including space for any callee-saved registers, temporaries and 34223 user variables. You need only specify an upper bound for this 34224 amount and will normally use the default of four words. 34225 34226 -- Macro: STACK_CHECK_MAX_VAR_SIZE 34227 The maximum size, in bytes, of an object that GCC will place in the 34228 fixed area of the stack frame when the user specifies 34229 '-fstack-check'. GCC computed the default from the values of the 34230 above macros and you will normally not need to override that 34231 default. 34232 34233 -- Target Hook: HOST_WIDE_INT 34234 TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE (void) 34235 Some targets have an ABI defined interval for which no probing 34236 needs to be done. When a probe does need to be done this same 34237 interval is used as the probe distance up when doing stack clash 34238 protection for alloca. On such targets this value can be set to 34239 override the default probing up interval. Define this variable to 34240 return nonzero if such a probe range is required or zero otherwise. 34241 Defining this hook also requires your functions which make use of 34242 alloca to have at least 8 byesof outgoing arguments. If this is 34243 not the case the stack will be corrupted. You need not define this 34244 macro if it would always have the value zero. 34245 34246 34247File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 34248 3424918.9.4 Registers That Address the Stack Frame 34250--------------------------------------------- 34251 34252This discusses registers that address the stack frame. 34253 34254 -- Macro: STACK_POINTER_REGNUM 34255 The register number of the stack pointer register, which must also 34256 be a fixed register according to 'FIXED_REGISTERS'. On most 34257 machines, the hardware determines which register this is. 34258 34259 -- Macro: FRAME_POINTER_REGNUM 34260 The register number of the frame pointer register, which is used to 34261 access automatic variables in the stack frame. On some machines, 34262 the hardware determines which register this is. On other machines, 34263 you can choose any register you wish for this purpose. 34264 34265 -- Macro: HARD_FRAME_POINTER_REGNUM 34266 On some machines the offset between the frame pointer and starting 34267 offset of the automatic variables is not known until after register 34268 allocation has been done (for example, because the saved registers 34269 are between these two locations). On those machines, define 34270 'FRAME_POINTER_REGNUM' the number of a special, fixed register to 34271 be used internally until the offset is known, and define 34272 'HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 34273 used for the frame pointer. 34274 34275 You should define this macro only in the very rare circumstances 34276 when it is not possible to calculate the offset between the frame 34277 pointer and the automatic variables until after register allocation 34278 has been completed. When this macro is defined, you must also 34279 indicate in your definition of 'ELIMINABLE_REGS' how to eliminate 34280 'FRAME_POINTER_REGNUM' into either 'HARD_FRAME_POINTER_REGNUM' or 34281 'STACK_POINTER_REGNUM'. 34282 34283 Do not define this macro if it would be the same as 34284 'FRAME_POINTER_REGNUM'. 34285 34286 -- Macro: ARG_POINTER_REGNUM 34287 The register number of the arg pointer register, which is used to 34288 access the function's argument list. On some machines, this is the 34289 same as the frame pointer register. On some machines, the hardware 34290 determines which register this is. On other machines, you can 34291 choose any register you wish for this purpose. If this is not the 34292 same register as the frame pointer register, then you must mark it 34293 as a fixed register according to 'FIXED_REGISTERS', or arrange to 34294 be able to eliminate it (*note Elimination::). 34295 34296 -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER 34297 Define this to a preprocessor constant that is nonzero if 34298 'hard_frame_pointer_rtx' and 'frame_pointer_rtx' should be the 34299 same. The default definition is '(HARD_FRAME_POINTER_REGNUM == 34300 FRAME_POINTER_REGNUM)'; you only need to define this macro if that 34301 definition is not suitable for use in preprocessor conditionals. 34302 34303 -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER 34304 Define this to a preprocessor constant that is nonzero if 34305 'hard_frame_pointer_rtx' and 'arg_pointer_rtx' should be the same. 34306 The default definition is '(HARD_FRAME_POINTER_REGNUM == 34307 ARG_POINTER_REGNUM)'; you only need to define this macro if that 34308 definition is not suitable for use in preprocessor conditionals. 34309 34310 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 34311 The register number of the return address pointer register, which 34312 is used to access the current function's return address from the 34313 stack. On some machines, the return address is not at a fixed 34314 offset from the frame pointer or stack pointer or argument pointer. 34315 This register can be defined to point to the return address on the 34316 stack, and then be converted by 'ELIMINABLE_REGS' into either the 34317 frame pointer or stack pointer. 34318 34319 Do not define this macro unless there is no other way to get the 34320 return address from the stack. 34321 34322 -- Macro: STATIC_CHAIN_REGNUM 34323 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 34324 Register numbers used for passing a function's static chain 34325 pointer. If register windows are used, the register number as seen 34326 by the called function is 'STATIC_CHAIN_INCOMING_REGNUM', while the 34327 register number as seen by the calling function is 34328 'STATIC_CHAIN_REGNUM'. If these registers are the same, 34329 'STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 34330 34331 The static chain register need not be a fixed register. 34332 34333 If the static chain is passed in memory, these macros should not be 34334 defined; instead, the 'TARGET_STATIC_CHAIN' hook should be used. 34335 34336 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL_OR_TYPE, 34337 bool INCOMING_P) 34338 This hook replaces the use of 'STATIC_CHAIN_REGNUM' et al for 34339 targets that may use different static chain locations for different 34340 nested functions. This may be required if the target has function 34341 attributes that affect the calling conventions of the function and 34342 those calling conventions use different static chain locations. 34343 34344 The default version of this hook uses 'STATIC_CHAIN_REGNUM' et al. 34345 34346 If the static chain is passed in memory, this hook should be used 34347 to provide rtx giving 'mem' expressions that denote where they are 34348 stored. Often the 'mem' expression as seen by the caller will be 34349 at an offset from the stack pointer and the 'mem' expression as 34350 seen by the callee will be at an offset from the frame pointer. 34351 The variables 'stack_pointer_rtx', 'frame_pointer_rtx', and 34352 'arg_pointer_rtx' will have been initialized and should be used to 34353 refer to those items. 34354 34355 -- Macro: DWARF_FRAME_REGISTERS 34356 This macro specifies the maximum number of hard registers that can 34357 be saved in a call frame. This is used to size data structures 34358 used in DWARF2 exception handling. 34359 34360 Prior to GCC 3.0, this macro was needed in order to establish a 34361 stable exception handling ABI in the face of adding new hard 34362 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 34363 insulated from changes in the number of hard registers. 34364 Nevertheless, this macro can still be used to reduce the runtime 34365 memory requirements of the exception handling routines, which can 34366 be substantial if the ISA contains a lot of registers that are not 34367 call-saved. 34368 34369 If this macro is not defined, it defaults to 34370 'FIRST_PSEUDO_REGISTER'. 34371 34372 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 34373 34374 This macro is similar to 'DWARF_FRAME_REGISTERS', but is provided 34375 for backward compatibility in pre GCC 3.0 compiled code. 34376 34377 If this macro is not defined, it defaults to 34378 'DWARF_FRAME_REGISTERS'. 34379 34380 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 34381 34382 Define this macro if the target's representation for dwarf 34383 registers is different than the internal representation for unwind 34384 column. Given a dwarf register, this macro should return the 34385 internal unwind column number to use instead. 34386 34387 -- Macro: DWARF_FRAME_REGNUM (REGNO) 34388 34389 Define this macro if the target's representation for dwarf 34390 registers used in .eh_frame or .debug_frame is different from that 34391 used in other debug info sections. Given a GCC hard register 34392 number, this macro should return the .eh_frame register number. 34393 The default is 'DBX_REGISTER_NUMBER (REGNO)'. 34394 34395 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 34396 34397 Define this macro to map register numbers held in the call frame 34398 info that GCC has collected using 'DWARF_FRAME_REGNUM' to those 34399 that should be output in .debug_frame ('FOR_EH' is zero) and 34400 .eh_frame ('FOR_EH' is nonzero). The default is to return 'REGNO'. 34401 34402 -- Macro: REG_VALUE_IN_UNWIND_CONTEXT 34403 34404 Define this macro if the target stores register values as 34405 '_Unwind_Word' type in unwind context. It should be defined if 34406 target register size is larger than the size of 'void *'. The 34407 default is to store register values as 'void *' type. 34408 34409 -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT 34410 34411 Define this macro to be 1 if the target always uses extended unwind 34412 context with version, args_size and by_value fields. If it is 34413 undefined, it will be defined to 1 when 34414 'REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise. 34415 34416 -- Macro: DWARF_LAZY_REGISTER_VALUE (REGNO, VALUE) 34417 Define this macro if the target has pseudo DWARF registers whose 34418 values need to be computed lazily on demand by the unwinder (such 34419 as when referenced in a CFA expression). The macro returns true if 34420 REGNO is such a register and stores its value in '*VALUE' if so. 34421 34422 34423File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 34424 3442518.9.5 Eliminating Frame Pointer and Arg Pointer 34426------------------------------------------------ 34427 34428This is about eliminating the frame pointer and arg pointer. 34429 34430 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 34431 This target hook should return 'true' if a function must have and 34432 use a frame pointer. This target hook is called in the reload 34433 pass. If its return value is 'true' the function will have a frame 34434 pointer. 34435 34436 This target hook can in principle examine the current function and 34437 decide according to the facts, but on most machines the constant 34438 'false' or the constant 'true' suffices. Use 'false' when the 34439 machine allows code to be generated with no frame pointer, and 34440 doing so saves some time or space. Use 'true' when there is no 34441 possible advantage to avoiding a frame pointer. 34442 34443 In certain cases, the compiler does not know how to produce valid 34444 code without a frame pointer. The compiler recognizes those cases 34445 and automatically gives the function a frame pointer regardless of 34446 what 'targetm.frame_pointer_required' returns. You don't need to 34447 worry about them. 34448 34449 In a function that does not require a frame pointer, the frame 34450 pointer register can be allocated for ordinary usage, unless you 34451 mark it as a fixed register. See 'FIXED_REGISTERS' for more 34452 information. 34453 34454 Default return value is 'false'. 34455 34456 -- Macro: ELIMINABLE_REGS 34457 This macro specifies a table of register pairs used to eliminate 34458 unneeded registers that point into the stack frame. 34459 34460 The definition of this macro is a list of structure 34461 initializations, each of which specifies an original and 34462 replacement register. 34463 34464 On some machines, the position of the argument pointer is not known 34465 until the compilation is completed. In such a case, a separate 34466 hard register must be used for the argument pointer. This register 34467 can be eliminated by replacing it with either the frame pointer or 34468 the argument pointer, depending on whether or not the frame pointer 34469 has been eliminated. 34470 34471 In this case, you might specify: 34472 #define ELIMINABLE_REGS \ 34473 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 34474 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 34475 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 34476 34477 Note that the elimination of the argument pointer with the stack 34478 pointer is specified first since that is the preferred elimination. 34479 34480 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 34481 int TO_REG) 34482 This target hook should return 'true' if the compiler is allowed to 34483 try to replace register number FROM_REG with register number 34484 TO_REG. This target hook will usually be 'true', since most of the 34485 cases preventing register elimination are things that the compiler 34486 already knows about. 34487 34488 Default return value is 'true'. 34489 34490 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 34491 This macro returns the initial difference between the specified 34492 pair of registers. The value would be computed from information 34493 such as the result of 'get_frame_size ()' and the tables of 34494 registers 'df_regs_ever_live_p' and 'call_used_regs'. 34495 34496 -- Target Hook: void TARGET_COMPUTE_FRAME_LAYOUT (void) 34497 This target hook is called once each time the frame layout needs to 34498 be recalculated. The calculations can be cached by the target and 34499 can then be used by 'INITIAL_ELIMINATION_OFFSET' instead of 34500 re-computing the layout on every invocation of that hook. This is 34501 particularly useful for targets that have an expensive frame layout 34502 function. Implementing this callback is optional. 34503 34504 34505File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 34506 3450718.9.6 Passing Function Arguments on the Stack 34508---------------------------------------------- 34509 34510The macros in this section control how arguments are passed on the 34511stack. See the following section for other macros that control passing 34512certain arguments in registers. 34513 34514 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 34515 This target hook returns 'true' if an argument declared in a 34516 prototype as an integral type smaller than 'int' should actually be 34517 passed as an 'int'. In addition to avoiding errors in certain 34518 cases of mismatch, it also makes for better code on certain 34519 machines. The default is to not promote prototypes. 34520 34521 -- Macro: PUSH_ARGS 34522 A C expression. If nonzero, push insns will be used to pass 34523 outgoing arguments. If the target machine does not have a push 34524 instruction, set it to zero. That directs GCC to use an alternate 34525 strategy: to allocate the entire argument block and then store the 34526 arguments into it. When 'PUSH_ARGS' is nonzero, 'PUSH_ROUNDING' 34527 must be defined too. 34528 34529 -- Macro: PUSH_ARGS_REVERSED 34530 A C expression. If nonzero, function arguments will be evaluated 34531 from last to first, rather than from first to last. If this macro 34532 is not defined, it defaults to 'PUSH_ARGS' on targets where the 34533 stack and args grow in opposite directions, and 0 otherwise. 34534 34535 -- Macro: PUSH_ROUNDING (NPUSHED) 34536 A C expression that is the number of bytes actually pushed onto the 34537 stack when an instruction attempts to push NPUSHED bytes. 34538 34539 On some machines, the definition 34540 34541 #define PUSH_ROUNDING(BYTES) (BYTES) 34542 34543 will suffice. But on other machines, instructions that appear to 34544 push one byte actually push two bytes in an attempt to maintain 34545 alignment. Then the definition should be 34546 34547 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 34548 34549 If the value of this macro has a type, it should be an unsigned 34550 type. 34551 34552 -- Macro: ACCUMULATE_OUTGOING_ARGS 34553 A C expression. If nonzero, the maximum amount of space required 34554 for outgoing arguments will be computed and placed into 34555 'crtl->outgoing_args_size'. No space will be pushed onto the stack 34556 for each call; instead, the function prologue should increase the 34557 stack frame size by this amount. 34558 34559 Setting both 'PUSH_ARGS' and 'ACCUMULATE_OUTGOING_ARGS' is not 34560 proper. 34561 34562 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 34563 Define this macro if functions should assume that stack space has 34564 been allocated for arguments even when their values are passed in 34565 registers. 34566 34567 The value of this macro is the size, in bytes, of the area reserved 34568 for arguments passed in registers for the function represented by 34569 FNDECL, which can be zero if GCC is calling a library function. 34570 The argument FNDECL can be the FUNCTION_DECL, or the type itself of 34571 the function. 34572 34573 This space can be allocated by the caller, or be a part of the 34574 machine-dependent stack frame: 'OUTGOING_REG_PARM_STACK_SPACE' says 34575 which. 34576 34577 -- Macro: INCOMING_REG_PARM_STACK_SPACE (FNDECL) 34578 Like 'REG_PARM_STACK_SPACE', but for incoming register arguments. 34579 Define this macro if space guaranteed when compiling a function 34580 body is different to space required when making a call, a situation 34581 that can arise with K&R style function definitions. 34582 34583 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 34584 Define this to a nonzero value if it is the responsibility of the 34585 caller to allocate the area reserved for arguments passed in 34586 registers when calling a function of FNTYPE. FNTYPE may be NULL if 34587 the function called is a library function. 34588 34589 If 'ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 34590 whether the space for these arguments counts in the value of 34591 'crtl->outgoing_args_size'. 34592 34593 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 34594 Define this macro if 'REG_PARM_STACK_SPACE' is defined, but the 34595 stack parameters don't skip the area specified by it. 34596 34597 Normally, when a parameter is not passed in registers, it is placed 34598 on the stack beyond the 'REG_PARM_STACK_SPACE' area. Defining this 34599 macro suppresses this behavior and causes the parameter to be 34600 passed on the stack in its natural location. 34601 34602 -- Target Hook: poly_int64 TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree 34603 FUNTYPE, poly_int64 SIZE) 34604 This target hook returns the number of bytes of its own arguments 34605 that a function pops on returning, or 0 if the function pops no 34606 arguments and the caller must therefore pop them all after the 34607 function returns. 34608 34609 FUNDECL is a C variable whose value is a tree node that describes 34610 the function in question. Normally it is a node of type 34611 'FUNCTION_DECL' that describes the declaration of the function. 34612 From this you can obtain the 'DECL_ATTRIBUTES' of the function. 34613 34614 FUNTYPE is a C variable whose value is a tree node that describes 34615 the function in question. Normally it is a node of type 34616 'FUNCTION_TYPE' that describes the data type of the function. From 34617 this it is possible to obtain the data types of the value and 34618 arguments (if known). 34619 34620 When a call to a library function is being considered, FUNDECL will 34621 contain an identifier node for the library function. Thus, if you 34622 need to distinguish among various library functions, you can do so 34623 by their names. Note that "library function" in this context means 34624 a function used to perform arithmetic, whose name is known 34625 specially in the compiler and was not mentioned in the C code being 34626 compiled. 34627 34628 SIZE is the number of bytes of arguments passed on the stack. If a 34629 variable number of bytes is passed, it is zero, and argument 34630 popping will always be the responsibility of the calling function. 34631 34632 On the VAX, all functions always pop their arguments, so the 34633 definition of this macro is SIZE. On the 68000, using the standard 34634 calling convention, no functions pop their arguments, so the value 34635 of the macro is always 0 in this case. But an alternative calling 34636 convention is available in which functions that take a fixed number 34637 of arguments pop them but other functions (such as 'printf') pop 34638 nothing (the caller pops all). When this convention is in use, 34639 FUNTYPE is examined to determine whether a function takes a fixed 34640 number of arguments. 34641 34642 -- Macro: CALL_POPS_ARGS (CUM) 34643 A C expression that should indicate the number of bytes a call 34644 sequence pops off the stack. It is added to the value of 34645 'RETURN_POPS_ARGS' when compiling a function call. 34646 34647 CUM is the variable in which all arguments to the called function 34648 have been accumulated. 34649 34650 On certain architectures, such as the SH5, a call trampoline is 34651 used that pops certain registers off the stack, depending on the 34652 arguments that have been passed to the function. Since this is a 34653 property of the call site, not of the called function, 34654 'RETURN_POPS_ARGS' is not appropriate. 34655 34656 34657File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 34658 3465918.9.7 Passing Arguments in Registers 34660------------------------------------- 34661 34662This section describes the macros which let you control how various 34663types of arguments are passed in registers or how they are arranged in 34664the stack. 34665 34666 -- Target Hook: rtx TARGET_FUNCTION_ARG (cumulative_args_t CA, const 34667 function_arg_info &ARG) 34668 Return an RTX indicating whether function argument ARG is passed in 34669 a register and if so, which register. Argument CA summarizes all 34670 the previous arguments. 34671 34672 The return value is usually either a 'reg' RTX for the hard 34673 register in which to pass the argument, or zero to pass the 34674 argument on the stack. 34675 34676 The return value can be a 'const_int' which means argument is 34677 passed in a target specific slot with specified number. Target 34678 hooks should be used to store or load argument in such case. See 34679 'TARGET_STORE_BOUNDS_FOR_ARG' and 'TARGET_LOAD_BOUNDS_FOR_ARG' for 34680 more information. 34681 34682 The value of the expression can also be a 'parallel' RTX. This is 34683 used when an argument is passed in multiple locations. The mode of 34684 the 'parallel' should be the mode of the entire argument. The 34685 'parallel' holds any number of 'expr_list' pairs; each one 34686 describes where part of the argument is passed. In each 34687 'expr_list' the first operand must be a 'reg' RTX for the hard 34688 register in which to pass this part of the argument, and the mode 34689 of the register RTX indicates how large this part of the argument 34690 is. The second operand of the 'expr_list' is a 'const_int' which 34691 gives the offset in bytes into the entire argument of where this 34692 part starts. As a special exception the first 'expr_list' in the 34693 'parallel' RTX may have a first operand of zero. This indicates 34694 that the entire argument is also stored on the stack. 34695 34696 The last time this hook is called, it is called with 'MODE == 34697 VOIDmode', and its result is passed to the 'call' or 'call_value' 34698 pattern as operands 2 and 3 respectively. 34699 34700 The usual way to make the ISO library 'stdarg.h' work on a machine 34701 where some arguments are usually passed in registers, is to cause 34702 nameless arguments to be passed on the stack instead. This is done 34703 by making 'TARGET_FUNCTION_ARG' return 0 whenever NAMED is 'false'. 34704 34705 You may use the hook 'targetm.calls.must_pass_in_stack' in the 34706 definition of this macro to determine if this argument is of a type 34707 that must be passed in the stack. If 'REG_PARM_STACK_SPACE' is not 34708 defined and 'TARGET_FUNCTION_ARG' returns nonzero for such an 34709 argument, the compiler will abort. If 'REG_PARM_STACK_SPACE' is 34710 defined, the argument will be computed in the stack and then loaded 34711 into a register. 34712 34713 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (const function_arg_info 34714 &ARG) 34715 This target hook should return 'true' if we should not pass ARG 34716 solely in registers. The file 'expr.h' defines a definition that 34717 is usually appropriate, refer to 'expr.h' for additional 34718 documentation. 34719 34720 -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t CA, 34721 const function_arg_info &ARG) 34722 Define this hook if the caller and callee on the target have 34723 different views of where arguments are passed. Also define this 34724 hook if there are functions that are never directly called, but are 34725 invoked by the hardware and which have nonstandard calling 34726 conventions. 34727 34728 In this case 'TARGET_FUNCTION_ARG' computes the register in which 34729 the caller passes the value, and 'TARGET_FUNCTION_INCOMING_ARG' 34730 should be defined in a similar fashion to tell the function being 34731 called where the arguments will arrive. 34732 34733 'TARGET_FUNCTION_INCOMING_ARG' can also return arbitrary address 34734 computation using hard register, which can be forced into a 34735 register, so that it can be used to pass special arguments. 34736 34737 If 'TARGET_FUNCTION_INCOMING_ARG' is not defined, 34738 'TARGET_FUNCTION_ARG' serves both purposes. 34739 34740 -- Target Hook: bool TARGET_USE_PSEUDO_PIC_REG (void) 34741 This hook should return 1 in case pseudo register should be created 34742 for pic_offset_table_rtx during function expand. 34743 34744 -- Target Hook: void TARGET_INIT_PIC_REG (void) 34745 Perform a target dependent initialization of pic_offset_table_rtx. 34746 This hook is called at the start of register allocation. 34747 34748 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (cumulative_args_t CUM, 34749 const function_arg_info &ARG) 34750 This target hook returns the number of bytes at the beginning of an 34751 argument that must be put in registers. The value must be zero for 34752 arguments that are passed entirely in registers or that are 34753 entirely pushed on the stack. 34754 34755 On some machines, certain arguments must be passed partially in 34756 registers and partially in memory. On these machines, typically 34757 the first few words of arguments are passed in registers, and the 34758 rest on the stack. If a multi-word argument (a 'double' or a 34759 structure) crosses that boundary, its first few words must be 34760 passed in registers and the rest must be pushed. This macro tells 34761 the compiler when this occurs, and how many bytes should go in 34762 registers. 34763 34764 'TARGET_FUNCTION_ARG' for these arguments should return the first 34765 register to be used by the caller for this argument; likewise 34766 'TARGET_FUNCTION_INCOMING_ARG', for the called function. 34767 34768 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM, 34769 const function_arg_info &ARG) 34770 This target hook should return 'true' if argument ARG at the 34771 position indicated by CUM should be passed by reference. This 34772 predicate is queried after target independent reasons for being 34773 passed by reference, such as 'TREE_ADDRESSABLE (ARG.type)'. 34774 34775 If the hook returns true, a copy of that argument is made in memory 34776 and a pointer to the argument is passed instead of the argument 34777 itself. The pointer is passed in whatever way is appropriate for 34778 passing a pointer to that type. 34779 34780 -- Target Hook: bool TARGET_CALLEE_COPIES (cumulative_args_t CUM, const 34781 function_arg_info &ARG) 34782 The function argument described by the parameters to this hook is 34783 known to be passed by reference. The hook should return true if 34784 the function argument should be copied by the callee instead of 34785 copied by the caller. 34786 34787 For any argument for which the hook returns true, if it can be 34788 determined that the argument is not modified, then a copy need not 34789 be generated. 34790 34791 The default version of this hook always returns false. 34792 34793 -- Macro: CUMULATIVE_ARGS 34794 A C type for declaring a variable that is used as the first 34795 argument of 'TARGET_FUNCTION_ARG' and other related values. For 34796 some target machines, the type 'int' suffices and can hold the 34797 number of bytes of argument so far. 34798 34799 There is no need to record in 'CUMULATIVE_ARGS' anything about the 34800 arguments that have been passed on the stack. The compiler has 34801 other variables to keep track of that. For target machines on 34802 which all arguments are passed on the stack, there is no need to 34803 store anything in 'CUMULATIVE_ARGS'; however, the data structure 34804 must exist and should not be empty, so use 'int'. 34805 34806 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 34807 If defined, this macro is called before generating any code for a 34808 function, but after the CFUN descriptor for the function has been 34809 created. The back end may use this macro to update CFUN to reflect 34810 an ABI other than that which would normally be used by default. If 34811 the compiler is generating code for a compiler-generated function, 34812 FNDECL may be 'NULL'. 34813 34814 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 34815 N_NAMED_ARGS) 34816 A C statement (sans semicolon) for initializing the variable CUM 34817 for the state at the beginning of the argument list. The variable 34818 has type 'CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 34819 for the data type of the function which will receive the args, or 0 34820 if the args are to a compiler support library function. For direct 34821 calls that are not libcalls, FNDECL contain the declaration node of 34822 the function. FNDECL is also set when 'INIT_CUMULATIVE_ARGS' is 34823 used to find arguments for the function being compiled. 34824 N_NAMED_ARGS is set to the number of named arguments, including a 34825 structure return address if it is passed as a parameter, when 34826 making a call. When processing incoming arguments, N_NAMED_ARGS is 34827 set to -1. 34828 34829 When processing a call to a compiler support library function, 34830 LIBNAME identifies which one. It is a 'symbol_ref' rtx which 34831 contains the name of the function, as a string. LIBNAME is 0 when 34832 an ordinary C function call is being processed. Thus, each time 34833 this macro is called, either LIBNAME or FNTYPE is nonzero, but 34834 never both of them at once. 34835 34836 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 34837 Like 'INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, it 34838 gets a 'MODE' argument instead of FNTYPE, that would be 'NULL'. 34839 INDIRECT would always be zero, too. If this macro is not defined, 34840 'INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 34841 34842 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 34843 Like 'INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 34844 finding the arguments for the function being compiled. If this 34845 macro is undefined, 'INIT_CUMULATIVE_ARGS' is used instead. 34846 34847 The value passed for LIBNAME is always 0, since library routines 34848 with special calling conventions are never compiled with GCC. The 34849 argument LIBNAME exists for symmetry with 'INIT_CUMULATIVE_ARGS'. 34850 34851 -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t CA, 34852 const function_arg_info &ARG) 34853 This hook updates the summarizer variable pointed to by CA to 34854 advance past argument ARG in the argument list. Once this is done, 34855 the variable CUM is suitable for analyzing the _following_ argument 34856 with 'TARGET_FUNCTION_ARG', etc. 34857 34858 This hook need not do anything if the argument in question was 34859 passed on the stack. The compiler knows how to track the amount of 34860 stack space used for arguments without any special help. 34861 34862 -- Target Hook: HOST_WIDE_INT TARGET_FUNCTION_ARG_OFFSET (machine_mode 34863 MODE, const_tree TYPE) 34864 This hook returns the number of bytes to add to the offset of an 34865 argument of type TYPE and mode MODE when passed in memory. This is 34866 needed for the SPU, which passes 'char' and 'short' arguments in 34867 the preferred slot that is in the middle of the quad word instead 34868 of starting at the top. The default implementation returns 0. 34869 34870 -- Target Hook: pad_direction TARGET_FUNCTION_ARG_PADDING (machine_mode 34871 MODE, const_tree TYPE) 34872 This hook determines whether, and in which direction, to pad out an 34873 argument of mode MODE and type TYPE. It returns 'PAD_UPWARD' to 34874 insert padding above the argument, 'PAD_DOWNWARD' to insert padding 34875 below the argument, or 'PAD_NONE' to inhibit padding. 34876 34877 The _amount_ of padding is not controlled by this hook, but by 34878 'TARGET_FUNCTION_ARG_ROUND_BOUNDARY'. It is always just enough to 34879 reach the next multiple of that boundary. 34880 34881 This hook has a default definition that is right for most systems. 34882 For little-endian machines, the default is to pad upward. For 34883 big-endian machines, the default is to pad downward for an argument 34884 of constant size shorter than an 'int', and upward otherwise. 34885 34886 -- Macro: PAD_VARARGS_DOWN 34887 If defined, a C expression which determines whether the default 34888 implementation of va_arg will attempt to pad down before reading 34889 the next argument, if that argument is smaller than its aligned 34890 space as controlled by 'PARM_BOUNDARY'. If this macro is not 34891 defined, all such arguments are padded down if 'BYTES_BIG_ENDIAN' 34892 is true. 34893 34894 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 34895 Specify padding for the last element of a block move between 34896 registers and memory. FIRST is nonzero if this is the only 34897 element. Defining this macro allows better control of register 34898 function parameters on big-endian machines, without using 34899 'PARALLEL' rtl. In particular, 'MUST_PASS_IN_STACK' need not test 34900 padding and mode of types in registers, as there is no longer a 34901 "wrong" part of a register; For example, a three byte aggregate may 34902 be passed in the high part of a register if so required. 34903 34904 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (machine_mode 34905 MODE, const_tree TYPE) 34906 This hook returns the alignment boundary, in bits, of an argument 34907 with the specified mode and type. The default hook returns 34908 'PARM_BOUNDARY' for all arguments. 34909 34910 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY 34911 (machine_mode MODE, const_tree TYPE) 34912 Normally, the size of an argument is rounded up to 'PARM_BOUNDARY', 34913 which is the default value for this hook. You can define this hook 34914 to return a different value if an argument size must be rounded to 34915 a larger value. 34916 34917 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 34918 A C expression that is nonzero if REGNO is the number of a hard 34919 register in which function arguments are sometimes passed. This 34920 does _not_ include implicit arguments such as the static chain and 34921 the structure-value address. On many machines, no registers can be 34922 used for this purpose since all function arguments are pushed on 34923 the stack. 34924 34925 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 34926 This hook should return true if parameter of type TYPE are passed 34927 as two scalar parameters. By default, GCC will attempt to pack 34928 complex arguments into the target's word size. Some ABIs require 34929 complex arguments to be split and treated as their individual 34930 components. For example, on AIX64, complex floats should be passed 34931 in a pair of floating point registers, even though a complex float 34932 would fit in one 64-bit floating point register. 34933 34934 The default value of this hook is 'NULL', which is treated as 34935 always false. 34936 34937 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 34938 This hook returns a type node for 'va_list' for the target. The 34939 default version of the hook returns 'void*'. 34940 34941 -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char **PNAME, 34942 tree *PTREE) 34943 This target hook is used in function 'c_common_nodes_and_builtins' 34944 to iterate through the target specific builtin types for va_list. 34945 The variable IDX is used as iterator. PNAME has to be a pointer to 34946 a 'const char *' and PTREE a pointer to a 'tree' typed variable. 34947 The arguments PNAME and PTREE are used to store the result of this 34948 macro and are set to the name of the va_list builtin type and its 34949 internal type. If the return value of this macro is zero, then 34950 there is no more element. Otherwise the IDX should be increased 34951 for the next call of this macro to iterate through all types. 34952 34953 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 34954 This hook returns the va_list type of the calling convention 34955 specified by FNDECL. The default version of this hook returns 34956 'va_list_type_node'. 34957 34958 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 34959 This hook returns the va_list type of the calling convention 34960 specified by the type of TYPE. If TYPE is not a valid va_list 34961 type, it returns 'NULL_TREE'. 34962 34963 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 34964 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 34965 This hook performs target-specific gimplification of 'VA_ARG_EXPR'. 34966 The first two parameters correspond to the arguments to 'va_arg'; 34967 the latter two are as in 'gimplify.c:gimplify_expr'. 34968 34969 -- Target Hook: bool TARGET_VALID_POINTER_MODE (scalar_int_mode MODE) 34970 Define this to return nonzero if the port can handle pointers with 34971 machine mode MODE. The default version of this hook returns true 34972 for both 'ptr_mode' and 'Pmode'. 34973 34974 -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (ao_ref *REF) 34975 Define this to return nonzero if the memory reference REF may alias 34976 with the system C library errno location. The default version of 34977 this hook assumes the system C library errno location is either a 34978 declaration of type int or accessed by dereferencing a pointer to 34979 int. 34980 34981 -- Target Hook: machine_mode TARGET_TRANSLATE_MODE_ATTRIBUTE 34982 (machine_mode MODE) 34983 Define this hook if during mode attribute processing, the port 34984 should translate machine_mode MODE to another mode. For example, 34985 rs6000's 'KFmode', when it is the same as 'TFmode'. 34986 34987 The default version of the hook returns that mode that was passed 34988 in. 34989 34990 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (scalar_mode MODE) 34991 Define this to return nonzero if the port is prepared to handle 34992 insns involving scalar mode MODE. For a scalar mode to be 34993 considered supported, all the basic arithmetic and comparisons must 34994 work. 34995 34996 The default version of this hook returns true for any mode required 34997 to handle the basic C types (as defined by the port). Included 34998 here are the double-word arithmetic supported by the code in 34999 'optabs.c'. 35000 35001 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE) 35002 Define this to return nonzero if the port is prepared to handle 35003 insns involving vector mode MODE. At the very least, it must have 35004 move patterns for this mode. 35005 35006 -- Target Hook: bool TARGET_COMPATIBLE_VECTOR_TYPES_P (const_tree 35007 TYPE1, const_tree TYPE2) 35008 Return true if there is no target-specific reason for treating 35009 vector types TYPE1 and TYPE2 as distinct types. The caller has 35010 already checked for target-independent reasons, meaning that the 35011 types are known to have the same mode, to have the same number of 35012 elements, and to have what the caller considers to be compatible 35013 element types. 35014 35015 The main reason for defining this hook is to reject pairs of types 35016 that are handled differently by the target's calling convention. 35017 For example, when a new N-bit vector architecture is added to a 35018 target, the target may want to handle normal N-bit 'VECTOR_TYPE' 35019 arguments and return values in the same way as before, to maintain 35020 backwards compatibility. However, it may also provide new, 35021 architecture-specific 'VECTOR_TYPE's that are passed and returned 35022 in a more efficient way. It is then important to maintain a 35023 distinction between the "normal" 'VECTOR_TYPE's and the new 35024 architecture-specific ones. 35025 35026 The default implementation returns true, which is correct for most 35027 targets. 35028 35029 -- Target Hook: opt_machine_mode TARGET_ARRAY_MODE (machine_mode MODE, 35030 unsigned HOST_WIDE_INT NELEMS) 35031 Return the mode that GCC should use for an array that has NELEMS 35032 elements, with each element having mode MODE. Return no mode if 35033 the target has no special requirements. In the latter case, GCC 35034 looks for an integer mode of the appropriate size if available and 35035 uses BLKmode otherwise. Usually the search for the integer mode is 35036 limited to 'MAX_FIXED_MODE_SIZE', but the 35037 'TARGET_ARRAY_MODE_SUPPORTED_P' hook allows a larger mode to be 35038 used in specific cases. 35039 35040 The main use of this hook is to specify that an array of vectors 35041 should also have a vector mode. The default implementation returns 35042 no mode. 35043 35044 -- Target Hook: bool TARGET_ARRAY_MODE_SUPPORTED_P (machine_mode MODE, 35045 unsigned HOST_WIDE_INT NELEMS) 35046 Return true if GCC should try to use a scalar mode to store an 35047 array of NELEMS elements, given that each element has mode MODE. 35048 Returning true here overrides the usual 'MAX_FIXED_MODE' limit and 35049 allows GCC to use any defined integer mode. 35050 35051 One use of this hook is to support vector load and store operations 35052 that operate on several homogeneous vectors. For example, ARM NEON 35053 has operations like: 35054 35055 int8x8x3_t vld3_s8 (const int8_t *) 35056 35057 where the return type is defined as: 35058 35059 typedef struct int8x8x3_t 35060 { 35061 int8x8_t val[3]; 35062 } int8x8x3_t; 35063 35064 If this hook allows 'val' to have a scalar mode, then 'int8x8x3_t' 35065 can have the same mode. GCC can then store 'int8x8x3_t's in 35066 registers rather than forcing them onto the stack. 35067 35068 -- Target Hook: bool TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 35069 (scalar_float_mode MODE) 35070 Define this to return nonzero if libgcc provides support for the 35071 floating-point mode MODE, which is known to pass 35072 'TARGET_SCALAR_MODE_SUPPORTED_P'. The default version of this hook 35073 returns true for all of 'SFmode', 'DFmode', 'XFmode' and 'TFmode', 35074 if such modes exist. 35075 35076 -- Target Hook: opt_scalar_float_mode TARGET_FLOATN_MODE (int N, bool 35077 EXTENDED) 35078 Define this to return the machine mode to use for the type 35079 '_FloatN', if EXTENDED is false, or the type '_FloatNx', if 35080 EXTENDED is true. If such a type is not supported, return 35081 'opt_scalar_float_mode ()'. The default version of this hook 35082 returns 'SFmode' for '_Float32', 'DFmode' for '_Float64' and 35083 '_Float32x' and 'TFmode' for '_Float128', if those modes exist and 35084 satisfy the requirements for those types and pass 35085 'TARGET_SCALAR_MODE_SUPPORTED_P' and 35086 'TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P'; for '_Float64x', it 35087 returns the first of 'XFmode' and 'TFmode' that exists and 35088 satisfies the same requirements; for other types, it returns 35089 'opt_scalar_float_mode ()'. The hook is only called for values of 35090 N and EXTENDED that are valid according to ISO/IEC TS 18661-3:2015; 35091 that is, N is one of 32, 64, 128, or, if EXTENDED is false, 16 or 35092 greater than 128 and a multiple of 32. 35093 35094 -- Target Hook: bool TARGET_FLOATN_BUILTIN_P (int FUNC) 35095 Define this to return true if the '_FloatN' and '_FloatNx' built-in 35096 functions should implicitly enable the built-in function without 35097 the '__builtin_' prefix in addition to the normal built-in function 35098 with the '__builtin_' prefix. The default is to only enable 35099 built-in functions without the '__builtin_' prefix for the GNU C 35100 langauge. In strict ANSI/ISO mode, the built-in function without 35101 the '__builtin_' prefix is not enabled. The argument 'FUNC' is the 35102 'enum built_in_function' id of the function to be enabled. 35103 35104 -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P 35105 (machine_mode MODE) 35106 Define this to return nonzero for machine modes for which the port 35107 has small register classes. If this target hook returns nonzero 35108 for a given MODE, the compiler will try to minimize the lifetime of 35109 registers in MODE. The hook may be called with 'VOIDmode' as 35110 argument. In this case, the hook is expected to return nonzero if 35111 it returns nonzero for any mode. 35112 35113 On some machines, it is risky to let hard registers live across 35114 arbitrary insns. Typically, these machines have instructions that 35115 require values to be in specific registers (like an accumulator), 35116 and reload will fail if the required hard register is used for 35117 another purpose across such an insn. 35118 35119 Passes before reload do not know which hard registers will be used 35120 in an instruction, but the machine modes of the registers set or 35121 used in the instruction are already known. And for some machines, 35122 register classes are small for, say, integer registers but not for 35123 floating point registers. For example, the AMD x86-64 architecture 35124 requires specific registers for the legacy x86 integer 35125 instructions, but there are many SSE registers for floating point 35126 operations. On such targets, a good strategy may be to return 35127 nonzero from this hook for 'INTEGRAL_MODE_P' machine modes but zero 35128 for the SSE register classes. 35129 35130 The default version of this hook returns false for any mode. It is 35131 always safe to redefine this hook to return with a nonzero value. 35132 But if you unnecessarily define it, you will reduce the amount of 35133 optimizations that can be performed in some cases. If you do not 35134 define this hook to return a nonzero value when it is required, the 35135 compiler will run out of spill registers and print a fatal error 35136 message. 35137 35138 35139File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 35140 3514118.9.8 How Scalar Function Values Are Returned 35142---------------------------------------------- 35143 35144This section discusses the macros that control returning scalars as 35145values--values that can fit in registers. 35146 35147 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 35148 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 35149 35150 Define this to return an RTX representing the place where a 35151 function returns or receives a value of data type RET_TYPE, a tree 35152 node representing a data type. FN_DECL_OR_TYPE is a tree node 35153 representing 'FUNCTION_DECL' or 'FUNCTION_TYPE' of a function being 35154 called. If OUTGOING is false, the hook should compute the register 35155 in which the caller will see the return value. Otherwise, the hook 35156 should return an RTX representing the place where a function 35157 returns a value. 35158 35159 On many machines, only 'TYPE_MODE (RET_TYPE)' is relevant. 35160 (Actually, on most machines, scalar values are returned in the same 35161 place regardless of mode.) The value of the expression is usually 35162 a 'reg' RTX for the hard register where the return value is stored. 35163 The value can also be a 'parallel' RTX, if the return value is in 35164 multiple places. See 'TARGET_FUNCTION_ARG' for an explanation of 35165 the 'parallel' form. Note that the callee will populate every 35166 location specified in the 'parallel', but if the first element of 35167 the 'parallel' contains the whole return value, callers will use 35168 that element as the canonical location and ignore the others. The 35169 m68k port uses this type of 'parallel' to return pointers in both 35170 '%a0' (the canonical location) and '%d0'. 35171 35172 If 'TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 35173 the same promotion rules specified in 'PROMOTE_MODE' if VALTYPE is 35174 a scalar type. 35175 35176 If the precise function being called is known, FUNC is a tree node 35177 ('FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 35178 makes it possible to use a different value-returning convention for 35179 specific functions when all their calls are known. 35180 35181 Some target machines have "register windows" so that the register 35182 in which a function returns its value is not the same as the one in 35183 which the caller sees the value. For such machines, you should 35184 return different RTX depending on OUTGOING. 35185 35186 'TARGET_FUNCTION_VALUE' is not used for return values with 35187 aggregate data types, because these are returned in another way. 35188 See 'TARGET_STRUCT_VALUE_RTX' and related macros, below. 35189 35190 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 35191 This macro has been deprecated. Use 'TARGET_FUNCTION_VALUE' for a 35192 new target instead. 35193 35194 -- Macro: LIBCALL_VALUE (MODE) 35195 A C expression to create an RTX representing the place where a 35196 library function returns a value of mode MODE. 35197 35198 Note that "library function" in this context means a compiler 35199 support routine, used to perform arithmetic, whose name is known 35200 specially by the compiler and was not mentioned in the C code being 35201 compiled. 35202 35203 -- Target Hook: rtx TARGET_LIBCALL_VALUE (machine_mode MODE, const_rtx 35204 FUN) 35205 Define this hook if the back-end needs to know the name of the 35206 libcall function in order to determine where the result should be 35207 returned. 35208 35209 The mode of the result is given by MODE and the name of the called 35210 library function is given by FUN. The hook should return an RTX 35211 representing the place where the library function result will be 35212 returned. 35213 35214 If this hook is not defined, then LIBCALL_VALUE will be used. 35215 35216 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 35217 A C expression that is nonzero if REGNO is the number of a hard 35218 register in which the values of called function may come back. 35219 35220 A register whose use for returning values is limited to serving as 35221 the second of a pair (for a value of type 'double', say) need not 35222 be recognized by this macro. So for most machines, this definition 35223 suffices: 35224 35225 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 35226 35227 If the machine has register windows, so that the caller and the 35228 called function use different registers for the return value, this 35229 macro should recognize only the caller's register numbers. 35230 35231 This macro has been deprecated. Use 35232 'TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead. 35233 35234 -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int 35235 REGNO) 35236 A target hook that return 'true' if REGNO is the number of a hard 35237 register in which the values of called function may come back. 35238 35239 A register whose use for returning values is limited to serving as 35240 the second of a pair (for a value of type 'double', say) need not 35241 be recognized by this target hook. 35242 35243 If the machine has register windows, so that the caller and the 35244 called function use different registers for the return value, this 35245 target hook should recognize only the caller's register numbers. 35246 35247 If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be 35248 used. 35249 35250 -- Macro: APPLY_RESULT_SIZE 35251 Define this macro if 'untyped_call' and 'untyped_return' need more 35252 space than is implied by 'FUNCTION_VALUE_REGNO_P' for saving and 35253 restoring an arbitrary return value. 35254 35255 -- Target Hook: bool TARGET_OMIT_STRUCT_RETURN_REG 35256 Normally, when a function returns a structure by memory, the 35257 address is passed as an invisible pointer argument, but the 35258 compiler also arranges to return the address from the function like 35259 it would a normal pointer return value. Define this to true if 35260 that behavior is undesirable on your target. 35261 35262 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 35263 This hook should return true if values of type TYPE are returned at 35264 the most significant end of a register (in other words, if they are 35265 padded at the least significant end). You can assume that TYPE is 35266 returned in a register; the caller is required to check this. 35267 35268 Note that the register provided by 'TARGET_FUNCTION_VALUE' must be 35269 able to hold the complete return value. For example, if a 1-, 2- 35270 or 3-byte structure is returned at the most significant end of a 35271 4-byte register, 'TARGET_FUNCTION_VALUE' should provide an 'SImode' 35272 rtx. 35273 35274 35275File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 35276 3527718.9.9 How Large Values Are Returned 35278------------------------------------ 35279 35280When a function value's mode is 'BLKmode' (and in some other cases), the 35281value is not returned according to 'TARGET_FUNCTION_VALUE' (*note Scalar 35282Return::). Instead, the caller passes the address of a block of memory 35283in which the value should be stored. This address is called the 35284"structure value address". 35285 35286 This section describes how to control returning structure values in 35287memory. 35288 35289 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 35290 const_tree FNTYPE) 35291 This target hook should return a nonzero value to say to return the 35292 function value in memory, just as large structures are always 35293 returned. Here TYPE will be the data type of the value, and FNTYPE 35294 will be the type of the function doing the returning, or 'NULL' for 35295 libcalls. 35296 35297 Note that values of mode 'BLKmode' must be explicitly handled by 35298 this function. Also, the option '-fpcc-struct-return' takes effect 35299 regardless of this macro. On most systems, it is possible to leave 35300 the hook undefined; this causes a default definition to be used, 35301 whose value is the constant 1 for 'BLKmode' values, and 0 35302 otherwise. 35303 35304 Do not use this hook to indicate that structures and unions should 35305 always be returned in memory. You should instead use 35306 'DEFAULT_PCC_STRUCT_RETURN' to indicate this. 35307 35308 -- Macro: DEFAULT_PCC_STRUCT_RETURN 35309 Define this macro to be 1 if all structure and union return values 35310 must be in memory. Since this results in slower code, this should 35311 be defined only if needed for compatibility with other compilers or 35312 with an ABI. If you define this macro to be 0, then the 35313 conventions used for structure and union return values are decided 35314 by the 'TARGET_RETURN_IN_MEMORY' target hook. 35315 35316 If not defined, this defaults to the value 1. 35317 35318 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 35319 This target hook should return the location of the structure value 35320 address (normally a 'mem' or 'reg'), or 0 if the address is passed 35321 as an "invisible" first argument. Note that FNDECL may be 'NULL', 35322 for libcalls. You do not need to define this target hook if the 35323 address is always passed as an "invisible" first argument. 35324 35325 On some architectures the place where the structure value address 35326 is found by the called function is not the same place that the 35327 caller put it. This can be due to register windows, or it could be 35328 because the function prologue moves it to a different place. 35329 INCOMING is '1' or '2' when the location is needed in the context 35330 of the called function, and '0' in the context of the caller. 35331 35332 If INCOMING is nonzero and the address is to be found on the stack, 35333 return a 'mem' which refers to the frame pointer. If INCOMING is 35334 '2', the result is being used to fetch the structure value address 35335 at the beginning of a function. If you need to emit adjusting 35336 code, you should do it at this point. 35337 35338 -- Macro: PCC_STATIC_STRUCT_RETURN 35339 Define this macro if the usual system convention on the target 35340 machine for returning structures and unions is for the called 35341 function to return the address of a static variable containing the 35342 value. 35343 35344 Do not define this if the usual system convention is for the caller 35345 to pass an address to the subroutine. 35346 35347 This macro has effect in '-fpcc-struct-return' mode, but it does 35348 nothing when you use '-freg-struct-return' mode. 35349 35350 -- Target Hook: fixed_size_mode TARGET_GET_RAW_RESULT_MODE (int REGNO) 35351 This target hook returns the mode to be used when accessing raw 35352 return registers in '__builtin_return'. Define this macro if the 35353 value in REG_RAW_MODE is not correct. 35354 35355 -- Target Hook: fixed_size_mode TARGET_GET_RAW_ARG_MODE (int REGNO) 35356 This target hook returns the mode to be used when accessing raw 35357 argument registers in '__builtin_apply_args'. Define this macro if 35358 the value in REG_RAW_MODE is not correct. 35359 35360 -- Target Hook: bool TARGET_EMPTY_RECORD_P (const_tree TYPE) 35361 This target hook returns true if the type is an empty record. The 35362 default is to return 'false'. 35363 35364 -- Target Hook: void TARGET_WARN_PARAMETER_PASSING_ABI 35365 (cumulative_args_t CA, tree TYPE) 35366 This target hook warns about the change in empty class parameter 35367 passing ABI. 35368 35369 35370File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 35371 3537218.9.10 Caller-Saves Register Allocation 35373---------------------------------------- 35374 35375If you enable it, GCC can save registers around function calls. This 35376makes it possible to use call-clobbered registers to hold variables that 35377must live across calls. 35378 35379 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 35380 A C expression specifying which mode is required for saving NREGS 35381 of a pseudo-register in call-clobbered hard register REGNO. If 35382 REGNO is unsuitable for caller save, 'VOIDmode' should be returned. 35383 For most machines this macro need not be defined since GCC will 35384 select the smallest suitable mode. 35385 35386 35387File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 35388 3538918.9.11 Function Entry and Exit 35390------------------------------- 35391 35392This section describes the macros that output function entry 35393("prologue") and exit ("epilogue") code. 35394 35395 -- Target Hook: void TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY (FILE 35396 *FILE, unsigned HOST_WIDE_INT PATCH_AREA_SIZE, bool RECORD_P) 35397 Generate a patchable area at the function start, consisting of 35398 PATCH_AREA_SIZE NOP instructions. If the target supports named 35399 sections and if RECORD_P is true, insert a pointer to the current 35400 location in the table of patchable functions. The default 35401 implementation of the hook places the table of pointers in the 35402 special section named '__patchable_function_entries'. 35403 35404 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE) 35405 If defined, a function that outputs the assembler code for entry to 35406 a function. The prologue is responsible for setting up the stack 35407 frame, initializing the frame pointer register, saving registers 35408 that must be saved, and allocating SIZE additional bytes of storage 35409 for the local variables. FILE is a stdio stream to which the 35410 assembler code should be output. 35411 35412 The label for the beginning of the function need not be output by 35413 this macro. That has already been done when the macro is run. 35414 35415 To determine which registers to save, the macro can refer to the 35416 array 'regs_ever_live': element R is nonzero if hard register R is 35417 used anywhere within the function. This implies the function 35418 prologue should save register R, provided it is not one of the 35419 call-used registers. ('TARGET_ASM_FUNCTION_EPILOGUE' must likewise 35420 use 'regs_ever_live'.) 35421 35422 On machines that have "register windows", the function entry code 35423 does not save on the stack the registers that are in the windows, 35424 even if they are supposed to be preserved by function calls; 35425 instead it takes appropriate steps to "push" the register stack, if 35426 any non-call-used registers are used in the function. 35427 35428 On machines where functions may or may not have frame-pointers, the 35429 function entry code must vary accordingly; it must set up the frame 35430 pointer if one is wanted, and not otherwise. To determine whether 35431 a frame pointer is in wanted, the macro can refer to the variable 35432 'frame_pointer_needed'. The variable's value will be 1 at run time 35433 in a function that needs a frame pointer. *Note Elimination::. 35434 35435 The function entry code is responsible for allocating any stack 35436 space required for the function. This stack space consists of the 35437 regions listed below. In most cases, these regions are allocated 35438 in the order listed, with the last listed region closest to the top 35439 of the stack (the lowest address if 'STACK_GROWS_DOWNWARD' is 35440 defined, and the highest address if it is not defined). You can 35441 use a different order for a machine if doing so is more convenient 35442 or required for compatibility reasons. Except in cases where 35443 required by standard or by a debugger, there is no reason why the 35444 stack layout used by GCC need agree with that used by other 35445 compilers for a machine. 35446 35447 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 35448 If defined, a function that outputs assembler code at the end of a 35449 prologue. This should be used when the function prologue is being 35450 emitted as RTL, and you have some extra assembler that needs to be 35451 emitted. *Note prologue instruction pattern::. 35452 35453 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 35454 If defined, a function that outputs assembler code at the start of 35455 an epilogue. This should be used when the function epilogue is 35456 being emitted as RTL, and you have some extra assembler that needs 35457 to be emitted. *Note epilogue instruction pattern::. 35458 35459 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE) 35460 If defined, a function that outputs the assembler code for exit 35461 from a function. The epilogue is responsible for restoring the 35462 saved registers and stack pointer to their values when the function 35463 was called, and returning control to the caller. This macro takes 35464 the same argument as the macro 'TARGET_ASM_FUNCTION_PROLOGUE', and 35465 the registers to restore are determined from 'regs_ever_live' and 35466 'CALL_USED_REGISTERS' in the same way. 35467 35468 On some machines, there is a single instruction that does all the 35469 work of returning from the function. On these machines, give that 35470 instruction the name 'return' and do not define the macro 35471 'TARGET_ASM_FUNCTION_EPILOGUE' at all. 35472 35473 Do not define a pattern named 'return' if you want the 35474 'TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 35475 switches to control whether return instructions or epilogues are 35476 used, define a 'return' pattern with a validity condition that 35477 tests the target switches appropriately. If the 'return' pattern's 35478 validity condition is false, epilogues will be used. 35479 35480 On machines where functions may or may not have frame-pointers, the 35481 function exit code must vary accordingly. Sometimes the code for 35482 these two cases is completely different. To determine whether a 35483 frame pointer is wanted, the macro can refer to the variable 35484 'frame_pointer_needed'. The variable's value will be 1 when 35485 compiling a function that needs a frame pointer. 35486 35487 Normally, 'TARGET_ASM_FUNCTION_PROLOGUE' and 35488 'TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 35489 The C variable 'current_function_is_leaf' is nonzero for such a 35490 function. *Note Leaf Functions::. 35491 35492 On some machines, some functions pop their arguments on exit while 35493 others leave that for the caller to do. For example, the 68020 35494 when given '-mrtd' pops arguments in functions that take a fixed 35495 number of arguments. 35496 35497 Your definition of the macro 'RETURN_POPS_ARGS' decides which 35498 functions pop their own arguments. 'TARGET_ASM_FUNCTION_EPILOGUE' 35499 needs to know what was decided. The number of bytes of the current 35500 function's arguments that this function should pop is available in 35501 'crtl->args.pops_args'. *Note Scalar Return::. 35502 35503 * A region of 'crtl->args.pretend_args_size' bytes of uninitialized 35504 space just underneath the first argument arriving on the stack. 35505 (This may not be at the very start of the allocated stack region if 35506 the calling sequence has pushed anything else since pushing the 35507 stack arguments. But usually, on such machines, nothing else has 35508 been pushed yet, because the function prologue itself does all the 35509 pushing.) This region is used on machines where an argument may be 35510 passed partly in registers and partly in memory, and, in some cases 35511 to support the features in '<stdarg.h>'. 35512 35513 * An area of memory used to save certain registers used by the 35514 function. The size of this area, which may also include space for 35515 such things as the return address and pointers to previous stack 35516 frames, is machine-specific and usually depends on which registers 35517 have been used in the function. Machines with register windows 35518 often do not require a save area. 35519 35520 * A region of at least SIZE bytes, possibly rounded up to an 35521 allocation boundary, to contain the local variables of the 35522 function. On some machines, this region and the save area may 35523 occur in the opposite order, with the save area closer to the top 35524 of the stack. 35525 35526 * Optionally, when 'ACCUMULATE_OUTGOING_ARGS' is defined, a region of 35527 'crtl->outgoing_args_size' bytes to be used for outgoing argument 35528 lists of the function. *Note Stack Arguments::. 35529 35530 -- Macro: EXIT_IGNORE_STACK 35531 Define this macro as a C expression that is nonzero if the return 35532 instruction or the function epilogue ignores the value of the stack 35533 pointer; in other words, if it is safe to delete an instruction to 35534 adjust the stack pointer before a return from the function. The 35535 default is 0. 35536 35537 Note that this macro's value is relevant only for functions for 35538 which frame pointers are maintained. It is never safe to delete a 35539 final stack adjustment in a function that has no frame pointer, and 35540 the compiler knows this regardless of 'EXIT_IGNORE_STACK'. 35541 35542 -- Macro: EPILOGUE_USES (REGNO) 35543 Define this macro as a C expression that is nonzero for registers 35544 that are used by the epilogue or the 'return' pattern. The stack 35545 and frame pointer registers are already assumed to be used as 35546 needed. 35547 35548 -- Macro: EH_USES (REGNO) 35549 Define this macro as a C expression that is nonzero for registers 35550 that are used by the exception handling mechanism, and so should be 35551 considered live on entry to an exception edge. 35552 35553 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 35554 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 35555 tree FUNCTION) 35556 A function that outputs the assembler code for a thunk function, 35557 used to implement C++ virtual function calls with multiple 35558 inheritance. The thunk acts as a wrapper around a virtual 35559 function, adjusting the implicit object parameter before handing 35560 control off to the real function. 35561 35562 First, emit code to add the integer DELTA to the location that 35563 contains the incoming first argument. Assume that this argument 35564 contains a pointer, and is the one used to pass the 'this' pointer 35565 in C++. This is the incoming argument _before_ the function 35566 prologue, e.g. '%o0' on a sparc. The addition must preserve the 35567 values of all other incoming arguments. 35568 35569 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 35570 be made after adding 'delta'. In particular, if P is the adjusted 35571 pointer, the following adjustment should be made: 35572 35573 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 35574 35575 After the additions, emit code to jump to FUNCTION, which is a 35576 'FUNCTION_DECL'. This is a direct pure jump, not a call, and does 35577 not touch the return address. Hence returning from FUNCTION will 35578 return to whoever called the current 'thunk'. 35579 35580 The effect must be as if FUNCTION had been called directly with the 35581 adjusted first argument. This macro is responsible for emitting 35582 all of the code for a thunk function; 35583 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' 35584 are not invoked. 35585 35586 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 35587 been extracted from it.) It might possibly be useful on some 35588 targets, but probably not. 35589 35590 If you do not define this macro, the target-independent code in the 35591 C++ front end will generate a less efficient heavyweight thunk that 35592 calls FUNCTION instead of jumping to it. The generic approach does 35593 not support varargs. 35594 35595 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 35596 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 35597 const_tree FUNCTION) 35598 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would be 35599 able to output the assembler code for the thunk function specified 35600 by the arguments it is passed, and false otherwise. In the latter 35601 case, the generic approach will be used by the C++ front end, with 35602 the limitations previously exposed. 35603 35604 35605File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 35606 3560718.9.12 Generating Code for Profiling 35608------------------------------------- 35609 35610These macros will help you generate code for profiling. 35611 35612 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 35613 A C statement or compound statement to output to FILE some 35614 assembler code to call the profiling subroutine 'mcount'. 35615 35616 The details of how 'mcount' expects to be called are determined by 35617 your operating system environment, not by GCC. To figure them out, 35618 compile a small program for profiling using the system's installed 35619 C compiler and look at the assembler code that results. 35620 35621 Older implementations of 'mcount' expect the address of a counter 35622 variable to be loaded into some register. The name of this 35623 variable is 'LP' followed by the number LABELNO, so you would 35624 generate the name using 'LP%d' in a 'fprintf'. 35625 35626 -- Macro: PROFILE_HOOK 35627 A C statement or compound statement to output to FILE some assembly 35628 code to call the profiling subroutine 'mcount' even the target does 35629 not support profiling. 35630 35631 -- Macro: NO_PROFILE_COUNTERS 35632 Define this macro to be an expression with a nonzero value if the 35633 'mcount' subroutine on your system does not need a counter variable 35634 allocated for each function. This is true for almost all modern 35635 implementations. If you define this macro, you must not use the 35636 LABELNO argument to 'FUNCTION_PROFILER'. 35637 35638 -- Macro: PROFILE_BEFORE_PROLOGUE 35639 Define this macro if the code for function profiling should come 35640 before the function prologue. Normally, the profiling code comes 35641 after. 35642 35643 -- Target Hook: bool TARGET_KEEP_LEAF_WHEN_PROFILED (void) 35644 This target hook returns true if the target wants the leaf flag for 35645 the current function to stay true even if it calls mcount. This 35646 might make sense for targets using the leaf flag only to determine 35647 whether a stack frame needs to be generated or not and for which 35648 the call to mcount is generated before the function prologue. 35649 35650 35651File: gccint.info, Node: Tail Calls, Next: Shrink-wrapping separate components, Prev: Profiling, Up: Stack and Calling 35652 3565318.9.13 Permitting tail calls 35654----------------------------- 35655 35656 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 35657 EXP) 35658 True if it is OK to do sibling call optimization for the specified 35659 call expression EXP. DECL will be the called function, or 'NULL' 35660 if this is an indirect call. 35661 35662 It is not uncommon for limitations of calling conventions to 35663 prevent tail calls to functions outside the current unit of 35664 translation, or during PIC compilation. The hook is used to 35665 enforce these restrictions, as the 'sibcall' md pattern cannot 35666 fail, or fall over to a "normal" call. The criteria for successful 35667 sibling call optimization may vary greatly between different 35668 architectures. 35669 35670 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 35671 Add any hard registers to REGS that are live on entry to the 35672 function. This hook only needs to be defined to provide registers 35673 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 35674 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 35675 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, FRAME_POINTER_REGNUM, 35676 EH_USES, FRAME_POINTER_REGNUM, ARG_POINTER_REGNUM, and the 35677 PIC_OFFSET_TABLE_REGNUM. 35678 35679 -- Target Hook: void TARGET_SET_UP_BY_PROLOGUE (struct 35680 hard_reg_set_container *) 35681 This hook should add additional registers that are computed by the 35682 prologue to the hard regset for shrink-wrapping optimization 35683 purposes. 35684 35685 -- Target Hook: bool TARGET_WARN_FUNC_RETURN (tree) 35686 True if a function's return statements should be checked for 35687 matching the function's return type. This includes checking for 35688 falling off the end of a non-void function. Return false if no 35689 such check should be made. 35690 35691 35692File: gccint.info, Node: Shrink-wrapping separate components, Next: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling 35693 3569418.9.14 Shrink-wrapping separate components 35695------------------------------------------- 35696 35697The prologue may perform a variety of target dependent tasks such as 35698saving callee-saved registers, saving the return address, aligning the 35699stack, creating a stack frame, initializing the PIC register, setting up 35700the static chain, etc. 35701 35702 On some targets some of these tasks may be independent of others and 35703thus may be shrink-wrapped separately. These independent tasks are 35704referred to as components and are handled generically by the target 35705independent parts of GCC. 35706 35707 Using the following hooks those prologue or epilogue components can be 35708shrink-wrapped separately, so that the initialization (and possibly 35709teardown) those components do is not done as frequently on execution 35710paths where this would unnecessary. 35711 35712 What exactly those components are is up to the target code; the generic 35713code treats them abstractly, as a bit in an 'sbitmap'. These 'sbitmap's 35714are allocated by the 'shrink_wrap.get_separate_components' and 35715'shrink_wrap.components_for_bb' hooks, and deallocated by the generic 35716code. 35717 35718 -- Target Hook: sbitmap TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS 35719 (void) 35720 This hook should return an 'sbitmap' with the bits set for those 35721 components that can be separately shrink-wrapped in the current 35722 function. Return 'NULL' if the current function should not get any 35723 separate shrink-wrapping. Don't define this hook if it would 35724 always return 'NULL'. If it is defined, the other hooks in this 35725 group have to be defined as well. 35726 35727 -- Target Hook: sbitmap TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB 35728 (basic_block) 35729 This hook should return an 'sbitmap' with the bits set for those 35730 components where either the prologue component has to be executed 35731 before the 'basic_block', or the epilogue component after it, or 35732 both. 35733 35734 -- Target Hook: void TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS (sbitmap 35735 COMPONENTS, edge E, sbitmap EDGE_COMPONENTS, bool IS_PROLOGUE) 35736 This hook should clear the bits in the COMPONENTS bitmap for those 35737 components in EDGE_COMPONENTS that the target cannot handle on edge 35738 E, where IS_PROLOGUE says if this is for a prologue or an epilogue 35739 instead. 35740 35741 -- Target Hook: void TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS 35742 (sbitmap) 35743 Emit prologue insns for the components indicated by the parameter. 35744 35745 -- Target Hook: void TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS 35746 (sbitmap) 35747 Emit epilogue insns for the components indicated by the parameter. 35748 35749 -- Target Hook: void TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS 35750 (sbitmap) 35751 Mark the components in the parameter as handled, so that the 35752 'prologue' and 'epilogue' named patterns know to ignore those 35753 components. The target code should not hang on to the 'sbitmap', 35754 it will be deleted after this call. 35755 35756 35757File: gccint.info, Node: Stack Smashing Protection, Next: Miscellaneous Register Hooks, Prev: Shrink-wrapping separate components, Up: Stack and Calling 35758 3575918.9.15 Stack smashing protection 35760--------------------------------- 35761 35762 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 35763 This hook returns a 'DECL' node for the external variable to use 35764 for the stack protection guard. This variable is initialized by 35765 the runtime to some random value and is used to initialize the 35766 guard value that is placed at the top of the local stack frame. 35767 The type of this variable must be 'ptr_type_node'. 35768 35769 The default version of this hook creates a variable called 35770 '__stack_chk_guard', which is normally defined in 'libgcc2.c'. 35771 35772 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 35773 This hook returns a 'CALL_EXPR' that alerts the runtime that the 35774 stack protect guard variable has been modified. This expression 35775 should involve a call to a 'noreturn' function. 35776 35777 The default version of this hook invokes a function called 35778 '__stack_chk_fail', taking no arguments. This function is normally 35779 defined in 'libgcc2.c'. 35780 35781 -- Target Hook: bool TARGET_STACK_PROTECT_RUNTIME_ENABLED_P (void) 35782 Returns true if the target wants GCC's default stack protect 35783 runtime support, otherwise return false. The default 35784 implementation always returns true. 35785 35786 -- Common Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, 35787 struct gcc_options *OPTS) 35788 Whether this target supports splitting the stack when the options 35789 described in OPTS have been passed. This is called after options 35790 have been parsed, so the target may reject splitting the stack in 35791 some configurations. The default version of this hook returns 35792 false. If REPORT is true, this function may issue a warning or 35793 error; if REPORT is false, it must simply return a value 35794 35795 -- Common Target Hook: vec<const char *> TARGET_GET_VALID_OPTION_VALUES 35796 (int OPTION_CODE, const char *PREFIX) 35797 The hook is used for options that have a non-trivial list of 35798 possible option values. OPTION_CODE is option code of opt_code 35799 enum type. PREFIX is used for bash completion and allows an 35800 implementation to return more specific completion based on the 35801 prefix. All string values should be allocated from heap memory and 35802 consumers should release them. The result will be pruned to cases 35803 with PREFIX if not NULL. 35804 35805 35806File: gccint.info, Node: Miscellaneous Register Hooks, Prev: Stack Smashing Protection, Up: Stack and Calling 35807 3580818.9.16 Miscellaneous register hooks 35809------------------------------------ 35810 35811 -- Target Hook: bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS 35812 Set to true if each call that binds to a local definition 35813 explicitly clobbers or sets all non-fixed registers modified by 35814 performing the call. That is, by the call pattern itself, or by 35815 code that might be inserted by the linker (e.g. stubs, veneers, 35816 branch islands), but not including those modifiable by the callee. 35817 The affected registers may be mentioned explicitly in the call 35818 pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE. The 35819 default version of this hook is set to false. The purpose of this 35820 hook is to enable the fipa-ra optimization. 35821 35822 35823File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 35824 3582518.10 Implementing the Varargs Macros 35826===================================== 35827 35828GCC comes with an implementation of '<varargs.h>' and '<stdarg.h>' that 35829work without change on machines that pass arguments on the stack. Other 35830machines require their own implementations of varargs, and the two 35831machine independent header files must have conditionals to include it. 35832 35833 ISO '<stdarg.h>' differs from traditional '<varargs.h>' mainly in the 35834calling convention for 'va_start'. The traditional implementation takes 35835just one argument, which is the variable in which to store the argument 35836pointer. The ISO implementation of 'va_start' takes an additional 35837second argument. The user is supposed to write the last named argument 35838of the function here. 35839 35840 However, 'va_start' should not use this argument. The way to find the 35841end of the named arguments is with the built-in functions described 35842below. 35843 35844 -- Macro: __builtin_saveregs () 35845 Use this built-in function to save the argument registers in memory 35846 so that the varargs mechanism can access them. Both ISO and 35847 traditional versions of 'va_start' must use '__builtin_saveregs', 35848 unless you use 'TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 35849 35850 On some machines, '__builtin_saveregs' is open-coded under the 35851 control of the target hook 'TARGET_EXPAND_BUILTIN_SAVEREGS'. On 35852 other machines, it calls a routine written in assembler language, 35853 found in 'libgcc2.c'. 35854 35855 Code generated for the call to '__builtin_saveregs' appears at the 35856 beginning of the function, as opposed to where the call to 35857 '__builtin_saveregs' is written, regardless of what the code is. 35858 This is because the registers must be saved before the function 35859 starts to use them for its own purposes. 35860 35861 -- Macro: __builtin_next_arg (LASTARG) 35862 This builtin returns the address of the first anonymous stack 35863 argument, as type 'void *'. If 'ARGS_GROW_DOWNWARD', it returns 35864 the address of the location above the first anonymous stack 35865 argument. Use it in 'va_start' to initialize the pointer for 35866 fetching arguments from the stack. Also use it in 'va_start' to 35867 verify that the second parameter LASTARG is the last named argument 35868 of the current function. 35869 35870 -- Macro: __builtin_classify_type (OBJECT) 35871 Since each machine has its own conventions for which data types are 35872 passed in which kind of register, your implementation of 'va_arg' 35873 has to embody these conventions. The easiest way to categorize the 35874 specified data type is to use '__builtin_classify_type' together 35875 with 'sizeof' and '__alignof__'. 35876 35877 '__builtin_classify_type' ignores the value of OBJECT, considering 35878 only its data type. It returns an integer describing what kind of 35879 type that is--integer, floating, pointer, structure, and so on. 35880 35881 The file 'typeclass.h' defines an enumeration that you can use to 35882 interpret the values of '__builtin_classify_type'. 35883 35884 These machine description macros help implement varargs: 35885 35886 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 35887 If defined, this hook produces the machine-specific code for a call 35888 to '__builtin_saveregs'. This code will be moved to the very 35889 beginning of the function, before any parameter access are made. 35890 The return value of this function should be an RTX that contains 35891 the value to use as the return of '__builtin_saveregs'. 35892 35893 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t 35894 ARGS_SO_FAR, const function_arg_info &ARG, int 35895 *PRETEND_ARGS_SIZE, int SECOND_TIME) 35896 This target hook offers an alternative to using 35897 '__builtin_saveregs' and defining the hook 35898 'TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 35899 register arguments into the stack so that all the arguments appear 35900 to have been passed consecutively on the stack. Once this is done, 35901 you can use the standard implementation of varargs that works for 35902 machines that pass all their arguments on the stack. 35903 35904 The argument ARGS_SO_FAR points to the 'CUMULATIVE_ARGS' data 35905 structure, containing the values that are obtained after processing 35906 the named arguments. The argument ARG describes the last of these 35907 named arguments. 35908 35909 The target hook should do two things: first, push onto the stack 35910 all the argument registers _not_ used for the named arguments, and 35911 second, store the size of the data thus pushed into the 35912 'int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 35913 that you store here will serve as additional offset for setting up 35914 the stack frame. 35915 35916 Because you must generate code to push the anonymous arguments at 35917 compile time without knowing their data types, 35918 'TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 35919 have just a single category of argument register and use it 35920 uniformly for all data types. 35921 35922 If the argument SECOND_TIME is nonzero, it means that the arguments 35923 of the function are being analyzed for the second time. This 35924 happens for an inline function, which is not actually compiled 35925 until the end of the source file. The hook 35926 'TARGET_SETUP_INCOMING_VARARGS' should not generate any 35927 instructions in this case. 35928 35929 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t 35930 CA) 35931 Define this hook to return 'true' if the location where a function 35932 argument is passed depends on whether or not it is a named 35933 argument. 35934 35935 This hook controls how the NAMED argument to 'TARGET_FUNCTION_ARG' 35936 is set for varargs and stdarg functions. If this hook returns 35937 'true', the NAMED argument is always true for named arguments, and 35938 false for unnamed arguments. If it returns 'false', but 35939 'TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns 'true', then all 35940 arguments are treated as named. Otherwise, all named arguments 35941 except the last are treated as named. 35942 35943 You need not define this hook if it always returns 'false'. 35944 35945 -- Target Hook: void TARGET_CALL_ARGS (rtx, TREE) 35946 While generating RTL for a function call, this target hook is 35947 invoked once for each argument passed to the function, either a 35948 register returned by 'TARGET_FUNCTION_ARG' or a memory location. 35949 It is called just before the point where argument registers are 35950 stored. The type of the function to be called is also passed as 35951 the second argument; it is 'NULL_TREE' for libcalls. The 35952 'TARGET_END_CALL_ARGS' hook is invoked just after the code to copy 35953 the return reg has been emitted. This functionality can be used to 35954 perform special setup of call argument registers if a target needs 35955 it. For functions without arguments, the hook is called once with 35956 'pc_rtx' passed instead of an argument register. Most ports do not 35957 need to implement anything for this hook. 35958 35959 -- Target Hook: void TARGET_END_CALL_ARGS (void) 35960 This target hook is invoked while generating RTL for a function 35961 call, just after the point where the return reg is copied into a 35962 pseudo. It signals that all the call argument and return registers 35963 for the just emitted call are now no longer in use. Most ports do 35964 not need to implement anything for this hook. 35965 35966 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 35967 (cumulative_args_t CA) 35968 If you need to conditionally change ABIs so that one works with 35969 'TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 35970 'TARGET_SETUP_INCOMING_VARARGS' nor 'TARGET_STRICT_ARGUMENT_NAMING' 35971 was defined, then define this hook to return 'true' if 35972 'TARGET_SETUP_INCOMING_VARARGS' is used, 'false' otherwise. 35973 Otherwise, you should not define this hook. 35974 35975 -- Target Hook: rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx SLOT, rtx ARG, rtx 35976 SLOT_NO) 35977 This hook is used by expand pass to emit insn to load bounds of ARG 35978 passed in SLOT. Expand pass uses this hook in case bounds of ARG 35979 are not passed in register. If SLOT is a memory, then bounds are 35980 loaded as for regular pointer loaded from memory. If SLOT is not a 35981 memory then SLOT_NO is an integer constant holding number of the 35982 target dependent special slot which should be used to obtain 35983 bounds. Hook returns RTX holding loaded bounds. 35984 35985 -- Target Hook: void TARGET_STORE_BOUNDS_FOR_ARG (rtx ARG, rtx SLOT, 35986 rtx BOUNDS, rtx SLOT_NO) 35987 This hook is used by expand pass to emit insns to store BOUNDS of 35988 ARG passed in SLOT. Expand pass uses this hook in case BOUNDS of 35989 ARG are not passed in register. If SLOT is a memory, then BOUNDS 35990 are stored as for regular pointer stored in memory. If SLOT is not 35991 a memory then SLOT_NO is an integer constant holding number of the 35992 target dependent special slot which should be used to store BOUNDS. 35993 35994 -- Target Hook: rtx TARGET_LOAD_RETURNED_BOUNDS (rtx SLOT) 35995 This hook is used by expand pass to emit insn to load bounds 35996 returned by function call in SLOT. Hook returns RTX holding loaded 35997 bounds. 35998 35999 -- Target Hook: void TARGET_STORE_RETURNED_BOUNDS (rtx SLOT, rtx 36000 BOUNDS) 36001 This hook is used by expand pass to emit insn to store BOUNDS 36002 returned by function call into SLOT. 36003 36004 36005File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 36006 3600718.11 Support for Nested Functions 36008================================== 36009 36010Taking the address of a nested function requires special compiler 36011handling to ensure that the static chain register is loaded when the 36012function is invoked via an indirect call. 36013 36014 GCC has traditionally supported nested functions by creating an 36015executable "trampoline" at run time when the address of a nested 36016function is taken. This is a small piece of code which normally resides 36017on the stack, in the stack frame of the containing function. The 36018trampoline loads the static chain register and then jumps to the real 36019address of the nested function. 36020 36021 The use of trampolines requires an executable stack, which is a 36022security risk. To avoid this problem, GCC also supports another 36023strategy: using descriptors for nested functions. Under this model, 36024taking the address of a nested function results in a pointer to a 36025non-executable function descriptor object. Initializing the static 36026chain from the descriptor is handled at indirect call sites. 36027 36028 On some targets, including HPPA and IA-64, function descriptors may be 36029mandated by the ABI or be otherwise handled in a target-specific way by 36030the back end in its code generation strategy for indirect calls. GCC 36031also provides its own generic descriptor implementation to support the 36032'-fno-trampolines' option. In this case runtime detection of function 36033descriptors at indirect call sites relies on descriptor pointers being 36034tagged with a bit that is never set in bare function addresses. Since 36035GCC's generic function descriptors are not ABI-compliant, this option is 36036typically used only on a per-language basis (notably by Ada) or when it 36037can otherwise be applied to the whole program. 36038 36039 Define the following hook if your backend either implements 36040ABI-specified descriptor support, or can use GCC's generic descriptor 36041implementation for nested functions. 36042 36043 -- Target Hook: int TARGET_CUSTOM_FUNCTION_DESCRIPTORS 36044 If the target can use GCC's generic descriptor mechanism for nested 36045 functions, define this hook to a power of 2 representing an unused 36046 bit in function pointers which can be used to differentiate 36047 descriptors at run time. This value gives the number of bytes by 36048 which descriptor pointers are misaligned compared to function 36049 pointers. For example, on targets that require functions to be 36050 aligned to a 4-byte boundary, a value of either 1 or 2 is 36051 appropriate unless the architecture already reserves the bit for 36052 another purpose, such as on ARM. 36053 36054 Define this hook to 0 if the target implements ABI support for 36055 function descriptors in its standard calling sequence, like for 36056 example HPPA or IA-64. 36057 36058 Using descriptors for nested functions eliminates the need for 36059 trampolines that reside on the stack and require it to be made 36060 executable. 36061 36062 The following macros tell GCC how to generate code to allocate and 36063initialize an executable trampoline. You can also use this interface if 36064your back end needs to create ABI-specified non-executable descriptors; 36065in this case the "trampoline" created is the descriptor containing data 36066only. 36067 36068 The instructions in an executable trampoline must do two things: load a 36069constant address into the static chain register, and jump to the real 36070address of the nested function. On CISC machines such as the m68k, this 36071requires two instructions, a move immediate and a jump. Then the two 36072addresses exist in the trampoline as word-long immediate operands. On 36073RISC machines, it is often necessary to load each address into a 36074register in two parts. Then pieces of each address form separate 36075immediate operands. 36076 36077 The code generated to initialize the trampoline must store the variable 36078parts--the static chain value and the function address--into the 36079immediate operands of the instructions. On a CISC machine, this is 36080simply a matter of copying each address to a memory reference at the 36081proper offset from the start of the trampoline. On a RISC machine, it 36082may be necessary to take out pieces of the address and store them 36083separately. 36084 36085 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 36086 This hook is called by 'assemble_trampoline_template' to output, on 36087 the stream F, assembler code for a block of data that contains the 36088 constant parts of a trampoline. This code should not include a 36089 label--the label is taken care of automatically. 36090 36091 If you do not define this hook, it means no template is needed for 36092 the target. Do not define this hook on systems where the block 36093 move code to copy the trampoline into place would be larger than 36094 the code to generate it on the spot. 36095 36096 -- Macro: TRAMPOLINE_SECTION 36097 Return the section into which the trampoline template is to be 36098 placed (*note Sections::). The default value is 36099 'readonly_data_section'. 36100 36101 -- Macro: TRAMPOLINE_SIZE 36102 A C expression for the size in bytes of the trampoline, as an 36103 integer. 36104 36105 -- Macro: TRAMPOLINE_ALIGNMENT 36106 Alignment required for trampolines, in bits. 36107 36108 If you don't define this macro, the value of 'FUNCTION_ALIGNMENT' 36109 is used for aligning trampolines. 36110 36111 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 36112 rtx STATIC_CHAIN) 36113 This hook is called to initialize a trampoline. M_TRAMP is an RTX 36114 for the memory block for the trampoline; FNDECL is the 36115 'FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX for 36116 the static chain value that should be passed to the function when 36117 it is called. 36118 36119 If the target defines 'TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 36120 first thing this hook should do is emit a block move into M_TRAMP 36121 from the memory block returned by 'assemble_trampoline_template'. 36122 Note that the block move need only cover the constant parts of the 36123 trampoline. If the target isolates the variable parts of the 36124 trampoline to the end, not all 'TRAMPOLINE_SIZE' bytes need be 36125 copied. 36126 36127 If the target requires any other actions, such as flushing caches 36128 or enabling stack execution, these actions should be performed 36129 after initializing the trampoline proper. 36130 36131 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 36132 This hook should perform any machine-specific adjustment in the 36133 address of the trampoline. Its argument contains the address of 36134 the memory block that was passed to 'TARGET_TRAMPOLINE_INIT'. In 36135 case the address to be used for a function call should be different 36136 from the address at which the template was stored, the different 36137 address should be returned; otherwise ADDR should be returned 36138 unchanged. If this hook is not defined, ADDR will be used for 36139 function calls. 36140 36141 Implementing trampolines is difficult on many machines because they 36142have separate instruction and data caches. Writing into a stack 36143location fails to clear the memory in the instruction cache, so when the 36144program jumps to that location, it executes the old contents. 36145 36146 Here are two possible solutions. One is to clear the relevant parts of 36147the instruction cache whenever a trampoline is set up. The other is to 36148make all trampolines identical, by having them jump to a standard 36149subroutine. The former technique makes trampoline execution faster; the 36150latter makes initialization faster. 36151 36152 To clear the instruction cache when a trampoline is initialized, define 36153the following macro. 36154 36155 -- Macro: CLEAR_INSN_CACHE (BEG, END) 36156 If defined, expands to a C expression clearing the _instruction 36157 cache_ in the specified interval. The definition of this macro 36158 would typically be a series of 'asm' statements. Both BEG and END 36159 are both pointer expressions. 36160 36161 To use a standard subroutine, define the following macro. In addition, 36162you must make sure that the instructions in a trampoline fill an entire 36163cache line with identical instructions, or else ensure that the 36164beginning of the trampoline code is always aligned at the same point in 36165its cache line. Look in 'm68k.h' as a guide. 36166 36167 -- Macro: TRANSFER_FROM_TRAMPOLINE 36168 Define this macro if trampolines need a special subroutine to do 36169 their work. The macro should expand to a series of 'asm' 36170 statements which will be compiled with GCC. They go in a library 36171 function named '__transfer_from_trampoline'. 36172 36173 If you need to avoid executing the ordinary prologue code of a 36174 compiled C function when you jump to the subroutine, you can do so 36175 by placing a special label of your own in the assembler code. Use 36176 one 'asm' statement to generate an assembler label, and another to 36177 make the label global. Then trampolines can use that label to jump 36178 directly to your special assembler code. 36179 36180 36181File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 36182 3618318.12 Implicit Calls to Library Routines 36184======================================== 36185 36186Here is an explanation of implicit calls to library routines. 36187 36188 -- Macro: DECLARE_LIBRARY_RENAMES 36189 This macro, if defined, should expand to a piece of C code that 36190 will get expanded when compiling functions for libgcc.a. It can be 36191 used to provide alternate names for GCC's internal library 36192 functions if there are ABI-mandated names that the compiler should 36193 provide. 36194 36195 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 36196 This hook should declare additional library routines or rename 36197 existing ones, using the functions 'set_optab_libfunc' and 36198 'init_one_libfunc' defined in 'optabs.c'. 'init_optabs' calls this 36199 macro after initializing all the normal library routines. 36200 36201 The default is to do nothing. Most ports don't need to define this 36202 hook. 36203 36204 -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX 36205 If false (the default), internal library routines start with two 36206 underscores. If set to true, these routines start with '__gnu_' 36207 instead. E.g., '__muldi3' changes to '__gnu_muldi3'. This 36208 currently only affects functions defined in 'libgcc2.c'. If this 36209 is set to true, the 'tm.h' file must also '#define 36210 LIBGCC2_GNU_PREFIX'. 36211 36212 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 36213 This macro should return 'true' if the library routine that 36214 implements the floating point comparison operator COMPARISON in 36215 mode MODE will return a boolean, and FALSE if it will return a 36216 tristate. 36217 36218 GCC's own floating point libraries return tristates from the 36219 comparison operators, so the default returns false always. Most 36220 ports don't need to define this macro. 36221 36222 -- Macro: TARGET_LIB_INT_CMP_BIASED 36223 This macro should evaluate to 'true' if the integer comparison 36224 functions (like '__cmpdi2') return 0 to indicate that the first 36225 operand is smaller than the second, 1 to indicate that they are 36226 equal, and 2 to indicate that the first operand is greater than the 36227 second. If this macro evaluates to 'false' the comparison 36228 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 36229 target uses the routines in 'libgcc.a', you do not need to define 36230 this macro. 36231 36232 -- Macro: TARGET_HAS_NO_HW_DIVIDE 36233 This macro should be defined if the target has no hardware divide 36234 instructions. If this macro is defined, GCC will use an algorithm 36235 which make use of simple logical and arithmetic operations for 36236 64-bit division. If the macro is not defined, GCC will use an 36237 algorithm which make use of a 64-bit by 32-bit divide primitive. 36238 36239 -- Macro: TARGET_EDOM 36240 The value of 'EDOM' on the target machine, as a C integer constant 36241 expression. If you don't define this macro, GCC does not attempt 36242 to deposit the value of 'EDOM' into 'errno' directly. Look in 36243 '/usr/include/errno.h' to find the value of 'EDOM' on your system. 36244 36245 If you do not define 'TARGET_EDOM', then compiled code reports 36246 domain errors by calling the library function and letting it report 36247 the error. If mathematical functions on your system use 'matherr' 36248 when there is an error, then you should leave 'TARGET_EDOM' 36249 undefined so that 'matherr' is used normally. 36250 36251 -- Macro: GEN_ERRNO_RTX 36252 Define this macro as a C expression to create an rtl expression 36253 that refers to the global "variable" 'errno'. (On certain systems, 36254 'errno' may not actually be a variable.) If you don't define this 36255 macro, a reasonable default is used. 36256 36257 -- Target Hook: bool TARGET_LIBC_HAS_FUNCTION (enum function_class 36258 FN_CLASS) 36259 This hook determines whether a function from a class of functions 36260 FN_CLASS is present in the target C library. 36261 36262 -- Target Hook: bool TARGET_LIBC_HAS_FAST_FUNCTION (int FCODE) 36263 This hook determines whether a function from a class of functions 36264 '(enum function_class)'FCODE has a fast implementation. 36265 36266 -- Macro: NEXT_OBJC_RUNTIME 36267 Set this macro to 1 to use the "NeXT" Objective-C message sending 36268 conventions by default. This calling convention involves passing 36269 the object, the selector and the method arguments all at once to 36270 the method-lookup library function. This is the usual setting when 36271 targeting Darwin/Mac OS X systems, which have the NeXT runtime 36272 installed. 36273 36274 If the macro is set to 0, the "GNU" Objective-C message sending 36275 convention will be used by default. This convention passes just 36276 the object and the selector to the method-lookup function, which 36277 returns a pointer to the method. 36278 36279 In either case, it remains possible to select code-generation for 36280 the alternate scheme, by means of compiler command line switches. 36281 36282 36283File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 36284 3628518.13 Addressing Modes 36286====================== 36287 36288This is about addressing modes. 36289 36290 -- Macro: HAVE_PRE_INCREMENT 36291 -- Macro: HAVE_PRE_DECREMENT 36292 -- Macro: HAVE_POST_INCREMENT 36293 -- Macro: HAVE_POST_DECREMENT 36294 A C expression that is nonzero if the machine supports 36295 pre-increment, pre-decrement, post-increment, or post-decrement 36296 addressing respectively. 36297 36298 -- Macro: HAVE_PRE_MODIFY_DISP 36299 -- Macro: HAVE_POST_MODIFY_DISP 36300 A C expression that is nonzero if the machine supports pre- or 36301 post-address side-effect generation involving constants other than 36302 the size of the memory operand. 36303 36304 -- Macro: HAVE_PRE_MODIFY_REG 36305 -- Macro: HAVE_POST_MODIFY_REG 36306 A C expression that is nonzero if the machine supports pre- or 36307 post-address side-effect generation involving a register 36308 displacement. 36309 36310 -- Macro: CONSTANT_ADDRESS_P (X) 36311 A C expression that is 1 if the RTX X is a constant which is a 36312 valid address. On most machines the default definition of 36313 '(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 36314 but a few machines are more restrictive as to which constant 36315 addresses are supported. 36316 36317 -- Macro: CONSTANT_P (X) 36318 'CONSTANT_P', which is defined by target-independent code, accepts 36319 integer-values expressions whose values are not explicitly known, 36320 such as 'symbol_ref', 'label_ref', and 'high' expressions and 36321 'const' arithmetic expressions, in addition to 'const_int' and 36322 'const_double' expressions. 36323 36324 -- Macro: MAX_REGS_PER_ADDRESS 36325 A number, the maximum number of registers that can appear in a 36326 valid memory address. Note that it is up to you to specify a value 36327 equal to the maximum number that 'TARGET_LEGITIMATE_ADDRESS_P' 36328 would ever accept. 36329 36330 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (machine_mode MODE, 36331 rtx X, bool STRICT) 36332 A function that returns whether X (an RTX) is a legitimate memory 36333 address on the target machine for a memory operand of mode MODE. 36334 36335 Legitimate addresses are defined in two variants: a strict variant 36336 and a non-strict one. The STRICT parameter chooses which variant 36337 is desired by the caller. 36338 36339 The strict variant is used in the reload pass. It must be defined 36340 so that any pseudo-register that has not been allocated a hard 36341 register is considered a memory reference. This is because in 36342 contexts where some kind of register is required, a pseudo-register 36343 with no hard register must be rejected. For non-hard registers, 36344 the strict variant should look up the 'reg_renumber' array; it 36345 should then proceed using the hard register number in the array, or 36346 treat the pseudo as a memory reference if the array holds '-1'. 36347 36348 The non-strict variant is used in other passes. It must be defined 36349 to accept all pseudo-registers in every context where some kind of 36350 register is required. 36351 36352 Normally, constant addresses which are the sum of a 'symbol_ref' 36353 and an integer are stored inside a 'const' RTX to mark them as 36354 constant. Therefore, there is no need to recognize such sums 36355 specifically as legitimate addresses. Normally you would simply 36356 recognize any 'const' as legitimate. 36357 36358 Usually 'PRINT_OPERAND_ADDRESS' is not prepared to handle constant 36359 sums that are not marked with 'const'. It assumes that a naked 36360 'plus' indicates indexing. If so, then you _must_ reject such 36361 naked constant sums as illegitimate addresses, so that none of them 36362 will be given to 'PRINT_OPERAND_ADDRESS'. 36363 36364 On some machines, whether a symbolic address is legitimate depends 36365 on the section that the address refers to. On these machines, 36366 define the target hook 'TARGET_ENCODE_SECTION_INFO' to store the 36367 information into the 'symbol_ref', and then check for it here. 36368 When you see a 'const', you will have to look inside it to find the 36369 'symbol_ref' in order to determine the section. *Note Assembler 36370 Format::. 36371 36372 Some ports are still using a deprecated legacy substitute for this 36373 hook, the 'GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 36374 syntax: 36375 36376 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 36377 36378 and should 'goto LABEL' if the address X is a valid address on the 36379 target machine for a memory operand of mode MODE. 36380 36381 Compiler source files that want to use the strict variant of this 36382 macro define the macro 'REG_OK_STRICT'. You should use an '#ifdef 36383 REG_OK_STRICT' conditional to define the strict variant in that 36384 case and the non-strict variant otherwise. 36385 36386 Using the hook is usually simpler because it limits the number of 36387 files that are recompiled when changes are made. 36388 36389 -- Macro: TARGET_MEM_CONSTRAINT 36390 A single character to be used instead of the default ''m'' 36391 character for general memory addresses. This defines the 36392 constraint letter which matches the memory addresses accepted by 36393 'TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 36394 support new address formats in your back end without changing the 36395 semantics of the ''m'' constraint. This is necessary in order to 36396 preserve functionality of inline assembly constructs using the 36397 ''m'' constraint. 36398 36399 -- Macro: FIND_BASE_TERM (X) 36400 A C expression to determine the base term of address X, or to 36401 provide a simplified version of X from which 'alias.c' can easily 36402 find the base term. This macro is used in only two places: 36403 'find_base_value' and 'find_base_term' in 'alias.c'. 36404 36405 It is always safe for this macro to not be defined. It exists so 36406 that alias analysis can understand machine-dependent addresses. 36407 36408 The typical use of this macro is to handle addresses containing a 36409 label_ref or symbol_ref within an UNSPEC. 36410 36411 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, 36412 machine_mode MODE) 36413 This hook is given an invalid memory address X for an operand of 36414 mode MODE and should try to return a valid memory address. 36415 36416 X will always be the result of a call to 'break_out_memory_refs', 36417 and OLDX will be the operand that was given to that function to 36418 produce X. 36419 36420 The code of the hook should not alter the substructure of X. If it 36421 transforms X into a more legitimate form, it should return the new 36422 X. 36423 36424 It is not necessary for this hook to come up with a legitimate 36425 address, with the exception of native TLS addresses (*note Emulated 36426 TLS::). The compiler has standard ways of doing so in all cases. 36427 In fact, if the target supports only emulated TLS, it is safe to 36428 omit this hook or make it return X if it cannot find a valid way to 36429 legitimize the address. But often a machine-dependent strategy can 36430 generate better code. 36431 36432 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 36433 WIN) 36434 A C compound statement that attempts to replace X, which is an 36435 address that needs reloading, with a valid memory address for an 36436 operand of mode MODE. WIN will be a C statement label elsewhere in 36437 the code. It is not necessary to define this macro, but it might 36438 be useful for performance reasons. 36439 36440 For example, on the i386, it is sometimes possible to use a single 36441 reload register instead of two by reloading a sum of two pseudo 36442 registers into a register. On the other hand, for number of RISC 36443 processors offsets are limited so that often an intermediate 36444 address needs to be generated in order to address a stack slot. By 36445 defining 'LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 36446 intermediate addresses generated for adjacent some stack slots can 36447 be made identical, and thus be shared. 36448 36449 _Note_: This macro should be used with caution. It is necessary to 36450 know something of how reload works in order to effectively use 36451 this, and it is quite easy to produce macros that build in too much 36452 knowledge of reload internals. 36453 36454 _Note_: This macro must be able to reload an address created by a 36455 previous invocation of this macro. If it fails to handle such 36456 addresses then the compiler may generate incorrect code or abort. 36457 36458 The macro definition should use 'push_reload' to indicate parts 36459 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 36460 suitable to be passed unaltered to 'push_reload'. 36461 36462 The code generated by this macro must not alter the substructure of 36463 X. If it transforms X into a more legitimate form, it should 36464 assign X (which will always be a C variable) a new value. This 36465 also applies to parts that you change indirectly by calling 36466 'push_reload'. 36467 36468 The macro definition may use 'strict_memory_address_p' to test if 36469 the address has become legitimate. 36470 36471 If you want to change only a part of X, one standard way of doing 36472 this is to use 'copy_rtx'. Note, however, that it unshares only a 36473 single level of rtl. Thus, if the part to be changed is not at the 36474 top level, you'll need to replace first the top level. It is not 36475 necessary for this macro to come up with a legitimate address; but 36476 often a machine-dependent strategy can generate better code. 36477 36478 -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR, 36479 addr_space_t ADDRSPACE) 36480 This hook returns 'true' if memory address ADDR in address space 36481 ADDRSPACE can have different meanings depending on the machine mode 36482 of the memory reference it is used for or if the address is valid 36483 for some modes but not others. 36484 36485 Autoincrement and autodecrement addresses typically have 36486 mode-dependent effects because the amount of the increment or 36487 decrement is the size of the operand being addressed. Some 36488 machines have other mode-dependent addresses. Many RISC machines 36489 have no mode-dependent addresses. 36490 36491 You may assume that ADDR is a valid address for the machine. 36492 36493 The default version of this hook returns 'false'. 36494 36495 -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (machine_mode MODE, 36496 rtx X) 36497 This hook returns true if X is a legitimate constant for a 36498 MODE-mode immediate operand on the target machine. You can assume 36499 that X satisfies 'CONSTANT_P', so you need not check this. 36500 36501 The default definition returns true. 36502 36503 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 36504 This hook is used to undo the possibly obfuscating effects of the 36505 'LEGITIMIZE_ADDRESS' and 'LEGITIMIZE_RELOAD_ADDRESS' target macros. 36506 Some backend implementations of these macros wrap symbol references 36507 inside an 'UNSPEC' rtx to represent PIC or similar addressing 36508 modes. This target hook allows GCC's optimizers to understand the 36509 semantics of these opaque 'UNSPEC's by converting them back into 36510 their original form. 36511 36512 -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X) 36513 This hook should return true if X should not be emitted into debug 36514 sections. 36515 36516 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (machine_mode MODE, 36517 rtx X) 36518 This hook should return true if X is of a form that cannot (or 36519 should not) be spilled to the constant pool. MODE is the mode of 36520 X. 36521 36522 The default version of this hook returns false. 36523 36524 The primary reason to define this hook is to prevent reload from 36525 deciding that a non-legitimate constant would be better reloaded 36526 from the constant pool instead of spilling and reloading a register 36527 holding the constant. This restriction is often true of addresses 36528 of TLS symbols for various targets. 36529 36530 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (machine_mode 36531 MODE, const_rtx X) 36532 This hook should return true if pool entries for constant X can be 36533 placed in an 'object_block' structure. MODE is the mode of X. 36534 36535 The default version returns false for all constants. 36536 36537 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL) 36538 This hook should return true if pool entries for DECL should be 36539 placed in an 'object_block' structure. 36540 36541 The default version returns true for all decls. 36542 36543 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (tree FNDECL) 36544 This hook should return the DECL of a function that implements the 36545 reciprocal of the machine-specific builtin function FNDECL, or 36546 'NULL_TREE' if such a function is not available. 36547 36548 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 36549 This hook should return the DECL of a function F that given an 36550 address ADDR as an argument returns a mask M that can be used to 36551 extract from two vectors the relevant data that resides in ADDR in 36552 case ADDR is not properly aligned. 36553 36554 The autovectorizer, when vectorizing a load operation from an 36555 address ADDR that may be unaligned, will generate two vector loads 36556 from the two aligned addresses around ADDR. It then generates a 36557 'REALIGN_LOAD' operation to extract the relevant data from the two 36558 loaded vectors. The first two arguments to 'REALIGN_LOAD', V1 and 36559 V2, are the two vectors, each of size VS, and the third argument, 36560 OFF, defines how the data will be extracted from these two vectors: 36561 if OFF is 0, then the returned vector is V2; otherwise, the 36562 returned vector is composed from the last VS-OFF elements of V1 36563 concatenated to the first OFF elements of V2. 36564 36565 If this hook is defined, the autovectorizer will generate a call to 36566 F (using the DECL tree that this hook returns) and will use the 36567 return value of F as the argument OFF to 'REALIGN_LOAD'. 36568 Therefore, the mask M returned by F should comply with the 36569 semantics expected by 'REALIGN_LOAD' described above. If this hook 36570 is not defined, then ADDR will be used as the argument OFF to 36571 'REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 36572 will be considered. 36573 36574 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum 36575 vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN) 36576 Returns cost of different scalar or vector statements for 36577 vectorization cost model. For vector memory operations the cost 36578 may depend on type (VECTYPE) and misalignment value (MISALIGN). 36579 36580 -- Target Hook: poly_uint64 TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT 36581 (const_tree TYPE) 36582 This hook returns the preferred alignment in bits for accesses to 36583 vectors of type TYPE in vectorized code. This might be less than 36584 or greater than the ABI-defined value returned by 36585 'TARGET_VECTOR_ALIGNMENT'. It can be equal to the alignment of a 36586 single element, in which case the vectorizer will not try to 36587 optimize for alignment. 36588 36589 The default hook returns 'TYPE_ALIGN (TYPE)', which is correct for 36590 most targets. 36591 36592 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 36593 (const_tree TYPE, bool IS_PACKED) 36594 Return true if vector alignment is reachable (by peeling N 36595 iterations) for the given scalar type TYPE. IS_PACKED is false if 36596 the scalar access using TYPE is known to be naturally aligned. 36597 36598 -- Target Hook: bool TARGET_VECTORIZE_VEC_PERM_CONST (machine_mode 36599 MODE, rtx OUTPUT, rtx IN0, rtx IN1, const vec_perm_indices 36600 &SEL) 36601 This hook is used to test whether the target can permute up to two 36602 vectors of mode MODE using the permutation vector 'sel', and also 36603 to emit such a permutation. In the former case IN0, IN1 and OUT 36604 are all null. In the latter case IN0 and IN1 are the source 36605 vectors and OUT is the destination vector; all three are registers 36606 of mode MODE. IN1 is the same as IN0 if SEL describes a 36607 permutation on one vector instead of two. 36608 36609 Return true if the operation is possible, emitting instructions for 36610 it if rtxes are provided. 36611 36612 If the hook returns false for a mode with multibyte elements, GCC 36613 will try the equivalent byte operation. If that also fails, it 36614 will try forcing the selector into a register and using the 36615 VEC_PERMMODE instruction pattern. There is no need for the hook to 36616 handle these two implementation approaches itself. 36617 36618 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION 36619 (unsigned CODE, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 36620 This hook should return the decl of a function that implements the 36621 vectorized variant of the function with the 'combined_fn' code CODE 36622 or 'NULL_TREE' if such a function is not available. The return 36623 type of the vectorized function shall be of vector type 36624 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 36625 36626 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION 36627 (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 36628 This hook should return the decl of a function that implements the 36629 vectorized variant of target built-in function 'fndecl'. The 36630 return type of the vectorized function shall be of vector type 36631 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 36632 36633 -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT 36634 (machine_mode MODE, const_tree TYPE, int MISALIGNMENT, bool 36635 IS_PACKED) 36636 This hook should return true if the target supports misaligned 36637 vector store/load of a specific factor denoted in the MISALIGNMENT 36638 parameter. The vector store/load should be of machine mode MODE 36639 and the elements in the vectors should be of type TYPE. IS_PACKED 36640 parameter is true if the memory access is defined in a packed 36641 struct. 36642 36643 -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE 36644 (scalar_mode MODE) 36645 This hook should return the preferred mode for vectorizing scalar 36646 mode MODE. The default is equal to 'word_mode', because the 36647 vectorizer can do some transformations even in absence of 36648 specialized SIMD hardware. 36649 36650 -- Target Hook: machine_mode TARGET_VECTORIZE_SPLIT_REDUCTION 36651 (machine_mode) 36652 This hook should return the preferred mode to split the final 36653 reduction step on MODE to. The reduction is then carried out 36654 reducing upper against lower halves of vectors recursively until 36655 the specified mode is reached. The default is MODE which means no 36656 splitting. 36657 36658 -- Target Hook: unsigned int 36659 TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES (vector_modes 36660 *MODES, bool ALL) 36661 If using the mode returned by 36662 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is not the only approach 36663 worth considering, this hook should add one mode to MODES for each 36664 useful alternative approach. These modes are then passed to 36665 'TARGET_VECTORIZE_RELATED_MODE' to obtain the vector mode for a 36666 given element mode. 36667 36668 The modes returned in MODES should use the smallest element mode 36669 possible for the vectorization approach that they represent, 36670 preferring integer modes over floating-poing modes in the event of 36671 a tie. The first mode should be the 36672 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' for its element mode. 36673 36674 If ALL is true, add suitable vector modes even when they are 36675 generally not expected to be worthwhile. 36676 36677 The hook returns a bitmask of flags that control how the modes in 36678 MODES are used. The flags are: 36679 'VECT_COMPARE_COSTS' 36680 Tells the loop vectorizer to try all the provided modes and 36681 pick the one with the lowest cost. By default the vectorizer 36682 will choose the first mode that works. 36683 36684 The hook does not need to do anything if the vector returned by 36685 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is the only one relevant for 36686 autovectorization. The default implementation adds no modes and 36687 returns 0. 36688 36689 -- Target Hook: opt_machine_mode TARGET_VECTORIZE_RELATED_MODE 36690 (machine_mode VECTOR_MODE, scalar_mode ELEMENT_MODE, 36691 poly_uint64 NUNITS) 36692 If a piece of code is using vector mode VECTOR_MODE and also wants 36693 to operate on elements of mode ELEMENT_MODE, return the vector mode 36694 it should use for those elements. If NUNITS is nonzero, ensure 36695 that the mode has exactly NUNITS elements, otherwise pick whichever 36696 vector size pairs the most naturally with VECTOR_MODE. Return an 36697 empty 'opt_machine_mode' if there is no supported vector mode with 36698 the required properties. 36699 36700 There is no prescribed way of handling the case in which NUNITS is 36701 zero. One common choice is to pick a vector mode with the same 36702 size as VECTOR_MODE; this is the natural choice if the target has a 36703 fixed vector size. Another option is to choose a vector mode with 36704 the same number of elements as VECTOR_MODE; this is the natural 36705 choice if the target has a fixed number of elements. 36706 Alternatively, the hook might choose a middle ground, such as 36707 trying to keep the number of elements as similar as possible while 36708 applying maximum and minimum vector sizes. 36709 36710 The default implementation uses 'mode_for_vector' to find the 36711 requested mode, returning a mode with the same size as VECTOR_MODE 36712 when NUNITS is zero. This is the correct behavior for most 36713 targets. 36714 36715 -- Target Hook: opt_machine_mode TARGET_VECTORIZE_GET_MASK_MODE 36716 (machine_mode MODE) 36717 Return the mode to use for a vector mask that holds one boolean 36718 result for each element of vector mode MODE. The returned mask 36719 mode can be a vector of integers (class 'MODE_VECTOR_INT'), a 36720 vector of booleans (class 'MODE_VECTOR_BOOL') or a scalar integer 36721 (class 'MODE_INT'). Return an empty 'opt_machine_mode' if no such 36722 mask mode exists. 36723 36724 The default implementation returns a 'MODE_VECTOR_INT' with the 36725 same size and number of elements as MODE, if such a mode exists. 36726 36727 -- Target Hook: bool TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE (unsigned 36728 IFN) 36729 This hook returns true if masked internal function IFN (really of 36730 type 'internal_fn') should be considered expensive when the mask is 36731 all zeros. GCC can then try to branch around the instruction 36732 instead. 36733 36734 -- Target Hook: void * TARGET_VECTORIZE_INIT_COST (class loop 36735 *LOOP_INFO) 36736 This hook should initialize target-specific data structures in 36737 preparation for modeling the costs of vectorizing a loop or basic 36738 block. The default allocates three unsigned integers for 36739 accumulating costs for the prologue, body, and epilogue of the loop 36740 or basic block. If LOOP_INFO is non-NULL, it identifies the loop 36741 being vectorized; otherwise a single block is being vectorized. 36742 36743 -- Target Hook: unsigned TARGET_VECTORIZE_ADD_STMT_COST (void *DATA, 36744 int COUNT, enum vect_cost_for_stmt KIND, class _stmt_vec_info 36745 *STMT_INFO, int MISALIGN, enum vect_cost_model_location WHERE) 36746 This hook should update the target-specific DATA in response to 36747 adding COUNT copies of the given KIND of statement to a loop or 36748 basic block. The default adds the builtin vectorizer cost for the 36749 copies of the statement to the accumulator specified by WHERE, (the 36750 prologue, body, or epilogue) and returns the amount added. The 36751 return value should be viewed as a tentative cost that may later be 36752 revised. 36753 36754 -- Target Hook: void TARGET_VECTORIZE_FINISH_COST (void *DATA, unsigned 36755 *PROLOGUE_COST, unsigned *BODY_COST, unsigned *EPILOGUE_COST) 36756 This hook should complete calculations of the cost of vectorizing a 36757 loop or basic block based on DATA, and return the prologue, body, 36758 and epilogue costs as unsigned integers. The default returns the 36759 value of the three accumulators. 36760 36761 -- Target Hook: void TARGET_VECTORIZE_DESTROY_COST_DATA (void *DATA) 36762 This hook should release DATA and any related data structures 36763 allocated by TARGET_VECTORIZE_INIT_COST. The default releases the 36764 accumulator. 36765 36766 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_GATHER (const_tree 36767 MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE) 36768 Target builtin that implements vector gather operation. 36769 MEM_VECTYPE is the vector type of the load and INDEX_TYPE is scalar 36770 type of the index, scaled by SCALE. The default is 'NULL_TREE' 36771 which means to not vectorize gather loads. 36772 36773 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_SCATTER (const_tree 36774 VECTYPE, const_tree INDEX_TYPE, int SCALE) 36775 Target builtin that implements vector scatter operation. VECTYPE 36776 is the vector type of the store and INDEX_TYPE is scalar type of 36777 the index, scaled by SCALE. The default is 'NULL_TREE' which means 36778 to not vectorize scatter stores. 36779 36780 -- Target Hook: int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN 36781 (struct cgraph_node *, struct cgraph_simd_clone *, TREE, INT) 36782 This hook should set VECSIZE_MANGLE, VECSIZE_INT, VECSIZE_FLOAT 36783 fields in SIMD_CLONE structure pointed by CLONE_INFO argument and 36784 also SIMDLEN field if it was previously 0. The hook should return 36785 0 if SIMD clones shouldn't be emitted, or number of VECSIZE_MANGLE 36786 variants that should be emitted. 36787 36788 -- Target Hook: void TARGET_SIMD_CLONE_ADJUST (struct cgraph_node *) 36789 This hook should add implicit 'attribute(target("..."))' attribute 36790 to SIMD clone NODE if needed. 36791 36792 -- Target Hook: int TARGET_SIMD_CLONE_USABLE (struct cgraph_node *) 36793 This hook should return -1 if SIMD clone NODE shouldn't be used in 36794 vectorized loops in current function, or non-negative number if it 36795 is usable. In that case, the smaller the number is, the more 36796 desirable it is to use it. 36797 36798 -- Target Hook: int TARGET_SIMT_VF (void) 36799 Return number of threads in SIMT thread group on the target. 36800 36801 -- Target Hook: int TARGET_OMP_DEVICE_KIND_ARCH_ISA (enum 36802 omp_device_kind_arch_isa TRAIT, const char *NAME) 36803 Return 1 if TRAIT NAME is present in the OpenMP context's device 36804 trait set, return 0 if not present in any OpenMP context in the 36805 whole translation unit, or -1 if not present in the current OpenMP 36806 context but might be present in another OpenMP context in the same 36807 TU. 36808 36809 -- Target Hook: bool TARGET_GOACC_VALIDATE_DIMS (tree DECL, int *DIMS, 36810 int FN_LEVEL, unsigned USED) 36811 This hook should check the launch dimensions provided for an 36812 OpenACC compute region, or routine. Defaulted values are 36813 represented as -1 and non-constant values as 0. The FN_LEVEL is 36814 negative for the function corresponding to the compute region. For 36815 a routine it is the outermost level at which partitioned execution 36816 may be spawned. The hook should verify non-default values. If 36817 DECL is NULL, global defaults are being validated and unspecified 36818 defaults should be filled in. Diagnostics should be issued as 36819 appropriate. Return true, if changes have been made. You must 36820 override this hook to provide dimensions larger than 1. 36821 36822 -- Target Hook: int TARGET_GOACC_DIM_LIMIT (int AXIS) 36823 This hook should return the maximum size of a particular dimension, 36824 or zero if unbounded. 36825 36826 -- Target Hook: bool TARGET_GOACC_FORK_JOIN (gcall *CALL, const int 36827 *DIMS, bool IS_FORK) 36828 This hook can be used to convert IFN_GOACC_FORK and IFN_GOACC_JOIN 36829 function calls to target-specific gimple, or indicate whether they 36830 should be retained. It is executed during the oacc_device_lower 36831 pass. It should return true, if the call should be retained. It 36832 should return false, if it is to be deleted (either because 36833 target-specific gimple has been inserted before it, or there is no 36834 need for it). The default hook returns false, if there are no RTL 36835 expanders for them. 36836 36837 -- Target Hook: void TARGET_GOACC_REDUCTION (gcall *CALL) 36838 This hook is used by the oacc_transform pass to expand calls to the 36839 GOACC_REDUCTION internal function, into a sequence of gimple 36840 instructions. CALL is gimple statement containing the call to the 36841 function. This hook removes statement CALL after the expanded 36842 sequence has been inserted. This hook is also responsible for 36843 allocating any storage for reductions when necessary. 36844 36845 -- Target Hook: tree TARGET_PREFERRED_ELSE_VALUE (unsigned IFN, tree 36846 TYPE, unsigned NOPS, tree *OPS) 36847 This hook returns the target's preferred final argument for a call 36848 to conditional internal function IFN (really of type 36849 'internal_fn'). TYPE specifies the return type of the function and 36850 OPS are the operands to the conditional operation, of which there 36851 are NOPS. 36852 36853 For example, if IFN is 'IFN_COND_ADD', the hook returns a value of 36854 type TYPE that should be used when 'OPS[0]' and 'OPS[1]' are 36855 conditionally added together. 36856 36857 This hook is only relevant if the target supports conditional 36858 patterns like 'cond_addM'. The default implementation returns a 36859 zero constant of type TYPE. 36860 36861 36862File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 36863 3686418.14 Anchored Addresses 36865======================== 36866 36867GCC usually addresses every static object as a separate entity. For 36868example, if we have: 36869 36870 static int a, b, c; 36871 int foo (void) { return a + b + c; } 36872 36873 the code for 'foo' will usually calculate three separate symbolic 36874addresses: those of 'a', 'b' and 'c'. On some targets, it would be 36875better to calculate just one symbolic address and access the three 36876variables relative to it. The equivalent pseudocode would be something 36877like: 36878 36879 int foo (void) 36880 { 36881 register int *xr = &x; 36882 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 36883 } 36884 36885 (which isn't valid C). We refer to shared addresses like 'x' as 36886"section anchors". Their use is controlled by '-fsection-anchors'. 36887 36888 The hooks below describe the target properties that GCC needs to know 36889in order to make effective use of section anchors. It won't use section 36890anchors at all unless either 'TARGET_MIN_ANCHOR_OFFSET' or 36891'TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 36892 36893 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 36894 The minimum offset that should be applied to a section anchor. On 36895 most targets, it should be the smallest offset that can be applied 36896 to a base register while still giving a legitimate address for 36897 every mode. The default value is 0. 36898 36899 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 36900 Like 'TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) offset 36901 that should be applied to section anchors. The default value is 0. 36902 36903 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 36904 Write the assembly code to define section anchor X, which is a 36905 'SYMBOL_REF' for which 'SYMBOL_REF_ANCHOR_P (X)' is true. The hook 36906 is called with the assembly output position set to the beginning of 36907 'SYMBOL_REF_BLOCK (X)'. 36908 36909 If 'ASM_OUTPUT_DEF' is available, the hook's default definition 36910 uses it to define the symbol as '. + SYMBOL_REF_BLOCK_OFFSET (X)'. 36911 If 'ASM_OUTPUT_DEF' is not available, the hook's default definition 36912 is 'NULL', which disables the use of section anchors altogether. 36913 36914 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 36915 Return true if GCC should attempt to use anchors to access 36916 'SYMBOL_REF' X. You can assume 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 36917 and '!SYMBOL_REF_ANCHOR_P (X)'. 36918 36919 The default version is correct for most targets, but you might need 36920 to intercept this hook to handle things like target-specific 36921 attributes or target-specific sections. 36922 36923 36924File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 36925 3692618.15 Condition Code Status 36927=========================== 36928 36929The macros in this section can be split in two families, according to 36930the two ways of representing condition codes in GCC. 36931 36932 The first representation is the so called '(cc0)' representation (*note 36933Jump Patterns::), where all instructions can have an implicit clobber of 36934the condition codes. The second is the condition code register 36935representation, which provides better schedulability for architectures 36936that do have a condition code register, but on which most instructions 36937do not affect it. The latter category includes most RISC machines. 36938 36939 The implicit clobbering poses a strong restriction on the placement of 36940the definition and use of the condition code. In the past the 36941definition and use were always adjacent. However, recent changes to 36942support trapping arithmatic may result in the definition and user being 36943in different blocks. Thus, there may be a 'NOTE_INSN_BASIC_BLOCK' 36944between them. Additionally, the definition may be the source of 36945exception handling edges. 36946 36947 These restrictions can prevent important optimizations on some 36948machines. For example, on the IBM RS/6000, there is a delay for taken 36949branches unless the condition code register is set three instructions 36950earlier than the conditional branch. The instruction scheduler cannot 36951perform this optimization if it is not permitted to separate the 36952definition and use of the condition code register. 36953 36954 For this reason, it is possible and suggested to use a register to 36955represent the condition code for new ports. If there is a specific 36956condition code register in the machine, use a hard register. If the 36957condition code or comparison result can be placed in any general 36958register, or if there are multiple condition registers, use a pseudo 36959register. Registers used to store the condition code value will usually 36960have a mode that is in class 'MODE_CC'. 36961 36962 Alternatively, you can use 'BImode' if the comparison operator is 36963specified already in the compare instruction. In this case, you are not 36964interested in most macros in this section. 36965 36966* Menu: 36967 36968* CC0 Condition Codes:: Old style representation of condition codes. 36969* MODE_CC Condition Codes:: Modern representation of condition codes. 36970 36971 36972File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 36973 3697418.15.1 Representation of condition codes using '(cc0)' 36975------------------------------------------------------- 36976 36977The file 'conditions.h' defines a variable 'cc_status' to describe how 36978the condition code was computed (in case the interpretation of the 36979condition code depends on the instruction that it was set by). This 36980variable contains the RTL expressions on which the condition code is 36981currently based, and several standard flags. 36982 36983 Sometimes additional machine-specific flags must be defined in the 36984machine description header file. It can also add additional 36985machine-specific information by defining 'CC_STATUS_MDEP'. 36986 36987 -- Macro: CC_STATUS_MDEP 36988 C code for a data type which is used for declaring the 'mdep' 36989 component of 'cc_status'. It defaults to 'int'. 36990 36991 This macro is not used on machines that do not use 'cc0'. 36992 36993 -- Macro: CC_STATUS_MDEP_INIT 36994 A C expression to initialize the 'mdep' field to "empty". The 36995 default definition does nothing, since most machines don't use the 36996 field anyway. If you want to use the field, you should probably 36997 define this macro to initialize it. 36998 36999 This macro is not used on machines that do not use 'cc0'. 37000 37001 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 37002 A C compound statement to set the components of 'cc_status' 37003 appropriately for an insn INSN whose body is EXP. It is this 37004 macro's responsibility to recognize insns that set the condition 37005 code as a byproduct of other activity as well as those that 37006 explicitly set '(cc0)'. 37007 37008 This macro is not used on machines that do not use 'cc0'. 37009 37010 If there are insns that do not set the condition code but do alter 37011 other machine registers, this macro must check to see whether they 37012 invalidate the expressions that the condition code is recorded as 37013 reflecting. For example, on the 68000, insns that store in address 37014 registers do not set the condition code, which means that usually 37015 'NOTICE_UPDATE_CC' can leave 'cc_status' unaltered for such insns. 37016 But suppose that the previous insn set the condition code based on 37017 location 'a4@(102)' and the current insn stores a new value in 37018 'a4'. Although the condition code is not changed by this, it will 37019 no longer be true that it reflects the contents of 'a4@(102)'. 37020 Therefore, 'NOTICE_UPDATE_CC' must alter 'cc_status' in this case 37021 to say that nothing is known about the condition code value. 37022 37023 The definition of 'NOTICE_UPDATE_CC' must be prepared to deal with 37024 the results of peephole optimization: insns whose patterns are 37025 'parallel' RTXs containing various 'reg', 'mem' or constants which 37026 are just the operands. The RTL structure of these insns is not 37027 sufficient to indicate what the insns actually do. What 37028 'NOTICE_UPDATE_CC' should do when it sees one is just to run 37029 'CC_STATUS_INIT'. 37030 37031 A possible definition of 'NOTICE_UPDATE_CC' is to call a function 37032 that looks at an attribute (*note Insn Attributes::) named, for 37033 example, 'cc'. This avoids having detailed information about 37034 patterns in two places, the 'md' file and in 'NOTICE_UPDATE_CC'. 37035 37036 37037File: gccint.info, Node: MODE_CC Condition Codes, Prev: CC0 Condition Codes, Up: Condition Code 37038 3703918.15.2 Representation of condition codes using registers 37040--------------------------------------------------------- 37041 37042 -- Macro: SELECT_CC_MODE (OP, X, Y) 37043 On many machines, the condition code may be produced by other 37044 instructions than compares, for example the branch can use directly 37045 the condition code set by a subtract instruction. However, on some 37046 machines when the condition code is set this way some bits (such as 37047 the overflow bit) are not set in the same way as a test 37048 instruction, so that a different branch instruction must be used 37049 for some conditional branches. When this happens, use the machine 37050 mode of the condition code register to record different formats of 37051 the condition code register. Modes can also be used to record 37052 which compare instruction (e.g. a signed or an unsigned comparison) 37053 produced the condition codes. 37054 37055 If other modes than 'CCmode' are required, add them to 37056 'MACHINE-modes.def' and define 'SELECT_CC_MODE' to choose a mode 37057 given an operand of a compare. This is needed because the modes 37058 have to be chosen not only during RTL generation but also, for 37059 example, by instruction combination. The result of 37060 'SELECT_CC_MODE' should be consistent with the mode used in the 37061 patterns; for example to support the case of the add on the SPARC 37062 discussed above, we have the pattern 37063 37064 (define_insn "" 37065 [(set (reg:CCNZ 0) 37066 (compare:CCNZ 37067 (plus:SI (match_operand:SI 0 "register_operand" "%r") 37068 (match_operand:SI 1 "arith_operand" "rI")) 37069 (const_int 0)))] 37070 "" 37071 "...") 37072 37073 together with a 'SELECT_CC_MODE' that returns 'CCNZmode' for 37074 comparisons whose argument is a 'plus': 37075 37076 #define SELECT_CC_MODE(OP,X,Y) \ 37077 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 37078 ? ((OP == LT || OP == LE || OP == GT || OP == GE) \ 37079 ? CCFPEmode : CCFPmode) \ 37080 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 37081 || GET_CODE (X) == NEG || GET_CODE (x) == ASHIFT) \ 37082 ? CCNZmode : CCmode)) 37083 37084 Another reason to use modes is to retain information on which 37085 operands were used by the comparison; see 'REVERSIBLE_CC_MODE' 37086 later in this section. 37087 37088 You should define this macro if and only if you define extra CC 37089 modes in 'MACHINE-modes.def'. 37090 37091 -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx 37092 *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE) 37093 On some machines not all possible comparisons are defined, but you 37094 can convert an invalid comparison into a valid one. For example, 37095 the Alpha does not have a 'GT' comparison, but you can use an 'LT' 37096 comparison instead and swap the order of the operands. 37097 37098 On such machines, implement this hook to do any required 37099 conversions. CODE is the initial comparison code and OP0 and OP1 37100 are the left and right operands of the comparison, respectively. 37101 If OP0_PRESERVE_VALUE is 'true' the implementation is not allowed 37102 to change the value of OP0 since the value might be used in RTXs 37103 which aren't comparisons. E.g. the implementation is not allowed 37104 to swap operands in that case. 37105 37106 GCC will not assume that the comparison resulting from this macro 37107 is valid but will see if the resulting insn matches a pattern in 37108 the 'md' file. 37109 37110 You need not to implement this hook if it would never change the 37111 comparison code or operands. 37112 37113 -- Macro: REVERSIBLE_CC_MODE (MODE) 37114 A C expression whose value is one if it is always safe to reverse a 37115 comparison whose mode is MODE. If 'SELECT_CC_MODE' can ever return 37116 MODE for a floating-point inequality comparison, then 37117 'REVERSIBLE_CC_MODE (MODE)' must be zero. 37118 37119 You need not define this macro if it would always returns zero or 37120 if the floating-point format is anything other than 37121 'IEEE_FLOAT_FORMAT'. For example, here is the definition used on 37122 the SPARC, where floating-point inequality comparisons are given 37123 either 'CCFPEmode' or 'CCFPmode': 37124 37125 #define REVERSIBLE_CC_MODE(MODE) \ 37126 ((MODE) != CCFPEmode && (MODE) != CCFPmode) 37127 37128 -- Macro: REVERSE_CONDITION (CODE, MODE) 37129 A C expression whose value is reversed condition code of the CODE 37130 for comparison done in CC_MODE MODE. The macro is used only in 37131 case 'REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 37132 case machine has some non-standard way how to reverse certain 37133 conditionals. For instance in case all floating point conditions 37134 are non-trapping, compiler may freely convert unordered compares to 37135 ordered ones. Then definition may look like: 37136 37137 #define REVERSE_CONDITION(CODE, MODE) \ 37138 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 37139 : reverse_condition_maybe_unordered (CODE)) 37140 37141 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 37142 *P1, unsigned int *P2) 37143 On targets which do not use '(cc0)', and which use a hard register 37144 rather than a pseudo-register to hold condition codes, the regular 37145 CSE passes are often not able to identify cases in which the hard 37146 register is set to a common value. Use this hook to enable a small 37147 pass which optimizes such cases. This hook should return true to 37148 enable this pass, and it should set the integers to which its 37149 arguments point to the hard register numbers used for condition 37150 codes. When there is only one such register, as is true on most 37151 systems, the integer pointed to by P2 should be set to 37152 'INVALID_REGNUM'. 37153 37154 The default version of this hook returns false. 37155 37156 -- Target Hook: machine_mode TARGET_CC_MODES_COMPATIBLE (machine_mode 37157 M1, machine_mode M2) 37158 On targets which use multiple condition code modes in class 37159 'MODE_CC', it is sometimes the case that a comparison can be 37160 validly done in more than one mode. On such a system, define this 37161 target hook to take two mode arguments and to return a mode in 37162 which both comparisons may be validly done. If there is no such 37163 mode, return 'VOIDmode'. 37164 37165 The default version of this hook checks whether the modes are the 37166 same. If they are, it returns that mode. If they are different, 37167 it returns 'VOIDmode'. 37168 37169 -- Target Hook: unsigned int TARGET_FLAGS_REGNUM 37170 If the target has a dedicated flags register, and it needs to use 37171 the post-reload comparison elimination pass, or the delay slot 37172 filler pass, then this value should be set appropriately. 37173 37174 37175File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 37176 3717718.16 Describing Relative Costs of Operations 37178============================================= 37179 37180These macros let you describe the relative speed of various operations 37181on the target machine. 37182 37183 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 37184 A C expression for the cost of moving data of mode MODE from a 37185 register in class FROM to one in class TO. The classes are 37186 expressed using the enumeration values such as 'GENERAL_REGS'. A 37187 value of 2 is the default; other values are interpreted relative to 37188 that. 37189 37190 It is not required that the cost always equal 2 when FROM is the 37191 same as TO; on some machines it is expensive to move between 37192 registers if they are not general registers. 37193 37194 If reload sees an insn consisting of a single 'set' between two 37195 hard registers, and if 'REGISTER_MOVE_COST' applied to their 37196 classes returns a value of 2, reload does not check to ensure that 37197 the constraints of the insn are met. Setting a cost of other than 37198 2 will allow reload to verify that the constraints are met. You 37199 should do this if the 'movM' pattern's constraints do not allow 37200 such copying. 37201 37202 These macros are obsolete, new ports should use the target hook 37203 'TARGET_REGISTER_MOVE_COST' instead. 37204 37205 -- Target Hook: int TARGET_REGISTER_MOVE_COST (machine_mode MODE, 37206 reg_class_t FROM, reg_class_t TO) 37207 This target hook should return the cost of moving data of mode MODE 37208 from a register in class FROM to one in class TO. The classes are 37209 expressed using the enumeration values such as 'GENERAL_REGS'. A 37210 value of 2 is the default; other values are interpreted relative to 37211 that. 37212 37213 It is not required that the cost always equal 2 when FROM is the 37214 same as TO; on some machines it is expensive to move between 37215 registers if they are not general registers. 37216 37217 If reload sees an insn consisting of a single 'set' between two 37218 hard registers, and if 'TARGET_REGISTER_MOVE_COST' applied to their 37219 classes returns a value of 2, reload does not check to ensure that 37220 the constraints of the insn are met. Setting a cost of other than 37221 2 will allow reload to verify that the constraints are met. You 37222 should do this if the 'movM' pattern's constraints do not allow 37223 such copying. 37224 37225 The default version of this function returns 2. 37226 37227 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 37228 A C expression for the cost of moving data of mode MODE between a 37229 register of class CLASS and memory; IN is zero if the value is to 37230 be written to memory, nonzero if it is to be read in. This cost is 37231 relative to those in 'REGISTER_MOVE_COST'. If moving between 37232 registers and memory is more expensive than between two registers, 37233 you should define this macro to express the relative cost. 37234 37235 If you do not define this macro, GCC uses a default cost of 4 plus 37236 the cost of copying via a secondary reload register, if one is 37237 needed. If your machine requires a secondary reload register to 37238 copy between memory and a register of CLASS but the reload 37239 mechanism is more complex than copying via an intermediate, define 37240 this macro to reflect the actual cost of the move. 37241 37242 GCC defines the function 'memory_move_secondary_cost' if secondary 37243 reloads are needed. It computes the costs due to copying via a 37244 secondary register. If your machine copies from memory using a 37245 secondary register in the conventional way but the default base 37246 value of 4 is not correct for your machine, define this macro to 37247 add some other value to the result of that function. The arguments 37248 to that function are the same as to this macro. 37249 37250 These macros are obsolete, new ports should use the target hook 37251 'TARGET_MEMORY_MOVE_COST' instead. 37252 37253 -- Target Hook: int TARGET_MEMORY_MOVE_COST (machine_mode MODE, 37254 reg_class_t RCLASS, bool IN) 37255 This target hook should return the cost of moving data of mode MODE 37256 between a register of class RCLASS and memory; IN is 'false' if the 37257 value is to be written to memory, 'true' if it is to be read in. 37258 This cost is relative to those in 'TARGET_REGISTER_MOVE_COST'. If 37259 moving between registers and memory is more expensive than between 37260 two registers, you should add this target hook to express the 37261 relative cost. 37262 37263 If you do not add this target hook, GCC uses a default cost of 4 37264 plus the cost of copying via a secondary reload register, if one is 37265 needed. If your machine requires a secondary reload register to 37266 copy between memory and a register of RCLASS but the reload 37267 mechanism is more complex than copying via an intermediate, use 37268 this target hook to reflect the actual cost of the move. 37269 37270 GCC defines the function 'memory_move_secondary_cost' if secondary 37271 reloads are needed. It computes the costs due to copying via a 37272 secondary register. If your machine copies from memory using a 37273 secondary register in the conventional way but the default base 37274 value of 4 is not correct for your machine, use this target hook to 37275 add some other value to the result of that function. The arguments 37276 to that function are the same as to this target hook. 37277 37278 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 37279 A C expression for the cost of a branch instruction. A value of 1 37280 is the default; other values are interpreted relative to that. 37281 Parameter SPEED_P is true when the branch in question should be 37282 optimized for speed. When it is false, 'BRANCH_COST' should return 37283 a value optimal for code size rather than performance. 37284 PREDICTABLE_P is true for well-predicted branches. On many 37285 architectures the 'BRANCH_COST' can be reduced then. 37286 37287 Here are additional macros which do not specify precise relative costs, 37288but only that certain actions are more expensive than GCC would 37289ordinarily expect. 37290 37291 -- Macro: SLOW_BYTE_ACCESS 37292 Define this macro as a C expression which is nonzero if accessing 37293 less than a word of memory (i.e. a 'char' or a 'short') is no 37294 faster than accessing a word of memory, i.e., if such access 37295 require more than one instruction or if there is no difference in 37296 cost between byte and (aligned) word loads. 37297 37298 When this macro is not defined, the compiler will access a field by 37299 finding the smallest containing object; when it is defined, a 37300 fullword load will be used if alignment permits. Unless bytes 37301 accesses are faster than word accesses, using word accesses is 37302 preferable since it may eliminate subsequent memory access if 37303 subsequent accesses occur to other fields in the same word of the 37304 structure, but to different bytes. 37305 37306 -- Target Hook: bool TARGET_SLOW_UNALIGNED_ACCESS (machine_mode MODE, 37307 unsigned int ALIGN) 37308 This hook returns true if memory accesses described by the MODE and 37309 ALIGNMENT parameters have a cost many times greater than aligned 37310 accesses, for example if they are emulated in a trap handler. This 37311 hook is invoked only for unaligned accesses, i.e. when 'ALIGNMENT < 37312 GET_MODE_ALIGNMENT (MODE)'. 37313 37314 When this hook returns true, the compiler will act as if 37315 'STRICT_ALIGNMENT' were true when generating code for block moves. 37316 This can cause significantly more instructions to be produced. 37317 Therefore, do not make this hook return true if unaligned accesses 37318 only add a cycle or two to the time for a memory access. 37319 37320 The hook must return true whenever 'STRICT_ALIGNMENT' is true. The 37321 default implementation returns 'STRICT_ALIGNMENT'. 37322 37323 -- Macro: MOVE_RATIO (SPEED) 37324 The threshold of number of scalar memory-to-memory move insns, 37325 _below_ which a sequence of insns should be generated instead of a 37326 string move insn or a library call. Increasing the value will 37327 always make code faster, but eventually incurs high cost in 37328 increased code size. 37329 37330 Note that on machines where the corresponding move insn is a 37331 'define_expand' that emits a sequence of insns, this macro counts 37332 the number of such sequences. 37333 37334 The parameter SPEED is true if the code is currently being 37335 optimized for speed rather than size. 37336 37337 If you don't define this, a reasonable default is used. 37338 37339 -- Target Hook: bool TARGET_USE_BY_PIECES_INFRASTRUCTURE_P (unsigned 37340 HOST_WIDE_INT SIZE, unsigned int ALIGNMENT, enum 37341 by_pieces_operation OP, bool SPEED_P) 37342 GCC will attempt several strategies when asked to copy between two 37343 areas of memory, or to set, clear or store to memory, for example 37344 when copying a 'struct'. The 'by_pieces' infrastructure implements 37345 such memory operations as a sequence of load, store or move insns. 37346 Alternate strategies are to expand the 'cpymem' or 'setmem' optabs, 37347 to emit a library call, or to emit unit-by-unit, loop-based 37348 operations. 37349 37350 This target hook should return true if, for a memory operation with 37351 a given SIZE and ALIGNMENT, using the 'by_pieces' infrastructure is 37352 expected to result in better code generation. Both SIZE and 37353 ALIGNMENT are measured in terms of storage units. 37354 37355 The parameter OP is one of: 'CLEAR_BY_PIECES', 'MOVE_BY_PIECES', 37356 'SET_BY_PIECES', 'STORE_BY_PIECES' or 'COMPARE_BY_PIECES'. These 37357 describe the type of memory operation under consideration. 37358 37359 The parameter SPEED_P is true if the code is currently being 37360 optimized for speed rather than size. 37361 37362 Returning true for higher values of SIZE can improve code 37363 generation for speed if the target does not provide an 37364 implementation of the 'cpymem' or 'setmem' standard names, if the 37365 'cpymem' or 'setmem' implementation would be more expensive than a 37366 sequence of insns, or if the overhead of a library call would 37367 dominate that of the body of the memory operation. 37368 37369 Returning true for higher values of 'size' may also cause an 37370 increase in code size, for example where the number of insns 37371 emitted to perform a move would be greater than that of a library 37372 call. 37373 37374 -- Target Hook: int TARGET_COMPARE_BY_PIECES_BRANCH_RATIO (machine_mode 37375 MODE) 37376 When expanding a block comparison in MODE, gcc can try to reduce 37377 the number of branches at the expense of more memory operations. 37378 This hook allows the target to override the default choice. It 37379 should return the factor by which branches should be reduced over 37380 the plain expansion with one comparison per MODE-sized piece. A 37381 port can also prevent a particular mode from being used for block 37382 comparisons by returning a negative number from this hook. 37383 37384 -- Macro: MOVE_MAX_PIECES 37385 A C expression used by 'move_by_pieces' to determine the largest 37386 unit a load or store used to copy memory is. Defaults to 37387 'MOVE_MAX'. 37388 37389 -- Macro: STORE_MAX_PIECES 37390 A C expression used by 'store_by_pieces' to determine the largest 37391 unit a store used to memory is. Defaults to 'MOVE_MAX_PIECES', or 37392 two times the size of 'HOST_WIDE_INT', whichever is smaller. 37393 37394 -- Macro: COMPARE_MAX_PIECES 37395 A C expression used by 'compare_by_pieces' to determine the largest 37396 unit a load or store used to compare memory is. Defaults to 37397 'MOVE_MAX_PIECES'. 37398 37399 -- Macro: CLEAR_RATIO (SPEED) 37400 The threshold of number of scalar move insns, _below_ which a 37401 sequence of insns should be generated to clear memory instead of a 37402 string clear insn or a library call. Increasing the value will 37403 always make code faster, but eventually incurs high cost in 37404 increased code size. 37405 37406 The parameter SPEED is true if the code is currently being 37407 optimized for speed rather than size. 37408 37409 If you don't define this, a reasonable default is used. 37410 37411 -- Macro: SET_RATIO (SPEED) 37412 The threshold of number of scalar move insns, _below_ which a 37413 sequence of insns should be generated to set memory to a constant 37414 value, instead of a block set insn or a library call. Increasing 37415 the value will always make code faster, but eventually incurs high 37416 cost in increased code size. 37417 37418 The parameter SPEED is true if the code is currently being 37419 optimized for speed rather than size. 37420 37421 If you don't define this, it defaults to the value of 'MOVE_RATIO'. 37422 37423 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 37424 A C expression used to determine whether a load postincrement is a 37425 good thing to use for a given mode. Defaults to the value of 37426 'HAVE_POST_INCREMENT'. 37427 37428 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 37429 A C expression used to determine whether a load postdecrement is a 37430 good thing to use for a given mode. Defaults to the value of 37431 'HAVE_POST_DECREMENT'. 37432 37433 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 37434 A C expression used to determine whether a load preincrement is a 37435 good thing to use for a given mode. Defaults to the value of 37436 'HAVE_PRE_INCREMENT'. 37437 37438 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 37439 A C expression used to determine whether a load predecrement is a 37440 good thing to use for a given mode. Defaults to the value of 37441 'HAVE_PRE_DECREMENT'. 37442 37443 -- Macro: USE_STORE_POST_INCREMENT (MODE) 37444 A C expression used to determine whether a store postincrement is a 37445 good thing to use for a given mode. Defaults to the value of 37446 'HAVE_POST_INCREMENT'. 37447 37448 -- Macro: USE_STORE_POST_DECREMENT (MODE) 37449 A C expression used to determine whether a store postdecrement is a 37450 good thing to use for a given mode. Defaults to the value of 37451 'HAVE_POST_DECREMENT'. 37452 37453 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 37454 This macro is used to determine whether a store preincrement is a 37455 good thing to use for a given mode. Defaults to the value of 37456 'HAVE_PRE_INCREMENT'. 37457 37458 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 37459 This macro is used to determine whether a store predecrement is a 37460 good thing to use for a given mode. Defaults to the value of 37461 'HAVE_PRE_DECREMENT'. 37462 37463 -- Macro: NO_FUNCTION_CSE 37464 Define this macro to be true if it is as good or better to call a 37465 constant function address than to call an address kept in a 37466 register. 37467 37468 -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT 37469 Define this macro if a non-short-circuit operation produced by 37470 'fold_range_test ()' is optimal. This macro defaults to true if 37471 'BRANCH_COST' is greater than or equal to the value 2. 37472 37473 -- Target Hook: bool TARGET_OPTAB_SUPPORTED_P (int OP, machine_mode 37474 MODE1, machine_mode MODE2, optimization_type OPT_TYPE) 37475 Return true if the optimizers should use optab OP with modes MODE1 37476 and MODE2 for optimization type OPT_TYPE. The optab is known to 37477 have an associated '.md' instruction whose C condition is true. 37478 MODE2 is only meaningful for conversion optabs; for direct optabs 37479 it is a copy of MODE1. 37480 37481 For example, when called with OP equal to 'rint_optab' and MODE1 37482 equal to 'DFmode', the hook should say whether the optimizers 37483 should use optab 'rintdf2'. 37484 37485 The default hook returns true for all inputs. 37486 37487 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, machine_mode MODE, int 37488 OUTER_CODE, int OPNO, int *TOTAL, bool SPEED) 37489 This target hook describes the relative costs of RTL expressions. 37490 37491 The cost may depend on the precise form of the expression, which is 37492 available for examination in X, and the fact that X appears as 37493 operand OPNO of an expression with rtx code OUTER_CODE. That is, 37494 the hook can assume that there is some rtx Y such that 'GET_CODE 37495 (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X' 37496 or (b) 'XVEC (Y, OPNO)' contains X. 37497 37498 MODE is X's machine mode, or for cases like 'const_int' that do not 37499 have a mode, the mode in which X is used. 37500 37501 In implementing this hook, you can use the construct 'COSTS_N_INSNS 37502 (N)' to specify a cost equal to N fast instructions. 37503 37504 On entry to the hook, '*TOTAL' contains a default estimate for the 37505 cost of the expression. The hook should modify this value as 37506 necessary. Traditionally, the default costs are 'COSTS_N_INSNS 37507 (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and 37508 modulus operations, and 'COSTS_N_INSNS (1)' for all other 37509 operations. 37510 37511 When optimizing for code size, i.e. when 'speed' is false, this 37512 target hook should be used to estimate the relative size cost of an 37513 expression, again relative to 'COSTS_N_INSNS'. 37514 37515 The hook returns true when all subexpressions of X have been 37516 processed, and false when 'rtx_cost' should recurse. 37517 37518 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, machine_mode 37519 MODE, addr_space_t AS, bool SPEED) 37520 This hook computes the cost of an addressing mode that contains 37521 ADDRESS. If not defined, the cost is computed from the ADDRESS 37522 expression and the 'TARGET_RTX_COST' hook. 37523 37524 For most CISC machines, the default cost is a good approximation of 37525 the true cost of the addressing mode. However, on RISC machines, 37526 all instructions normally have the same length and execution time. 37527 Hence all addresses will have equal costs. 37528 37529 In cases where more than one form of an address is known, the form 37530 with the lowest cost will be used. If multiple forms have the 37531 same, lowest, cost, the one that is the most complex will be used. 37532 37533 For example, suppose an address that is equal to the sum of a 37534 register and a constant is used twice in the same basic block. 37535 When this macro is not defined, the address will be computed in a 37536 register and memory references will be indirect through that 37537 register. On machines where the cost of the addressing mode 37538 containing the sum is no higher than that of a simple indirect 37539 reference, this will produce an additional instruction and possibly 37540 require an additional register. Proper specification of this macro 37541 eliminates this overhead for such machines. 37542 37543 This hook is never called with an invalid address. 37544 37545 On machines where an address involving more than one register is as 37546 cheap as an address computation involving only one register, 37547 defining 'TARGET_ADDRESS_COST' to reflect this can cause two 37548 registers to be live over a region of code where only one would 37549 have been if 'TARGET_ADDRESS_COST' were not defined in that manner. 37550 This effect should be considered in the definition of this macro. 37551 Equivalent costs should probably only be given to addresses with 37552 different numbers of registers on machines with lots of registers. 37553 37554 -- Target Hook: int TARGET_INSN_COST (rtx_insn *INSN, bool SPEED) 37555 This target hook describes the relative costs of RTL instructions. 37556 37557 In implementing this hook, you can use the construct 'COSTS_N_INSNS 37558 (N)' to specify a cost equal to N fast instructions. 37559 37560 When optimizing for code size, i.e. when 'speed' is false, this 37561 target hook should be used to estimate the relative size cost of an 37562 expression, again relative to 'COSTS_N_INSNS'. 37563 37564 -- Target Hook: unsigned int TARGET_MAX_NOCE_IFCVT_SEQ_COST (edge E) 37565 This hook returns a value in the same units as 'TARGET_RTX_COSTS', 37566 giving the maximum acceptable cost for a sequence generated by the 37567 RTL if-conversion pass when conditional execution is not available. 37568 The RTL if-conversion pass attempts to convert conditional 37569 operations that would require a branch to a series of unconditional 37570 operations and 'movMODEcc' insns. This hook returns the maximum 37571 cost of the unconditional instructions and the 'movMODEcc' insns. 37572 RTL if-conversion is cancelled if the cost of the converted 37573 sequence is greater than the value returned by this hook. 37574 37575 'e' is the edge between the basic block containing the conditional 37576 branch to the basic block which would be executed if the condition 37577 were true. 37578 37579 The default implementation of this hook uses the 37580 'max-rtl-if-conversion-[un]predictable' parameters if they are set, 37581 and uses a multiple of 'BRANCH_COST' otherwise. 37582 37583 -- Target Hook: bool TARGET_NOCE_CONVERSION_PROFITABLE_P (rtx_insn 37584 *SEQ, struct noce_if_info *IF_INFO) 37585 This hook returns true if the instruction sequence 'seq' is a good 37586 candidate as a replacement for the if-convertible sequence 37587 described in 'if_info'. 37588 37589 -- Target Hook: bool TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P (void) 37590 This predicate controls the use of the eager delay slot filler to 37591 disallow speculatively executed instructions being placed in delay 37592 slots. Targets such as certain MIPS architectures possess both 37593 branches with and without delay slots. As the eager delay slot 37594 filler can decrease performance, disabling it is beneficial when 37595 ordinary branches are available. Use of delay slot branches filled 37596 using the basic filler is often still desirable as the delay slot 37597 can hide a pipeline bubble. 37598 37599 -- Target Hook: HOST_WIDE_INT TARGET_ESTIMATED_POLY_VALUE (poly_int64 37600 VAL) 37601 Return an estimate of the runtime value of VAL, for use in things 37602 like cost calculations or profiling frequencies. The default 37603 implementation returns the lowest possible value of VAL. 37604 37605 37606File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 37607 3760818.17 Adjusting the Instruction Scheduler 37609========================================= 37610 37611The instruction scheduler may need a fair amount of machine-specific 37612adjustment in order to produce good code. GCC provides several target 37613hooks for this purpose. It is usually enough to define just a few of 37614them: try the first ones in this list first. 37615 37616 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 37617 This hook returns the maximum number of instructions that can ever 37618 issue at the same time on the target machine. The default is one. 37619 Although the insn scheduler can define itself the possibility of 37620 issue an insn on the same cycle, the value can serve as an 37621 additional constraint to issue insns on the same simulated 37622 processor cycle (see hooks 'TARGET_SCHED_REORDER' and 37623 'TARGET_SCHED_REORDER2'). This value must be constant over the 37624 entire compilation. If you need it to vary depending on what the 37625 instructions are, you must use 'TARGET_SCHED_VARIABLE_ISSUE'. 37626 37627 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 37628 VERBOSE, rtx_insn *INSN, int MORE) 37629 This hook is executed by the scheduler after it has scheduled an 37630 insn from the ready list. It should return the number of insns 37631 which can still be issued in the current cycle. The default is 37632 'MORE - 1' for insns other than 'CLOBBER' and 'USE', which normally 37633 are not counted against the issue rate. You should define this 37634 hook if some insns take more machine resources than others, so that 37635 fewer insns can follow them in the same cycle. FILE is either a 37636 null pointer, or a stdio stream to write any debug output to. 37637 VERBOSE is the verbose level provided by '-fsched-verbose-N'. INSN 37638 is the instruction that was scheduled. 37639 37640 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx_insn *INSN, int 37641 DEP_TYPE1, rtx_insn *DEP_INSN, int COST, unsigned int DW) 37642 This function corrects the value of COST based on the relationship 37643 between INSN and DEP_INSN through a dependence of type dep_type, 37644 and strength DW. It should return the new value. The default is 37645 to make no adjustment to COST. This can be used for example to 37646 specify to the scheduler using the traditional pipeline description 37647 that an output- or anti-dependence does not incur the same cost as 37648 a data-dependence. If the scheduler using the automaton based 37649 pipeline description, the cost of anti-dependence is zero and the 37650 cost of output-dependence is maximum of one and the difference of 37651 latency times of the first and the second insns. If these values 37652 are not acceptable, you could use the hook to modify them too. See 37653 also *note Processor pipeline description::. 37654 37655 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx_insn *INSN, int 37656 PRIORITY) 37657 This hook adjusts the integer scheduling priority PRIORITY of INSN. 37658 It should return the new priority. Increase the priority to 37659 execute INSN earlier, reduce the priority to execute INSN later. 37660 Do not define this hook if you do not need to adjust the scheduling 37661 priorities of insns. 37662 37663 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, 37664 rtx_insn **READY, int *N_READYP, int CLOCK) 37665 This hook is executed by the scheduler after it has scheduled the 37666 ready list, to allow the machine description to reorder it (for 37667 example to combine two small instructions together on 'VLIW' 37668 machines). FILE is either a null pointer, or a stdio stream to 37669 write any debug output to. VERBOSE is the verbose level provided 37670 by '-fsched-verbose-N'. READY is a pointer to the ready list of 37671 instructions that are ready to be scheduled. N_READYP is a pointer 37672 to the number of elements in the ready list. The scheduler reads 37673 the ready list in reverse order, starting with READY[*N_READYP - 1] 37674 and going to READY[0]. CLOCK is the timer tick of the scheduler. 37675 You may modify the ready list and the number of ready insns. The 37676 return value is the number of insns that can issue this cycle; 37677 normally this is just 'issue_rate'. See also 37678 'TARGET_SCHED_REORDER2'. 37679 37680 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 37681 rtx_insn **READY, int *N_READYP, int CLOCK) 37682 Like 'TARGET_SCHED_REORDER', but called at a different time. That 37683 function is called whenever the scheduler starts a new cycle. This 37684 one is called once per iteration over a cycle, immediately after 37685 'TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list and 37686 return the number of insns to be scheduled in the same cycle. 37687 Defining this hook can be useful if there are frequent situations 37688 where scheduling one insn causes other insns to become ready in the 37689 same cycle. These other insns can then be taken into account 37690 properly. 37691 37692 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_P (void) 37693 This hook is used to check whether target platform supports macro 37694 fusion. 37695 37696 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_PAIR_P (rtx_insn *PREV, 37697 rtx_insn *CURR) 37698 This hook is used to check whether two insns should be macro fused 37699 for a target microarchitecture. If this hook returns true for the 37700 given insn pair (PREV and CURR), the scheduler will put them into a 37701 sched group, and they will not be scheduled apart. The two insns 37702 will be either two SET insns or a compare and a conditional jump 37703 and this hook should validate any dependencies needed to fuse the 37704 two insns together. 37705 37706 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK 37707 (rtx_insn *HEAD, rtx_insn *TAIL) 37708 This hook is called after evaluation forward dependencies of insns 37709 in chain given by two parameter values (HEAD and TAIL 37710 correspondingly) but before insns scheduling of the insn chain. 37711 For example, it can be used for better insn classification if it 37712 requires analysis of dependencies. This hook can use backward and 37713 forward dependencies of the insn scheduler because they are already 37714 calculated. 37715 37716 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 37717 MAX_READY) 37718 This hook is executed by the scheduler at the beginning of each 37719 block of instructions that are to be scheduled. FILE is either a 37720 null pointer, or a stdio stream to write any debug output to. 37721 VERBOSE is the verbose level provided by '-fsched-verbose-N'. 37722 MAX_READY is the maximum number of insns in the current scheduling 37723 region that can be live at the same time. This can be used to 37724 allocate scratch space if it is needed, e.g. by 37725 'TARGET_SCHED_REORDER'. 37726 37727 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 37728 This hook is executed by the scheduler at the end of each block of 37729 instructions that are to be scheduled. It can be used to perform 37730 cleanup of any actions done by the other scheduling hooks. FILE is 37731 either a null pointer, or a stdio stream to write any debug output 37732 to. VERBOSE is the verbose level provided by '-fsched-verbose-N'. 37733 37734 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int VERBOSE, 37735 int OLD_MAX_UID) 37736 This hook is executed by the scheduler after function level 37737 initializations. FILE is either a null pointer, or a stdio stream 37738 to write any debug output to. VERBOSE is the verbose level 37739 provided by '-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 37740 uid when scheduling begins. 37741 37742 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 37743 VERBOSE) 37744 This is the cleanup hook corresponding to 37745 'TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 37746 stdio stream to write any debug output to. VERBOSE is the verbose 37747 level provided by '-fsched-verbose-N'. 37748 37749 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 37750 The hook returns an RTL insn. The automaton state used in the 37751 pipeline hazard recognizer is changed as if the insn were scheduled 37752 when the new simulated processor cycle starts. Usage of the hook 37753 may simplify the automaton pipeline description for some VLIW 37754 processors. If the hook is defined, it is used only for the 37755 automaton based pipeline description. The default is not to change 37756 the state when the new simulated processor cycle starts. 37757 37758 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 37759 The hook can be used to initialize data used by the previous hook. 37760 37761 -- Target Hook: rtx_insn * TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 37762 The hook is analogous to 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 37763 to changed the state as if the insn were scheduled when the new 37764 simulated processor cycle finishes. 37765 37766 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 37767 The hook is analogous to 'TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 37768 used to initialize data used by the previous hook. 37769 37770 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 37771 The hook to notify target that the current simulated cycle is about 37772 to finish. The hook is analogous to 37773 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 37774 more complicated situations - e.g., when advancing state on a 37775 single insn is not enough. 37776 37777 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 37778 The hook to notify target that new simulated cycle has just 37779 started. The hook is analogous to 37780 'TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 37781 more complicated situations - e.g., when advancing state on a 37782 single insn is not enough. 37783 37784 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 37785 (void) 37786 This hook controls better choosing an insn from the ready insn 37787 queue for the DFA-based insn scheduler. Usually the scheduler 37788 chooses the first insn from the queue. If the hook returns a 37789 positive value, an additional scheduler code tries all permutations 37790 of 'TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD ()' subsequent 37791 ready insns to choose an insn whose issue will result in maximal 37792 number of issued insns on the same cycle. For the VLIW processor, 37793 the code could actually solve the problem of packing simple insns 37794 into the VLIW insn. Of course, if the rules of VLIW packing are 37795 described in the automaton. 37796 37797 This code also could be used for superscalar RISC processors. Let 37798 us consider a superscalar RISC processor with 3 pipelines. Some 37799 insns can be executed in pipelines A or B, some insns can be 37800 executed only in pipelines B or C, and one insn can be executed in 37801 pipeline B. The processor may issue the 1st insn into A and the 37802 2nd one into B. In this case, the 3rd insn will wait for freeing B 37803 until the next cycle. If the scheduler issues the 3rd insn the 37804 first, the processor could issue all 3 insns per cycle. 37805 37806 Actually this code demonstrates advantages of the automaton based 37807 pipeline hazard recognizer. We try quickly and easy many insn 37808 schedules to choose the best one. 37809 37810 The default is no multipass scheduling. 37811 37812 -- Target Hook: int 37813 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD 37814 (rtx_insn *INSN, int READY_INDEX) 37815 37816 This hook controls what insns from the ready insn queue will be 37817 considered for the multipass insn scheduling. If the hook returns 37818 zero for INSN, the insn will be considered in multipass scheduling. 37819 Positive return values will remove INSN from consideration on the 37820 current round of multipass scheduling. Negative return values will 37821 remove INSN from consideration for given number of cycles. 37822 Backends should be careful about returning non-zero for highest 37823 priority instruction at position 0 in the ready list. READY_INDEX 37824 is passed to allow backends make correct judgements. 37825 37826 The default is that any ready insns can be chosen to be issued. 37827 37828 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void 37829 *DATA, signed char *READY_TRY, int N_READY, bool 37830 FIRST_CYCLE_INSN_P) 37831 This hook prepares the target backend for a new round of multipass 37832 scheduling. 37833 37834 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void 37835 *DATA, signed char *READY_TRY, int N_READY, rtx_insn *INSN, 37836 const void *PREV_DATA) 37837 This hook is called when multipass scheduling evaluates instruction 37838 INSN. 37839 37840 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK 37841 (const void *DATA, signed char *READY_TRY, int N_READY) 37842 This is called when multipass scheduling backtracks from evaluation 37843 of an instruction. 37844 37845 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const void 37846 *DATA) 37847 This hook notifies the target about the result of the concluded 37848 current round of multipass scheduling. 37849 37850 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void 37851 *DATA) 37852 This hook initializes target-specific data used in multipass 37853 scheduling. 37854 37855 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void 37856 *DATA) 37857 This hook finalizes target-specific data used in multipass 37858 scheduling. 37859 37860 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 37861 VERBOSE, rtx_insn *INSN, int LAST_CLOCK, int CLOCK, int 37862 *SORT_P) 37863 This hook is called by the insn scheduler before issuing INSN on 37864 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 37865 this processor cycle. Instead, the processor cycle is advanced. 37866 If *SORT_P is zero, the insn ready queue is not sorted on the new 37867 cycle start as usually. DUMP and VERBOSE specify the file and 37868 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 37869 are, respectively, the processor cycle on which the previous insn 37870 has been issued, and the current processor cycle. 37871 37872 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 37873 *_DEP, int COST, int DISTANCE) 37874 This hook is used to define which dependences are considered costly 37875 by the target, so costly that it is not advisable to schedule the 37876 insns that are involved in the dependence too close to one another. 37877 The parameters to this hook are as follows: The first parameter 37878 _DEP is the dependence being evaluated. The second parameter COST 37879 is the cost of the dependence as estimated by the scheduler, and 37880 the third parameter DISTANCE is the distance in cycles between the 37881 two insns. The hook returns 'true' if considering the distance 37882 between the two insns the dependence between them is considered 37883 costly by the target, and 'false' otherwise. 37884 37885 Defining this hook can be useful in multiple-issue out-of-order 37886 machines, where (a) it's practically hopeless to predict the actual 37887 data/resource delays, however: (b) there's a better chance to 37888 predict the actual grouping that will be formed, and (c) correctly 37889 emulating the grouping can be very important. In such targets one 37890 may want to allow issuing dependent insns closer to one 37891 another--i.e., closer than the dependence distance; however, not in 37892 cases of "costly dependences", which this hooks allows to define. 37893 37894 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 37895 This hook is called by the insn scheduler after emitting a new 37896 instruction to the instruction stream. The hook notifies a target 37897 backend to extend its per instruction data structures. 37898 37899 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 37900 Return a pointer to a store large enough to hold target scheduling 37901 context. 37902 37903 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 37904 CLEAN_P) 37905 Initialize store pointed to by TC to hold target scheduling 37906 context. It CLEAN_P is true then initialize TC as if scheduler is 37907 at the beginning of the block. Otherwise, copy the current context 37908 into TC. 37909 37910 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 37911 Copy target scheduling context pointed to by TC to the current 37912 context. 37913 37914 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 37915 Deallocate internal data in target scheduling context pointed to by 37916 TC. 37917 37918 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 37919 Deallocate a store for target scheduling context pointed to by TC. 37920 37921 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx_insn *INSN, 37922 unsigned int DEP_STATUS, rtx *NEW_PAT) 37923 This hook is called by the insn scheduler when INSN has only 37924 speculative dependencies and therefore can be scheduled 37925 speculatively. The hook is used to check if the pattern of INSN 37926 has a speculative version and, in case of successful check, to 37927 generate that speculative pattern. The hook should return 1, if 37928 the instruction has a speculative form, or -1, if it doesn't. 37929 REQUEST describes the type of requested speculation. If the return 37930 value equals 1 then NEW_PAT is assigned the generated speculative 37931 pattern. 37932 37933 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (unsigned int 37934 DEP_STATUS) 37935 This hook is called by the insn scheduler during generation of 37936 recovery code for INSN. It should return 'true', if the 37937 corresponding check instruction should branch to recovery code, or 37938 'false' otherwise. 37939 37940 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx_insn *INSN, 37941 rtx_insn *LABEL, unsigned int DS) 37942 This hook is called by the insn scheduler to generate a pattern for 37943 recovery check instruction. If MUTATE_P is zero, then INSN is a 37944 speculative instruction for which the check should be generated. 37945 LABEL is either a label of a basic block, where recovery code 37946 should be emitted, or a null pointer, when requested check doesn't 37947 branch to recovery code (a simple check). If MUTATE_P is nonzero, 37948 then a pattern for a branchy check corresponding to a simple check 37949 denoted by INSN should be generated. In this case LABEL can't be 37950 null. 37951 37952 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct spec_info_def 37953 *SPEC_INFO) 37954 This hook is used by the insn scheduler to find out what features 37955 should be enabled/used. The structure *SPEC_INFO should be filled 37956 in by the target. The structure describes speculation types that 37957 can be used in the scheduler. 37958 37959 -- Target Hook: bool TARGET_SCHED_CAN_SPECULATE_INSN (rtx_insn *INSN) 37960 Some instructions should never be speculated by the schedulers, 37961 usually because the instruction is too expensive to get this wrong. 37962 Often such instructions have long latency, and often they are not 37963 fully modeled in the pipeline descriptions. This hook should 37964 return 'false' if INSN should not be speculated. 37965 37966 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 37967 This hook is called by the swing modulo scheduler to calculate a 37968 resource-based lower bound which is based on the resources 37969 available in the machine and the resources required by each 37970 instruction. The target backend can use G to calculate such bound. 37971 A very simple lower bound will be used in case this hook is not 37972 implemented: the total number of instructions divided by the issue 37973 rate. 37974 37975 -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx_insn *INSN, int X) 37976 This hook is called by Haifa Scheduler. It returns true if 37977 dispatch scheduling is supported in hardware and the condition 37978 specified in the parameter is true. 37979 37980 -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx_insn *INSN, int X) 37981 This hook is called by Haifa Scheduler. It performs the operation 37982 specified in its second parameter. 37983 37984 -- Target Hook: bool TARGET_SCHED_EXPOSED_PIPELINE 37985 True if the processor has an exposed pipeline, which means that not 37986 just the order of instructions is important for correctness when 37987 scheduling, but also the latencies of operations. 37988 37989 -- Target Hook: int TARGET_SCHED_REASSOCIATION_WIDTH (unsigned int OPC, 37990 machine_mode MODE) 37991 This hook is called by tree reassociator to determine a level of 37992 parallelism required in output calculations chain. 37993 37994 -- Target Hook: void TARGET_SCHED_FUSION_PRIORITY (rtx_insn *INSN, int 37995 MAX_PRI, int *FUSION_PRI, int *PRI) 37996 This hook is called by scheduling fusion pass. It calculates 37997 fusion priorities for each instruction passed in by parameter. The 37998 priorities are returned via pointer parameters. 37999 38000 INSN is the instruction whose priorities need to be calculated. 38001 MAX_PRI is the maximum priority can be returned in any cases. 38002 FUSION_PRI is the pointer parameter through which INSN's fusion 38003 priority should be calculated and returned. PRI is the pointer 38004 parameter through which INSN's priority should be calculated and 38005 returned. 38006 38007 Same FUSION_PRI should be returned for instructions which should be 38008 scheduled together. Different PRI should be returned for 38009 instructions with same FUSION_PRI. FUSION_PRI is the major sort 38010 key, PRI is the minor sort key. All instructions will be scheduled 38011 according to the two priorities. All priorities calculated should 38012 be between 0 (exclusive) and MAX_PRI (inclusive). To avoid false 38013 dependencies, FUSION_PRI of instructions which need to be scheduled 38014 together should be smaller than FUSION_PRI of irrelevant 38015 instructions. 38016 38017 Given below example: 38018 38019 ldr r10, [r1, 4] 38020 add r4, r4, r10 38021 ldr r15, [r2, 8] 38022 sub r5, r5, r15 38023 ldr r11, [r1, 0] 38024 add r4, r4, r11 38025 ldr r16, [r2, 12] 38026 sub r5, r5, r16 38027 38028 On targets like ARM/AArch64, the two pairs of consecutive loads 38029 should be merged. Since peephole2 pass can't help in this case 38030 unless consecutive loads are actually next to each other in 38031 instruction flow. That's where this scheduling fusion pass works. 38032 This hook calculates priority for each instruction based on its 38033 fustion type, like: 38034 38035 ldr r10, [r1, 4] ; fusion_pri=99, pri=96 38036 add r4, r4, r10 ; fusion_pri=100, pri=100 38037 ldr r15, [r2, 8] ; fusion_pri=98, pri=92 38038 sub r5, r5, r15 ; fusion_pri=100, pri=100 38039 ldr r11, [r1, 0] ; fusion_pri=99, pri=100 38040 add r4, r4, r11 ; fusion_pri=100, pri=100 38041 ldr r16, [r2, 12] ; fusion_pri=98, pri=88 38042 sub r5, r5, r16 ; fusion_pri=100, pri=100 38043 38044 Scheduling fusion pass then sorts all ready to issue instructions 38045 according to the priorities. As a result, instructions of same 38046 fusion type will be pushed together in instruction flow, like: 38047 38048 ldr r11, [r1, 0] 38049 ldr r10, [r1, 4] 38050 ldr r15, [r2, 8] 38051 ldr r16, [r2, 12] 38052 add r4, r4, r10 38053 sub r5, r5, r15 38054 add r4, r4, r11 38055 sub r5, r5, r16 38056 38057 Now peephole2 pass can simply merge the two pairs of loads. 38058 38059 Since scheduling fusion pass relies on peephole2 to do real fusion 38060 work, it is only enabled by default when peephole2 is in effect. 38061 38062 This is firstly introduced on ARM/AArch64 targets, please refer to 38063 the hook implementation for how different fusion types are 38064 supported. 38065 38066 -- Target Hook: void TARGET_EXPAND_DIVMOD_LIBFUNC (rtx LIBFUNC, 38067 machine_mode MODE, rtx OP0, rtx OP1, rtx *QUOT, rtx *REM) 38068 Define this hook for enabling divmod transform if the port does not 38069 have hardware divmod insn but defines target-specific divmod 38070 libfuncs. 38071 38072 38073File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 38074 3807518.18 Dividing the Output into Sections (Texts, Data, ...) 38076========================================================== 38077 38078An object file is divided into sections containing different types of 38079data. In the most common case, there are three sections: the "text 38080section", which holds instructions and read-only data; the "data 38081section", which holds initialized writable data; and the "bss section", 38082which holds uninitialized data. Some systems have other kinds of 38083sections. 38084 38085 'varasm.c' provides several well-known sections, such as 38086'text_section', 'data_section' and 'bss_section'. The normal way of 38087controlling a 'FOO_section' variable is to define the associated 38088'FOO_SECTION_ASM_OP' macro, as described below. The macros are only 38089read once, when 'varasm.c' initializes itself, so their values must be 38090run-time constants. They may however depend on command-line flags. 38091 38092 _Note:_ Some run-time files, such 'crtstuff.c', also make use of the 38093'FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 38094 38095 Some assemblers require a different string to be written every time a 38096section is selected. If your assembler falls into this category, you 38097should define the 'TARGET_ASM_INIT_SECTIONS' hook and use 38098'get_unnamed_section' to set up the sections. 38099 38100 You must always create a 'text_section', either by defining 38101'TEXT_SECTION_ASM_OP' or by initializing 'text_section' in 38102'TARGET_ASM_INIT_SECTIONS'. The same is true of 'data_section' and 38103'DATA_SECTION_ASM_OP'. If you do not create a distinct 38104'readonly_data_section', the default is to reuse 'text_section'. 38105 38106 All the other 'varasm.c' sections are optional, and are null if the 38107target does not provide them. 38108 38109 -- Macro: TEXT_SECTION_ASM_OP 38110 A C expression whose value is a string, including spacing, 38111 containing the assembler operation that should precede instructions 38112 and read-only data. Normally '"\t.text"' is right. 38113 38114 -- Macro: HOT_TEXT_SECTION_NAME 38115 If defined, a C string constant for the name of the section 38116 containing most frequently executed functions of the program. If 38117 not defined, GCC will provide a default definition if the target 38118 supports named sections. 38119 38120 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 38121 If defined, a C string constant for the name of the section 38122 containing unlikely executed functions in the program. 38123 38124 -- Macro: DATA_SECTION_ASM_OP 38125 A C expression whose value is a string, including spacing, 38126 containing the assembler operation to identify the following data 38127 as writable initialized data. Normally '"\t.data"' is right. 38128 38129 -- Macro: SDATA_SECTION_ASM_OP 38130 If defined, a C expression whose value is a string, including 38131 spacing, containing the assembler operation to identify the 38132 following data as initialized, writable small data. 38133 38134 -- Macro: READONLY_DATA_SECTION_ASM_OP 38135 A C expression whose value is a string, including spacing, 38136 containing the assembler operation to identify the following data 38137 as read-only initialized data. 38138 38139 -- Macro: BSS_SECTION_ASM_OP 38140 If defined, a C expression whose value is a string, including 38141 spacing, containing the assembler operation to identify the 38142 following data as uninitialized global data. If not defined, and 38143 'ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data 38144 will be output in the data section if '-fno-common' is passed, 38145 otherwise 'ASM_OUTPUT_COMMON' will be used. 38146 38147 -- Macro: SBSS_SECTION_ASM_OP 38148 If defined, a C expression whose value is a string, including 38149 spacing, containing the assembler operation to identify the 38150 following data as uninitialized, writable small data. 38151 38152 -- Macro: TLS_COMMON_ASM_OP 38153 If defined, a C expression whose value is a string containing the 38154 assembler operation to identify the following data as thread-local 38155 common data. The default is '".tls_common"'. 38156 38157 -- Macro: TLS_SECTION_ASM_FLAG 38158 If defined, a C expression whose value is a character constant 38159 containing the flag used to mark a section as a TLS section. The 38160 default is ''T''. 38161 38162 -- Macro: INIT_SECTION_ASM_OP 38163 If defined, a C expression whose value is a string, including 38164 spacing, containing the assembler operation to identify the 38165 following data as initialization code. If not defined, GCC will 38166 assume such a section does not exist. This section has no 38167 corresponding 'init_section' variable; it is used entirely in 38168 runtime code. 38169 38170 -- Macro: FINI_SECTION_ASM_OP 38171 If defined, a C expression whose value is a string, including 38172 spacing, containing the assembler operation to identify the 38173 following data as finalization code. If not defined, GCC will 38174 assume such a section does not exist. This section has no 38175 corresponding 'fini_section' variable; it is used entirely in 38176 runtime code. 38177 38178 -- Macro: INIT_ARRAY_SECTION_ASM_OP 38179 If defined, a C expression whose value is a string, including 38180 spacing, containing the assembler operation to identify the 38181 following data as part of the '.init_array' (or equivalent) 38182 section. If not defined, GCC will assume such a section does not 38183 exist. Do not define both this macro and 'INIT_SECTION_ASM_OP'. 38184 38185 -- Macro: FINI_ARRAY_SECTION_ASM_OP 38186 If defined, a C expression whose value is a string, including 38187 spacing, containing the assembler operation to identify the 38188 following data as part of the '.fini_array' (or equivalent) 38189 section. If not defined, GCC will assume such a section does not 38190 exist. Do not define both this macro and 'FINI_SECTION_ASM_OP'. 38191 38192 -- Macro: MACH_DEP_SECTION_ASM_FLAG 38193 If defined, a C expression whose value is a character constant 38194 containing the flag used to mark a machine-dependent section. This 38195 corresponds to the 'SECTION_MACH_DEP' section flag. 38196 38197 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 38198 If defined, an ASM statement that switches to a different section 38199 via SECTION_OP, calls FUNCTION, and switches back to the text 38200 section. This is used in 'crtstuff.c' if 'INIT_SECTION_ASM_OP' or 38201 'FINI_SECTION_ASM_OP' to calls to initialization and finalization 38202 functions from the init and fini sections. By default, this macro 38203 uses a simple function call. Some ports need hand-crafted assembly 38204 code to avoid dependencies on registers initialized in the function 38205 prologue or to ensure that constant pools don't end up too far way 38206 in the text section. 38207 38208 -- Macro: TARGET_LIBGCC_SDATA_SECTION 38209 If defined, a string which names the section into which small 38210 variables defined in crtstuff and libgcc should go. This is useful 38211 when the target has options for optimizing access to small data, 38212 and you want the crtstuff and libgcc routines to be conservative in 38213 what they expect of your application yet liberal in what your 38214 application expects. For example, for targets with a '.sdata' 38215 section (like MIPS), you could compile crtstuff with '-G 0' so that 38216 it doesn't require small data support from your application, but 38217 use this macro to put small data into '.sdata' so that your 38218 application can access these variables whether it uses small data 38219 or not. 38220 38221 -- Macro: FORCE_CODE_SECTION_ALIGN 38222 If defined, an ASM statement that aligns a code section to some 38223 arbitrary boundary. This is used to force all fragments of the 38224 '.init' and '.fini' sections to have to same alignment and thus 38225 prevent the linker from having to add any padding. 38226 38227 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 38228 Define this macro to be an expression with a nonzero value if jump 38229 tables (for 'tablejump' insns) should be output in the text 38230 section, along with the assembler instructions. Otherwise, the 38231 readonly data section is used. 38232 38233 This macro is irrelevant if there is no separate readonly data 38234 section. 38235 38236 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 38237 Define this hook if you need to do something special to set up the 38238 'varasm.c' sections, or if your target has some special sections of 38239 its own that you need to create. 38240 38241 GCC calls this hook after processing the command line, but before 38242 writing any assembly code, and before calling any of the 38243 section-returning hooks described below. 38244 38245 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 38246 Return a mask describing how relocations should be treated when 38247 selecting sections. Bit 1 should be set if global relocations 38248 should be placed in a read-write section; bit 0 should be set if 38249 local relocations should be placed in a read-write section. 38250 38251 The default version of this function returns 3 when '-fpic' is in 38252 effect, and 0 otherwise. The hook is typically redefined when the 38253 target cannot support (some kinds of) dynamic relocations in 38254 read-only sections even in executables. 38255 38256 -- Target Hook: bool TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC (void) 38257 Return true to generate ADDR_DIF_VEC table or false to generate 38258 ADDR_VEC table for jumps in case of -fPIC. 38259 38260 The default version of this function returns true if flag_pic 38261 equals true and false otherwise 38262 38263 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 38264 RELOC, unsigned HOST_WIDE_INT ALIGN) 38265 Return the section into which EXP should be placed. You can assume 38266 that EXP is either a 'VAR_DECL' node or a constant of some sort. 38267 RELOC indicates whether the initial value of EXP requires link-time 38268 relocations. Bit 0 is set when variable contains local relocations 38269 only, while bit 1 is set for global relocations. ALIGN is the 38270 constant alignment in bits. 38271 38272 The default version of this function takes care of putting 38273 read-only variables in 'readonly_data_section'. 38274 38275 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 38276 38277 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 38278 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 38279 called for 'FUNCTION_DECL's as well as for variables and constants. 38280 38281 In the case of a 'FUNCTION_DECL', RELOC will be zero if the 38282 function has been determined to be likely to be called, and nonzero 38283 if it is unlikely to be called. 38284 38285 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 38286 Build up a unique section name, expressed as a 'STRING_CST' node, 38287 and assign it to 'DECL_SECTION_NAME (DECL)'. As with 38288 'TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 38289 value of EXP requires link-time relocations. 38290 38291 The default version of this function appends the symbol name to the 38292 ELF section name that would normally be used for the symbol. For 38293 example, the function 'foo' would be placed in '.text.foo'. 38294 Whatever the actual target object format, this is often good 38295 enough. 38296 38297 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 38298 DECL) 38299 Return the readonly data section associated with 'DECL_SECTION_NAME 38300 (DECL)'. The default version of this function selects 38301 '.gnu.linkonce.r.name' if the function's section is 38302 '.gnu.linkonce.t.name', '.rodata.name' if function is in 38303 '.text.name', and the normal readonly-data section otherwise. 38304 38305 -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX 38306 Usually, the compiler uses the prefix '".rodata"' to construct 38307 section names for mergeable constant data. Define this macro to 38308 override the string if a different section name should be used. 38309 38310 -- Target Hook: section * TARGET_ASM_TM_CLONE_TABLE_SECTION (void) 38311 Return the section that should be used for transactional memory 38312 clone tables. 38313 38314 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (machine_mode 38315 MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 38316 Return the section into which a constant X, of mode MODE, should be 38317 placed. You can assume that X is some kind of constant in RTL. 38318 The argument MODE is redundant except in the case of a 'const_int' 38319 rtx. ALIGN is the constant alignment in bits. 38320 38321 The default version of this function takes care of putting symbolic 38322 constants in 'flag_pic' mode in 'data_section' and everything else 38323 in 'readonly_data_section'. 38324 38325 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, tree 38326 ID) 38327 Define this hook if you need to postprocess the assembler name 38328 generated by target-independent code. The ID provided to this hook 38329 will be the computed name (e.g., the macro 'DECL_NAME' of the DECL 38330 in C, or the mangled name of the DECL in C++). The return value of 38331 the hook is an 'IDENTIFIER_NODE' for the appropriate mangled name 38332 on your target system. The default implementation of this hook 38333 just returns the ID provided. 38334 38335 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 38336 int NEW_DECL_P) 38337 Define this hook if references to a symbol or a constant must be 38338 treated differently depending on something about the variable or 38339 function named by the symbol (such as what section it is in). 38340 38341 The hook is executed immediately after rtl has been created for 38342 DECL, which may be a variable or function declaration or an entry 38343 in the constant pool. In either case, RTL is the rtl in question. 38344 Do _not_ use 'DECL_RTL (DECL)' in this hook; that field may not 38345 have been initialized yet. 38346 38347 In the case of a constant, it is safe to assume that the rtl is a 38348 'mem' whose address is a 'symbol_ref'. Most decls will also have 38349 this form, but that is not guaranteed. Global register variables, 38350 for instance, will have a 'reg' for their rtl. (Normally the right 38351 thing to do with such unusual rtl is leave it alone.) 38352 38353 The NEW_DECL_P argument will be true if this is the first time that 38354 'TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. It 38355 will be false for subsequent invocations, which will happen for 38356 duplicate declarations. Whether or not anything must be done for 38357 the duplicate declaration depends on whether the hook examines 38358 'DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 38359 called for a constant. 38360 38361 The usual thing for this hook to do is to record flags in the 38362 'symbol_ref', using 'SYMBOL_REF_FLAG' or 'SYMBOL_REF_FLAGS'. 38363 Historically, the name string was modified if it was necessary to 38364 encode more than one bit of information, but this practice is now 38365 discouraged; use 'SYMBOL_REF_FLAGS'. 38366 38367 The default definition of this hook, 'default_encode_section_info' 38368 in 'varasm.c', sets a number of commonly-useful bits in 38369 'SYMBOL_REF_FLAGS'. Check whether the default does what you need 38370 before overriding it. 38371 38372 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 38373 *NAME) 38374 Decode NAME and return the real name part, sans the characters that 38375 'TARGET_ENCODE_SECTION_INFO' may have added. 38376 38377 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 38378 Returns true if EXP should be placed into a "small data" section. 38379 The default version of this hook always returns false. 38380 38381 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 38382 Contains the value true if the target places read-only "small data" 38383 into a separate section. The default value is false. 38384 38385 -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void) 38386 It returns true if target wants profile code emitted before 38387 prologue. 38388 38389 The default version of this hook use the target macro 38390 'PROFILE_BEFORE_PROLOGUE'. 38391 38392 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 38393 Returns true if EXP names an object for which name resolution rules 38394 must resolve to the current "module" (dynamic shared library or 38395 executable image). 38396 38397 The default version of this hook implements the name resolution 38398 rules for ELF, which has a looser model of global name binding than 38399 other currently supported object file formats. 38400 38401 -- Target Hook: bool TARGET_HAVE_TLS 38402 Contains the value true if the target supports thread-local 38403 storage. The default value is false. 38404 38405 38406File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 38407 3840818.19 Position Independent Code 38409=============================== 38410 38411This section describes macros that help implement generation of position 38412independent code. Simply defining these macros is not enough to 38413generate valid PIC; you must also add support to the hook 38414'TARGET_LEGITIMATE_ADDRESS_P' and to the macro 'PRINT_OPERAND_ADDRESS', 38415as well as 'LEGITIMIZE_ADDRESS'. You must modify the definition of 38416'movsi' to do something appropriate when the source operand contains a 38417symbolic address. You may also need to alter the handling of switch 38418statements so that they use relative addresses. 38419 38420 -- Macro: PIC_OFFSET_TABLE_REGNUM 38421 The register number of the register used to address a table of 38422 static data addresses in memory. In some cases this register is 38423 defined by a processor's "application binary interface" (ABI). 38424 When this macro is defined, RTL is generated for this register 38425 once, as with the stack pointer and frame pointer registers. If 38426 this macro is not defined, it is up to the machine-dependent files 38427 to allocate such a register (if necessary). Note that this 38428 register must be fixed when in use (e.g. when 'flag_pic' is true). 38429 38430 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 38431 A C expression that is nonzero if the register defined by 38432 'PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined, 38433 the default is zero. Do not define this macro if 38434 'PIC_OFFSET_TABLE_REGNUM' is not defined. 38435 38436 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 38437 A C expression that is nonzero if X is a legitimate immediate 38438 operand on the target machine when generating position independent 38439 code. You can assume that X satisfies 'CONSTANT_P', so you need 38440 not check this. You can also assume FLAG_PIC is true, so you need 38441 not check it either. You need not define this macro if all 38442 constants (including 'SYMBOL_REF') can be immediate operands when 38443 generating position independent code. 38444 38445 38446File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 38447 3844818.20 Defining the Output Assembler Language 38449============================================ 38450 38451This section describes macros whose principal purpose is to describe how 38452to write instructions in assembler language--rather than what the 38453instructions do. 38454 38455* Menu: 38456 38457* File Framework:: Structural information for the assembler file. 38458* Data Output:: Output of constants (numbers, strings, addresses). 38459* Uninitialized Data:: Output of uninitialized variables. 38460* Label Output:: Output and generation of labels. 38461* Initialization:: General principles of initialization 38462 and termination routines. 38463* Macros for Initialization:: 38464 Specific macros that control the handling of 38465 initialization and termination routines. 38466* Instruction Output:: Output of actual instructions. 38467* Dispatch Tables:: Output of jump tables. 38468* Exception Region Output:: Output of exception region code. 38469* Alignment Output:: Pseudo ops for alignment and skipping data. 38470 38471 38472File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 38473 3847418.20.1 The Overall Framework of an Assembler File 38475-------------------------------------------------- 38476 38477This describes the overall framework of an assembly file. 38478 38479 -- Target Hook: void TARGET_ASM_FILE_START (void) 38480 Output to 'asm_out_file' any text which the assembler expects to 38481 find at the beginning of a file. The default behavior is 38482 controlled by two flags, documented below. Unless your target's 38483 assembler is quite unusual, if you override the default, you should 38484 call 'default_file_start' at some point in your target hook. This 38485 lets other target files rely on these variables. 38486 38487 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 38488 If this flag is true, the text of the macro 'ASM_APP_OFF' will be 38489 printed as the very first line in the assembly file, unless 38490 '-fverbose-asm' is in effect. (If that macro has been defined to 38491 the empty string, this variable has no effect.) With the normal 38492 definition of 'ASM_APP_OFF', the effect is to notify the GNU 38493 assembler that it need not bother stripping comments or extra 38494 whitespace from its input. This allows it to work a bit faster. 38495 38496 The default is false. You should not set it to true unless you 38497 have verified that your port does not generate any extra whitespace 38498 or comments that will cause GAS to issue errors in NO_APP mode. 38499 38500 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 38501 If this flag is true, 'output_file_directive' will be called for 38502 the primary source file, immediately after printing 'ASM_APP_OFF' 38503 (if that is enabled). Most ELF assemblers expect this to be done. 38504 The default is false. 38505 38506 -- Target Hook: void TARGET_ASM_FILE_END (void) 38507 Output to 'asm_out_file' any text which the assembler expects to 38508 find at the end of a file. The default is to output nothing. 38509 38510 -- Function: void file_end_indicate_exec_stack () 38511 Some systems use a common convention, the '.note.GNU-stack' special 38512 section, to indicate whether or not an object file relies on the 38513 stack being executable. If your system uses this convention, you 38514 should define 'TARGET_ASM_FILE_END' to this function. If you need 38515 to do other things in that hook, have your hook function call this 38516 function. 38517 38518 -- Target Hook: void TARGET_ASM_LTO_START (void) 38519 Output to 'asm_out_file' any text which the assembler expects to 38520 find at the start of an LTO section. The default is to output 38521 nothing. 38522 38523 -- Target Hook: void TARGET_ASM_LTO_END (void) 38524 Output to 'asm_out_file' any text which the assembler expects to 38525 find at the end of an LTO section. The default is to output 38526 nothing. 38527 38528 -- Target Hook: void TARGET_ASM_CODE_END (void) 38529 Output to 'asm_out_file' any text which is needed before emitting 38530 unwind info and debug info at the end of a file. Some targets emit 38531 here PIC setup thunks that cannot be emitted at the end of file, 38532 because they couldn't have unwind info then. The default is to 38533 output nothing. 38534 38535 -- Macro: ASM_COMMENT_START 38536 A C string constant describing how to begin a comment in the target 38537 assembler language. The compiler assumes that the comment will end 38538 at the end of the line. 38539 38540 -- Macro: ASM_APP_ON 38541 A C string constant for text to be output before each 'asm' 38542 statement or group of consecutive ones. Normally this is '"#APP"', 38543 which is a comment that has no effect on most assemblers but tells 38544 the GNU assembler that it must check the lines that follow for all 38545 valid assembler constructs. 38546 38547 -- Macro: ASM_APP_OFF 38548 A C string constant for text to be output after each 'asm' 38549 statement or group of consecutive ones. Normally this is 38550 '"#NO_APP"', which tells the GNU assembler to resume making the 38551 time-saving assumptions that are valid for ordinary compiler 38552 output. 38553 38554 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 38555 A C statement to output COFF information or DWARF debugging 38556 information which indicates that filename NAME is the current 38557 source file to the stdio stream STREAM. 38558 38559 This macro need not be defined if the standard form of output for 38560 the file format in use is appropriate. 38561 38562 -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE, 38563 const char *NAME) 38564 Output DWARF debugging information which indicates that filename 38565 NAME is the current source file to the stdio stream FILE. 38566 38567 This target hook need not be defined if the standard form of output 38568 for the file format in use is appropriate. 38569 38570 -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME) 38571 Output a string based on NAME, suitable for the '#ident' directive, 38572 or the equivalent directive or pragma in non-C-family languages. 38573 If this hook is not defined, nothing is output for the '#ident' 38574 directive. 38575 38576 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 38577 A C statement to output the string STRING to the stdio stream 38578 STREAM. If you do not call the function 'output_quoted_string' in 38579 your config files, GCC will only call it to output filenames to the 38580 assembler source. So you can use it to canonicalize the format of 38581 the filename using this macro. 38582 38583 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 38584 unsigned int FLAGS, tree DECL) 38585 Output assembly directives to switch to section NAME. The section 38586 should have attributes as specified by FLAGS, which is a bit mask 38587 of the 'SECTION_*' flags defined in 'output.h'. If DECL is 38588 non-NULL, it is the 'VAR_DECL' or 'FUNCTION_DECL' with which this 38589 section is associated. 38590 38591 -- Target Hook: bool TARGET_ASM_ELF_FLAGS_NUMERIC (unsigned int FLAGS, 38592 unsigned int *NUM) 38593 This hook can be used to encode ELF section flags for which no 38594 letter code has been defined in the assembler. It is called by 38595 'default_asm_named_section' whenever the section flags need to be 38596 emitted in the assembler output. If the hook returns true, then 38597 the numerical value for ELF section flags should be calculated from 38598 FLAGS and saved in *NUM; the value is printed out instead of the 38599 normal sequence of letter codes. If the hook is not defined, or if 38600 it returns false, then NUM is ignored and the traditional letter 38601 sequence is emitted. 38602 38603 -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum 38604 node_frequency FREQ, bool STARTUP, bool EXIT) 38605 Return preferred text (sub)section for function DECL. Main purpose 38606 of this function is to separate cold, normal and hot functions. 38607 STARTUP is true when function is known to be used only at startup 38608 (from static constructors or it is 'main()'). EXIT is true when 38609 function is known to be used only at exit (from static 38610 destructors). Return NULL if function should go to default text 38611 section. 38612 38613 -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE 38614 *FILE, tree DECL, bool NEW_IS_COLD) 38615 Used by the target to emit any assembler directives or additional 38616 labels needed when a function is partitioned between different 38617 sections. Output should be written to FILE. The function decl is 38618 available as DECL and the new section is 'cold' if NEW_IS_COLD is 38619 'true'. 38620 38621 -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 38622 This flag is true if the target supports 38623 'TARGET_ASM_NAMED_SECTION'. It must not be modified by 38624 command-line option processing. 38625 38626 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 38627 This flag is true if we can create zeroed data by switching to a 38628 BSS section and then using 'ASM_OUTPUT_SKIP' to allocate the space. 38629 This is true on most ELF targets. 38630 38631 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 38632 const char *NAME, int RELOC) 38633 Choose a set of section attributes for use by 38634 'TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 38635 section name, and whether or not the declaration's initializer may 38636 contain runtime relocations. DECL may be null, in which case 38637 read-write data should be assumed. 38638 38639 The default version of this function handles choosing code vs data, 38640 read-only vs read-write data, and 'flag_pic'. You should only need 38641 to override this if your target has special flags that might be set 38642 via '__attribute__'. 38643 38644 -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type 38645 TYPE, const char *TEXT) 38646 Provides the target with the ability to record the gcc command line 38647 switches that have been passed to the compiler, and options that 38648 are enabled. The TYPE argument specifies what is being recorded. 38649 It can take the following values: 38650 38651 'SWITCH_TYPE_PASSED' 38652 TEXT is a command line switch that has been set by the user. 38653 38654 'SWITCH_TYPE_ENABLED' 38655 TEXT is an option which has been enabled. This might be as a 38656 direct result of a command line switch, or because it is 38657 enabled by default or because it has been enabled as a side 38658 effect of a different command line switch. For example, the 38659 '-O2' switch enables various different individual optimization 38660 passes. 38661 38662 'SWITCH_TYPE_DESCRIPTIVE' 38663 TEXT is either NULL or some descriptive text which should be 38664 ignored. If TEXT is NULL then it is being used to warn the 38665 target hook that either recording is starting or ending. The 38666 first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL, 38667 the warning is for start up and the second time the warning is 38668 for wind down. This feature is to allow the target hook to 38669 make any necessary preparations before it starts to record 38670 switches and to perform any necessary tidying up after it has 38671 finished recording switches. 38672 38673 'SWITCH_TYPE_LINE_START' 38674 This option can be ignored by this target hook. 38675 38676 'SWITCH_TYPE_LINE_END' 38677 This option can be ignored by this target hook. 38678 38679 The hook's return value must be zero. Other return values may be 38680 supported in the future. 38681 38682 By default this hook is set to NULL, but an example implementation 38683 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 38684 it records the switches as ASCII text inside a new, string 38685 mergeable section in the assembler output file. The name of the 38686 new section is provided by the 38687 'TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 38688 38689 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 38690 This is the name of the section that will be created by the example 38691 ELF implementation of the 'TARGET_ASM_RECORD_GCC_SWITCHES' target 38692 hook. 38693 38694 38695File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 38696 3869718.20.2 Output of Data 38698---------------------- 38699 38700 -- Target Hook: const char * TARGET_ASM_BYTE_OP 38701 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 38702 -- Target Hook: const char * TARGET_ASM_ALIGNED_PSI_OP 38703 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 38704 -- Target Hook: const char * TARGET_ASM_ALIGNED_PDI_OP 38705 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 38706 -- Target Hook: const char * TARGET_ASM_ALIGNED_PTI_OP 38707 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 38708 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 38709 -- Target Hook: const char * TARGET_ASM_UNALIGNED_PSI_OP 38710 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 38711 -- Target Hook: const char * TARGET_ASM_UNALIGNED_PDI_OP 38712 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 38713 -- Target Hook: const char * TARGET_ASM_UNALIGNED_PTI_OP 38714 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 38715 These hooks specify assembly directives for creating certain kinds 38716 of integer object. The 'TARGET_ASM_BYTE_OP' directive creates a 38717 byte-sized object, the 'TARGET_ASM_ALIGNED_HI_OP' one creates an 38718 aligned two-byte object, and so on. Any of the hooks may be 38719 'NULL', indicating that no suitable directive is available. 38720 38721 The compiler will print these strings at the start of a new line, 38722 followed immediately by the object's initial value. In most cases, 38723 the string should contain a tab, a pseudo-op, and then another tab. 38724 38725 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 38726 ALIGNED_P) 38727 The 'assemble_integer' function uses this hook to output an integer 38728 object. X is the object's value, SIZE is its size in bytes and 38729 ALIGNED_P indicates whether it is aligned. The function should 38730 return 'true' if it was able to output the object. If it returns 38731 false, 'assemble_integer' will try to split the object into smaller 38732 parts. 38733 38734 The default implementation of this hook will use the 38735 'TARGET_ASM_BYTE_OP' family of strings, returning 'false' when the 38736 relevant string is 'NULL'. 38737 38738 -- Target Hook: void TARGET_ASM_DECL_END (void) 38739 Define this hook if the target assembler requires a special marker 38740 to terminate an initialized variable declaration. 38741 38742 -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE, 38743 rtx X) 38744 A target hook to recognize RTX patterns that 'output_addr_const' 38745 can't deal with, and output assembly code to FILE corresponding to 38746 the pattern X. This may be used to allow machine-dependent 38747 'UNSPEC's to appear within constants. 38748 38749 If target hook fails to recognize a pattern, it must return 38750 'false', so that a standard error message is printed. If it prints 38751 an error message itself, by calling, for example, 38752 'output_operand_lossage', it may just return 'true'. 38753 38754 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 38755 A C statement to output to the stdio stream STREAM an assembler 38756 instruction to assemble a string constant containing the LEN bytes 38757 at PTR. PTR will be a C expression of type 'char *' and LEN a C 38758 expression of type 'int'. 38759 38760 If the assembler has a '.ascii' pseudo-op as found in the Berkeley 38761 Unix assembler, do not define the macro 'ASM_OUTPUT_ASCII'. 38762 38763 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 38764 A C statement to output word N of a function descriptor for DECL. 38765 This must be defined if 'TARGET_VTABLE_USES_DESCRIPTORS' is 38766 defined, and is otherwise unused. 38767 38768 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 38769 You may define this macro as a C expression. You should define the 38770 expression to have a nonzero value if GCC should output the 38771 constant pool for a function before the code for the function, or a 38772 zero value if GCC should output the constant pool after the 38773 function. If you do not define this macro, the usual case, GCC 38774 will output the constant pool before the function. 38775 38776 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 38777 A C statement to output assembler commands to define the start of 38778 the constant pool for a function. FUNNAME is a string giving the 38779 name of the function. Should the return type of the function be 38780 required, it can be obtained via FUNDECL. SIZE is the size, in 38781 bytes, of the constant pool that will be written immediately after 38782 this call. 38783 38784 If no constant-pool prefix is required, the usual case, this macro 38785 need not be defined. 38786 38787 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, 38788 JUMPTO) 38789 A C statement (with or without semicolon) to output a constant in 38790 the constant pool, if it needs special treatment. (This macro need 38791 not do anything for RTL expressions that can be output normally.) 38792 38793 The argument FILE is the standard I/O stream to output the 38794 assembler code on. X is the RTL expression for the constant to 38795 output, and MODE is the machine mode (in case X is a 'const_int'). 38796 ALIGN is the required alignment for the value X; you should output 38797 an assembler directive to force this much alignment. 38798 38799 The argument LABELNO is a number to use in an internal label for 38800 the address of this pool entry. The definition of this macro is 38801 responsible for outputting the label definition at the proper 38802 place. Here is how to do this: 38803 38804 (*targetm.asm_out.internal_label) (FILE, "LC", LABELNO); 38805 38806 When you output a pool entry specially, you should end with a 38807 'goto' to the label JUMPTO. This will prevent the same pool entry 38808 from being output a second time in the usual manner. 38809 38810 You need not define this macro if it would do nothing. 38811 38812 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 38813 A C statement to output assembler commands to at the end of the 38814 constant pool for a function. FUNNAME is a string giving the name 38815 of the function. Should the return type of the function be 38816 required, you can obtain it via FUNDECL. SIZE is the size, in 38817 bytes, of the constant pool that GCC wrote immediately before this 38818 call. 38819 38820 If no constant-pool epilogue is required, the usual case, you need 38821 not define this macro. 38822 38823 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 38824 Define this macro as a C expression which is nonzero if C is used 38825 as a logical line separator by the assembler. STR points to the 38826 position in the string where C was found; this can be used if a 38827 line separator uses multiple characters. 38828 38829 If you do not define this macro, the default is that only the 38830 character ';' is treated as a logical line separator. 38831 38832 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 38833 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 38834 These target hooks are C string constants, describing the syntax in 38835 the assembler for grouping arithmetic expressions. If not 38836 overridden, they default to normal parentheses, which is correct 38837 for most assemblers. 38838 38839 These macros are provided by 'real.h' for writing the definitions of 38840'ASM_OUTPUT_DOUBLE' and the like: 38841 38842 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 38843 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 38844 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 38845 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 38846 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 38847 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 38848 These translate X, of type 'REAL_VALUE_TYPE', to the target's 38849 floating point representation, and store its bit pattern in the 38850 variable L. For 'REAL_VALUE_TO_TARGET_SINGLE' and 38851 'REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 38852 'long int'. For the others, it should be an array of 'long int'. 38853 The number of elements in this array is determined by the size of 38854 the desired target floating point data type: 32 bits of it go in 38855 each 'long int' array element. Each array element holds 32 bits of 38856 the result, even if 'long int' is wider than 32 bits on the host 38857 machine. 38858 38859 The array element values are designed so that you can print them 38860 out using 'fprintf' in the order they should appear in the target 38861 machine's memory. 38862 38863 38864File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 38865 3886618.20.3 Output of Uninitialized Variables 38867----------------------------------------- 38868 38869Each of the macros in this section is used to do the whole job of 38870outputting a single uninitialized variable. 38871 38872 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 38873 A C statement (sans semicolon) to output to the stdio stream STREAM 38874 the assembler definition of a common-label named NAME whose size is 38875 SIZE bytes. The variable ROUNDED is the size rounded up to 38876 whatever alignment the caller wants. It is possible that SIZE may 38877 be zero, for instance if a struct with no other member than a 38878 zero-length array is defined. In this case, the backend must 38879 output a symbol definition that allocates at least one byte, both 38880 so that the address of the resulting object does not compare equal 38881 to any other, and because some object formats cannot even express 38882 the concept of a zero-sized common symbol, as that is how they 38883 represent an ordinary undefined external. 38884 38885 Use the expression 'assemble_name (STREAM, NAME)' to output the 38886 name itself; before and after that, output the additional assembler 38887 syntax for defining the name, and a newline. 38888 38889 This macro controls how the assembler definitions of uninitialized 38890 common global variables are output. 38891 38892 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 38893 Like 'ASM_OUTPUT_COMMON' except takes the required alignment as a 38894 separate, explicit argument. If you define this macro, it is used 38895 in place of 'ASM_OUTPUT_COMMON', and gives you more flexibility in 38896 handling the required alignment of the variable. The alignment is 38897 specified as the number of bits. 38898 38899 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 38900 ALIGNMENT) 38901 Like 'ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 38902 to be output, if there is one, or 'NULL_TREE' if there is no 38903 corresponding variable. If you define this macro, GCC will use it 38904 in place of both 'ASM_OUTPUT_COMMON' and 38905 'ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 38906 see the variable's decl in order to chose what to output. 38907 38908 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 38909 A C statement (sans semicolon) to output to the stdio stream STREAM 38910 the assembler definition of uninitialized global DECL named NAME 38911 whose size is SIZE bytes. The variable ALIGNMENT is the alignment 38912 specified as the number of bits. 38913 38914 Try to use function 'asm_output_aligned_bss' defined in file 38915 'varasm.c' when defining this macro. If unable, use the expression 38916 'assemble_name (STREAM, NAME)' to output the name itself; before 38917 and after that, output the additional assembler syntax for defining 38918 the name, and a newline. 38919 38920 There are two ways of handling global BSS. One is to define this 38921 macro. The other is to have 'TARGET_ASM_SELECT_SECTION' return a 38922 switchable BSS section (*note 38923 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 38924 both. 38925 38926 Some languages do not have 'common' data, and require a non-common 38927 form of global BSS in order to handle uninitialized globals 38928 efficiently. C++ is one example of this. However, if the target 38929 does not support global BSS, the front end may choose to make 38930 globals common in order to save space in the object file. 38931 38932 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 38933 A C statement (sans semicolon) to output to the stdio stream STREAM 38934 the assembler definition of a local-common-label named NAME whose 38935 size is SIZE bytes. The variable ROUNDED is the size rounded up to 38936 whatever alignment the caller wants. 38937 38938 Use the expression 'assemble_name (STREAM, NAME)' to output the 38939 name itself; before and after that, output the additional assembler 38940 syntax for defining the name, and a newline. 38941 38942 This macro controls how the assembler definitions of uninitialized 38943 static variables are output. 38944 38945 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 38946 Like 'ASM_OUTPUT_LOCAL' except takes the required alignment as a 38947 separate, explicit argument. If you define this macro, it is used 38948 in place of 'ASM_OUTPUT_LOCAL', and gives you more flexibility in 38949 handling the required alignment of the variable. The alignment is 38950 specified as the number of bits. 38951 38952 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 38953 ALIGNMENT) 38954 Like 'ASM_OUTPUT_ALIGNED_LOCAL' except that DECL of the variable to 38955 be output, if there is one, or 'NULL_TREE' if there is no 38956 corresponding variable. If you define this macro, GCC will use it 38957 in place of both 'ASM_OUTPUT_LOCAL' and 'ASM_OUTPUT_ALIGNED_LOCAL'. 38958 Define this macro when you need to see the variable's decl in order 38959 to chose what to output. 38960 38961 38962File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 38963 3896418.20.4 Output and Generation of Labels 38965--------------------------------------- 38966 38967This is about outputting labels. 38968 38969 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 38970 A C statement (sans semicolon) to output to the stdio stream STREAM 38971 the assembler definition of a label named NAME. Use the expression 38972 'assemble_name (STREAM, NAME)' to output the name itself; before 38973 and after that, output the additional assembler syntax for defining 38974 the name, and a newline. A default definition of this macro is 38975 provided which is correct for most systems. 38976 38977 -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL) 38978 A C statement (sans semicolon) to output to the stdio stream STREAM 38979 the assembler definition of a label named NAME of a function. Use 38980 the expression 'assemble_name (STREAM, NAME)' to output the name 38981 itself; before and after that, output the additional assembler 38982 syntax for defining the name, and a newline. A default definition 38983 of this macro is provided which is correct for most systems. 38984 38985 If this macro is not defined, then the function name is defined in 38986 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 38987 38988 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 38989 Identical to 'ASM_OUTPUT_LABEL', except that NAME is known to refer 38990 to a compiler-generated label. The default definition uses 38991 'assemble_name_raw', which is like 'assemble_name' except that it 38992 is more efficient. 38993 38994 -- Macro: SIZE_ASM_OP 38995 A C string containing the appropriate assembler directive to 38996 specify the size of a symbol, without any arguments. On systems 38997 that use ELF, the default (in 'config/elfos.h') is '"\t.size\t"'; 38998 on other systems, the default is not to define this macro. 38999 39000 Define this macro only if it is correct to use the default 39001 definitions of 'ASM_OUTPUT_SIZE_DIRECTIVE' and 39002 'ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 39003 custom definitions of those macros, or if you do not need explicit 39004 symbol sizes at all, do not define this macro. 39005 39006 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 39007 A C statement (sans semicolon) to output to the stdio stream STREAM 39008 a directive telling the assembler that the size of the symbol NAME 39009 is SIZE. SIZE is a 'HOST_WIDE_INT'. If you define 'SIZE_ASM_OP', 39010 a default definition of this macro is provided. 39011 39012 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 39013 A C statement (sans semicolon) to output to the stdio stream STREAM 39014 a directive telling the assembler to calculate the size of the 39015 symbol NAME by subtracting its address from the current address. 39016 39017 If you define 'SIZE_ASM_OP', a default definition of this macro is 39018 provided. The default assumes that the assembler recognizes a 39019 special '.' symbol as referring to the current address, and can 39020 calculate the difference between this and another symbol. If your 39021 assembler does not recognize '.' or cannot do calculations with it, 39022 you will need to redefine 'ASM_OUTPUT_MEASURED_SIZE' to use some 39023 other technique. 39024 39025 -- Macro: NO_DOLLAR_IN_LABEL 39026 Define this macro if the assembler does not accept the character 39027 '$' in label names. By default constructors and destructors in G++ 39028 have '$' in the identifiers. If this macro is defined, '.' is used 39029 instead. 39030 39031 -- Macro: NO_DOT_IN_LABEL 39032 Define this macro if the assembler does not accept the character 39033 '.' in label names. By default constructors and destructors in G++ 39034 have names that use '.'. If this macro is defined, these names are 39035 rewritten to avoid '.'. 39036 39037 -- Macro: TYPE_ASM_OP 39038 A C string containing the appropriate assembler directive to 39039 specify the type of a symbol, without any arguments. On systems 39040 that use ELF, the default (in 'config/elfos.h') is '"\t.type\t"'; 39041 on other systems, the default is not to define this macro. 39042 39043 Define this macro only if it is correct to use the default 39044 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 39045 need your own custom definition of this macro, or if you do not 39046 need explicit symbol types at all, do not define this macro. 39047 39048 -- Macro: TYPE_OPERAND_FMT 39049 A C string which specifies (using 'printf' syntax) the format of 39050 the second operand to 'TYPE_ASM_OP'. On systems that use ELF, the 39051 default (in 'config/elfos.h') is '"@%s"'; on other systems, the 39052 default is not to define this macro. 39053 39054 Define this macro only if it is correct to use the default 39055 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 39056 need your own custom definition of this macro, or if you do not 39057 need explicit symbol types at all, do not define this macro. 39058 39059 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 39060 A C statement (sans semicolon) to output to the stdio stream STREAM 39061 a directive telling the assembler that the type of the symbol NAME 39062 is TYPE. TYPE is a C string; currently, that string is always 39063 either '"function"' or '"object"', but you should not count on 39064 this. 39065 39066 If you define 'TYPE_ASM_OP' and 'TYPE_OPERAND_FMT', a default 39067 definition of this macro is provided. 39068 39069 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 39070 A C statement (sans semicolon) to output to the stdio stream STREAM 39071 any text necessary for declaring the name NAME of a function which 39072 is being defined. This macro is responsible for outputting the 39073 label definition (perhaps using 'ASM_OUTPUT_FUNCTION_LABEL'). The 39074 argument DECL is the 'FUNCTION_DECL' tree node representing the 39075 function. 39076 39077 If this macro is not defined, then the function name is defined in 39078 the usual manner as a label (by means of 39079 'ASM_OUTPUT_FUNCTION_LABEL'). 39080 39081 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 39082 of this macro. 39083 39084 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 39085 A C statement (sans semicolon) to output to the stdio stream STREAM 39086 any text necessary for declaring the size of a function which is 39087 being defined. The argument NAME is the name of the function. The 39088 argument DECL is the 'FUNCTION_DECL' tree node representing the 39089 function. 39090 39091 If this macro is not defined, then the function size is not 39092 defined. 39093 39094 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 39095 this macro. 39096 39097 -- Macro: ASM_DECLARE_COLD_FUNCTION_NAME (STREAM, NAME, DECL) 39098 A C statement (sans semicolon) to output to the stdio stream STREAM 39099 any text necessary for declaring the name NAME of a cold function 39100 partition which is being defined. This macro is responsible for 39101 outputting the label definition (perhaps using 39102 'ASM_OUTPUT_FUNCTION_LABEL'). The argument DECL is the 39103 'FUNCTION_DECL' tree node representing the function. 39104 39105 If this macro is not defined, then the cold partition name is 39106 defined in the usual manner as a label (by means of 39107 'ASM_OUTPUT_LABEL'). 39108 39109 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 39110 of this macro. 39111 39112 -- Macro: ASM_DECLARE_COLD_FUNCTION_SIZE (STREAM, NAME, DECL) 39113 A C statement (sans semicolon) to output to the stdio stream STREAM 39114 any text necessary for declaring the size of a cold function 39115 partition which is being defined. The argument NAME is the name of 39116 the cold partition of the function. The argument DECL is the 39117 'FUNCTION_DECL' tree node representing the function. 39118 39119 If this macro is not defined, then the partition size is not 39120 defined. 39121 39122 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 39123 this macro. 39124 39125 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 39126 A C statement (sans semicolon) to output to the stdio stream STREAM 39127 any text necessary for declaring the name NAME of an initialized 39128 variable which is being defined. This macro must output the label 39129 definition (perhaps using 'ASM_OUTPUT_LABEL'). The argument DECL 39130 is the 'VAR_DECL' tree node representing the variable. 39131 39132 If this macro is not defined, then the variable name is defined in 39133 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 39134 39135 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' and/or 39136 'ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 39137 39138 -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE, 39139 const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE) 39140 A target hook to output to the stdio stream FILE any text necessary 39141 for declaring the name NAME of a constant which is being defined. 39142 This target hook is responsible for outputting the label definition 39143 (perhaps using 'assemble_label'). The argument EXP is the value of 39144 the constant, and SIZE is the size of the constant in bytes. The 39145 NAME will be an internal label. 39146 39147 The default version of this target hook, define the NAME in the 39148 usual manner as a label (by means of 'assemble_label'). 39149 39150 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in this target 39151 hook. 39152 39153 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 39154 A C statement (sans semicolon) to output to the stdio stream STREAM 39155 any text necessary for claiming a register REGNO for a global 39156 variable DECL with name NAME. 39157 39158 If you don't define this macro, that is equivalent to defining it 39159 to do nothing. 39160 39161 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 39162 A C statement (sans semicolon) to finish up declaring a variable 39163 name once the compiler has processed its initializer fully and thus 39164 has had a chance to determine the size of an array when controlled 39165 by an initializer. This is used on systems where it's necessary to 39166 declare something about the size of the object. 39167 39168 If you don't define this macro, that is equivalent to defining it 39169 to do nothing. 39170 39171 You may wish to use 'ASM_OUTPUT_SIZE_DIRECTIVE' and/or 39172 'ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 39173 39174 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 39175 char *NAME) 39176 This target hook is a function to output to the stdio stream STREAM 39177 some commands that will make the label NAME global; that is, 39178 available for reference from other files. 39179 39180 The default implementation relies on a proper definition of 39181 'GLOBAL_ASM_OP'. 39182 39183 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, tree 39184 DECL) 39185 This target hook is a function to output to the stdio stream STREAM 39186 some commands that will make the name associated with DECL global; 39187 that is, available for reference from other files. 39188 39189 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 39190 target hook. 39191 39192 -- Target Hook: void TARGET_ASM_ASSEMBLE_UNDEFINED_DECL (FILE *STREAM, 39193 const char *NAME, const_tree DECL) 39194 This target hook is a function to output to the stdio stream STREAM 39195 some commands that will declare the name associated with DECL which 39196 is not defined in the current translation unit. Most assemblers do 39197 not require anything to be output in this case. 39198 39199 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 39200 A C statement (sans semicolon) to output to the stdio stream STREAM 39201 some commands that will make the label NAME weak; that is, 39202 available for reference from other files but only used if no other 39203 definition is available. Use the expression 'assemble_name 39204 (STREAM, NAME)' to output the name itself; before and after that, 39205 output the additional assembler syntax for making that name weak, 39206 and a newline. 39207 39208 If you don't define this macro or 'ASM_WEAKEN_DECL', GCC will not 39209 support weak symbols and you should not define the 'SUPPORTS_WEAK' 39210 macro. 39211 39212 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 39213 Combines (and replaces) the function of 'ASM_WEAKEN_LABEL' and 39214 'ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 39215 or variable decl. If VALUE is not 'NULL', this C statement should 39216 output to the stdio stream STREAM assembler code which defines 39217 (equates) the weak symbol NAME to have the value VALUE. If VALUE 39218 is 'NULL', it should output commands to make NAME weak. 39219 39220 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 39221 Outputs a directive that enables NAME to be used to refer to symbol 39222 VALUE with weak-symbol semantics. 'decl' is the declaration of 39223 'name'. 39224 39225 -- Macro: SUPPORTS_WEAK 39226 A preprocessor constant expression which evaluates to true if the 39227 target supports weak symbols. 39228 39229 If you don't define this macro, 'defaults.h' provides a default 39230 definition. If either 'ASM_WEAKEN_LABEL' or 'ASM_WEAKEN_DECL' is 39231 defined, the default definition is '1'; otherwise, it is '0'. 39232 39233 -- Macro: TARGET_SUPPORTS_WEAK 39234 A C expression which evaluates to true if the target supports weak 39235 symbols. 39236 39237 If you don't define this macro, 'defaults.h' provides a default 39238 definition. The default definition is '(SUPPORTS_WEAK)'. Define 39239 this macro if you want to control weak symbol support with a 39240 compiler flag such as '-melf'. 39241 39242 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 39243 A C statement (sans semicolon) to mark DECL to be emitted as a 39244 public symbol such that extra copies in multiple translation units 39245 will be discarded by the linker. Define this macro if your object 39246 file format provides support for this concept, such as the 'COMDAT' 39247 section flags in the Microsoft Windows PE/COFF format, and this 39248 support requires changes to DECL, such as putting it in a separate 39249 section. 39250 39251 -- Macro: SUPPORTS_ONE_ONLY 39252 A C expression which evaluates to true if the target supports 39253 one-only semantics. 39254 39255 If you don't define this macro, 'varasm.c' provides a default 39256 definition. If 'MAKE_DECL_ONE_ONLY' is defined, the default 39257 definition is '1'; otherwise, it is '0'. Define this macro if you 39258 want to control one-only symbol support with a compiler flag, or if 39259 setting the 'DECL_ONE_ONLY' flag is enough to mark a declaration to 39260 be emitted as one-only. 39261 39262 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 39263 VISIBILITY) 39264 This target hook is a function to output to ASM_OUT_FILE some 39265 commands that will make the symbol(s) associated with DECL have 39266 hidden, protected or internal visibility as specified by 39267 VISIBILITY. 39268 39269 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 39270 A C expression that evaluates to true if the target's linker 39271 expects that weak symbols do not appear in a static archive's table 39272 of contents. The default is '0'. 39273 39274 Leaving weak symbols out of an archive's table of contents means 39275 that, if a symbol will only have a definition in one translation 39276 unit and will have undefined references from other translation 39277 units, that symbol should not be weak. Defining this macro to be 39278 nonzero will thus have the effect that certain symbols that would 39279 normally be weak (explicit template instantiations, and vtables for 39280 polymorphic classes with noninline key methods) will instead be 39281 nonweak. 39282 39283 The C++ ABI requires this macro to be zero. Define this macro for 39284 targets where full C++ ABI compliance is impossible and where 39285 linker restrictions require weak symbols to be left out of a static 39286 archive's table of contents. 39287 39288 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 39289 A C statement (sans semicolon) to output to the stdio stream STREAM 39290 any text necessary for declaring the name of an external symbol 39291 named NAME which is referenced in this compilation but not defined. 39292 The value of DECL is the tree node for the declaration. 39293 39294 This macro need not be defined if it does not need to output 39295 anything. The GNU assembler and most Unix assemblers don't require 39296 anything. 39297 39298 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 39299 This target hook is a function to output to ASM_OUT_FILE an 39300 assembler pseudo-op to declare a library function name external. 39301 The name of the library function is given by SYMREF, which is a 39302 'symbol_ref'. 39303 39304 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 39305 *SYMBOL) 39306 This target hook is a function to output to ASM_OUT_FILE an 39307 assembler directive to annotate SYMBOL as used. The Darwin target 39308 uses the .no_dead_code_strip directive. 39309 39310 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 39311 A C statement (sans semicolon) to output to the stdio stream STREAM 39312 a reference in assembler syntax to a label named NAME. This should 39313 add '_' to the front of the name, if that is customary on your 39314 operating system, as it is in most Berkeley Unix systems. This 39315 macro is used in 'assemble_name'. 39316 39317 -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME) 39318 Given a symbol NAME, perform same mangling as 'varasm.c''s 39319 'assemble_name', but in memory rather than to a file stream, 39320 returning result as an 'IDENTIFIER_NODE'. Required for correct LTO 39321 symtabs. The default implementation calls the 39322 'TARGET_STRIP_NAME_ENCODING' hook and then prepends the 39323 'USER_LABEL_PREFIX', if any. 39324 39325 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 39326 A C statement (sans semicolon) to output a reference to 39327 'SYMBOL_REF' SYM. If not defined, 'assemble_name' will be used to 39328 output the name of the symbol. This macro may be used to modify 39329 the way a symbol is referenced depending on information encoded by 39330 'TARGET_ENCODE_SECTION_INFO'. 39331 39332 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 39333 A C statement (sans semicolon) to output a reference to BUF, the 39334 result of 'ASM_GENERATE_INTERNAL_LABEL'. If not defined, 39335 'assemble_name' will be used to output the name of the symbol. 39336 This macro is not used by 'output_asm_label', or the '%l' specifier 39337 that calls it; the intention is that this macro should be set when 39338 it is necessary to output a label differently when its address is 39339 being taken. 39340 39341 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 39342 char *PREFIX, unsigned long LABELNO) 39343 A function to output to the stdio stream STREAM a label whose name 39344 is made from the string PREFIX and the number LABELNO. 39345 39346 It is absolutely essential that these labels be distinct from the 39347 labels used for user-level functions and variables. Otherwise, 39348 certain programs will have name conflicts with internal labels. 39349 39350 It is desirable to exclude internal labels from the symbol table of 39351 the object file. Most assemblers have a naming convention for 39352 labels that should be excluded; on many systems, the letter 'L' at 39353 the beginning of a label has this effect. You should find out what 39354 convention your system uses, and follow it. 39355 39356 The default version of this function utilizes 39357 'ASM_GENERATE_INTERNAL_LABEL'. 39358 39359 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 39360 A C statement to output to the stdio stream STREAM a debug info 39361 label whose name is made from the string PREFIX and the number NUM. 39362 This is useful for VLIW targets, where debug info labels may need 39363 to be treated differently than branch target labels. On some 39364 systems, branch target labels must be at the beginning of 39365 instruction bundles, but debug info labels can occur in the middle 39366 of instruction bundles. 39367 39368 If this macro is not defined, then 39369 '(*targetm.asm_out.internal_label)' will be used. 39370 39371 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 39372 A C statement to store into the string STRING a label whose name is 39373 made from the string PREFIX and the number NUM. 39374 39375 This string, when output subsequently by 'assemble_name', should 39376 produce the output that '(*targetm.asm_out.internal_label)' would 39377 produce with the same PREFIX and NUM. 39378 39379 If the string begins with '*', then 'assemble_name' will output the 39380 rest of the string unchanged. It is often convenient for 39381 'ASM_GENERATE_INTERNAL_LABEL' to use '*' in this way. If the 39382 string doesn't start with '*', then 'ASM_OUTPUT_LABELREF' gets to 39383 output the string, and may change it. (Of course, 39384 'ASM_OUTPUT_LABELREF' is also part of your machine description, so 39385 you should know what it does on your machine.) 39386 39387 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 39388 A C expression to assign to OUTVAR (which is a variable of type 39389 'char *') a newly allocated string made from the string NAME and 39390 the number NUMBER, with some suitable punctuation added. Use 39391 'alloca' to get space for the string. 39392 39393 The string will be used as an argument to 'ASM_OUTPUT_LABELREF' to 39394 produce an assembler label for an internal static variable whose 39395 name is NAME. Therefore, the string must be such as to result in 39396 valid assembler code. The argument NUMBER is different each time 39397 this macro is executed; it prevents conflicts between 39398 similarly-named internal static variables in different scopes. 39399 39400 Ideally this string should not be a valid C identifier, to prevent 39401 any conflict with the user's own symbols. Most assemblers allow 39402 periods or percent signs in assembler symbols; putting at least one 39403 of these between the name and the number will suffice. 39404 39405 If this macro is not defined, a default definition will be provided 39406 which is correct for most systems. 39407 39408 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 39409 A C statement to output to the stdio stream STREAM assembler code 39410 which defines (equates) the symbol NAME to have the value VALUE. 39411 39412 If 'SET_ASM_OP' is defined, a default definition is provided which 39413 is correct for most systems. 39414 39415 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 39416 DECL_OF_VALUE) 39417 A C statement to output to the stdio stream STREAM assembler code 39418 which defines (equates) the symbol whose tree node is DECL_OF_NAME 39419 to have the value of the tree node DECL_OF_VALUE. This macro will 39420 be used in preference to 'ASM_OUTPUT_DEF' if it is defined and if 39421 the tree nodes are available. 39422 39423 If 'SET_ASM_OP' is defined, a default definition is provided which 39424 is correct for most systems. 39425 39426 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 39427 A C statement that evaluates to true if the assembler code which 39428 defines (equates) the symbol whose tree node is DECL_OF_NAME to 39429 have the value of the tree node DECL_OF_VALUE should be emitted 39430 near the end of the current compilation unit. The default is to 39431 not defer output of defines. This macro affects defines output by 39432 'ASM_OUTPUT_DEF' and 'ASM_OUTPUT_DEF_FROM_DECLS'. 39433 39434 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 39435 A C statement to output to the stdio stream STREAM assembler code 39436 which defines (equates) the weak symbol NAME to have the value 39437 VALUE. If VALUE is 'NULL', it defines NAME as an undefined weak 39438 symbol. 39439 39440 Define this macro if the target only supports weak aliases; define 39441 'ASM_OUTPUT_DEF' instead if possible. 39442 39443 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 39444 SEL_NAME) 39445 Define this macro to override the default assembler names used for 39446 Objective-C methods. 39447 39448 The default name is a unique method number followed by the name of 39449 the class (e.g. '_1_Foo'). For methods in categories, the name of 39450 the category is also included in the assembler name (e.g. 39451 '_1_Foo_Bar'). 39452 39453 These names are safe on most systems, but make debugging difficult 39454 since the method's selector is not present in the name. Therefore, 39455 particular systems define other ways of computing names. 39456 39457 BUF is an expression of type 'char *' which gives you a buffer in 39458 which to store the name; its length is as long as CLASS_NAME, 39459 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 39460 39461 The argument IS_INST specifies whether the method is an instance 39462 method or a class method; CLASS_NAME is the name of the class; 39463 CAT_NAME is the name of the category (or 'NULL' if the method is 39464 not in a category); and SEL_NAME is the name of the selector. 39465 39466 On systems where the assembler can handle quoted names, you can use 39467 this macro to provide more human-readable names. 39468 39469 39470File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 39471 3947218.20.5 How Initialization Functions Are Handled 39473------------------------------------------------ 39474 39475The compiled code for certain languages includes "constructors" (also 39476called "initialization routines")--functions to initialize data in the 39477program when the program is started. These functions need to be called 39478before the program is "started"--that is to say, before 'main' is 39479called. 39480 39481 Compiling some languages generates "destructors" (also called 39482"termination routines") that should be called when the program 39483terminates. 39484 39485 To make the initialization and termination functions work, the compiler 39486must output something in the assembler code to cause those functions to 39487be called at the appropriate time. When you port the compiler to a new 39488system, you need to specify how to do this. 39489 39490 There are two major ways that GCC currently supports the execution of 39491initialization and termination functions. Each way has two variants. 39492Much of the structure is common to all four variations. 39493 39494 The linker must build two lists of these functions--a list of 39495initialization functions, called '__CTOR_LIST__', and a list of 39496termination functions, called '__DTOR_LIST__'. 39497 39498 Each list always begins with an ignored function pointer (which may 39499hold 0, -1, or a count of the function pointers after it, depending on 39500the environment). This is followed by a series of zero or more function 39501pointers to constructors (or destructors), followed by a function 39502pointer containing zero. 39503 39504 Depending on the operating system and its executable file format, 39505either 'crtstuff.c' or 'libgcc2.c' traverses these lists at startup time 39506and exit time. Constructors are called in reverse order of the list; 39507destructors in forward order. 39508 39509 The best way to handle static constructors works only for object file 39510formats which provide arbitrarily-named sections. A section is set 39511aside for a list of constructors, and another for a list of destructors. 39512Traditionally these are called '.ctors' and '.dtors'. Each object file 39513that defines an initialization function also puts a word in the 39514constructor section to point to that function. The linker accumulates 39515all these words into one contiguous '.ctors' section. Termination 39516functions are handled similarly. 39517 39518 This method will be chosen as the default by 'target-def.h' if 39519'TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 39520arbitrary sections, but does support special designated constructor and 39521destructor sections may define 'CTORS_SECTION_ASM_OP' and 39522'DTORS_SECTION_ASM_OP' to achieve the same effect. 39523 39524 When arbitrary sections are available, there are two variants, 39525depending upon how the code in 'crtstuff.c' is called. On systems that 39526support a ".init" section which is executed at program startup, parts of 39527'crtstuff.c' are compiled into that section. The program is linked by 39528the 'gcc' driver like this: 39529 39530 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 39531 39532 The prologue of a function ('__init') appears in the '.init' section of 39533'crti.o'; the epilogue appears in 'crtn.o'. Likewise for the function 39534'__fini' in the ".fini" section. Normally these files are provided by 39535the operating system or by the GNU C library, but are provided by GCC 39536for a few targets. 39537 39538 The objects 'crtbegin.o' and 'crtend.o' are (for most targets) compiled 39539from 'crtstuff.c'. They contain, among other things, code fragments 39540within the '.init' and '.fini' sections that branch to routines in the 39541'.text' section. The linker will pull all parts of a section together, 39542which results in a complete '__init' function that invokes the routines 39543we need at startup. 39544 39545 To use this variant, you must define the 'INIT_SECTION_ASM_OP' macro 39546properly. 39547 39548 If no init section is available, when GCC compiles any function called 39549'main' (or more accurately, any function designated as a program entry 39550point by the language front end calling 'expand_main_function'), it 39551inserts a procedure call to '__main' as the first executable code after 39552the function prologue. The '__main' function is defined in 'libgcc2.c' 39553and runs the global constructors. 39554 39555 In file formats that don't support arbitrary sections, there are again 39556two variants. In the simplest variant, the GNU linker (GNU 'ld') and an 39557'a.out' format must be used. In this case, 'TARGET_ASM_CONSTRUCTOR' is 39558defined to produce a '.stabs' entry of type 'N_SETT', referencing the 39559name '__CTOR_LIST__', and with the address of the void function 39560containing the initialization code as its value. The GNU linker 39561recognizes this as a request to add the value to a "set"; the values are 39562accumulated, and are eventually placed in the executable as a vector in 39563the format described above, with a leading (ignored) count and a 39564trailing zero element. 'TARGET_ASM_DESTRUCTOR' is handled similarly. 39565Since no init section is available, the absence of 'INIT_SECTION_ASM_OP' 39566causes the compilation of 'main' to call '__main' as above, starting the 39567initialization process. 39568 39569 The last variant uses neither arbitrary sections nor the GNU linker. 39570This is preferable when you want to do dynamic linking and when using 39571file formats which the GNU linker does not support, such as 'ECOFF'. In 39572this case, 'TARGET_HAVE_CTORS_DTORS' is false, initialization and 39573termination functions are recognized simply by their names. This 39574requires an extra program in the linkage step, called 'collect2'. This 39575program pretends to be the linker, for use with GCC; it does its job by 39576running the ordinary linker, but also arranges to include the vectors of 39577initialization and termination functions. These functions are called 39578via '__main' as described above. In order to use this method, 39579'use_collect2' must be defined in the target in 'config.gcc'. 39580 39581 The following section describes the specific macros that control and 39582customize the handling of initialization and termination functions. 39583 39584 39585File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 39586 3958718.20.6 Macros Controlling Initialization Routines 39588-------------------------------------------------- 39589 39590Here are the macros that control how the compiler handles initialization 39591and termination functions: 39592 39593 -- Macro: INIT_SECTION_ASM_OP 39594 If defined, a C string constant, including spacing, for the 39595 assembler operation to identify the following data as 39596 initialization code. If not defined, GCC will assume such a 39597 section does not exist. When you are using special sections for 39598 initialization and termination functions, this macro also controls 39599 how 'crtstuff.c' and 'libgcc2.c' arrange to run the initialization 39600 functions. 39601 39602 -- Macro: HAS_INIT_SECTION 39603 If defined, 'main' will not call '__main' as described above. This 39604 macro should be defined for systems that control start-up code on a 39605 symbol-by-symbol basis, such as OSF/1, and should not be defined 39606 explicitly for systems that support 'INIT_SECTION_ASM_OP'. 39607 39608 -- Macro: LD_INIT_SWITCH 39609 If defined, a C string constant for a switch that tells the linker 39610 that the following symbol is an initialization routine. 39611 39612 -- Macro: LD_FINI_SWITCH 39613 If defined, a C string constant for a switch that tells the linker 39614 that the following symbol is a finalization routine. 39615 39616 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 39617 If defined, a C statement that will write a function that can be 39618 automatically called when a shared library is loaded. The function 39619 should call FUNC, which takes no arguments. If not defined, and 39620 the object format requires an explicit initialization function, 39621 then a function called '_GLOBAL__DI' will be generated. 39622 39623 This function and the following one are used by collect2 when 39624 linking a shared library that needs constructors or destructors, or 39625 has DWARF2 exception tables embedded in the code. 39626 39627 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 39628 If defined, a C statement that will write a function that can be 39629 automatically called when a shared library is unloaded. The 39630 function should call FUNC, which takes no arguments. If not 39631 defined, and the object format requires an explicit finalization 39632 function, then a function called '_GLOBAL__DD' will be generated. 39633 39634 -- Macro: INVOKE__main 39635 If defined, 'main' will call '__main' despite the presence of 39636 'INIT_SECTION_ASM_OP'. This macro should be defined for systems 39637 where the init section is not actually run automatically, but is 39638 still useful for collecting the lists of constructors and 39639 destructors. 39640 39641 -- Macro: SUPPORTS_INIT_PRIORITY 39642 If nonzero, the C++ 'init_priority' attribute is supported and the 39643 compiler should emit instructions to control the order of 39644 initialization of objects. If zero, the compiler will issue an 39645 error message upon encountering an 'init_priority' attribute. 39646 39647 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 39648 This value is true if the target supports some "native" method of 39649 collecting constructors and destructors to be run at startup and 39650 exit. It is false if we must use 'collect2'. 39651 39652 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 39653 If defined, a function that outputs assembler code to arrange to 39654 call the function referenced by SYMBOL at initialization time. 39655 39656 Assume that SYMBOL is a 'SYMBOL_REF' for a function taking no 39657 arguments and with no return value. If the target supports 39658 initialization priorities, PRIORITY is a value between 0 and 39659 'MAX_INIT_PRIORITY'; otherwise it must be 'DEFAULT_INIT_PRIORITY'. 39660 39661 If this macro is not defined by the target, a suitable default will 39662 be chosen if (1) the target supports arbitrary section names, (2) 39663 the target defines 'CTORS_SECTION_ASM_OP', or (3) 'USE_COLLECT2' is 39664 not defined. 39665 39666 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 39667 This is like 'TARGET_ASM_CONSTRUCTOR' but used for termination 39668 functions rather than initialization functions. 39669 39670 If 'TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 39671generated for the generated object file will have static linkage. 39672 39673 If your system uses 'collect2' as the means of processing constructors, 39674then that program normally uses 'nm' to scan an object file for 39675constructor functions to be called. 39676 39677 On certain kinds of systems, you can define this macro to make 39678'collect2' work faster (and, in some cases, make it work at all): 39679 39680 -- Macro: OBJECT_FORMAT_COFF 39681 Define this macro if the system uses COFF (Common Object File 39682 Format) object files, so that 'collect2' can assume this format and 39683 scan object files directly for dynamic constructor/destructor 39684 functions. 39685 39686 This macro is effective only in a native compiler; 'collect2' as 39687 part of a cross compiler always uses 'nm' for the target machine. 39688 39689 -- Macro: REAL_NM_FILE_NAME 39690 Define this macro as a C string constant containing the file name 39691 to use to execute 'nm'. The default is to search the path normally 39692 for 'nm'. 39693 39694 -- Macro: NM_FLAGS 39695 'collect2' calls 'nm' to scan object files for static constructors 39696 and destructors and LTO info. By default, '-n' is passed. Define 39697 'NM_FLAGS' to a C string constant if other options are needed to 39698 get the same output format as GNU 'nm -n' produces. 39699 39700 If your system supports shared libraries and has a program to list the 39701dynamic dependencies of a given library or executable, you can define 39702these macros to enable support for running initialization and 39703termination functions in shared libraries: 39704 39705 -- Macro: LDD_SUFFIX 39706 Define this macro to a C string constant containing the name of the 39707 program which lists dynamic dependencies, like 'ldd' under SunOS 4. 39708 39709 -- Macro: PARSE_LDD_OUTPUT (PTR) 39710 Define this macro to be C code that extracts filenames from the 39711 output of the program denoted by 'LDD_SUFFIX'. PTR is a variable 39712 of type 'char *' that points to the beginning of a line of output 39713 from 'LDD_SUFFIX'. If the line lists a dynamic dependency, the 39714 code must advance PTR to the beginning of the filename on that 39715 line. Otherwise, it must set PTR to 'NULL'. 39716 39717 -- Macro: SHLIB_SUFFIX 39718 Define this macro to a C string constant containing the default 39719 shared library extension of the target (e.g., '".so"'). 'collect2' 39720 strips version information after this suffix when generating global 39721 constructor and destructor names. This define is only needed on 39722 targets that use 'collect2' to process constructors and 39723 destructors. 39724 39725 39726File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 39727 3972818.20.7 Output of Assembler Instructions 39729---------------------------------------- 39730 39731This describes assembler instruction output. 39732 39733 -- Macro: REGISTER_NAMES 39734 A C initializer containing the assembler's names for the machine 39735 registers, each one as a C string constant. This is what 39736 translates register numbers in the compiler into assembler 39737 language. 39738 39739 -- Macro: ADDITIONAL_REGISTER_NAMES 39740 If defined, a C initializer for an array of structures containing a 39741 name and a register number. This macro defines additional names 39742 for hard registers, thus allowing the 'asm' option in declarations 39743 to refer to registers using alternate names. 39744 39745 -- Macro: OVERLAPPING_REGISTER_NAMES 39746 If defined, a C initializer for an array of structures containing a 39747 name, a register number and a count of the number of consecutive 39748 machine registers the name overlaps. This macro defines additional 39749 names for hard registers, thus allowing the 'asm' option in 39750 declarations to refer to registers using alternate names. Unlike 39751 'ADDITIONAL_REGISTER_NAMES', this macro should be used when the 39752 register name implies multiple underlying registers. 39753 39754 This macro should be used when it is important that a clobber in an 39755 'asm' statement clobbers all the underlying values implied by the 39756 register name. For example, on ARM, clobbering the 39757 double-precision VFP register "d0" implies clobbering both 39758 single-precision registers "s0" and "s1". 39759 39760 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 39761 Define this macro if you are using an unusual assembler that 39762 requires different names for the machine instructions. 39763 39764 The definition is a C statement or statements which output an 39765 assembler instruction opcode to the stdio stream STREAM. The 39766 macro-operand PTR is a variable of type 'char *' which points to 39767 the opcode name in its "internal" form--the form that is written in 39768 the machine description. The definition should output the opcode 39769 name to STREAM, performing any translation you desire, and 39770 increment the variable PTR to point at the end of the opcode so 39771 that it will not be output twice. 39772 39773 In fact, your macro definition may process less than the entire 39774 opcode name, or more than the opcode name; but if you want to 39775 process text that includes '%'-sequences to substitute operands, 39776 you must take care of the substitution yourself. Just be sure to 39777 increment PTR over whatever text should not be output normally. 39778 39779 If you need to look at the operand values, they can be found as the 39780 elements of 'recog_data.operand'. 39781 39782 If the macro definition does nothing, the instruction is output in 39783 the usual way. 39784 39785 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 39786 If defined, a C statement to be executed just prior to the output 39787 of assembler code for INSN, to modify the extracted operands so 39788 they will be output differently. 39789 39790 Here the argument OPVEC is the vector containing the operands 39791 extracted from INSN, and NOPERANDS is the number of elements of the 39792 vector which contain meaningful data for this insn. The contents 39793 of this vector are what will be used to convert the insn template 39794 into assembler code, so you can change the assembler output by 39795 changing the contents of the vector. 39796 39797 This macro is useful when various assembler syntaxes share a single 39798 file of instruction patterns; by defining this macro differently, 39799 you can cause a large class of instructions to be output 39800 differently (such as with rearranged operands). Naturally, 39801 variations in assembler syntax affecting individual insn patterns 39802 ought to be handled by writing conditional output routines in those 39803 patterns. 39804 39805 If this macro is not defined, it is equivalent to a null statement. 39806 39807 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, 39808 rtx_insn *INSN, rtx *OPVEC, int NOPERANDS) 39809 If defined, this target hook is a function which is executed just 39810 after the output of assembler code for INSN, to change the mode of 39811 the assembler if necessary. 39812 39813 Here the argument OPVEC is the vector containing the operands 39814 extracted from INSN, and NOPERANDS is the number of elements of the 39815 vector which contain meaningful data for this insn. The contents 39816 of this vector are what was used to convert the insn template into 39817 assembler code, so you can change the assembler mode by checking 39818 the contents of the vector. 39819 39820 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 39821 A C compound statement to output to stdio stream STREAM the 39822 assembler syntax for an instruction operand X. X is an RTL 39823 expression. 39824 39825 CODE is a value that can be used to specify one of several ways of 39826 printing the operand. It is used when identical operands must be 39827 printed differently depending on the context. CODE comes from the 39828 '%' specification that was used to request printing of the operand. 39829 If the specification was just '%DIGIT' then CODE is 0; if the 39830 specification was '%LTR DIGIT' then CODE is the ASCII code for LTR. 39831 39832 If X is a register, this macro should print the register's name. 39833 The names can be found in an array 'reg_names' whose type is 'char 39834 *[]'. 'reg_names' is initialized from 'REGISTER_NAMES'. 39835 39836 When the machine description has a specification '%PUNCT' (a '%' 39837 followed by a punctuation character), this macro is called with a 39838 null pointer for X and the punctuation character for CODE. 39839 39840 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 39841 A C expression which evaluates to true if CODE is a valid 39842 punctuation character for use in the 'PRINT_OPERAND' macro. If 39843 'PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 39844 punctuation characters (except for the standard one, '%') are used 39845 in this way. 39846 39847 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 39848 A C compound statement to output to stdio stream STREAM the 39849 assembler syntax for an instruction operand that is a memory 39850 reference whose address is X. X is an RTL expression. 39851 39852 On some machines, the syntax for a symbolic address depends on the 39853 section that the address refers to. On these machines, define the 39854 hook 'TARGET_ENCODE_SECTION_INFO' to store the information into the 39855 'symbol_ref', and then check for it here. *Note Assembler 39856 Format::. 39857 39858 -- Macro: DBR_OUTPUT_SEQEND (FILE) 39859 A C statement, to be executed after all slot-filler instructions 39860 have been output. If necessary, call 'dbr_sequence_length' to 39861 determine the number of slots filled in a sequence (zero if not 39862 currently outputting a sequence), to decide how many no-ops to 39863 output, or whatever. 39864 39865 Don't define this macro if it has nothing to do, but it is helpful 39866 in reading assembly output if the extent of the delay sequence is 39867 made explicit (e.g. with white space). 39868 39869 Note that output routines for instructions with delay slots must be 39870prepared to deal with not being output as part of a sequence (i.e. when 39871the scheduling pass is not run, or when no slot fillers could be found.) 39872The variable 'final_sequence' is null when not processing a sequence, 39873otherwise it contains the 'sequence' rtx being output. 39874 39875 -- Macro: REGISTER_PREFIX 39876 -- Macro: LOCAL_LABEL_PREFIX 39877 -- Macro: USER_LABEL_PREFIX 39878 -- Macro: IMMEDIATE_PREFIX 39879 If defined, C string expressions to be used for the '%R', '%L', 39880 '%U', and '%I' options of 'asm_fprintf' (see 'final.c'). These are 39881 useful when a single 'md' file must support multiple assembler 39882 formats. In that case, the various 'tm.h' files can define these 39883 macros differently. 39884 39885 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 39886 If defined this macro should expand to a series of 'case' 39887 statements which will be parsed inside the 'switch' statement of 39888 the 'asm_fprintf' function. This allows targets to define extra 39889 printf formats which may useful when generating their assembler 39890 statements. Note that uppercase letters are reserved for future 39891 generic extensions to asm_fprintf, and so are not available to 39892 target specific code. The output file is given by the parameter 39893 FILE. The varargs input pointer is ARGPTR and the rest of the 39894 format string, starting the character after the one that is being 39895 switched upon, is pointed to by FORMAT. 39896 39897 -- Macro: ASSEMBLER_DIALECT 39898 If your target supports multiple dialects of assembler language 39899 (such as different opcodes), define this macro as a C expression 39900 that gives the numeric index of the assembler language dialect to 39901 use, with zero as the first variant. 39902 39903 If this macro is defined, you may use constructs of the form 39904 '{option0|option1|option2...}' 39905 in the output templates of patterns (*note Output Template::) or in 39906 the first argument of 'asm_fprintf'. This construct outputs 39907 'option0', 'option1', 'option2', etc., if the value of 39908 'ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 39909 within these strings retain their usual meaning. If there are 39910 fewer alternatives within the braces than the value of 39911 'ASSEMBLER_DIALECT', the construct outputs nothing. If it's needed 39912 to print curly braces or '|' character in assembler output 39913 directly, '%{', '%}' and '%|' can be used. 39914 39915 If you do not define this macro, the characters '{', '|' and '}' do 39916 not have any special meaning when used in templates or operands to 39917 'asm_fprintf'. 39918 39919 Define the macros 'REGISTER_PREFIX', 'LOCAL_LABEL_PREFIX', 39920 'USER_LABEL_PREFIX' and 'IMMEDIATE_PREFIX' if you can express the 39921 variations in assembler language syntax with that mechanism. 39922 Define 'ASSEMBLER_DIALECT' and use the '{option0|option1}' syntax 39923 if the syntax variant are larger and involve such things as 39924 different opcodes or operand order. 39925 39926 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 39927 A C expression to output to STREAM some assembler code which will 39928 push hard register number REGNO onto the stack. The code need not 39929 be optimal, since this macro is used only when profiling. 39930 39931 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 39932 A C expression to output to STREAM some assembler code which will 39933 pop hard register number REGNO off of the stack. The code need not 39934 be optimal, since this macro is used only when profiling. 39935 39936 39937File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 39938 3993918.20.8 Output of Dispatch Tables 39940--------------------------------- 39941 39942This concerns dispatch tables. 39943 39944 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 39945 A C statement to output to the stdio stream STREAM an assembler 39946 pseudo-instruction to generate a difference between two labels. 39947 VALUE and REL are the numbers of two internal labels. The 39948 definitions of these labels are output using 39949 '(*targetm.asm_out.internal_label)', and they must be printed in 39950 the same way here. For example, 39951 39952 fprintf (STREAM, "\t.word L%d-L%d\n", 39953 VALUE, REL) 39954 39955 You must provide this macro on machines where the addresses in a 39956 dispatch table are relative to the table's own address. If 39957 defined, GCC will also use this macro on all machines when 39958 producing PIC. BODY is the body of the 'ADDR_DIFF_VEC'; it is 39959 provided so that the mode and flags can be read. 39960 39961 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 39962 This macro should be provided on machines where the addresses in a 39963 dispatch table are absolute. 39964 39965 The definition should be a C statement to output to the stdio 39966 stream STREAM an assembler pseudo-instruction to generate a 39967 reference to a label. VALUE is the number of an internal label 39968 whose definition is output using 39969 '(*targetm.asm_out.internal_label)'. For example, 39970 39971 fprintf (STREAM, "\t.word L%d\n", VALUE) 39972 39973 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 39974 Define this if the label before a jump-table needs to be output 39975 specially. The first three arguments are the same as for 39976 '(*targetm.asm_out.internal_label)'; the fourth argument is the 39977 jump-table which follows (a 'jump_table_data' containing an 39978 'addr_vec' or 'addr_diff_vec'). 39979 39980 This feature is used on system V to output a 'swbeg' statement for 39981 the table. 39982 39983 If this macro is not defined, these labels are output with 39984 '(*targetm.asm_out.internal_label)'. 39985 39986 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 39987 Define this if something special must be output at the end of a 39988 jump-table. The definition should be a C statement to be executed 39989 after the assembler code for the table is written. It should write 39990 the appropriate code to stdio stream STREAM. The argument TABLE is 39991 the jump-table insn, and NUM is the label-number of the preceding 39992 label. 39993 39994 If this macro is not defined, nothing special is output at the end 39995 of the jump-table. 39996 39997 -- Target Hook: void TARGET_ASM_POST_CFI_STARTPROC (FILE *, TREE) 39998 This target hook is used to emit assembly strings required by the 39999 target after the .cfi_startproc directive. The first argument is 40000 the file stream to write the strings to and the second argument is 40001 the function's declaration. The expected use is to add more .cfi_* 40002 directives. 40003 40004 The default is to not output any assembly strings. 40005 40006 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 40007 DECL, int FOR_EH, int EMPTY) 40008 This target hook emits a label at the beginning of each FDE. It 40009 should be defined on targets where FDEs need special labels, and it 40010 should write the appropriate label, for the FDE associated with the 40011 function declaration DECL, to the stdio stream STREAM. The third 40012 argument, FOR_EH, is a boolean: true if this is for an exception 40013 table. The fourth argument, EMPTY, is a boolean: true if this is a 40014 placeholder label for an omitted FDE. 40015 40016 The default is that FDEs are not given nonlocal labels. 40017 40018 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 40019 This target hook emits a label at the beginning of the exception 40020 table. It should be defined on targets where it is desirable for 40021 the table to be broken up according to function. 40022 40023 The default is that no label is emitted. 40024 40025 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx 40026 PERSONALITY) 40027 If the target implements 'TARGET_ASM_UNWIND_EMIT', this hook may be 40028 used to emit a directive to install a personality hook into the 40029 unwind info. This hook should not be used if dwarf2 unwind info is 40030 used. 40031 40032 -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx_insn 40033 *INSN) 40034 This target hook emits assembly directives required to unwind the 40035 given instruction. This is only used when 40036 'TARGET_EXCEPT_UNWIND_INFO' returns 'UI_TARGET'. 40037 40038 -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN 40039 True if the 'TARGET_ASM_UNWIND_EMIT' hook should be called before 40040 the assembly for INSN has been emitted, false if the hook should be 40041 called afterward. 40042 40043 -- Target Hook: bool TARGET_ASM_SHOULD_RESTORE_CFA_STATE (void) 40044 For DWARF-based unwind frames, two CFI instructions provide for 40045 save and restore of register state. GCC maintains the current 40046 frame address (CFA) separately from the register bank but the 40047 unwinder in libgcc preserves this state along with the registers 40048 (and this is expected by the code that writes the unwind frames). 40049 This hook allows the target to specify that the CFA data is not 40050 saved/restored along with the registers by the target unwinder so 40051 that suitable additional instructions should be emitted to restore 40052 it. 40053 40054 40055File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 40056 4005718.20.9 Assembler Commands for Exception Regions 40058------------------------------------------------ 40059 40060This describes commands marking the start and the end of an exception 40061region. 40062 40063 -- Macro: EH_FRAME_SECTION_NAME 40064 If defined, a C string constant for the name of the section 40065 containing exception handling frame unwind information. If not 40066 defined, GCC will provide a default definition if the target 40067 supports named sections. 'crtstuff.c' uses this macro to switch to 40068 the appropriate section. 40069 40070 You should define this symbol if your target supports DWARF 2 frame 40071 unwind information and the default definition does not work. 40072 40073 -- Macro: EH_FRAME_THROUGH_COLLECT2 40074 If defined, DWARF 2 frame unwind information will identified by 40075 specially named labels. The collect2 process will locate these 40076 labels and generate code to register the frames. 40077 40078 This might be necessary, for instance, if the system linker will 40079 not place the eh_frames in-between the sentinals from 'crtstuff.c', 40080 or if the system linker does garbage collection and sections cannot 40081 be marked as not to be collected. 40082 40083 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 40084 Define this macro to 1 if your target is such that no frame unwind 40085 information encoding used with non-PIC code will ever require a 40086 runtime relocation, but the linker may not support merging 40087 read-only and read-write sections into a single read-write section. 40088 40089 -- Macro: MASK_RETURN_ADDR 40090 An rtx used to mask the return address found via 'RETURN_ADDR_RTX', 40091 so that it does not contain any extraneous set bits in it. 40092 40093 -- Macro: DWARF2_UNWIND_INFO 40094 Define this macro to 0 if your target supports DWARF 2 frame unwind 40095 information, but it does not yet work with exception handling. 40096 Otherwise, if your target supports this information (if it defines 40097 'INCOMING_RETURN_ADDR_RTX' and 'OBJECT_FORMAT_ELF'), GCC will 40098 provide a default definition of 1. 40099 40100 -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO 40101 (struct gcc_options *OPTS) 40102 This hook defines the mechanism that will be used for exception 40103 handling by the target. If the target has ABI specified unwind 40104 tables, the hook should return 'UI_TARGET'. If the target is to 40105 use the 'setjmp'/'longjmp'-based exception handling scheme, the 40106 hook should return 'UI_SJLJ'. If the target supports DWARF 2 frame 40107 unwind information, the hook should return 'UI_DWARF2'. 40108 40109 A target may, if exceptions are disabled, choose to return 40110 'UI_NONE'. This may end up simplifying other parts of 40111 target-specific code. The default implementation of this hook 40112 never returns 'UI_NONE'. 40113 40114 Note that the value returned by this hook should be constant. It 40115 should not depend on anything except the command-line switches 40116 described by OPTS. In particular, the setting 'UI_SJLJ' must be 40117 fixed at compiler start-up as C pre-processor macros and builtin 40118 functions related to exception handling are set up depending on 40119 this setting. 40120 40121 The default implementation of the hook first honors the 40122 '--enable-sjlj-exceptions' configure option, then 40123 'DWARF2_UNWIND_INFO', and finally defaults to 'UI_SJLJ'. If 40124 'DWARF2_UNWIND_INFO' depends on command-line options, the target 40125 must define this hook so that OPTS is used correctly. 40126 40127 -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 40128 This variable should be set to 'true' if the target ABI requires 40129 unwinding tables even when exceptions are not used. It must not be 40130 modified by command-line option processing. 40131 40132 -- Macro: DONT_USE_BUILTIN_SETJMP 40133 Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme 40134 should use the 'setjmp'/'longjmp' functions from the C library 40135 instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery. 40136 40137 -- Macro: JMP_BUF_SIZE 40138 This macro has no effect unless 'DONT_USE_BUILTIN_SETJMP' is also 40139 defined. Define this macro if the default size of 'jmp_buf' buffer 40140 for the 'setjmp'/'longjmp'-based exception handling mechanism is 40141 not large enough, or if it is much too large. The default size is 40142 'FIRST_PSEUDO_REGISTER * sizeof(void *)'. 40143 40144 -- Macro: DWARF_CIE_DATA_ALIGNMENT 40145 This macro need only be defined if the target might save registers 40146 in the function prologue at an offset to the stack pointer that is 40147 not aligned to 'UNITS_PER_WORD'. The definition should be the 40148 negative minimum alignment if 'STACK_GROWS_DOWNWARD' is true, and 40149 the positive minimum alignment otherwise. *Note DWARF::. Only 40150 applicable if the target supports DWARF 2 frame unwind information. 40151 40152 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 40153 Contains the value true if the target should add a zero word onto 40154 the end of a Dwarf-2 frame info section when used for exception 40155 handling. Default value is false if 'EH_FRAME_SECTION_NAME' is 40156 defined, and true otherwise. 40157 40158 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 40159 Given a register, this hook should return a parallel of registers 40160 to represent where to find the register pieces. Define this hook 40161 if the register and its mode are represented in Dwarf in 40162 non-contiguous locations, or if the register should be represented 40163 in more than one register in Dwarf. Otherwise, this hook should 40164 return 'NULL_RTX'. If not defined, the default is to return 40165 'NULL_RTX'. 40166 40167 -- Target Hook: machine_mode TARGET_DWARF_FRAME_REG_MODE (int REGNO) 40168 Given a register, this hook should return the mode which the 40169 corresponding Dwarf frame register should have. This is normally 40170 used to return a smaller mode than the raw mode to prevent call 40171 clobbered parts of a register altering the frame register size 40172 40173 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 40174 If some registers are represented in Dwarf-2 unwind information in 40175 multiple pieces, define this hook to fill in information about the 40176 sizes of those pieces in the table used by the unwinder at runtime. 40177 It will be called by 'expand_builtin_init_dwarf_reg_sizes' after 40178 filling in a single size corresponding to each hard register; 40179 ADDRESS is the address of the table. 40180 40181 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 40182 This hook is used to output a reference from a frame unwinding 40183 table to the type_info object identified by SYM. It should return 40184 'true' if the reference was output. Returning 'false' will cause 40185 the reference to be output using the normal Dwarf2 routines. 40186 40187 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 40188 This flag should be set to 'true' on targets that use an ARM EABI 40189 based unwinding library, and 'false' on other targets. This 40190 effects the format of unwinding tables, and how the unwinder in 40191 entered after running a cleanup. The default is 'false'. 40192 40193 40194File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 40195 4019618.20.10 Assembler Commands for Alignment 40197----------------------------------------- 40198 40199This describes commands for alignment. 40200 40201 -- Macro: JUMP_ALIGN (LABEL) 40202 The alignment (log base 2) to put in front of LABEL, which is a 40203 common destination of jumps and has no fallthru incoming edge. 40204 40205 This macro need not be defined if you don't want any special 40206 alignment to be done at such a time. Most machine descriptions do 40207 not currently define the macro. 40208 40209 Unless it's necessary to inspect the LABEL parameter, it is better 40210 to set the variable ALIGN_JUMPS in the target's 40211 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 40212 user's selection in ALIGN_JUMPS in a 'JUMP_ALIGN' implementation. 40213 40214 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 40215 The alignment (log base 2) to put in front of LABEL, which follows 40216 a 'BARRIER'. 40217 40218 This macro need not be defined if you don't want any special 40219 alignment to be done at such a time. Most machine descriptions do 40220 not currently define the macro. 40221 40222 -- Macro: LOOP_ALIGN (LABEL) 40223 The alignment (log base 2) to put in front of LABEL that heads a 40224 frequently executed basic block (usually the header of a loop). 40225 40226 This macro need not be defined if you don't want any special 40227 alignment to be done at such a time. Most machine descriptions do 40228 not currently define the macro. 40229 40230 Unless it's necessary to inspect the LABEL parameter, it is better 40231 to set the variable 'align_loops' in the target's 40232 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 40233 user's selection in 'align_loops' in a 'LOOP_ALIGN' implementation. 40234 40235 -- Macro: LABEL_ALIGN (LABEL) 40236 The alignment (log base 2) to put in front of LABEL. If 40237 'LABEL_ALIGN_AFTER_BARRIER' / 'LOOP_ALIGN' specify a different 40238 alignment, the maximum of the specified values is used. 40239 40240 Unless it's necessary to inspect the LABEL parameter, it is better 40241 to set the variable 'align_labels' in the target's 40242 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 40243 user's selection in 'align_labels' in a 'LABEL_ALIGN' 40244 implementation. 40245 40246 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 40247 A C statement to output to the stdio stream STREAM an assembler 40248 instruction to advance the location counter by NBYTES bytes. Those 40249 bytes should be zero when loaded. NBYTES will be a C expression of 40250 type 'unsigned HOST_WIDE_INT'. 40251 40252 -- Macro: ASM_NO_SKIP_IN_TEXT 40253 Define this macro if 'ASM_OUTPUT_SKIP' should not be used in the 40254 text section because it fails to put zeros in the bytes that are 40255 skipped. This is true on many Unix systems, where the pseudo-op to 40256 skip bytes produces no-op instructions rather than zeros when used 40257 in the text section. 40258 40259 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 40260 A C statement to output to the stdio stream STREAM an assembler 40261 command to advance the location counter to a multiple of 2 to the 40262 POWER bytes. POWER will be a C expression of type 'int'. 40263 40264 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 40265 Like 'ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 40266 for padding, if necessary. 40267 40268 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 40269 A C statement to output to the stdio stream STREAM an assembler 40270 command to advance the location counter to a multiple of 2 to the 40271 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 40272 satisfy the alignment request. POWER and MAX_SKIP will be a C 40273 expression of type 'int'. 40274 40275 40276File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 40277 4027818.21 Controlling Debugging Information Format 40279============================================== 40280 40281This describes how to specify debugging information. 40282 40283* Menu: 40284 40285* All Debuggers:: Macros that affect all debugging formats uniformly. 40286* DBX Options:: Macros enabling specific options in DBX format. 40287* DBX Hooks:: Hook macros for varying DBX format. 40288* File Names and DBX:: Macros controlling output of file names in DBX format. 40289* DWARF:: Macros for DWARF format. 40290* VMS Debug:: Macros for VMS debug format. 40291 40292 40293File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 40294 4029518.21.1 Macros Affecting All Debugging Formats 40296---------------------------------------------- 40297 40298These macros affect all debugging formats. 40299 40300 -- Macro: DBX_REGISTER_NUMBER (REGNO) 40301 A C expression that returns the DBX register number for the 40302 compiler register number REGNO. In the default macro provided, the 40303 value of this expression will be REGNO itself. But sometimes there 40304 are some registers that the compiler knows about and DBX does not, 40305 or vice versa. In such cases, some register may need to have one 40306 number in the compiler and another for DBX. 40307 40308 If two registers have consecutive numbers inside GCC, and they can 40309 be used as a pair to hold a multiword value, then they _must_ have 40310 consecutive numbers after renumbering with 'DBX_REGISTER_NUMBER'. 40311 Otherwise, debuggers will be unable to access such a pair, because 40312 they expect register pairs to be consecutive in their own numbering 40313 scheme. 40314 40315 If you find yourself defining 'DBX_REGISTER_NUMBER' in way that 40316 does not preserve register pairs, then what you must do instead is 40317 redefine the actual register numbering scheme. 40318 40319 -- Macro: DEBUGGER_AUTO_OFFSET (X) 40320 A C expression that returns the integer offset value for an 40321 automatic variable having address X (an RTL expression). The 40322 default computation assumes that X is based on the frame-pointer 40323 and gives the offset from the frame-pointer. This is required for 40324 targets that produce debugging output for DBX and allow the 40325 frame-pointer to be eliminated when the '-g' option is used. 40326 40327 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 40328 A C expression that returns the integer offset value for an 40329 argument having address X (an RTL expression). The nominal offset 40330 is OFFSET. 40331 40332 -- Macro: PREFERRED_DEBUGGING_TYPE 40333 A C expression that returns the type of debugging output GCC should 40334 produce when the user specifies just '-g'. Define this if you have 40335 arranged for GCC to support more than one format of debugging 40336 output. Currently, the allowable values are 'DBX_DEBUG', 40337 'DWARF2_DEBUG', 'XCOFF_DEBUG', 'VMS_DEBUG', and 40338 'VMS_AND_DWARF2_DEBUG'. 40339 40340 When the user specifies '-ggdb', GCC normally also uses the value 40341 of this macro to select the debugging output format, but with two 40342 exceptions. If 'DWARF2_DEBUGGING_INFO' is defined, GCC uses the 40343 value 'DWARF2_DEBUG'. Otherwise, if 'DBX_DEBUGGING_INFO' is 40344 defined, GCC uses 'DBX_DEBUG'. 40345 40346 The value of this macro only affects the default debugging output; 40347 the user can always get a specific type of output by using 40348 '-gstabs', '-gdwarf-2', '-gxcoff', or '-gvms'. 40349 40350 40351File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 40352 4035318.21.2 Specific Options for DBX Output 40354--------------------------------------- 40355 40356These are specific options for DBX output. 40357 40358 -- Macro: DBX_DEBUGGING_INFO 40359 Define this macro if GCC should produce debugging output for DBX in 40360 response to the '-g' option. 40361 40362 -- Macro: XCOFF_DEBUGGING_INFO 40363 Define this macro if GCC should produce XCOFF format debugging 40364 output in response to the '-g' option. This is a variant of DBX 40365 format. 40366 40367 -- Macro: DEFAULT_GDB_EXTENSIONS 40368 Define this macro to control whether GCC should by default generate 40369 GDB's extended version of DBX debugging information (assuming 40370 DBX-format debugging information is enabled at all). If you don't 40371 define the macro, the default is 1: always generate the extended 40372 information if there is any occasion to. 40373 40374 -- Macro: DEBUG_SYMS_TEXT 40375 Define this macro if all '.stabs' commands should be output while 40376 in the text section. 40377 40378 -- Macro: ASM_STABS_OP 40379 A C string constant, including spacing, naming the assembler pseudo 40380 op to use instead of '"\t.stabs\t"' to define an ordinary debugging 40381 symbol. If you don't define this macro, '"\t.stabs\t"' is used. 40382 This macro applies only to DBX debugging information format. 40383 40384 -- Macro: ASM_STABD_OP 40385 A C string constant, including spacing, naming the assembler pseudo 40386 op to use instead of '"\t.stabd\t"' to define a debugging symbol 40387 whose value is the current location. If you don't define this 40388 macro, '"\t.stabd\t"' is used. This macro applies only to DBX 40389 debugging information format. 40390 40391 -- Macro: ASM_STABN_OP 40392 A C string constant, including spacing, naming the assembler pseudo 40393 op to use instead of '"\t.stabn\t"' to define a debugging symbol 40394 with no name. If you don't define this macro, '"\t.stabn\t"' is 40395 used. This macro applies only to DBX debugging information format. 40396 40397 -- Macro: DBX_NO_XREFS 40398 Define this macro if DBX on your system does not support the 40399 construct 'xsTAGNAME'. On some systems, this construct is used to 40400 describe a forward reference to a structure named TAGNAME. On 40401 other systems, this construct is not supported at all. 40402 40403 -- Macro: DBX_CONTIN_LENGTH 40404 A symbol name in DBX-format debugging information is normally 40405 continued (split into two separate '.stabs' directives) when it 40406 exceeds a certain length (by default, 80 characters). On some 40407 operating systems, DBX requires this splitting; on others, 40408 splitting must not be done. You can inhibit splitting by defining 40409 this macro with the value zero. You can override the default 40410 splitting-length by defining this macro as an expression for the 40411 length you desire. 40412 40413 -- Macro: DBX_CONTIN_CHAR 40414 Normally continuation is indicated by adding a '\' character to the 40415 end of a '.stabs' string when a continuation follows. To use a 40416 different character instead, define this macro as a character 40417 constant for the character you want to use. Do not define this 40418 macro if backslash is correct for your system. 40419 40420 -- Macro: DBX_STATIC_STAB_DATA_SECTION 40421 Define this macro if it is necessary to go to the data section 40422 before outputting the '.stabs' pseudo-op for a non-global static 40423 variable. 40424 40425 -- Macro: DBX_TYPE_DECL_STABS_CODE 40426 The value to use in the "code" field of the '.stabs' directive for 40427 a typedef. The default is 'N_LSYM'. 40428 40429 -- Macro: DBX_STATIC_CONST_VAR_CODE 40430 The value to use in the "code" field of the '.stabs' directive for 40431 a static variable located in the text section. DBX format does not 40432 provide any "right" way to do this. The default is 'N_FUN'. 40433 40434 -- Macro: DBX_REGPARM_STABS_CODE 40435 The value to use in the "code" field of the '.stabs' directive for 40436 a parameter passed in registers. DBX format does not provide any 40437 "right" way to do this. The default is 'N_RSYM'. 40438 40439 -- Macro: DBX_REGPARM_STABS_LETTER 40440 The letter to use in DBX symbol data to identify a symbol as a 40441 parameter passed in registers. DBX format does not customarily 40442 provide any way to do this. The default is ''P''. 40443 40444 -- Macro: DBX_FUNCTION_FIRST 40445 Define this macro if the DBX information for a function and its 40446 arguments should precede the assembler code for the function. 40447 Normally, in DBX format, the debugging information entirely follows 40448 the assembler code. 40449 40450 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 40451 Define this macro, with value 1, if the value of a symbol 40452 describing the scope of a block ('N_LBRAC' or 'N_RBRAC') should be 40453 relative to the start of the enclosing function. Normally, GCC 40454 uses an absolute address. 40455 40456 -- Macro: DBX_LINES_FUNCTION_RELATIVE 40457 Define this macro, with value 1, if the value of a symbol 40458 indicating the current line number ('N_SLINE') should be relative 40459 to the start of the enclosing function. Normally, GCC uses an 40460 absolute address. 40461 40462 -- Macro: DBX_USE_BINCL 40463 Define this macro if GCC should generate 'N_BINCL' and 'N_EINCL' 40464 stabs for included header files, as on Sun systems. This macro 40465 also directs GCC to output a type number as a pair of a file number 40466 and a type number within the file. Normally, GCC does not generate 40467 'N_BINCL' or 'N_EINCL' stabs, and it outputs a single number for a 40468 type number. 40469 40470 40471File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 40472 4047318.21.3 Open-Ended Hooks for DBX Format 40474--------------------------------------- 40475 40476These are hooks for DBX format. 40477 40478 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 40479 A C statement to output DBX debugging information before code for 40480 line number LINE of the current source file to the stdio stream 40481 STREAM. COUNTER is the number of time the macro was invoked, 40482 including the current invocation; it is intended to generate unique 40483 labels in the assembly output. 40484 40485 This macro should not be defined if the default output is correct, 40486 or if it can be made correct by defining 40487 'DBX_LINES_FUNCTION_RELATIVE'. 40488 40489 -- Macro: NO_DBX_FUNCTION_END 40490 Some stabs encapsulation formats (in particular ECOFF), cannot 40491 handle the '.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 40492 extension construct. On those machines, define this macro to turn 40493 this feature off without disturbing the rest of the gdb extensions. 40494 40495 -- Macro: NO_DBX_BNSYM_ENSYM 40496 Some assemblers cannot handle the '.stabd BNSYM/ENSYM,0,0' gdb dbx 40497 extension construct. On those machines, define this macro to turn 40498 this feature off without disturbing the rest of the gdb extensions. 40499 40500 40501File: gccint.info, Node: File Names and DBX, Next: DWARF, Prev: DBX Hooks, Up: Debugging Info 40502 4050318.21.4 File Names in DBX Format 40504-------------------------------- 40505 40506This describes file names in DBX format. 40507 40508 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 40509 A C statement to output DBX debugging information to the stdio 40510 stream STREAM, which indicates that file NAME is the main source 40511 file--the file specified as the input file for compilation. This 40512 macro is called only once, at the beginning of compilation. 40513 40514 This macro need not be defined if the standard form of output for 40515 DBX debugging information is appropriate. 40516 40517 It may be necessary to refer to a label equal to the beginning of 40518 the text section. You can use 'assemble_name (stream, 40519 ltext_label_name)' to do so. If you do this, you must also set the 40520 variable USED_LTEXT_LABEL_NAME to 'true'. 40521 40522 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 40523 Define this macro, with value 1, if GCC should not emit an 40524 indication of the current directory for compilation and current 40525 source language at the beginning of the file. 40526 40527 -- Macro: NO_DBX_GCC_MARKER 40528 Define this macro, with value 1, if GCC should not emit an 40529 indication that this object file was compiled by GCC. The default 40530 is to emit an 'N_OPT' stab at the beginning of every source file, 40531 with 'gcc2_compiled.' for the string and value 0. 40532 40533 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 40534 A C statement to output DBX debugging information at the end of 40535 compilation of the main source file NAME. Output should be written 40536 to the stdio stream STREAM. 40537 40538 If you don't define this macro, nothing special is output at the 40539 end of compilation, which is correct for most machines. 40540 40541 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 40542 Define this macro _instead of_ defining 40543 'DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 40544 the end of compilation is an 'N_SO' stab with an empty string, 40545 whose value is the highest absolute text address in the file. 40546 40547 40548File: gccint.info, Node: DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 40549 4055018.21.5 Macros for DWARF Output 40551------------------------------- 40552 40553Here are macros for DWARF output. 40554 40555 -- Macro: DWARF2_DEBUGGING_INFO 40556 Define this macro if GCC should produce dwarf version 2 format 40557 debugging output in response to the '-g' option. 40558 40559 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 40560 FUNCTION) 40561 Define this to enable the dwarf attribute 40562 'DW_AT_calling_convention' to be emitted for each function. 40563 Instead of an integer return the enum value for the 'DW_CC_' 40564 tag. 40565 40566 To support optional call frame debugging information, you must also 40567 define 'INCOMING_RETURN_ADDR_RTX' and either set 40568 'RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 40569 prologue, or call 'dwarf2out_def_cfa' and 'dwarf2out_reg_save' as 40570 appropriate from 'TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 40571 40572 -- Macro: DWARF2_FRAME_INFO 40573 Define this macro to a nonzero value if GCC should always output 40574 Dwarf 2 frame information. If 'TARGET_EXCEPT_UNWIND_INFO' (*note 40575 Exception Region Output::) returns 'UI_DWARF2', and exceptions are 40576 enabled, GCC will output this information not matter how you define 40577 'DWARF2_FRAME_INFO'. 40578 40579 -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void) 40580 This hook defines the mechanism that will be used for describing 40581 frame unwind information to the debugger. Normally the hook will 40582 return 'UI_DWARF2' if DWARF 2 debug information is enabled, and 40583 return 'UI_NONE' otherwise. 40584 40585 A target may return 'UI_DWARF2' even when DWARF 2 debug information 40586 is disabled in order to always output DWARF 2 frame information. 40587 40588 A target may return 'UI_TARGET' if it has ABI specified unwind 40589 tables. This will suppress generation of the normal debug frame 40590 unwind information. 40591 40592 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 40593 Define this macro to be a nonzero value if the assembler can 40594 generate Dwarf 2 line debug info sections. This will result in 40595 much more compact line number tables, and hence is desirable if it 40596 works. 40597 40598 -- Macro: DWARF2_ASM_VIEW_DEBUG_INFO 40599 Define this macro to be a nonzero value if the assembler supports 40600 view assignment and verification in '.loc'. If it does not, but 40601 the user enables location views, the compiler may have to fallback 40602 to internal line number tables. 40603 40604 -- Target Hook: int TARGET_RESET_LOCATION_VIEW (rtx_insn *) 40605 This hook, if defined, enables -ginternal-reset-location-views, and 40606 uses its result to override cases in which the estimated min insn 40607 length might be nonzero even when a PC advance (i.e., a view reset) 40608 cannot be taken for granted. 40609 40610 If the hook is defined, it must return a positive value to indicate 40611 the insn definitely advances the PC, and so the view number can be 40612 safely assumed to be reset; a negative value to mean the insn 40613 definitely does not advance the PC, and os the view number must not 40614 be reset; or zero to decide based on the estimated insn length. 40615 40616 If insn length is to be regarded as reliable, set the hook to 40617 'hook_int_rtx_insn_0'. 40618 40619 -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS 40620 True if the '.debug_pubtypes' and '.debug_pubnames' sections should 40621 be emitted. These sections are not used on most platforms, and in 40622 particular GDB does not use them. 40623 40624 -- Target Hook: bool TARGET_DELAY_SCHED2 40625 True if sched2 is not to be run at its normal place. This usually 40626 means it will be run as part of machine-specific reorg. 40627 40628 -- Target Hook: bool TARGET_DELAY_VARTRACK 40629 True if vartrack is not to be run at its normal place. This 40630 usually means it will be run as part of machine-specific reorg. 40631 40632 -- Target Hook: bool TARGET_NO_REGISTER_ALLOCATION 40633 True if register allocation and the passes following it should not 40634 be run. Usually true only for virtual assembler targets. 40635 40636 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 40637 A C statement to issue assembly directives that create a difference 40638 LAB1 minus LAB2, using an integer of the given SIZE. 40639 40640 -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2) 40641 A C statement to issue assembly directives that create a difference 40642 between the two given labels in system defined units, e.g. 40643 instruction slots on IA64 VMS, using an integer of the given size. 40644 40645 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, OFFSET, 40646 SECTION) 40647 A C statement to issue assembly directives that create a 40648 section-relative reference to the given LABEL plus OFFSET, using an 40649 integer of the given SIZE. The label is known to be defined in the 40650 given SECTION. 40651 40652 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 40653 A C statement to issue assembly directives that create a 40654 self-relative reference to the given LABEL, using an integer of the 40655 given SIZE. 40656 40657 -- Macro: ASM_OUTPUT_DWARF_DATAREL (STREAM, SIZE, LABEL) 40658 A C statement to issue assembly directives that create a reference 40659 to the given LABEL relative to the dbase, using an integer of the 40660 given SIZE. 40661 40662 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 40663 A C statement to issue assembly directives that create a reference 40664 to the DWARF table identifier LABEL from the current section. This 40665 is used on some systems to avoid garbage collecting a DWARF table 40666 which is referenced by a function. 40667 40668 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 40669 SIZE, rtx X) 40670 If defined, this target hook is a function which outputs a 40671 DTP-relative reference to the given TLS symbol of the specified 40672 size. 40673 40674 40675File: gccint.info, Node: VMS Debug, Prev: DWARF, Up: Debugging Info 40676 4067718.21.6 Macros for VMS Debug Format 40678----------------------------------- 40679 40680Here are macros for VMS debug format. 40681 40682 -- Macro: VMS_DEBUGGING_INFO 40683 Define this macro if GCC should produce debugging output for VMS in 40684 response to the '-g' option. The default behavior for VMS is to 40685 generate minimal debug info for a traceback in the absence of '-g' 40686 unless explicitly overridden with '-g0'. This behavior is 40687 controlled by 'TARGET_OPTION_OPTIMIZATION' and 40688 'TARGET_OPTION_OVERRIDE'. 40689 40690 40691File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 40692 4069318.22 Cross Compilation and Floating Point 40694========================================== 40695 40696While all modern machines use twos-complement representation for 40697integers, there are a variety of representations for floating point 40698numbers. This means that in a cross-compiler the representation of 40699floating point numbers in the compiled program may be different from 40700that used in the machine doing the compilation. 40701 40702 Because different representation systems may offer different amounts of 40703range and precision, all floating point constants must be represented in 40704the target machine's format. Therefore, the cross compiler cannot 40705safely use the host machine's floating point arithmetic; it must emulate 40706the target's arithmetic. To ensure consistency, GCC always uses 40707emulation to work with floating point values, even when the host and 40708target floating point formats are identical. 40709 40710 The following macros are provided by 'real.h' for the compiler to use. 40711All parts of the compiler which generate or optimize floating-point 40712calculations must use these macros. They may evaluate their operands 40713more than once, so operands must not have side effects. 40714 40715 -- Macro: REAL_VALUE_TYPE 40716 The C data type to be used to hold a floating point value in the 40717 target machine's format. Typically this is a 'struct' containing 40718 an array of 'HOST_WIDE_INT', but all code should treat it as an 40719 opaque quantity. 40720 40721 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 40722 Truncates X to a signed integer, rounding toward zero. 40723 40724 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 40725 (REAL_VALUE_TYPE X) 40726 Truncates X to an unsigned integer, rounding toward zero. If X is 40727 negative, returns zero. 40728 40729 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, 40730 machine_mode MODE) 40731 Converts STRING into a floating point number in the target 40732 machine's representation for mode MODE. This routine can handle 40733 both decimal and hexadecimal floating point constants, using the 40734 syntax defined by the C language for both. 40735 40736 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 40737 Returns 1 if X is negative (including negative zero), 0 otherwise. 40738 40739 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 40740 Determines whether X represents infinity (positive or negative). 40741 40742 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 40743 Determines whether X represents a "NaN" (not-a-number). 40744 40745 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 40746 Returns the negative of the floating point value X. 40747 40748 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 40749 Returns the absolute value of X. 40750 40751 40752File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 40753 4075418.23 Mode Switching Instructions 40755================================= 40756 40757The following macros control mode switching optimizations: 40758 40759 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 40760 Define this macro if the port needs extra instructions inserted for 40761 mode switching in an optimizing compilation. 40762 40763 For an example, the SH4 can perform both single and double 40764 precision floating point operations, but to perform a single 40765 precision operation, the FPSCR PR bit has to be cleared, while for 40766 a double precision operation, this bit has to be set. Changing the 40767 PR bit requires a general purpose register as a scratch register, 40768 hence these FPSCR sets have to be inserted before reload, i.e. you 40769 cannot put this into instruction emitting or 40770 'TARGET_MACHINE_DEPENDENT_REORG'. 40771 40772 You can have multiple entities that are mode-switched, and select 40773 at run time which entities actually need it. 40774 'OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY that 40775 needs mode-switching. If you define this macro, you also have to 40776 define 'NUM_MODES_FOR_MODE_SWITCHING', 'TARGET_MODE_NEEDED', 40777 'TARGET_MODE_PRIORITY' and 'TARGET_MODE_EMIT'. 40778 'TARGET_MODE_AFTER', 'TARGET_MODE_ENTRY', and 'TARGET_MODE_EXIT' 40779 are optional. 40780 40781 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 40782 If you define 'OPTIMIZE_MODE_SWITCHING', you have to define this as 40783 initializer for an array of integers. Each initializer element N 40784 refers to an entity that needs mode switching, and specifies the 40785 number of different modes that might need to be set for this 40786 entity. The position of the initializer in the 40787 initializer--starting counting at zero--determines the integer that 40788 is used to refer to the mode-switched entity in question. In 40789 macros that take mode arguments / yield a mode result, modes are 40790 represented as numbers 0 ... N - 1. N is used to specify that no 40791 mode switch is needed / supplied. 40792 40793 -- Target Hook: void TARGET_MODE_EMIT (int ENTITY, int MODE, int 40794 PREV_MODE, HARD_REG_SET REGS_LIVE) 40795 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE is 40796 the set of hard registers live at the point where the insn(s) are 40797 to be inserted. PREV_MOXDE indicates the mode to switch from. 40798 Sets of a lower numbered entity will be emitted before sets of a 40799 higher numbered entity to a mode of the same or lower priority. 40800 40801 -- Target Hook: int TARGET_MODE_NEEDED (int ENTITY, rtx_insn *INSN) 40802 ENTITY is an integer specifying a mode-switched entity. If 40803 'OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 40804 return an integer value not larger than the corresponding element 40805 in 'NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 40806 must be switched into prior to the execution of INSN. 40807 40808 -- Target Hook: int TARGET_MODE_AFTER (int ENTITY, int MODE, rtx_insn 40809 *INSN) 40810 ENTITY is an integer specifying a mode-switched entity. If this 40811 macro is defined, it is evaluated for every INSN during mode 40812 switching. It determines the mode that an insn results in (if 40813 different from the incoming mode). 40814 40815 -- Target Hook: int TARGET_MODE_ENTRY (int ENTITY) 40816 If this macro is defined, it is evaluated for every ENTITY that 40817 needs mode switching. It should evaluate to an integer, which is a 40818 mode that ENTITY is assumed to be switched to at function entry. 40819 If 'TARGET_MODE_ENTRY' is defined then 'TARGET_MODE_EXIT' must be 40820 defined. 40821 40822 -- Target Hook: int TARGET_MODE_EXIT (int ENTITY) 40823 If this macro is defined, it is evaluated for every ENTITY that 40824 needs mode switching. It should evaluate to an integer, which is a 40825 mode that ENTITY is assumed to be switched to at function exit. If 40826 'TARGET_MODE_EXIT' is defined then 'TARGET_MODE_ENTRY' must be 40827 defined. 40828 40829 -- Target Hook: int TARGET_MODE_PRIORITY (int ENTITY, int N) 40830 This macro specifies the order in which modes for ENTITY are 40831 processed. 0 is the highest priority, 40832 'NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 40833 of the macro should be an integer designating a mode for ENTITY. 40834 For any fixed ENTITY, 'mode_priority' (ENTITY, N) shall be a 40835 bijection in 0 ... 'num_modes_for_mode_switching[ENTITY] - 1'. 40836 40837 40838File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 40839 4084018.24 Defining target-specific uses of '__attribute__' 40841====================================================== 40842 40843Target-specific attributes may be defined for functions, data and types. 40844These are described using the following target hooks; they also need to 40845be documented in 'extend.texi'. 40846 40847 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 40848 If defined, this target hook points to an array of 'struct 40849 attribute_spec' (defined in 'tree-core.h') specifying the machine 40850 specific attributes for this target and some of the restrictions on 40851 the entities to which these attributes are applied and the 40852 arguments they take. 40853 40854 -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree 40855 NAME) 40856 If defined, this target hook is a function which returns true if 40857 the machine-specific attribute named NAME expects an identifier 40858 given as its first argument to be passed on as a plain identifier, 40859 not subjected to name lookup. If this is not defined, the default 40860 is false for all machine-specific attributes. 40861 40862 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 40863 const_tree TYPE2) 40864 If defined, this target hook is a function which returns zero if 40865 the attributes on TYPE1 and TYPE2 are incompatible, one if they are 40866 compatible, and two if they are nearly compatible (which causes a 40867 warning to be generated). If this is not defined, machine-specific 40868 attributes are supposed always to be compatible. 40869 40870 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 40871 If defined, this target hook is a function which assigns default 40872 attributes to the newly defined TYPE. 40873 40874 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 40875 TYPE2) 40876 Define this target hook if the merging of type attributes needs 40877 special handling. If defined, the result is a list of the combined 40878 'TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 40879 'comptypes' has already been called and returned 1. This function 40880 may call 'merge_attributes' to handle machine-independent merging. 40881 40882 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 40883 NEWDECL) 40884 Define this target hook if the merging of decl attributes needs 40885 special handling. If defined, the result is a list of the combined 40886 'DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 40887 declaration of OLDDECL. Examples of when this is needed are when 40888 one attribute overrides another, or when an attribute is nullified 40889 by a subsequent definition. This function may call 40890 'merge_attributes' to handle machine-independent merging. 40891 40892 If the only target-specific handling you require is 'dllimport' for 40893 Microsoft Windows targets, you should define the macro 40894 'TARGET_DLLIMPORT_DECL_ATTRIBUTES' to '1'. The compiler will then 40895 define a function called 'merge_dllimport_decl_attributes' which 40896 can then be defined as the expansion of 40897 'TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 40898 'handle_dll_attribute' in the attribute table for your port to 40899 perform initial processing of the 'dllimport' and 'dllexport' 40900 attributes. This is done in 'i386/cygwin.h' and 'i386/i386.c', for 40901 example. 40902 40903 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 40904 DECL) 40905 DECL is a variable or function with '__attribute__((dllimport))' 40906 specified. Use this hook if the target needs to add extra 40907 validation checks to 'handle_dll_attribute'. 40908 40909 -- Macro: TARGET_DECLSPEC 40910 Define this macro to a nonzero value if you want to treat 40911 '__declspec(X)' as equivalent to '__attribute((X))'. By default, 40912 this behavior is enabled only for targets that define 40913 'TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 40914 '__declspec' is via a built-in macro, but you should not rely on 40915 this implementation detail. 40916 40917 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 40918 *ATTR_PTR) 40919 Define this target hook if you want to be able to add attributes to 40920 a decl when it is being created. This is normally useful for back 40921 ends which wish to implement a pragma by using the attributes which 40922 correspond to the pragma's effect. The NODE argument is the decl 40923 which is being created. The ATTR_PTR argument is a pointer to the 40924 attribute list for this decl. The list itself should not be 40925 modified, since it may be shared with other decls, but attributes 40926 may be chained on the head of the list and '*ATTR_PTR' modified to 40927 point to the new attributes, or a copy of the list may be made if 40928 further changes are needed. 40929 40930 -- Target Hook: tree TARGET_HANDLE_GENERIC_ATTRIBUTE (tree *NODE, tree 40931 NAME, tree ARGS, int FLAGS, bool *NO_ADD_ATTRS) 40932 Define this target hook if you want to be able to perform 40933 additional target-specific processing of an attribute which is 40934 handled generically by a front end. The arguments are the same as 40935 those which are passed to attribute handlers. So far this only 40936 affects the NOINIT and SECTION attribute. 40937 40938 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 40939 FNDECL) 40940 This target hook returns 'true' if it is OK to inline FNDECL into 40941 the current function, despite its having target-specific 40942 attributes, 'false' otherwise. By default, if a function has a 40943 target specific attribute attached to it, it will not be inlined. 40944 40945 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, tree 40946 NAME, tree ARGS, int FLAGS) 40947 This hook is called to parse 'attribute(target("..."))', which 40948 allows setting target-specific options on individual functions. 40949 These function-specific options may differ from the options 40950 specified on the command line. The hook should return 'true' if 40951 the options are valid. 40952 40953 The hook should set the 'DECL_FUNCTION_SPECIFIC_TARGET' field in 40954 the function declaration to hold a pointer to a target-specific 40955 'struct cl_target_option' structure. 40956 40957 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR, 40958 struct gcc_options *OPTS) 40959 This hook is called to save any additional target-specific 40960 information in the 'struct cl_target_option' structure for 40961 function-specific options from the 'struct gcc_options' structure. 40962 *Note Option file format::. 40963 40964 -- Target Hook: void TARGET_OPTION_RESTORE (struct gcc_options *OPTS, 40965 struct cl_target_option *PTR) 40966 This hook is called to restore any additional target-specific 40967 information in the 'struct cl_target_option' structure for 40968 function-specific options to the 'struct gcc_options' structure. 40969 40970 -- Target Hook: void TARGET_OPTION_POST_STREAM_IN (struct 40971 cl_target_option *PTR) 40972 This hook is called to update target-specific information in the 40973 'struct cl_target_option' structure after it is streamed in from 40974 LTO bytecode. 40975 40976 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 40977 struct cl_target_option *PTR) 40978 This hook is called to print any additional target-specific 40979 information in the 'struct cl_target_option' structure for 40980 function-specific options. 40981 40982 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree 40983 POP_TARGET) 40984 This target hook parses the options for '#pragma GCC target', which 40985 sets the target-specific options for functions that occur later in 40986 the input stream. The options accepted should be the same as those 40987 handled by the 'TARGET_OPTION_VALID_ATTRIBUTE_P' hook. 40988 40989 -- Target Hook: void TARGET_OPTION_OVERRIDE (void) 40990 Sometimes certain combinations of command options do not make sense 40991 on a particular target machine. You can override the hook 40992 'TARGET_OPTION_OVERRIDE' to take account of this. This hooks is 40993 called once just after all the command options have been parsed. 40994 40995 Don't use this hook to turn on various extra optimizations for 40996 '-O'. That is what 'TARGET_OPTION_OPTIMIZATION' is for. 40997 40998 If you need to do something whenever the optimization level is 40999 changed via the optimize attribute or pragma, see 41000 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 41001 41002 -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree 41003 DECL2) 41004 This target hook returns 'true' if DECL1 and DECL2 are versions of 41005 the same function. DECL1 and DECL2 are function versions if and 41006 only if they have the same function signature and different target 41007 specific attributes, that is, they are compiled for different 41008 target machines. 41009 41010 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 41011 This target hook returns 'false' if the CALLER function cannot 41012 inline CALLEE, based on target specific information. By default, 41013 inlining is not allowed if the callee function has function 41014 specific target options and the caller does not use the same 41015 options. 41016 41017 -- Target Hook: void TARGET_RELAYOUT_FUNCTION (tree FNDECL) 41018 This target hook fixes function FNDECL after attributes are 41019 processed. Default does nothing. On ARM, the default function's 41020 alignment is updated with the attribute target. 41021 41022 41023File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 41024 4102518.25 Emulating TLS 41026=================== 41027 41028For targets whose psABI does not provide Thread Local Storage via 41029specific relocations and instruction sequences, an emulation layer is 41030used. A set of target hooks allows this emulation layer to be 41031configured for the requirements of a particular target. For instance 41032the psABI may in fact specify TLS support in terms of an emulation 41033layer. 41034 41035 The emulation layer works by creating a control object for every TLS 41036object. To access the TLS object, a lookup function is provided which, 41037when given the address of the control object, will return the address of 41038the current thread's instance of the TLS object. 41039 41040 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 41041 Contains the name of the helper function that uses a TLS control 41042 object to locate a TLS instance. The default causes libgcc's 41043 emulated TLS helper function to be used. 41044 41045 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 41046 Contains the name of the helper function that should be used at 41047 program startup to register TLS objects that are implicitly 41048 initialized to zero. If this is 'NULL', all TLS objects will have 41049 explicit initializers. The default causes libgcc's emulated TLS 41050 registration function to be used. 41051 41052 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 41053 Contains the name of the section in which TLS control variables 41054 should be placed. The default of 'NULL' allows these to be placed 41055 in any section. 41056 41057 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 41058 Contains the name of the section in which TLS initializers should 41059 be placed. The default of 'NULL' allows these to be placed in any 41060 section. 41061 41062 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 41063 Contains the prefix to be prepended to TLS control variable names. 41064 The default of 'NULL' uses a target-specific prefix. 41065 41066 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 41067 Contains the prefix to be prepended to TLS initializer objects. 41068 The default of 'NULL' uses a target-specific prefix. 41069 41070 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 41071 Specifies a function that generates the FIELD_DECLs for a TLS 41072 control object type. TYPE is the RECORD_TYPE the fields are for 41073 and NAME should be filled with the structure tag, if the default of 41074 '__emutls_object' is unsuitable. The default creates a type 41075 suitable for libgcc's emulated TLS function. 41076 41077 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 41078 TMPL_ADDR) 41079 Specifies a function that generates the CONSTRUCTOR to initialize a 41080 TLS control object. VAR is the TLS control object, DECL is the TLS 41081 object and TMPL_ADDR is the address of the initializer. The 41082 default initializes libgcc's emulated TLS control object. 41083 41084 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 41085 Specifies whether the alignment of TLS control variable objects is 41086 fixed and should not be increased as some backends may do to 41087 optimize single objects. The default is false. 41088 41089 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 41090 Specifies whether a DWARF 'DW_OP_form_tls_address' location 41091 descriptor may be used to describe emulated TLS control objects. 41092 41093 41094File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 41095 4109618.26 Defining coprocessor specifics for MIPS targets. 41097====================================================== 41098 41099The MIPS specification allows MIPS implementations to have as many as 4 41100coprocessors, each with as many as 32 private registers. GCC supports 41101accessing these registers and transferring values between the registers 41102and memory using asm-ized variables. For example: 41103 41104 register unsigned int cp0count asm ("c0r1"); 41105 unsigned int d; 41106 41107 d = cp0count + 3; 41108 41109 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 41110names may be added as described below, or the default names may be 41111overridden entirely in 'SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 41112 41113 Coprocessor registers are assumed to be epilogue-used; sets to them 41114will be preserved even if it does not appear that the register is used 41115again later in the function. 41116 41117 Another note: according to the MIPS spec, coprocessor 1 (if present) is 41118the FPU. One accesses COP1 registers through standard mips 41119floating-point support; they are not included in this mechanism. 41120 41121 41122File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 41123 4112418.27 Parameters for Precompiled Header Validity Checking 41125========================================================= 41126 41127 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 41128 This hook returns a pointer to the data needed by 41129 'TARGET_PCH_VALID_P' and sets '*SZ' to the size of the data in 41130 bytes. 41131 41132 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 41133 size_t SZ) 41134 This hook checks whether the options used to create a PCH file are 41135 compatible with the current settings. It returns 'NULL' if so and 41136 a suitable error message if not. Error messages will be presented 41137 to the user and must be localized using '_(MSG)'. 41138 41139 DATA is the data that was returned by 'TARGET_GET_PCH_VALIDITY' 41140 when the PCH file was created and SZ is the size of that data in 41141 bytes. It's safe to assume that the data was created by the same 41142 version of the compiler, so no format checking is needed. 41143 41144 The default definition of 'default_pch_valid_p' should be suitable 41145 for most targets. 41146 41147 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 41148 PCH_FLAGS) 41149 If this hook is nonnull, the default implementation of 41150 'TARGET_PCH_VALID_P' will use it to check for compatible values of 41151 'target_flags'. PCH_FLAGS specifies the value that 'target_flags' 41152 had when the PCH file was created. The return value is the same as 41153 for 'TARGET_PCH_VALID_P'. 41154 41155 -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void) 41156 Called before writing out a PCH file. If the target has some 41157 garbage-collected data that needs to be in a particular state on 41158 PCH loads, it can use this hook to enforce that state. Very few 41159 targets need to do anything here. 41160 41161 41162File: gccint.info, Node: C++ ABI, Next: D Language and ABI, Prev: PCH Target, Up: Target Macros 41163 4116418.28 C++ ABI parameters 41165======================== 41166 41167 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 41168 Define this hook to override the integer type used for guard 41169 variables. These are used to implement one-time construction of 41170 static objects. The default is long_long_integer_type_node. 41171 41172 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 41173 This hook determines how guard variables are used. It should 41174 return 'false' (the default) if the first byte should be used. A 41175 return value of 'true' indicates that only the least significant 41176 bit should be used. 41177 41178 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 41179 This hook returns the size of the cookie to use when allocating an 41180 array whose elements have the indicated TYPE. Assumes that it is 41181 already known that a cookie is needed. The default is 'max(sizeof 41182 (size_t), alignof(type))', as defined in section 2.7 of the 41183 IA64/Generic C++ ABI. 41184 41185 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 41186 This hook should return 'true' if the element size should be stored 41187 in array cookies. The default is to return 'false'. 41188 41189 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 41190 IMPORT_EXPORT) 41191 If defined by a backend this hook allows the decision made to 41192 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 41193 contain 1 if the class is going to be exported, -1 if it is going 41194 to be imported and 0 otherwise. This function should return the 41195 modified value and perform any other actions necessary to support 41196 the backend's targeted operating system. 41197 41198 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 41199 This hook should return 'true' if constructors and destructors 41200 return the address of the object created/destroyed. The default is 41201 to return 'false'. 41202 41203 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 41204 This hook returns true if the key method for a class (i.e., the 41205 method which, if defined in the current translation unit, causes 41206 the virtual table to be emitted) may be an inline function. Under 41207 the standard Itanium C++ ABI the key method may be an inline 41208 function so long as the function is not declared inline in the 41209 class definition. Under some variants of the ABI, an inline 41210 function can never be the key method. The default is to return 41211 'true'. 41212 41213 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 41214 DECL) 41215 DECL is a virtual table, virtual table table, typeinfo object, or 41216 other similar implicit class data object that will be emitted with 41217 external linkage in this translation unit. No ELF visibility has 41218 been explicitly specified. If the target needs to specify a 41219 visibility other than that of the containing class, use this hook 41220 to set 'DECL_VISIBILITY' and 'DECL_VISIBILITY_SPECIFIED'. 41221 41222 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 41223 This hook returns true (the default) if virtual tables and other 41224 similar implicit class data objects are always COMDAT if they have 41225 external linkage. If this hook returns false, then class data for 41226 classes whose virtual table will be emitted in only one translation 41227 unit will not be COMDAT. 41228 41229 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 41230 This hook returns true (the default) if the RTTI information for 41231 the basic types which is defined in the C++ runtime should always 41232 be COMDAT, false if it should not be COMDAT. 41233 41234 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 41235 This hook returns true if '__aeabi_atexit' (as defined by the ARM 41236 EABI) should be used to register static destructors when 41237 '-fuse-cxa-atexit' is in effect. The default is to return false to 41238 use '__cxa_atexit'. 41239 41240 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 41241 This hook returns true if the target 'atexit' function can be used 41242 in the same manner as '__cxa_atexit' to register C++ static 41243 destructors. This requires that 'atexit'-registered functions in 41244 shared libraries are run in the correct order when the libraries 41245 are unloaded. The default is to return false. 41246 41247 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 41248 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has just 41249 been defined. Use this hook to make adjustments to the class (eg, 41250 tweak visibility or perform any other required target 41251 modifications). 41252 41253 -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL) 41254 Return target-specific mangling context of DECL or 'NULL_TREE'. 41255 41256 41257File: gccint.info, Node: D Language and ABI, Next: Named Address Spaces, Prev: C++ ABI, Up: Target Macros 41258 4125918.29 D ABI parameters 41260====================== 41261 41262 -- D Target Hook: void TARGET_D_CPU_VERSIONS (void) 41263 Declare all environmental version identifiers relating to the 41264 target CPU using the function 'builtin_version', which takes a 41265 string representing the name of the version. Version identifiers 41266 predefined by this hook apply to all modules that are being 41267 compiled and imported. 41268 41269 -- D Target Hook: void TARGET_D_OS_VERSIONS (void) 41270 Similarly to 'TARGET_D_CPU_VERSIONS', but is used for versions 41271 relating to the target operating system. 41272 41273 -- D Target Hook: unsigned TARGET_D_CRITSEC_SIZE (void) 41274 Returns the size of the data structure used by the target operating 41275 system for critical sections and monitors. For example, on 41276 Microsoft Windows this would return the 'sizeof(CRITICAL_SECTION)', 41277 while other platforms that implement pthreads would return 41278 'sizeof(pthread_mutex_t)'. 41279 41280 41281File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: D Language and ABI, Up: Target Macros 41282 4128318.30 Adding support for named address spaces 41284============================================= 41285 41286The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 41287committee, 'Programming Languages - C - Extensions to support embedded 41288processors', specifies a syntax for embedded processors to specify 41289alternate address spaces. You can configure a GCC port to support 41290section 5.1 of the draft report to add support for address spaces other 41291than the default address space. These address spaces are new keywords 41292that are similar to the 'volatile' and 'const' type attributes. 41293 41294 Pointers to named address spaces can have a different size than 41295pointers to the generic address space. 41296 41297 For example, the SPU port uses the '__ea' address space to refer to 41298memory in the host processor, rather than memory local to the SPU 41299processor. Access to memory in the '__ea' address space involves 41300issuing DMA operations to move data between the host processor and the 41301local processor memory address space. Pointers in the '__ea' address 41302space are either 32 bits or 64 bits based on the '-mea32' or '-mea64' 41303switches (native SPU pointers are always 32 bits). 41304 41305 Internally, address spaces are represented as a small integer in the 41306range 0 to 15 with address space 0 being reserved for the generic 41307address space. 41308 41309 To register a named address space qualifier keyword with the C front 41310end, the target may call the 'c_register_addr_space' routine. For 41311example, the SPU port uses the following to declare '__ea' as the 41312keyword for named address space #1: 41313 #define ADDR_SPACE_EA 1 41314 c_register_addr_space ("__ea", ADDR_SPACE_EA); 41315 41316 -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_POINTER_MODE 41317 (addr_space_t ADDRESS_SPACE) 41318 Define this to return the machine mode to use for pointers to 41319 ADDRESS_SPACE if the target supports named address spaces. The 41320 default version of this hook returns 'ptr_mode'. 41321 41322 -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_ADDRESS_MODE 41323 (addr_space_t ADDRESS_SPACE) 41324 Define this to return the machine mode to use for addresses in 41325 ADDRESS_SPACE if the target supports named address spaces. The 41326 default version of this hook returns 'Pmode'. 41327 41328 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE 41329 (scalar_int_mode MODE, addr_space_t AS) 41330 Define this to return nonzero if the port can handle pointers with 41331 machine mode MODE to address space AS. This target hook is the 41332 same as the 'TARGET_VALID_POINTER_MODE' target hook, except that it 41333 includes explicit named address space support. The default version 41334 of this hook returns true for the modes returned by either the 41335 'TARGET_ADDR_SPACE_POINTER_MODE' or 41336 'TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given address 41337 space. 41338 41339 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P 41340 (machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 41341 Define this to return true if EXP is a valid address for mode MODE 41342 in the named address space AS. The STRICT parameter says whether 41343 strict addressing is in effect after reload has finished. This 41344 target hook is the same as the 'TARGET_LEGITIMATE_ADDRESS_P' target 41345 hook, except that it includes explicit named address space support. 41346 41347 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 41348 OLDX, machine_mode MODE, addr_space_t AS) 41349 Define this to modify an invalid address X to be a valid address 41350 with mode MODE in the named address space AS. This target hook is 41351 the same as the 'TARGET_LEGITIMIZE_ADDRESS' target hook, except 41352 that it includes explicit named address space support. 41353 41354 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET, 41355 addr_space_t SUPERSET) 41356 Define this to return whether the SUBSET named address space is 41357 contained within the SUPERSET named address space. Pointers to a 41358 named address space that is a subset of another named address space 41359 will be converted automatically without a cast if used together in 41360 arithmetic operations. Pointers to a superset address space can be 41361 converted to pointers to a subset address space via explicit casts. 41362 41363 -- Target Hook: bool TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID (addr_space_t 41364 AS) 41365 Define this to modify the default handling of address 0 for the 41366 address space. Return true if 0 should be considered a valid 41367 address. 41368 41369 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 41370 tree TO_TYPE) 41371 Define this to convert the pointer expression represented by the 41372 RTL OP with type FROM_TYPE that points to a named address space to 41373 a new pointer expression with type TO_TYPE that points to a 41374 different named address space. When this hook it called, it is 41375 guaranteed that one of the two address spaces is a subset of the 41376 other, as determined by the 'TARGET_ADDR_SPACE_SUBSET_P' target 41377 hook. 41378 41379 -- Target Hook: int TARGET_ADDR_SPACE_DEBUG (addr_space_t AS) 41380 Define this to define how the address space is encoded in dwarf. 41381 The result is the value to be used with 'DW_AT_address_class'. 41382 41383 -- Target Hook: void TARGET_ADDR_SPACE_DIAGNOSE_USAGE (addr_space_t AS, 41384 location_t LOC) 41385 Define this hook if the availability of an address space depends on 41386 command line options and some diagnostics should be printed when 41387 the address space is used. This hook is called during parsing and 41388 allows to emit a better diagnostic compared to the case where the 41389 address space was not registered with 'c_register_addr_space'. AS 41390 is the address space as registered with 'c_register_addr_space'. 41391 LOC is the location of the address space qualifier token. The 41392 default implementation does nothing. 41393 41394 41395File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 41396 4139718.31 Miscellaneous Parameters 41398============================== 41399 41400Here are several miscellaneous parameters. 41401 41402 -- Macro: HAS_LONG_COND_BRANCH 41403 Define this boolean macro to indicate whether or not your 41404 architecture has conditional branches that can span all of memory. 41405 It is used in conjunction with an optimization that partitions hot 41406 and cold basic blocks into separate sections of the executable. If 41407 this macro is set to false, gcc will convert any conditional 41408 branches that attempt to cross between sections into unconditional 41409 branches or indirect jumps. 41410 41411 -- Macro: HAS_LONG_UNCOND_BRANCH 41412 Define this boolean macro to indicate whether or not your 41413 architecture has unconditional branches that can span all of 41414 memory. It is used in conjunction with an optimization that 41415 partitions hot and cold basic blocks into separate sections of the 41416 executable. If this macro is set to false, gcc will convert any 41417 unconditional branches that attempt to cross between sections into 41418 indirect jumps. 41419 41420 -- Macro: CASE_VECTOR_MODE 41421 An alias for a machine mode name. This is the machine mode that 41422 elements of a jump-table should have. 41423 41424 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 41425 Optional: return the preferred mode for an 'addr_diff_vec' when the 41426 minimum and maximum offset are known. If you define this, it 41427 enables extra code in branch shortening to deal with 41428 'addr_diff_vec'. To make this work, you also have to define 41429 'INSN_ALIGN' and make the alignment for 'addr_diff_vec' explicit. 41430 The BODY argument is provided so that the offset_unsigned and scale 41431 flags can be updated. 41432 41433 -- Macro: CASE_VECTOR_PC_RELATIVE 41434 Define this macro to be a C expression to indicate when jump-tables 41435 should contain relative addresses. You need not define this macro 41436 if jump-tables never contain relative addresses, or jump-tables 41437 should contain relative addresses only when '-fPIC' or '-fPIC' is 41438 in effect. 41439 41440 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 41441 This function return the smallest number of different values for 41442 which it is best to use a jump-table instead of a tree of 41443 conditional branches. The default is four for machines with a 41444 'casesi' instruction and five otherwise. This is best for most 41445 machines. 41446 41447 -- Macro: WORD_REGISTER_OPERATIONS 41448 Define this macro to 1 if operations between registers with 41449 integral mode smaller than a word are always performed on the 41450 entire register. To be more explicit, if you start with a pair of 41451 'word_mode' registers with known values and you do a subword, for 41452 example 'QImode', addition on the low part of the registers, then 41453 the compiler may consider that the result has a known value in 41454 'word_mode' too if the macro is defined to 1. Most RISC machines 41455 have this property and most CISC machines do not. 41456 41457 -- Target Hook: unsigned int TARGET_MIN_ARITHMETIC_PRECISION (void) 41458 On some RISC architectures with 64-bit registers, the processor 41459 also maintains 32-bit condition codes that make it possible to do 41460 real 32-bit arithmetic, although the operations are performed on 41461 the full registers. 41462 41463 On such architectures, defining this hook to 32 tells the compiler 41464 to try using 32-bit arithmetical operations setting the condition 41465 codes instead of doing full 64-bit arithmetic. 41466 41467 More generally, define this hook on RISC architectures if you want 41468 the compiler to try using arithmetical operations setting the 41469 condition codes with a precision lower than the word precision. 41470 41471 You need not define this hook if 'WORD_REGISTER_OPERATIONS' is not 41472 defined to 1. 41473 41474 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 41475 Define this macro to be a C expression indicating when insns that 41476 read memory in MEM_MODE, an integral mode narrower than a word, set 41477 the bits outside of MEM_MODE to be either the sign-extension or the 41478 zero-extension of the data read. Return 'SIGN_EXTEND' for values 41479 of MEM_MODE for which the insn sign-extends, 'ZERO_EXTEND' for 41480 which it zero-extends, and 'UNKNOWN' for other modes. 41481 41482 This macro is not called with MEM_MODE non-integral or with a width 41483 greater than or equal to 'BITS_PER_WORD', so you may return any 41484 value in this case. Do not define this macro if it would always 41485 return 'UNKNOWN'. On machines where this macro is defined, you 41486 will normally define it as the constant 'SIGN_EXTEND' or 41487 'ZERO_EXTEND'. 41488 41489 You may return a non-'UNKNOWN' value even if for some hard 41490 registers the sign extension is not performed, if for the 41491 'REGNO_REG_CLASS' of these hard registers 41492 'TARGET_CAN_CHANGE_MODE_CLASS' returns false when the FROM mode is 41493 MEM_MODE and the TO mode is any integral mode larger than this but 41494 not larger than 'word_mode'. 41495 41496 You must return 'UNKNOWN' if for some hard registers that allow 41497 this mode, 'TARGET_CAN_CHANGE_MODE_CLASS' says that they cannot 41498 change to 'word_mode', but that they can change to another integral 41499 mode that is larger then MEM_MODE but still smaller than 41500 'word_mode'. 41501 41502 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 41503 Define this macro to 1 if loading short immediate values into 41504 registers sign extends. 41505 41506 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL 41507 (machine_mode MODE) 41508 When '-ffast-math' is in effect, GCC tries to optimize divisions by 41509 the same divisor, by turning them into multiplications by the 41510 reciprocal. This target hook specifies the minimum number of 41511 divisions that should be there for GCC to perform the optimization 41512 for a variable of mode MODE. The default implementation returns 3 41513 if the machine has an instruction for the division, and 2 if it 41514 does not. 41515 41516 -- Macro: MOVE_MAX 41517 The maximum number of bytes that a single instruction can move 41518 quickly between memory and registers or between two memory 41519 locations. 41520 41521 -- Macro: MAX_MOVE_MAX 41522 The maximum number of bytes that a single instruction can move 41523 quickly between memory and registers or between two memory 41524 locations. If this is undefined, the default is 'MOVE_MAX'. 41525 Otherwise, it is the constant value that is the largest value that 41526 'MOVE_MAX' can have at run-time. 41527 41528 -- Macro: SHIFT_COUNT_TRUNCATED 41529 A C expression that is nonzero if on this machine the number of 41530 bits actually used for the count of a shift operation is equal to 41531 the number of bits needed to represent the size of the object being 41532 shifted. When this macro is nonzero, the compiler will assume that 41533 it is safe to omit a sign-extend, zero-extend, and certain bitwise 41534 'and' instructions that truncates the count of a shift operation. 41535 On machines that have instructions that act on bit-fields at 41536 variable positions, which may include 'bit test' instructions, a 41537 nonzero 'SHIFT_COUNT_TRUNCATED' also enables deletion of 41538 truncations of the values that serve as arguments to bit-field 41539 instructions. 41540 41541 If both types of instructions truncate the count (for shifts) and 41542 position (for bit-field operations), or if no variable-position 41543 bit-field instructions exist, you should define this macro. 41544 41545 However, on some machines, such as the 80386 and the 680x0, 41546 truncation only applies to shift operations and not the (real or 41547 pretended) bit-field operations. Define 'SHIFT_COUNT_TRUNCATED' to 41548 be zero on such machines. Instead, add patterns to the 'md' file 41549 that include the implied truncation of the shift instructions. 41550 41551 You need not define this macro if it would always have the value of 41552 zero. 41553 41554 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 41555 (machine_mode MODE) 41556 This function describes how the standard shift patterns for MODE 41557 deal with shifts by negative amounts or by more than the width of 41558 the mode. *Note shift patterns::. 41559 41560 On many machines, the shift patterns will apply a mask M to the 41561 shift count, meaning that a fixed-width shift of X by Y is 41562 equivalent to an arbitrary-width shift of X by Y & M. If this is 41563 true for mode MODE, the function should return M, otherwise it 41564 should return 0. A return value of 0 indicates that no particular 41565 behavior is guaranteed. 41566 41567 Note that, unlike 'SHIFT_COUNT_TRUNCATED', this function does _not_ 41568 apply to general shift rtxes; it applies only to instructions that 41569 are generated by the named shift patterns. 41570 41571 The default implementation of this function returns 41572 'GET_MODE_BITSIZE (MODE) - 1' if 'SHIFT_COUNT_TRUNCATED' and 0 41573 otherwise. This definition is always safe, but if 41574 'SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 41575 nevertheless truncate the shift count, you may get better code by 41576 overriding it. 41577 41578 -- Target Hook: bool TARGET_TRULY_NOOP_TRUNCATION (poly_uint64 OUTPREC, 41579 poly_uint64 INPREC) 41580 This hook returns true if it is safe to "convert" a value of INPREC 41581 bits to one of OUTPREC bits (where OUTPREC is smaller than INPREC) 41582 by merely operating on it as if it had only OUTPREC bits. The 41583 default returns true unconditionally, which is correct for most 41584 machines. 41585 41586 If 'TARGET_MODES_TIEABLE_P' returns false for a pair of modes, 41587 suboptimal code can result if this hook returns true for the 41588 corresponding mode sizes. Making this hook return false in such 41589 cases may improve things. 41590 41591 -- Target Hook: int TARGET_MODE_REP_EXTENDED (scalar_int_mode MODE, 41592 scalar_int_mode REP_MODE) 41593 The representation of an integral mode can be such that the values 41594 are always extended to a wider integral mode. Return 'SIGN_EXTEND' 41595 if values of MODE are represented in sign-extended form to 41596 REP_MODE. Return 'UNKNOWN' otherwise. (Currently, none of the 41597 targets use zero-extended representation this way so unlike 41598 'LOAD_EXTEND_OP', 'TARGET_MODE_REP_EXTENDED' is expected to return 41599 either 'SIGN_EXTEND' or 'UNKNOWN'. Also no target extends MODE to 41600 REP_MODE so that REP_MODE is not the next widest integral mode and 41601 currently we take advantage of this fact.) 41602 41603 Similarly to 'LOAD_EXTEND_OP' you may return a non-'UNKNOWN' value 41604 even if the extension is not performed on certain hard registers as 41605 long as for the 'REGNO_REG_CLASS' of these hard registers 41606 'TARGET_CAN_CHANGE_MODE_CLASS' returns false. 41607 41608 Note that 'TARGET_MODE_REP_EXTENDED' and 'LOAD_EXTEND_OP' describe 41609 two related properties. If you define 'TARGET_MODE_REP_EXTENDED 41610 (mode, word_mode)' you probably also want to define 'LOAD_EXTEND_OP 41611 (mode)' to return the same type of extension. 41612 41613 In order to enforce the representation of 'mode', 41614 'TARGET_TRULY_NOOP_TRUNCATION' should return false when truncating 41615 to 'mode'. 41616 41617 -- Target Hook: bool TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P (void) 41618 On some targets, it is assumed that the compiler will spill all 41619 pseudos that are live across a call to 'setjmp', while other 41620 targets treat 'setjmp' calls as normal function calls. 41621 41622 This hook returns false if 'setjmp' calls do not preserve all 41623 non-volatile registers so that gcc that must spill all pseudos that 41624 are live across 'setjmp' calls. Define this to return true if the 41625 target does not need to spill all pseudos live across 'setjmp' 41626 calls. The default implementation conservatively assumes all 41627 pseudos must be spilled across 'setjmp' calls. 41628 41629 -- Macro: STORE_FLAG_VALUE 41630 A C expression describing the value returned by a comparison 41631 operator with an integral mode and stored by a store-flag 41632 instruction ('cstoreMODE4') when the condition is true. This 41633 description must apply to _all_ the 'cstoreMODE4' patterns and all 41634 the comparison operators whose results have a 'MODE_INT' mode. 41635 41636 A value of 1 or -1 means that the instruction implementing the 41637 comparison operator returns exactly 1 or -1 when the comparison is 41638 true and 0 when the comparison is false. Otherwise, the value 41639 indicates which bits of the result are guaranteed to be 1 when the 41640 comparison is true. This value is interpreted in the mode of the 41641 comparison operation, which is given by the mode of the first 41642 operand in the 'cstoreMODE4' pattern. Either the low bit or the 41643 sign bit of 'STORE_FLAG_VALUE' be on. Presently, only those bits 41644 are used by the compiler. 41645 41646 If 'STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 41647 generate code that depends only on the specified bits. It can also 41648 replace comparison operators with equivalent operations if they 41649 cause the required bits to be set, even if the remaining bits are 41650 undefined. For example, on a machine whose comparison operators 41651 return an 'SImode' value and where 'STORE_FLAG_VALUE' is defined as 41652 '0x80000000', saying that just the sign bit is relevant, the 41653 expression 41654 41655 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 41656 41657 can be converted to 41658 41659 (ashift:SI X (const_int N)) 41660 41661 where N is the appropriate shift count to move the bit being tested 41662 into the sign bit. 41663 41664 There is no way to describe a machine that always sets the 41665 low-order bit for a true value, but does not guarantee the value of 41666 any other bits, but we do not know of any machine that has such an 41667 instruction. If you are trying to port GCC to such a machine, 41668 include an instruction to perform a logical-and of the result with 41669 1 in the pattern for the comparison operators and let us know at 41670 <gcc@gcc.gnu.org>. 41671 41672 Often, a machine will have multiple instructions that obtain a 41673 value from a comparison (or the condition codes). Here are rules 41674 to guide the choice of value for 'STORE_FLAG_VALUE', and hence the 41675 instructions to be used: 41676 41677 * Use the shortest sequence that yields a valid definition for 41678 'STORE_FLAG_VALUE'. It is more efficient for the compiler to 41679 "normalize" the value (convert it to, e.g., 1 or 0) than for 41680 the comparison operators to do so because there may be 41681 opportunities to combine the normalization with other 41682 operations. 41683 41684 * For equal-length sequences, use a value of 1 or -1, with -1 41685 being slightly preferred on machines with expensive jumps and 41686 1 preferred on other machines. 41687 41688 * As a second choice, choose a value of '0x80000001' if 41689 instructions exist that set both the sign and low-order bits 41690 but do not define the others. 41691 41692 * Otherwise, use a value of '0x80000000'. 41693 41694 Many machines can produce both the value chosen for 41695 'STORE_FLAG_VALUE' and its negation in the same number of 41696 instructions. On those machines, you should also define a pattern 41697 for those cases, e.g., one matching 41698 41699 (set A (neg:M (ne:M B C))) 41700 41701 Some machines can also perform 'and' or 'plus' operations on 41702 condition code values with less instructions than the corresponding 41703 'cstoreMODE4' insn followed by 'and' or 'plus'. On those machines, 41704 define the appropriate patterns. Use the names 'incscc' and 41705 'decscc', respectively, for the patterns which perform 'plus' or 41706 'minus' operations on condition code values. See 'rs6000.md' for 41707 some examples. The GNU Superoptimizer can be used to find such 41708 instruction sequences on other machines. 41709 41710 If this macro is not defined, the default value, 1, is used. You 41711 need not define 'STORE_FLAG_VALUE' if the machine has no store-flag 41712 instructions, or if the value generated by these instructions is 1. 41713 41714 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 41715 A C expression that gives a nonzero 'REAL_VALUE_TYPE' value that is 41716 returned when comparison operators with floating-point results are 41717 true. Define this macro on machines that have comparison 41718 operations that return floating-point values. If there are no such 41719 operations, do not define this macro. 41720 41721 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 41722 A C expression that gives a rtx representing the nonzero true 41723 element for vector comparisons. The returned rtx should be valid 41724 for the inner mode of MODE which is guaranteed to be a vector mode. 41725 Define this macro on machines that have vector comparison 41726 operations that return a vector result. If there are no such 41727 operations, do not define this macro. Typically, this macro is 41728 defined as 'const1_rtx' or 'constm1_rtx'. This macro may return 41729 'NULL_RTX' to prevent the compiler optimizing such vector 41730 comparison operations for the given mode. 41731 41732 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 41733 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 41734 A C expression that indicates whether the architecture defines a 41735 value for 'clz' or 'ctz' with a zero operand. A result of '0' 41736 indicates the value is undefined. If the value is defined for only 41737 the RTL expression, the macro should evaluate to '1'; if the value 41738 applies also to the corresponding optab entry (which is normally 41739 the case if it expands directly into the corresponding RTL), then 41740 the macro should evaluate to '2'. In the cases where the value is 41741 defined, VALUE should be set to this value. 41742 41743 If this macro is not defined, the value of 'clz' or 'ctz' at zero 41744 is assumed to be undefined. 41745 41746 This macro must be defined if the target's expansion for 'ffs' 41747 relies on a particular value to get correct results. Otherwise it 41748 is not necessary, though it may be used to optimize some corner 41749 cases, and to provide a default expansion for the 'ffs' optab. 41750 41751 Note that regardless of this macro the "definedness" of 'clz' and 41752 'ctz' at zero do _not_ extend to the builtin functions visible to 41753 the user. Thus one may be free to adjust the value at will to 41754 match the target expansion of these operations without fear of 41755 breaking the API. 41756 41757 -- Macro: Pmode 41758 An alias for the machine mode for pointers. On most machines, 41759 define this to be the integer mode corresponding to the width of a 41760 hardware pointer; 'SImode' on 32-bit machine or 'DImode' on 64-bit 41761 machines. On some machines you must define this to be one of the 41762 partial integer modes, such as 'PSImode'. 41763 41764 The width of 'Pmode' must be at least as large as the value of 41765 'POINTER_SIZE'. If it is not equal, you must define the macro 41766 'POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 41767 'Pmode'. 41768 41769 -- Macro: FUNCTION_MODE 41770 An alias for the machine mode used for memory references to 41771 functions being called, in 'call' RTL expressions. On most CISC 41772 machines, where an instruction can begin at any byte address, this 41773 should be 'QImode'. On most RISC machines, where all instructions 41774 have fixed size and alignment, this should be a mode with the same 41775 size and alignment as the machine instruction words - typically 41776 'SImode' or 'HImode'. 41777 41778 -- Macro: STDC_0_IN_SYSTEM_HEADERS 41779 In normal operation, the preprocessor expands '__STDC__' to the 41780 constant 1, to signify that GCC conforms to ISO Standard C. On 41781 some hosts, like Solaris, the system compiler uses a different 41782 convention, where '__STDC__' is normally 0, but is 1 if the user 41783 specifies strict conformance to the C Standard. 41784 41785 Defining 'STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 41786 convention when processing system header files, but when processing 41787 user files '__STDC__' will always expand to 1. 41788 41789 -- C Target Hook: const char * TARGET_C_PREINCLUDE (void) 41790 Define this hook to return the name of a header file to be included 41791 at the start of all compilations, as if it had been included with 41792 '#include <FILE>'. If this hook returns 'NULL', or is not defined, 41793 or the header is not found, or if the user specifies 41794 '-ffreestanding' or '-nostdinc', no header is included. 41795 41796 This hook can be used together with a header provided by the system 41797 C library to implement ISO C requirements for certain macros to be 41798 predefined that describe properties of the whole implementation 41799 rather than just the compiler. 41800 41801 -- C Target Hook: bool TARGET_CXX_IMPLICIT_EXTERN_C (const char*) 41802 Define this hook to add target-specific C++ implicit extern C 41803 functions. If this function returns true for the name of a 41804 file-scope function, that function implicitly gets extern "C" 41805 linkage rather than whatever language linkage the declaration would 41806 normally have. An example of such function is WinMain on Win32 41807 targets. 41808 41809 -- Macro: SYSTEM_IMPLICIT_EXTERN_C 41810 Define this macro if the system header files do not support C++. 41811 This macro handles system header files by pretending that system 41812 header files are enclosed in 'extern "C" {...}'. 41813 41814 -- Macro: REGISTER_TARGET_PRAGMAS () 41815 Define this macro if you want to implement any target-specific 41816 pragmas. If defined, it is a C expression which makes a series of 41817 calls to 'c_register_pragma' or 'c_register_pragma_with_expansion' 41818 for each pragma. The macro may also do any setup required for the 41819 pragmas. 41820 41821 The primary reason to define this macro is to provide compatibility 41822 with other compilers for the same target. In general, we 41823 discourage definition of target-specific pragmas for GCC. 41824 41825 If the pragma can be implemented by attributes then you should 41826 consider defining the target hook 'TARGET_INSERT_ATTRIBUTES' as 41827 well. 41828 41829 Preprocessor macros that appear on pragma lines are not expanded. 41830 All '#pragma' directives that do not match any registered pragma 41831 are silently ignored, unless the user specifies 41832 '-Wunknown-pragmas'. 41833 41834 -- Function: void c_register_pragma (const char *SPACE, const char 41835 *NAME, void (*CALLBACK) (struct cpp_reader *)) 41836 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 41837 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 41838 41839 Each call to 'c_register_pragma' or 41840 'c_register_pragma_with_expansion' establishes one pragma. The 41841 CALLBACK routine will be called when the preprocessor encounters a 41842 pragma of the form 41843 41844 #pragma [SPACE] NAME ... 41845 41846 SPACE is the case-sensitive namespace of the pragma, or 'NULL' to 41847 put the pragma in the global namespace. The callback routine 41848 receives PFILE as its first argument, which can be passed on to 41849 cpplib's functions if necessary. You can lex tokens after the NAME 41850 by calling 'pragma_lex'. Tokens that are not read by the callback 41851 will be silently ignored. The end of the line is indicated by a 41852 token of type 'CPP_EOF'. Macro expansion occurs on the arguments 41853 of pragmas registered with 'c_register_pragma_with_expansion' but 41854 not on the arguments of pragmas registered with 41855 'c_register_pragma'. 41856 41857 Note that the use of 'pragma_lex' is specific to the C and C++ 41858 compilers. It will not work in the Java or Fortran compilers, or 41859 any other language compilers for that matter. Thus if 'pragma_lex' 41860 is going to be called from target-specific code, it must only be 41861 done so when building the C and C++ compilers. This can be done by 41862 defining the variables 'c_target_objs' and 'cxx_target_objs' in the 41863 target entry in the 'config.gcc' file. These variables should name 41864 the target-specific, language-specific object file which contains 41865 the code that uses 'pragma_lex'. Note it will also be necessary to 41866 add a rule to the makefile fragment pointed to by 'tmake_file' that 41867 shows how to build this object file. 41868 41869 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 41870 Define this macro if macros should be expanded in the arguments of 41871 '#pragma pack'. 41872 41873 -- Macro: TARGET_DEFAULT_PACK_STRUCT 41874 If your target requires a structure packing default other than 0 41875 (meaning the machine default), define this macro to the necessary 41876 value (in bytes). This must be a value that would also be valid to 41877 use with '#pragma pack()' (that is, a small power of two). 41878 41879 -- Macro: DOLLARS_IN_IDENTIFIERS 41880 Define this macro to control use of the character '$' in identifier 41881 names for the C family of languages. 0 means '$' is not allowed by 41882 default; 1 means it is allowed. 1 is the default; there is no need 41883 to define this macro in that case. 41884 41885 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 41886 Define this macro as a C expression that is nonzero if it is safe 41887 for the delay slot scheduler to place instructions in the delay 41888 slot of INSN, even if they appear to use a resource set or 41889 clobbered in INSN. INSN is always a 'jump_insn' or an 'insn'; GCC 41890 knows that every 'call_insn' has this behavior. On machines where 41891 some 'insn' or 'jump_insn' is really a function call and hence has 41892 this behavior, you should define this macro. 41893 41894 You need not define this macro if it would always return zero. 41895 41896 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 41897 Define this macro as a C expression that is nonzero if it is safe 41898 for the delay slot scheduler to place instructions in the delay 41899 slot of INSN, even if they appear to set or clobber a resource 41900 referenced in INSN. INSN is always a 'jump_insn' or an 'insn'. On 41901 machines where some 'insn' or 'jump_insn' is really a function call 41902 and its operands are registers whose use is actually in the 41903 subroutine it calls, you should define this macro. Doing so allows 41904 the delay slot scheduler to move instructions which copy arguments 41905 into the argument registers into the delay slot of INSN. 41906 41907 You need not define this macro if it would always return zero. 41908 41909 -- Macro: MULTIPLE_SYMBOL_SPACES 41910 Define this macro as a C expression that is nonzero if, in some 41911 cases, global symbols from one translation unit may not be bound to 41912 undefined symbols in another translation unit without user 41913 intervention. For instance, under Microsoft Windows symbols must 41914 be explicitly imported from shared libraries (DLLs). 41915 41916 You need not define this macro if it would always evaluate to zero. 41917 41918 -- Target Hook: rtx_insn * TARGET_MD_ASM_ADJUST (vec<rtx>& OUTPUTS, 41919 vec<rtx>& INPUTS, vec<const char *>& CONSTRAINTS, vec<rtx>& 41920 CLOBBERS, HARD_REG_SET& CLOBBERED_REGS) 41921 This target hook may add "clobbers" to CLOBBERS and CLOBBERED_REGS 41922 for any hard regs the port wishes to automatically clobber for an 41923 asm. The OUTPUTS and INPUTS may be inspected to avoid clobbering a 41924 register that is already used by the asm. 41925 41926 It may modify the OUTPUTS, INPUTS, and CONSTRAINTS as necessary for 41927 other pre-processing. In this case the return value is a sequence 41928 of insns to emit after the asm. 41929 41930 -- Macro: MATH_LIBRARY 41931 Define this macro as a C string constant for the linker argument to 41932 link in the system math library, minus the initial '"-l"', or '""' 41933 if the target does not have a separate math library. 41934 41935 You need only define this macro if the default of '"m"' is wrong. 41936 41937 -- Macro: LIBRARY_PATH_ENV 41938 Define this macro as a C string constant for the environment 41939 variable that specifies where the linker should look for libraries. 41940 41941 You need only define this macro if the default of '"LIBRARY_PATH"' 41942 is wrong. 41943 41944 -- Macro: TARGET_POSIX_IO 41945 Define this macro if the target supports the following POSIX file 41946 functions, access, mkdir and file locking with fcntl / F_SETLKW. 41947 Defining 'TARGET_POSIX_IO' will enable the test coverage code to 41948 use file locking when exiting a program, which avoids race 41949 conditions if the program has forked. It will also create 41950 directories at run-time for cross-profiling. 41951 41952 -- Macro: MAX_CONDITIONAL_EXECUTE 41953 41954 A C expression for the maximum number of instructions to execute 41955 via conditional execution instructions instead of a branch. A 41956 value of 'BRANCH_COST'+1 is the default if the machine does not use 41957 cc0, and 1 if it does use cc0. 41958 41959 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 41960 Used if the target needs to perform machine-dependent modifications 41961 on the conditionals used for turning basic blocks into 41962 conditionally executed code. CE_INFO points to a data structure, 41963 'struct ce_if_block', which contains information about the 41964 currently processed blocks. TRUE_EXPR and FALSE_EXPR are the tests 41965 that are used for converting the then-block and the else-block, 41966 respectively. Set either TRUE_EXPR or FALSE_EXPR to a null pointer 41967 if the tests cannot be converted. 41968 41969 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 41970 FALSE_EXPR) 41971 Like 'IFCVT_MODIFY_TESTS', but used when converting more 41972 complicated if-statements into conditions combined by 'and' and 41973 'or' operations. BB contains the basic block that contains the 41974 test that is currently being processed and about to be turned into 41975 a condition. 41976 41977 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 41978 A C expression to modify the PATTERN of an INSN that is to be 41979 converted to conditional execution format. CE_INFO points to a 41980 data structure, 'struct ce_if_block', which contains information 41981 about the currently processed blocks. 41982 41983 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 41984 A C expression to perform any final machine dependent modifications 41985 in converting code to conditional execution. The involved basic 41986 blocks can be found in the 'struct ce_if_block' structure that is 41987 pointed to by CE_INFO. 41988 41989 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 41990 A C expression to cancel any machine dependent modifications in 41991 converting code to conditional execution. The involved basic 41992 blocks can be found in the 'struct ce_if_block' structure that is 41993 pointed to by CE_INFO. 41994 41995 -- Macro: IFCVT_MACHDEP_INIT (CE_INFO) 41996 A C expression to initialize any machine specific data for 41997 if-conversion of the if-block in the 'struct ce_if_block' structure 41998 that is pointed to by CE_INFO. 41999 42000 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 42001 If non-null, this hook performs a target-specific pass over the 42002 instruction stream. The compiler will run it at all optimization 42003 levels, just before the point at which it normally does 42004 delayed-branch scheduling. 42005 42006 The exact purpose of the hook varies from target to target. Some 42007 use it to do transformations that are necessary for correctness, 42008 such as laying out in-function constant pools or avoiding hardware 42009 hazards. Others use it as an opportunity to do some 42010 machine-dependent optimizations. 42011 42012 You need not implement the hook if it has nothing to do. The 42013 default definition is null. 42014 42015 -- Target Hook: void TARGET_INIT_BUILTINS (void) 42016 Define this hook if you have any machine-specific built-in 42017 functions that need to be defined. It should be a function that 42018 performs the necessary setup. 42019 42020 Machine specific built-in functions can be useful to expand special 42021 machine instructions that would otherwise not normally be generated 42022 because they have no equivalent in the source language (for 42023 example, SIMD vector instructions or prefetch instructions). 42024 42025 To create a built-in function, call the function 42026 'lang_hooks.builtin_function' which is defined by the language 42027 front end. You can use any type nodes set up by 42028 'build_common_tree_nodes'; only language front ends that use those 42029 two functions will call 'TARGET_INIT_BUILTINS'. 42030 42031 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 42032 INITIALIZE_P) 42033 Define this hook if you have any machine-specific built-in 42034 functions that need to be defined. It should be a function that 42035 returns the builtin function declaration for the builtin function 42036 code CODE. If there is no such builtin and it cannot be 42037 initialized at this time if INITIALIZE_P is true the function 42038 should return 'NULL_TREE'. If CODE is out of range the function 42039 should return 'error_mark_node'. 42040 42041 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 42042 SUBTARGET, machine_mode MODE, int IGNORE) 42043 42044 Expand a call to a machine specific built-in function that was set 42045 up by 'TARGET_INIT_BUILTINS'. EXP is the expression for the 42046 function call; the result should go to TARGET if that is 42047 convenient, and have mode MODE if that is convenient. SUBTARGET 42048 may be used as the target for computing one of EXP's operands. 42049 IGNORE is nonzero if the value is to be ignored. This function 42050 should return the result of the call to the built-in function. 42051 42052 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 42053 LOC, tree FNDECL, void *ARGLIST) 42054 Select a replacement for a machine specific built-in function that 42055 was set up by 'TARGET_INIT_BUILTINS'. This is done _before_ 42056 regular type checking, and so allows the target to implement a 42057 crude form of function overloading. FNDECL is the declaration of 42058 the built-in function. ARGLIST is the list of arguments passed to 42059 the built-in function. The result is a complete expression that 42060 implements the operation, usually another 'CALL_EXPR'. ARGLIST 42061 really has type 'VEC(tree,gc)*' 42062 42063 -- Target Hook: bool TARGET_CHECK_BUILTIN_CALL (location_t LOC, 42064 vec<location_t> ARG_LOC, tree FNDECL, tree ORIG_FNDECL, 42065 unsigned int NARGS, tree *ARGS) 42066 Perform semantic checking on a call to a machine-specific built-in 42067 function after its arguments have been constrained to the function 42068 signature. Return true if the call is valid, otherwise report an 42069 error and return false. 42070 42071 This hook is called after 'TARGET_RESOLVE_OVERLOADED_BUILTIN'. The 42072 call was originally to built-in function ORIG_FNDECL, but after the 42073 optional 'TARGET_RESOLVE_OVERLOADED_BUILTIN' step is now to 42074 built-in function FNDECL. LOC is the location of the call and ARGS 42075 is an array of function arguments, of which there are NARGS. 42076 ARG_LOC specifies the location of each argument. 42077 42078 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, tree 42079 *ARGP, bool IGNORE) 42080 Fold a call to a machine specific built-in function that was set up 42081 by 'TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 42082 built-in function. N_ARGS is the number of arguments passed to the 42083 function; the arguments themselves are pointed to by ARGP. The 42084 result is another tree, valid for both GIMPLE and GENERIC, 42085 containing a simplified expression for the call's result. If 42086 IGNORE is true the value will be ignored. 42087 42088 -- Target Hook: bool TARGET_GIMPLE_FOLD_BUILTIN (gimple_stmt_iterator 42089 *GSI) 42090 Fold a call to a machine specific built-in function that was set up 42091 by 'TARGET_INIT_BUILTINS'. GSI points to the gimple statement 42092 holding the function call. Returns true if any change was made to 42093 the GIMPLE stream. 42094 42095 -- Target Hook: int TARGET_COMPARE_VERSION_PRIORITY (tree DECL1, tree 42096 DECL2) 42097 This hook is used to compare the target attributes in two functions 42098 to determine which function's features get higher priority. This 42099 is used during function multi-versioning to figure out the order in 42100 which two versions must be dispatched. A function version with a 42101 higher priority is checked for dispatching earlier. DECL1 and 42102 DECL2 are the two function decls that will be compared. 42103 42104 -- Target Hook: tree TARGET_GET_FUNCTION_VERSIONS_DISPATCHER (void 42105 *DECL) 42106 This hook is used to get the dispatcher function for a set of 42107 function versions. The dispatcher function is called to invoke the 42108 right function version at run-time. DECL is one version from a set 42109 of semantically identical versions. 42110 42111 -- Target Hook: tree TARGET_GENERATE_VERSION_DISPATCHER_BODY (void 42112 *ARG) 42113 This hook is used to generate the dispatcher logic to invoke the 42114 right function version at run-time for a given set of function 42115 versions. ARG points to the callgraph node of the dispatcher 42116 function whose body must be generated. 42117 42118 -- Target Hook: bool TARGET_PREDICT_DOLOOP_P (class loop *LOOP) 42119 Return true if we can predict it is possible to use a low-overhead 42120 loop for a particular loop. The parameter LOOP is a pointer to the 42121 loop. This target hook is required only when the target supports 42122 low-overhead loops, and will help ivopts to make some decisions. 42123 The default version of this hook returns false. 42124 42125 -- Target Hook: bool TARGET_HAVE_COUNT_REG_DECR_P 42126 Return true if the target supports hardware count register for 42127 decrement and branch. The default value is false. 42128 42129 -- Target Hook: int64_t TARGET_DOLOOP_COST_FOR_GENERIC 42130 One IV candidate dedicated for doloop is introduced in IVOPTs, we 42131 can calculate the computation cost of adopting it to any generic IV 42132 use by function get_computation_cost as before. But for targets 42133 which have hardware count register support for decrement and 42134 branch, it may have to move IV value from hardware count register 42135 to general purpose register while doloop IV candidate is used for 42136 generic IV uses. It probably takes expensive penalty. This hook 42137 allows target owners to define the cost for this especially for 42138 generic IV uses. The default value is zero. 42139 42140 -- Target Hook: int64_t TARGET_DOLOOP_COST_FOR_ADDRESS 42141 One IV candidate dedicated for doloop is introduced in IVOPTs, we 42142 can calculate the computation cost of adopting it to any address IV 42143 use by function get_computation_cost as before. But for targets 42144 which have hardware count register support for decrement and 42145 branch, it may have to move IV value from hardware count register 42146 to general purpose register while doloop IV candidate is used for 42147 address IV uses. It probably takes expensive penalty. This hook 42148 allows target owners to define the cost for this escpecially for 42149 address IV uses. The default value is zero. 42150 42151 -- Target Hook: bool TARGET_CAN_USE_DOLOOP_P (const widest_int 42152 &ITERATIONS, const widest_int &ITERATIONS_MAX, unsigned int 42153 LOOP_DEPTH, bool ENTERED_AT_TOP) 42154 Return true if it is possible to use low-overhead loops 42155 ('doloop_end' and 'doloop_begin') for a particular loop. 42156 ITERATIONS gives the exact number of iterations, or 0 if not known. 42157 ITERATIONS_MAX gives the maximum number of iterations, or 0 if not 42158 known. LOOP_DEPTH is the nesting depth of the loop, with 1 for 42159 innermost loops, 2 for loops that contain innermost loops, and so 42160 on. ENTERED_AT_TOP is true if the loop is only entered from the 42161 top. 42162 42163 This hook is only used if 'doloop_end' is available. The default 42164 implementation returns true. You can use 42165 'can_use_doloop_if_innermost' if the loop must be the innermost, 42166 and if there are no other restrictions. 42167 42168 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const 42169 rtx_insn *INSN) 42170 42171 Take an instruction in INSN and return NULL if it is valid within a 42172 low-overhead loop, otherwise return a string explaining why doloop 42173 could not be applied. 42174 42175 Many targets use special registers for low-overhead looping. For 42176 any instruction that clobbers these this function should return a 42177 string indicating the reason why the doloop could not be applied. 42178 By default, the RTL loop optimizer does not use a present doloop 42179 pattern for loops containing function calls or branch on table 42180 instructions. 42181 42182 -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx_insn *INSN) 42183 Take an instruction in INSN and return 'false' if the instruction 42184 is not appropriate as a combination of two or more instructions. 42185 The default is to accept all instructions. 42186 42187 -- Target Hook: bool TARGET_CAN_FOLLOW_JUMP (const rtx_insn *FOLLOWER, 42188 const rtx_insn *FOLLOWEE) 42189 FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if 42190 FOLLOWER may be modified to follow FOLLOWEE; false, if it can't. 42191 For example, on some targets, certain kinds of branches can't be 42192 made to follow through a hot/cold partitioning. 42193 42194 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 42195 This target hook returns 'true' if X is considered to be 42196 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 42197 PA doesn't consider PLUS to be commutative inside a MEM. 42198 OUTER_CODE is the rtx code of the enclosing rtl, if known, 42199 otherwise it is UNKNOWN. 42200 42201 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 42202 42203 When the initial value of a hard register has been copied in a 42204 pseudo register, it is often not necessary to actually allocate 42205 another register to this pseudo register, because the original hard 42206 register or a stack slot it has been saved into can be used. 42207 'TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 42208 allocation once for each hard register that had its initial value 42209 copied by using 'get_func_hard_reg_initial_val' or 42210 'get_hard_reg_initial_val'. Possible values are 'NULL_RTX', if you 42211 don't want to do any special allocation, a 'REG' rtx--that would 42212 typically be the hard register itself, if it is known not to be 42213 clobbered--or a 'MEM'. If you are returning a 'MEM', this is only 42214 a hint for the allocator; it might decide to use another register 42215 anyways. You may use 'current_function_is_leaf' or 'REG_N_SETS' in 42216 the hook to determine if the hard register in question will not be 42217 clobbered. The default value of this hook is 'NULL', which 42218 disables any special allocation. 42219 42220 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 42221 FLAGS) 42222 This target hook returns nonzero if X, an 'unspec' or 42223 'unspec_volatile' operation, might cause a trap. Targets can use 42224 this hook to enhance precision of analysis for 'unspec' and 42225 'unspec_volatile' operations. You may call 'may_trap_p_1' to 42226 analyze inner elements of X in which case FLAGS should be passed 42227 along. 42228 42229 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 42230 The compiler invokes this hook whenever it changes its current 42231 function context ('cfun'). You can define this function if the 42232 back end needs to perform any initialization or reset actions on a 42233 per-function basis. For example, it may be used to implement 42234 function attributes that affect register usage or code generation 42235 patterns. The argument DECL is the declaration for the new 42236 function context, and may be null to indicate that the compiler has 42237 left a function context and is returning to processing at the top 42238 level. The default hook function does nothing. 42239 42240 GCC sets 'cfun' to a dummy function context during initialization 42241 of some parts of the back end. The hook function is not invoked in 42242 this situation; you need not worry about the hook being invoked 42243 recursively, or when the back end is in a partially-initialized 42244 state. 'cfun' might be 'NULL' to indicate processing at top level, 42245 outside of any function scope. 42246 42247 -- Macro: TARGET_OBJECT_SUFFIX 42248 Define this macro to be a C string representing the suffix for 42249 object files on your target machine. If you do not define this 42250 macro, GCC will use '.o' as the suffix for object files. 42251 42252 -- Macro: TARGET_EXECUTABLE_SUFFIX 42253 Define this macro to be a C string representing the suffix to be 42254 automatically added to executable files on your target machine. If 42255 you do not define this macro, GCC will use the null string as the 42256 suffix for executable files. 42257 42258 -- Macro: COLLECT_EXPORT_LIST 42259 If defined, 'collect2' will scan the individual object files 42260 specified on its command line and create an export list for the 42261 linker. Define this macro for systems like AIX, where the linker 42262 discards object files that are not referenced from 'main' and uses 42263 export lists. 42264 42265 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 42266 This target hook returns 'true' past the point in which new jump 42267 instructions could be created. On machines that require a register 42268 for every jump such as the SHmedia ISA of SH5, this point would 42269 typically be reload, so this target hook should be defined to a 42270 function such as: 42271 42272 static bool 42273 cannot_modify_jumps_past_reload_p () 42274 { 42275 return (reload_completed || reload_in_progress); 42276 } 42277 42278 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 42279 This target hook returns true if the target supports conditional 42280 execution. This target hook is required only when the target has 42281 several different modes and they have different conditional 42282 execution capability, such as ARM. 42283 42284 -- Target Hook: rtx TARGET_GEN_CCMP_FIRST (rtx_insn **PREP_SEQ, 42285 rtx_insn **GEN_SEQ, int CODE, tree OP0, tree OP1) 42286 This function prepares to emit a comparison insn for the first 42287 compare in a sequence of conditional comparisions. It returns an 42288 appropriate comparison with 'CC' for passing to 'gen_ccmp_next' or 42289 'cbranch_optab'. The insns to prepare the compare are saved in 42290 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 42291 emitted when all the compares in the conditional comparision are 42292 generated without error. CODE is the 'rtx_code' of the compare for 42293 OP0 and OP1. 42294 42295 -- Target Hook: rtx TARGET_GEN_CCMP_NEXT (rtx_insn **PREP_SEQ, rtx_insn 42296 **GEN_SEQ, rtx PREV, int CMP_CODE, tree OP0, tree OP1, int 42297 BIT_CODE) 42298 This function prepares to emit a conditional comparison within a 42299 sequence of conditional comparisons. It returns an appropriate 42300 comparison with 'CC' for passing to 'gen_ccmp_next' or 42301 'cbranch_optab'. The insns to prepare the compare are saved in 42302 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 42303 emitted when all the compares in the conditional comparision are 42304 generated without error. The PREV expression is the result of a 42305 prior call to 'gen_ccmp_first' or 'gen_ccmp_next'. It may return 42306 'NULL' if the combination of PREV and this comparison is not 42307 supported, otherwise the result must be appropriate for passing to 42308 'gen_ccmp_next' or 'cbranch_optab'. CODE is the 'rtx_code' of the 42309 compare for OP0 and OP1. BIT_CODE is 'AND' or 'IOR', which is the 42310 op on the compares. 42311 42312 -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL, 42313 class loop *LOOP) 42314 This target hook returns a new value for the number of times LOOP 42315 should be unrolled. The parameter NUNROLL is the number of times 42316 the loop is to be unrolled. The parameter LOOP is a pointer to the 42317 loop, which is going to be checked for unrolling. This target hook 42318 is required only when the target has special constraints like 42319 maximum number of memory accesses. 42320 42321 -- Macro: POWI_MAX_MULTS 42322 If defined, this macro is interpreted as a signed integer C 42323 expression that specifies the maximum number of floating point 42324 multiplications that should be emitted when expanding 42325 exponentiation by an integer constant inline. When this value is 42326 defined, exponentiation requiring more than this number of 42327 multiplications is implemented by calling the system library's 42328 'pow', 'powf' or 'powl' routines. The default value places no 42329 upper bound on the multiplication count. 42330 42331 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 42332 *IPREFIX, int STDINC) 42333 This target hook should register any extra include files for the 42334 target. The parameter STDINC indicates if normal include files are 42335 present. The parameter SYSROOT is the system root directory. The 42336 parameter IPREFIX is the prefix for the gcc directory. 42337 42338 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 42339 char *IPREFIX, int STDINC) 42340 This target hook should register any extra include files for the 42341 target before any standard headers. The parameter STDINC indicates 42342 if normal include files are present. The parameter SYSROOT is the 42343 system root directory. The parameter IPREFIX is the prefix for the 42344 gcc directory. 42345 42346 -- Macro: void TARGET_OPTF (char *PATH) 42347 This target hook should register special include paths for the 42348 target. The parameter PATH is the include to register. On Darwin 42349 systems, this is used for Framework includes, which have semantics 42350 that are different from '-I'. 42351 42352 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 42353 This target macro returns 'true' if it is safe to use a local alias 42354 for a virtual function FNDECL when constructing thunks, 'false' 42355 otherwise. By default, the macro returns 'true' for all functions, 42356 if a target supports aliases (i.e. defines 'ASM_OUTPUT_DEF'), 42357 'false' otherwise, 42358 42359 -- Macro: TARGET_FORMAT_TYPES 42360 If defined, this macro is the name of a global variable containing 42361 target-specific format checking information for the '-Wformat' 42362 option. The default is to have no target-specific format checks. 42363 42364 -- Macro: TARGET_N_FORMAT_TYPES 42365 If defined, this macro is the number of entries in 42366 'TARGET_FORMAT_TYPES'. 42367 42368 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 42369 If defined, this macro is the name of a global variable containing 42370 target-specific format overrides for the '-Wformat' option. The 42371 default is to have no target-specific format overrides. If 42372 defined, 'TARGET_FORMAT_TYPES' must be defined, too. 42373 42374 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 42375 If defined, this macro specifies the number of entries in 42376 'TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 42377 42378 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 42379 If defined, this macro specifies the optional initialization 42380 routine for target specific customizations of the system printf and 42381 scanf formatter settings. 42382 42383 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 42384 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 42385 If defined, this macro returns the diagnostic message when it is 42386 illegal to pass argument VAL to function FUNCDECL with prototype 42387 TYPELIST. 42388 42389 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 42390 FROMTYPE, const_tree TOTYPE) 42391 If defined, this macro returns the diagnostic message when it is 42392 invalid to convert from FROMTYPE to TOTYPE, or 'NULL' if validity 42393 should be determined by the front end. 42394 42395 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 42396 const_tree TYPE) 42397 If defined, this macro returns the diagnostic message when it is 42398 invalid to apply operation OP (where unary plus is denoted by 42399 'CONVERT_EXPR') to an operand of type TYPE, or 'NULL' if validity 42400 should be determined by the front end. 42401 42402 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 42403 const_tree TYPE1, const_tree TYPE2) 42404 If defined, this macro returns the diagnostic message when it is 42405 invalid to apply operation OP to operands of types TYPE1 and TYPE2, 42406 or 'NULL' if validity should be determined by the front end. 42407 42408 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 42409 If defined, this target hook returns the type to which values of 42410 TYPE should be promoted when they appear in expressions, analogous 42411 to the integer promotions, or 'NULL_TREE' to use the front end's 42412 normal promotion rules. This hook is useful when there are 42413 target-specific types with special promotion rules. This is 42414 currently used only by the C and C++ front ends. 42415 42416 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 42417 If defined, this hook returns the result of converting EXPR to 42418 TYPE. It should return the converted expression, or 'NULL_TREE' to 42419 apply the front end's normal conversion rules. This hook is useful 42420 when there are target-specific types with special conversion rules. 42421 This is currently used only by the C and C++ front ends. 42422 42423 -- Target Hook: bool TARGET_VERIFY_TYPE_CONTEXT (location_t LOC, 42424 type_context_kind CONTEXT, const_tree TYPE, bool SILENT_P) 42425 If defined, this hook returns false if there is a target-specific 42426 reason why type TYPE cannot be used in the source language context 42427 described by CONTEXT. When SILENT_P is false, the hook also 42428 reports an error against LOC for invalid uses of TYPE. 42429 42430 Calls to this hook should be made through the global function 42431 'verify_type_context', which makes the SILENT_P parameter default 42432 to false and also handles 'error_mark_node'. 42433 42434 The default implementation always returns true. 42435 42436 -- Macro: OBJC_JBLEN 42437 This macro determines the size of the objective C jump buffer for 42438 the NeXT runtime. By default, OBJC_JBLEN is defined to an 42439 innocuous value. 42440 42441 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 42442 Define this macro if any target-specific attributes need to be 42443 attached to the functions in 'libgcc' that provide low-level 42444 support for call stack unwinding. It is used in declarations in 42445 'unwind-generic.h' and the associated definitions of those 42446 functions. 42447 42448 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 42449 Define this macro to update the current function stack boundary if 42450 necessary. 42451 42452 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 42453 This hook should return an rtx for Dynamic Realign Argument Pointer 42454 (DRAP) if a different argument pointer register is needed to access 42455 the function's argument list due to stack realignment. Return 42456 'NULL' if no DRAP is needed. 42457 42458 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 42459 When optimization is disabled, this hook indicates whether or not 42460 arguments should be allocated to stack slots. Normally, GCC 42461 allocates stacks slots for arguments when not optimizing in order 42462 to make debugging easier. However, when a function is declared 42463 with '__attribute__((naked))', there is no stack frame, and the 42464 compiler cannot safely move arguments from the registers in which 42465 they are passed to the stack. Therefore, this hook should return 42466 true in general, but false for naked functions. The default 42467 implementation always returns true. 42468 42469 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 42470 On some architectures it can take multiple instructions to 42471 synthesize a constant. If there is another constant already in a 42472 register that is close enough in value then it is preferable that 42473 the new constant is computed from this register using immediate 42474 addition or subtraction. We accomplish this through CSE. Besides 42475 the value of the constant we also add a lower and an upper constant 42476 anchor to the available expressions. These are then queried when 42477 encountering new constants. The anchors are computed by rounding 42478 the constant up and down to a multiple of the value of 42479 'TARGET_CONST_ANCHOR'. 'TARGET_CONST_ANCHOR' should be the maximum 42480 positive value accepted by immediate-add plus one. We currently 42481 assume that the value of 'TARGET_CONST_ANCHOR' is a power of 2. 42482 For example, on MIPS, where add-immediate takes a 16-bit signed 42483 value, 'TARGET_CONST_ANCHOR' is set to '0x8000'. The default value 42484 is zero, which disables this optimization. 42485 42486 -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void) 42487 Return the offset bitwise ored into shifted address to get 42488 corresponding Address Sanitizer shadow memory address. NULL if 42489 Address Sanitizer is not supported by the target. 42490 42491 -- Target Hook: unsigned HOST_WIDE_INT TARGET_MEMMODEL_CHECK (unsigned 42492 HOST_WIDE_INT VAL) 42493 Validate target specific memory model mask bits. When NULL no 42494 target specific memory model bits are allowed. 42495 42496 -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 42497 This value should be set if the result written by 42498 'atomic_test_and_set' is not exactly 1, i.e. the 'bool' 'true'. 42499 42500 -- Target Hook: bool TARGET_HAS_IFUNC_P (void) 42501 It returns true if the target supports GNU indirect functions. The 42502 support includes the assembler, linker and dynamic linker. The 42503 default value of this hook is based on target's libc. 42504 42505 -- Target Hook: unsigned int TARGET_ATOMIC_ALIGN_FOR_MODE (machine_mode 42506 MODE) 42507 If defined, this function returns an appropriate alignment in bits 42508 for an atomic object of machine_mode MODE. If 0 is returned then 42509 the default alignment for the specified mode is used. 42510 42511 -- Target Hook: void TARGET_ATOMIC_ASSIGN_EXPAND_FENV (tree *HOLD, tree 42512 *CLEAR, tree *UPDATE) 42513 ISO C11 requires atomic compound assignments that may raise 42514 floating-point exceptions to raise exceptions corresponding to the 42515 arithmetic operation whose result was successfully stored in a 42516 compare-and-exchange sequence. This requires code equivalent to 42517 calls to 'feholdexcept', 'feclearexcept' and 'feupdateenv' to be 42518 generated at appropriate points in the compare-and-exchange 42519 sequence. This hook should set '*HOLD' to an expression equivalent 42520 to the call to 'feholdexcept', '*CLEAR' to an expression equivalent 42521 to the call to 'feclearexcept' and '*UPDATE' to an expression 42522 equivalent to the call to 'feupdateenv'. The three expressions are 42523 'NULL_TREE' on entry to the hook and may be left as 'NULL_TREE' if 42524 no code is required in a particular place. The default 42525 implementation leaves all three expressions as 'NULL_TREE'. The 42526 '__atomic_feraiseexcept' function from 'libatomic' may be of use as 42527 part of the code generated in '*UPDATE'. 42528 42529 -- Target Hook: void TARGET_RECORD_OFFLOAD_SYMBOL (tree) 42530 Used when offloaded functions are seen in the compilation unit and 42531 no named sections are available. It is called once for each symbol 42532 that must be recorded in the offload function and variable table. 42533 42534 -- Target Hook: char * TARGET_OFFLOAD_OPTIONS (void) 42535 Used when writing out the list of options into an LTO file. It 42536 should translate any relevant target-specific options (such as the 42537 ABI in use) into one of the '-foffload' options that exist as a 42538 common interface to express such options. It should return a 42539 string containing these options, separated by spaces, which the 42540 caller will free. 42541 42542 -- Macro: TARGET_SUPPORTS_WIDE_INT 42543 42544 On older ports, large integers are stored in 'CONST_DOUBLE' rtl 42545 objects. Newer ports define 'TARGET_SUPPORTS_WIDE_INT' to be 42546 nonzero to indicate that large integers are stored in 42547 'CONST_WIDE_INT' rtl objects. The 'CONST_WIDE_INT' allows very 42548 large integer constants to be represented. 'CONST_DOUBLE' is 42549 limited to twice the size of the host's 'HOST_WIDE_INT' 42550 representation. 42551 42552 Converting a port mostly requires looking for the places where 42553 'CONST_DOUBLE's are used with 'VOIDmode' and replacing that code 42554 with code that accesses 'CONST_WIDE_INT's. '"grep -i 42555 const_double"' at the port level gets you to 95% of the changes 42556 that need to be made. There are a few places that require a deeper 42557 look. 42558 42559 * There is no equivalent to 'hval' and 'lval' for 42560 'CONST_WIDE_INT's. This would be difficult to express in the 42561 md language since there are a variable number of elements. 42562 42563 Most ports only check that 'hval' is either 0 or -1 to see if 42564 the value is small. As mentioned above, this will no longer 42565 be necessary since small constants are always 'CONST_INT'. Of 42566 course there are still a few exceptions, the alpha's 42567 constraint used by the zap instruction certainly requires 42568 careful examination by C code. However, all the current code 42569 does is pass the hval and lval to C code, so evolving the c 42570 code to look at the 'CONST_WIDE_INT' is not really a large 42571 change. 42572 42573 * Because there is no standard template that ports use to 42574 materialize constants, there is likely to be some futzing that 42575 is unique to each port in this code. 42576 42577 * The rtx costs may have to be adjusted to properly account for 42578 larger constants that are represented as 'CONST_WIDE_INT'. 42579 42580 All and all it does not take long to convert ports that the 42581 maintainer is familiar with. 42582 42583 -- Target Hook: bool TARGET_HAVE_SPECULATION_SAFE_VALUE (bool ACTIVE) 42584 This hook is used to determine the level of target support for 42585 '__builtin_speculation_safe_value'. If called with an argument of 42586 false, it returns true if the target has been modified to support 42587 this builtin. If called with an argument of true, it returns true 42588 if the target requires active mitigation execution might be 42589 speculative. 42590 42591 The default implementation returns false if the target does not 42592 define a pattern named 'speculation_barrier'. Else it returns true 42593 for the first case and whether the pattern is enabled for the 42594 current compilation for the second case. 42595 42596 For targets that have no processors that can execute instructions 42597 speculatively an alternative implemenation of this hook is 42598 available: simply redefine this hook to 42599 'speculation_safe_value_not_needed' along with your other target 42600 hooks. 42601 42602 -- Target Hook: rtx TARGET_SPECULATION_SAFE_VALUE (machine_mode MODE, 42603 rtx RESULT, rtx VAL, rtx FAILVAL) 42604 This target hook can be used to generate a target-specific code 42605 sequence that implements the '__builtin_speculation_safe_value' 42606 built-in function. The function must always return VAL in RESULT 42607 in mode MODE when the cpu is not executing speculatively, but must 42608 never return that when speculating until it is known that the 42609 speculation will not be unwound. The hook supports two primary 42610 mechanisms for implementing the requirements. The first is to emit 42611 a speculation barrier which forces the processor to wait until all 42612 prior speculative operations have been resolved; the second is to 42613 use a target-specific mechanism that can track the speculation 42614 state and to return FAILVAL if it can determine that speculation 42615 must be unwound at a later time. 42616 42617 The default implementation simply copies VAL to RESULT and emits a 42618 'speculation_barrier' instruction if that is defined. 42619 42620 -- Target Hook: void TARGET_RUN_TARGET_SELFTESTS (void) 42621 If selftests are enabled, run any selftests for this target. 42622 42623 42624File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 42625 4262619 Host Configuration 42627********************* 42628 42629Most details about the machine and system on which the compiler is 42630actually running are detected by the 'configure' script. Some things 42631are impossible for 'configure' to detect; these are described in two 42632ways, either by macros defined in a file named 'xm-MACHINE.h' or by hook 42633functions in the file specified by the OUT_HOST_HOOK_OBJ variable in 42634'config.gcc'. (The intention is that very few hosts will need a header 42635file but nearly every fully supported host will need to override some 42636hooks.) 42637 42638 If you need to define only a few macros, and they have simple 42639definitions, consider using the 'xm_defines' variable in your 42640'config.gcc' entry instead of creating a host configuration header. 42641*Note System Config::. 42642 42643* Menu: 42644 42645* Host Common:: Things every host probably needs implemented. 42646* Filesystem:: Your host cannot have the letter 'a' in filenames? 42647* Host Misc:: Rare configuration options for hosts. 42648 42649 42650File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 42651 4265219.1 Host Common 42653================ 42654 42655Some things are just not portable, even between similar operating 42656systems, and are too difficult for autoconf to detect. They get 42657implemented using hook functions in the file specified by the 42658HOST_HOOK_OBJ variable in 'config.gcc'. 42659 42660 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 42661 This host hook is used to set up handling for extra signals. The 42662 most common thing to do in this hook is to detect stack overflow. 42663 42664 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 42665 FD) 42666 This host hook returns the address of some space that is likely to 42667 be free in some subsequent invocation of the compiler. We intend 42668 to load the PCH data at this address such that the data need not be 42669 relocated. The area should be able to hold SIZE bytes. If the 42670 host uses 'mmap', FD is an open file descriptor that can be used 42671 for probing. 42672 42673 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, size_t 42674 SIZE, int FD, size_t OFFSET) 42675 This host hook is called when a PCH file is about to be loaded. We 42676 want to load SIZE bytes from FD at OFFSET into memory at ADDRESS. 42677 The given address will be the result of a previous invocation of 42678 'HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we couldn't allocate 42679 SIZE bytes at ADDRESS. Return 0 if the memory is allocated but the 42680 data is not loaded. Return 1 if the hook has performed everything. 42681 42682 If the implementation uses reserved address space, free any 42683 reserved space beyond SIZE, regardless of the return value. If no 42684 PCH will be loaded, this hook may be called with SIZE zero, in 42685 which case all reserved address space should be freed. 42686 42687 Do not try to handle values of ADDRESS that could not have been 42688 returned by this executable; just return -1. Such values usually 42689 indicate an out-of-date PCH file (built by some other GCC 42690 executable), and such a PCH file won't work. 42691 42692 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 42693 This host hook returns the alignment required for allocating 42694 virtual memory. Usually this is the same as getpagesize, but on 42695 some hosts the alignment for reserving memory differs from the 42696 pagesize for committing memory. 42697 42698 42699File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 42700 4270119.2 Host Filesystem 42702==================== 42703 42704GCC needs to know a number of things about the semantics of the host 42705machine's filesystem. Filesystems with Unix and MS-DOS semantics are 42706automatically detected. For other systems, you can define the following 42707macros in 'xm-MACHINE.h'. 42708 42709'HAVE_DOS_BASED_FILE_SYSTEM' 42710 This macro is automatically defined by 'system.h' if the host file 42711 system obeys the semantics defined by MS-DOS instead of Unix. DOS 42712 file systems are case insensitive, file specifications may begin 42713 with a drive letter, and both forward slash and backslash ('/' and 42714 '\') are directory separators. 42715 42716'DIR_SEPARATOR' 42717'DIR_SEPARATOR_2' 42718 If defined, these macros expand to character constants specifying 42719 separators for directory names within a file specification. 42720 'system.h' will automatically give them appropriate values on Unix 42721 and MS-DOS file systems. If your file system is neither of these, 42722 define one or both appropriately in 'xm-MACHINE.h'. 42723 42724 However, operating systems like VMS, where constructing a pathname 42725 is more complicated than just stringing together directory names 42726 separated by a special character, should not define either of these 42727 macros. 42728 42729'PATH_SEPARATOR' 42730 If defined, this macro should expand to a character constant 42731 specifying the separator for elements of search paths. The default 42732 value is a colon (':'). DOS-based systems usually, but not always, 42733 use semicolon (';'). 42734 42735'VMS' 42736 Define this macro if the host system is VMS. 42737 42738'HOST_OBJECT_SUFFIX' 42739 Define this macro to be a C string representing the suffix for 42740 object files on your host machine. If you do not define this 42741 macro, GCC will use '.o' as the suffix for object files. 42742 42743'HOST_EXECUTABLE_SUFFIX' 42744 Define this macro to be a C string representing the suffix for 42745 executable files on your host machine. If you do not define this 42746 macro, GCC will use the null string as the suffix for executable 42747 files. 42748 42749'HOST_BIT_BUCKET' 42750 A pathname defined by the host operating system, which can be 42751 opened as a file and written to, but all the information written is 42752 discarded. This is commonly known as a "bit bucket" or "null 42753 device". If you do not define this macro, GCC will use '/dev/null' 42754 as the bit bucket. If the host does not support a bit bucket, 42755 define this macro to an invalid filename. 42756 42757'UPDATE_PATH_HOST_CANONICALIZE (PATH)' 42758 If defined, a C statement (sans semicolon) that performs 42759 host-dependent canonicalization when a path used in a compilation 42760 driver or preprocessor is canonicalized. PATH is a malloc-ed path 42761 to be canonicalized. If the C statement does canonicalize PATH 42762 into a different buffer, the old path should be freed and the new 42763 buffer should have been allocated with malloc. 42764 42765'DUMPFILE_FORMAT' 42766 Define this macro to be a C string representing the format to use 42767 for constructing the index part of debugging dump file names. The 42768 resultant string must fit in fifteen bytes. The full filename will 42769 be the concatenation of: the prefix of the assembler file name, the 42770 string resulting from applying this format to an index number, and 42771 a string unique to each dump file kind, e.g. 'rtl'. 42772 42773 If you do not define this macro, GCC will use '.%02d.'. You should 42774 define this macro if using the default will create an invalid file 42775 name. 42776 42777'DELETE_IF_ORDINARY' 42778 Define this macro to be a C statement (sans semicolon) that 42779 performs host-dependent removal of ordinary temp files in the 42780 compilation driver. 42781 42782 If you do not define this macro, GCC will use the default version. 42783 You should define this macro if the default version does not 42784 reliably remove the temp file as, for example, on VMS which allows 42785 multiple versions of a file. 42786 42787'HOST_LACKS_INODE_NUMBERS' 42788 Define this macro if the host filesystem does not report meaningful 42789 inode numbers in struct stat. 42790 42791 42792File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 42793 4279419.3 Host Misc 42795============== 42796 42797'FATAL_EXIT_CODE' 42798 A C expression for the status code to be returned when the compiler 42799 exits after serious errors. The default is the system-provided 42800 macro 'EXIT_FAILURE', or '1' if the system doesn't define that 42801 macro. Define this macro only if these defaults are incorrect. 42802 42803'SUCCESS_EXIT_CODE' 42804 A C expression for the status code to be returned when the compiler 42805 exits without serious errors. (Warnings are not serious errors.) 42806 The default is the system-provided macro 'EXIT_SUCCESS', or '0' if 42807 the system doesn't define that macro. Define this macro only if 42808 these defaults are incorrect. 42809 42810'USE_C_ALLOCA' 42811 Define this macro if GCC should use the C implementation of 42812 'alloca' provided by 'libiberty.a'. This only affects how some 42813 parts of the compiler itself allocate memory. It does not change 42814 code generation. 42815 42816 When GCC is built with a compiler other than itself, the C 'alloca' 42817 is always used. This is because most other implementations have 42818 serious bugs. You should define this macro only on a system where 42819 no stack-based 'alloca' can possibly work. For instance, if a 42820 system has a small limit on the size of the stack, GCC's builtin 42821 'alloca' will not work reliably. 42822 42823'COLLECT2_HOST_INITIALIZATION' 42824 If defined, a C statement (sans semicolon) that performs 42825 host-dependent initialization when 'collect2' is being initialized. 42826 42827'GCC_DRIVER_HOST_INITIALIZATION' 42828 If defined, a C statement (sans semicolon) that performs 42829 host-dependent initialization when a compilation driver is being 42830 initialized. 42831 42832'HOST_LONG_LONG_FORMAT' 42833 If defined, the string used to indicate an argument of type 'long 42834 long' to functions like 'printf'. The default value is '"ll"'. 42835 42836'HOST_LONG_FORMAT' 42837 If defined, the string used to indicate an argument of type 'long' 42838 to functions like 'printf'. The default value is '"l"'. 42839 42840'HOST_PTR_PRINTF' 42841 If defined, the string used to indicate an argument of type 'void 42842 *' to functions like 'printf'. The default value is '"%p"'. 42843 42844 In addition, if 'configure' generates an incorrect definition of any of 42845the macros in 'auto-host.h', you can override that definition in a host 42846configuration header. If you need to do this, first see if it is 42847possible to fix 'configure'. 42848 42849 42850File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 42851 4285220 Makefile Fragments 42853********************* 42854 42855When you configure GCC using the 'configure' script, it will construct 42856the file 'Makefile' from the template file 'Makefile.in'. When it does 42857this, it can incorporate makefile fragments from the 'config' directory. 42858These are used to set Makefile parameters that are not amenable to being 42859calculated by autoconf. The list of fragments to incorporate is set by 42860'config.gcc' (and occasionally 'config.build' and 'config.host'); *Note 42861System Config::. 42862 42863 Fragments are named either 't-TARGET' or 'x-HOST', depending on whether 42864they are relevant to configuring GCC to produce code for a particular 42865target, or to configuring GCC to run on a particular host. Here TARGET 42866and HOST are mnemonics which usually have some relationship to the 42867canonical system name, but no formal connection. 42868 42869 If these files do not exist, it means nothing needs to be added for a 42870given target or host. Most targets need a few 't-TARGET' fragments, but 42871needing 'x-HOST' fragments is rare. 42872 42873* Menu: 42874 42875* Target Fragment:: Writing 't-TARGET' files. 42876* Host Fragment:: Writing 'x-HOST' files. 42877 42878 42879File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 42880 4288120.1 Target Makefile Fragments 42882============================== 42883 42884Target makefile fragments can set these Makefile variables. 42885 42886'LIBGCC2_CFLAGS' 42887 Compiler flags to use when compiling 'libgcc2.c'. 42888 42889'LIB2FUNCS_EXTRA' 42890 A list of source file names to be compiled or assembled and 42891 inserted into 'libgcc.a'. 42892 42893'CRTSTUFF_T_CFLAGS' 42894 Special flags used when compiling 'crtstuff.c'. *Note 42895 Initialization::. 42896 42897'CRTSTUFF_T_CFLAGS_S' 42898 Special flags used when compiling 'crtstuff.c' for shared linking. 42899 Used if you use 'crtbeginS.o' and 'crtendS.o' in 'EXTRA-PARTS'. 42900 *Note Initialization::. 42901 42902'MULTILIB_OPTIONS' 42903 For some targets, invoking GCC in different ways produces objects 42904 that cannot be linked together. For example, for some targets GCC 42905 produces both big and little endian code. For these targets, you 42906 must arrange for multiple versions of 'libgcc.a' to be compiled, 42907 one for each set of incompatible options. When GCC invokes the 42908 linker, it arranges to link in the right version of 'libgcc.a', 42909 based on the command line options used. 42910 42911 The 'MULTILIB_OPTIONS' macro lists the set of options for which 42912 special versions of 'libgcc.a' must be built. Write options that 42913 are mutually incompatible side by side, separated by a slash. 42914 Write options that may be used together separated by a space. The 42915 build procedure will build all combinations of compatible options. 42916 42917 For example, if you set 'MULTILIB_OPTIONS' to 'm68000/m68020 42918 msoft-float', 'Makefile' will build special versions of 'libgcc.a' 42919 using the following sets of options: '-m68000', '-m68020', 42920 '-msoft-float', '-m68000 -msoft-float', and '-m68020 -msoft-float'. 42921 42922'MULTILIB_DIRNAMES' 42923 If 'MULTILIB_OPTIONS' is used, this variable specifies the 42924 directory names that should be used to hold the various libraries. 42925 Write one element in 'MULTILIB_DIRNAMES' for each element in 42926 'MULTILIB_OPTIONS'. If 'MULTILIB_DIRNAMES' is not used, the 42927 default value will be 'MULTILIB_OPTIONS', with all slashes treated 42928 as spaces. 42929 42930 'MULTILIB_DIRNAMES' describes the multilib directories using GCC 42931 conventions and is applied to directories that are part of the GCC 42932 installation. When multilib-enabled, the compiler will add a 42933 subdirectory of the form PREFIX/MULTILIB before each directory in 42934 the search path for libraries and crt files. 42935 42936 For example, if 'MULTILIB_OPTIONS' is set to 'm68000/m68020 42937 msoft-float', then the default value of 'MULTILIB_DIRNAMES' is 42938 'm68000 m68020 msoft-float'. You may specify a different value if 42939 you desire a different set of directory names. 42940 42941'MULTILIB_MATCHES' 42942 Sometimes the same option may be written in two different ways. If 42943 an option is listed in 'MULTILIB_OPTIONS', GCC needs to know about 42944 any synonyms. In that case, set 'MULTILIB_MATCHES' to a list of 42945 items of the form 'option=option' to describe all relevant 42946 synonyms. For example, 'm68000=mc68000 m68020=mc68020'. 42947 42948'MULTILIB_EXCEPTIONS' 42949 Sometimes when there are multiple sets of 'MULTILIB_OPTIONS' being 42950 specified, there are combinations that should not be built. In 42951 that case, set 'MULTILIB_EXCEPTIONS' to be all of the switch 42952 exceptions in shell case syntax that should not be built. 42953 42954 For example the ARM processor cannot execute both hardware floating 42955 point instructions and the reduced size THUMB instructions at the 42956 same time, so there is no need to build libraries with both of 42957 these options enabled. Therefore 'MULTILIB_EXCEPTIONS' is set to: 42958 *mthumb/*mhard-float* 42959 42960'MULTILIB_REQUIRED' 42961 Sometimes when there are only a few combinations are required, it 42962 would be a big effort to come up with a 'MULTILIB_EXCEPTIONS' list 42963 to cover all undesired ones. In such a case, just listing all the 42964 required combinations in 'MULTILIB_REQUIRED' would be more 42965 straightforward. 42966 42967 The way to specify the entries in 'MULTILIB_REQUIRED' is same with 42968 the way used for 'MULTILIB_EXCEPTIONS', only this time what are 42969 required will be specified. Suppose there are multiple sets of 42970 'MULTILIB_OPTIONS' and only two combinations are required, one for 42971 ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU, 42972 the 'MULTILIB_REQUIRED' can be set to: 42973 MULTILIB_REQUIRED = mthumb/march=armv7-m 42974 MULTILIB_REQUIRED += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16 42975 42976 The 'MULTILIB_REQUIRED' can be used together with 42977 'MULTILIB_EXCEPTIONS'. The option combinations generated from 42978 'MULTILIB_OPTIONS' will be filtered by 'MULTILIB_EXCEPTIONS' and 42979 then by 'MULTILIB_REQUIRED'. 42980 42981'MULTILIB_REUSE' 42982 Sometimes it is desirable to reuse one existing multilib for 42983 different sets of options. Such kind of reuse can minimize the 42984 number of multilib variants. And for some targets it is better to 42985 reuse an existing multilib than to fall back to default multilib 42986 when there is no corresponding multilib. This can be done by 42987 adding reuse rules to 'MULTILIB_REUSE'. 42988 42989 A reuse rule is comprised of two parts connected by equality sign. 42990 The left part is the option set used to build multilib and the 42991 right part is the option set that will reuse this multilib. Both 42992 parts should only use options specified in 'MULTILIB_OPTIONS' and 42993 the equality signs found in options name should be replaced with 42994 periods. An explicit period in the rule can be escaped by 42995 preceding it with a backslash. The order of options in the left 42996 part matters and should be same with those specified in 42997 'MULTILIB_REQUIRED' or aligned with the order in 42998 'MULTILIB_OPTIONS'. There is no such limitation for options in the 42999 right part as we don't build multilib from them. 43000 43001 'MULTILIB_REUSE' is different from 'MULTILIB_MATCHES' in that it 43002 sets up relations between two option sets rather than two options. 43003 Here is an example to demo how we reuse libraries built in Thumb 43004 mode for applications built in ARM mode: 43005 MULTILIB_REUSE = mthumb/march.armv7-r=marm/march.armv7-r 43006 43007 Before the advent of 'MULTILIB_REUSE', GCC select multilib by 43008 comparing command line options with options used to build multilib. 43009 The 'MULTILIB_REUSE' is complementary to that way. Only when the 43010 original comparison matches nothing it will work to see if it is OK 43011 to reuse some existing multilib. 43012 43013'MULTILIB_EXTRA_OPTS' 43014 Sometimes it is desirable that when building multiple versions of 43015 'libgcc.a' certain options should always be passed on to the 43016 compiler. In that case, set 'MULTILIB_EXTRA_OPTS' to be the list 43017 of options to be used for all builds. If you set this, you should 43018 probably set 'CRTSTUFF_T_CFLAGS' to a dash followed by it. 43019 43020'MULTILIB_OSDIRNAMES' 43021 If 'MULTILIB_OPTIONS' is used, this variable specifies a list of 43022 subdirectory names, that are used to modify the search path 43023 depending on the chosen multilib. Unlike 'MULTILIB_DIRNAMES', 43024 'MULTILIB_OSDIRNAMES' describes the multilib directories using 43025 operating systems conventions, and is applied to the directories 43026 such as 'lib' or those in the 'LIBRARY_PATH' environment variable. 43027 The format is either the same as of 'MULTILIB_DIRNAMES', or a set 43028 of mappings. When it is the same as 'MULTILIB_DIRNAMES', it 43029 describes the multilib directories using operating system 43030 conventions, rather than GCC conventions. When it is a set of 43031 mappings of the form GCCDIR=OSDIR, the left side gives the GCC 43032 convention and the right gives the equivalent OS defined location. 43033 If the OSDIR part begins with a '!', GCC will not search in the 43034 non-multilib directory and use exclusively the multilib directory. 43035 Otherwise, the compiler will examine the search path for libraries 43036 and crt files twice; the first time it will add MULTILIB to each 43037 directory in the search path, the second it will not. 43038 43039 For configurations that support both multilib and multiarch, 43040 'MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus 43041 subsuming 'MULTIARCH_DIRNAME'. The multiarch name is appended to 43042 each directory name, separated by a colon (e.g. 43043 '../lib32:i386-linux-gnu'). 43044 43045 Each multiarch subdirectory will be searched before the 43046 corresponding OS multilib directory, for example 43047 '/lib/i386-linux-gnu' before '/lib/../lib32'. The multiarch name 43048 will also be used to modify the system header search path, as 43049 explained for 'MULTIARCH_DIRNAME'. 43050 43051'MULTIARCH_DIRNAME' 43052 This variable specifies the multiarch name for configurations that 43053 are multiarch-enabled but not multilibbed configurations. 43054 43055 The multiarch name is used to augment the search path for 43056 libraries, crt files and system header files with additional 43057 locations. The compiler will add a multiarch subdirectory of the 43058 form PREFIX/MULTIARCH before each directory in the library and crt 43059 search path. It will also add two directories 43060 'LOCAL_INCLUDE_DIR'/MULTIARCH and 43061 'NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search 43062 path, respectively before 'LOCAL_INCLUDE_DIR' and 43063 'NATIVE_SYSTEM_HEADER_DIR'. 43064 43065 'MULTIARCH_DIRNAME' is not used for configurations that support 43066 both multilib and multiarch. In that case, multiarch names are 43067 encoded in 'MULTILIB_OSDIRNAMES' instead. 43068 43069 More documentation about multiarch can be found at 43070 <https://wiki.debian.org/Multiarch>. 43071 43072'SPECS' 43073 Unfortunately, setting 'MULTILIB_EXTRA_OPTS' is not enough, since 43074 it does not affect the build of target libraries, at least not the 43075 build of the default multilib. One possible work-around is to use 43076 'DRIVER_SELF_SPECS' to bring options from the 'specs' file as if 43077 they had been passed in the compiler driver command line. However, 43078 you don't want to be adding these options after the toolchain is 43079 installed, so you can instead tweak the 'specs' file that will be 43080 used during the toolchain build, while you still install the 43081 original, built-in 'specs'. The trick is to set 'SPECS' to some 43082 other filename (say 'specs.install'), that will then be created out 43083 of the built-in specs, and introduce a 'Makefile' rule to generate 43084 the 'specs' file that's going to be used at build time out of your 43085 'specs.install'. 43086 43087'T_CFLAGS' 43088 These are extra flags to pass to the C compiler. They are used 43089 both when building GCC, and when compiling things with the 43090 just-built GCC. This variable is deprecated and should not be 43091 used. 43092 43093 43094File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 43095 4309620.2 Host Makefile Fragments 43097============================ 43098 43099The use of 'x-HOST' fragments is discouraged. You should only use it 43100for makefile dependencies. 43101 43102 43103File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 43104 4310521 'collect2' 43106************* 43107 43108GCC uses a utility called 'collect2' on nearly all systems to arrange to 43109call various initialization functions at start time. 43110 43111 The program 'collect2' works by linking the program once and looking 43112through the linker output file for symbols with particular names 43113indicating they are constructor functions. If it finds any, it creates 43114a new temporary '.c' file containing a table of them, compiles it, and 43115links the program a second time including that file. 43116 43117 The actual calls to the constructors are carried out by a subroutine 43118called '__main', which is called (automatically) at the beginning of the 43119body of 'main' (provided 'main' was compiled with GNU CC). Calling 43120'__main' is necessary, even when compiling C code, to allow linking C 43121and C++ object code together. (If you use '-nostdlib', you get an 43122unresolved reference to '__main', since it's defined in the standard GCC 43123library. Include '-lgcc' at the end of your compiler command line to 43124resolve this reference.) 43125 43126 The program 'collect2' is installed as 'ld' in the directory where the 43127passes of the compiler are installed. When 'collect2' needs to find the 43128_real_ 'ld', it tries the following file names: 43129 43130 * a hard coded linker file name, if GCC was configured with the 43131 '--with-ld' option. 43132 43133 * 'real-ld' in the directories listed in the compiler's search 43134 directories. 43135 43136 * 'real-ld' in the directories listed in the environment variable 43137 'PATH'. 43138 43139 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 43140 if specified. 43141 43142 * 'ld' in the compiler's search directories, except that 'collect2' 43143 will not execute itself recursively. 43144 43145 * 'ld' in 'PATH'. 43146 43147 "The compiler's search directories" means all the directories where 43148'gcc' searches for passes of the compiler. This includes directories 43149that you specify with '-B'. 43150 43151 Cross-compilers search a little differently: 43152 43153 * 'real-ld' in the compiler's search directories. 43154 43155 * 'TARGET-real-ld' in 'PATH'. 43156 43157 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 43158 if specified. 43159 43160 * 'ld' in the compiler's search directories. 43161 43162 * 'TARGET-ld' in 'PATH'. 43163 43164 'collect2' explicitly avoids running 'ld' using the file name under 43165which 'collect2' itself was invoked. In fact, it remembers up a list of 43166such names--in case one copy of 'collect2' finds another copy (or 43167version) of 'collect2' installed as 'ld' in a second place in the search 43168path. 43169 43170 'collect2' searches for the utilities 'nm' and 'strip' using the same 43171algorithm as above for 'ld'. 43172 43173 43174File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 43175 4317622 Standard Header File Directories 43177*********************************** 43178 43179'GCC_INCLUDE_DIR' means the same thing for native and cross. It is 43180where GCC stores its private include files, and also where GCC stores 43181the fixed include files. A cross compiled GCC runs 'fixincludes' on the 43182header files in '$(tooldir)/include'. (If the cross compilation header 43183files need to be fixed, they must be installed before GCC is built. If 43184the cross compilation header files are already suitable for GCC, nothing 43185special need be done). 43186 43187 'GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 43188is where 'g++' looks first for header files. The C++ library installs 43189only target independent header files in that directory. 43190 43191 'LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 43192install anything there. It is normally '/usr/local/include'. This is 43193where local additions to a packaged system should place header files. 43194 43195 'CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 43196install anything there. 43197 43198 'TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 43199the place for other packages to install header files that GCC will use. 43200For a cross-compiler, this is the equivalent of '/usr/include'. When 43201you build a cross-compiler, 'fixincludes' processes any header files in 43202this directory. 43203 43204 43205File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 43206 4320723 Memory Management and Type Information 43208***************************************** 43209 43210GCC uses some fairly sophisticated memory management techniques, which 43211involve determining information about GCC's data structures from GCC's 43212source code and using this information to perform garbage collection and 43213implement precompiled headers. 43214 43215 A full C++ parser would be too complicated for this task, so a limited 43216subset of C++ is interpreted and special markers are used to determine 43217what parts of the source to look at. All 'struct', 'union' and 43218'template' structure declarations that define data structures that are 43219allocated under control of the garbage collector must be marked. All 43220global variables that hold pointers to garbage-collected memory must 43221also be marked. Finally, all global variables that need to be saved and 43222restored by a precompiled header must be marked. (The precompiled 43223header mechanism can only save static variables if they're scalar. 43224Complex data structures must be allocated in garbage-collected memory to 43225be saved in a precompiled header.) 43226 43227 The full format of a marker is 43228 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 43229but in most cases no options are needed. The outer double parentheses 43230are still necessary, though: 'GTY(())'. Markers can appear: 43231 43232 * In a structure definition, before the open brace; 43233 * In a global variable declaration, after the keyword 'static' or 43234 'extern'; and 43235 * In a structure field definition, before the name of the field. 43236 43237 Here are some examples of marking simple data structures and globals. 43238 43239 struct GTY(()) TAG 43240 { 43241 FIELDS... 43242 }; 43243 43244 typedef struct GTY(()) TAG 43245 { 43246 FIELDS... 43247 } *TYPENAME; 43248 43249 static GTY(()) struct TAG *LIST; /* points to GC memory */ 43250 static GTY(()) int COUNTER; /* save counter in a PCH */ 43251 43252 The parser understands simple typedefs such as 'typedef struct TAG 43253*NAME;' and 'typedef int NAME;'. These don't need to be marked. 43254 43255 Since 'gengtype''s understanding of C++ is limited, there are several 43256constructs and declarations that are not supported inside 43257classes/structures marked for automatic GC code generation. The 43258following C++ constructs produce a 'gengtype' error on 43259structures/classes marked for automatic GC code generation: 43260 43261 * Type definitions inside classes/structures are not supported. 43262 * Enumerations inside classes/structures are not supported. 43263 43264 If you have a class or structure using any of the above constructs, you 43265need to mark that class as 'GTY ((user))' and provide your own marking 43266routines (see section *note User GC:: for details). 43267 43268 It is always valid to include function definitions inside classes. 43269Those are always ignored by 'gengtype', as it only cares about data 43270members. 43271 43272* Menu: 43273 43274* GTY Options:: What goes inside a 'GTY(())'. 43275* Inheritance and GTY:: Adding GTY to a class hierarchy. 43276* User GC:: Adding user-provided GC marking routines. 43277* GGC Roots:: Making global variables GGC roots. 43278* Files:: How the generated files work. 43279* Invoking the garbage collector:: How to invoke the garbage collector. 43280* Troubleshooting:: When something does not work as expected. 43281 43282 43283File: gccint.info, Node: GTY Options, Next: Inheritance and GTY, Up: Type Information 43284 4328523.1 The Inside of a 'GTY(())' 43286============================== 43287 43288Sometimes the C code is not enough to fully describe the type structure. 43289Extra information can be provided with 'GTY' options and additional 43290markers. Some options take a parameter, which may be either a string or 43291a type name, depending on the parameter. If an option takes no 43292parameter, it is acceptable either to omit the parameter entirely, or to 43293provide an empty string as a parameter. For example, 'GTY ((skip))' and 43294'GTY ((skip ("")))' are equivalent. 43295 43296 When the parameter is a string, often it is a fragment of C code. Four 43297special escapes may be used in these strings, to refer to pieces of the 43298data structure being marked: 43299 43300'%h' 43301 The current structure. 43302'%1' 43303 The structure that immediately contains the current structure. 43304'%0' 43305 The outermost structure that contains the current structure. 43306'%a' 43307 A partial expression of the form '[i1][i2]...' that indexes the 43308 array item currently being marked. 43309 43310 For instance, suppose that you have a structure of the form 43311 struct A { 43312 ... 43313 }; 43314 struct B { 43315 struct A foo[12]; 43316 }; 43317and 'b' is a variable of type 'struct B'. When marking 'b.foo[11]', 43318'%h' would expand to 'b.foo[11]', '%0' and '%1' would both expand to 43319'b', and '%a' would expand to '[11]'. 43320 43321 As in ordinary C, adjacent strings will be concatenated; this is 43322helpful when you have a complicated expression. 43323 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 43324 " ? TYPE_NEXT_VARIANT (&%h.generic)" 43325 " : TREE_CHAIN (&%h.generic)"))) 43326 43327 The available options are: 43328 43329'length ("EXPRESSION")' 43330 43331 There are two places the type machinery will need to be explicitly 43332 told the length of an array of non-atomic objects. The first case 43333 is when a structure ends in a variable-length array, like this: 43334 struct GTY(()) rtvec_def { 43335 int num_elem; /* number of elements */ 43336 rtx GTY ((length ("%h.num_elem"))) elem[1]; 43337 }; 43338 43339 In this case, the 'length' option is used to override the specified 43340 array length (which should usually be '1'). The parameter of the 43341 option is a fragment of C code that calculates the length. 43342 43343 The second case is when a structure or a global variable contains a 43344 pointer to an array, like this: 43345 struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter; 43346 In this case, 'iter' has been allocated by writing something like 43347 x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse); 43348 and the 'collapse' provides the length of the field. 43349 43350 This second use of 'length' also works on global variables, like: 43351 static GTY((length("reg_known_value_size"))) rtx *reg_known_value; 43352 43353 Note that the 'length' option is only meant for use with arrays of 43354 non-atomic objects, that is, objects that contain pointers pointing 43355 to other GTY-managed objects. For other GC-allocated arrays and 43356 strings you should use 'atomic'. 43357 43358'skip' 43359 43360 If 'skip' is applied to a field, the type machinery will ignore it. 43361 This is somewhat dangerous; the only safe use is in a union when 43362 one field really isn't ever used. 43363 43364'for_user' 43365 43366 Use this to mark types that need to be marked by user gc routines, 43367 but are not refered to in a template argument. So if you have some 43368 user gc type T1 and a non user gc type T2 you can give T2 the 43369 for_user option so that the marking functions for T1 can call non 43370 mangled functions to mark T2. 43371 43372'desc ("EXPRESSION")' 43373'tag ("CONSTANT")' 43374'default' 43375 43376 The type machinery needs to be told which field of a 'union' is 43377 currently active. This is done by giving each field a constant 43378 'tag' value, and then specifying a discriminator using 'desc'. The 43379 value of the expression given by 'desc' is compared against each 43380 'tag' value, each of which should be different. If no 'tag' is 43381 matched, the field marked with 'default' is used if there is one, 43382 otherwise no field in the union will be marked. 43383 43384 In the 'desc' option, the "current structure" is the union that it 43385 discriminates. Use '%1' to mean the structure containing it. 43386 There are no escapes available to the 'tag' option, since it is a 43387 constant. 43388 43389 For example, 43390 struct GTY(()) tree_binding 43391 { 43392 struct tree_common common; 43393 union tree_binding_u { 43394 tree GTY ((tag ("0"))) scope; 43395 struct cp_binding_level * GTY ((tag ("1"))) level; 43396 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 43397 tree value; 43398 }; 43399 43400 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 43401 'struct tree_binding *' is presumed to be 0 or 1. If 1, the type 43402 mechanism will treat the field 'level' as being present and if 0, 43403 will treat the field 'scope' as being present. 43404 43405 The 'desc' and 'tag' options can also be used for inheritance to 43406 denote which subclass an instance is. See *note Inheritance and 43407 GTY:: for more information. 43408 43409'cache' 43410 43411 When the 'cache' option is applied to a global variable 43412 gt_clear_cache is called on that variable between the mark and 43413 sweep phases of garbage collection. The gt_clear_cache function is 43414 free to mark blocks as used, or to clear pointers in the variable. 43415 43416'deletable' 43417 43418 'deletable', when applied to a global variable, indicates that when 43419 garbage collection runs, there's no need to mark anything pointed 43420 to by this variable, it can just be set to 'NULL' instead. This is 43421 used to keep a list of free structures around for re-use. 43422 43423'maybe_undef' 43424 43425 When applied to a field, 'maybe_undef' indicates that it's OK if 43426 the structure that this fields points to is never defined, so long 43427 as this field is always 'NULL'. This is used to avoid requiring 43428 backends to define certain optional structures. It doesn't work 43429 with language frontends. 43430 43431'nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 43432 43433 The type machinery expects all pointers to point to the start of an 43434 object. Sometimes for abstraction purposes it's convenient to have 43435 a pointer which points inside an object. So long as it's possible 43436 to convert the original object to and from the pointer, such 43437 pointers can still be used. TYPE is the type of the original 43438 object, the TO EXPRESSION returns the pointer given the original 43439 object, and the FROM EXPRESSION returns the original object given 43440 the pointer. The pointer will be available using the '%h' escape. 43441 43442'chain_next ("EXPRESSION")' 43443'chain_prev ("EXPRESSION")' 43444'chain_circular ("EXPRESSION")' 43445 43446 It's helpful for the type machinery to know if objects are often 43447 chained together in long lists; this lets it generate code that 43448 uses less stack space by iterating along the list instead of 43449 recursing down it. 'chain_next' is an expression for the next item 43450 in the list, 'chain_prev' is an expression for the previous item. 43451 For singly linked lists, use only 'chain_next'; for doubly linked 43452 lists, use both. The machinery requires that taking the next item 43453 of the previous item gives the original item. 'chain_circular' is 43454 similar to 'chain_next', but can be used for circular single linked 43455 lists. 43456 43457'reorder ("FUNCTION NAME")' 43458 43459 Some data structures depend on the relative ordering of pointers. 43460 If the precompiled header machinery needs to change that ordering, 43461 it will call the function referenced by the 'reorder' option, 43462 before changing the pointers in the object that's pointed to by the 43463 field the option applies to. The function must take four 43464 arguments, with the signature 43465 'void *, void *, gt_pointer_operator, void *'. The first parameter 43466 is a pointer to the structure that contains the object being 43467 updated, or the object itself if there is no containing structure. 43468 The second parameter is a cookie that should be ignored. The third 43469 parameter is a routine that, given a pointer, will update it to its 43470 correct new value. The fourth parameter is a cookie that must be 43471 passed to the second parameter. 43472 43473 PCH cannot handle data structures that depend on the absolute 43474 values of pointers. 'reorder' functions can be expensive. When 43475 possible, it is better to depend on properties of the data, like an 43476 ID number or the hash of a string instead. 43477 43478'atomic' 43479 43480 The 'atomic' option can only be used with pointers. It informs the 43481 GC machinery that the memory that the pointer points to does not 43482 contain any pointers, and hence it should be treated by the GC and 43483 PCH machinery as an "atomic" block of memory that does not need to 43484 be examined when scanning memory for pointers. In particular, the 43485 machinery will not scan that memory for pointers to mark them as 43486 reachable (when marking pointers for GC) or to relocate them (when 43487 writing a PCH file). 43488 43489 The 'atomic' option differs from the 'skip' option. 'atomic' keeps 43490 the memory under Garbage Collection, but makes the GC ignore the 43491 contents of the memory. 'skip' is more drastic in that it causes 43492 the pointer and the memory to be completely ignored by the Garbage 43493 Collector. So, memory marked as 'atomic' is automatically freed 43494 when no longer reachable, while memory marked as 'skip' is not. 43495 43496 The 'atomic' option must be used with great care, because all sorts 43497 of problem can occur if used incorrectly, that is, if the memory 43498 the pointer points to does actually contain a pointer. 43499 43500 Here is an example of how to use it: 43501 struct GTY(()) my_struct { 43502 int number_of_elements; 43503 unsigned int * GTY ((atomic)) elements; 43504 }; 43505 In this case, 'elements' is a pointer under GC, and the memory it 43506 points to needs to be allocated using the Garbage Collector, and 43507 will be freed automatically by the Garbage Collector when it is no 43508 longer referenced. But the memory that the pointer points to is an 43509 array of 'unsigned int' elements, and the GC must not try to scan 43510 it to find pointers to mark or relocate, which is why it is marked 43511 with the 'atomic' option. 43512 43513 Note that, currently, global variables cannot be marked with 43514 'atomic'; only fields of a struct can. This is a known limitation. 43515 It would be useful to be able to mark global pointers with 'atomic' 43516 to make the PCH machinery aware of them so that they are saved and 43517 restored correctly to PCH files. 43518 43519'special ("NAME")' 43520 43521 The 'special' option is used to mark types that have to be dealt 43522 with by special case machinery. The parameter is the name of the 43523 special case. See 'gengtype.c' for further details. Avoid adding 43524 new special cases unless there is no other alternative. 43525 43526'user' 43527 43528 The 'user' option indicates that the code to mark structure fields 43529 is completely handled by user-provided routines. See section *note 43530 User GC:: for details on what functions need to be provided. 43531 43532 43533File: gccint.info, Node: Inheritance and GTY, Next: User GC, Prev: GTY Options, Up: Type Information 43534 4353523.2 Support for inheritance 43536============================ 43537 43538gengtype has some support for simple class hierarchies. You can use 43539this to have gengtype autogenerate marking routines, provided: 43540 43541 * There must be a concrete base class, with a discriminator 43542 expression that can be used to identify which subclass an instance 43543 is. 43544 * Only single inheritance is used. 43545 * None of the classes within the hierarchy are templates. 43546 43547 If your class hierarchy does not fit in this pattern, you must use 43548*note User GC:: instead. 43549 43550 The base class and its discriminator must be identified using the 43551"desc" option. Each concrete subclass must use the "tag" option to 43552identify which value of the discriminator it corresponds to. 43553 43554 Every class in the hierarchy must have a 'GTY(())' marker, as gengtype 43555will only attempt to parse classes that have such a marker (1). 43556 43557 class GTY((desc("%h.kind"), tag("0"))) example_base 43558 { 43559 public: 43560 int kind; 43561 tree a; 43562 }; 43563 43564 class GTY((tag("1"))) some_subclass : public example_base 43565 { 43566 public: 43567 tree b; 43568 }; 43569 43570 class GTY((tag("2"))) some_other_subclass : public example_base 43571 { 43572 public: 43573 tree c; 43574 }; 43575 43576 The generated marking routines for the above will contain a "switch" on 43577"kind", visiting all appropriate fields. For example, if kind is 2, it 43578will cast to "some_other_subclass" and visit fields a, b, and c. 43579 43580 ---------- Footnotes ---------- 43581 43582 (1) Classes lacking such a marker will not be identified as being 43583part of the hierarchy, and so the marking routines will not handle them, 43584leading to a assertion failure within the marking routines due to an 43585unknown tag value (assuming that assertions are enabled). 43586 43587 43588File: gccint.info, Node: User GC, Next: GGC Roots, Prev: Inheritance and GTY, Up: Type Information 43589 4359023.3 Support for user-provided GC marking routines 43591================================================== 43592 43593The garbage collector supports types for which no automatic marking code 43594is generated. For these types, the user is required to provide three 43595functions: one to act as a marker for garbage collection, and two 43596functions to act as marker and pointer walker for pre-compiled headers. 43597 43598 Given a structure 'struct GTY((user)) my_struct', the following 43599functions should be defined to mark 'my_struct': 43600 43601 void gt_ggc_mx (my_struct *p) 43602 { 43603 /* This marks field 'fld'. */ 43604 gt_ggc_mx (p->fld); 43605 } 43606 43607 void gt_pch_nx (my_struct *p) 43608 { 43609 /* This marks field 'fld'. */ 43610 gt_pch_nx (tp->fld); 43611 } 43612 43613 void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie) 43614 { 43615 /* For every field 'fld', call the given pointer operator. */ 43616 op (&(tp->fld), cookie); 43617 } 43618 43619 In general, each marker 'M' should call 'M' for every pointer field in 43620the structure. Fields that are not allocated in GC or are not pointers 43621must be ignored. 43622 43623 For embedded lists (e.g., structures with a 'next' or 'prev' pointer), 43624the marker must follow the chain and mark every element in it. 43625 43626 Note that the rules for the pointer walker 'gt_pch_nx (my_struct *, 43627gt_pointer_operator, void *)' are slightly different. In this case, the 43628operation 'op' must be applied to the _address_ of every pointer field. 43629 4363023.3.1 User-provided marking routines for template types 43631-------------------------------------------------------- 43632 43633When a template type 'TP' is marked with 'GTY', all instances of that 43634type are considered user-provided types. This means that the individual 43635instances of 'TP' do not need to be marked with 'GTY'. The user needs 43636to provide template functions to mark all the fields of the type. 43637 43638 The following code snippets represent all the functions that need to be 43639provided. Note that type 'TP' may reference to more than one type. In 43640these snippets, there is only one type 'T', but there could be more. 43641 43642 template<typename T> 43643 void gt_ggc_mx (TP<T> *tp) 43644 { 43645 extern void gt_ggc_mx (T&); 43646 43647 /* This marks field 'fld' of type 'T'. */ 43648 gt_ggc_mx (tp->fld); 43649 } 43650 43651 template<typename T> 43652 void gt_pch_nx (TP<T> *tp) 43653 { 43654 extern void gt_pch_nx (T&); 43655 43656 /* This marks field 'fld' of type 'T'. */ 43657 gt_pch_nx (tp->fld); 43658 } 43659 43660 template<typename T> 43661 void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie) 43662 { 43663 /* For every field 'fld' of 'tp' with type 'T *', call the given 43664 pointer operator. */ 43665 op (&(tp->fld), cookie); 43666 } 43667 43668 template<typename T> 43669 void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie) 43670 { 43671 extern void gt_pch_nx (T *, gt_pointer_operator, void *); 43672 43673 /* For every field 'fld' of 'tp' with type 'T', call the pointer 43674 walker for all the fields of T. */ 43675 gt_pch_nx (&(tp->fld), op, cookie); 43676 } 43677 43678 Support for user-defined types is currently limited. The following 43679restrictions apply: 43680 43681 1. Type 'TP' and all the argument types 'T' must be marked with 'GTY'. 43682 43683 2. Type 'TP' can only have type names in its argument list. 43684 43685 3. The pointer walker functions are different for 'TP<T>' and 'TP<T 43686 *>'. In the case of 'TP<T>', references to 'T' must be handled by 43687 calling 'gt_pch_nx' (which will, in turn, walk all the pointers 43688 inside fields of 'T'). In the case of 'TP<T *>', references to 'T 43689 *' must be handled by calling the 'op' function on the address of 43690 the pointer (see the code snippets above). 43691 43692 43693File: gccint.info, Node: GGC Roots, Next: Files, Prev: User GC, Up: Type Information 43694 4369523.4 Marking Roots for the Garbage Collector 43696============================================ 43697 43698In addition to keeping track of types, the type machinery also locates 43699the global variables ("roots") that the garbage collector starts at. 43700Roots must be declared using one of the following syntaxes: 43701 43702 * 'extern GTY(([OPTIONS])) TYPE NAME;' 43703 * 'static GTY(([OPTIONS])) TYPE NAME;' 43704The syntax 43705 * 'GTY(([OPTIONS])) TYPE NAME;' 43706is _not_ accepted. There should be an 'extern' declaration of such a 43707variable in a header somewhere--mark that, not the definition. Or, if 43708the variable is only used in one file, make it 'static'. 43709 43710 43711File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 43712 4371323.5 Source Files Containing Type Information 43714============================================= 43715 43716Whenever you add 'GTY' markers to a source file that previously had 43717none, or create a new source file containing 'GTY' markers, there are 43718three things you need to do: 43719 43720 1. You need to add the file to the list of source files the type 43721 machinery scans. There are four cases: 43722 43723 a. For a back-end file, this is usually done automatically; if 43724 not, you should add it to 'target_gtfiles' in the appropriate 43725 port's entries in 'config.gcc'. 43726 43727 b. For files shared by all front ends, add the filename to the 43728 'GTFILES' variable in 'Makefile.in'. 43729 43730 c. For files that are part of one front end, add the filename to 43731 the 'gtfiles' variable defined in the appropriate 43732 'config-lang.in'. Headers should appear before non-headers in 43733 this list. 43734 43735 d. For files that are part of some but not all front ends, add 43736 the filename to the 'gtfiles' variable of _all_ the front ends 43737 that use it. 43738 43739 2. If the file was a header file, you'll need to check that it's 43740 included in the right place to be visible to the generated files. 43741 For a back-end header file, this should be done automatically. For 43742 a front-end header file, it needs to be included by the same file 43743 that includes 'gtype-LANG.h'. For other header files, it needs to 43744 be included in 'gtype-desc.c', which is a generated file, so add it 43745 to 'ifiles' in 'open_base_file' in 'gengtype.c'. 43746 43747 For source files that aren't header files, the machinery will 43748 generate a header file that should be included in the source file 43749 you just changed. The file will be called 'gt-PATH.h' where PATH 43750 is the pathname relative to the 'gcc' directory with slashes 43751 replaced by -, so for example the header file to be included in 43752 'cp/parser.c' is called 'gt-cp-parser.c'. The generated header 43753 file should be included after everything else in the source file. 43754 Don't forget to mention this file as a dependency in the 43755 'Makefile'! 43756 43757 For language frontends, there is another file that needs to be included 43758somewhere. It will be called 'gtype-LANG.h', where LANG is the name of 43759the subdirectory the language is contained in. 43760 43761 Plugins can add additional root tables. Run the 'gengtype' utility in 43762plugin mode as 'gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 43763with your plugin files PLUGIN*.C using 'GTY' to generate the PLUGINOUT.H 43764file. The GCC build tree is needed to be present in that mode. 43765 43766 43767File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information 43768 4376923.6 How to invoke the garbage collector 43770======================================== 43771 43772The GCC garbage collector GGC is only invoked explicitly. In contrast 43773with many other garbage collectors, it is not implicitly invoked by 43774allocation routines when a lot of memory has been consumed. So the only 43775way to have GGC reclaim storage is to call the 'ggc_collect' function 43776explicitly. This call is an expensive operation, as it may have to scan 43777the entire heap. Beware that local variables (on the GCC call stack) 43778are not followed by such an invocation (as many other garbage collectors 43779do): you should reference all your data from static or external 'GTY'-ed 43780variables, and it is advised to call 'ggc_collect' with a shallow call 43781stack. The GGC is an exact mark and sweep garbage collector (so it does 43782not scan the call stack for pointers). In practice GCC passes don't 43783often call 'ggc_collect' themselves, because it is called by the pass 43784manager between passes. 43785 43786 At the time of the 'ggc_collect' call all pointers in the GC-marked 43787structures must be valid or 'NULL'. In practice this means that there 43788should not be uninitialized pointer fields in the structures even if 43789your code never reads or writes those fields at a particular instance. 43790One way to ensure this is to use cleared versions of allocators unless 43791all the fields are initialized manually immediately after allocation. 43792 43793 43794File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information 43795 4379623.7 Troubleshooting the garbage collector 43797========================================== 43798 43799With the current garbage collector implementation, most issues should 43800show up as GCC compilation errors. Some of the most commonly 43801encountered issues are described below. 43802 43803 * Gengtype does not produce allocators for a 'GTY'-marked type. 43804 Gengtype checks if there is at least one possible path from GC 43805 roots to at least one instance of each type before outputting 43806 allocators. If there is no such path, the 'GTY' markers will be 43807 ignored and no allocators will be output. Solve this by making 43808 sure that there exists at least one such path. If creating it is 43809 unfeasible or raises a "code smell", consider if you really must 43810 use GC for allocating such type. 43811 43812 * Link-time errors about undefined 'gt_ggc_r_foo_bar' and 43813 similarly-named symbols. Check if your 'foo_bar' source file has 43814 '#include "gt-foo_bar.h"' as its very last line. 43815 43816 43817File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top 43818 4381924 Plugins 43820********** 43821 43822GCC plugins are loadable modules that provide extra features to the 43823compiler. Like GCC itself they can be distributed in source and binary 43824forms. 43825 43826 GCC plugins provide developers with a rich subset of the GCC API to 43827allow them to extend GCC as they see fit. Whether it is writing an 43828additional optimization pass, transforming code, or analyzing 43829information, plugins can be quite useful. 43830 43831* Menu: 43832 43833* Plugins loading:: How can we load plugins. 43834* Plugin API:: The APIs for plugins. 43835* Plugins pass:: How a plugin interact with the pass manager. 43836* Plugins GC:: How a plugin Interact with GCC Garbage Collector. 43837* Plugins description:: Giving information about a plugin itself. 43838* Plugins attr:: Registering custom attributes or pragmas. 43839* Plugins recording:: Recording information about pass execution. 43840* Plugins gate:: Controlling which passes are being run. 43841* Plugins tracking:: Keeping track of available passes. 43842* Plugins building:: How can we build a plugin. 43843 43844 43845File: gccint.info, Node: Plugins loading, Next: Plugin API, Up: Plugins 43846 4384724.1 Loading Plugins 43848==================== 43849 43850Plugins are supported on platforms that support '-ldl -rdynamic' as well 43851as Windows/MinGW. They are loaded by the compiler using 'dlopen' or 43852equivalent and invoked at pre-determined locations in the compilation 43853process. 43854 43855 Plugins are loaded with 43856 43857 '-fplugin=/path/to/NAME.EXT' '-fplugin-arg-NAME-KEY1[=VALUE1]' 43858 43859 Where NAME is the plugin name and EXT is the platform-specific dynamic 43860library extension. It should be 'dll' on Windows/MinGW, 'dylib' on 43861Darwin/Mac OS X, and 'so' on all other platforms. The plugin arguments 43862are parsed by GCC and passed to respective plugins as key-value pairs. 43863Multiple plugins can be invoked by specifying multiple '-fplugin' 43864arguments. 43865 43866 A plugin can be simply given by its short name (no dots or slashes). 43867When simply passing '-fplugin=NAME', the plugin is loaded from the 43868'plugin' directory, so '-fplugin=NAME' is the same as '-fplugin=`gcc 43869-print-file-name=plugin`/NAME.EXT', using backquote shell syntax to 43870query the 'plugin' directory. 43871 43872 43873File: gccint.info, Node: Plugin API, Next: Plugins pass, Prev: Plugins loading, Up: Plugins 43874 4387524.2 Plugin API 43876=============== 43877 43878Plugins are activated by the compiler at specific events as defined in 43879'gcc-plugin.h'. For each event of interest, the plugin should call 43880'register_callback' specifying the name of the event and address of the 43881callback function that will handle that event. 43882 43883 The header 'gcc-plugin.h' must be the first gcc header to be included. 43884 4388524.2.1 Plugin license check 43886--------------------------- 43887 43888Every plugin should define the global symbol 'plugin_is_GPL_compatible' 43889to assert that it has been licensed under a GPL-compatible license. If 43890this symbol does not exist, the compiler will emit a fatal error and 43891exit with the error message: 43892 43893 fatal error: plugin NAME is not licensed under a GPL-compatible license 43894 NAME: undefined symbol: plugin_is_GPL_compatible 43895 compilation terminated 43896 43897 The declared type of the symbol should be int, to match a forward 43898declaration in 'gcc-plugin.h' that suppresses C++ mangling. It does not 43899need to be in any allocated section, though. The compiler merely 43900asserts that the symbol exists in the global scope. Something like this 43901is enough: 43902 43903 int plugin_is_GPL_compatible; 43904 4390524.2.2 Plugin initialization 43906---------------------------- 43907 43908Every plugin should export a function called 'plugin_init' that is 43909called right after the plugin is loaded. This function is responsible 43910for registering all the callbacks required by the plugin and do any 43911other required initialization. 43912 43913 This function is called from 'compile_file' right before invoking the 43914parser. The arguments to 'plugin_init' are: 43915 43916 * 'plugin_info': Plugin invocation information. 43917 * 'version': GCC version. 43918 43919 The 'plugin_info' struct is defined as follows: 43920 43921 struct plugin_name_args 43922 { 43923 char *base_name; /* Short name of the plugin 43924 (filename without .so suffix). */ 43925 const char *full_name; /* Path to the plugin as specified with 43926 -fplugin=. */ 43927 int argc; /* Number of arguments specified with 43928 -fplugin-arg-.... */ 43929 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 43930 const char *version; /* Version string provided by plugin. */ 43931 const char *help; /* Help string provided by plugin. */ 43932 } 43933 43934 If initialization fails, 'plugin_init' must return a non-zero value. 43935Otherwise, it should return 0. 43936 43937 The version of the GCC compiler loading the plugin is described by the 43938following structure: 43939 43940 struct plugin_gcc_version 43941 { 43942 const char *basever; 43943 const char *datestamp; 43944 const char *devphase; 43945 const char *revision; 43946 const char *configuration_arguments; 43947 }; 43948 43949 The function 'plugin_default_version_check' takes two pointers to such 43950structure and compare them field by field. It can be used by the 43951plugin's 'plugin_init' function. 43952 43953 The version of GCC used to compile the plugin can be found in the 43954symbol 'gcc_version' defined in the header 'plugin-version.h'. The 43955recommended version check to perform looks like 43956 43957 #include "plugin-version.h" 43958 ... 43959 43960 int 43961 plugin_init (struct plugin_name_args *plugin_info, 43962 struct plugin_gcc_version *version) 43963 { 43964 if (!plugin_default_version_check (version, &gcc_version)) 43965 return 1; 43966 43967 } 43968 43969 but you can also check the individual fields if you want a less strict 43970check. 43971 4397224.2.3 Plugin callbacks 43973----------------------- 43974 43975Callback functions have the following prototype: 43976 43977 /* The prototype for a plugin callback function. 43978 gcc_data - event-specific data provided by GCC 43979 user_data - plugin-specific data provided by the plug-in. */ 43980 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 43981 43982 Callbacks can be invoked at the following pre-determined events: 43983 43984 enum plugin_event 43985 { 43986 PLUGIN_START_PARSE_FUNCTION, /* Called before parsing the body of a function. */ 43987 PLUGIN_FINISH_PARSE_FUNCTION, /* After finishing parsing a function. */ 43988 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 43989 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 43990 PLUGIN_FINISH_DECL, /* After finishing parsing a declaration. */ 43991 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 43992 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 43993 PLUGIN_FINISH, /* Called before GCC exits. */ 43994 PLUGIN_INFO, /* Information about the plugin. */ 43995 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 43996 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 43997 PLUGIN_GGC_END, /* Called at end of GGC. */ 43998 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 43999 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 44000 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 44001 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 44002 /* Called before first pass from all_passes. */ 44003 PLUGIN_ALL_PASSES_START, 44004 /* Called after last pass from all_passes. */ 44005 PLUGIN_ALL_PASSES_END, 44006 /* Called before first ipa pass. */ 44007 PLUGIN_ALL_IPA_PASSES_START, 44008 /* Called after last ipa pass. */ 44009 PLUGIN_ALL_IPA_PASSES_END, 44010 /* Allows to override pass gate decision for current_pass. */ 44011 PLUGIN_OVERRIDE_GATE, 44012 /* Called before executing a pass. */ 44013 PLUGIN_PASS_EXECUTION, 44014 /* Called before executing subpasses of a GIMPLE_PASS in 44015 execute_ipa_pass_list. */ 44016 PLUGIN_EARLY_GIMPLE_PASSES_START, 44017 /* Called after executing subpasses of a GIMPLE_PASS in 44018 execute_ipa_pass_list. */ 44019 PLUGIN_EARLY_GIMPLE_PASSES_END, 44020 /* Called when a pass is first instantiated. */ 44021 PLUGIN_NEW_PASS, 44022 /* Called when a file is #include-d or given via the #line directive. 44023 This could happen many times. The event data is the included file path, 44024 as a const char* pointer. */ 44025 PLUGIN_INCLUDE_FILE, 44026 44027 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 44028 array. */ 44029 }; 44030 44031 In addition, plugins can also look up the enumerator of a named event, 44032and / or generate new events dynamically, by calling the function 44033'get_named_event_id'. 44034 44035 To register a callback, the plugin calls 'register_callback' with the 44036arguments: 44037 44038 * 'char *name': Plugin name. 44039 * 'int event': The event code. 44040 * 'plugin_callback_func callback': The function that handles 'event'. 44041 * 'void *user_data': Pointer to plugin-specific data. 44042 44043 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, and 44044PLUGIN_REGISTER_GGC_ROOTS pseudo-events the 'callback' should be null, 44045and the 'user_data' is specific. 44046 44047 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as data 44048from GCC), plugins may register their own pragmas. Notice that pragmas 44049are not available from 'lto1', so plugins used with '-flto' option to 44050GCC during link-time optimization cannot use pragmas and do not even see 44051functions like 'c_register_pragma' or 'pragma_lex'. 44052 44053 The PLUGIN_INCLUDE_FILE event, with a 'const char*' file path as GCC 44054data, is triggered for processing of '#include' or '#line' directives. 44055 44056 The PLUGIN_FINISH event is the last time that plugins can call GCC 44057functions, notably emit diagnostics with 'warning', 'error' etc. 44058 44059 44060File: gccint.info, Node: Plugins pass, Next: Plugins GC, Prev: Plugin API, Up: Plugins 44061 4406224.3 Interacting with the pass manager 44063====================================== 44064 44065There needs to be a way to add/reorder/remove passes dynamically. This 44066is useful for both analysis plugins (plugging in after a certain pass 44067such as CFG or an IPA pass) and optimization plugins. 44068 44069 Basic support for inserting new passes or replacing existing passes is 44070provided. A plugin registers a new pass with GCC by calling 44071'register_callback' with the 'PLUGIN_PASS_MANAGER_SETUP' event and a 44072pointer to a 'struct register_pass_info' object defined as follows 44073 44074 enum pass_positioning_ops 44075 { 44076 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 44077 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 44078 PASS_POS_REPLACE // Replace the reference pass. 44079 }; 44080 44081 struct register_pass_info 44082 { 44083 struct opt_pass *pass; /* New pass provided by the plugin. */ 44084 const char *reference_pass_name; /* Name of the reference pass for hooking 44085 up the new pass. */ 44086 int ref_pass_instance_number; /* Insert the pass at the specified 44087 instance number of the reference pass. */ 44088 /* Do it for every instance if it is 0. */ 44089 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 44090 }; 44091 44092 44093 /* Sample plugin code that registers a new pass. */ 44094 int 44095 plugin_init (struct plugin_name_args *plugin_info, 44096 struct plugin_gcc_version *version) 44097 { 44098 struct register_pass_info pass_info; 44099 44100 ... 44101 44102 /* Code to fill in the pass_info object with new pass information. */ 44103 44104 ... 44105 44106 /* Register the new pass. */ 44107 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 44108 44109 ... 44110 } 44111 44112 44113File: gccint.info, Node: Plugins GC, Next: Plugins description, Prev: Plugins pass, Up: Plugins 44114 4411524.4 Interacting with the GCC Garbage Collector 44116=============================================== 44117 44118Some plugins may want to be informed when GGC (the GCC Garbage 44119Collector) is running. They can register callbacks for the 44120'PLUGIN_GGC_START' and 'PLUGIN_GGC_END' events (for which the callback 44121is called with a null 'gcc_data') to be notified of the start or end of 44122the GCC garbage collection. 44123 44124 Some plugins may need to have GGC mark additional data. This can be 44125done by registering a callback (called with a null 'gcc_data') for the 44126'PLUGIN_GGC_MARKING' event. Such callbacks can call the 'ggc_set_mark' 44127routine, preferably through the 'ggc_mark' macro (and conversely, these 44128routines should usually not be used in plugins outside of the 44129'PLUGIN_GGC_MARKING' event). Plugins that wish to hold weak references 44130to gc data may also use this event to drop weak references when the 44131object is about to be collected. The 'ggc_marked_p' function can be 44132used to tell if an object is marked, or is about to be collected. The 44133'gt_clear_cache' overloads which some types define may also be of use in 44134managing weak references. 44135 44136 Some plugins may need to add extra GGC root tables, e.g. to handle 44137their own 'GTY'-ed data. This can be done with the 44138'PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 44139extra root table (of type 'struct ggc_root_tab*') as 'user_data'. 44140Running the 'gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 44141generates these extra root tables. 44142 44143 You should understand the details of memory management inside GCC 44144before using 'PLUGIN_GGC_MARKING' or 'PLUGIN_REGISTER_GGC_ROOTS'. 44145 44146 44147File: gccint.info, Node: Plugins description, Next: Plugins attr, Prev: Plugins GC, Up: Plugins 44148 4414924.5 Giving information about a plugin 44150====================================== 44151 44152A plugin should give some information to the user about itself. This 44153uses the following structure: 44154 44155 struct plugin_info 44156 { 44157 const char *version; 44158 const char *help; 44159 }; 44160 44161 Such a structure is passed as the 'user_data' by the plugin's init 44162routine using 'register_callback' with the 'PLUGIN_INFO' pseudo-event 44163and a null callback. 44164 44165 44166File: gccint.info, Node: Plugins attr, Next: Plugins recording, Prev: Plugins description, Up: Plugins 44167 4416824.6 Registering custom attributes or pragmas 44169============================================= 44170 44171For analysis (or other) purposes it is useful to be able to add custom 44172attributes or pragmas. 44173 44174 The 'PLUGIN_ATTRIBUTES' callback is called during attribute 44175registration. Use the 'register_attribute' function to register custom 44176attributes. 44177 44178 /* Attribute handler callback */ 44179 static tree 44180 handle_user_attribute (tree *node, tree name, tree args, 44181 int flags, bool *no_add_attrs) 44182 { 44183 return NULL_TREE; 44184 } 44185 44186 /* Attribute definition */ 44187 static struct attribute_spec user_attr = 44188 { "user", 1, 1, false, false, false, false, handle_user_attribute, NULL }; 44189 44190 /* Plugin callback called during attribute registration. 44191 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 44192 */ 44193 static void 44194 register_attributes (void *event_data, void *data) 44195 { 44196 warning (0, G_("Callback to register attributes")); 44197 register_attribute (&user_attr); 44198 } 44199 44200 44201 The PLUGIN_PRAGMAS callback is called once during pragmas registration. 44202Use the 'c_register_pragma', 'c_register_pragma_with_data', 44203'c_register_pragma_with_expansion', 44204'c_register_pragma_with_expansion_and_data' functions to register custom 44205pragmas and their handlers (which often want to call 'pragma_lex') from 44206'c-family/c-pragma.h'. 44207 44208 /* Plugin callback called during pragmas registration. Registered with 44209 register_callback (plugin_name, PLUGIN_PRAGMAS, 44210 register_my_pragma, NULL); 44211 */ 44212 static void 44213 register_my_pragma (void *event_data, void *data) 44214 { 44215 warning (0, G_("Callback to register pragmas")); 44216 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 44217 } 44218 44219 It is suggested to pass '"GCCPLUGIN"' (or a short name identifying your 44220plugin) as the "space" argument of your pragma. 44221 44222 Pragmas registered with 'c_register_pragma_with_expansion' or 44223'c_register_pragma_with_expansion_and_data' support preprocessor 44224expansions. For example: 44225 44226 #define NUMBER 10 44227 #pragma GCCPLUGIN foothreshold (NUMBER) 44228 44229 44230File: gccint.info, Node: Plugins recording, Next: Plugins gate, Prev: Plugins attr, Up: Plugins 44231 4423224.7 Recording information about pass execution 44233=============================================== 44234 44235The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 44236(the same as current_pass) as 'gcc_data' to the callback. You can also 44237inspect cfun to find out about which function this pass is executed for. 44238Note that this event will only be invoked if the gate check (if 44239applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 44240other hooks, like 'PLUGIN_ALL_PASSES_START', 'PLUGIN_ALL_PASSES_END', 44241'PLUGIN_ALL_IPA_PASSES_START', 'PLUGIN_ALL_IPA_PASSES_END', 44242'PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 44243'PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 44244plugin(s) in order to get context for the pass execution. 44245 44246 44247File: gccint.info, Node: Plugins gate, Next: Plugins tracking, Prev: Plugins recording, Up: Plugins 44248 4424924.8 Controlling which passes are being run 44250=========================================== 44251 44252After the original gate function for a pass is called, its result - the 44253gate status - is stored as an integer. Then the event 44254'PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 44255the 'gcc_data' parameter to the callback function. A nonzero value of 44256the gate status means that the pass is to be executed. You can both 44257read and write the gate status via the passed pointer. 44258 44259 44260File: gccint.info, Node: Plugins tracking, Next: Plugins building, Prev: Plugins gate, Up: Plugins 44261 4426224.9 Keeping track of available passes 44263====================================== 44264 44265When your plugin is loaded, you can inspect the various pass lists to 44266determine what passes are available. However, other plugins might add 44267new passes. Also, future changes to GCC might cause generic passes to 44268be added after plugin loading. When a pass is first added to one of the 44269pass lists, the event 'PLUGIN_NEW_PASS' is invoked, with the callback 44270parameter 'gcc_data' pointing to the new pass. 44271 44272 44273File: gccint.info, Node: Plugins building, Prev: Plugins tracking, Up: Plugins 44274 4427524.10 Building GCC plugins 44276========================== 44277 44278If plugins are enabled, GCC installs the headers needed to build a 44279plugin (somewhere in the installation tree, e.g. under '/usr/local'). 44280In particular a 'plugin/include' directory is installed, containing all 44281the header files needed to build plugins. 44282 44283 On most systems, you can query this 'plugin' directory by invoking 'gcc 44284-print-file-name=plugin' (replace if needed 'gcc' with the appropriate 44285program path). 44286 44287 Inside plugins, this 'plugin' directory name can be queried by calling 44288'default_plugin_dir_name ()'. 44289 44290 Plugins may know, when they are compiled, the GCC version for which 44291'plugin-version.h' is provided. The constant macros 44292'GCCPLUGIN_VERSION_MAJOR', 'GCCPLUGIN_VERSION_MINOR', 44293'GCCPLUGIN_VERSION_PATCHLEVEL', 'GCCPLUGIN_VERSION' are integer numbers, 44294so a plugin could ensure it is built for GCC 4.7 with 44295 #if GCCPLUGIN_VERSION != 4007 44296 #error this GCC plugin is for GCC 4.7 44297 #endif 44298 44299 The following GNU Makefile excerpt shows how to build a simple plugin: 44300 44301 HOST_GCC=g++ 44302 TARGET_GCC=gcc 44303 PLUGIN_SOURCE_FILES= plugin1.c plugin2.cc 44304 GCCPLUGINS_DIR:= $(shell $(TARGET_GCC) -print-file-name=plugin) 44305 CXXFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -fno-rtti -O2 44306 44307 plugin.so: $(PLUGIN_SOURCE_FILES) 44308 $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@ 44309 44310 A single source file plugin may be built with 'g++ -I`gcc 44311-print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.c -o 44312plugin.so', using backquote shell syntax to query the 'plugin' 44313directory. 44314 44315 Plugin support on Windows/MinGW has a number of limitations and 44316additional requirements. When building a plugin on Windows we have to 44317link an import library for the corresponding backend executable, for 44318example, 'cc1.exe', 'cc1plus.exe', etc., in order to gain access to the 44319symbols provided by GCC. This means that on Windows a plugin is 44320language-specific, for example, for C, C++, etc. If you wish to use 44321your plugin with multiple languages, then you will need to build 44322multiple plugin libraries and either instruct your users on how to load 44323the correct version or provide a compiler wrapper that does this 44324automatically. 44325 44326 Additionally, on Windows the plugin library has to export the 44327'plugin_is_GPL_compatible' and 'plugin_init' symbols. If you do not 44328wish to modify the source code of your plugin, then you can use the 44329'-Wl,--export-all-symbols' option or provide a suitable DEF file. 44330Alternatively, you can export just these two symbols by decorating them 44331with '__declspec(dllexport)', for example: 44332 44333 #ifdef _WIN32 44334 __declspec(dllexport) 44335 #endif 44336 int plugin_is_GPL_compatible; 44337 44338 #ifdef _WIN32 44339 __declspec(dllexport) 44340 #endif 44341 int plugin_init (plugin_name_args *, plugin_gcc_version *) 44342 44343 The import libraries are installed into the 'plugin' directory and 44344their names are derived by appending the '.a' extension to the backend 44345executable names, for example, 'cc1.exe.a', 'cc1plus.exe.a', etc. The 44346following command line shows how to build the single source file plugin 44347on Windows to be used with the C++ compiler: 44348 44349 g++ -I`gcc -print-file-name=plugin`/include -shared -Wl,--export-all-symbols \ 44350 -o plugin.dll plugin.c `gcc -print-file-name=plugin`/cc1plus.exe.a 44351 44352 When a plugin needs to use 'gengtype', be sure that both 'gengtype' and 44353'gtype.state' have the same version as the GCC for which the plugin is 44354built. 44355 44356 44357File: gccint.info, Node: LTO, Next: Match and Simplify, Prev: Plugins, Up: Top 44358 4435925 Link Time Optimization 44360************************* 44361 44362Link Time Optimization (LTO) gives GCC the capability of dumping its 44363internal representation (GIMPLE) to disk, so that all the different 44364compilation units that make up a single executable can be optimized as a 44365single module. This expands the scope of inter-procedural optimizations 44366to encompass the whole program (or, rather, everything that is visible 44367at link time). 44368 44369* Menu: 44370 44371* LTO Overview:: Overview of LTO. 44372* LTO object file layout:: LTO file sections in ELF. 44373* IPA:: Using summary information in IPA passes. 44374* WHOPR:: Whole program assumptions, 44375 linker plugin and symbol visibilities. 44376* Internal flags:: Internal flags controlling 'lto1'. 44377 44378 44379File: gccint.info, Node: LTO Overview, Next: LTO object file layout, Up: LTO 44380 4438125.1 Design Overview 44382==================== 44383 44384Link time optimization is implemented as a GCC front end for a bytecode 44385representation of GIMPLE that is emitted in special sections of '.o' 44386files. Currently, LTO support is enabled in most ELF-based systems, as 44387well as darwin, cygwin and mingw systems. 44388 44389 Since GIMPLE bytecode is saved alongside final object code, object 44390files generated with LTO support are larger than regular object files. 44391This "fat" object format makes it easy to integrate LTO into existing 44392build systems, as one can, for instance, produce archives of the files. 44393Additionally, one might be able to ship one set of fat objects which 44394could be used both for development and the production of optimized 44395builds. A, perhaps surprising, side effect of this feature is that any 44396mistake in the toolchain leads to LTO information not being used (e.g. 44397an older 'libtool' calling 'ld' directly). This is both an advantage, 44398as the system is more robust, and a disadvantage, as the user is not 44399informed that the optimization has been disabled. 44400 44401 The current implementation only produces "fat" objects, effectively 44402doubling compilation time and increasing file sizes up to 5x the 44403original size. This hides the problem that some tools, such as 'ar' and 44404'nm', need to understand symbol tables of LTO sections. These tools 44405were extended to use the plugin infrastructure, and with these problems 44406solved, GCC will also support "slim" objects consisting of the 44407intermediate code alone. 44408 44409 At the highest level, LTO splits the compiler in two. The first half 44410(the "writer") produces a streaming representation of all the internal 44411data structures needed to optimize and generate code. This includes 44412declarations, types, the callgraph and the GIMPLE representation of 44413function bodies. 44414 44415 When '-flto' is given during compilation of a source file, the pass 44416manager executes all the passes in 'all_lto_gen_passes'. Currently, 44417this phase is composed of two IPA passes: 44418 44419 * 'pass_ipa_lto_gimple_out' This pass executes the function 44420 'lto_output' in 'lto-streamer-out.c', which traverses the call 44421 graph encoding every reachable declaration, type and function. 44422 This generates a memory representation of all the file sections 44423 described below. 44424 44425 * 'pass_ipa_lto_finish_out' This pass executes the function 44426 'produce_asm_for_decls' in 'lto-streamer-out.c', which takes the 44427 memory image built in the previous pass and encodes it in the 44428 corresponding ELF file sections. 44429 44430 The second half of LTO support is the "reader". This is implemented as 44431the GCC front end 'lto1' in 'lto/lto.c'. When 'collect2' detects a link 44432set of '.o'/'.a' files with LTO information and the '-flto' is enabled, 44433it invokes 'lto1' which reads the set of files and aggregates them into 44434a single translation unit for optimization. The main entry point for 44435the reader is 'lto/lto.c':'lto_main'. 44436 4443725.1.1 LTO modes of operation 44438----------------------------- 44439 44440One of the main goals of the GCC link-time infrastructure was to allow 44441effective compilation of large programs. For this reason GCC implements 44442two link-time compilation modes. 44443 44444 1. _LTO mode_, in which the whole program is read into the compiler at 44445 link-time and optimized in a similar way as if it were a single 44446 source-level compilation unit. 44447 44448 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs 44449 and/or a distributed compilation environment to quickly link large 44450 applications. WHOPR stands for WHOle Program optimizeR (not to be 44451 confused with the semantics of '-fwhole-program'). It partitions 44452 the aggregated callgraph from many different '.o' files and 44453 distributes the compilation of the sub-graphs to different CPUs. 44454 44455 Note that distributed compilation is not implemented yet, but since 44456 the parallelism is facilitated via generating a 'Makefile', it 44457 would be easy to implement. 44458 44459 WHOPR splits LTO into three main stages: 44460 1. Local generation (LGEN) This stage executes in parallel. Every 44461 file in the program is compiled into the intermediate language and 44462 packaged together with the local call-graph and summary 44463 information. This stage is the same for both the LTO and WHOPR 44464 compilation mode. 44465 44466 2. Whole Program Analysis (WPA) WPA is performed sequentially. The 44467 global call-graph is generated, and a global analysis procedure 44468 makes transformation decisions. The global call-graph is 44469 partitioned to facilitate parallel optimization during phase 3. 44470 The results of the WPA stage are stored into new object files which 44471 contain the partitions of program expressed in the intermediate 44472 language and the optimization decisions. 44473 44474 3. Local transformations (LTRANS) This stage executes in parallel. 44475 All the decisions made during phase 2 are implemented locally in 44476 each partitioned object file, and the final object code is 44477 generated. Optimizations which cannot be decided efficiently 44478 during the phase 2 may be performed on the local call-graph 44479 partitions. 44480 44481 WHOPR can be seen as an extension of the usual LTO mode of compilation. 44482In LTO, WPA and LTRANS are executed within a single execution of the 44483compiler, after the whole program has been read into memory. 44484 44485 When compiling in WHOPR mode, the callgraph is partitioned during the 44486WPA stage. The whole program is split into a given number of partitions 44487of roughly the same size. The compiler tries to minimize the number of 44488references which cross partition boundaries. The main advantage of 44489WHOPR is to allow the parallel execution of LTRANS stages, which are the 44490most time-consuming part of the compilation process. Additionally, it 44491avoids the need to load the whole program into memory. 44492 44493 44494File: gccint.info, Node: LTO object file layout, Next: IPA, Prev: LTO Overview, Up: LTO 44495 4449625.2 LTO file sections 44497====================== 44498 44499LTO information is stored in several ELF sections inside object files. 44500Data structures and enum codes for sections are defined in 44501'lto-streamer.h'. 44502 44503 These sections are emitted from 'lto-streamer-out.c' and mapped in all 44504at once from 'lto/lto.c':'lto_file_read'. The individual functions 44505dealing with the reading/writing of each section are described below. 44506 44507 * Command line options ('.gnu.lto_.opts') 44508 44509 This section contains the command line options used to generate the 44510 object files. This is used at link time to determine the 44511 optimization level and other settings when they are not explicitly 44512 specified at the linker command line. 44513 44514 Currently, GCC does not support combining LTO object files compiled 44515 with different set of the command line options into a single 44516 binary. At link time, the options given on the command line and 44517 the options saved on all the files in a link-time set are applied 44518 globally. No attempt is made at validating the combination of 44519 flags (other than the usual validation done by option processing). 44520 This is implemented in 'lto/lto.c':'lto_read_all_file_options'. 44521 44522 * Symbol table ('.gnu.lto_.symtab') 44523 44524 This table replaces the ELF symbol table for functions and 44525 variables represented in the LTO IL. Symbols used and exported by 44526 the optimized assembly code of "fat" objects might not match the 44527 ones used and exported by the intermediate code. This table is 44528 necessary because the intermediate code is less optimized and thus 44529 requires a separate symbol table. 44530 44531 Additionally, the binary code in the "fat" object will lack a call 44532 to a function, since the call was optimized out at compilation time 44533 after the intermediate language was streamed out. In some special 44534 cases, the same optimization may not happen during link-time 44535 optimization. This would lead to an undefined symbol if only one 44536 symbol table was used. 44537 44538 The symbol table is emitted in 44539 'lto-streamer-out.c':'produce_symtab'. 44540 44541 * Global declarations and types ('.gnu.lto_.decls') 44542 44543 This section contains an intermediate language dump of all 44544 declarations and types required to represent the callgraph, static 44545 variables and top-level debug info. 44546 44547 The contents of this section are emitted in 44548 'lto-streamer-out.c':'produce_asm_for_decls'. Types and symbols 44549 are emitted in a topological order that preserves the sharing of 44550 pointers when the file is read back in 44551 ('lto.c':'read_cgraph_and_symbols'). 44552 44553 * The callgraph ('.gnu.lto_.cgraph') 44554 44555 This section contains the basic data structure used by the GCC 44556 inter-procedural optimization infrastructure. This section stores 44557 an annotated multi-graph which represents the functions and call 44558 sites as well as the variables, aliases and top-level 'asm' 44559 statements. 44560 44561 This section is emitted in 'lto-streamer-out.c':'output_cgraph' and 44562 read in 'lto-cgraph.c':'input_cgraph'. 44563 44564 * IPA references ('.gnu.lto_.refs') 44565 44566 This section contains references between function and static 44567 variables. It is emitted by 'lto-cgraph.c':'output_refs' and read 44568 by 'lto-cgraph.c':'input_refs'. 44569 44570 * Function bodies ('.gnu.lto_.function_body.<name>') 44571 44572 This section contains function bodies in the intermediate language 44573 representation. Every function body is in a separate section to 44574 allow copying of the section independently to different object 44575 files or reading the function on demand. 44576 44577 Functions are emitted in 'lto-streamer-out.c':'output_function' and 44578 read in 'lto-streamer-in.c':'input_function'. 44579 44580 * Static variable initializers ('.gnu.lto_.vars') 44581 44582 This section contains all the symbols in the global variable pool. 44583 It is emitted by 'lto-cgraph.c':'output_varpool' and read in 44584 'lto-cgraph.c':'input_cgraph'. 44585 44586 * Summaries and optimization summaries used by IPA passes 44587 ('.gnu.lto_.<xxx>', where '<xxx>' is one of 'jmpfuncs', 'pureconst' 44588 or 'reference') 44589 44590 These sections are used by IPA passes that need to emit summary 44591 information during LTO generation to be read and aggregated at link 44592 time. Each pass is responsible for implementing two pass manager 44593 hooks: one for writing the summary and another for reading it in. 44594 The format of these sections is entirely up to each individual 44595 pass. The only requirement is that the writer and reader hooks 44596 agree on the format. 44597 44598 44599File: gccint.info, Node: IPA, Next: WHOPR, Prev: LTO object file layout, Up: LTO 44600 4460125.3 Using summary information in IPA passes 44602============================================ 44603 44604Programs are represented internally as a _callgraph_ (a multi-graph 44605where nodes are functions and edges are call sites) and a _varpool_ (a 44606list of static and external variables in the program). 44607 44608 The inter-procedural optimization is organized as a sequence of 44609individual passes, which operate on the callgraph and the varpool. To 44610make the implementation of WHOPR possible, every inter-procedural 44611optimization pass is split into several stages that are executed at 44612different times during WHOPR compilation: 44613 44614 * LGEN time 44615 1. _Generate summary_ ('generate_summary' in 'struct 44616 ipa_opt_pass_d'). This stage analyzes every function body and 44617 variable initializer is examined and stores relevant 44618 information into a pass-specific data structure. 44619 44620 2. _Write summary_ ('write_summary' in 'struct ipa_opt_pass_d'). 44621 This stage writes all the pass-specific information generated 44622 by 'generate_summary'. Summaries go into their own 44623 'LTO_section_*' sections that have to be declared in 44624 'lto-streamer.h':'enum lto_section_type'. A new section is 44625 created by calling 'create_output_block' and data can be 44626 written using the 'lto_output_*' routines. 44627 44628 * WPA time 44629 1. _Read summary_ ('read_summary' in 'struct ipa_opt_pass_d'). 44630 This stage reads all the pass-specific information in exactly 44631 the same order that it was written by 'write_summary'. 44632 44633 2. _Execute_ ('execute' in 'struct opt_pass'). This performs 44634 inter-procedural propagation. This must be done without 44635 actual access to the individual function bodies or variable 44636 initializers. Typically, this results in a transitive closure 44637 operation over the summary information of all the nodes in the 44638 callgraph. 44639 44640 3. _Write optimization summary_ ('write_optimization_summary' in 44641 'struct ipa_opt_pass_d'). This writes the result of the 44642 inter-procedural propagation into the object file. This can 44643 use the same data structures and helper routines used in 44644 'write_summary'. 44645 44646 * LTRANS time 44647 1. _Read optimization summary_ ('read_optimization_summary' in 44648 'struct ipa_opt_pass_d'). The counterpart to 44649 'write_optimization_summary'. This reads the interprocedural 44650 optimization decisions in exactly the same format emitted by 44651 'write_optimization_summary'. 44652 44653 2. _Transform_ ('function_transform' and 'variable_transform' in 44654 'struct ipa_opt_pass_d'). The actual function bodies and 44655 variable initializers are updated based on the information 44656 passed down from the _Execute_ stage. 44657 44658 The implementation of the inter-procedural passes are shared between 44659LTO, WHOPR and classic non-LTO compilation. 44660 44661 * During the traditional file-by-file mode every pass executes its 44662 own _Generate summary_, _Execute_, and _Transform_ stages within 44663 the single execution context of the compiler. 44664 44665 * In LTO compilation mode, every pass uses _Generate summary_ and 44666 _Write summary_ stages at compilation time, while the _Read 44667 summary_, _Execute_, and _Transform_ stages are executed at link 44668 time. 44669 44670 * In WHOPR mode all stages are used. 44671 44672 To simplify development, the GCC pass manager differentiates between 44673normal inter-procedural passes (*note Regular IPA passes::), small 44674inter-procedural passes (*note Small IPA passes::) and late 44675inter-procedural passes (*note Late IPA passes::). A small or late IPA 44676pass ('SIMPLE_IPA_PASS') does everything at once and thus cannot be 44677executed during WPA in WHOPR mode. It defines only the _Execute_ stage 44678and during this stage it accesses and modifies the function bodies. 44679Such passes are useful for optimization at LGEN or LTRANS time and are 44680used, for example, to implement early optimization before writing object 44681files. The simple inter-procedural passes can also be used for easier 44682prototyping and development of a new inter-procedural pass. 44683 4468425.3.1 Virtual clones 44685--------------------- 44686 44687One of the main challenges of introducing the WHOPR compilation mode was 44688addressing the interactions between optimization passes. In LTO 44689compilation mode, the passes are executed in a sequence, each of which 44690consists of analysis (or _Generate summary_), propagation (or _Execute_) 44691and _Transform_ stages. Once the work of one pass is finished, the next 44692pass sees the updated program representation and can execute. This 44693makes the individual passes dependent on each other. 44694 44695 In WHOPR mode all passes first execute their _Generate summary_ stage. 44696Then summary writing marks the end of the LGEN stage. At WPA time, the 44697summaries are read back into memory and all passes run the _Execute_ 44698stage. Optimization summaries are streamed and sent to LTRANS, where 44699all the passes execute the _Transform_ stage. 44700 44701 Most optimization passes split naturally into analysis, propagation and 44702transformation stages. But some do not. The main problem arises when 44703one pass performs changes and the following pass gets confused by seeing 44704different callgraphs between the _Transform_ stage and the _Generate 44705summary_ or _Execute_ stage. This means that the passes are required to 44706communicate their decisions with each other. 44707 44708 To facilitate this communication, the GCC callgraph infrastructure 44709implements _virtual clones_, a method of representing the changes 44710performed by the optimization passes in the callgraph without needing to 44711update function bodies. 44712 44713 A _virtual clone_ in the callgraph is a function that has no associated 44714body, just a description of how to create its body based on a different 44715function (which itself may be a virtual clone). 44716 44717 The description of function modifications includes adjustments to the 44718function's signature (which allows, for example, removing or adding 44719function arguments), substitutions to perform on the function body, and, 44720for inlined functions, a pointer to the function that it will be inlined 44721into. 44722 44723 It is also possible to redirect any edge of the callgraph from a 44724function to its virtual clone. This implies updating of the call site 44725to adjust for the new function signature. 44726 44727 Most of the transformations performed by inter-procedural optimizations 44728can be represented via virtual clones. For instance, a constant 44729propagation pass can produce a virtual clone of the function which 44730replaces one of its arguments by a constant. The inliner can represent 44731its decisions by producing a clone of a function whose body will be 44732later integrated into a given function. 44733 44734 Using _virtual clones_, the program can be easily updated during the 44735_Execute_ stage, solving most of pass interactions problems that would 44736otherwise occur during _Transform_. 44737 44738 Virtual clones are later materialized in the LTRANS stage and turned 44739into real functions. Passes executed after the virtual clone were 44740introduced also perform their _Transform_ stage on new functions, so for 44741a pass there is no significant difference between operating on a real 44742function or a virtual clone introduced before its _Execute_ stage. 44743 44744 Optimization passes then work on virtual clones introduced before their 44745_Execute_ stage as if they were real functions. The only difference is 44746that clones are not visible during the _Generate Summary_ stage. 44747 44748 To keep function summaries updated, the callgraph interface allows an 44749optimizer to register a callback that is called every time a new clone 44750is introduced as well as when the actual function or variable is 44751generated or when a function or variable is removed. These hooks are 44752registered in the _Generate summary_ stage and allow the pass to keep 44753its information intact until the _Execute_ stage. The same hooks can 44754also be registered during the _Execute_ stage to keep the optimization 44755summaries updated for the _Transform_ stage. 44756 4475725.3.2 IPA references 44758--------------------- 44759 44760GCC represents IPA references in the callgraph. For a function or 44761variable 'A', the _IPA reference_ is a list of all locations where the 44762address of 'A' is taken and, when 'A' is a variable, a list of all 44763direct stores and reads to/from 'A'. References represent an oriented 44764multi-graph on the union of nodes of the callgraph and the varpool. See 44765'ipa-reference.c':'ipa_reference_write_optimization_summary' and 44766'ipa-reference.c':'ipa_reference_read_optimization_summary' for details. 44767 4476825.3.3 Jump functions 44769--------------------- 44770 44771Suppose that an optimization pass sees a function 'A' and it knows the 44772values of (some of) its arguments. The _jump function_ describes the 44773value of a parameter of a given function call in function 'A' based on 44774this knowledge. 44775 44776 Jump functions are used by several optimizations, such as the 44777inter-procedural constant propagation pass and the devirtualization 44778pass. The inliner also uses jump functions to perform inlining of 44779callbacks. 44780 44781 44782File: gccint.info, Node: WHOPR, Next: Internal flags, Prev: IPA, Up: LTO 44783 4478425.4 Whole program assumptions, linker plugin and symbol visibilities 44785===================================================================== 44786 44787Link-time optimization gives relatively minor benefits when used alone. 44788The problem is that propagation of inter-procedural information does not 44789work well across functions and variables that are called or referenced 44790by other compilation units (such as from a dynamically linked library). 44791We say that such functions and variables are _externally visible_. 44792 44793 To make the situation even more difficult, many applications organize 44794themselves as a set of shared libraries, and the default ELF visibility 44795rules allow one to overwrite any externally visible symbol with a 44796different symbol at runtime. This basically disables any optimizations 44797across such functions and variables, because the compiler cannot be sure 44798that the function body it is seeing is the same function body that will 44799be used at runtime. Any function or variable not declared 'static' in 44800the sources degrades the quality of inter-procedural optimization. 44801 44802 To avoid this problem the compiler must assume that it sees the whole 44803program when doing link-time optimization. Strictly speaking, the whole 44804program is rarely visible even at link-time. Standard system libraries 44805are usually linked dynamically or not provided with the link-time 44806information. In GCC, the whole program option ('-fwhole-program') 44807asserts that every function and variable defined in the current 44808compilation unit is static, except for function 'main' (note: at link 44809time, the current unit is the union of all objects compiled with LTO). 44810Since some functions and variables need to be referenced externally, for 44811example by another DSO or from an assembler file, GCC also provides the 44812function and variable attribute 'externally_visible' which can be used 44813to disable the effect of '-fwhole-program' on a specific symbol. 44814 44815 The whole program mode assumptions are slightly more complex in C++, 44816where inline functions in headers are put into _COMDAT_ sections. 44817COMDAT function and variables can be defined by multiple object files 44818and their bodies are unified at link-time and dynamic link-time. COMDAT 44819functions are changed to local only when their address is not taken and 44820thus un-sharing them with a library is not harmful. COMDAT variables 44821always remain externally visible, however for readonly variables it is 44822assumed that their initializers cannot be overwritten by a different 44823value. 44824 44825 GCC provides the function and variable attribute 'visibility' that can 44826be used to specify the visibility of externally visible symbols (or 44827alternatively an '-fdefault-visibility' command line option). ELF 44828defines the 'default', 'protected', 'hidden' and 'internal' 44829visibilities. 44830 44831 The most commonly used is visibility is 'hidden'. It specifies that 44832the symbol cannot be referenced from outside of the current shared 44833library. Unfortunately, this information cannot be used directly by the 44834link-time optimization in the compiler since the whole shared library 44835also might contain non-LTO objects and those are not visible to the 44836compiler. 44837 44838 GCC solves this problem using linker plugins. A _linker plugin_ is an 44839interface to the linker that allows an external program to claim the 44840ownership of a given object file. The linker then performs the linking 44841procedure by querying the plugin about the symbol table of the claimed 44842objects and once the linking decisions are complete, the plugin is 44843allowed to provide the final object file before the actual linking is 44844made. The linker plugin obtains the symbol resolution information which 44845specifies which symbols provided by the claimed objects are bound from 44846the rest of a binary being linked. 44847 44848 GCC is designed to be independent of the rest of the toolchain and aims 44849to support linkers without plugin support. For this reason it does not 44850use the linker plugin by default. Instead, the object files are 44851examined by 'collect2' before being passed to the linker and objects 44852found to have LTO sections are passed to 'lto1' first. This mode does 44853not work for library archives. The decision on what object files from 44854the archive are needed depends on the actual linking and thus GCC would 44855have to implement the linker itself. The resolution information is 44856missing too and thus GCC needs to make an educated guess based on 44857'-fwhole-program'. Without the linker plugin GCC also assumes that 44858symbols are declared 'hidden' and not referred by non-LTO code by 44859default. 44860 44861 44862File: gccint.info, Node: Internal flags, Prev: WHOPR, Up: LTO 44863 4486425.5 Internal flags controlling 'lto1' 44865====================================== 44866 44867The following flags are passed into 'lto1' and are not meant to be used 44868directly from the command line. 44869 44870 * -fwpa This option runs the serial part of the link-time optimizer 44871 performing the inter-procedural propagation (WPA mode). The 44872 compiler reads in summary information from all inputs and performs 44873 an analysis based on summary information only. It generates object 44874 files for subsequent runs of the link-time optimizer where 44875 individual object files are optimized using both summary 44876 information from the WPA mode and the actual function bodies. It 44877 then drives the LTRANS phase. 44878 44879 * -fltrans This option runs the link-time optimizer in the 44880 local-transformation (LTRANS) mode, which reads in output from a 44881 previous run of the LTO in WPA mode. In the LTRANS mode, LTO 44882 optimizes an object and produces the final assembly. 44883 44884 * -fltrans-output-list=FILE This option specifies a file to which the 44885 names of LTRANS output files are written. This option is only 44886 meaningful in conjunction with '-fwpa'. 44887 44888 * -fresolution=FILE This option specifies the linker resolution file. 44889 This option is only meaningful in conjunction with '-fwpa' and as 44890 option to pass through to the LTO linker plugin. 44891 44892 44893File: gccint.info, Node: Match and Simplify, Next: Static Analyzer, Prev: LTO, Up: Top 44894 4489526 Match and Simplify 44896********************* 44897 44898The GIMPLE and GENERIC pattern matching project match-and-simplify tries 44899to address several issues. 44900 44901 1. unify expression simplifications currently spread and duplicated 44902 over separate files like fold-const.c, gimple-fold.c and builtins.c 44903 2. allow for a cheap way to implement building and simplifying 44904 non-trivial GIMPLE expressions, avoiding the need to go through 44905 building and simplifying GENERIC via fold_buildN and then 44906 gimplifying via force_gimple_operand 44907 44908 To address these the project introduces a simple domain specific 44909language to write expression simplifications from which code targeting 44910GIMPLE and GENERIC is auto-generated. The GENERIC variant follows the 44911fold_buildN API while for the GIMPLE variant and to address 2) new APIs 44912are introduced. 44913 44914* Menu: 44915 44916* GIMPLE API:: 44917* The Language:: 44918 44919 44920File: gccint.info, Node: GIMPLE API, Next: The Language, Up: Match and Simplify 44921 4492226.1 GIMPLE API 44923=============== 44924 44925 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 44926 gimple_seq *, tree (*)(tree)) 44927 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 44928 tree, gimple_seq *, tree (*)(tree)) 44929 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 44930 tree, tree, gimple_seq *, tree (*)(tree)) 44931 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 44932 tree, gimple_seq *, tree (*)(tree)) 44933 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 44934 tree, tree, gimple_seq *, tree (*)(tree)) 44935 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 44936 tree, tree, tree, gimple_seq *, tree (*)(tree)) 44937 The main GIMPLE API entry to the expression simplifications 44938 mimicing that of the GENERIC fold_{unary,binary,ternary} functions. 44939 44940 thus providing n-ary overloads for operation or function. The 44941additional arguments are a gimple_seq where built statements are 44942inserted on (if 'NULL' then simplifications requiring new statements are 44943not performed) and a valueization hook that can be used to tie 44944simplifications to a SSA lattice. 44945 44946 In addition to those APIs 'fold_stmt' is overloaded with a valueization 44947hook: 44948 44949 -- bool: fold_stmt (gimple_stmt_iterator *, tree (*)(tree)); 44950 44951 Ontop of these a 'fold_buildN'-like API for GIMPLE is introduced: 44952 44953 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44954 tree_code, tree, tree, tree (*valueize) (tree) = NULL); 44955 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44956 tree_code, tree, tree, tree, tree (*valueize) (tree) = NULL); 44957 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44958 tree_code, tree, tree, tree, tree, tree (*valueize) (tree) = 44959 NULL); 44960 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44961 built_in_function, tree, tree, tree (*valueize) (tree) = 44962 NULL); 44963 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44964 built_in_function, tree, tree, tree, tree (*valueize) (tree) = 44965 NULL); 44966 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44967 built_in_function, tree, tree, tree, tree, tree (*valueize) 44968 (tree) = NULL); 44969 -- GIMPLE function: tree gimple_convert (gimple_seq *, location_t, 44970 tree, tree); 44971 44972 which is supposed to replace 'force_gimple_operand (fold_buildN (...), 44973...)' and calls to 'fold_convert'. Overloads without the 'location_t' 44974argument exist. Built statements are inserted on the provided sequence 44975and simplification is performed using the optional valueization hook. 44976 44977 44978File: gccint.info, Node: The Language, Prev: GIMPLE API, Up: Match and Simplify 44979 4498026.2 The Language 44981================= 44982 44983The language to write expression simplifications in resembles other 44984domain-specific languages GCC uses. Thus it is lispy. Lets start with 44985an example from the match.pd file: 44986 44987 (simplify 44988 (bit_and @0 integer_all_onesp) 44989 @0) 44990 44991 This example contains all required parts of an expression 44992simplification. A simplification is wrapped inside a '(simplify ...)' 44993expression. That contains at least two operands - an expression that is 44994matched with the GIMPLE or GENERIC IL and a replacement expression that 44995is returned if the match was successful. 44996 44997 Expressions have an operator ID, 'bit_and' in this case. Expressions 44998can be lower-case tree codes with '_expr' stripped off or builtin 44999function code names in all-caps, like 'BUILT_IN_SQRT'. 45000 45001 '@n' denotes a so-called capture. It captures the operand and lets you 45002refer to it in other places of the match-and-simplify. In the above 45003example it is refered to in the replacement expression. Captures are 45004'@' followed by a number or an identifier. 45005 45006 (simplify 45007 (bit_xor @0 @0) 45008 { build_zero_cst (type); }) 45009 45010 In this example '@0' is mentioned twice which constrains the matched 45011expression to have two equal operands. Usually matches are constraint 45012to equal types. If operands may be constants and conversions are 45013involved matching by value might be preferred in which case use '@@0' to 45014denote a by value match and the specific operand you want to refer to in 45015the result part. This example also introduces operands written in C 45016code. These can be used in the expression replacements and are supposed 45017to evaluate to a tree node which has to be a valid GIMPLE operand (so 45018you cannot generate expressions in C code). 45019 45020 (simplify 45021 (trunc_mod integer_zerop@0 @1) 45022 (if (!integer_zerop (@1)) 45023 @0)) 45024 45025 Here '@0' captures the first operand of the trunc_mod expression which 45026is also predicated with 'integer_zerop'. Expression operands may be 45027either expressions, predicates or captures. Captures can be 45028unconstrained or capture expresions or predicates. 45029 45030 This example introduces an optional operand of simplify, the 45031if-expression. This condition is evaluated after the expression matched 45032in the IL and is required to evaluate to true to enable the replacement 45033expression in the second operand position. The expression operand of 45034the 'if' is a standard C expression which may contain references to 45035captures. The 'if' has an optional third operand which may contain the 45036replacement expression that is enabled when the condition evaluates to 45037false. 45038 45039 A 'if' expression can be used to specify a common condition for 45040multiple simplify patterns, avoiding the need to repeat that multiple 45041times: 45042 45043 (if (!TYPE_SATURATING (type) 45044 && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) 45045 (simplify 45046 (minus (plus @0 @1) @0) 45047 @1) 45048 (simplify 45049 (minus (minus @0 @1) @0) 45050 (negate @1))) 45051 45052 Note that 'if's in outer position do not have the optional else clause 45053but instead have multiple then clauses. 45054 45055 Ifs can be nested. 45056 45057 There exists a 'switch' expression which can be used to chain 45058conditions avoiding nesting 'if's too much: 45059 45060 (simplify 45061 (simple_comparison @0 REAL_CST@1) 45062 (switch 45063 /* a CMP (-0) -> a CMP 0 */ 45064 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 45065 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); })) 45066 /* x != NaN is always true, other ops are always false. */ 45067 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 45068 && ! HONOR_SNANS (@1)) 45069 { constant_boolean_node (cmp == NE_EXPR, type); }))) 45070 45071 Is equal to 45072 45073 (simplify 45074 (simple_comparison @0 REAL_CST@1) 45075 (switch 45076 /* a CMP (-0) -> a CMP 0 */ 45077 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 45078 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); }) 45079 /* x != NaN is always true, other ops are always false. */ 45080 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 45081 && ! HONOR_SNANS (@1)) 45082 { constant_boolean_node (cmp == NE_EXPR, type); })))) 45083 45084 which has the second 'if' in the else operand of the first. The 45085'switch' expression takes 'if' expressions as operands (which may not 45086have else clauses) and as a last operand a replacement expression which 45087should be enabled by default if no other condition evaluated to true. 45088 45089 Captures can also be used for capturing results of sub-expressions. 45090 45091 #if GIMPLE 45092 (simplify 45093 (pointer_plus (addr@2 @0) INTEGER_CST_P@1) 45094 (if (is_gimple_min_invariant (@2))) 45095 { 45096 poly_int64 off; 45097 tree base = get_addr_base_and_unit_offset (@0, &off); 45098 off += tree_to_uhwi (@1); 45099 /* Now with that we should be able to simply write 45100 (addr (mem_ref (addr @base) (plus @off @1))) */ 45101 build1 (ADDR_EXPR, type, 45102 build2 (MEM_REF, TREE_TYPE (TREE_TYPE (@2)), 45103 build_fold_addr_expr (base), 45104 build_int_cst (ptr_type_node, off))); 45105 }) 45106 #endif 45107 45108 In the above example, '@2' captures the result of the expression '(addr 45109@0)'. For outermost expression only its type can be captured, and the 45110keyword 'type' is reserved for this purpose. The above example also 45111gives a way to conditionalize patterns to only apply to 'GIMPLE' or 45112'GENERIC' by means of using the pre-defined preprocessor macros 'GIMPLE' 45113and 'GENERIC' and using preprocessor directives. 45114 45115 (simplify 45116 (bit_and:c integral_op_p@0 (bit_ior:c (bit_not @0) @1)) 45117 (bit_and @1 @0)) 45118 45119 Here we introduce flags on match expressions. The flag used above, 45120'c', denotes that the expression should be also matched commutated. 45121Thus the above match expression is really the following four match 45122expressions: 45123 45124 (bit_and integral_op_p@0 (bit_ior (bit_not @0) @1)) 45125 (bit_and (bit_ior (bit_not @0) @1) integral_op_p@0) 45126 (bit_and integral_op_p@0 (bit_ior @1 (bit_not @0))) 45127 (bit_and (bit_ior @1 (bit_not @0)) integral_op_p@0) 45128 45129 Usual canonicalizations you know from GENERIC expressions are applied 45130before matching, so for example constant operands always come second in 45131commutative expressions. 45132 45133 The second supported flag is 's' which tells the code generator to fail 45134the pattern if the expression marked with 's' does have more than one 45135use and the simplification results in an expression with more than one 45136operator. For example in 45137 45138 (simplify 45139 (pointer_plus (pointer_plus:s @0 @1) @3) 45140 (pointer_plus @0 (plus @1 @3))) 45141 45142 this avoids the association if '(pointer_plus @0 @1)' is used outside 45143of the matched expression and thus it would stay live and not trivially 45144removed by dead code elimination. Now consider '((x + 3) + -3)' with 45145the temporary holding '(x + 3)' used elsewhere. This simplifies down to 45146'x' which is desirable and thus flagging with 's' does not prevent the 45147transform. Now consider '((x + 3) + 1)' which simplifies to '(x + 4)'. 45148Despite being flagged with 's' the simplification will be performed. 45149The simplification of '((x + a) + 1)' to '(x + (a + 1))' will not 45150performed in this case though. 45151 45152 More features exist to avoid too much repetition. 45153 45154 (for op (plus pointer_plus minus bit_ior bit_xor) 45155 (simplify 45156 (op @0 integer_zerop) 45157 @0)) 45158 45159 A 'for' expression can be used to repeat a pattern for each operator 45160specified, substituting 'op'. 'for' can be nested and a 'for' can have 45161multiple operators to iterate. 45162 45163 (for opa (plus minus) 45164 opb (minus plus) 45165 (for opc (plus minus) 45166 (simplify... 45167 45168 In this example the pattern will be repeated four times with 'opa, opb, 45169opc' being 'plus, minus, plus'; 'plus, minus, minus'; 'minus, plus, 45170plus'; 'minus, plus, minus'. 45171 45172 To avoid repeating operator lists in 'for' you can name them via 45173 45174 (define_operator_list pmm plus minus mult) 45175 45176 and use them in 'for' operator lists where they get expanded. 45177 45178 (for opa (pmm trunc_div) 45179 (simplify... 45180 45181 So this example iterates over 'plus', 'minus', 'mult' and 'trunc_div'. 45182 45183 Using operator lists can also remove the need to explicitely write a 45184'for'. All operator list uses that appear in a 'simplify' or 'match' 45185pattern in operator positions will implicitely be added to a new 'for'. 45186For example 45187 45188 (define_operator_list SQRT BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 45189 (define_operator_list POW BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 45190 (simplify 45191 (SQRT (POW @0 @1)) 45192 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); }))) 45193 45194 is the same as 45195 45196 (for SQRT (BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 45197 POW (BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 45198 (simplify 45199 (SQRT (POW @0 @1)) 45200 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); })))) 45201 45202 'for's and operator lists can include the special identifier 'null' 45203that matches nothing and can never be generated. This can be used to 45204pad an operator list so that it has a standard form, even if there isn't 45205a suitable operator for every form. 45206 45207 Another building block are 'with' expressions in the result expression 45208which nest the generated code in a new C block followed by its argument: 45209 45210 (simplify 45211 (convert (mult @0 @1)) 45212 (with { tree utype = unsigned_type_for (type); } 45213 (convert (mult (convert:utype @0) (convert:utype @1))))) 45214 45215 This allows code nested in the 'with' to refer to the declared 45216variables. In the above case we use the feature to specify the type of 45217a generated expression with the ':type' syntax where 'type' needs to be 45218an identifier that refers to the desired type. Usually the types of the 45219generated result expressions are determined from the context, but 45220sometimes like in the above case it is required that you specify them 45221explicitely. 45222 45223 As intermediate conversions are often optional there is a way to avoid 45224the need to repeat patterns both with and without such conversions. 45225Namely you can mark a conversion as being optional with a '?': 45226 45227 (simplify 45228 (eq (convert@0 @1) (convert? @2)) 45229 (eq @1 (convert @2))) 45230 45231 which will match both '(eq (convert @1) (convert @2))' and '(eq 45232(convert @1) @2)'. The optional converts are supposed to be all either 45233present or not, thus '(eq (convert? @1) (convert? @2))' will result in 45234two patterns only. If you want to match all four combinations you have 45235access to two additional conditional converts as in '(eq (convert1? @1) 45236(convert2? @2))'. 45237 45238 The support for '?' marking extends to all unary operations including 45239predicates you declare yourself with 'match'. 45240 45241 Predicates available from the GCC middle-end need to be made available 45242explicitely via 'define_predicates': 45243 45244 (define_predicates 45245 integer_onep integer_zerop integer_all_onesp) 45246 45247 You can also define predicates using the pattern matching language and 45248the 'match' form: 45249 45250 (match negate_expr_p 45251 INTEGER_CST 45252 (if (TYPE_OVERFLOW_WRAPS (type) 45253 || may_negate_without_overflow_p (t)))) 45254 (match negate_expr_p 45255 (negate @0)) 45256 45257 This shows that for 'match' expressions there is 't' available which 45258captures the outermost expression (something not possible in the 45259'simplify' context). As you can see 'match' has an identifier as first 45260operand which is how you refer to the predicate in patterns. Multiple 45261'match' for the same identifier add additional cases where the predicate 45262matches. 45263 45264 Predicates can also match an expression in which case you need to 45265provide a template specifying the identifier and where to get its 45266operands from: 45267 45268 (match (logical_inverted_value @0) 45269 (eq @0 integer_zerop)) 45270 (match (logical_inverted_value @0) 45271 (bit_not truth_valued_p@0)) 45272 45273 You can use the above predicate like 45274 45275 (simplify 45276 (bit_and @0 (logical_inverted_value @0)) 45277 { build_zero_cst (type); }) 45278 45279 Which will match a bitwise and of an operand with its logical inverted 45280value. 45281 45282 45283File: gccint.info, Node: Static Analyzer, Next: User Experience Guidelines, Prev: Match and Simplify, Up: Top 45284 4528527 Static Analyzer 45286****************** 45287 45288* Menu: 45289 45290* Analyzer Internals:: Analyzer Internals 45291* Debugging the Analyzer:: Useful debugging tips 45292 45293 45294File: gccint.info, Node: Analyzer Internals, Next: Debugging the Analyzer, Up: Static Analyzer 45295 4529627.1 Analyzer Internals 45297======================= 45298 4529927.1.1 Overview 45300--------------- 45301 45302The analyzer implementation works on the gimple-SSA representation. (I 45303chose this in the hopes of making it easy to work with LTO to do 45304whole-program analysis). 45305 45306 The implementation is read-only: it doesn't attempt to change anything, 45307just emit warnings. 45308 45309 The gimple representation can be seen using '-fdump-ipa-analyzer'. 45310 45311 First, we build a 'supergraph' which combines the callgraph and all of 45312the CFGs into a single directed graph, with both interprocedural and 45313intraprocedural edges. The nodes and edges in the supergraph are called 45314"supernodes" and "superedges", and often referred to in code as 'snodes' 45315and 'sedges'. Basic blocks in the CFGs are split at interprocedural 45316calls, so there can be more than one supernode per basic block. Most 45317statements will be in just one supernode, but a call statement can 45318appear in two supernodes: at the end of one for the call, and again at 45319the start of another for the return. 45320 45321 The supergraph can be seen using '-fdump-analyzer-supergraph'. 45322 45323 We then build an 'analysis_plan' which walks the callgraph to determine 45324which calls might be suitable for being summarized (rather than fully 45325explored) and thus in what order to explore the functions. 45326 45327 Next is the heart of the analyzer: we use a worklist to explore state 45328within the supergraph, building an "exploded graph". Nodes in the 45329exploded graph correspond to <point, state> pairs, as in "Precise 45330Interprocedural Dataflow Analysis via Graph Reachability" (Thomas Reps, 45331Susan Horwitz and Mooly Sagiv). 45332 45333 We reuse nodes for <point, state> pairs we've already seen, and avoid 45334tracking state too closely, so that (hopefully) we rapidly converge on a 45335final exploded graph, and terminate the analysis. We also bail out if 45336the number of exploded <end-of-basic-block, state> nodes gets larger 45337than a particular multiple of the total number of basic blocks (to 45338ensure termination in the face of pathological state-explosion cases, or 45339bugs). We also stop exploring a point once we hit a limit of states for 45340that point. 45341 45342 We can identify problems directly when processing a <point, state> 45343instance. For example, if we're finding the successors of 45344 45345 <point: before-stmt: "free (ptr);", 45346 state: {"ptr": freed}> 45347 45348 then we can detect a double-free of "ptr". We can then emit a path to 45349reach the problem by finding the simplest route through the graph. 45350 45351 Program points in the analysis are much more fine-grained than in the 45352CFG and supergraph, with points (and thus potentially exploded nodes) 45353for various events, including before individual statements. By default 45354the exploded graph merges multiple consecutive statements in a supernode 45355into one exploded edge to minimize the size of the exploded graph. This 45356can be suppressed via '-fanalyzer-fine-grained'. The fine-grained 45357approach seems to make things simpler and more debuggable that other 45358approaches I tried, in that each point is responsible for one thing. 45359 45360 Program points in the analysis also have a "call string" identifying 45361the stack of callsites below them, so that paths in the exploded graph 45362correspond to interprocedurally valid paths: we always return to the 45363correct call site, propagating state information accordingly. We avoid 45364infinite recursion by stopping the analysis if a callsite appears more 45365than 'analyzer-max-recursion-depth' in a callstring (defaulting to 2). 45366 4536727.1.2 Graphs 45368------------- 45369 45370Nodes and edges in the exploded graph are called "exploded nodes" and 45371"exploded edges" and often referred to in the code as 'enodes' and 45372'eedges' (especially when distinguishing them from the 'snodes' and 45373'sedges' in the supergraph). 45374 45375 Each graph numbers its nodes, giving unique identifiers - supernodes 45376are referred to throughout dumps in the form 'SN': INDEX' and exploded 45377nodes in the form 'EN: INDEX' (e.g. 'SN: 2' and 'EN:29'). 45378 45379 The supergraph can be seen using '-fdump-analyzer-supergraph-graph'. 45380 45381 The exploded graph can be seen using '-fdump-analyzer-exploded-graph' 45382and other dump options. Exploded nodes are color-coded in the .dot 45383output based on state-machine states to make it easier to see state 45384changes at a glance. 45385 4538627.1.3 State Tracking 45387--------------------- 45388 45389There's a tension between: 45390 * precision of analysis in the straight-line case, vs 45391 * exponential blow-up in the face of control flow. 45392 45393 For example, in general, given this CFG: 45394 45395 A 45396 / \ 45397 B C 45398 \ / 45399 D 45400 / \ 45401 E F 45402 \ / 45403 G 45404 45405 we want to avoid differences in state-tracking in B and C from leading 45406to blow-up. If we don't prevent state blowup, we end up with 45407exponential growth of the exploded graph like this: 45408 45409 45410 1:A 45411 / \ 45412 / \ 45413 / \ 45414 2:B 3:C 45415 | | 45416 4:D 5:D (2 exploded nodes for D) 45417 / \ / \ 45418 6:E 7:F 8:E 9:F 45419 | | | | 45420 10:G 11:G 12:G 13:G (4 exploded nodes for G) 45421 45422 45423 Similar issues arise with loops. 45424 45425 To prevent this, we follow various approaches: 45426 45427 a. state pruning: which tries to discard state that won't be relevant 45428 later on withing the function. This can be disabled via 45429 '-fno-analyzer-state-purge'. 45430 45431 b. state merging. We can try to find the commonality between two 45432 program_state instances to make a third, simpler program_state. We 45433 have two strategies here: 45434 45435 1. the worklist keeps new nodes for the same program_point 45436 together, and tries to merge them before processing, and thus 45437 before they have successors. Hence, in the above, the two 45438 nodes for D (4 and 5) reach the front of the worklist 45439 together, and we create a node for D with the merger of the 45440 incoming states. 45441 45442 2. try merging with the state of existing enodes for the 45443 program_point (which may have already been explored). There 45444 will be duplication, but only one set of duplication; 45445 subsequent duplicates are more likely to hit the cache. In 45446 particular, (hopefully) all merger chains are finite, and so 45447 we guarantee termination. This is intended to help with 45448 loops: we ought to explore the first iteration, and then have 45449 a "subsequent iterations" exploration, which uses a state 45450 merged from that of the first, to be more abstract. 45451 45452 We avoid merging pairs of states that have state-machine 45453 differences, as these are the kinds of differences that are likely 45454 to be most interesting. So, for example, given: 45455 45456 if (condition) 45457 ptr = malloc (size); 45458 else 45459 ptr = local_buf; 45460 45461 .... do things with 'ptr' 45462 45463 if (condition) 45464 free (ptr); 45465 45466 ...etc 45467 45468 then we end up with an exploded graph that looks like this: 45469 45470 45471 if (condition) 45472 / T \ F 45473 --------- ---------- 45474 / \ 45475 ptr = malloc (size) ptr = local_buf 45476 | | 45477 copy of copy of 45478 "do things with 'ptr'" "do things with 'ptr'" 45479 with ptr: heap-allocated with ptr: stack-allocated 45480 | | 45481 if (condition) if (condition) 45482 | known to be T | known to be F 45483 free (ptr); | 45484 \ / 45485 ----------------------------- 45486 | ('ptr' is pruned, so states can be merged) 45487 etc 45488 45489 45490 where some duplication has occurred, but only for the places where 45491 the the different paths are worth exploringly separately. 45492 45493 Merging can be disabled via '-fno-analyzer-state-merge'. 45494 4549527.1.4 Region Model 45496------------------- 45497 45498Part of the state stored at a 'exploded_node' is a 'region_model'. This 45499is an implementation of the region-based ternary model described in "A 45500Memory Model for Static Analysis of C Programs" 45501(http://lcs.ios.ac.cn/~xuzb/canalyze/memmodel.pdf) (Zhongxing Xu, Ted 45502Kremenek, and Jian Zhang). 45503 45504 A 'region_model' encapsulates a representation of the state of memory, 45505with a tree of 'region' instances, along with their associated values. 45506The representation is graph-like because values can be pointers to 45507regions. It also stores a constraint_manager, capturing relationships 45508between the values. 45509 45510 Because each node in the 'exploded_graph' has a 'region_model', and 45511each of the latter is graph-like, the 'exploded_graph' is in some ways a 45512graph of graphs. 45513 45514 Here's an example of printing a 'region_model', showing the ASCII-art 45515used to visualize the region hierarchy (colorized when printing to 45516stderr): 45517 45518 (gdb) call debug (*this) 45519 r0: {kind: 'root', parent: null, sval: null} 45520 |-stack: r1: {kind: 'stack', parent: r0, sval: sv1} 45521 | |: sval: sv1: {poisoned: uninit} 45522 | |-frame for 'test': r2: {kind: 'frame', parent: r1, sval: null, map: {'ptr_3': r3}, function: 'test', depth: 0} 45523 | | `-'ptr_3': r3: {kind: 'map', parent: r2, sval: sv3, type: 'void *', map: {}} 45524 | | |: sval: sv3: {type: 'void *', unknown} 45525 | | |: type: 'void *' 45526 | `-frame for 'calls_malloc': r4: {kind: 'frame', parent: r1, sval: null, map: {'result_3': r7, '_4': r8, '<anonymous>': r5}, function: 'calls_malloc', depth: 1} 45527 | |-'<anonymous>': r5: {kind: 'map', parent: r4, sval: sv4, type: 'void *', map: {}} 45528 | | |: sval: sv4: {type: 'void *', &r6} 45529 | | |: type: 'void *' 45530 | |-'result_3': r7: {kind: 'map', parent: r4, sval: sv4, type: 'void *', map: {}} 45531 | | |: sval: sv4: {type: 'void *', &r6} 45532 | | |: type: 'void *' 45533 | `-'_4': r8: {kind: 'map', parent: r4, sval: sv4, type: 'void *', map: {}} 45534 | |: sval: sv4: {type: 'void *', &r6} 45535 | |: type: 'void *' 45536 `-heap: r9: {kind: 'heap', parent: r0, sval: sv2} 45537 |: sval: sv2: {poisoned: uninit} 45538 `-r6: {kind: 'symbolic', parent: r9, sval: null, map: {}} 45539 svalues: 45540 sv0: {type: 'size_t', '1024'} 45541 sv1: {poisoned: uninit} 45542 sv2: {poisoned: uninit} 45543 sv3: {type: 'void *', unknown} 45544 sv4: {type: 'void *', &r6} 45545 constraint manager: 45546 equiv classes: 45547 ec0: {sv0 == '1024'} 45548 ec1: {sv4} 45549 constraints: 45550 45551 This is the state at the point of returning from 'calls_malloc' back to 45552'test' in the following: 45553 45554 void * 45555 calls_malloc (void) 45556 { 45557 void *result = malloc (1024); 45558 return result; 45559 } 45560 45561 void test (void) 45562 { 45563 void *ptr = calls_malloc (); 45564 /* etc. */ 45565 } 45566 45567 The "root" region ("r0") has a "stack" child ("r1"), with two children: 45568a frame for 'test' ("r2"), and a frame for 'calls_malloc' ("r4"). These 45569frame regions have child regions for storing their local variables. For 45570example, the return region and that of various other regions within the 45571"calls_malloc" frame all have value "sv4", a pointer to a heap-allocated 45572region "r6". Within the parent frame, 'ptr_3' has value "sv3", an 45573unknown 'void *'. 45574 4557527.1.5 Analyzer Paths 45576--------------------- 45577 45578We need to explain to the user what the problem is, and to persuade them 45579that there really is a problem. Hence having a 'diagnostic_path' isn't 45580just an incidental detail of the analyzer; it's required. 45581 45582 Paths ought to be: 45583 * interprocedurally-valid 45584 * feasible 45585 45586 Without state-merging, all paths in the exploded graph are feasible (in 45587terms of constraints being satisified). With state-merging, paths in 45588the exploded graph can be infeasible. 45589 45590 We collate warnings and only emit them for the simplest path e.g. for 45591a bug in a utility function, with lots of routes to calling it, we only 45592emit the simplest path (which could be intraprocedural, if it can be 45593reproduced without a caller). We apply a check that each duplicate 45594warning's shortest path is feasible, rejecting any warnings for which 45595the shortest path is infeasible (which could lead to false negatives). 45596 45597 We use the shortest feasible 'exploded_path' through the 45598'exploded_graph' (a list of 'exploded_edge *') to build a 45599'diagnostic_path' (a list of events for the diagnostic subsystem) - 45600specifically a 'checker_path'. 45601 45602 Having built the 'checker_path', we prune it to try to eliminate events 45603that aren't relevant, to minimize how much the user has to read. 45604 45605 After pruning, we notify each event in the path of its ID and record 45606the IDs of interesting events, allowing for events to refer to other 45607events in their descriptions. The 'pending_diagnostic' class has 45608various vfuncs to support emitting more precise descriptions, so that 45609e.g. 45610 45611 * a deref-of-unchecked-malloc diagnostic might use: 45612 returning possibly-NULL pointer to 'make_obj' from 'allocator' 45613 for a 'return_event' to make it clearer how the unchecked value 45614 moves from callee back to caller 45615 * a double-free diagnostic might use: 45616 second 'free' here; first 'free' was at (3) 45617 and a use-after-free might use 45618 use after 'free' here; memory was freed at (2) 45619 45620 At this point we can emit the diagnostic. 45621 4562227.1.6 Limitations 45623------------------ 45624 45625 * Only for C so far 45626 * The implementation of call summaries is currently very simplistic. 45627 * Lack of function pointer analysis 45628 * The constraint-handling code assumes reflexivity in some places 45629 (that values are equal to themselves), which is not the case for 45630 NaN. As a simple workaround, constraints on floating-point values 45631 are currently ignored. 45632 * The region model code creates lots of little mutable objects at 45633 each 'region_model' (and thus per 'exploded_node') rather than 45634 sharing immutable objects and having the mutable state in the 45635 'program_state' or 'region_model'. The latter approach might be 45636 more efficient, and might avoid dealing with IDs rather than 45637 pointers (which requires us to impose an ordering to get meaningful 45638 equality). 45639 * The region model code doesn't yet support 'memcpy'. At the 45640 gimple-ssa level these have been optimized to statements like this: 45641 _10 = MEM <long unsigned int> [(char * {ref-all})&c] 45642 MEM <long unsigned int> [(char * {ref-all})&d] = _10; 45643 Perhaps they could be supported via a new 'compound_svalue' type. 45644 * There are various other limitations in the region model (grep for 45645 TODO/xfail in the testsuite). 45646 * The constraint_manager's implementation of transitivity is 45647 currently too expensive to enable by default and so must be 45648 manually enabled via '-fanalyzer-transitivity'). 45649 * The checkers are currently hardcoded and don't allow for user 45650 extensibility (e.g. adding allocate/release pairs). 45651 * Although the analyzer's test suite has a proof-of-concept test case 45652 for LTO, LTO support hasn't had extensive testing. There are 45653 various lang-specific things in the analyzer that assume C rather 45654 than LTO. For example, SSA names are printed to the user in "raw" 45655 form, rather than printing the underlying variable name. 45656 45657 Some ideas for other checkers 45658 * File-descriptor-based APIs 45659 * Linux kernel internal APIs 45660 * Signal handling 45661 45662 45663File: gccint.info, Node: Debugging the Analyzer, Prev: Analyzer Internals, Up: Static Analyzer 45664 4566527.2 Debugging the Analyzer 45666=========================== 45667 4566827.2.1 Special Functions for Debugging the Analyzer 45669--------------------------------------------------- 45670 45671The analyzer recognizes various special functions by name, for use in 45672debugging the analyzer. Declarations can be seen in the testsuite in 45673'analyzer-decls.h'. None of these functions are actually implemented. 45674 45675 Add: 45676 __analyzer_break (); 45677 to the source being analyzed to trigger a breakpoint in the analyzer 45678when that source is reached. By putting a series of these in the 45679source, it's much easier to effectively step through the program state 45680as it's analyzed. 45681 45682 __analyzer_dump (); 45683 45684 will dump the copious information about the analyzer's state each time 45685it reaches the call in its traversal of the source. 45686 45687 __analyzer_dump_path (); 45688 45689 will emit a placeholder "note" diagnostic with a path to that call 45690site, if the analyzer finds a feasible path to it. 45691 45692 The builtin '__analyzer_dump_exploded_nodes' will emit a warning after 45693analysis containing information on all of the exploded nodes at that 45694program point: 45695 45696 __analyzer_dump_exploded_nodes (0); 45697 45698 will output the number of "processed" nodes, and the IDs of both 45699"processed" and "merger" nodes, such as: 45700 45701 warning: 2 processed enodes: [EN: 56, EN: 58] merger(s): [EN: 54-55, EN: 57, EN: 59] 45702 45703 With a non-zero argument 45704 45705 __analyzer_dump_exploded_nodes (1); 45706 45707 it will also dump all of the states within the "processed" nodes. 45708 45709 __analyzer_dump_region_model (); 45710 will dump the region_model's state to stderr. 45711 45712 __analyzer_eval (expr); 45713 will emit a warning with text "TRUE", FALSE" or "UNKNOWN" based on the 45714truthfulness of the argument. This is useful for writing DejaGnu tests. 45715 4571627.2.2 Other Debugging Techniques 45717--------------------------------- 45718 45719One approach when tracking down where a particular bogus state is 45720introduced into the 'exploded_graph' is to add custom code to 45721'region_model::validate'. 45722 45723 For example, this custom code (added to 'region_model::validate') 45724breaks with an assertion failure when a variable called 'ptr' acquires a 45725value that's unknown, using 'region_model::get_value_by_name' to locate 45726the variable 45727 45728 /* Find a variable matching "ptr". */ 45729 svalue_id sid = get_value_by_name ("ptr"); 45730 if (!sid.null_p ()) 45731 { 45732 svalue *sval = get_svalue (sid); 45733 gcc_assert (sval->get_kind () != SK_UNKNOWN); 45734 } 45735 45736 making it easier to investigate further in a debugger when this occurs. 45737 45738 45739File: gccint.info, Node: User Experience Guidelines, Next: Funding, Prev: Static Analyzer, Up: Top 45740 4574128 User Experience Guidelines 45742***************************** 45743 45744To borrow a slogan from Elm 45745(https://elm-lang.org/news/compilers-as-assistants), 45746 45747 *Compilers should be assistants, not adversaries.* A compiler 45748 should not just detect bugs, it should then help you understand why 45749 there is a bug. It should not berate you in a robot voice, it 45750 should give you specific hints that help you write better code. 45751 Ultimately, a compiler should make programming faster and more fun! 45752 -- _Evan Czaplicki_ 45753 45754 This chapter provides guidelines on how to implement diagnostics and 45755command-line options in ways that we hope achieve the above ideal. 45756 45757* Menu: 45758 45759* Guidelines for Diagnostics:: How to implement diagnostics. 45760* Guidelines for Options:: Guidelines for command-line options. 45761 45762 45763File: gccint.info, Node: Guidelines for Diagnostics, Next: Guidelines for Options, Up: User Experience Guidelines 45764 4576528.1 Guidelines for Diagnostics 45766=============================== 45767 4576828.1.1 Talk in terms of the user's code 45769--------------------------------------- 45770 45771Diagnostics should be worded in terms of the user's source code, and the 45772source language, rather than GCC's own implementation details. 45773 4577428.1.2 Diagnostics are actionable 45775--------------------------------- 45776 45777A good diagnostic is "actionable": it should assist the user in taking 45778action. 45779 45780 Consider what an end user will want to do when encountering a 45781diagnostic. 45782 45783 Given an error, an end user will think: "How do I fix this?" 45784 45785 Given a warning, an end user will think: 45786 45787 * "Is this a real problem?" 45788 * "Do I care?" 45789 * if they decide it's genuine: "How do I fix this?" 45790 45791 A good diagnostic provides pertinent information to allow the user to 45792easily answer the above questions. 45793 4579428.1.3 The user's attention is important 45795---------------------------------------- 45796 45797A perfect compiler would issue a warning on every aspect of the user's 45798source code that ought to be fixed, and issue no other warnings. 45799Naturally, this ideal is impossible to achieve. 45800 45801 Warnings should have a good "signal-to-noise ratio": we should have few 45802"false positives" (falsely issuing a warning when no warning is 45803warranted) and few "false negatives" (failing to issue a warning when 45804one _is_ justified). 45805 45806 Note that a false positive can mean, in practice, a warning that the 45807user doesn't agree with. Ideally a diagnostic should contain enough 45808information to allow the user to make an informed choice about whether 45809they should care (and how to fix it), but a balance must be drawn 45810against overloading the user with irrelevant data. 45811 4581228.1.4 Precision of Wording 45813--------------------------- 45814 45815Provide the user with details that allow them to identify what the 45816problem is. For example, the vaguely-worded message: 45817 45818 demo.c:1:1: warning: 'noinline' attribute ignored [-Wattributes] 45819 1 | int foo __attribute__((noinline)); 45820 | ^~~ 45821 45822doesn't tell the user why the attribute was ignored, or what kind of 45823entity the compiler thought the attribute was being applied to (the 45824source location for the diagnostic is also poor; *note discussion of 45825'input_location': input_location_example.). A better message would be: 45826 45827 demo.c:1:24: warning: attribute 'noinline' on variable 'foo' was 45828 ignored [-Wattributes] 45829 1 | int foo __attribute__((noinline)); 45830 | ~~~ ~~~~~~~~~~~~~~~^~~~~~~~~ 45831 demo.c:1:24: note: attribute 'noinline' is only applicable to functions 45832 45833which spells out the missing information (and fixes the location 45834information, as discussed below). 45835 45836 The above example uses a note to avoid a combinatorial explosion of 45837possible messages. 45838 4583928.1.5 Try the diagnostic on real-world code 45840-------------------------------------------- 45841 45842It's worth testing a new warning on many instances of real-world code, 45843written by different people, and seeing what it complains about, and 45844what it doesn't complain about. 45845 45846 This may suggest heuristics that silence common false positives. 45847 45848 It may also suggest ways to improve the precision of the message. 45849 4585028.1.6 Make mismatches clear 45851---------------------------- 45852 45853Many diagnostics relate to a mismatch between two different places in 45854the user's source code. Examples include: 45855 * a type mismatch, where the type at a usage site does not match the 45856 type at a declaration 45857 45858 * the argument count at a call site does not match the parameter 45859 count at the declaration 45860 45861 * something is erroneously duplicated (e.g. an error, due to breaking 45862 a uniqueness requirement, or a warning, if it's suggestive of a 45863 bug) 45864 45865 * an "opened" syntactic construct (such as an open-parenthesis) is 45866 not closed 45867 45868 In each case, the diagnostic should indicate *both* pertinent locations 45869(so that the user can easily see the problem and how to fix it). 45870 45871 The standard way to do this is with a note (via 'inform'). For 45872example: 45873 45874 auto_diagnostic_group d; 45875 if (warning_at (loc, OPT_Wduplicated_cond, 45876 "duplicated %<if%> condition")) 45877 inform (EXPR_LOCATION (t), "previously used here"); 45878 45879which leads to: 45880 45881 demo.c: In function 'test': 45882 demo.c:5:17: warning: duplicated 'if' condition [-Wduplicated-cond] 45883 5 | else if (flag > 3) 45884 | ~~~~~^~~ 45885 demo.c:3:12: note: previously used here 45886 3 | if (flag > 3) 45887 | ~~~~~^~~ 45888 45889The 'inform' call should be guarded by the return value from the 45890'warning_at' call so that the note isn't emitted when the warning is 45891suppressed. 45892 45893 For cases involving punctuation where the locations might be near each 45894other, they can be conditionally consolidated via 45895'gcc_rich_location::add_location_if_nearby': 45896 45897 auto_diagnostic_group d; 45898 gcc_rich_location richloc (primary_loc); 45899 bool added secondary = richloc.add_location_if_nearby (secondary_loc); 45900 error_at (&richloc, "main message"); 45901 if (!added secondary) 45902 inform (secondary_loc, "message for secondary"); 45903 45904This will emit either one diagnostic with two locations: 45905 demo.c:42:10: error: main message 45906 (foo) 45907 ~ ^ 45908 45909or two diagnostics: 45910 45911 demo.c:42:4: error: main message 45912 foo) 45913 ^ 45914 demo.c:40:2: note: message for secondary 45915 ( 45916 ^ 45917 4591828.1.7 Location Information 45919--------------------------- 45920 45921GCC's 'location_t' type can support both ordinary locations, and 45922locations relating to a macro expansion. 45923 45924 As of GCC 6, ordinary locations changed from supporting just a point in 45925the user's source code to supporting three points: the "caret" location, 45926plus a start and a finish: 45927 45928 a = foo && bar; 45929 ~~~~^~~~~~ 45930 | | | 45931 | | finish 45932 | caret 45933 start 45934 45935 Tokens coming out of libcpp have locations of the form 'caret == 45936start', such as for 'foo' here: 45937 45938 a = foo && bar; 45939 ^~~ 45940 | | 45941 | finish 45942 caret == start 45943 45944 Compound expressions should be reported using the location of the 45945expression as a whole, rather than just of one token within it. 45946 45947 For example, in '-Wformat', rather than underlining just the first 45948token of a bad argument: 45949 45950 printf("hello %i %s", (long)0, "world"); 45951 ~^ ~ 45952 %li 45953 45954the whole of the expression should be underlined, so that the user can 45955easily identify what is being referred to: 45956 45957 printf("hello %i %s", (long)0, "world"); 45958 ~^ ~~~~~~~ 45959 %li 45960 45961 Avoid using the 'input_location' global, and the diagnostic functions 45962that implicitly use it--use 'error_at' and 'warning_at' rather than 45963'error' and 'warning', and provide the most appropriate 'location_t' 45964value available at that phase of the compilation. It's possible to 45965supply secondary 'location_t' values via 'rich_location'. 45966 45967For example, in the example of imprecise wording above, generating the 45968diagnostic using 'warning': 45969 45970 // BAD: implicitly uses input_location 45971 warning (OPT_Wattributes, "%qE attribute ignored", name); 45972 45973leads to: 45974 45975 // BAD: uses input_location 45976 demo.c:1:1: warning: 'noinline' attribute ignored [-Wattributes] 45977 1 | int foo __attribute__((noinline)); 45978 | ^~~ 45979 45980which thus happened to use the location of the 'int' token, rather than 45981that of the attribute. Using 'warning_at' with the location of the 45982attribute, providing the location of the declaration in question as a 45983secondary location, and adding a note: 45984 45985 auto_diagnostic_group d; 45986 gcc_rich_location richloc (attrib_loc); 45987 richloc.add_range (decl_loc); 45988 if (warning_at (OPT_Wattributes, &richloc, 45989 "attribute %qE on variable %qE was ignored", name)) 45990 inform (attrib_loc, "attribute %qE is only applicable to functions"); 45991 45992would lead to: 45993 45994 // OK: use location of attribute, with a secondary location 45995 demo.c:1:24: warning: attribute 'noinline' on variable 'foo' was 45996 ignored [-Wattributes] 45997 1 | int foo __attribute__((noinline)); 45998 | ~~~ ~~~~~~~~~~~~~~~^~~~~~~~~ 45999 demo.c:1:24: note: attribute 'noinline' is only applicable to functions 46000 4600128.1.8 Coding Conventions 46002------------------------- 46003 46004See the diagnostics section 46005(https://gcc.gnu.org/codingconventions.html#Diagnostics) of the GCC 46006coding conventions. 46007 46008 In the C++ front end, when comparing two types in a message, use '%H' 46009and '%I' rather than '%T', as this allows the diagnostics subsystem to 46010highlight differences between template-based types. For example, rather 46011than using '%qT': 46012 46013 // BAD: a pair of %qT used in C++ front end for type comparison 46014 error_at (loc, "could not convert %qE from %qT to %qT", expr, 46015 TREE_TYPE (expr), type); 46016 46017which could lead to: 46018 46019 error: could not convert 'map<int, double>()' from 'map<int,double>' 46020 to 'map<int,int>' 46021 46022using '%H' and '%I' (via '%qH' and '%qI'): 46023 46024 // OK: compare types in C++ front end via %qH and %qI 46025 error_at (loc, "could not convert %qE from %qH to %qI", expr, 46026 TREE_TYPE (expr), type); 46027 46028allows the above output to be simplified to: 46029 46030 error: could not convert 'map<int, double>()' from 'map<[...],double>' 46031 to 'map<[...],int>' 46032 46033where the 'double' and 'int' are colorized to highlight them. 46034 4603528.1.9 Group logically-related diagnostics 46036------------------------------------------ 46037 46038Use 'auto_diagnostic_group' when issuing multiple related diagnostics 46039(seen in various examples on this page). This informs the diagnostic 46040subsystem that all diagnostics issued within the lifetime of the 46041'auto_diagnostic_group' are related. For example, 46042'-fdiagnostics-format=json' will treat the first diagnostic emitted 46043within the group as a top-level diagnostic, and all subsequent 46044diagnostics within the group as its children. 46045 4604628.1.10 Quoting 46047--------------- 46048 46049Text should be quoted by either using the 'q' modifier in a directive 46050such as '%qE', or by enclosing the quoted text in a pair of '%<' and 46051'%>' directives, and never by using explicit quote characters. The 46052directives handle the appropriate quote characters for each language and 46053apply the correct color or highlighting. 46054 46055 The following elements should be quoted in GCC diagnostics: 46056 46057 * Language keywords. 46058 * Tokens. 46059 * Boolean, numerical, character, and string constants that appear in 46060 the source code. 46061 * Identifiers, including function, macro, type, and variable names. 46062 46063 Other elements such as numbers that do not refer to numeric constants 46064that appear in the source code should not be quoted. For example, in 46065the message: 46066 46067 argument %d of %qE must be a pointer type 46068 46069since the argument number does not refer to a numerical constant in the 46070source code it should not be quoted. 46071 4607228.1.11 Spelling and Terminology 46073-------------------------------- 46074 46075See the terminology and markup 46076(https://gcc.gnu.org/codingconventions.html#Spelling Spelling) section 46077of the GCC coding conventions. 46078 4607928.1.12 Fix-it hints 46080-------------------- 46081 46082GCC's diagnostic subsystem can emit "fix-it hints": small suggested 46083edits to the user's source code. 46084 46085 They are printed by default underneath the code in question. They can 46086also be viewed via '-fdiagnostics-generate-patch' and 46087'-fdiagnostics-parseable-fixits'. With the latter, an IDE ought to be 46088able to offer to automatically apply the suggested fix. 46089 46090 Fix-it hints contain code fragments, and thus they should not be marked 46091for translation. 46092 46093 Fix-it hints can be added to a diagnostic by using a 'rich_location' 46094rather than a 'location_t' - the fix-it hints are added to the 46095'rich_location' using one of the various 'add_fixit' member functions of 46096'rich_location'. They are documented with 'rich_location' in 46097'libcpp/line-map.h'. It's easiest to use the 'gcc_rich_location' 46098subclass of 'rich_location' found in 'gcc-rich-location.h', as this 46099implicitly supplies the 'line_table' variable. 46100 46101 For example: 46102 46103 if (const char *suggestion = hint.suggestion ()) 46104 { 46105 gcc_rich_location richloc (location); 46106 richloc.add_fixit_replace (suggestion); 46107 error_at (&richloc, 46108 "%qE does not name a type; did you mean %qs?", 46109 id, suggestion); 46110 } 46111 46112which can lead to: 46113 46114 spellcheck-typenames.C:73:1: error: 'singed' does not name a type; did 46115 you mean 'signed'? 46116 73 | singed char ch; 46117 | ^~~~~~ 46118 | signed 46119 46120 Non-trivial edits can be built up by adding multiple fix-it hints to 46121one 'rich_location'. It's best to express the edits in terms of the 46122locations of individual tokens. Various handy functions for adding 46123fix-it hints for idiomatic C and C++ can be seen in 46124'gcc-rich-location.h'. 46125 4612628.1.12.1 Fix-it hints should work 46127.................................. 46128 46129When implementing a fix-it hint, please verify that the suggested edit 46130leads to fixed, compilable code. (Unfortunately, this currently must be 46131done by hand using '-fdiagnostics-generate-patch'. It would be good to 46132have an automated way of verifying that fix-it hints actually fix the 46133code). 46134 46135 For example, a "gotcha" here is to forget to add a space when adding a 46136missing reserved word. Consider a C++ fix-it hint that adds 'typename' 46137in front of a template declaration. A naive way to implement this might 46138be: 46139 46140 gcc_rich_location richloc (loc); 46141 // BAD: insertion is missing a trailing space 46142 richloc.add_fixit_insert_before ("typename"); 46143 error_at (&richloc, "need %<typename%> before %<%T::%E%> because " 46144 "%qT is a dependent scope", 46145 parser->scope, id, parser->scope); 46146 46147When applied to the code, this might lead to: 46148 46149 T::type x; 46150 46151being "corrected" to: 46152 46153 typenameT::type x; 46154 46155In this case, the correct thing to do is to add a trailing space after 46156'typename': 46157 46158 gcc_rich_location richloc (loc); 46159 // OK: note that here we have a trailing space 46160 richloc.add_fixit_insert_before ("typename "); 46161 error_at (&richloc, "need %<typename%> before %<%T::%E%> because " 46162 "%qT is a dependent scope", 46163 parser->scope, id, parser->scope); 46164 46165leading to this corrected code: 46166 46167 typename T::type x; 46168 4616928.1.12.2 Express deletion in terms of deletion, not replacement 46170................................................................ 46171 46172It's best to express deletion suggestions in terms of deletion fix-it 46173hints, rather than replacement fix-it hints. For example, consider 46174this: 46175 46176 auto_diagnostic_group d; 46177 gcc_rich_location richloc (location_of (retval)); 46178 tree name = DECL_NAME (arg); 46179 richloc.add_fixit_replace (IDENTIFIER_POINTER (name)); 46180 warning_at (&richloc, OPT_Wredundant_move, 46181 "redundant move in return statement"); 46182 46183which is intended to e.g. replace a 'std::move' with the underlying 46184value: 46185 46186 return std::move (retval); 46187 ~~~~~~~~~~^~~~~~~~ 46188 retval 46189 46190where the change has been expressed as replacement, replacing with the 46191name of the declaration. This works for simple cases, but consider this 46192case: 46193 46194 #ifdef SOME_CONFIG_FLAG 46195 # define CONFIGURY_GLOBAL global_a 46196 #else 46197 # define CONFIGURY_GLOBAL global_b 46198 #endif 46199 46200 int fn () 46201 { 46202 return std::move (CONFIGURY_GLOBAL /* some comment */); 46203 } 46204 46205The above implementation erroneously strips out the macro and the 46206comment in the fix-it hint: 46207 46208 return std::move (CONFIGURY_GLOBAL /* some comment */); 46209 ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 46210 global_a 46211 46212and thus this resulting code: 46213 46214 return global_a; 46215 46216It's better to do deletions in terms of deletions; deleting the 46217'std::move (' and the trailing close-paren, leading to this: 46218 46219 return std::move (CONFIGURY_GLOBAL /* some comment */); 46220 ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 46221 CONFIGURY_GLOBAL /* some comment */ 46222 46223and thus this result: 46224 46225 return CONFIGURY_GLOBAL /* some comment */; 46226 46227Unfortunately, the pertinent 'location_t' values are not always 46228available. 46229 4623028.1.12.3 Multiple suggestions 46231.............................. 46232 46233In the rare cases where you need to suggest more than one mutually 46234exclusive solution to a problem, this can be done by emitting multiple 46235notes and calling 'rich_location::fixits_cannot_be_auto_applied' on each 46236note's 'rich_location'. If this is called, then the fix-it hints in the 46237'rich_location' will be printed, but will not be added to generated 46238patches. 46239 46240 46241File: gccint.info, Node: Guidelines for Options, Prev: Guidelines for Diagnostics, Up: User Experience Guidelines 46242 4624328.2 Guidelines for Options 46244=========================== 46245 46246 46247File: gccint.info, Node: Funding, Next: GNU Project, Prev: User Experience Guidelines, Up: Top 46248 46249Funding Free Software 46250********************* 46251 46252If you want to have more free software a few years from now, it makes 46253sense for you to help encourage people to contribute funds for its 46254development. The most effective approach known is to encourage 46255commercial redistributors to donate. 46256 46257 Users of free software systems can boost the pace of development by 46258encouraging for-a-fee distributors to donate part of their selling price 46259to free software developers--the Free Software Foundation, and others. 46260 46261 The way to convince distributors to do this is to demand it and expect 46262it from them. So when you compare distributors, judge them partly by 46263how much they give to free software development. Show distributors they 46264must compete to be the one who gives the most. 46265 46266 To make this approach work, you must insist on numbers that you can 46267compare, such as, "We will donate ten dollars to the Frobnitz project 46268for each disk sold." Don't be satisfied with a vague promise, such as 46269"A portion of the profits are donated," since it doesn't give a basis 46270for comparison. 46271 46272 Even a precise fraction "of the profits from this disk" is not very 46273meaningful, since creative accounting and unrelated business decisions 46274can greatly alter what fraction of the sales price counts as profit. If 46275the price you pay is $50, ten percent of the profit is probably less 46276than a dollar; it might be a few cents, or nothing at all. 46277 46278 Some redistributors do development work themselves. This is useful 46279too; but to keep everyone honest, you need to inquire how much they do, 46280and what kind. Some kinds of development make much more long-term 46281difference than others. For example, maintaining a separate version of 46282a program contributes very little; maintaining the standard version of a 46283program for the whole community contributes much. Easy new ports 46284contribute little, since someone else would surely do them; difficult 46285ports such as adding a new CPU to the GNU Compiler Collection contribute 46286more; major new features or packages contribute the most. 46287 46288 By establishing the idea that supporting further development is "the 46289proper thing to do" when distributing free software for a fee, we can 46290assure a steady flow of resources into making more free software. 46291 46292 Copyright (C) 1994 Free Software Foundation, Inc. 46293 Verbatim copying and redistribution of this section is permitted 46294 without royalty; alteration is not permitted. 46295 46296 46297File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 46298 46299The GNU Project and GNU/Linux 46300***************************** 46301 46302The GNU Project was launched in 1984 to develop a complete Unix-like 46303operating system which is free software: the GNU system. (GNU is a 46304recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 46305Variants of the GNU operating system, which use the kernel Linux, are 46306now widely used; though these systems are often referred to as "Linux", 46307they are more accurately called GNU/Linux systems. 46308 46309 For more information, see: 46310 <http://www.gnu.org/> 46311 <http://www.gnu.org/gnu/linux-and-gnu.html> 46312 46313 46314File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 46315 46316GNU General Public License 46317************************** 46318 46319 Version 3, 29 June 2007 46320 46321 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> 46322 46323 Everyone is permitted to copy and distribute verbatim copies of this 46324 license document, but changing it is not allowed. 46325 46326Preamble 46327======== 46328 46329The GNU General Public License is a free, copyleft license for software 46330and other kinds of works. 46331 46332 The licenses for most software and other practical works are designed 46333to take away your freedom to share and change the works. By contrast, 46334the GNU General Public License is intended to guarantee your freedom to 46335share and change all versions of a program-to make sure it remains free 46336software for all its users. We, the Free Software Foundation, use the 46337GNU General Public License for most of our software; it applies also to 46338any other work released this way by its authors. You can apply it to 46339your programs, too. 46340 46341 When we speak of free software, we are referring to freedom, not price. 46342Our General Public Licenses are designed to make sure that you have the 46343freedom to distribute copies of free software (and charge for them if 46344you wish), that you receive source code or can get it if you want it, 46345that you can change the software or use pieces of it in new free 46346programs, and that you know you can do these things. 46347 46348 To protect your rights, we need to prevent others from denying you 46349these rights or asking you to surrender the rights. Therefore, you have 46350certain responsibilities if you distribute copies of the software, or if 46351you modify it: responsibilities to respect the freedom of others. 46352 46353 For example, if you distribute copies of such a program, whether gratis 46354or for a fee, you must pass on to the recipients the same freedoms that 46355you received. You must make sure that they, too, receive or can get the 46356source code. And you must show them these terms so they know their 46357rights. 46358 46359 Developers that use the GNU GPL protect your rights with two steps: (1) 46360assert copyright on the software, and (2) offer you this License giving 46361you legal permission to copy, distribute and/or modify it. 46362 46363 For the developers' and authors' protection, the GPL clearly explains 46364that there is no warranty for this free software. For both users' and 46365authors' sake, the GPL requires that modified versions be marked as 46366changed, so that their problems will not be attributed erroneously to 46367authors of previous versions. 46368 46369 Some devices are designed to deny users access to install or run 46370modified versions of the software inside them, although the manufacturer 46371can do so. This is fundamentally incompatible with the aim of 46372protecting users' freedom to change the software. The systematic 46373pattern of such abuse occurs in the area of products for individuals to 46374use, which is precisely where it is most unacceptable. Therefore, we 46375have designed this version of the GPL to prohibit the practice for those 46376products. If such problems arise substantially in other domains, we 46377stand ready to extend this provision to those domains in future versions 46378of the GPL, as needed to protect the freedom of users. 46379 46380 Finally, every program is threatened constantly by software patents. 46381States should not allow patents to restrict development and use of 46382software on general-purpose computers, but in those that do, we wish to 46383avoid the special danger that patents applied to a free program could 46384make it effectively proprietary. To prevent this, the GPL assures that 46385patents cannot be used to render the program non-free. 46386 46387 The precise terms and conditions for copying, distribution and 46388modification follow. 46389 46390TERMS AND CONDITIONS 46391==================== 46392 46393 0. Definitions. 46394 46395 "This License" refers to version 3 of the GNU General Public 46396 License. 46397 46398 "Copyright" also means copyright-like laws that apply to other 46399 kinds of works, such as semiconductor masks. 46400 46401 "The Program" refers to any copyrightable work licensed under this 46402 License. Each licensee is addressed as "you". "Licensees" and 46403 "recipients" may be individuals or organizations. 46404 46405 To "modify" a work means to copy from or adapt all or part of the 46406 work in a fashion requiring copyright permission, other than the 46407 making of an exact copy. The resulting work is called a "modified 46408 version" of the earlier work or a work "based on" the earlier work. 46409 46410 A "covered work" means either the unmodified Program or a work 46411 based on the Program. 46412 46413 To "propagate" a work means to do anything with it that, without 46414 permission, would make you directly or secondarily liable for 46415 infringement under applicable copyright law, except executing it on 46416 a computer or modifying a private copy. Propagation includes 46417 copying, distribution (with or without modification), making 46418 available to the public, and in some countries other activities as 46419 well. 46420 46421 To "convey" a work means any kind of propagation that enables other 46422 parties to make or receive copies. Mere interaction with a user 46423 through a computer network, with no transfer of a copy, is not 46424 conveying. 46425 46426 An interactive user interface displays "Appropriate Legal Notices" 46427 to the extent that it includes a convenient and prominently visible 46428 feature that (1) displays an appropriate copyright notice, and (2) 46429 tells the user that there is no warranty for the work (except to 46430 the extent that warranties are provided), that licensees may convey 46431 the work under this License, and how to view a copy of this 46432 License. If the interface presents a list of user commands or 46433 options, such as a menu, a prominent item in the list meets this 46434 criterion. 46435 46436 1. Source Code. 46437 46438 The "source code" for a work means the preferred form of the work 46439 for making modifications to it. "Object code" means any non-source 46440 form of a work. 46441 46442 A "Standard Interface" means an interface that either is an 46443 official standard defined by a recognized standards body, or, in 46444 the case of interfaces specified for a particular programming 46445 language, one that is widely used among developers working in that 46446 language. 46447 46448 The "System Libraries" of an executable work include anything, 46449 other than the work as a whole, that (a) is included in the normal 46450 form of packaging a Major Component, but which is not part of that 46451 Major Component, and (b) serves only to enable use of the work with 46452 that Major Component, or to implement a Standard Interface for 46453 which an implementation is available to the public in source code 46454 form. A "Major Component", in this context, means a major 46455 essential component (kernel, window system, and so on) of the 46456 specific operating system (if any) on which the executable work 46457 runs, or a compiler used to produce the work, or an object code 46458 interpreter used to run it. 46459 46460 The "Corresponding Source" for a work in object code form means all 46461 the source code needed to generate, install, and (for an executable 46462 work) run the object code and to modify the work, including scripts 46463 to control those activities. However, it does not include the 46464 work's System Libraries, or general-purpose tools or generally 46465 available free programs which are used unmodified in performing 46466 those activities but which are not part of the work. For example, 46467 Corresponding Source includes interface definition files associated 46468 with source files for the work, and the source code for shared 46469 libraries and dynamically linked subprograms that the work is 46470 specifically designed to require, such as by intimate data 46471 communication or control flow between those subprograms and other 46472 parts of the work. 46473 46474 The Corresponding Source need not include anything that users can 46475 regenerate automatically from other parts of the Corresponding 46476 Source. 46477 46478 The Corresponding Source for a work in source code form is that 46479 same work. 46480 46481 2. Basic Permissions. 46482 46483 All rights granted under this License are granted for the term of 46484 copyright on the Program, and are irrevocable provided the stated 46485 conditions are met. This License explicitly affirms your unlimited 46486 permission to run the unmodified Program. The output from running 46487 a covered work is covered by this License only if the output, given 46488 its content, constitutes a covered work. This License acknowledges 46489 your rights of fair use or other equivalent, as provided by 46490 copyright law. 46491 46492 You may make, run and propagate covered works that you do not 46493 convey, without conditions so long as your license otherwise 46494 remains in force. You may convey covered works to others for the 46495 sole purpose of having them make modifications exclusively for you, 46496 or provide you with facilities for running those works, provided 46497 that you comply with the terms of this License in conveying all 46498 material for which you do not control copyright. Those thus making 46499 or running the covered works for you must do so exclusively on your 46500 behalf, under your direction and control, on terms that prohibit 46501 them from making any copies of your copyrighted material outside 46502 their relationship with you. 46503 46504 Conveying under any other circumstances is permitted solely under 46505 the conditions stated below. Sublicensing is not allowed; section 46506 10 makes it unnecessary. 46507 46508 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 46509 46510 No covered work shall be deemed part of an effective technological 46511 measure under any applicable law fulfilling obligations under 46512 article 11 of the WIPO copyright treaty adopted on 20 December 46513 1996, or similar laws prohibiting or restricting circumvention of 46514 such measures. 46515 46516 When you convey a covered work, you waive any legal power to forbid 46517 circumvention of technological measures to the extent such 46518 circumvention is effected by exercising rights under this License 46519 with respect to the covered work, and you disclaim any intention to 46520 limit operation or modification of the work as a means of 46521 enforcing, against the work's users, your or third parties' legal 46522 rights to forbid circumvention of technological measures. 46523 46524 4. Conveying Verbatim Copies. 46525 46526 You may convey verbatim copies of the Program's source code as you 46527 receive it, in any medium, provided that you conspicuously and 46528 appropriately publish on each copy an appropriate copyright notice; 46529 keep intact all notices stating that this License and any 46530 non-permissive terms added in accord with section 7 apply to the 46531 code; keep intact all notices of the absence of any warranty; and 46532 give all recipients a copy of this License along with the Program. 46533 46534 You may charge any price or no price for each copy that you convey, 46535 and you may offer support or warranty protection for a fee. 46536 46537 5. Conveying Modified Source Versions. 46538 46539 You may convey a work based on the Program, or the modifications to 46540 produce it from the Program, in the form of source code under the 46541 terms of section 4, provided that you also meet all of these 46542 conditions: 46543 46544 a. The work must carry prominent notices stating that you 46545 modified it, and giving a relevant date. 46546 46547 b. The work must carry prominent notices stating that it is 46548 released under this License and any conditions added under 46549 section 7. This requirement modifies the requirement in 46550 section 4 to "keep intact all notices". 46551 46552 c. You must license the entire work, as a whole, under this 46553 License to anyone who comes into possession of a copy. This 46554 License will therefore apply, along with any applicable 46555 section 7 additional terms, to the whole of the work, and all 46556 its parts, regardless of how they are packaged. This License 46557 gives no permission to license the work in any other way, but 46558 it does not invalidate such permission if you have separately 46559 received it. 46560 46561 d. If the work has interactive user interfaces, each must display 46562 Appropriate Legal Notices; however, if the Program has 46563 interactive interfaces that do not display Appropriate Legal 46564 Notices, your work need not make them do so. 46565 46566 A compilation of a covered work with other separate and independent 46567 works, which are not by their nature extensions of the covered 46568 work, and which are not combined with it such as to form a larger 46569 program, in or on a volume of a storage or distribution medium, is 46570 called an "aggregate" if the compilation and its resulting 46571 copyright are not used to limit the access or legal rights of the 46572 compilation's users beyond what the individual works permit. 46573 Inclusion of a covered work in an aggregate does not cause this 46574 License to apply to the other parts of the aggregate. 46575 46576 6. Conveying Non-Source Forms. 46577 46578 You may convey a covered work in object code form under the terms 46579 of sections 4 and 5, provided that you also convey the 46580 machine-readable Corresponding Source under the terms of this 46581 License, in one of these ways: 46582 46583 a. Convey the object code in, or embodied in, a physical product 46584 (including a physical distribution medium), accompanied by the 46585 Corresponding Source fixed on a durable physical medium 46586 customarily used for software interchange. 46587 46588 b. Convey the object code in, or embodied in, a physical product 46589 (including a physical distribution medium), accompanied by a 46590 written offer, valid for at least three years and valid for as 46591 long as you offer spare parts or customer support for that 46592 product model, to give anyone who possesses the object code 46593 either (1) a copy of the Corresponding Source for all the 46594 software in the product that is covered by this License, on a 46595 durable physical medium customarily used for software 46596 interchange, for a price no more than your reasonable cost of 46597 physically performing this conveying of source, or (2) access 46598 to copy the Corresponding Source from a network server at no 46599 charge. 46600 46601 c. Convey individual copies of the object code with a copy of the 46602 written offer to provide the Corresponding Source. This 46603 alternative is allowed only occasionally and noncommercially, 46604 and only if you received the object code with such an offer, 46605 in accord with subsection 6b. 46606 46607 d. Convey the object code by offering access from a designated 46608 place (gratis or for a charge), and offer equivalent access to 46609 the Corresponding Source in the same way through the same 46610 place at no further charge. You need not require recipients 46611 to copy the Corresponding Source along with the object code. 46612 If the place to copy the object code is a network server, the 46613 Corresponding Source may be on a different server (operated by 46614 you or a third party) that supports equivalent copying 46615 facilities, provided you maintain clear directions next to the 46616 object code saying where to find the Corresponding Source. 46617 Regardless of what server hosts the Corresponding Source, you 46618 remain obligated to ensure that it is available for as long as 46619 needed to satisfy these requirements. 46620 46621 e. Convey the object code using peer-to-peer transmission, 46622 provided you inform other peers where the object code and 46623 Corresponding Source of the work are being offered to the 46624 general public at no charge under subsection 6d. 46625 46626 A separable portion of the object code, whose source code is 46627 excluded from the Corresponding Source as a System Library, need 46628 not be included in conveying the object code work. 46629 46630 A "User Product" is either (1) a "consumer product", which means 46631 any tangible personal property which is normally used for personal, 46632 family, or household purposes, or (2) anything designed or sold for 46633 incorporation into a dwelling. In determining whether a product is 46634 a consumer product, doubtful cases shall be resolved in favor of 46635 coverage. For a particular product received by a particular user, 46636 "normally used" refers to a typical or common use of that class of 46637 product, regardless of the status of the particular user or of the 46638 way in which the particular user actually uses, or expects or is 46639 expected to use, the product. A product is a consumer product 46640 regardless of whether the product has substantial commercial, 46641 industrial or non-consumer uses, unless such uses represent the 46642 only significant mode of use of the product. 46643 46644 "Installation Information" for a User Product means any methods, 46645 procedures, authorization keys, or other information required to 46646 install and execute modified versions of a covered work in that 46647 User Product from a modified version of its Corresponding Source. 46648 The information must suffice to ensure that the continued 46649 functioning of the modified object code is in no case prevented or 46650 interfered with solely because modification has been made. 46651 46652 If you convey an object code work under this section in, or with, 46653 or specifically for use in, a User Product, and the conveying 46654 occurs as part of a transaction in which the right of possession 46655 and use of the User Product is transferred to the recipient in 46656 perpetuity or for a fixed term (regardless of how the transaction 46657 is characterized), the Corresponding Source conveyed under this 46658 section must be accompanied by the Installation Information. But 46659 this requirement does not apply if neither you nor any third party 46660 retains the ability to install modified object code on the User 46661 Product (for example, the work has been installed in ROM). 46662 46663 The requirement to provide Installation Information does not 46664 include a requirement to continue to provide support service, 46665 warranty, or updates for a work that has been modified or installed 46666 by the recipient, or for the User Product in which it has been 46667 modified or installed. Access to a network may be denied when the 46668 modification itself materially and adversely affects the operation 46669 of the network or violates the rules and protocols for 46670 communication across the network. 46671 46672 Corresponding Source conveyed, and Installation Information 46673 provided, in accord with this section must be in a format that is 46674 publicly documented (and with an implementation available to the 46675 public in source code form), and must require no special password 46676 or key for unpacking, reading or copying. 46677 46678 7. Additional Terms. 46679 46680 "Additional permissions" are terms that supplement the terms of 46681 this License by making exceptions from one or more of its 46682 conditions. Additional permissions that are applicable to the 46683 entire Program shall be treated as though they were included in 46684 this License, to the extent that they are valid under applicable 46685 law. If additional permissions apply only to part of the Program, 46686 that part may be used separately under those permissions, but the 46687 entire Program remains governed by this License without regard to 46688 the additional permissions. 46689 46690 When you convey a copy of a covered work, you may at your option 46691 remove any additional permissions from that copy, or from any part 46692 of it. (Additional permissions may be written to require their own 46693 removal in certain cases when you modify the work.) You may place 46694 additional permissions on material, added by you to a covered work, 46695 for which you have or can give appropriate copyright permission. 46696 46697 Notwithstanding any other provision of this License, for material 46698 you add to a covered work, you may (if authorized by the copyright 46699 holders of that material) supplement the terms of this License with 46700 terms: 46701 46702 a. Disclaiming warranty or limiting liability differently from 46703 the terms of sections 15 and 16 of this License; or 46704 46705 b. Requiring preservation of specified reasonable legal notices 46706 or author attributions in that material or in the Appropriate 46707 Legal Notices displayed by works containing it; or 46708 46709 c. Prohibiting misrepresentation of the origin of that material, 46710 or requiring that modified versions of such material be marked 46711 in reasonable ways as different from the original version; or 46712 46713 d. Limiting the use for publicity purposes of names of licensors 46714 or authors of the material; or 46715 46716 e. Declining to grant rights under trademark law for use of some 46717 trade names, trademarks, or service marks; or 46718 46719 f. Requiring indemnification of licensors and authors of that 46720 material by anyone who conveys the material (or modified 46721 versions of it) with contractual assumptions of liability to 46722 the recipient, for any liability that these contractual 46723 assumptions directly impose on those licensors and authors. 46724 46725 All other non-permissive additional terms are considered "further 46726 restrictions" within the meaning of section 10. If the Program as 46727 you received it, or any part of it, contains a notice stating that 46728 it is governed by this License along with a term that is a further 46729 restriction, you may remove that term. If a license document 46730 contains a further restriction but permits relicensing or conveying 46731 under this License, you may add to a covered work material governed 46732 by the terms of that license document, provided that the further 46733 restriction does not survive such relicensing or conveying. 46734 46735 If you add terms to a covered work in accord with this section, you 46736 must place, in the relevant source files, a statement of the 46737 additional terms that apply to those files, or a notice indicating 46738 where to find the applicable terms. 46739 46740 Additional terms, permissive or non-permissive, may be stated in 46741 the form of a separately written license, or stated as exceptions; 46742 the above requirements apply either way. 46743 46744 8. Termination. 46745 46746 You may not propagate or modify a covered work except as expressly 46747 provided under this License. Any attempt otherwise to propagate or 46748 modify it is void, and will automatically terminate your rights 46749 under this License (including any patent licenses granted under the 46750 third paragraph of section 11). 46751 46752 However, if you cease all violation of this License, then your 46753 license from a particular copyright holder is reinstated (a) 46754 provisionally, unless and until the copyright holder explicitly and 46755 finally terminates your license, and (b) permanently, if the 46756 copyright holder fails to notify you of the violation by some 46757 reasonable means prior to 60 days after the cessation. 46758 46759 Moreover, your license from a particular copyright holder is 46760 reinstated permanently if the copyright holder notifies you of the 46761 violation by some reasonable means, this is the first time you have 46762 received notice of violation of this License (for any work) from 46763 that copyright holder, and you cure the violation prior to 30 days 46764 after your receipt of the notice. 46765 46766 Termination of your rights under this section does not terminate 46767 the licenses of parties who have received copies or rights from you 46768 under this License. If your rights have been terminated and not 46769 permanently reinstated, you do not qualify to receive new licenses 46770 for the same material under section 10. 46771 46772 9. Acceptance Not Required for Having Copies. 46773 46774 You are not required to accept this License in order to receive or 46775 run a copy of the Program. Ancillary propagation of a covered work 46776 occurring solely as a consequence of using peer-to-peer 46777 transmission to receive a copy likewise does not require 46778 acceptance. However, nothing other than this License grants you 46779 permission to propagate or modify any covered work. These actions 46780 infringe copyright if you do not accept this License. Therefore, 46781 by modifying or propagating a covered work, you indicate your 46782 acceptance of this License to do so. 46783 46784 10. Automatic Licensing of Downstream Recipients. 46785 46786 Each time you convey a covered work, the recipient automatically 46787 receives a license from the original licensors, to run, modify and 46788 propagate that work, subject to this License. You are not 46789 responsible for enforcing compliance by third parties with this 46790 License. 46791 46792 An "entity transaction" is a transaction transferring control of an 46793 organization, or substantially all assets of one, or subdividing an 46794 organization, or merging organizations. If propagation of a 46795 covered work results from an entity transaction, each party to that 46796 transaction who receives a copy of the work also receives whatever 46797 licenses to the work the party's predecessor in interest had or 46798 could give under the previous paragraph, plus a right to possession 46799 of the Corresponding Source of the work from the predecessor in 46800 interest, if the predecessor has it or can get it with reasonable 46801 efforts. 46802 46803 You may not impose any further restrictions on the exercise of the 46804 rights granted or affirmed under this License. For example, you 46805 may not impose a license fee, royalty, or other charge for exercise 46806 of rights granted under this License, and you may not initiate 46807 litigation (including a cross-claim or counterclaim in a lawsuit) 46808 alleging that any patent claim is infringed by making, using, 46809 selling, offering for sale, or importing the Program or any portion 46810 of it. 46811 46812 11. Patents. 46813 46814 A "contributor" is a copyright holder who authorizes use under this 46815 License of the Program or a work on which the Program is based. 46816 The work thus licensed is called the contributor's "contributor 46817 version". 46818 46819 A contributor's "essential patent claims" are all patent claims 46820 owned or controlled by the contributor, whether already acquired or 46821 hereafter acquired, that would be infringed by some manner, 46822 permitted by this License, of making, using, or selling its 46823 contributor version, but do not include claims that would be 46824 infringed only as a consequence of further modification of the 46825 contributor version. For purposes of this definition, "control" 46826 includes the right to grant patent sublicenses in a manner 46827 consistent with the requirements of this License. 46828 46829 Each contributor grants you a non-exclusive, worldwide, 46830 royalty-free patent license under the contributor's essential 46831 patent claims, to make, use, sell, offer for sale, import and 46832 otherwise run, modify and propagate the contents of its contributor 46833 version. 46834 46835 In the following three paragraphs, a "patent license" is any 46836 express agreement or commitment, however denominated, not to 46837 enforce a patent (such as an express permission to practice a 46838 patent or covenant not to sue for patent infringement). To "grant" 46839 such a patent license to a party means to make such an agreement or 46840 commitment not to enforce a patent against the party. 46841 46842 If you convey a covered work, knowingly relying on a patent 46843 license, and the Corresponding Source of the work is not available 46844 for anyone to copy, free of charge and under the terms of this 46845 License, through a publicly available network server or other 46846 readily accessible means, then you must either (1) cause the 46847 Corresponding Source to be so available, or (2) arrange to deprive 46848 yourself of the benefit of the patent license for this particular 46849 work, or (3) arrange, in a manner consistent with the requirements 46850 of this License, to extend the patent license to downstream 46851 recipients. "Knowingly relying" means you have actual knowledge 46852 that, but for the patent license, your conveying the covered work 46853 in a country, or your recipient's use of the covered work in a 46854 country, would infringe one or more identifiable patents in that 46855 country that you have reason to believe are valid. 46856 46857 If, pursuant to or in connection with a single transaction or 46858 arrangement, you convey, or propagate by procuring conveyance of, a 46859 covered work, and grant a patent license to some of the parties 46860 receiving the covered work authorizing them to use, propagate, 46861 modify or convey a specific copy of the covered work, then the 46862 patent license you grant is automatically extended to all 46863 recipients of the covered work and works based on it. 46864 46865 A patent license is "discriminatory" if it does not include within 46866 the scope of its coverage, prohibits the exercise of, or is 46867 conditioned on the non-exercise of one or more of the rights that 46868 are specifically granted under this License. You may not convey a 46869 covered work if you are a party to an arrangement with a third 46870 party that is in the business of distributing software, under which 46871 you make payment to the third party based on the extent of your 46872 activity of conveying the work, and under which the third party 46873 grants, to any of the parties who would receive the covered work 46874 from you, a discriminatory patent license (a) in connection with 46875 copies of the covered work conveyed by you (or copies made from 46876 those copies), or (b) primarily for and in connection with specific 46877 products or compilations that contain the covered work, unless you 46878 entered into that arrangement, or that patent license was granted, 46879 prior to 28 March 2007. 46880 46881 Nothing in this License shall be construed as excluding or limiting 46882 any implied license or other defenses to infringement that may 46883 otherwise be available to you under applicable patent law. 46884 46885 12. No Surrender of Others' Freedom. 46886 46887 If conditions are imposed on you (whether by court order, agreement 46888 or otherwise) that contradict the conditions of this License, they 46889 do not excuse you from the conditions of this License. If you 46890 cannot convey a covered work so as to satisfy simultaneously your 46891 obligations under this License and any other pertinent obligations, 46892 then as a consequence you may not convey it at all. For example, 46893 if you agree to terms that obligate you to collect a royalty for 46894 further conveying from those to whom you convey the Program, the 46895 only way you could satisfy both those terms and this License would 46896 be to refrain entirely from conveying the Program. 46897 46898 13. Use with the GNU Affero General Public License. 46899 46900 Notwithstanding any other provision of this License, you have 46901 permission to link or combine any covered work with a work licensed 46902 under version 3 of the GNU Affero General Public License into a 46903 single combined work, and to convey the resulting work. The terms 46904 of this License will continue to apply to the part which is the 46905 covered work, but the special requirements of the GNU Affero 46906 General Public License, section 13, concerning interaction through 46907 a network will apply to the combination as such. 46908 46909 14. Revised Versions of this License. 46910 46911 The Free Software Foundation may publish revised and/or new 46912 versions of the GNU General Public License from time to time. Such 46913 new versions will be similar in spirit to the present version, but 46914 may differ in detail to address new problems or concerns. 46915 46916 Each version is given a distinguishing version number. If the 46917 Program specifies that a certain numbered version of the GNU 46918 General Public License "or any later version" applies to it, you 46919 have the option of following the terms and conditions either of 46920 that numbered version or of any later version published by the Free 46921 Software Foundation. If the Program does not specify a version 46922 number of the GNU General Public License, you may choose any 46923 version ever published by the Free Software Foundation. 46924 46925 If the Program specifies that a proxy can decide which future 46926 versions of the GNU General Public License can be used, that 46927 proxy's public statement of acceptance of a version permanently 46928 authorizes you to choose that version for the Program. 46929 46930 Later license versions may give you additional or different 46931 permissions. However, no additional obligations are imposed on any 46932 author or copyright holder as a result of your choosing to follow a 46933 later version. 46934 46935 15. Disclaimer of Warranty. 46936 46937 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 46938 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 46939 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 46940 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 46941 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 46942 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 46943 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 46944 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 46945 NECESSARY SERVICING, REPAIR OR CORRECTION. 46946 46947 16. Limitation of Liability. 46948 46949 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 46950 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 46951 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR 46952 DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 46953 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 46954 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 46955 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 46956 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 46957 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 46958 THE POSSIBILITY OF SUCH DAMAGES. 46959 46960 17. Interpretation of Sections 15 and 16. 46961 46962 If the disclaimer of warranty and limitation of liability provided 46963 above cannot be given local legal effect according to their terms, 46964 reviewing courts shall apply local law that most closely 46965 approximates an absolute waiver of all civil liability in 46966 connection with the Program, unless a warranty or assumption of 46967 liability accompanies a copy of the Program in return for a fee. 46968 46969END OF TERMS AND CONDITIONS 46970=========================== 46971 46972How to Apply These Terms to Your New Programs 46973============================================= 46974 46975If you develop a new program, and you want it to be of the greatest 46976possible use to the public, the best way to achieve this is to make it 46977free software which everyone can redistribute and change under these 46978terms. 46979 46980 To do so, attach the following notices to the program. It is safest to 46981attach them to the start of each source file to most effectively state 46982the exclusion of warranty; and each file should have at least the 46983"copyright" line and a pointer to where the full notice is found. 46984 46985 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 46986 Copyright (C) YEAR NAME OF AUTHOR 46987 46988 This program is free software: you can redistribute it and/or modify 46989 it under the terms of the GNU General Public License as published by 46990 the Free Software Foundation, either version 3 of the License, or (at 46991 your option) any later version. 46992 46993 This program is distributed in the hope that it will be useful, but 46994 WITHOUT ANY WARRANTY; without even the implied warranty of 46995 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 46996 General Public License for more details. 46997 46998 You should have received a copy of the GNU General Public License 46999 along with this program. If not, see <http://www.gnu.org/licenses/>. 47000 47001 Also add information on how to contact you by electronic and paper 47002mail. 47003 47004 If the program does terminal interaction, make it output a short notice 47005like this when it starts in an interactive mode: 47006 47007 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 47008 This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'. 47009 This is free software, and you are welcome to redistribute it 47010 under certain conditions; type 'show c' for details. 47011 47012 The hypothetical commands 'show w' and 'show c' should show the 47013appropriate parts of the General Public License. Of course, your 47014program's commands might be different; for a GUI interface, you would 47015use an "about box". 47016 47017 You should also get your employer (if you work as a programmer) or 47018school, if any, to sign a "copyright disclaimer" for the program, if 47019necessary. For more information on this, and how to apply and follow 47020the GNU GPL, see <http://www.gnu.org/licenses/>. 47021 47022 The GNU General Public License does not permit incorporating your 47023program into proprietary programs. If your program is a subroutine 47024library, you may consider it more useful to permit linking proprietary 47025applications with the library. If this is what you want to do, use the 47026GNU Lesser General Public License instead of this License. But first, 47027please read <https://www.gnu.org/licenses/why-not-lgpl.html>. 47028 47029 47030File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 47031 47032GNU Free Documentation License 47033****************************** 47034 47035 Version 1.3, 3 November 2008 47036 47037 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 47038 <http://fsf.org/> 47039 47040 Everyone is permitted to copy and distribute verbatim copies 47041 of this license document, but changing it is not allowed. 47042 47043 0. PREAMBLE 47044 47045 The purpose of this License is to make a manual, textbook, or other 47046 functional and useful document "free" in the sense of freedom: to 47047 assure everyone the effective freedom to copy and redistribute it, 47048 with or without modifying it, either commercially or 47049 noncommercially. Secondarily, this License preserves for the 47050 author and publisher a way to get credit for their work, while not 47051 being considered responsible for modifications made by others. 47052 47053 This License is a kind of "copyleft", which means that derivative 47054 works of the document must themselves be free in the same sense. 47055 It complements the GNU General Public License, which is a copyleft 47056 license designed for free software. 47057 47058 We have designed this License in order to use it for manuals for 47059 free software, because free software needs free documentation: a 47060 free program should come with manuals providing the same freedoms 47061 that the software does. But this License is not limited to 47062 software manuals; it can be used for any textual work, regardless 47063 of subject matter or whether it is published as a printed book. We 47064 recommend this License principally for works whose purpose is 47065 instruction or reference. 47066 47067 1. APPLICABILITY AND DEFINITIONS 47068 47069 This License applies to any manual or other work, in any medium, 47070 that contains a notice placed by the copyright holder saying it can 47071 be distributed under the terms of this License. Such a notice 47072 grants a world-wide, royalty-free license, unlimited in duration, 47073 to use that work under the conditions stated herein. The 47074 "Document", below, refers to any such manual or work. Any member 47075 of the public is a licensee, and is addressed as "you". You accept 47076 the license if you copy, modify or distribute the work in a way 47077 requiring permission under copyright law. 47078 47079 A "Modified Version" of the Document means any work containing the 47080 Document or a portion of it, either copied verbatim, or with 47081 modifications and/or translated into another language. 47082 47083 A "Secondary Section" is a named appendix or a front-matter section 47084 of the Document that deals exclusively with the relationship of the 47085 publishers or authors of the Document to the Document's overall 47086 subject (or to related matters) and contains nothing that could 47087 fall directly within that overall subject. (Thus, if the Document 47088 is in part a textbook of mathematics, a Secondary Section may not 47089 explain any mathematics.) The relationship could be a matter of 47090 historical connection with the subject or with related matters, or 47091 of legal, commercial, philosophical, ethical or political position 47092 regarding them. 47093 47094 The "Invariant Sections" are certain Secondary Sections whose 47095 titles are designated, as being those of Invariant Sections, in the 47096 notice that says that the Document is released under this License. 47097 If a section does not fit the above definition of Secondary then it 47098 is not allowed to be designated as Invariant. The Document may 47099 contain zero Invariant Sections. If the Document does not identify 47100 any Invariant Sections then there are none. 47101 47102 The "Cover Texts" are certain short passages of text that are 47103 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 47104 that says that the Document is released under this License. A 47105 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 47106 be at most 25 words. 47107 47108 A "Transparent" copy of the Document means a machine-readable copy, 47109 represented in a format whose specification is available to the 47110 general public, that is suitable for revising the document 47111 straightforwardly with generic text editors or (for images composed 47112 of pixels) generic paint programs or (for drawings) some widely 47113 available drawing editor, and that is suitable for input to text 47114 formatters or for automatic translation to a variety of formats 47115 suitable for input to text formatters. A copy made in an otherwise 47116 Transparent file format whose markup, or absence of markup, has 47117 been arranged to thwart or discourage subsequent modification by 47118 readers is not Transparent. An image format is not Transparent if 47119 used for any substantial amount of text. A copy that is not 47120 "Transparent" is called "Opaque". 47121 47122 Examples of suitable formats for Transparent copies include plain 47123 ASCII without markup, Texinfo input format, LaTeX input format, 47124 SGML or XML using a publicly available DTD, and standard-conforming 47125 simple HTML, PostScript or PDF designed for human modification. 47126 Examples of transparent image formats include PNG, XCF and JPG. 47127 Opaque formats include proprietary formats that can be read and 47128 edited only by proprietary word processors, SGML or XML for which 47129 the DTD and/or processing tools are not generally available, and 47130 the machine-generated HTML, PostScript or PDF produced by some word 47131 processors for output purposes only. 47132 47133 The "Title Page" means, for a printed book, the title page itself, 47134 plus such following pages as are needed to hold, legibly, the 47135 material this License requires to appear in the title page. For 47136 works in formats which do not have any title page as such, "Title 47137 Page" means the text near the most prominent appearance of the 47138 work's title, preceding the beginning of the body of the text. 47139 47140 The "publisher" means any person or entity that distributes copies 47141 of the Document to the public. 47142 47143 A section "Entitled XYZ" means a named subunit of the Document 47144 whose title either is precisely XYZ or contains XYZ in parentheses 47145 following text that translates XYZ in another language. (Here XYZ 47146 stands for a specific section name mentioned below, such as 47147 "Acknowledgements", "Dedications", "Endorsements", or "History".) 47148 To "Preserve the Title" of such a section when you modify the 47149 Document means that it remains a section "Entitled XYZ" according 47150 to this definition. 47151 47152 The Document may include Warranty Disclaimers next to the notice 47153 which states that this License applies to the Document. These 47154 Warranty Disclaimers are considered to be included by reference in 47155 this License, but only as regards disclaiming warranties: any other 47156 implication that these Warranty Disclaimers may have is void and 47157 has no effect on the meaning of this License. 47158 47159 2. VERBATIM COPYING 47160 47161 You may copy and distribute the Document in any medium, either 47162 commercially or noncommercially, provided that this License, the 47163 copyright notices, and the license notice saying this License 47164 applies to the Document are reproduced in all copies, and that you 47165 add no other conditions whatsoever to those of this License. You 47166 may not use technical measures to obstruct or control the reading 47167 or further copying of the copies you make or distribute. However, 47168 you may accept compensation in exchange for copies. If you 47169 distribute a large enough number of copies you must also follow the 47170 conditions in section 3. 47171 47172 You may also lend copies, under the same conditions stated above, 47173 and you may publicly display copies. 47174 47175 3. COPYING IN QUANTITY 47176 47177 If you publish printed copies (or copies in media that commonly 47178 have printed covers) of the Document, numbering more than 100, and 47179 the Document's license notice requires Cover Texts, you must 47180 enclose the copies in covers that carry, clearly and legibly, all 47181 these Cover Texts: Front-Cover Texts on the front cover, and 47182 Back-Cover Texts on the back cover. Both covers must also clearly 47183 and legibly identify you as the publisher of these copies. The 47184 front cover must present the full title with all words of the title 47185 equally prominent and visible. You may add other material on the 47186 covers in addition. Copying with changes limited to the covers, as 47187 long as they preserve the title of the Document and satisfy these 47188 conditions, can be treated as verbatim copying in other respects. 47189 47190 If the required texts for either cover are too voluminous to fit 47191 legibly, you should put the first ones listed (as many as fit 47192 reasonably) on the actual cover, and continue the rest onto 47193 adjacent pages. 47194 47195 If you publish or distribute Opaque copies of the Document 47196 numbering more than 100, you must either include a machine-readable 47197 Transparent copy along with each Opaque copy, or state in or with 47198 each Opaque copy a computer-network location from which the general 47199 network-using public has access to download using public-standard 47200 network protocols a complete Transparent copy of the Document, free 47201 of added material. If you use the latter option, you must take 47202 reasonably prudent steps, when you begin distribution of Opaque 47203 copies in quantity, to ensure that this Transparent copy will 47204 remain thus accessible at the stated location until at least one 47205 year after the last time you distribute an Opaque copy (directly or 47206 through your agents or retailers) of that edition to the public. 47207 47208 It is requested, but not required, that you contact the authors of 47209 the Document well before redistributing any large number of copies, 47210 to give them a chance to provide you with an updated version of the 47211 Document. 47212 47213 4. MODIFICATIONS 47214 47215 You may copy and distribute a Modified Version of the Document 47216 under the conditions of sections 2 and 3 above, provided that you 47217 release the Modified Version under precisely this License, with the 47218 Modified Version filling the role of the Document, thus licensing 47219 distribution and modification of the Modified Version to whoever 47220 possesses a copy of it. In addition, you must do these things in 47221 the Modified Version: 47222 47223 A. Use in the Title Page (and on the covers, if any) a title 47224 distinct from that of the Document, and from those of previous 47225 versions (which should, if there were any, be listed in the 47226 History section of the Document). You may use the same title 47227 as a previous version if the original publisher of that 47228 version gives permission. 47229 47230 B. List on the Title Page, as authors, one or more persons or 47231 entities responsible for authorship of the modifications in 47232 the Modified Version, together with at least five of the 47233 principal authors of the Document (all of its principal 47234 authors, if it has fewer than five), unless they release you 47235 from this requirement. 47236 47237 C. State on the Title page the name of the publisher of the 47238 Modified Version, as the publisher. 47239 47240 D. Preserve all the copyright notices of the Document. 47241 47242 E. Add an appropriate copyright notice for your modifications 47243 adjacent to the other copyright notices. 47244 47245 F. Include, immediately after the copyright notices, a license 47246 notice giving the public permission to use the Modified 47247 Version under the terms of this License, in the form shown in 47248 the Addendum below. 47249 47250 G. Preserve in that license notice the full lists of Invariant 47251 Sections and required Cover Texts given in the Document's 47252 license notice. 47253 47254 H. Include an unaltered copy of this License. 47255 47256 I. Preserve the section Entitled "History", Preserve its Title, 47257 and add to it an item stating at least the title, year, new 47258 authors, and publisher of the Modified Version as given on the 47259 Title Page. If there is no section Entitled "History" in the 47260 Document, create one stating the title, year, authors, and 47261 publisher of the Document as given on its Title Page, then add 47262 an item describing the Modified Version as stated in the 47263 previous sentence. 47264 47265 J. Preserve the network location, if any, given in the Document 47266 for public access to a Transparent copy of the Document, and 47267 likewise the network locations given in the Document for 47268 previous versions it was based on. These may be placed in the 47269 "History" section. You may omit a network location for a work 47270 that was published at least four years before the Document 47271 itself, or if the original publisher of the version it refers 47272 to gives permission. 47273 47274 K. For any section Entitled "Acknowledgements" or "Dedications", 47275 Preserve the Title of the section, and preserve in the section 47276 all the substance and tone of each of the contributor 47277 acknowledgements and/or dedications given therein. 47278 47279 L. Preserve all the Invariant Sections of the Document, unaltered 47280 in their text and in their titles. Section numbers or the 47281 equivalent are not considered part of the section titles. 47282 47283 M. Delete any section Entitled "Endorsements". Such a section 47284 may not be included in the Modified Version. 47285 47286 N. Do not retitle any existing section to be Entitled 47287 "Endorsements" or to conflict in title with any Invariant 47288 Section. 47289 47290 O. Preserve any Warranty Disclaimers. 47291 47292 If the Modified Version includes new front-matter sections or 47293 appendices that qualify as Secondary Sections and contain no 47294 material copied from the Document, you may at your option designate 47295 some or all of these sections as invariant. To do this, add their 47296 titles to the list of Invariant Sections in the Modified Version's 47297 license notice. These titles must be distinct from any other 47298 section titles. 47299 47300 You may add a section Entitled "Endorsements", provided it contains 47301 nothing but endorsements of your Modified Version by various 47302 parties--for example, statements of peer review or that the text 47303 has been approved by an organization as the authoritative 47304 definition of a standard. 47305 47306 You may add a passage of up to five words as a Front-Cover Text, 47307 and a passage of up to 25 words as a Back-Cover Text, to the end of 47308 the list of Cover Texts in the Modified Version. Only one passage 47309 of Front-Cover Text and one of Back-Cover Text may be added by (or 47310 through arrangements made by) any one entity. If the Document 47311 already includes a cover text for the same cover, previously added 47312 by you or by arrangement made by the same entity you are acting on 47313 behalf of, you may not add another; but you may replace the old 47314 one, on explicit permission from the previous publisher that added 47315 the old one. 47316 47317 The author(s) and publisher(s) of the Document do not by this 47318 License give permission to use their names for publicity for or to 47319 assert or imply endorsement of any Modified Version. 47320 47321 5. COMBINING DOCUMENTS 47322 47323 You may combine the Document with other documents released under 47324 this License, under the terms defined in section 4 above for 47325 modified versions, provided that you include in the combination all 47326 of the Invariant Sections of all of the original documents, 47327 unmodified, and list them all as Invariant Sections of your 47328 combined work in its license notice, and that you preserve all 47329 their Warranty Disclaimers. 47330 47331 The combined work need only contain one copy of this License, and 47332 multiple identical Invariant Sections may be replaced with a single 47333 copy. If there are multiple Invariant Sections with the same name 47334 but different contents, make the title of each such section unique 47335 by adding at the end of it, in parentheses, the name of the 47336 original author or publisher of that section if known, or else a 47337 unique number. Make the same adjustment to the section titles in 47338 the list of Invariant Sections in the license notice of the 47339 combined work. 47340 47341 In the combination, you must combine any sections Entitled 47342 "History" in the various original documents, forming one section 47343 Entitled "History"; likewise combine any sections Entitled 47344 "Acknowledgements", and any sections Entitled "Dedications". You 47345 must delete all sections Entitled "Endorsements." 47346 47347 6. COLLECTIONS OF DOCUMENTS 47348 47349 You may make a collection consisting of the Document and other 47350 documents released under this License, and replace the individual 47351 copies of this License in the various documents with a single copy 47352 that is included in the collection, provided that you follow the 47353 rules of this License for verbatim copying of each of the documents 47354 in all other respects. 47355 47356 You may extract a single document from such a collection, and 47357 distribute it individually under this License, provided you insert 47358 a copy of this License into the extracted document, and follow this 47359 License in all other respects regarding verbatim copying of that 47360 document. 47361 47362 7. AGGREGATION WITH INDEPENDENT WORKS 47363 47364 A compilation of the Document or its derivatives with other 47365 separate and independent documents or works, in or on a volume of a 47366 storage or distribution medium, is called an "aggregate" if the 47367 copyright resulting from the compilation is not used to limit the 47368 legal rights of the compilation's users beyond what the individual 47369 works permit. When the Document is included in an aggregate, this 47370 License does not apply to the other works in the aggregate which 47371 are not themselves derivative works of the Document. 47372 47373 If the Cover Text requirement of section 3 is applicable to these 47374 copies of the Document, then if the Document is less than one half 47375 of the entire aggregate, the Document's Cover Texts may be placed 47376 on covers that bracket the Document within the aggregate, or the 47377 electronic equivalent of covers if the Document is in electronic 47378 form. Otherwise they must appear on printed covers that bracket 47379 the whole aggregate. 47380 47381 8. TRANSLATION 47382 47383 Translation is considered a kind of modification, so you may 47384 distribute translations of the Document under the terms of section 47385 4. Replacing Invariant Sections with translations requires special 47386 permission from their copyright holders, but you may include 47387 translations of some or all Invariant Sections in addition to the 47388 original versions of these Invariant Sections. You may include a 47389 translation of this License, and all the license notices in the 47390 Document, and any Warranty Disclaimers, provided that you also 47391 include the original English version of this License and the 47392 original versions of those notices and disclaimers. In case of a 47393 disagreement between the translation and the original version of 47394 this License or a notice or disclaimer, the original version will 47395 prevail. 47396 47397 If a section in the Document is Entitled "Acknowledgements", 47398 "Dedications", or "History", the requirement (section 4) to 47399 Preserve its Title (section 1) will typically require changing the 47400 actual title. 47401 47402 9. TERMINATION 47403 47404 You may not copy, modify, sublicense, or distribute the Document 47405 except as expressly provided under this License. Any attempt 47406 otherwise to copy, modify, sublicense, or distribute it is void, 47407 and will automatically terminate your rights under this License. 47408 47409 However, if you cease all violation of this License, then your 47410 license from a particular copyright holder is reinstated (a) 47411 provisionally, unless and until the copyright holder explicitly and 47412 finally terminates your license, and (b) permanently, if the 47413 copyright holder fails to notify you of the violation by some 47414 reasonable means prior to 60 days after the cessation. 47415 47416 Moreover, your license from a particular copyright holder is 47417 reinstated permanently if the copyright holder notifies you of the 47418 violation by some reasonable means, this is the first time you have 47419 received notice of violation of this License (for any work) from 47420 that copyright holder, and you cure the violation prior to 30 days 47421 after your receipt of the notice. 47422 47423 Termination of your rights under this section does not terminate 47424 the licenses of parties who have received copies or rights from you 47425 under this License. If your rights have been terminated and not 47426 permanently reinstated, receipt of a copy of some or all of the 47427 same material does not give you any rights to use it. 47428 47429 10. FUTURE REVISIONS OF THIS LICENSE 47430 47431 The Free Software Foundation may publish new, revised versions of 47432 the GNU Free Documentation License from time to time. Such new 47433 versions will be similar in spirit to the present version, but may 47434 differ in detail to address new problems or concerns. See 47435 <http://www.gnu.org/copyleft/>. 47436 47437 Each version of the License is given a distinguishing version 47438 number. If the Document specifies that a particular numbered 47439 version of this License "or any later version" applies to it, you 47440 have the option of following the terms and conditions either of 47441 that specified version or of any later version that has been 47442 published (not as a draft) by the Free Software Foundation. If the 47443 Document does not specify a version number of this License, you may 47444 choose any version ever published (not as a draft) by the Free 47445 Software Foundation. If the Document specifies that a proxy can 47446 decide which future versions of this License can be used, that 47447 proxy's public statement of acceptance of a version permanently 47448 authorizes you to choose that version for the Document. 47449 47450 11. RELICENSING 47451 47452 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 47453 World Wide Web server that publishes copyrightable works and also 47454 provides prominent facilities for anybody to edit those works. A 47455 public wiki that anybody can edit is an example of such a server. 47456 A "Massive Multiauthor Collaboration" (or "MMC") contained in the 47457 site means any set of copyrightable works thus published on the MMC 47458 site. 47459 47460 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 47461 license published by Creative Commons Corporation, a not-for-profit 47462 corporation with a principal place of business in San Francisco, 47463 California, as well as future copyleft versions of that license 47464 published by that same organization. 47465 47466 "Incorporate" means to publish or republish a Document, in whole or 47467 in part, as part of another Document. 47468 47469 An MMC is "eligible for relicensing" if it is licensed under this 47470 License, and if all works that were first published under this 47471 License somewhere other than this MMC, and subsequently 47472 incorporated in whole or in part into the MMC, (1) had no cover 47473 texts or invariant sections, and (2) were thus incorporated prior 47474 to November 1, 2008. 47475 47476 The operator of an MMC Site may republish an MMC contained in the 47477 site under CC-BY-SA on the same site at any time before August 1, 47478 2009, provided the MMC is eligible for relicensing. 47479 47480ADDENDUM: How to use this License for your documents 47481==================================================== 47482 47483To use this License in a document you have written, include a copy of 47484the License in the document and put the following copyright and license 47485notices just after the title page: 47486 47487 Copyright (C) YEAR YOUR NAME. 47488 Permission is granted to copy, distribute and/or modify this document 47489 under the terms of the GNU Free Documentation License, Version 1.3 47490 or any later version published by the Free Software Foundation; 47491 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 47492 Texts. A copy of the license is included in the section entitled ``GNU 47493 Free Documentation License''. 47494 47495 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 47496replace the "with...Texts." line with this: 47497 47498 with the Invariant Sections being LIST THEIR TITLES, with 47499 the Front-Cover Texts being LIST, and with the Back-Cover Texts 47500 being LIST. 47501 47502 If you have Invariant Sections without Cover Texts, or some other 47503combination of the three, merge those two alternatives to suit the 47504situation. 47505 47506 If your document contains nontrivial examples of program code, we 47507recommend releasing these examples in parallel under your choice of free 47508software license, such as the GNU General Public License, to permit 47509their use in free software. 47510 47511 47512File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 47513 47514Contributors to GCC 47515******************* 47516 47517The GCC project would like to thank its many contributors. Without them 47518the project would not have been nearly as successful as it has been. 47519Any omissions in this list are accidental. Feel free to contact 47520<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or 47521some of your contributions are not listed. Please keep this list in 47522alphabetical order. 47523 47524 * Analog Devices helped implement the support for complex data types 47525 and iterators. 47526 47527 * John David Anglin for threading-related fixes and improvements to 47528 libstdc++-v3, and the HP-UX port. 47529 47530 * James van Artsdalen wrote the code that makes efficient use of the 47531 Intel 80387 register stack. 47532 47533 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 47534 Series port. 47535 47536 * Alasdair Baird for various bug fixes. 47537 47538 * Giovanni Bajo for analyzing lots of complicated C++ problem 47539 reports. 47540 47541 * Peter Barada for his work to improve code generation for new 47542 ColdFire cores. 47543 47544 * Gerald Baumgartner added the signature extension to the C++ front 47545 end. 47546 47547 * Godmar Back for his Java improvements and encouragement. 47548 47549 * Scott Bambrough for help porting the Java compiler. 47550 47551 * Wolfgang Bangerth for processing tons of bug reports. 47552 47553 * Jon Beniston for his Microsoft Windows port of Java and port to 47554 Lattice Mico32. 47555 47556 * Daniel Berlin for better DWARF 2 support, faster/better 47557 optimizations, improved alias analysis, plus migrating GCC to 47558 Bugzilla. 47559 47560 * Geoff Berry for his Java object serialization work and various 47561 patches. 47562 47563 * David Binderman tests weekly snapshots of GCC trunk against Fedora 47564 Rawhide for several architectures. 47565 47566 * Laurynas Biveinis for memory management work and DJGPP port fixes. 47567 47568 * Uros Bizjak for the implementation of x87 math built-in functions 47569 and for various middle end and i386 back end improvements and bug 47570 fixes. 47571 47572 * Eric Blake for helping to make GCJ and libgcj conform to the 47573 specifications. 47574 47575 * Janne Blomqvist for contributions to GNU Fortran. 47576 47577 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 47578 other Java work. 47579 47580 * Segher Boessenkool for helping maintain the PowerPC port and the 47581 instruction combiner plus various contributions to the middle end. 47582 47583 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 47584 miscellaneous clean-ups. 47585 47586 * Steven Bosscher for integrating the GNU Fortran front end into GCC 47587 and for contributing to the tree-ssa branch. 47588 47589 * Eric Botcazou for fixing middle- and backend bugs left and right. 47590 47591 * Per Bothner for his direction via the steering committee and 47592 various improvements to the infrastructure for supporting new 47593 languages. Chill front end implementation. Initial 47594 implementations of cpplib, fix-header, config.guess, libio, and 47595 past C++ library (libg++) maintainer. Dreaming up, designing and 47596 implementing much of GCJ. 47597 47598 * Devon Bowen helped port GCC to the Tahoe. 47599 47600 * Don Bowman for mips-vxworks contributions. 47601 47602 * James Bowman for the FT32 port. 47603 47604 * Dave Brolley for work on cpplib and Chill. 47605 47606 * Paul Brook for work on the ARM architecture and maintaining GNU 47607 Fortran. 47608 47609 * Robert Brown implemented the support for Encore 32000 systems. 47610 47611 * Christian Bruel for improvements to local store elimination. 47612 47613 * Herman A.J. ten Brugge for various fixes. 47614 47615 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 47616 FAQ. 47617 47618 * Joe Buck for his direction via the steering committee from its 47619 creation to 2013. 47620 47621 * Iain Buclaw for the D frontend. 47622 47623 * Craig Burley for leadership of the G77 Fortran effort. 47624 47625 * Tobias Burnus for contributions to GNU Fortran. 47626 47627 * Stephan Buys for contributing Doxygen notes for libstdc++. 47628 47629 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 47630 to the C++ strings, streambufs and formatted I/O, hard detective 47631 work on the frustrating localization issues, and keeping up with 47632 the problem reports. 47633 47634 * John Carr for his alias work, SPARC hacking, infrastructure 47635 improvements, previous contributions to the steering committee, 47636 loop optimizations, etc. 47637 47638 * Stephane Carrez for 68HC11 and 68HC12 ports. 47639 47640 * Steve Chamberlain for support for the Renesas SH and H8 processors 47641 and the PicoJava processor, and for GCJ config fixes. 47642 47643 * Glenn Chambers for help with the GCJ FAQ. 47644 47645 * John-Marc Chandonia for various libgcj patches. 47646 47647 * Denis Chertykov for contributing and maintaining the AVR port, the 47648 first GCC port for an 8-bit architecture. 47649 47650 * Kito Cheng for his work on the RISC-V port, including bringing up 47651 the test suite and maintenance. 47652 47653 * Scott Christley for his Objective-C contributions. 47654 47655 * Eric Christopher for his Java porting help and clean-ups. 47656 47657 * Branko Cibej for more warning contributions. 47658 47659 * The GNU Classpath project for all of their merged runtime code. 47660 47661 * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work, 47662 '--help', and other random hacking. 47663 47664 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 47665 47666 * R. Kelley Cook for making GCC buildable from a read-only directory 47667 as well as other miscellaneous build process and documentation 47668 clean-ups. 47669 47670 * Ralf Corsepius for SH testing and minor bug fixing. 47671 47672 * Franc,ois-Xavier Coudert for contributions to GNU Fortran. 47673 47674 * Stan Cox for care and feeding of the x86 port and lots of behind 47675 the scenes hacking. 47676 47677 * Alex Crain provided changes for the 3b1. 47678 47679 * Ian Dall for major improvements to the NS32k port. 47680 47681 * Paul Dale for his work to add uClinux platform support to the m68k 47682 backend. 47683 47684 * Palmer Dabbelt for his work maintaining the RISC-V port. 47685 47686 * Dario Dariol contributed the four varieties of sample programs that 47687 print a copy of their source. 47688 47689 * Russell Davidson for fstream and stringstream fixes in libstdc++. 47690 47691 * Bud Davis for work on the G77 and GNU Fortran compilers. 47692 47693 * Mo DeJong for GCJ and libgcj bug fixes. 47694 47695 * Jerry DeLisle for contributions to GNU Fortran. 47696 47697 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 47698 various bug fixes, and the M32C, MeP, MSP430, and RL78 ports. 47699 47700 * Arnaud Desitter for helping to debug GNU Fortran. 47701 47702 * Gabriel Dos Reis for contributions to G++, contributions and 47703 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 47704 including 'valarray<>', 'complex<>', maintaining the numerics 47705 library (including that pesky '<limits>' :-) and keeping up-to-date 47706 anything to do with numbers. 47707 47708 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 47709 ISO C99 support, CFG dumping support, etc., plus support of the C++ 47710 runtime libraries including for all kinds of C interface issues, 47711 contributing and maintaining 'complex<>', sanity checking and 47712 disbursement, configuration architecture, libio maintenance, and 47713 early math work. 47714 47715 * Franc,ois Dumont for his work on libstdc++-v3, especially 47716 maintaining and improving 'debug-mode' and associative and 47717 unordered containers. 47718 47719 * Zdenek Dvorak for a new loop unroller and various fixes. 47720 47721 * Michael Eager for his work on the Xilinx MicroBlaze port. 47722 47723 * Richard Earnshaw for his ongoing work with the ARM. 47724 47725 * David Edelsohn for his direction via the steering committee, 47726 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 47727 loop changes, doing the entire AIX port of libstdc++ with his bare 47728 hands, and for ensuring GCC properly keeps working on AIX. 47729 47730 * Kevin Ediger for the floating point formatting of num_put::do_put 47731 in libstdc++. 47732 47733 * Phil Edwards for libstdc++ work including configuration hackery, 47734 documentation maintainer, chief breaker of the web pages, the 47735 occasional iostream bug fix, and work on shared library symbol 47736 versioning. 47737 47738 * Paul Eggert for random hacking all over GCC. 47739 47740 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 47741 configuration support for locales and fstream-related fixes. 47742 47743 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 47744 iostreams. 47745 47746 * Christian Ehrhardt for dealing with bug reports. 47747 47748 * Ben Elliston for his work to move the Objective-C runtime into its 47749 own subdirectory and for his work on autoconf. 47750 47751 * Revital Eres for work on the PowerPC 750CL port. 47752 47753 * Marc Espie for OpenBSD support. 47754 47755 * Doug Evans for much of the global optimization framework, arc, 47756 m32r, and SPARC work. 47757 47758 * Christopher Faylor for his work on the Cygwin port and for caring 47759 and feeding the gcc.gnu.org box and saving its users tons of spam. 47760 47761 * Fred Fish for BeOS support and Ada fixes. 47762 47763 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 47764 47765 * Peter Gerwinski for various bug fixes and the Pascal front end. 47766 47767 * Kaveh R. Ghazi for his direction via the steering committee, 47768 amazing work to make '-W -Wall -W* -Werror' useful, and testing GCC 47769 on a plethora of platforms. Kaveh extends his gratitude to the 47770 CAIP Center at Rutgers University for providing him with computing 47771 resources to work on Free Software from the late 1980s to 2010. 47772 47773 * John Gilmore for a donation to the FSF earmarked improving GNU 47774 Java. 47775 47776 * Judy Goldberg for c++ contributions. 47777 47778 * Torbjorn Granlund for various fixes and the c-torture testsuite, 47779 multiply- and divide-by-constant optimization, improved long long 47780 support, improved leaf function register allocation, and his 47781 direction via the steering committee. 47782 47783 * Jonny Grant for improvements to 'collect2's' '--help' 47784 documentation. 47785 47786 * Anthony Green for his '-Os' contributions, the moxie port, and Java 47787 front end work. 47788 47789 * Stu Grossman for gdb hacking, allowing GCJ developers to debug Java 47790 code. 47791 47792 * Michael K. Gschwind contributed the port to the PDP-11. 47793 47794 * Richard Biener for his ongoing middle-end contributions and bug 47795 fixes and for release management. 47796 47797 * Ron Guilmette implemented the 'protoize' and 'unprotoize' tools, 47798 the support for DWARF 1 symbolic debugging information, and much of 47799 the support for System V Release 4. He has also worked heavily on 47800 the Intel 386 and 860 support. 47801 47802 * Sumanth Gundapaneni for contributing the CR16 port. 47803 47804 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 47805 GCSE. 47806 47807 * Bruno Haible for improvements in the runtime overhead for EH, new 47808 warnings and assorted bug fixes. 47809 47810 * Andrew Haley for his amazing Java compiler and library efforts. 47811 47812 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 47813 series 300. 47814 47815 * Michael Hayes for various thankless work he's done trying to get 47816 the c30/c40 ports functional. Lots of loop and unroll improvements 47817 and fixes. 47818 47819 * Dara Hazeghi for wading through myriads of target-specific bug 47820 reports. 47821 47822 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 47823 47824 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 47825 work, loop opts, and generally fixing lots of old problems we've 47826 ignored for years, flow rewrite and lots of further stuff, 47827 including reviewing tons of patches. 47828 47829 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 47830 various fixes. 47831 47832 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 47833 contributed the support for the Sony NEWS machine. 47834 47835 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 47836 various fixes. 47837 47838 * Katherine Holcomb for work on GNU Fortran. 47839 47840 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 47841 of testing and bug fixing, particularly of GCC configury code. 47842 47843 * Steve Holmgren for MachTen patches. 47844 47845 * Mat Hostetter for work on the TILE-Gx and TILEPro ports. 47846 47847 * Jan Hubicka for his x86 port improvements. 47848 47849 * Falk Hueffner for working on C and optimization bug reports. 47850 47851 * Bernardo Innocenti for his m68k work, including merging of ColdFire 47852 improvements and uClinux support. 47853 47854 * Christian Iseli for various bug fixes. 47855 47856 * Kamil Iskra for general m68k hacking. 47857 47858 * Lee Iverson for random fixes and MIPS testing. 47859 47860 * Balaji V. Iyer for Cilk+ development and merging. 47861 47862 * Andreas Jaeger for testing and benchmarking of GCC and various bug 47863 fixes. 47864 47865 * Martin Jambor for his work on inter-procedural optimizations, the 47866 switch conversion pass, and scalar replacement of aggregates. 47867 47868 * Jakub Jelinek for his SPARC work and sibling call optimizations as 47869 well as lots of bug fixes and test cases, and for improving the 47870 Java build system. 47871 47872 * Janis Johnson for ia64 testing and fixes, her quality improvement 47873 sidetracks, and web page maintenance. 47874 47875 * Kean Johnston for SCO OpenServer support and various fixes. 47876 47877 * Tim Josling for the sample language treelang based originally on 47878 Richard Kenner's "toy" language. 47879 47880 * Nicolai Josuttis for additional libstdc++ documentation. 47881 47882 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 47883 target. 47884 47885 * Steven G. Kargl for work on GNU Fortran. 47886 47887 * David Kashtan of SRI adapted GCC to VMS. 47888 47889 * Ryszard Kabatek for many, many libstdc++ bug fixes and 47890 optimizations of strings, especially member functions, and for 47891 auto_ptr fixes. 47892 47893 * Geoffrey Keating for his ongoing work to make the PPC work for 47894 GNU/Linux and his automatic regression tester. 47895 47896 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 47897 work in just about every part of libstdc++. 47898 47899 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 47900 MIL-STD-1750A. 47901 47902 * Richard Kenner of the New York University Ultracomputer Research 47903 Laboratory wrote the machine descriptions for the AMD 29000, the 47904 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 47905 support for instruction attributes. He also made changes to better 47906 support RISC processors including changes to common subexpression 47907 elimination, strength reduction, function calling sequence 47908 handling, and condition code support, in addition to generalizing 47909 the code for frame pointer elimination and delay slot scheduling. 47910 Richard Kenner was also the head maintainer of GCC for several 47911 years. 47912 47913 * Mumit Khan for various contributions to the Cygwin and Mingw32 47914 ports and maintaining binary releases for Microsoft Windows hosts, 47915 and for massive libstdc++ porting work to Cygwin/Mingw32. 47916 47917 * Robin Kirkham for cpu32 support. 47918 47919 * Mark Klein for PA improvements. 47920 47921 * Thomas Koenig for various bug fixes. 47922 47923 * Bruce Korb for the new and improved fixincludes code. 47924 47925 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 47926 effort. 47927 47928 * Maxim Kuvyrkov for contributions to the instruction scheduler, the 47929 Android and m68k/Coldfire ports, and optimizations. 47930 47931 * Charles LaBrec contributed the support for the Integrated Solutions 47932 68020 system. 47933 47934 * Asher Langton and Mike Kumbera for contributing Cray pointer 47935 support to GNU Fortran, and for other GNU Fortran improvements. 47936 47937 * Jeff Law for his direction via the steering committee, coordinating 47938 the entire egcs project and GCC 2.95, rolling out snapshots and 47939 releases, handling merges from GCC2, reviewing tons of patches that 47940 might have fallen through the cracks else, and random but extensive 47941 hacking. 47942 47943 * Walter Lee for work on the TILE-Gx and TILEPro ports. 47944 47945 * Marc Lehmann for his direction via the steering committee and 47946 helping with analysis and improvements of x86 performance. 47947 47948 * Victor Leikehman for work on GNU Fortran. 47949 47950 * Ted Lemon wrote parts of the RTL reader and printer. 47951 47952 * Kriang Lerdsuwanakij for C++ improvements including template as 47953 template parameter support, and many C++ fixes. 47954 47955 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 47956 and random work on the Java front end. 47957 47958 * Alain Lichnewsky ported GCC to the MIPS CPU. 47959 47960 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 47961 and patches. 47962 47963 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 47964 47965 * Chen Liqin for various S+core related fixes/improvement, and for 47966 maintaining the S+core port. 47967 47968 * Martin Liska for his work on identical code folding, the 47969 sanitizers, HSA, general bug fixing and for running automated 47970 regression testing of GCC and reporting numerous bugs. 47971 47972 * Weiwen Liu for testing and various bug fixes. 47973 47974 * Manuel Lo'pez-Iba'n~ez for improving '-Wconversion' and many other 47975 diagnostics fixes and improvements. 47976 47977 * Dave Love for his ongoing work with the Fortran front end and 47978 runtime libraries. 47979 47980 * Martin von Lo"wis for internal consistency checking infrastructure, 47981 various C++ improvements including namespace support, and tons of 47982 assistance with libstdc++/compiler merges. 47983 47984 * H.J. Lu for his previous contributions to the steering committee, 47985 many x86 bug reports, prototype patches, and keeping the GNU/Linux 47986 ports working. 47987 47988 * Greg McGary for random fixes and (someday) bounded pointers. 47989 47990 * Andrew MacLeod for his ongoing work in building a real EH system, 47991 various code generation improvements, work on the global optimizer, 47992 etc. 47993 47994 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 47995 hacking improvements to compile-time performance, overall knowledge 47996 and direction in the area of instruction scheduling, design and 47997 implementation of the automaton based instruction scheduler and 47998 design and implementation of the integrated and local register 47999 allocators. 48000 48001 * David Malcolm for his work on improving GCC diagnostics, JIT, 48002 self-tests and unit testing. 48003 48004 * Bob Manson for his behind the scenes work on dejagnu. 48005 48006 * John Marino for contributing the DragonFly BSD port. 48007 48008 * Philip Martin for lots of libstdc++ string and vector iterator 48009 fixes and improvements, and string clean up and testsuites. 48010 48011 * Michael Matz for his work on dominance tree discovery, the x86-64 48012 port, link-time optimization framework and general optimization 48013 improvements. 48014 48015 * All of the Mauve project contributors for Java test code. 48016 48017 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 48018 48019 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 48020 48021 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 48022 powerpc, haifa, ECOFF debug support, and other assorted hacking. 48023 48024 * Jason Merrill for his direction via the steering committee and 48025 leading the G++ effort. 48026 48027 * Martin Michlmayr for testing GCC on several architectures using the 48028 entire Debian archive. 48029 48030 * David Miller for his direction via the steering committee, lots of 48031 SPARC work, improvements in jump.c and interfacing with the Linux 48032 kernel developers. 48033 48034 * Gary Miller ported GCC to Charles River Data Systems machines. 48035 48036 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 48037 the entire libstdc++ testsuite namespace-compatible. 48038 48039 * Mark Mitchell for his direction via the steering committee, 48040 mountains of C++ work, load/store hoisting out of loops, alias 48041 analysis improvements, ISO C 'restrict' support, and serving as 48042 release manager from 2000 to 2011. 48043 48044 * Alan Modra for various GNU/Linux bits and testing. 48045 48046 * Toon Moene for his direction via the steering committee, Fortran 48047 maintenance, and his ongoing work to make us make Fortran run fast. 48048 48049 * Jason Molenda for major help in the care and feeding of all the 48050 services on the gcc.gnu.org (formerly egcs.cygnus.com) 48051 machine--mail, web services, ftp services, etc etc. Doing all this 48052 work on scrap paper and the backs of envelopes would have been... 48053 difficult. 48054 48055 * Catherine Moore for fixing various ugly problems we have sent her 48056 way, including the haifa bug which was killing the Alpha & PowerPC 48057 Linux kernels. 48058 48059 * Mike Moreton for his various Java patches. 48060 48061 * David Mosberger-Tang for various Alpha improvements, and for the 48062 initial IA-64 port. 48063 48064 * Stephen Moshier contributed the floating point emulator that 48065 assists in cross-compilation and permits support for floating point 48066 numbers wider than 64 bits and for ISO C99 support. 48067 48068 * Bill Moyer for his behind the scenes work on various issues. 48069 48070 * Philippe De Muyter for his work on the m68k port. 48071 48072 * Joseph S. Myers for his work on the PDP-11 port, format checking 48073 and ISO C99 support, and continuous emphasis on (and contributions 48074 to) documentation. 48075 48076 * Nathan Myers for his work on libstdc++-v3: architecture and 48077 authorship through the first three snapshots, including 48078 implementation of locale infrastructure, string, shadow C headers, 48079 and the initial project documentation (DESIGN, CHECKLIST, and so 48080 forth). Later, more work on MT-safe string and shadow headers. 48081 48082 * Felix Natter for documentation on porting libstdc++. 48083 48084 * Nathanael Nerode for cleaning up the configuration/build process. 48085 48086 * NeXT, Inc. donated the front end that supports the Objective-C 48087 language. 48088 48089 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the 48090 search engine setup, various documentation fixes and other small 48091 fixes. 48092 48093 * Geoff Noer for his work on getting cygwin native builds working. 48094 48095 * Vegard Nossum for running automated regression testing of GCC and 48096 reporting numerous bugs. 48097 48098 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 48099 tracking web pages, GIMPLE tuples, and assorted fixes. 48100 48101 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 48102 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related 48103 infrastructure improvements. 48104 48105 * Alexandre Oliva for various build infrastructure improvements, 48106 scripts and amazing testing work, including keeping libtool issues 48107 sane and happy. 48108 48109 * Stefan Olsson for work on mt_alloc. 48110 48111 * Melissa O'Neill for various NeXT fixes. 48112 48113 * Rainer Orth for random MIPS work, including improvements to GCC's 48114 o32 ABI support, improvements to dejagnu's MIPS support, Java 48115 configuration clean-ups and porting work, and maintaining the IRIX, 48116 Solaris 2, and Tru64 UNIX ports. 48117 48118 * Steven Pemberton for his contribution of 'enquire' which allowed 48119 GCC to determine various properties of the floating point unit and 48120 generate 'float.h' in older versions of GCC. 48121 48122 * Hartmut Penner for work on the s390 port. 48123 48124 * Paul Petersen wrote the machine description for the Alliant FX/8. 48125 48126 * Alexandre Petit-Bianco for implementing much of the Java compiler 48127 and continued Java maintainership. 48128 48129 * Matthias Pfaller for major improvements to the NS32k port. 48130 48131 * Gerald Pfeifer for his direction via the steering committee, 48132 pointing out lots of problems we need to solve, maintenance of the 48133 web pages, and taking care of documentation maintenance in general. 48134 48135 * Marek Polacek for his work on the C front end, the sanitizers and 48136 general bug fixing. 48137 48138 * Andrew Pinski for processing bug reports by the dozen. 48139 48140 * Ovidiu Predescu for his work on the Objective-C front end and 48141 runtime libraries. 48142 48143 * Jerry Quinn for major performance improvements in C++ formatted 48144 I/O. 48145 48146 * Ken Raeburn for various improvements to checker, MIPS ports and 48147 various cleanups in the compiler. 48148 48149 * Rolf W. Rasmussen for hacking on AWT. 48150 48151 * David Reese of Sun Microsystems contributed to the Solaris on 48152 PowerPC port. 48153 48154 * John Regehr for running automated regression testing of GCC and 48155 reporting numerous bugs. 48156 48157 * Volker Reichelt for running automated regression testing of GCC and 48158 reporting numerous bugs and for keeping up with the problem 48159 reports. 48160 48161 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 48162 hacking and developing and maintaining the Epiphany port. 48163 48164 * Loren J. Rittle for improvements to libstdc++-v3 including the 48165 FreeBSD port, threading fixes, thread-related configury changes, 48166 critical threading documentation, and solutions to really tricky 48167 I/O problems, as well as keeping GCC properly working on FreeBSD 48168 and continuous testing. 48169 48170 * Craig Rodrigues for processing tons of bug reports. 48171 48172 * Ola Ro"nnerup for work on mt_alloc. 48173 48174 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 48175 48176 * David Ronis inspired and encouraged Craig to rewrite the G77 48177 documentation in texinfo format by contributing a first pass at a 48178 translation of the old 'g77-0.5.16/f/DOC' file. 48179 48180 * Ken Rose for fixes to GCC's delay slot filling code. 48181 48182 * Ira Rosen for her contributions to the auto-vectorizer. 48183 48184 * Paul Rubin wrote most of the preprocessor. 48185 48186 * Pe'tur Runo'lfsson for major performance improvements in C++ 48187 formatted I/O and large file support in C++ filebuf. 48188 48189 * Chip Salzenberg for libstdc++ patches and improvements to locales, 48190 traits, Makefiles, libio, libtool hackery, and "long long" support. 48191 48192 * Juha Sarlin for improvements to the H8 code generator. 48193 48194 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 48195 300. 48196 48197 * Roger Sayle for improvements to constant folding and GCC's RTL 48198 optimizers as well as for fixing numerous bugs. 48199 48200 * Bradley Schatz for his work on the GCJ FAQ. 48201 48202 * Peter Schauer wrote the code to allow debugging to work on the 48203 Alpha. 48204 48205 * William Schelter did most of the work on the Intel 80386 support. 48206 48207 * Tobias Schlu"ter for work on GNU Fortran. 48208 48209 * Bernd Schmidt for various code generation improvements and major 48210 work in the reload pass, serving as release manager for GCC 2.95.3, 48211 and work on the Blackfin and C6X ports. 48212 48213 * Peter Schmid for constant testing of libstdc++--especially 48214 application testing, going above and beyond what was requested for 48215 the release criteria--and libstdc++ header file tweaks. 48216 48217 * Jason Schroeder for jcf-dump patches. 48218 48219 * Andreas Schwab for his work on the m68k port. 48220 48221 * Lars Segerlund for work on GNU Fortran. 48222 48223 * Dodji Seketeli for numerous C++ bug fixes and debug info 48224 improvements. 48225 48226 * Tim Shen for major work on '<regex>'. 48227 48228 * Joel Sherrill for his direction via the steering committee, RTEMS 48229 contributions and RTEMS testing. 48230 48231 * Nathan Sidwell for many C++ fixes/improvements. 48232 48233 * Jeffrey Siegal for helping RMS with the original design of GCC, 48234 some code which handles the parse tree and RTL data structures, 48235 constant folding and help with the original VAX & m68k ports. 48236 48237 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 48238 from the LWG (thereby keeping GCC in line with updates from the 48239 ISO). 48240 48241 * Franz Sirl for his ongoing work with making the PPC port stable for 48242 GNU/Linux. 48243 48244 * Andrey Slepuhin for assorted AIX hacking. 48245 48246 * Trevor Smigiel for contributing the SPU port. 48247 48248 * Christopher Smith did the port for Convex machines. 48249 48250 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 48251 Retired from GCC maintainership August 2010, having mentored two 48252 new maintainers into the role. 48253 48254 * Randy Smith finished the Sun FPA support. 48255 48256 * Ed Smith-Rowland for his continuous work on libstdc++-v3, special 48257 functions, '<random>', and various improvements to C++11 features. 48258 48259 * Scott Snyder for queue, iterator, istream, and string fixes and 48260 libstdc++ testsuite entries. Also for providing the patch to G77 48261 to add rudimentary support for 'INTEGER*1', 'INTEGER*2', and 48262 'LOGICAL*1'. 48263 48264 * Zdenek Sojka for running automated regression testing of GCC and 48265 reporting numerous bugs. 48266 48267 * Arseny Solokha for running automated regression testing of GCC and 48268 reporting numerous bugs. 48269 48270 * Jayant Sonar for contributing the CR16 port. 48271 48272 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 48273 48274 * Richard Stallman, for writing the original GCC and launching the 48275 GNU project. 48276 48277 * Jan Stein of the Chalmers Computer Society provided support for 48278 Genix, as well as part of the 32000 machine description. 48279 48280 * Gerhard Steinmetz for running automated regression testing of GCC 48281 and reporting numerous bugs. 48282 48283 * Nigel Stephens for various mips16 related fixes/improvements. 48284 48285 * Jonathan Stone wrote the machine description for the Pyramid 48286 computer. 48287 48288 * Graham Stott for various infrastructure improvements. 48289 48290 * John Stracke for his Java HTTP protocol fixes. 48291 48292 * Mike Stump for his Elxsi port, G++ contributions over the years and 48293 more recently his vxworks contributions 48294 48295 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 48296 48297 * Zhendong Su for running automated regression testing of GCC and 48298 reporting numerous bugs. 48299 48300 * Chengnian Sun for running automated regression testing of GCC and 48301 reporting numerous bugs. 48302 48303 * Shigeya Suzuki for this fixes for the bsdi platforms. 48304 48305 * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64 48306 support, general configury hacking, fixincludes, etc. 48307 48308 * Holger Teutsch provided the support for the Clipper CPU. 48309 48310 * Gary Thomas for his ongoing work to make the PPC work for 48311 GNU/Linux. 48312 48313 * Paul Thomas for contributions to GNU Fortran. 48314 48315 * Philipp Thomas for random bug fixes throughout the compiler 48316 48317 * Jason Thorpe for thread support in libstdc++ on NetBSD. 48318 48319 * Kresten Krab Thorup wrote the run time support for the Objective-C 48320 language and the fantastic Java bytecode interpreter. 48321 48322 * Michael Tiemann for random bug fixes, the first instruction 48323 scheduler, initial C++ support, function integration, NS32k, SPARC 48324 and M88k machine description work, delay slot scheduling. 48325 48326 * Andreas Tobler for his work porting libgcj to Darwin. 48327 48328 * Teemu Torma for thread safe exception handling support. 48329 48330 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 48331 definitions, and of the VAX machine description. 48332 48333 * Daniel Towner and Hariharan Sandanagobalane contributed and 48334 maintain the picoChip port. 48335 48336 * Tom Tromey for internationalization support and for his many Java 48337 contributions and libgcj maintainership. 48338 48339 * Lassi Tuura for improvements to config.guess to determine HP 48340 processor types. 48341 48342 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 48343 48344 * Andy Vaught for the design and initial implementation of the GNU 48345 Fortran front end. 48346 48347 * Brent Verner for work with the libstdc++ cshadow files and their 48348 associated configure steps. 48349 48350 * Todd Vierling for contributions for NetBSD ports. 48351 48352 * Andrew Waterman for contributing the RISC-V port, as well as 48353 maintaining it. 48354 48355 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 48356 guidance and maintaining libstdc++. 48357 48358 * Dean Wakerley for converting the install documentation from HTML to 48359 texinfo in time for GCC 3.0. 48360 48361 * Krister Walfridsson for random bug fixes. 48362 48363 * Feng Wang for contributions to GNU Fortran. 48364 48365 * Stephen M. Webb for time and effort on making libstdc++ shadow 48366 files work with the tricky Solaris 8+ headers, and for pushing the 48367 build-time header tree. Also, for starting and driving the 48368 '<regex>' effort. 48369 48370 * John Wehle for various improvements for the x86 code generator, 48371 related infrastructure improvements to help x86 code generation, 48372 value range propagation and other work, WE32k port. 48373 48374 * Ulrich Weigand for work on the s390 port. 48375 48376 * Janus Weil for contributions to GNU Fortran. 48377 48378 * Zack Weinberg for major work on cpplib and various other bug fixes. 48379 48380 * Matt Welsh for help with Linux Threads support in GCJ. 48381 48382 * Urban Widmark for help fixing java.io. 48383 48384 * Mark Wielaard for new Java library code and his work integrating 48385 with Classpath. 48386 48387 * Dale Wiles helped port GCC to the Tahoe. 48388 48389 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 48390 48391 * Jim Wilson for his direction via the steering committee, tackling 48392 hard problems in various places that nobody else wanted to work on, 48393 strength reduction and other loop optimizations. 48394 48395 * Paul Woegerer and Tal Agmon for the CRX port. 48396 48397 * Carlo Wood for various fixes. 48398 48399 * Tom Wood for work on the m88k port. 48400 48401 * Chung-Ju Wu for his work on the Andes NDS32 port. 48402 48403 * Canqun Yang for work on GNU Fortran. 48404 48405 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 48406 description for the Tron architecture (specifically, the Gmicro). 48407 48408 * Kevin Zachmann helped port GCC to the Tahoe. 48409 48410 * Ayal Zaks for Swing Modulo Scheduling (SMS). 48411 48412 * Qirun Zhang for running automated regression testing of GCC and 48413 reporting numerous bugs. 48414 48415 * Xiaoqiang Zhang for work on GNU Fortran. 48416 48417 * Gilles Zunino for help porting Java to Irix. 48418 48419 The following people are recognized for their contributions to GNAT, 48420the Ada front end of GCC: 48421 * Bernard Banner 48422 48423 * Romain Berrendonner 48424 48425 * Geert Bosch 48426 48427 * Emmanuel Briot 48428 48429 * Joel Brobecker 48430 48431 * Ben Brosgol 48432 48433 * Vincent Celier 48434 48435 * Arnaud Charlet 48436 48437 * Chien Chieng 48438 48439 * Cyrille Comar 48440 48441 * Cyrille Crozes 48442 48443 * Robert Dewar 48444 48445 * Gary Dismukes 48446 48447 * Robert Duff 48448 48449 * Ed Falis 48450 48451 * Ramon Fernandez 48452 48453 * Sam Figueroa 48454 48455 * Vasiliy Fofanov 48456 48457 * Michael Friess 48458 48459 * Franco Gasperoni 48460 48461 * Ted Giering 48462 48463 * Matthew Gingell 48464 48465 * Laurent Guerby 48466 48467 * Jerome Guitton 48468 48469 * Olivier Hainque 48470 48471 * Jerome Hugues 48472 48473 * Hristian Kirtchev 48474 48475 * Jerome Lambourg 48476 48477 * Bruno Leclerc 48478 48479 * Albert Lee 48480 48481 * Sean McNeil 48482 48483 * Javier Miranda 48484 48485 * Laurent Nana 48486 48487 * Pascal Obry 48488 48489 * Dong-Ik Oh 48490 48491 * Laurent Pautet 48492 48493 * Brett Porter 48494 48495 * Thomas Quinot 48496 48497 * Nicolas Roche 48498 48499 * Pat Rogers 48500 48501 * Jose Ruiz 48502 48503 * Douglas Rupp 48504 48505 * Sergey Rybin 48506 48507 * Gail Schenker 48508 48509 * Ed Schonberg 48510 48511 * Nicolas Setton 48512 48513 * Samuel Tardieu 48514 48515 The following people are recognized for their contributions of new 48516features, bug reports, testing and integration of classpath/libgcj for 48517GCC version 4.1: 48518 * Lillian Angel for 'JTree' implementation and lots Free Swing 48519 additions and bug fixes. 48520 48521 * Wolfgang Baer for 'GapContent' bug fixes. 48522 48523 * Anthony Balkissoon for 'JList', Free Swing 1.5 updates and mouse 48524 event fixes, lots of Free Swing work including 'JTable' editing. 48525 48526 * Stuart Ballard for RMI constant fixes. 48527 48528 * Goffredo Baroncelli for 'HTTPURLConnection' fixes. 48529 48530 * Gary Benson for 'MessageFormat' fixes. 48531 48532 * Daniel Bonniot for 'Serialization' fixes. 48533 48534 * Chris Burdess for lots of gnu.xml and http protocol fixes, 'StAX' 48535 and 'DOM xml:id' support. 48536 48537 * Ka-Hing Cheung for 'TreePath' and 'TreeSelection' fixes. 48538 48539 * Archie Cobbs for build fixes, VM interface updates, 48540 'URLClassLoader' updates. 48541 48542 * Kelley Cook for build fixes. 48543 48544 * Martin Cordova for Suggestions for better 'SocketTimeoutException'. 48545 48546 * David Daney for 'BitSet' bug fixes, 'HttpURLConnection' rewrite and 48547 improvements. 48548 48549 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 48550 2D support. Lots of imageio framework additions, lots of AWT and 48551 Free Swing bug fixes. 48552 48553 * Jeroen Frijters for 'ClassLoader' and nio cleanups, serialization 48554 fixes, better 'Proxy' support, bug fixes and IKVM integration. 48555 48556 * Santiago Gala for 'AccessControlContext' fixes. 48557 48558 * Nicolas Geoffray for 'VMClassLoader' and 'AccessController' 48559 improvements. 48560 48561 * David Gilbert for 'basic' and 'metal' icon and plaf support and 48562 lots of documenting, Lots of Free Swing and metal theme additions. 48563 'MetalIconFactory' implementation. 48564 48565 * Anthony Green for 'MIDI' framework, 'ALSA' and 'DSSI' providers. 48566 48567 * Andrew Haley for 'Serialization' and 'URLClassLoader' fixes, gcj 48568 build speedups. 48569 48570 * Kim Ho for 'JFileChooser' implementation. 48571 48572 * Andrew John Hughes for 'Locale' and net fixes, URI RFC2986 updates, 48573 'Serialization' fixes, 'Properties' XML support and generic branch 48574 work, VMIntegration guide update. 48575 48576 * Bastiaan Huisman for 'TimeZone' bug fixing. 48577 48578 * Andreas Jaeger for mprec updates. 48579 48580 * Paul Jenner for better '-Werror' support. 48581 48582 * Ito Kazumitsu for 'NetworkInterface' implementation and updates. 48583 48584 * Roman Kennke for 'BoxLayout', 'GrayFilter' and 'SplitPane', plus 48585 bug fixes all over. Lots of Free Swing work including styled text. 48586 48587 * Simon Kitching for 'String' cleanups and optimization suggestions. 48588 48589 * Michael Koch for configuration fixes, 'Locale' updates, bug and 48590 build fixes. 48591 48592 * Guilhem Lavaux for configuration, thread and channel fixes and 48593 Kaffe integration. JCL native 'Pointer' updates. Logger bug 48594 fixes. 48595 48596 * David Lichteblau for JCL support library global/local reference 48597 cleanups. 48598 48599 * Aaron Luchko for JDWP updates and documentation fixes. 48600 48601 * Ziga Mahkovec for 'Graphics2D' upgraded to Cairo 0.5 and new regex 48602 features. 48603 48604 * Sven de Marothy for BMP imageio support, CSS and 'TextLayout' 48605 fixes. 'GtkImage' rewrite, 2D, awt, free swing and date/time fixes 48606 and implementing the Qt4 peers. 48607 48608 * Casey Marshall for crypto algorithm fixes, 'FileChannel' lock, 48609 'SystemLogger' and 'FileHandler' rotate implementations, NIO 48610 'FileChannel.map' support, security and policy updates. 48611 48612 * Bryce McKinlay for RMI work. 48613 48614 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 48615 testing and documenting. 48616 48617 * Kalle Olavi Niemitalo for build fixes. 48618 48619 * Rainer Orth for build fixes. 48620 48621 * Andrew Overholt for 'File' locking fixes. 48622 48623 * Ingo Proetel for 'Image', 'Logger' and 'URLClassLoader' updates. 48624 48625 * Olga Rodimina for 'MenuSelectionManager' implementation. 48626 48627 * Jan Roehrich for 'BasicTreeUI' and 'JTree' fixes. 48628 48629 * Julian Scheid for documentation updates and gjdoc support. 48630 48631 * Christian Schlichtherle for zip fixes and cleanups. 48632 48633 * Robert Schuster for documentation updates and beans fixes, 48634 'TreeNode' enumerations and 'ActionCommand' and various fixes, XML 48635 and URL, AWT and Free Swing bug fixes. 48636 48637 * Keith Seitz for lots of JDWP work. 48638 48639 * Christian Thalinger for 64-bit cleanups, Configuration and VM 48640 interface fixes and 'CACAO' integration, 'fdlibm' updates. 48641 48642 * Gael Thomas for 'VMClassLoader' boot packages support suggestions. 48643 48644 * Andreas Tobler for Darwin and Solaris testing and fixing, 'Qt4' 48645 support for Darwin/OS X, 'Graphics2D' support, 'gtk+' updates. 48646 48647 * Dalibor Topic for better 'DEBUG' support, build cleanups and Kaffe 48648 integration. 'Qt4' build infrastructure, 'SHA1PRNG' and 48649 'GdkPixbugDecoder' updates. 48650 48651 * Tom Tromey for Eclipse integration, generics work, lots of bug 48652 fixes and gcj integration including coordinating The Big Merge. 48653 48654 * Mark Wielaard for bug fixes, packaging and release management, 48655 'Clipboard' implementation, system call interrupts and network 48656 timeouts and 'GdkPixpufDecoder' fixes. 48657 48658 In addition to the above, all of which also contributed time and energy 48659in testing GCC, we would like to thank the following for their 48660contributions to testing: 48661 48662 * Michael Abd-El-Malek 48663 48664 * Thomas Arend 48665 48666 * Bonzo Armstrong 48667 48668 * Steven Ashe 48669 48670 * Chris Baldwin 48671 48672 * David Billinghurst 48673 48674 * Jim Blandy 48675 48676 * Stephane Bortzmeyer 48677 48678 * Horst von Brand 48679 48680 * Frank Braun 48681 48682 * Rodney Brown 48683 48684 * Sidney Cadot 48685 48686 * Bradford Castalia 48687 48688 * Robert Clark 48689 48690 * Jonathan Corbet 48691 48692 * Ralph Doncaster 48693 48694 * Richard Emberson 48695 48696 * Levente Farkas 48697 48698 * Graham Fawcett 48699 48700 * Mark Fernyhough 48701 48702 * Robert A. French 48703 48704 * Jo"rgen Freyh 48705 48706 * Mark K. Gardner 48707 48708 * Charles-Antoine Gauthier 48709 48710 * Yung Shing Gene 48711 48712 * David Gilbert 48713 48714 * Simon Gornall 48715 48716 * Fred Gray 48717 48718 * John Griffin 48719 48720 * Patrik Hagglund 48721 48722 * Phil Hargett 48723 48724 * Amancio Hasty 48725 48726 * Takafumi Hayashi 48727 48728 * Bryan W. Headley 48729 48730 * Kevin B. Hendricks 48731 48732 * Joep Jansen 48733 48734 * Christian Joensson 48735 48736 * Michel Kern 48737 48738 * David Kidd 48739 48740 * Tobias Kuipers 48741 48742 * Anand Krishnaswamy 48743 48744 * A. O. V. Le Blanc 48745 48746 * llewelly 48747 48748 * Damon Love 48749 48750 * Brad Lucier 48751 48752 * Matthias Klose 48753 48754 * Martin Knoblauch 48755 48756 * Rick Lutowski 48757 48758 * Jesse Macnish 48759 48760 * Stefan Morrell 48761 48762 * Anon A. Mous 48763 48764 * Matthias Mueller 48765 48766 * Pekka Nikander 48767 48768 * Rick Niles 48769 48770 * Jon Olson 48771 48772 * Magnus Persson 48773 48774 * Chris Pollard 48775 48776 * Richard Polton 48777 48778 * Derk Reefman 48779 48780 * David Rees 48781 48782 * Paul Reilly 48783 48784 * Tom Reilly 48785 48786 * Torsten Rueger 48787 48788 * Danny Sadinoff 48789 48790 * Marc Schifer 48791 48792 * Erik Schnetter 48793 48794 * Wayne K. Schroll 48795 48796 * David Schuler 48797 48798 * Vin Shelton 48799 48800 * Tim Souder 48801 48802 * Adam Sulmicki 48803 48804 * Bill Thorson 48805 48806 * George Talbot 48807 48808 * Pedro A. M. Vazquez 48809 48810 * Gregory Warnes 48811 48812 * Ian Watson 48813 48814 * David E. Young 48815 48816 * And many others 48817 48818 And finally we'd like to thank everyone who uses the compiler, provides 48819feedback and generally reminds us why we're doing this work in the first 48820place. 48821 48822 48823File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 48824 48825Option Index 48826************ 48827 48828GCC's command line options are indexed here without any initial '-' or 48829'--'. Where an option has both positive and negative forms (such as 48830'-fOPTION' and '-fno-OPTION'), relevant entries in the manual are 48831indexed under the most appropriate form; it may sometimes be useful to 48832look up both forms. 48833 48834�[index�] 48835* Menu: 48836 48837* fltrans: Internal flags. (line 18) 48838* fltrans-output-list: Internal flags. (line 23) 48839* fresolution: Internal flags. (line 27) 48840* fwpa: Internal flags. (line 9) 48841* msoft-float: Soft float library routines. 48842 (line 6) 48843 48844 48845File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 48846 48847Concept Index 48848************* 48849 48850�[index�] 48851* Menu: 48852 48853* ! in constraint: Multi-Alternative. (line 48) 48854* # in constraint: Modifiers. (line 78) 48855* # in template: Output Template. (line 66) 48856* #pragma: Misc. (line 420) 48857* $ in constraint: Multi-Alternative. (line 57) 48858* % in constraint: Modifiers. (line 52) 48859* % in GTY option: GTY Options. (line 18) 48860* % in template: Output Template. (line 6) 48861* & in constraint: Modifiers. (line 25) 48862* (gimple: Logical Operators. (line 169) 48863* (gimple <1>: Logical Operators. (line 173) 48864* (gimple <2>: Logical Operators. (line 177) 48865* (gimple_stmt_iterator: GIMPLE API. (line 30) 48866* (nil): RTL Objects. (line 73) 48867* * in constraint: Modifiers. (line 83) 48868* * in template: Output Statement. (line 29) 48869* *gimple_build_asm_vec: GIMPLE_ASM. (line 6) 48870* *gimple_build_assign: GIMPLE_ASSIGN. (line 6) 48871* *gimple_build_assign <1>: GIMPLE_ASSIGN. (line 18) 48872* *gimple_build_assign <2>: GIMPLE_ASSIGN. (line 29) 48873* *gimple_build_assign <3>: GIMPLE_ASSIGN. (line 35) 48874* *gimple_build_bind: GIMPLE_BIND. (line 6) 48875* *gimple_build_call: GIMPLE_CALL. (line 6) 48876* *gimple_build_call_from_tree: GIMPLE_CALL. (line 15) 48877* *gimple_build_call_vec: GIMPLE_CALL. (line 25) 48878* *gimple_build_catch: GIMPLE_CATCH. (line 6) 48879* *gimple_build_cond: GIMPLE_COND. (line 6) 48880* *gimple_build_cond_from_tree: GIMPLE_COND. (line 14) 48881* *gimple_build_debug_bind: GIMPLE_DEBUG. (line 6) 48882* *gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 6) 48883* *gimple_build_goto: GIMPLE_GOTO. (line 6) 48884* *gimple_build_label: GIMPLE_LABEL. (line 6) 48885* *gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 48886 (line 6) 48887* *gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 48888 (line 6) 48889* *gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 48890 (line 6) 48891* *gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 48892 (line 6) 48893* *gimple_build_omp_for: GIMPLE_OMP_FOR. (line 6) 48894* *gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 48895 (line 6) 48896* *gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 48897 (line 6) 48898* *gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 6) 48899* *gimple_build_resx: GIMPLE_RESX. (line 6) 48900* *gimple_build_return: GIMPLE_RETURN. (line 6) 48901* *gimple_build_switch: GIMPLE_SWITCH. (line 6) 48902* *gimple_build_try: GIMPLE_TRY. (line 6) 48903* + in constraint: Modifiers. (line 12) 48904* -fsection-anchors: Special Accessors. (line 117) 48905* -fsection-anchors <1>: Anchored Addresses. (line 6) 48906* /c in RTL dump: Flags. (line 230) 48907* /f in RTL dump: Flags. (line 238) 48908* /i in RTL dump: Flags. (line 283) 48909* /j in RTL dump: Flags. (line 295) 48910* /s in RTL dump: Flags. (line 254) 48911* /u in RTL dump: Flags. (line 307) 48912* /v in RTL dump: Flags. (line 339) 48913* 0 in constraint: Simple Constraints. (line 128) 48914* < in constraint: Simple Constraints. (line 47) 48915* = in constraint: Modifiers. (line 8) 48916* > in constraint: Simple Constraints. (line 59) 48917* ? in constraint: Multi-Alternative. (line 42) 48918* @ in instruction pattern names: Parameterized Names. 48919 (line 6) 48920* \: Output Template. (line 46) 48921* ^ in constraint: Multi-Alternative. (line 53) 48922* __absvdi2: Integer library routines. 48923 (line 106) 48924* __absvsi2: Integer library routines. 48925 (line 105) 48926* __addda3: Fixed-point fractional library routines. 48927 (line 52) 48928* __adddf3: Soft float library routines. 48929 (line 22) 48930* __adddq3: Fixed-point fractional library routines. 48931 (line 39) 48932* __addha3: Fixed-point fractional library routines. 48933 (line 49) 48934* __addhq3: Fixed-point fractional library routines. 48935 (line 37) 48936* __addqq3: Fixed-point fractional library routines. 48937 (line 35) 48938* __addsa3: Fixed-point fractional library routines. 48939 (line 51) 48940* __addsf3: Soft float library routines. 48941 (line 21) 48942* __addsq3: Fixed-point fractional library routines. 48943 (line 38) 48944* __addta3: Fixed-point fractional library routines. 48945 (line 53) 48946* __addtf3: Soft float library routines. 48947 (line 23) 48948* __adduda3: Fixed-point fractional library routines. 48949 (line 59) 48950* __addudq3: Fixed-point fractional library routines. 48951 (line 47) 48952* __adduha3: Fixed-point fractional library routines. 48953 (line 55) 48954* __adduhq3: Fixed-point fractional library routines. 48955 (line 43) 48956* __adduqq3: Fixed-point fractional library routines. 48957 (line 41) 48958* __addusa3: Fixed-point fractional library routines. 48959 (line 57) 48960* __addusq3: Fixed-point fractional library routines. 48961 (line 45) 48962* __adduta3: Fixed-point fractional library routines. 48963 (line 61) 48964* __addvdi3: Integer library routines. 48965 (line 110) 48966* __addvsi3: Integer library routines. 48967 (line 109) 48968* __addxf3: Soft float library routines. 48969 (line 25) 48970* __ashlda3: Fixed-point fractional library routines. 48971 (line 358) 48972* __ashldi3: Integer library routines. 48973 (line 13) 48974* __ashldq3: Fixed-point fractional library routines. 48975 (line 346) 48976* __ashlha3: Fixed-point fractional library routines. 48977 (line 356) 48978* __ashlhq3: Fixed-point fractional library routines. 48979 (line 344) 48980* __ashlqq3: Fixed-point fractional library routines. 48981 (line 343) 48982* __ashlsa3: Fixed-point fractional library routines. 48983 (line 357) 48984* __ashlsi3: Integer library routines. 48985 (line 12) 48986* __ashlsq3: Fixed-point fractional library routines. 48987 (line 345) 48988* __ashlta3: Fixed-point fractional library routines. 48989 (line 359) 48990* __ashlti3: Integer library routines. 48991 (line 14) 48992* __ashluda3: Fixed-point fractional library routines. 48993 (line 365) 48994* __ashludq3: Fixed-point fractional library routines. 48995 (line 354) 48996* __ashluha3: Fixed-point fractional library routines. 48997 (line 361) 48998* __ashluhq3: Fixed-point fractional library routines. 48999 (line 350) 49000* __ashluqq3: Fixed-point fractional library routines. 49001 (line 348) 49002* __ashlusa3: Fixed-point fractional library routines. 49003 (line 363) 49004* __ashlusq3: Fixed-point fractional library routines. 49005 (line 352) 49006* __ashluta3: Fixed-point fractional library routines. 49007 (line 367) 49008* __ashrda3: Fixed-point fractional library routines. 49009 (line 378) 49010* __ashrdi3: Integer library routines. 49011 (line 18) 49012* __ashrdq3: Fixed-point fractional library routines. 49013 (line 374) 49014* __ashrha3: Fixed-point fractional library routines. 49015 (line 376) 49016* __ashrhq3: Fixed-point fractional library routines. 49017 (line 372) 49018* __ashrqq3: Fixed-point fractional library routines. 49019 (line 371) 49020* __ashrsa3: Fixed-point fractional library routines. 49021 (line 377) 49022* __ashrsi3: Integer library routines. 49023 (line 17) 49024* __ashrsq3: Fixed-point fractional library routines. 49025 (line 373) 49026* __ashrta3: Fixed-point fractional library routines. 49027 (line 379) 49028* __ashrti3: Integer library routines. 49029 (line 19) 49030* __bid_adddd3: Decimal float library routines. 49031 (line 23) 49032* __bid_addsd3: Decimal float library routines. 49033 (line 19) 49034* __bid_addtd3: Decimal float library routines. 49035 (line 27) 49036* __bid_divdd3: Decimal float library routines. 49037 (line 66) 49038* __bid_divsd3: Decimal float library routines. 49039 (line 62) 49040* __bid_divtd3: Decimal float library routines. 49041 (line 70) 49042* __bid_eqdd2: Decimal float library routines. 49043 (line 258) 49044* __bid_eqsd2: Decimal float library routines. 49045 (line 256) 49046* __bid_eqtd2: Decimal float library routines. 49047 (line 260) 49048* __bid_extendddtd2: Decimal float library routines. 49049 (line 91) 49050* __bid_extendddtf: Decimal float library routines. 49051 (line 139) 49052* __bid_extendddxf: Decimal float library routines. 49053 (line 133) 49054* __bid_extenddfdd: Decimal float library routines. 49055 (line 146) 49056* __bid_extenddftd: Decimal float library routines. 49057 (line 106) 49058* __bid_extendsddd2: Decimal float library routines. 49059 (line 87) 49060* __bid_extendsddf: Decimal float library routines. 49061 (line 127) 49062* __bid_extendsdtd2: Decimal float library routines. 49063 (line 89) 49064* __bid_extendsdtf: Decimal float library routines. 49065 (line 137) 49066* __bid_extendsdxf: Decimal float library routines. 49067 (line 131) 49068* __bid_extendsfdd: Decimal float library routines. 49069 (line 102) 49070* __bid_extendsfsd: Decimal float library routines. 49071 (line 144) 49072* __bid_extendsftd: Decimal float library routines. 49073 (line 104) 49074* __bid_extendtftd: Decimal float library routines. 49075 (line 148) 49076* __bid_extendxftd: Decimal float library routines. 49077 (line 108) 49078* __bid_fixdddi: Decimal float library routines. 49079 (line 169) 49080* __bid_fixddsi: Decimal float library routines. 49081 (line 161) 49082* __bid_fixsddi: Decimal float library routines. 49083 (line 167) 49084* __bid_fixsdsi: Decimal float library routines. 49085 (line 159) 49086* __bid_fixtddi: Decimal float library routines. 49087 (line 171) 49088* __bid_fixtdsi: Decimal float library routines. 49089 (line 163) 49090* __bid_fixunsdddi: Decimal float library routines. 49091 (line 186) 49092* __bid_fixunsddsi: Decimal float library routines. 49093 (line 177) 49094* __bid_fixunssddi: Decimal float library routines. 49095 (line 184) 49096* __bid_fixunssdsi: Decimal float library routines. 49097 (line 175) 49098* __bid_fixunstddi: Decimal float library routines. 49099 (line 188) 49100* __bid_fixunstdsi: Decimal float library routines. 49101 (line 179) 49102* __bid_floatdidd: Decimal float library routines. 49103 (line 204) 49104* __bid_floatdisd: Decimal float library routines. 49105 (line 202) 49106* __bid_floatditd: Decimal float library routines. 49107 (line 206) 49108* __bid_floatsidd: Decimal float library routines. 49109 (line 195) 49110* __bid_floatsisd: Decimal float library routines. 49111 (line 193) 49112* __bid_floatsitd: Decimal float library routines. 49113 (line 197) 49114* __bid_floatunsdidd: Decimal float library routines. 49115 (line 222) 49116* __bid_floatunsdisd: Decimal float library routines. 49117 (line 220) 49118* __bid_floatunsditd: Decimal float library routines. 49119 (line 224) 49120* __bid_floatunssidd: Decimal float library routines. 49121 (line 213) 49122* __bid_floatunssisd: Decimal float library routines. 49123 (line 211) 49124* __bid_floatunssitd: Decimal float library routines. 49125 (line 215) 49126* __bid_gedd2: Decimal float library routines. 49127 (line 276) 49128* __bid_gesd2: Decimal float library routines. 49129 (line 274) 49130* __bid_getd2: Decimal float library routines. 49131 (line 278) 49132* __bid_gtdd2: Decimal float library routines. 49133 (line 303) 49134* __bid_gtsd2: Decimal float library routines. 49135 (line 301) 49136* __bid_gttd2: Decimal float library routines. 49137 (line 305) 49138* __bid_ledd2: Decimal float library routines. 49139 (line 294) 49140* __bid_lesd2: Decimal float library routines. 49141 (line 292) 49142* __bid_letd2: Decimal float library routines. 49143 (line 296) 49144* __bid_ltdd2: Decimal float library routines. 49145 (line 285) 49146* __bid_ltsd2: Decimal float library routines. 49147 (line 283) 49148* __bid_lttd2: Decimal float library routines. 49149 (line 287) 49150* __bid_muldd3: Decimal float library routines. 49151 (line 52) 49152* __bid_mulsd3: Decimal float library routines. 49153 (line 48) 49154* __bid_multd3: Decimal float library routines. 49155 (line 56) 49156* __bid_nedd2: Decimal float library routines. 49157 (line 267) 49158* __bid_negdd2: Decimal float library routines. 49159 (line 77) 49160* __bid_negsd2: Decimal float library routines. 49161 (line 75) 49162* __bid_negtd2: Decimal float library routines. 49163 (line 79) 49164* __bid_nesd2: Decimal float library routines. 49165 (line 265) 49166* __bid_netd2: Decimal float library routines. 49167 (line 269) 49168* __bid_subdd3: Decimal float library routines. 49169 (line 37) 49170* __bid_subsd3: Decimal float library routines. 49171 (line 33) 49172* __bid_subtd3: Decimal float library routines. 49173 (line 41) 49174* __bid_truncdddf: Decimal float library routines. 49175 (line 152) 49176* __bid_truncddsd2: Decimal float library routines. 49177 (line 93) 49178* __bid_truncddsf: Decimal float library routines. 49179 (line 123) 49180* __bid_truncdfsd: Decimal float library routines. 49181 (line 110) 49182* __bid_truncsdsf: Decimal float library routines. 49183 (line 150) 49184* __bid_trunctddd2: Decimal float library routines. 49185 (line 97) 49186* __bid_trunctddf: Decimal float library routines. 49187 (line 129) 49188* __bid_trunctdsd2: Decimal float library routines. 49189 (line 95) 49190* __bid_trunctdsf: Decimal float library routines. 49191 (line 125) 49192* __bid_trunctdtf: Decimal float library routines. 49193 (line 154) 49194* __bid_trunctdxf: Decimal float library routines. 49195 (line 135) 49196* __bid_trunctfdd: Decimal float library routines. 49197 (line 118) 49198* __bid_trunctfsd: Decimal float library routines. 49199 (line 114) 49200* __bid_truncxfdd: Decimal float library routines. 49201 (line 116) 49202* __bid_truncxfsd: Decimal float library routines. 49203 (line 112) 49204* __bid_unorddd2: Decimal float library routines. 49205 (line 234) 49206* __bid_unordsd2: Decimal float library routines. 49207 (line 232) 49208* __bid_unordtd2: Decimal float library routines. 49209 (line 236) 49210* __bswapdi2: Integer library routines. 49211 (line 161) 49212* __bswapsi2: Integer library routines. 49213 (line 160) 49214* __builtin_classify_type: Varargs. (line 48) 49215* __builtin_next_arg: Varargs. (line 39) 49216* __builtin_saveregs: Varargs. (line 22) 49217* __clear_cache: Miscellaneous routines. 49218 (line 9) 49219* __clzdi2: Integer library routines. 49220 (line 130) 49221* __clzsi2: Integer library routines. 49222 (line 129) 49223* __clzti2: Integer library routines. 49224 (line 131) 49225* __cmpda2: Fixed-point fractional library routines. 49226 (line 458) 49227* __cmpdf2: Soft float library routines. 49228 (line 163) 49229* __cmpdi2: Integer library routines. 49230 (line 86) 49231* __cmpdq2: Fixed-point fractional library routines. 49232 (line 447) 49233* __cmpha2: Fixed-point fractional library routines. 49234 (line 456) 49235* __cmphq2: Fixed-point fractional library routines. 49236 (line 445) 49237* __cmpqq2: Fixed-point fractional library routines. 49238 (line 444) 49239* __cmpsa2: Fixed-point fractional library routines. 49240 (line 457) 49241* __cmpsf2: Soft float library routines. 49242 (line 162) 49243* __cmpsq2: Fixed-point fractional library routines. 49244 (line 446) 49245* __cmpta2: Fixed-point fractional library routines. 49246 (line 459) 49247* __cmptf2: Soft float library routines. 49248 (line 164) 49249* __cmpti2: Integer library routines. 49250 (line 87) 49251* __cmpuda2: Fixed-point fractional library routines. 49252 (line 464) 49253* __cmpudq2: Fixed-point fractional library routines. 49254 (line 454) 49255* __cmpuha2: Fixed-point fractional library routines. 49256 (line 461) 49257* __cmpuhq2: Fixed-point fractional library routines. 49258 (line 451) 49259* __cmpuqq2: Fixed-point fractional library routines. 49260 (line 449) 49261* __cmpusa2: Fixed-point fractional library routines. 49262 (line 463) 49263* __cmpusq2: Fixed-point fractional library routines. 49264 (line 452) 49265* __cmputa2: Fixed-point fractional library routines. 49266 (line 466) 49267* __CTOR_LIST__: Initialization. (line 25) 49268* __ctzdi2: Integer library routines. 49269 (line 137) 49270* __ctzsi2: Integer library routines. 49271 (line 136) 49272* __ctzti2: Integer library routines. 49273 (line 138) 49274* __divda3: Fixed-point fractional library routines. 49275 (line 234) 49276* __divdc3: Soft float library routines. 49277 (line 250) 49278* __divdf3: Soft float library routines. 49279 (line 47) 49280* __divdi3: Integer library routines. 49281 (line 24) 49282* __divdq3: Fixed-point fractional library routines. 49283 (line 229) 49284* __divha3: Fixed-point fractional library routines. 49285 (line 231) 49286* __divhq3: Fixed-point fractional library routines. 49287 (line 227) 49288* __divqq3: Fixed-point fractional library routines. 49289 (line 225) 49290* __divsa3: Fixed-point fractional library routines. 49291 (line 233) 49292* __divsc3: Soft float library routines. 49293 (line 248) 49294* __divsf3: Soft float library routines. 49295 (line 46) 49296* __divsi3: Integer library routines. 49297 (line 23) 49298* __divsq3: Fixed-point fractional library routines. 49299 (line 228) 49300* __divta3: Fixed-point fractional library routines. 49301 (line 235) 49302* __divtc3: Soft float library routines. 49303 (line 252) 49304* __divtf3: Soft float library routines. 49305 (line 48) 49306* __divti3: Integer library routines. 49307 (line 25) 49308* __divxc3: Soft float library routines. 49309 (line 254) 49310* __divxf3: Soft float library routines. 49311 (line 50) 49312* __dpd_adddd3: Decimal float library routines. 49313 (line 21) 49314* __dpd_addsd3: Decimal float library routines. 49315 (line 17) 49316* __dpd_addtd3: Decimal float library routines. 49317 (line 25) 49318* __dpd_divdd3: Decimal float library routines. 49319 (line 64) 49320* __dpd_divsd3: Decimal float library routines. 49321 (line 60) 49322* __dpd_divtd3: Decimal float library routines. 49323 (line 68) 49324* __dpd_eqdd2: Decimal float library routines. 49325 (line 257) 49326* __dpd_eqsd2: Decimal float library routines. 49327 (line 255) 49328* __dpd_eqtd2: Decimal float library routines. 49329 (line 259) 49330* __dpd_extendddtd2: Decimal float library routines. 49331 (line 90) 49332* __dpd_extendddtf: Decimal float library routines. 49333 (line 138) 49334* __dpd_extendddxf: Decimal float library routines. 49335 (line 132) 49336* __dpd_extenddfdd: Decimal float library routines. 49337 (line 145) 49338* __dpd_extenddftd: Decimal float library routines. 49339 (line 105) 49340* __dpd_extendsddd2: Decimal float library routines. 49341 (line 86) 49342* __dpd_extendsddf: Decimal float library routines. 49343 (line 126) 49344* __dpd_extendsdtd2: Decimal float library routines. 49345 (line 88) 49346* __dpd_extendsdtf: Decimal float library routines. 49347 (line 136) 49348* __dpd_extendsdxf: Decimal float library routines. 49349 (line 130) 49350* __dpd_extendsfdd: Decimal float library routines. 49351 (line 101) 49352* __dpd_extendsfsd: Decimal float library routines. 49353 (line 143) 49354* __dpd_extendsftd: Decimal float library routines. 49355 (line 103) 49356* __dpd_extendtftd: Decimal float library routines. 49357 (line 147) 49358* __dpd_extendxftd: Decimal float library routines. 49359 (line 107) 49360* __dpd_fixdddi: Decimal float library routines. 49361 (line 168) 49362* __dpd_fixddsi: Decimal float library routines. 49363 (line 160) 49364* __dpd_fixsddi: Decimal float library routines. 49365 (line 166) 49366* __dpd_fixsdsi: Decimal float library routines. 49367 (line 158) 49368* __dpd_fixtddi: Decimal float library routines. 49369 (line 170) 49370* __dpd_fixtdsi: Decimal float library routines. 49371 (line 162) 49372* __dpd_fixunsdddi: Decimal float library routines. 49373 (line 185) 49374* __dpd_fixunsddsi: Decimal float library routines. 49375 (line 176) 49376* __dpd_fixunssddi: Decimal float library routines. 49377 (line 183) 49378* __dpd_fixunssdsi: Decimal float library routines. 49379 (line 174) 49380* __dpd_fixunstddi: Decimal float library routines. 49381 (line 187) 49382* __dpd_fixunstdsi: Decimal float library routines. 49383 (line 178) 49384* __dpd_floatdidd: Decimal float library routines. 49385 (line 203) 49386* __dpd_floatdisd: Decimal float library routines. 49387 (line 201) 49388* __dpd_floatditd: Decimal float library routines. 49389 (line 205) 49390* __dpd_floatsidd: Decimal float library routines. 49391 (line 194) 49392* __dpd_floatsisd: Decimal float library routines. 49393 (line 192) 49394* __dpd_floatsitd: Decimal float library routines. 49395 (line 196) 49396* __dpd_floatunsdidd: Decimal float library routines. 49397 (line 221) 49398* __dpd_floatunsdisd: Decimal float library routines. 49399 (line 219) 49400* __dpd_floatunsditd: Decimal float library routines. 49401 (line 223) 49402* __dpd_floatunssidd: Decimal float library routines. 49403 (line 212) 49404* __dpd_floatunssisd: Decimal float library routines. 49405 (line 210) 49406* __dpd_floatunssitd: Decimal float library routines. 49407 (line 214) 49408* __dpd_gedd2: Decimal float library routines. 49409 (line 275) 49410* __dpd_gesd2: Decimal float library routines. 49411 (line 273) 49412* __dpd_getd2: Decimal float library routines. 49413 (line 277) 49414* __dpd_gtdd2: Decimal float library routines. 49415 (line 302) 49416* __dpd_gtsd2: Decimal float library routines. 49417 (line 300) 49418* __dpd_gttd2: Decimal float library routines. 49419 (line 304) 49420* __dpd_ledd2: Decimal float library routines. 49421 (line 293) 49422* __dpd_lesd2: Decimal float library routines. 49423 (line 291) 49424* __dpd_letd2: Decimal float library routines. 49425 (line 295) 49426* __dpd_ltdd2: Decimal float library routines. 49427 (line 284) 49428* __dpd_ltsd2: Decimal float library routines. 49429 (line 282) 49430* __dpd_lttd2: Decimal float library routines. 49431 (line 286) 49432* __dpd_muldd3: Decimal float library routines. 49433 (line 50) 49434* __dpd_mulsd3: Decimal float library routines. 49435 (line 46) 49436* __dpd_multd3: Decimal float library routines. 49437 (line 54) 49438* __dpd_nedd2: Decimal float library routines. 49439 (line 266) 49440* __dpd_negdd2: Decimal float library routines. 49441 (line 76) 49442* __dpd_negsd2: Decimal float library routines. 49443 (line 74) 49444* __dpd_negtd2: Decimal float library routines. 49445 (line 78) 49446* __dpd_nesd2: Decimal float library routines. 49447 (line 264) 49448* __dpd_netd2: Decimal float library routines. 49449 (line 268) 49450* __dpd_subdd3: Decimal float library routines. 49451 (line 35) 49452* __dpd_subsd3: Decimal float library routines. 49453 (line 31) 49454* __dpd_subtd3: Decimal float library routines. 49455 (line 39) 49456* __dpd_truncdddf: Decimal float library routines. 49457 (line 151) 49458* __dpd_truncddsd2: Decimal float library routines. 49459 (line 92) 49460* __dpd_truncddsf: Decimal float library routines. 49461 (line 122) 49462* __dpd_truncdfsd: Decimal float library routines. 49463 (line 109) 49464* __dpd_truncsdsf: Decimal float library routines. 49465 (line 149) 49466* __dpd_trunctddd2: Decimal float library routines. 49467 (line 96) 49468* __dpd_trunctddf: Decimal float library routines. 49469 (line 128) 49470* __dpd_trunctdsd2: Decimal float library routines. 49471 (line 94) 49472* __dpd_trunctdsf: Decimal float library routines. 49473 (line 124) 49474* __dpd_trunctdtf: Decimal float library routines. 49475 (line 153) 49476* __dpd_trunctdxf: Decimal float library routines. 49477 (line 134) 49478* __dpd_trunctfdd: Decimal float library routines. 49479 (line 117) 49480* __dpd_trunctfsd: Decimal float library routines. 49481 (line 113) 49482* __dpd_truncxfdd: Decimal float library routines. 49483 (line 115) 49484* __dpd_truncxfsd: Decimal float library routines. 49485 (line 111) 49486* __dpd_unorddd2: Decimal float library routines. 49487 (line 233) 49488* __dpd_unordsd2: Decimal float library routines. 49489 (line 231) 49490* __dpd_unordtd2: Decimal float library routines. 49491 (line 235) 49492* __DTOR_LIST__: Initialization. (line 25) 49493* __eqdf2: Soft float library routines. 49494 (line 193) 49495* __eqsf2: Soft float library routines. 49496 (line 192) 49497* __eqtf2: Soft float library routines. 49498 (line 194) 49499* __extenddftf2: Soft float library routines. 49500 (line 67) 49501* __extenddfxf2: Soft float library routines. 49502 (line 68) 49503* __extendsfdf2: Soft float library routines. 49504 (line 64) 49505* __extendsftf2: Soft float library routines. 49506 (line 65) 49507* __extendsfxf2: Soft float library routines. 49508 (line 66) 49509* __ffsdi2: Integer library routines. 49510 (line 143) 49511* __ffsti2: Integer library routines. 49512 (line 144) 49513* __fixdfdi: Soft float library routines. 49514 (line 87) 49515* __fixdfsi: Soft float library routines. 49516 (line 80) 49517* __fixdfti: Soft float library routines. 49518 (line 93) 49519* __fixsfdi: Soft float library routines. 49520 (line 86) 49521* __fixsfsi: Soft float library routines. 49522 (line 79) 49523* __fixsfti: Soft float library routines. 49524 (line 92) 49525* __fixtfdi: Soft float library routines. 49526 (line 88) 49527* __fixtfsi: Soft float library routines. 49528 (line 81) 49529* __fixtfti: Soft float library routines. 49530 (line 94) 49531* __fixunsdfdi: Soft float library routines. 49532 (line 107) 49533* __fixunsdfsi: Soft float library routines. 49534 (line 100) 49535* __fixunsdfti: Soft float library routines. 49536 (line 114) 49537* __fixunssfdi: Soft float library routines. 49538 (line 106) 49539* __fixunssfsi: Soft float library routines. 49540 (line 99) 49541* __fixunssfti: Soft float library routines. 49542 (line 113) 49543* __fixunstfdi: Soft float library routines. 49544 (line 108) 49545* __fixunstfsi: Soft float library routines. 49546 (line 101) 49547* __fixunstfti: Soft float library routines. 49548 (line 115) 49549* __fixunsxfdi: Soft float library routines. 49550 (line 109) 49551* __fixunsxfsi: Soft float library routines. 49552 (line 102) 49553* __fixunsxfti: Soft float library routines. 49554 (line 116) 49555* __fixxfdi: Soft float library routines. 49556 (line 89) 49557* __fixxfsi: Soft float library routines. 49558 (line 82) 49559* __fixxfti: Soft float library routines. 49560 (line 95) 49561* __floatdidf: Soft float library routines. 49562 (line 127) 49563* __floatdisf: Soft float library routines. 49564 (line 126) 49565* __floatditf: Soft float library routines. 49566 (line 128) 49567* __floatdixf: Soft float library routines. 49568 (line 129) 49569* __floatsidf: Soft float library routines. 49570 (line 121) 49571* __floatsisf: Soft float library routines. 49572 (line 120) 49573* __floatsitf: Soft float library routines. 49574 (line 122) 49575* __floatsixf: Soft float library routines. 49576 (line 123) 49577* __floattidf: Soft float library routines. 49578 (line 133) 49579* __floattisf: Soft float library routines. 49580 (line 132) 49581* __floattitf: Soft float library routines. 49582 (line 134) 49583* __floattixf: Soft float library routines. 49584 (line 135) 49585* __floatundidf: Soft float library routines. 49586 (line 145) 49587* __floatundisf: Soft float library routines. 49588 (line 144) 49589* __floatunditf: Soft float library routines. 49590 (line 146) 49591* __floatundixf: Soft float library routines. 49592 (line 147) 49593* __floatunsidf: Soft float library routines. 49594 (line 139) 49595* __floatunsisf: Soft float library routines. 49596 (line 138) 49597* __floatunsitf: Soft float library routines. 49598 (line 140) 49599* __floatunsixf: Soft float library routines. 49600 (line 141) 49601* __floatuntidf: Soft float library routines. 49602 (line 151) 49603* __floatuntisf: Soft float library routines. 49604 (line 150) 49605* __floatuntitf: Soft float library routines. 49606 (line 152) 49607* __floatuntixf: Soft float library routines. 49608 (line 153) 49609* __fractdadf: Fixed-point fractional library routines. 49610 (line 643) 49611* __fractdadi: Fixed-point fractional library routines. 49612 (line 640) 49613* __fractdadq: Fixed-point fractional library routines. 49614 (line 623) 49615* __fractdaha2: Fixed-point fractional library routines. 49616 (line 624) 49617* __fractdahi: Fixed-point fractional library routines. 49618 (line 638) 49619* __fractdahq: Fixed-point fractional library routines. 49620 (line 621) 49621* __fractdaqi: Fixed-point fractional library routines. 49622 (line 637) 49623* __fractdaqq: Fixed-point fractional library routines. 49624 (line 620) 49625* __fractdasa2: Fixed-point fractional library routines. 49626 (line 625) 49627* __fractdasf: Fixed-point fractional library routines. 49628 (line 642) 49629* __fractdasi: Fixed-point fractional library routines. 49630 (line 639) 49631* __fractdasq: Fixed-point fractional library routines. 49632 (line 622) 49633* __fractdata2: Fixed-point fractional library routines. 49634 (line 626) 49635* __fractdati: Fixed-point fractional library routines. 49636 (line 641) 49637* __fractdauda: Fixed-point fractional library routines. 49638 (line 634) 49639* __fractdaudq: Fixed-point fractional library routines. 49640 (line 630) 49641* __fractdauha: Fixed-point fractional library routines. 49642 (line 632) 49643* __fractdauhq: Fixed-point fractional library routines. 49644 (line 628) 49645* __fractdauqq: Fixed-point fractional library routines. 49646 (line 627) 49647* __fractdausa: Fixed-point fractional library routines. 49648 (line 633) 49649* __fractdausq: Fixed-point fractional library routines. 49650 (line 629) 49651* __fractdauta: Fixed-point fractional library routines. 49652 (line 635) 49653* __fractdfda: Fixed-point fractional library routines. 49654 (line 1032) 49655* __fractdfdq: Fixed-point fractional library routines. 49656 (line 1029) 49657* __fractdfha: Fixed-point fractional library routines. 49658 (line 1030) 49659* __fractdfhq: Fixed-point fractional library routines. 49660 (line 1027) 49661* __fractdfqq: Fixed-point fractional library routines. 49662 (line 1026) 49663* __fractdfsa: Fixed-point fractional library routines. 49664 (line 1031) 49665* __fractdfsq: Fixed-point fractional library routines. 49666 (line 1028) 49667* __fractdfta: Fixed-point fractional library routines. 49668 (line 1033) 49669* __fractdfuda: Fixed-point fractional library routines. 49670 (line 1040) 49671* __fractdfudq: Fixed-point fractional library routines. 49672 (line 1037) 49673* __fractdfuha: Fixed-point fractional library routines. 49674 (line 1038) 49675* __fractdfuhq: Fixed-point fractional library routines. 49676 (line 1035) 49677* __fractdfuqq: Fixed-point fractional library routines. 49678 (line 1034) 49679* __fractdfusa: Fixed-point fractional library routines. 49680 (line 1039) 49681* __fractdfusq: Fixed-point fractional library routines. 49682 (line 1036) 49683* __fractdfuta: Fixed-point fractional library routines. 49684 (line 1041) 49685* __fractdida: Fixed-point fractional library routines. 49686 (line 982) 49687* __fractdidq: Fixed-point fractional library routines. 49688 (line 979) 49689* __fractdiha: Fixed-point fractional library routines. 49690 (line 980) 49691* __fractdihq: Fixed-point fractional library routines. 49692 (line 977) 49693* __fractdiqq: Fixed-point fractional library routines. 49694 (line 976) 49695* __fractdisa: Fixed-point fractional library routines. 49696 (line 981) 49697* __fractdisq: Fixed-point fractional library routines. 49698 (line 978) 49699* __fractdita: Fixed-point fractional library routines. 49700 (line 983) 49701* __fractdiuda: Fixed-point fractional library routines. 49702 (line 990) 49703* __fractdiudq: Fixed-point fractional library routines. 49704 (line 987) 49705* __fractdiuha: Fixed-point fractional library routines. 49706 (line 988) 49707* __fractdiuhq: Fixed-point fractional library routines. 49708 (line 985) 49709* __fractdiuqq: Fixed-point fractional library routines. 49710 (line 984) 49711* __fractdiusa: Fixed-point fractional library routines. 49712 (line 989) 49713* __fractdiusq: Fixed-point fractional library routines. 49714 (line 986) 49715* __fractdiuta: Fixed-point fractional library routines. 49716 (line 991) 49717* __fractdqda: Fixed-point fractional library routines. 49718 (line 551) 49719* __fractdqdf: Fixed-point fractional library routines. 49720 (line 573) 49721* __fractdqdi: Fixed-point fractional library routines. 49722 (line 570) 49723* __fractdqha: Fixed-point fractional library routines. 49724 (line 549) 49725* __fractdqhi: Fixed-point fractional library routines. 49726 (line 568) 49727* __fractdqhq2: Fixed-point fractional library routines. 49728 (line 547) 49729* __fractdqqi: Fixed-point fractional library routines. 49730 (line 567) 49731* __fractdqqq2: Fixed-point fractional library routines. 49732 (line 546) 49733* __fractdqsa: Fixed-point fractional library routines. 49734 (line 550) 49735* __fractdqsf: Fixed-point fractional library routines. 49736 (line 572) 49737* __fractdqsi: Fixed-point fractional library routines. 49738 (line 569) 49739* __fractdqsq2: Fixed-point fractional library routines. 49740 (line 548) 49741* __fractdqta: Fixed-point fractional library routines. 49742 (line 552) 49743* __fractdqti: Fixed-point fractional library routines. 49744 (line 571) 49745* __fractdquda: Fixed-point fractional library routines. 49746 (line 563) 49747* __fractdqudq: Fixed-point fractional library routines. 49748 (line 558) 49749* __fractdquha: Fixed-point fractional library routines. 49750 (line 560) 49751* __fractdquhq: Fixed-point fractional library routines. 49752 (line 555) 49753* __fractdquqq: Fixed-point fractional library routines. 49754 (line 553) 49755* __fractdqusa: Fixed-point fractional library routines. 49756 (line 562) 49757* __fractdqusq: Fixed-point fractional library routines. 49758 (line 556) 49759* __fractdquta: Fixed-point fractional library routines. 49760 (line 565) 49761* __fracthada2: Fixed-point fractional library routines. 49762 (line 579) 49763* __fracthadf: Fixed-point fractional library routines. 49764 (line 597) 49765* __fracthadi: Fixed-point fractional library routines. 49766 (line 594) 49767* __fracthadq: Fixed-point fractional library routines. 49768 (line 577) 49769* __fracthahi: Fixed-point fractional library routines. 49770 (line 592) 49771* __fracthahq: Fixed-point fractional library routines. 49772 (line 575) 49773* __fracthaqi: Fixed-point fractional library routines. 49774 (line 591) 49775* __fracthaqq: Fixed-point fractional library routines. 49776 (line 574) 49777* __fracthasa2: Fixed-point fractional library routines. 49778 (line 578) 49779* __fracthasf: Fixed-point fractional library routines. 49780 (line 596) 49781* __fracthasi: Fixed-point fractional library routines. 49782 (line 593) 49783* __fracthasq: Fixed-point fractional library routines. 49784 (line 576) 49785* __fracthata2: Fixed-point fractional library routines. 49786 (line 580) 49787* __fracthati: Fixed-point fractional library routines. 49788 (line 595) 49789* __fracthauda: Fixed-point fractional library routines. 49790 (line 588) 49791* __fracthaudq: Fixed-point fractional library routines. 49792 (line 584) 49793* __fracthauha: Fixed-point fractional library routines. 49794 (line 586) 49795* __fracthauhq: Fixed-point fractional library routines. 49796 (line 582) 49797* __fracthauqq: Fixed-point fractional library routines. 49798 (line 581) 49799* __fracthausa: Fixed-point fractional library routines. 49800 (line 587) 49801* __fracthausq: Fixed-point fractional library routines. 49802 (line 583) 49803* __fracthauta: Fixed-point fractional library routines. 49804 (line 589) 49805* __fracthida: Fixed-point fractional library routines. 49806 (line 950) 49807* __fracthidq: Fixed-point fractional library routines. 49808 (line 947) 49809* __fracthiha: Fixed-point fractional library routines. 49810 (line 948) 49811* __fracthihq: Fixed-point fractional library routines. 49812 (line 945) 49813* __fracthiqq: Fixed-point fractional library routines. 49814 (line 944) 49815* __fracthisa: Fixed-point fractional library routines. 49816 (line 949) 49817* __fracthisq: Fixed-point fractional library routines. 49818 (line 946) 49819* __fracthita: Fixed-point fractional library routines. 49820 (line 951) 49821* __fracthiuda: Fixed-point fractional library routines. 49822 (line 958) 49823* __fracthiudq: Fixed-point fractional library routines. 49824 (line 955) 49825* __fracthiuha: Fixed-point fractional library routines. 49826 (line 956) 49827* __fracthiuhq: Fixed-point fractional library routines. 49828 (line 953) 49829* __fracthiuqq: Fixed-point fractional library routines. 49830 (line 952) 49831* __fracthiusa: Fixed-point fractional library routines. 49832 (line 957) 49833* __fracthiusq: Fixed-point fractional library routines. 49834 (line 954) 49835* __fracthiuta: Fixed-point fractional library routines. 49836 (line 959) 49837* __fracthqda: Fixed-point fractional library routines. 49838 (line 505) 49839* __fracthqdf: Fixed-point fractional library routines. 49840 (line 521) 49841* __fracthqdi: Fixed-point fractional library routines. 49842 (line 518) 49843* __fracthqdq2: Fixed-point fractional library routines. 49844 (line 502) 49845* __fracthqha: Fixed-point fractional library routines. 49846 (line 503) 49847* __fracthqhi: Fixed-point fractional library routines. 49848 (line 516) 49849* __fracthqqi: Fixed-point fractional library routines. 49850 (line 515) 49851* __fracthqqq2: Fixed-point fractional library routines. 49852 (line 500) 49853* __fracthqsa: Fixed-point fractional library routines. 49854 (line 504) 49855* __fracthqsf: Fixed-point fractional library routines. 49856 (line 520) 49857* __fracthqsi: Fixed-point fractional library routines. 49858 (line 517) 49859* __fracthqsq2: Fixed-point fractional library routines. 49860 (line 501) 49861* __fracthqta: Fixed-point fractional library routines. 49862 (line 506) 49863* __fracthqti: Fixed-point fractional library routines. 49864 (line 519) 49865* __fracthquda: Fixed-point fractional library routines. 49866 (line 513) 49867* __fracthqudq: Fixed-point fractional library routines. 49868 (line 510) 49869* __fracthquha: Fixed-point fractional library routines. 49870 (line 511) 49871* __fracthquhq: Fixed-point fractional library routines. 49872 (line 508) 49873* __fracthquqq: Fixed-point fractional library routines. 49874 (line 507) 49875* __fracthqusa: Fixed-point fractional library routines. 49876 (line 512) 49877* __fracthqusq: Fixed-point fractional library routines. 49878 (line 509) 49879* __fracthquta: Fixed-point fractional library routines. 49880 (line 514) 49881* __fractqida: Fixed-point fractional library routines. 49882 (line 932) 49883* __fractqidq: Fixed-point fractional library routines. 49884 (line 929) 49885* __fractqiha: Fixed-point fractional library routines. 49886 (line 930) 49887* __fractqihq: Fixed-point fractional library routines. 49888 (line 927) 49889* __fractqiqq: Fixed-point fractional library routines. 49890 (line 926) 49891* __fractqisa: Fixed-point fractional library routines. 49892 (line 931) 49893* __fractqisq: Fixed-point fractional library routines. 49894 (line 928) 49895* __fractqita: Fixed-point fractional library routines. 49896 (line 933) 49897* __fractqiuda: Fixed-point fractional library routines. 49898 (line 941) 49899* __fractqiudq: Fixed-point fractional library routines. 49900 (line 937) 49901* __fractqiuha: Fixed-point fractional library routines. 49902 (line 939) 49903* __fractqiuhq: Fixed-point fractional library routines. 49904 (line 935) 49905* __fractqiuqq: Fixed-point fractional library routines. 49906 (line 934) 49907* __fractqiusa: Fixed-point fractional library routines. 49908 (line 940) 49909* __fractqiusq: Fixed-point fractional library routines. 49910 (line 936) 49911* __fractqiuta: Fixed-point fractional library routines. 49912 (line 942) 49913* __fractqqda: Fixed-point fractional library routines. 49914 (line 481) 49915* __fractqqdf: Fixed-point fractional library routines. 49916 (line 499) 49917* __fractqqdi: Fixed-point fractional library routines. 49918 (line 496) 49919* __fractqqdq2: Fixed-point fractional library routines. 49920 (line 478) 49921* __fractqqha: Fixed-point fractional library routines. 49922 (line 479) 49923* __fractqqhi: Fixed-point fractional library routines. 49924 (line 494) 49925* __fractqqhq2: Fixed-point fractional library routines. 49926 (line 476) 49927* __fractqqqi: Fixed-point fractional library routines. 49928 (line 493) 49929* __fractqqsa: Fixed-point fractional library routines. 49930 (line 480) 49931* __fractqqsf: Fixed-point fractional library routines. 49932 (line 498) 49933* __fractqqsi: Fixed-point fractional library routines. 49934 (line 495) 49935* __fractqqsq2: Fixed-point fractional library routines. 49936 (line 477) 49937* __fractqqta: Fixed-point fractional library routines. 49938 (line 482) 49939* __fractqqti: Fixed-point fractional library routines. 49940 (line 497) 49941* __fractqquda: Fixed-point fractional library routines. 49942 (line 490) 49943* __fractqqudq: Fixed-point fractional library routines. 49944 (line 486) 49945* __fractqquha: Fixed-point fractional library routines. 49946 (line 488) 49947* __fractqquhq: Fixed-point fractional library routines. 49948 (line 484) 49949* __fractqquqq: Fixed-point fractional library routines. 49950 (line 483) 49951* __fractqqusa: Fixed-point fractional library routines. 49952 (line 489) 49953* __fractqqusq: Fixed-point fractional library routines. 49954 (line 485) 49955* __fractqquta: Fixed-point fractional library routines. 49956 (line 491) 49957* __fractsada2: Fixed-point fractional library routines. 49958 (line 603) 49959* __fractsadf: Fixed-point fractional library routines. 49960 (line 619) 49961* __fractsadi: Fixed-point fractional library routines. 49962 (line 616) 49963* __fractsadq: Fixed-point fractional library routines. 49964 (line 601) 49965* __fractsaha2: Fixed-point fractional library routines. 49966 (line 602) 49967* __fractsahi: Fixed-point fractional library routines. 49968 (line 614) 49969* __fractsahq: Fixed-point fractional library routines. 49970 (line 599) 49971* __fractsaqi: Fixed-point fractional library routines. 49972 (line 613) 49973* __fractsaqq: Fixed-point fractional library routines. 49974 (line 598) 49975* __fractsasf: Fixed-point fractional library routines. 49976 (line 618) 49977* __fractsasi: Fixed-point fractional library routines. 49978 (line 615) 49979* __fractsasq: Fixed-point fractional library routines. 49980 (line 600) 49981* __fractsata2: Fixed-point fractional library routines. 49982 (line 604) 49983* __fractsati: Fixed-point fractional library routines. 49984 (line 617) 49985* __fractsauda: Fixed-point fractional library routines. 49986 (line 611) 49987* __fractsaudq: Fixed-point fractional library routines. 49988 (line 608) 49989* __fractsauha: Fixed-point fractional library routines. 49990 (line 609) 49991* __fractsauhq: Fixed-point fractional library routines. 49992 (line 606) 49993* __fractsauqq: Fixed-point fractional library routines. 49994 (line 605) 49995* __fractsausa: Fixed-point fractional library routines. 49996 (line 610) 49997* __fractsausq: Fixed-point fractional library routines. 49998 (line 607) 49999* __fractsauta: Fixed-point fractional library routines. 50000 (line 612) 50001* __fractsfda: Fixed-point fractional library routines. 50002 (line 1016) 50003* __fractsfdq: Fixed-point fractional library routines. 50004 (line 1013) 50005* __fractsfha: Fixed-point fractional library routines. 50006 (line 1014) 50007* __fractsfhq: Fixed-point fractional library routines. 50008 (line 1011) 50009* __fractsfqq: Fixed-point fractional library routines. 50010 (line 1010) 50011* __fractsfsa: Fixed-point fractional library routines. 50012 (line 1015) 50013* __fractsfsq: Fixed-point fractional library routines. 50014 (line 1012) 50015* __fractsfta: Fixed-point fractional library routines. 50016 (line 1017) 50017* __fractsfuda: Fixed-point fractional library routines. 50018 (line 1024) 50019* __fractsfudq: Fixed-point fractional library routines. 50020 (line 1021) 50021* __fractsfuha: Fixed-point fractional library routines. 50022 (line 1022) 50023* __fractsfuhq: Fixed-point fractional library routines. 50024 (line 1019) 50025* __fractsfuqq: Fixed-point fractional library routines. 50026 (line 1018) 50027* __fractsfusa: Fixed-point fractional library routines. 50028 (line 1023) 50029* __fractsfusq: Fixed-point fractional library routines. 50030 (line 1020) 50031* __fractsfuta: Fixed-point fractional library routines. 50032 (line 1025) 50033* __fractsida: Fixed-point fractional library routines. 50034 (line 966) 50035* __fractsidq: Fixed-point fractional library routines. 50036 (line 963) 50037* __fractsiha: Fixed-point fractional library routines. 50038 (line 964) 50039* __fractsihq: Fixed-point fractional library routines. 50040 (line 961) 50041* __fractsiqq: Fixed-point fractional library routines. 50042 (line 960) 50043* __fractsisa: Fixed-point fractional library routines. 50044 (line 965) 50045* __fractsisq: Fixed-point fractional library routines. 50046 (line 962) 50047* __fractsita: Fixed-point fractional library routines. 50048 (line 967) 50049* __fractsiuda: Fixed-point fractional library routines. 50050 (line 974) 50051* __fractsiudq: Fixed-point fractional library routines. 50052 (line 971) 50053* __fractsiuha: Fixed-point fractional library routines. 50054 (line 972) 50055* __fractsiuhq: Fixed-point fractional library routines. 50056 (line 969) 50057* __fractsiuqq: Fixed-point fractional library routines. 50058 (line 968) 50059* __fractsiusa: Fixed-point fractional library routines. 50060 (line 973) 50061* __fractsiusq: Fixed-point fractional library routines. 50062 (line 970) 50063* __fractsiuta: Fixed-point fractional library routines. 50064 (line 975) 50065* __fractsqda: Fixed-point fractional library routines. 50066 (line 527) 50067* __fractsqdf: Fixed-point fractional library routines. 50068 (line 545) 50069* __fractsqdi: Fixed-point fractional library routines. 50070 (line 542) 50071* __fractsqdq2: Fixed-point fractional library routines. 50072 (line 524) 50073* __fractsqha: Fixed-point fractional library routines. 50074 (line 525) 50075* __fractsqhi: Fixed-point fractional library routines. 50076 (line 540) 50077* __fractsqhq2: Fixed-point fractional library routines. 50078 (line 523) 50079* __fractsqqi: Fixed-point fractional library routines. 50080 (line 539) 50081* __fractsqqq2: Fixed-point fractional library routines. 50082 (line 522) 50083* __fractsqsa: Fixed-point fractional library routines. 50084 (line 526) 50085* __fractsqsf: Fixed-point fractional library routines. 50086 (line 544) 50087* __fractsqsi: Fixed-point fractional library routines. 50088 (line 541) 50089* __fractsqta: Fixed-point fractional library routines. 50090 (line 528) 50091* __fractsqti: Fixed-point fractional library routines. 50092 (line 543) 50093* __fractsquda: Fixed-point fractional library routines. 50094 (line 536) 50095* __fractsqudq: Fixed-point fractional library routines. 50096 (line 532) 50097* __fractsquha: Fixed-point fractional library routines. 50098 (line 534) 50099* __fractsquhq: Fixed-point fractional library routines. 50100 (line 530) 50101* __fractsquqq: Fixed-point fractional library routines. 50102 (line 529) 50103* __fractsqusa: Fixed-point fractional library routines. 50104 (line 535) 50105* __fractsqusq: Fixed-point fractional library routines. 50106 (line 531) 50107* __fractsquta: Fixed-point fractional library routines. 50108 (line 537) 50109* __fracttada2: Fixed-point fractional library routines. 50110 (line 650) 50111* __fracttadf: Fixed-point fractional library routines. 50112 (line 671) 50113* __fracttadi: Fixed-point fractional library routines. 50114 (line 668) 50115* __fracttadq: Fixed-point fractional library routines. 50116 (line 647) 50117* __fracttaha2: Fixed-point fractional library routines. 50118 (line 648) 50119* __fracttahi: Fixed-point fractional library routines. 50120 (line 666) 50121* __fracttahq: Fixed-point fractional library routines. 50122 (line 645) 50123* __fracttaqi: Fixed-point fractional library routines. 50124 (line 665) 50125* __fracttaqq: Fixed-point fractional library routines. 50126 (line 644) 50127* __fracttasa2: Fixed-point fractional library routines. 50128 (line 649) 50129* __fracttasf: Fixed-point fractional library routines. 50130 (line 670) 50131* __fracttasi: Fixed-point fractional library routines. 50132 (line 667) 50133* __fracttasq: Fixed-point fractional library routines. 50134 (line 646) 50135* __fracttati: Fixed-point fractional library routines. 50136 (line 669) 50137* __fracttauda: Fixed-point fractional library routines. 50138 (line 661) 50139* __fracttaudq: Fixed-point fractional library routines. 50140 (line 656) 50141* __fracttauha: Fixed-point fractional library routines. 50142 (line 658) 50143* __fracttauhq: Fixed-point fractional library routines. 50144 (line 653) 50145* __fracttauqq: Fixed-point fractional library routines. 50146 (line 651) 50147* __fracttausa: Fixed-point fractional library routines. 50148 (line 660) 50149* __fracttausq: Fixed-point fractional library routines. 50150 (line 654) 50151* __fracttauta: Fixed-point fractional library routines. 50152 (line 663) 50153* __fracttida: Fixed-point fractional library routines. 50154 (line 998) 50155* __fracttidq: Fixed-point fractional library routines. 50156 (line 995) 50157* __fracttiha: Fixed-point fractional library routines. 50158 (line 996) 50159* __fracttihq: Fixed-point fractional library routines. 50160 (line 993) 50161* __fracttiqq: Fixed-point fractional library routines. 50162 (line 992) 50163* __fracttisa: Fixed-point fractional library routines. 50164 (line 997) 50165* __fracttisq: Fixed-point fractional library routines. 50166 (line 994) 50167* __fracttita: Fixed-point fractional library routines. 50168 (line 999) 50169* __fracttiuda: Fixed-point fractional library routines. 50170 (line 1007) 50171* __fracttiudq: Fixed-point fractional library routines. 50172 (line 1003) 50173* __fracttiuha: Fixed-point fractional library routines. 50174 (line 1005) 50175* __fracttiuhq: Fixed-point fractional library routines. 50176 (line 1001) 50177* __fracttiuqq: Fixed-point fractional library routines. 50178 (line 1000) 50179* __fracttiusa: Fixed-point fractional library routines. 50180 (line 1006) 50181* __fracttiusq: Fixed-point fractional library routines. 50182 (line 1002) 50183* __fracttiuta: Fixed-point fractional library routines. 50184 (line 1008) 50185* __fractudada: Fixed-point fractional library routines. 50186 (line 865) 50187* __fractudadf: Fixed-point fractional library routines. 50188 (line 888) 50189* __fractudadi: Fixed-point fractional library routines. 50190 (line 885) 50191* __fractudadq: Fixed-point fractional library routines. 50192 (line 861) 50193* __fractudaha: Fixed-point fractional library routines. 50194 (line 863) 50195* __fractudahi: Fixed-point fractional library routines. 50196 (line 883) 50197* __fractudahq: Fixed-point fractional library routines. 50198 (line 859) 50199* __fractudaqi: Fixed-point fractional library routines. 50200 (line 882) 50201* __fractudaqq: Fixed-point fractional library routines. 50202 (line 858) 50203* __fractudasa: Fixed-point fractional library routines. 50204 (line 864) 50205* __fractudasf: Fixed-point fractional library routines. 50206 (line 887) 50207* __fractudasi: Fixed-point fractional library routines. 50208 (line 884) 50209* __fractudasq: Fixed-point fractional library routines. 50210 (line 860) 50211* __fractudata: Fixed-point fractional library routines. 50212 (line 866) 50213* __fractudati: Fixed-point fractional library routines. 50214 (line 886) 50215* __fractudaudq: Fixed-point fractional library routines. 50216 (line 874) 50217* __fractudauha2: Fixed-point fractional library routines. 50218 (line 876) 50219* __fractudauhq: Fixed-point fractional library routines. 50220 (line 870) 50221* __fractudauqq: Fixed-point fractional library routines. 50222 (line 868) 50223* __fractudausa2: Fixed-point fractional library routines. 50224 (line 878) 50225* __fractudausq: Fixed-point fractional library routines. 50226 (line 872) 50227* __fractudauta2: Fixed-point fractional library routines. 50228 (line 880) 50229* __fractudqda: Fixed-point fractional library routines. 50230 (line 772) 50231* __fractudqdf: Fixed-point fractional library routines. 50232 (line 798) 50233* __fractudqdi: Fixed-point fractional library routines. 50234 (line 794) 50235* __fractudqdq: Fixed-point fractional library routines. 50236 (line 767) 50237* __fractudqha: Fixed-point fractional library routines. 50238 (line 769) 50239* __fractudqhi: Fixed-point fractional library routines. 50240 (line 792) 50241* __fractudqhq: Fixed-point fractional library routines. 50242 (line 764) 50243* __fractudqqi: Fixed-point fractional library routines. 50244 (line 790) 50245* __fractudqqq: Fixed-point fractional library routines. 50246 (line 762) 50247* __fractudqsa: Fixed-point fractional library routines. 50248 (line 771) 50249* __fractudqsf: Fixed-point fractional library routines. 50250 (line 797) 50251* __fractudqsi: Fixed-point fractional library routines. 50252 (line 793) 50253* __fractudqsq: Fixed-point fractional library routines. 50254 (line 765) 50255* __fractudqta: Fixed-point fractional library routines. 50256 (line 774) 50257* __fractudqti: Fixed-point fractional library routines. 50258 (line 795) 50259* __fractudquda: Fixed-point fractional library routines. 50260 (line 786) 50261* __fractudquha: Fixed-point fractional library routines. 50262 (line 782) 50263* __fractudquhq2: Fixed-point fractional library routines. 50264 (line 778) 50265* __fractudquqq2: Fixed-point fractional library routines. 50266 (line 776) 50267* __fractudqusa: Fixed-point fractional library routines. 50268 (line 784) 50269* __fractudqusq2: Fixed-point fractional library routines. 50270 (line 780) 50271* __fractudquta: Fixed-point fractional library routines. 50272 (line 788) 50273* __fractuhada: Fixed-point fractional library routines. 50274 (line 806) 50275* __fractuhadf: Fixed-point fractional library routines. 50276 (line 829) 50277* __fractuhadi: Fixed-point fractional library routines. 50278 (line 826) 50279* __fractuhadq: Fixed-point fractional library routines. 50280 (line 802) 50281* __fractuhaha: Fixed-point fractional library routines. 50282 (line 804) 50283* __fractuhahi: Fixed-point fractional library routines. 50284 (line 824) 50285* __fractuhahq: Fixed-point fractional library routines. 50286 (line 800) 50287* __fractuhaqi: Fixed-point fractional library routines. 50288 (line 823) 50289* __fractuhaqq: Fixed-point fractional library routines. 50290 (line 799) 50291* __fractuhasa: Fixed-point fractional library routines. 50292 (line 805) 50293* __fractuhasf: Fixed-point fractional library routines. 50294 (line 828) 50295* __fractuhasi: Fixed-point fractional library routines. 50296 (line 825) 50297* __fractuhasq: Fixed-point fractional library routines. 50298 (line 801) 50299* __fractuhata: Fixed-point fractional library routines. 50300 (line 807) 50301* __fractuhati: Fixed-point fractional library routines. 50302 (line 827) 50303* __fractuhauda2: Fixed-point fractional library routines. 50304 (line 819) 50305* __fractuhaudq: Fixed-point fractional library routines. 50306 (line 815) 50307* __fractuhauhq: Fixed-point fractional library routines. 50308 (line 811) 50309* __fractuhauqq: Fixed-point fractional library routines. 50310 (line 809) 50311* __fractuhausa2: Fixed-point fractional library routines. 50312 (line 817) 50313* __fractuhausq: Fixed-point fractional library routines. 50314 (line 813) 50315* __fractuhauta2: Fixed-point fractional library routines. 50316 (line 821) 50317* __fractuhqda: Fixed-point fractional library routines. 50318 (line 709) 50319* __fractuhqdf: Fixed-point fractional library routines. 50320 (line 730) 50321* __fractuhqdi: Fixed-point fractional library routines. 50322 (line 727) 50323* __fractuhqdq: Fixed-point fractional library routines. 50324 (line 706) 50325* __fractuhqha: Fixed-point fractional library routines. 50326 (line 707) 50327* __fractuhqhi: Fixed-point fractional library routines. 50328 (line 725) 50329* __fractuhqhq: Fixed-point fractional library routines. 50330 (line 704) 50331* __fractuhqqi: Fixed-point fractional library routines. 50332 (line 724) 50333* __fractuhqqq: Fixed-point fractional library routines. 50334 (line 703) 50335* __fractuhqsa: Fixed-point fractional library routines. 50336 (line 708) 50337* __fractuhqsf: Fixed-point fractional library routines. 50338 (line 729) 50339* __fractuhqsi: Fixed-point fractional library routines. 50340 (line 726) 50341* __fractuhqsq: Fixed-point fractional library routines. 50342 (line 705) 50343* __fractuhqta: Fixed-point fractional library routines. 50344 (line 710) 50345* __fractuhqti: Fixed-point fractional library routines. 50346 (line 728) 50347* __fractuhquda: Fixed-point fractional library routines. 50348 (line 720) 50349* __fractuhqudq2: Fixed-point fractional library routines. 50350 (line 715) 50351* __fractuhquha: Fixed-point fractional library routines. 50352 (line 717) 50353* __fractuhquqq2: Fixed-point fractional library routines. 50354 (line 711) 50355* __fractuhqusa: Fixed-point fractional library routines. 50356 (line 719) 50357* __fractuhqusq2: Fixed-point fractional library routines. 50358 (line 713) 50359* __fractuhquta: Fixed-point fractional library routines. 50360 (line 722) 50361* __fractunsdadi: Fixed-point fractional library routines. 50362 (line 1562) 50363* __fractunsdahi: Fixed-point fractional library routines. 50364 (line 1560) 50365* __fractunsdaqi: Fixed-point fractional library routines. 50366 (line 1559) 50367* __fractunsdasi: Fixed-point fractional library routines. 50368 (line 1561) 50369* __fractunsdati: Fixed-point fractional library routines. 50370 (line 1563) 50371* __fractunsdida: Fixed-point fractional library routines. 50372 (line 1714) 50373* __fractunsdidq: Fixed-point fractional library routines. 50374 (line 1711) 50375* __fractunsdiha: Fixed-point fractional library routines. 50376 (line 1712) 50377* __fractunsdihq: Fixed-point fractional library routines. 50378 (line 1709) 50379* __fractunsdiqq: Fixed-point fractional library routines. 50380 (line 1708) 50381* __fractunsdisa: Fixed-point fractional library routines. 50382 (line 1713) 50383* __fractunsdisq: Fixed-point fractional library routines. 50384 (line 1710) 50385* __fractunsdita: Fixed-point fractional library routines. 50386 (line 1715) 50387* __fractunsdiuda: Fixed-point fractional library routines. 50388 (line 1726) 50389* __fractunsdiudq: Fixed-point fractional library routines. 50390 (line 1721) 50391* __fractunsdiuha: Fixed-point fractional library routines. 50392 (line 1723) 50393* __fractunsdiuhq: Fixed-point fractional library routines. 50394 (line 1718) 50395* __fractunsdiuqq: Fixed-point fractional library routines. 50396 (line 1716) 50397* __fractunsdiusa: Fixed-point fractional library routines. 50398 (line 1725) 50399* __fractunsdiusq: Fixed-point fractional library routines. 50400 (line 1719) 50401* __fractunsdiuta: Fixed-point fractional library routines. 50402 (line 1728) 50403* __fractunsdqdi: Fixed-point fractional library routines. 50404 (line 1546) 50405* __fractunsdqhi: Fixed-point fractional library routines. 50406 (line 1544) 50407* __fractunsdqqi: Fixed-point fractional library routines. 50408 (line 1543) 50409* __fractunsdqsi: Fixed-point fractional library routines. 50410 (line 1545) 50411* __fractunsdqti: Fixed-point fractional library routines. 50412 (line 1547) 50413* __fractunshadi: Fixed-point fractional library routines. 50414 (line 1552) 50415* __fractunshahi: Fixed-point fractional library routines. 50416 (line 1550) 50417* __fractunshaqi: Fixed-point fractional library routines. 50418 (line 1549) 50419* __fractunshasi: Fixed-point fractional library routines. 50420 (line 1551) 50421* __fractunshati: Fixed-point fractional library routines. 50422 (line 1553) 50423* __fractunshida: Fixed-point fractional library routines. 50424 (line 1670) 50425* __fractunshidq: Fixed-point fractional library routines. 50426 (line 1667) 50427* __fractunshiha: Fixed-point fractional library routines. 50428 (line 1668) 50429* __fractunshihq: Fixed-point fractional library routines. 50430 (line 1665) 50431* __fractunshiqq: Fixed-point fractional library routines. 50432 (line 1664) 50433* __fractunshisa: Fixed-point fractional library routines. 50434 (line 1669) 50435* __fractunshisq: Fixed-point fractional library routines. 50436 (line 1666) 50437* __fractunshita: Fixed-point fractional library routines. 50438 (line 1671) 50439* __fractunshiuda: Fixed-point fractional library routines. 50440 (line 1682) 50441* __fractunshiudq: Fixed-point fractional library routines. 50442 (line 1677) 50443* __fractunshiuha: Fixed-point fractional library routines. 50444 (line 1679) 50445* __fractunshiuhq: Fixed-point fractional library routines. 50446 (line 1674) 50447* __fractunshiuqq: Fixed-point fractional library routines. 50448 (line 1672) 50449* __fractunshiusa: Fixed-point fractional library routines. 50450 (line 1681) 50451* __fractunshiusq: Fixed-point fractional library routines. 50452 (line 1675) 50453* __fractunshiuta: Fixed-point fractional library routines. 50454 (line 1684) 50455* __fractunshqdi: Fixed-point fractional library routines. 50456 (line 1536) 50457* __fractunshqhi: Fixed-point fractional library routines. 50458 (line 1534) 50459* __fractunshqqi: Fixed-point fractional library routines. 50460 (line 1533) 50461* __fractunshqsi: Fixed-point fractional library routines. 50462 (line 1535) 50463* __fractunshqti: Fixed-point fractional library routines. 50464 (line 1537) 50465* __fractunsqida: Fixed-point fractional library routines. 50466 (line 1648) 50467* __fractunsqidq: Fixed-point fractional library routines. 50468 (line 1645) 50469* __fractunsqiha: Fixed-point fractional library routines. 50470 (line 1646) 50471* __fractunsqihq: Fixed-point fractional library routines. 50472 (line 1643) 50473* __fractunsqiqq: Fixed-point fractional library routines. 50474 (line 1642) 50475* __fractunsqisa: Fixed-point fractional library routines. 50476 (line 1647) 50477* __fractunsqisq: Fixed-point fractional library routines. 50478 (line 1644) 50479* __fractunsqita: Fixed-point fractional library routines. 50480 (line 1649) 50481* __fractunsqiuda: Fixed-point fractional library routines. 50482 (line 1660) 50483* __fractunsqiudq: Fixed-point fractional library routines. 50484 (line 1655) 50485* __fractunsqiuha: Fixed-point fractional library routines. 50486 (line 1657) 50487* __fractunsqiuhq: Fixed-point fractional library routines. 50488 (line 1652) 50489* __fractunsqiuqq: Fixed-point fractional library routines. 50490 (line 1650) 50491* __fractunsqiusa: Fixed-point fractional library routines. 50492 (line 1659) 50493* __fractunsqiusq: Fixed-point fractional library routines. 50494 (line 1653) 50495* __fractunsqiuta: Fixed-point fractional library routines. 50496 (line 1662) 50497* __fractunsqqdi: Fixed-point fractional library routines. 50498 (line 1531) 50499* __fractunsqqhi: Fixed-point fractional library routines. 50500 (line 1529) 50501* __fractunsqqqi: Fixed-point fractional library routines. 50502 (line 1528) 50503* __fractunsqqsi: Fixed-point fractional library routines. 50504 (line 1530) 50505* __fractunsqqti: Fixed-point fractional library routines. 50506 (line 1532) 50507* __fractunssadi: Fixed-point fractional library routines. 50508 (line 1557) 50509* __fractunssahi: Fixed-point fractional library routines. 50510 (line 1555) 50511* __fractunssaqi: Fixed-point fractional library routines. 50512 (line 1554) 50513* __fractunssasi: Fixed-point fractional library routines. 50514 (line 1556) 50515* __fractunssati: Fixed-point fractional library routines. 50516 (line 1558) 50517* __fractunssida: Fixed-point fractional library routines. 50518 (line 1692) 50519* __fractunssidq: Fixed-point fractional library routines. 50520 (line 1689) 50521* __fractunssiha: Fixed-point fractional library routines. 50522 (line 1690) 50523* __fractunssihq: Fixed-point fractional library routines. 50524 (line 1687) 50525* __fractunssiqq: Fixed-point fractional library routines. 50526 (line 1686) 50527* __fractunssisa: Fixed-point fractional library routines. 50528 (line 1691) 50529* __fractunssisq: Fixed-point fractional library routines. 50530 (line 1688) 50531* __fractunssita: Fixed-point fractional library routines. 50532 (line 1693) 50533* __fractunssiuda: Fixed-point fractional library routines. 50534 (line 1704) 50535* __fractunssiudq: Fixed-point fractional library routines. 50536 (line 1699) 50537* __fractunssiuha: Fixed-point fractional library routines. 50538 (line 1701) 50539* __fractunssiuhq: Fixed-point fractional library routines. 50540 (line 1696) 50541* __fractunssiuqq: Fixed-point fractional library routines. 50542 (line 1694) 50543* __fractunssiusa: Fixed-point fractional library routines. 50544 (line 1703) 50545* __fractunssiusq: Fixed-point fractional library routines. 50546 (line 1697) 50547* __fractunssiuta: Fixed-point fractional library routines. 50548 (line 1706) 50549* __fractunssqdi: Fixed-point fractional library routines. 50550 (line 1541) 50551* __fractunssqhi: Fixed-point fractional library routines. 50552 (line 1539) 50553* __fractunssqqi: Fixed-point fractional library routines. 50554 (line 1538) 50555* __fractunssqsi: Fixed-point fractional library routines. 50556 (line 1540) 50557* __fractunssqti: Fixed-point fractional library routines. 50558 (line 1542) 50559* __fractunstadi: Fixed-point fractional library routines. 50560 (line 1567) 50561* __fractunstahi: Fixed-point fractional library routines. 50562 (line 1565) 50563* __fractunstaqi: Fixed-point fractional library routines. 50564 (line 1564) 50565* __fractunstasi: Fixed-point fractional library routines. 50566 (line 1566) 50567* __fractunstati: Fixed-point fractional library routines. 50568 (line 1568) 50569* __fractunstida: Fixed-point fractional library routines. 50570 (line 1737) 50571* __fractunstidq: Fixed-point fractional library routines. 50572 (line 1733) 50573* __fractunstiha: Fixed-point fractional library routines. 50574 (line 1735) 50575* __fractunstihq: Fixed-point fractional library routines. 50576 (line 1731) 50577* __fractunstiqq: Fixed-point fractional library routines. 50578 (line 1730) 50579* __fractunstisa: Fixed-point fractional library routines. 50580 (line 1736) 50581* __fractunstisq: Fixed-point fractional library routines. 50582 (line 1732) 50583* __fractunstita: Fixed-point fractional library routines. 50584 (line 1738) 50585* __fractunstiuda: Fixed-point fractional library routines. 50586 (line 1752) 50587* __fractunstiudq: Fixed-point fractional library routines. 50588 (line 1746) 50589* __fractunstiuha: Fixed-point fractional library routines. 50590 (line 1748) 50591* __fractunstiuhq: Fixed-point fractional library routines. 50592 (line 1742) 50593* __fractunstiuqq: Fixed-point fractional library routines. 50594 (line 1740) 50595* __fractunstiusa: Fixed-point fractional library routines. 50596 (line 1750) 50597* __fractunstiusq: Fixed-point fractional library routines. 50598 (line 1744) 50599* __fractunstiuta: Fixed-point fractional library routines. 50600 (line 1754) 50601* __fractunsudadi: Fixed-point fractional library routines. 50602 (line 1628) 50603* __fractunsudahi: Fixed-point fractional library routines. 50604 (line 1624) 50605* __fractunsudaqi: Fixed-point fractional library routines. 50606 (line 1622) 50607* __fractunsudasi: Fixed-point fractional library routines. 50608 (line 1626) 50609* __fractunsudati: Fixed-point fractional library routines. 50610 (line 1630) 50611* __fractunsudqdi: Fixed-point fractional library routines. 50612 (line 1602) 50613* __fractunsudqhi: Fixed-point fractional library routines. 50614 (line 1598) 50615* __fractunsudqqi: Fixed-point fractional library routines. 50616 (line 1596) 50617* __fractunsudqsi: Fixed-point fractional library routines. 50618 (line 1600) 50619* __fractunsudqti: Fixed-point fractional library routines. 50620 (line 1604) 50621* __fractunsuhadi: Fixed-point fractional library routines. 50622 (line 1612) 50623* __fractunsuhahi: Fixed-point fractional library routines. 50624 (line 1608) 50625* __fractunsuhaqi: Fixed-point fractional library routines. 50626 (line 1606) 50627* __fractunsuhasi: Fixed-point fractional library routines. 50628 (line 1610) 50629* __fractunsuhati: Fixed-point fractional library routines. 50630 (line 1614) 50631* __fractunsuhqdi: Fixed-point fractional library routines. 50632 (line 1583) 50633* __fractunsuhqhi: Fixed-point fractional library routines. 50634 (line 1581) 50635* __fractunsuhqqi: Fixed-point fractional library routines. 50636 (line 1580) 50637* __fractunsuhqsi: Fixed-point fractional library routines. 50638 (line 1582) 50639* __fractunsuhqti: Fixed-point fractional library routines. 50640 (line 1584) 50641* __fractunsuqqdi: Fixed-point fractional library routines. 50642 (line 1576) 50643* __fractunsuqqhi: Fixed-point fractional library routines. 50644 (line 1572) 50645* __fractunsuqqqi: Fixed-point fractional library routines. 50646 (line 1570) 50647* __fractunsuqqsi: Fixed-point fractional library routines. 50648 (line 1574) 50649* __fractunsuqqti: Fixed-point fractional library routines. 50650 (line 1578) 50651* __fractunsusadi: Fixed-point fractional library routines. 50652 (line 1619) 50653* __fractunsusahi: Fixed-point fractional library routines. 50654 (line 1617) 50655* __fractunsusaqi: Fixed-point fractional library routines. 50656 (line 1616) 50657* __fractunsusasi: Fixed-point fractional library routines. 50658 (line 1618) 50659* __fractunsusati: Fixed-point fractional library routines. 50660 (line 1620) 50661* __fractunsusqdi: Fixed-point fractional library routines. 50662 (line 1592) 50663* __fractunsusqhi: Fixed-point fractional library routines. 50664 (line 1588) 50665* __fractunsusqqi: Fixed-point fractional library routines. 50666 (line 1586) 50667* __fractunsusqsi: Fixed-point fractional library routines. 50668 (line 1590) 50669* __fractunsusqti: Fixed-point fractional library routines. 50670 (line 1594) 50671* __fractunsutadi: Fixed-point fractional library routines. 50672 (line 1638) 50673* __fractunsutahi: Fixed-point fractional library routines. 50674 (line 1634) 50675* __fractunsutaqi: Fixed-point fractional library routines. 50676 (line 1632) 50677* __fractunsutasi: Fixed-point fractional library routines. 50678 (line 1636) 50679* __fractunsutati: Fixed-point fractional library routines. 50680 (line 1640) 50681* __fractuqqda: Fixed-point fractional library routines. 50682 (line 679) 50683* __fractuqqdf: Fixed-point fractional library routines. 50684 (line 702) 50685* __fractuqqdi: Fixed-point fractional library routines. 50686 (line 699) 50687* __fractuqqdq: Fixed-point fractional library routines. 50688 (line 675) 50689* __fractuqqha: Fixed-point fractional library routines. 50690 (line 677) 50691* __fractuqqhi: Fixed-point fractional library routines. 50692 (line 697) 50693* __fractuqqhq: Fixed-point fractional library routines. 50694 (line 673) 50695* __fractuqqqi: Fixed-point fractional library routines. 50696 (line 696) 50697* __fractuqqqq: Fixed-point fractional library routines. 50698 (line 672) 50699* __fractuqqsa: Fixed-point fractional library routines. 50700 (line 678) 50701* __fractuqqsf: Fixed-point fractional library routines. 50702 (line 701) 50703* __fractuqqsi: Fixed-point fractional library routines. 50704 (line 698) 50705* __fractuqqsq: Fixed-point fractional library routines. 50706 (line 674) 50707* __fractuqqta: Fixed-point fractional library routines. 50708 (line 680) 50709* __fractuqqti: Fixed-point fractional library routines. 50710 (line 700) 50711* __fractuqquda: Fixed-point fractional library routines. 50712 (line 692) 50713* __fractuqqudq2: Fixed-point fractional library routines. 50714 (line 686) 50715* __fractuqquha: Fixed-point fractional library routines. 50716 (line 688) 50717* __fractuqquhq2: Fixed-point fractional library routines. 50718 (line 682) 50719* __fractuqqusa: Fixed-point fractional library routines. 50720 (line 690) 50721* __fractuqqusq2: Fixed-point fractional library routines. 50722 (line 684) 50723* __fractuqquta: Fixed-point fractional library routines. 50724 (line 694) 50725* __fractusada: Fixed-point fractional library routines. 50726 (line 836) 50727* __fractusadf: Fixed-point fractional library routines. 50728 (line 857) 50729* __fractusadi: Fixed-point fractional library routines. 50730 (line 854) 50731* __fractusadq: Fixed-point fractional library routines. 50732 (line 833) 50733* __fractusaha: Fixed-point fractional library routines. 50734 (line 834) 50735* __fractusahi: Fixed-point fractional library routines. 50736 (line 852) 50737* __fractusahq: Fixed-point fractional library routines. 50738 (line 831) 50739* __fractusaqi: Fixed-point fractional library routines. 50740 (line 851) 50741* __fractusaqq: Fixed-point fractional library routines. 50742 (line 830) 50743* __fractusasa: Fixed-point fractional library routines. 50744 (line 835) 50745* __fractusasf: Fixed-point fractional library routines. 50746 (line 856) 50747* __fractusasi: Fixed-point fractional library routines. 50748 (line 853) 50749* __fractusasq: Fixed-point fractional library routines. 50750 (line 832) 50751* __fractusata: Fixed-point fractional library routines. 50752 (line 837) 50753* __fractusati: Fixed-point fractional library routines. 50754 (line 855) 50755* __fractusauda2: Fixed-point fractional library routines. 50756 (line 847) 50757* __fractusaudq: Fixed-point fractional library routines. 50758 (line 843) 50759* __fractusauha2: Fixed-point fractional library routines. 50760 (line 845) 50761* __fractusauhq: Fixed-point fractional library routines. 50762 (line 840) 50763* __fractusauqq: Fixed-point fractional library routines. 50764 (line 838) 50765* __fractusausq: Fixed-point fractional library routines. 50766 (line 841) 50767* __fractusauta2: Fixed-point fractional library routines. 50768 (line 849) 50769* __fractusqda: Fixed-point fractional library routines. 50770 (line 738) 50771* __fractusqdf: Fixed-point fractional library routines. 50772 (line 761) 50773* __fractusqdi: Fixed-point fractional library routines. 50774 (line 758) 50775* __fractusqdq: Fixed-point fractional library routines. 50776 (line 734) 50777* __fractusqha: Fixed-point fractional library routines. 50778 (line 736) 50779* __fractusqhi: Fixed-point fractional library routines. 50780 (line 756) 50781* __fractusqhq: Fixed-point fractional library routines. 50782 (line 732) 50783* __fractusqqi: Fixed-point fractional library routines. 50784 (line 755) 50785* __fractusqqq: Fixed-point fractional library routines. 50786 (line 731) 50787* __fractusqsa: Fixed-point fractional library routines. 50788 (line 737) 50789* __fractusqsf: Fixed-point fractional library routines. 50790 (line 760) 50791* __fractusqsi: Fixed-point fractional library routines. 50792 (line 757) 50793* __fractusqsq: Fixed-point fractional library routines. 50794 (line 733) 50795* __fractusqta: Fixed-point fractional library routines. 50796 (line 739) 50797* __fractusqti: Fixed-point fractional library routines. 50798 (line 759) 50799* __fractusquda: Fixed-point fractional library routines. 50800 (line 751) 50801* __fractusqudq2: Fixed-point fractional library routines. 50802 (line 745) 50803* __fractusquha: Fixed-point fractional library routines. 50804 (line 747) 50805* __fractusquhq2: Fixed-point fractional library routines. 50806 (line 743) 50807* __fractusquqq2: Fixed-point fractional library routines. 50808 (line 741) 50809* __fractusqusa: Fixed-point fractional library routines. 50810 (line 749) 50811* __fractusquta: Fixed-point fractional library routines. 50812 (line 753) 50813* __fractutada: Fixed-point fractional library routines. 50814 (line 899) 50815* __fractutadf: Fixed-point fractional library routines. 50816 (line 925) 50817* __fractutadi: Fixed-point fractional library routines. 50818 (line 921) 50819* __fractutadq: Fixed-point fractional library routines. 50820 (line 894) 50821* __fractutaha: Fixed-point fractional library routines. 50822 (line 896) 50823* __fractutahi: Fixed-point fractional library routines. 50824 (line 919) 50825* __fractutahq: Fixed-point fractional library routines. 50826 (line 891) 50827* __fractutaqi: Fixed-point fractional library routines. 50828 (line 917) 50829* __fractutaqq: Fixed-point fractional library routines. 50830 (line 889) 50831* __fractutasa: Fixed-point fractional library routines. 50832 (line 898) 50833* __fractutasf: Fixed-point fractional library routines. 50834 (line 924) 50835* __fractutasi: Fixed-point fractional library routines. 50836 (line 920) 50837* __fractutasq: Fixed-point fractional library routines. 50838 (line 892) 50839* __fractutata: Fixed-point fractional library routines. 50840 (line 901) 50841* __fractutati: Fixed-point fractional library routines. 50842 (line 922) 50843* __fractutauda2: Fixed-point fractional library routines. 50844 (line 915) 50845* __fractutaudq: Fixed-point fractional library routines. 50846 (line 909) 50847* __fractutauha2: Fixed-point fractional library routines. 50848 (line 911) 50849* __fractutauhq: Fixed-point fractional library routines. 50850 (line 905) 50851* __fractutauqq: Fixed-point fractional library routines. 50852 (line 903) 50853* __fractutausa2: Fixed-point fractional library routines. 50854 (line 913) 50855* __fractutausq: Fixed-point fractional library routines. 50856 (line 907) 50857* __gedf2: Soft float library routines. 50858 (line 205) 50859* __gesf2: Soft float library routines. 50860 (line 204) 50861* __getf2: Soft float library routines. 50862 (line 206) 50863* __gtdf2: Soft float library routines. 50864 (line 223) 50865* __gtsf2: Soft float library routines. 50866 (line 222) 50867* __gttf2: Soft float library routines. 50868 (line 224) 50869* __ledf2: Soft float library routines. 50870 (line 217) 50871* __lesf2: Soft float library routines. 50872 (line 216) 50873* __letf2: Soft float library routines. 50874 (line 218) 50875* __lshrdi3: Integer library routines. 50876 (line 30) 50877* __lshrsi3: Integer library routines. 50878 (line 29) 50879* __lshrti3: Integer library routines. 50880 (line 31) 50881* __lshruda3: Fixed-point fractional library routines. 50882 (line 396) 50883* __lshrudq3: Fixed-point fractional library routines. 50884 (line 390) 50885* __lshruha3: Fixed-point fractional library routines. 50886 (line 392) 50887* __lshruhq3: Fixed-point fractional library routines. 50888 (line 386) 50889* __lshruqq3: Fixed-point fractional library routines. 50890 (line 384) 50891* __lshrusa3: Fixed-point fractional library routines. 50892 (line 394) 50893* __lshrusq3: Fixed-point fractional library routines. 50894 (line 388) 50895* __lshruta3: Fixed-point fractional library routines. 50896 (line 398) 50897* __ltdf2: Soft float library routines. 50898 (line 211) 50899* __ltsf2: Soft float library routines. 50900 (line 210) 50901* __lttf2: Soft float library routines. 50902 (line 212) 50903* __main: Collect2. (line 15) 50904* __moddi3: Integer library routines. 50905 (line 36) 50906* __modsi3: Integer library routines. 50907 (line 35) 50908* __modti3: Integer library routines. 50909 (line 37) 50910* __morestack_current_segment: Miscellaneous routines. 50911 (line 45) 50912* __morestack_initial_sp: Miscellaneous routines. 50913 (line 46) 50914* __morestack_segments: Miscellaneous routines. 50915 (line 44) 50916* __mulda3: Fixed-point fractional library routines. 50917 (line 178) 50918* __muldc3: Soft float library routines. 50919 (line 239) 50920* __muldf3: Soft float library routines. 50921 (line 39) 50922* __muldi3: Integer library routines. 50923 (line 42) 50924* __muldq3: Fixed-point fractional library routines. 50925 (line 165) 50926* __mulha3: Fixed-point fractional library routines. 50927 (line 175) 50928* __mulhq3: Fixed-point fractional library routines. 50929 (line 163) 50930* __mulqq3: Fixed-point fractional library routines. 50931 (line 161) 50932* __mulsa3: Fixed-point fractional library routines. 50933 (line 177) 50934* __mulsc3: Soft float library routines. 50935 (line 237) 50936* __mulsf3: Soft float library routines. 50937 (line 38) 50938* __mulsi3: Integer library routines. 50939 (line 41) 50940* __mulsq3: Fixed-point fractional library routines. 50941 (line 164) 50942* __multa3: Fixed-point fractional library routines. 50943 (line 179) 50944* __multc3: Soft float library routines. 50945 (line 241) 50946* __multf3: Soft float library routines. 50947 (line 40) 50948* __multi3: Integer library routines. 50949 (line 43) 50950* __muluda3: Fixed-point fractional library routines. 50951 (line 185) 50952* __muludq3: Fixed-point fractional library routines. 50953 (line 173) 50954* __muluha3: Fixed-point fractional library routines. 50955 (line 181) 50956* __muluhq3: Fixed-point fractional library routines. 50957 (line 169) 50958* __muluqq3: Fixed-point fractional library routines. 50959 (line 167) 50960* __mulusa3: Fixed-point fractional library routines. 50961 (line 183) 50962* __mulusq3: Fixed-point fractional library routines. 50963 (line 171) 50964* __muluta3: Fixed-point fractional library routines. 50965 (line 187) 50966* __mulvdi3: Integer library routines. 50967 (line 114) 50968* __mulvsi3: Integer library routines. 50969 (line 113) 50970* __mulxc3: Soft float library routines. 50971 (line 243) 50972* __mulxf3: Soft float library routines. 50973 (line 42) 50974* __nedf2: Soft float library routines. 50975 (line 199) 50976* __negda2: Fixed-point fractional library routines. 50977 (line 306) 50978* __negdf2: Soft float library routines. 50979 (line 55) 50980* __negdi2: Integer library routines. 50981 (line 46) 50982* __negdq2: Fixed-point fractional library routines. 50983 (line 296) 50984* __negha2: Fixed-point fractional library routines. 50985 (line 304) 50986* __neghq2: Fixed-point fractional library routines. 50987 (line 294) 50988* __negqq2: Fixed-point fractional library routines. 50989 (line 293) 50990* __negsa2: Fixed-point fractional library routines. 50991 (line 305) 50992* __negsf2: Soft float library routines. 50993 (line 54) 50994* __negsq2: Fixed-point fractional library routines. 50995 (line 295) 50996* __negta2: Fixed-point fractional library routines. 50997 (line 307) 50998* __negtf2: Soft float library routines. 50999 (line 56) 51000* __negti2: Integer library routines. 51001 (line 47) 51002* __neguda2: Fixed-point fractional library routines. 51003 (line 311) 51004* __negudq2: Fixed-point fractional library routines. 51005 (line 302) 51006* __neguha2: Fixed-point fractional library routines. 51007 (line 308) 51008* __neguhq2: Fixed-point fractional library routines. 51009 (line 299) 51010* __neguqq2: Fixed-point fractional library routines. 51011 (line 297) 51012* __negusa2: Fixed-point fractional library routines. 51013 (line 310) 51014* __negusq2: Fixed-point fractional library routines. 51015 (line 300) 51016* __neguta2: Fixed-point fractional library routines. 51017 (line 313) 51018* __negvdi2: Integer library routines. 51019 (line 118) 51020* __negvsi2: Integer library routines. 51021 (line 117) 51022* __negxf2: Soft float library routines. 51023 (line 57) 51024* __nesf2: Soft float library routines. 51025 (line 198) 51026* __netf2: Soft float library routines. 51027 (line 200) 51028* __paritydi2: Integer library routines. 51029 (line 150) 51030* __paritysi2: Integer library routines. 51031 (line 149) 51032* __parityti2: Integer library routines. 51033 (line 151) 51034* __popcountdi2: Integer library routines. 51035 (line 156) 51036* __popcountsi2: Integer library routines. 51037 (line 155) 51038* __popcountti2: Integer library routines. 51039 (line 157) 51040* __powidf2: Soft float library routines. 51041 (line 232) 51042* __powisf2: Soft float library routines. 51043 (line 231) 51044* __powitf2: Soft float library routines. 51045 (line 233) 51046* __powixf2: Soft float library routines. 51047 (line 234) 51048* __satfractdadq: Fixed-point fractional library routines. 51049 (line 1160) 51050* __satfractdaha2: Fixed-point fractional library routines. 51051 (line 1161) 51052* __satfractdahq: Fixed-point fractional library routines. 51053 (line 1158) 51054* __satfractdaqq: Fixed-point fractional library routines. 51055 (line 1157) 51056* __satfractdasa2: Fixed-point fractional library routines. 51057 (line 1162) 51058* __satfractdasq: Fixed-point fractional library routines. 51059 (line 1159) 51060* __satfractdata2: Fixed-point fractional library routines. 51061 (line 1163) 51062* __satfractdauda: Fixed-point fractional library routines. 51063 (line 1173) 51064* __satfractdaudq: Fixed-point fractional library routines. 51065 (line 1168) 51066* __satfractdauha: Fixed-point fractional library routines. 51067 (line 1170) 51068* __satfractdauhq: Fixed-point fractional library routines. 51069 (line 1166) 51070* __satfractdauqq: Fixed-point fractional library routines. 51071 (line 1164) 51072* __satfractdausa: Fixed-point fractional library routines. 51073 (line 1172) 51074* __satfractdausq: Fixed-point fractional library routines. 51075 (line 1167) 51076* __satfractdauta: Fixed-point fractional library routines. 51077 (line 1174) 51078* __satfractdfda: Fixed-point fractional library routines. 51079 (line 1513) 51080* __satfractdfdq: Fixed-point fractional library routines. 51081 (line 1510) 51082* __satfractdfha: Fixed-point fractional library routines. 51083 (line 1511) 51084* __satfractdfhq: Fixed-point fractional library routines. 51085 (line 1508) 51086* __satfractdfqq: Fixed-point fractional library routines. 51087 (line 1507) 51088* __satfractdfsa: Fixed-point fractional library routines. 51089 (line 1512) 51090* __satfractdfsq: Fixed-point fractional library routines. 51091 (line 1509) 51092* __satfractdfta: Fixed-point fractional library routines. 51093 (line 1514) 51094* __satfractdfuda: Fixed-point fractional library routines. 51095 (line 1522) 51096* __satfractdfudq: Fixed-point fractional library routines. 51097 (line 1518) 51098* __satfractdfuha: Fixed-point fractional library routines. 51099 (line 1520) 51100* __satfractdfuhq: Fixed-point fractional library routines. 51101 (line 1516) 51102* __satfractdfuqq: Fixed-point fractional library routines. 51103 (line 1515) 51104* __satfractdfusa: Fixed-point fractional library routines. 51105 (line 1521) 51106* __satfractdfusq: Fixed-point fractional library routines. 51107 (line 1517) 51108* __satfractdfuta: Fixed-point fractional library routines. 51109 (line 1523) 51110* __satfractdida: Fixed-point fractional library routines. 51111 (line 1463) 51112* __satfractdidq: Fixed-point fractional library routines. 51113 (line 1460) 51114* __satfractdiha: Fixed-point fractional library routines. 51115 (line 1461) 51116* __satfractdihq: Fixed-point fractional library routines. 51117 (line 1458) 51118* __satfractdiqq: Fixed-point fractional library routines. 51119 (line 1457) 51120* __satfractdisa: Fixed-point fractional library routines. 51121 (line 1462) 51122* __satfractdisq: Fixed-point fractional library routines. 51123 (line 1459) 51124* __satfractdita: Fixed-point fractional library routines. 51125 (line 1464) 51126* __satfractdiuda: Fixed-point fractional library routines. 51127 (line 1471) 51128* __satfractdiudq: Fixed-point fractional library routines. 51129 (line 1468) 51130* __satfractdiuha: Fixed-point fractional library routines. 51131 (line 1469) 51132* __satfractdiuhq: Fixed-point fractional library routines. 51133 (line 1466) 51134* __satfractdiuqq: Fixed-point fractional library routines. 51135 (line 1465) 51136* __satfractdiusa: Fixed-point fractional library routines. 51137 (line 1470) 51138* __satfractdiusq: Fixed-point fractional library routines. 51139 (line 1467) 51140* __satfractdiuta: Fixed-point fractional library routines. 51141 (line 1472) 51142* __satfractdqda: Fixed-point fractional library routines. 51143 (line 1105) 51144* __satfractdqha: Fixed-point fractional library routines. 51145 (line 1103) 51146* __satfractdqhq2: Fixed-point fractional library routines. 51147 (line 1101) 51148* __satfractdqqq2: Fixed-point fractional library routines. 51149 (line 1100) 51150* __satfractdqsa: Fixed-point fractional library routines. 51151 (line 1104) 51152* __satfractdqsq2: Fixed-point fractional library routines. 51153 (line 1102) 51154* __satfractdqta: Fixed-point fractional library routines. 51155 (line 1106) 51156* __satfractdquda: Fixed-point fractional library routines. 51157 (line 1117) 51158* __satfractdqudq: Fixed-point fractional library routines. 51159 (line 1112) 51160* __satfractdquha: Fixed-point fractional library routines. 51161 (line 1114) 51162* __satfractdquhq: Fixed-point fractional library routines. 51163 (line 1109) 51164* __satfractdquqq: Fixed-point fractional library routines. 51165 (line 1107) 51166* __satfractdqusa: Fixed-point fractional library routines. 51167 (line 1116) 51168* __satfractdqusq: Fixed-point fractional library routines. 51169 (line 1110) 51170* __satfractdquta: Fixed-point fractional library routines. 51171 (line 1119) 51172* __satfracthada2: Fixed-point fractional library routines. 51173 (line 1126) 51174* __satfracthadq: Fixed-point fractional library routines. 51175 (line 1124) 51176* __satfracthahq: Fixed-point fractional library routines. 51177 (line 1122) 51178* __satfracthaqq: Fixed-point fractional library routines. 51179 (line 1121) 51180* __satfracthasa2: Fixed-point fractional library routines. 51181 (line 1125) 51182* __satfracthasq: Fixed-point fractional library routines. 51183 (line 1123) 51184* __satfracthata2: Fixed-point fractional library routines. 51185 (line 1127) 51186* __satfracthauda: Fixed-point fractional library routines. 51187 (line 1138) 51188* __satfracthaudq: Fixed-point fractional library routines. 51189 (line 1133) 51190* __satfracthauha: Fixed-point fractional library routines. 51191 (line 1135) 51192* __satfracthauhq: Fixed-point fractional library routines. 51193 (line 1130) 51194* __satfracthauqq: Fixed-point fractional library routines. 51195 (line 1128) 51196* __satfracthausa: Fixed-point fractional library routines. 51197 (line 1137) 51198* __satfracthausq: Fixed-point fractional library routines. 51199 (line 1131) 51200* __satfracthauta: Fixed-point fractional library routines. 51201 (line 1140) 51202* __satfracthida: Fixed-point fractional library routines. 51203 (line 1431) 51204* __satfracthidq: Fixed-point fractional library routines. 51205 (line 1428) 51206* __satfracthiha: Fixed-point fractional library routines. 51207 (line 1429) 51208* __satfracthihq: Fixed-point fractional library routines. 51209 (line 1426) 51210* __satfracthiqq: Fixed-point fractional library routines. 51211 (line 1425) 51212* __satfracthisa: Fixed-point fractional library routines. 51213 (line 1430) 51214* __satfracthisq: Fixed-point fractional library routines. 51215 (line 1427) 51216* __satfracthita: Fixed-point fractional library routines. 51217 (line 1432) 51218* __satfracthiuda: Fixed-point fractional library routines. 51219 (line 1439) 51220* __satfracthiudq: Fixed-point fractional library routines. 51221 (line 1436) 51222* __satfracthiuha: Fixed-point fractional library routines. 51223 (line 1437) 51224* __satfracthiuhq: Fixed-point fractional library routines. 51225 (line 1434) 51226* __satfracthiuqq: Fixed-point fractional library routines. 51227 (line 1433) 51228* __satfracthiusa: Fixed-point fractional library routines. 51229 (line 1438) 51230* __satfracthiusq: Fixed-point fractional library routines. 51231 (line 1435) 51232* __satfracthiuta: Fixed-point fractional library routines. 51233 (line 1440) 51234* __satfracthqda: Fixed-point fractional library routines. 51235 (line 1071) 51236* __satfracthqdq2: Fixed-point fractional library routines. 51237 (line 1068) 51238* __satfracthqha: Fixed-point fractional library routines. 51239 (line 1069) 51240* __satfracthqqq2: Fixed-point fractional library routines. 51241 (line 1066) 51242* __satfracthqsa: Fixed-point fractional library routines. 51243 (line 1070) 51244* __satfracthqsq2: Fixed-point fractional library routines. 51245 (line 1067) 51246* __satfracthqta: Fixed-point fractional library routines. 51247 (line 1072) 51248* __satfracthquda: Fixed-point fractional library routines. 51249 (line 1079) 51250* __satfracthqudq: Fixed-point fractional library routines. 51251 (line 1076) 51252* __satfracthquha: Fixed-point fractional library routines. 51253 (line 1077) 51254* __satfracthquhq: Fixed-point fractional library routines. 51255 (line 1074) 51256* __satfracthquqq: Fixed-point fractional library routines. 51257 (line 1073) 51258* __satfracthqusa: Fixed-point fractional library routines. 51259 (line 1078) 51260* __satfracthqusq: Fixed-point fractional library routines. 51261 (line 1075) 51262* __satfracthquta: Fixed-point fractional library routines. 51263 (line 1080) 51264* __satfractqida: Fixed-point fractional library routines. 51265 (line 1409) 51266* __satfractqidq: Fixed-point fractional library routines. 51267 (line 1406) 51268* __satfractqiha: Fixed-point fractional library routines. 51269 (line 1407) 51270* __satfractqihq: Fixed-point fractional library routines. 51271 (line 1404) 51272* __satfractqiqq: Fixed-point fractional library routines. 51273 (line 1403) 51274* __satfractqisa: Fixed-point fractional library routines. 51275 (line 1408) 51276* __satfractqisq: Fixed-point fractional library routines. 51277 (line 1405) 51278* __satfractqita: Fixed-point fractional library routines. 51279 (line 1410) 51280* __satfractqiuda: Fixed-point fractional library routines. 51281 (line 1421) 51282* __satfractqiudq: Fixed-point fractional library routines. 51283 (line 1416) 51284* __satfractqiuha: Fixed-point fractional library routines. 51285 (line 1418) 51286* __satfractqiuhq: Fixed-point fractional library routines. 51287 (line 1413) 51288* __satfractqiuqq: Fixed-point fractional library routines. 51289 (line 1411) 51290* __satfractqiusa: Fixed-point fractional library routines. 51291 (line 1420) 51292* __satfractqiusq: Fixed-point fractional library routines. 51293 (line 1414) 51294* __satfractqiuta: Fixed-point fractional library routines. 51295 (line 1423) 51296* __satfractqqda: Fixed-point fractional library routines. 51297 (line 1050) 51298* __satfractqqdq2: Fixed-point fractional library routines. 51299 (line 1047) 51300* __satfractqqha: Fixed-point fractional library routines. 51301 (line 1048) 51302* __satfractqqhq2: Fixed-point fractional library routines. 51303 (line 1045) 51304* __satfractqqsa: Fixed-point fractional library routines. 51305 (line 1049) 51306* __satfractqqsq2: Fixed-point fractional library routines. 51307 (line 1046) 51308* __satfractqqta: Fixed-point fractional library routines. 51309 (line 1051) 51310* __satfractqquda: Fixed-point fractional library routines. 51311 (line 1062) 51312* __satfractqqudq: Fixed-point fractional library routines. 51313 (line 1057) 51314* __satfractqquha: Fixed-point fractional library routines. 51315 (line 1059) 51316* __satfractqquhq: Fixed-point fractional library routines. 51317 (line 1054) 51318* __satfractqquqq: Fixed-point fractional library routines. 51319 (line 1052) 51320* __satfractqqusa: Fixed-point fractional library routines. 51321 (line 1061) 51322* __satfractqqusq: Fixed-point fractional library routines. 51323 (line 1055) 51324* __satfractqquta: Fixed-point fractional library routines. 51325 (line 1064) 51326* __satfractsada2: Fixed-point fractional library routines. 51327 (line 1147) 51328* __satfractsadq: Fixed-point fractional library routines. 51329 (line 1145) 51330* __satfractsaha2: Fixed-point fractional library routines. 51331 (line 1146) 51332* __satfractsahq: Fixed-point fractional library routines. 51333 (line 1143) 51334* __satfractsaqq: Fixed-point fractional library routines. 51335 (line 1142) 51336* __satfractsasq: Fixed-point fractional library routines. 51337 (line 1144) 51338* __satfractsata2: Fixed-point fractional library routines. 51339 (line 1148) 51340* __satfractsauda: Fixed-point fractional library routines. 51341 (line 1155) 51342* __satfractsaudq: Fixed-point fractional library routines. 51343 (line 1152) 51344* __satfractsauha: Fixed-point fractional library routines. 51345 (line 1153) 51346* __satfractsauhq: Fixed-point fractional library routines. 51347 (line 1150) 51348* __satfractsauqq: Fixed-point fractional library routines. 51349 (line 1149) 51350* __satfractsausa: Fixed-point fractional library routines. 51351 (line 1154) 51352* __satfractsausq: Fixed-point fractional library routines. 51353 (line 1151) 51354* __satfractsauta: Fixed-point fractional library routines. 51355 (line 1156) 51356* __satfractsfda: Fixed-point fractional library routines. 51357 (line 1497) 51358* __satfractsfdq: Fixed-point fractional library routines. 51359 (line 1494) 51360* __satfractsfha: Fixed-point fractional library routines. 51361 (line 1495) 51362* __satfractsfhq: Fixed-point fractional library routines. 51363 (line 1492) 51364* __satfractsfqq: Fixed-point fractional library routines. 51365 (line 1491) 51366* __satfractsfsa: Fixed-point fractional library routines. 51367 (line 1496) 51368* __satfractsfsq: Fixed-point fractional library routines. 51369 (line 1493) 51370* __satfractsfta: Fixed-point fractional library routines. 51371 (line 1498) 51372* __satfractsfuda: Fixed-point fractional library routines. 51373 (line 1505) 51374* __satfractsfudq: Fixed-point fractional library routines. 51375 (line 1502) 51376* __satfractsfuha: Fixed-point fractional library routines. 51377 (line 1503) 51378* __satfractsfuhq: Fixed-point fractional library routines. 51379 (line 1500) 51380* __satfractsfuqq: Fixed-point fractional library routines. 51381 (line 1499) 51382* __satfractsfusa: Fixed-point fractional library routines. 51383 (line 1504) 51384* __satfractsfusq: Fixed-point fractional library routines. 51385 (line 1501) 51386* __satfractsfuta: Fixed-point fractional library routines. 51387 (line 1506) 51388* __satfractsida: Fixed-point fractional library routines. 51389 (line 1447) 51390* __satfractsidq: Fixed-point fractional library routines. 51391 (line 1444) 51392* __satfractsiha: Fixed-point fractional library routines. 51393 (line 1445) 51394* __satfractsihq: Fixed-point fractional library routines. 51395 (line 1442) 51396* __satfractsiqq: Fixed-point fractional library routines. 51397 (line 1441) 51398* __satfractsisa: Fixed-point fractional library routines. 51399 (line 1446) 51400* __satfractsisq: Fixed-point fractional library routines. 51401 (line 1443) 51402* __satfractsita: Fixed-point fractional library routines. 51403 (line 1448) 51404* __satfractsiuda: Fixed-point fractional library routines. 51405 (line 1455) 51406* __satfractsiudq: Fixed-point fractional library routines. 51407 (line 1452) 51408* __satfractsiuha: Fixed-point fractional library routines. 51409 (line 1453) 51410* __satfractsiuhq: Fixed-point fractional library routines. 51411 (line 1450) 51412* __satfractsiuqq: Fixed-point fractional library routines. 51413 (line 1449) 51414* __satfractsiusa: Fixed-point fractional library routines. 51415 (line 1454) 51416* __satfractsiusq: Fixed-point fractional library routines. 51417 (line 1451) 51418* __satfractsiuta: Fixed-point fractional library routines. 51419 (line 1456) 51420* __satfractsqda: Fixed-point fractional library routines. 51421 (line 1086) 51422* __satfractsqdq2: Fixed-point fractional library routines. 51423 (line 1083) 51424* __satfractsqha: Fixed-point fractional library routines. 51425 (line 1084) 51426* __satfractsqhq2: Fixed-point fractional library routines. 51427 (line 1082) 51428* __satfractsqqq2: Fixed-point fractional library routines. 51429 (line 1081) 51430* __satfractsqsa: Fixed-point fractional library routines. 51431 (line 1085) 51432* __satfractsqta: Fixed-point fractional library routines. 51433 (line 1087) 51434* __satfractsquda: Fixed-point fractional library routines. 51435 (line 1097) 51436* __satfractsqudq: Fixed-point fractional library routines. 51437 (line 1092) 51438* __satfractsquha: Fixed-point fractional library routines. 51439 (line 1094) 51440* __satfractsquhq: Fixed-point fractional library routines. 51441 (line 1090) 51442* __satfractsquqq: Fixed-point fractional library routines. 51443 (line 1088) 51444* __satfractsqusa: Fixed-point fractional library routines. 51445 (line 1096) 51446* __satfractsqusq: Fixed-point fractional library routines. 51447 (line 1091) 51448* __satfractsquta: Fixed-point fractional library routines. 51449 (line 1098) 51450* __satfracttada2: Fixed-point fractional library routines. 51451 (line 1182) 51452* __satfracttadq: Fixed-point fractional library routines. 51453 (line 1179) 51454* __satfracttaha2: Fixed-point fractional library routines. 51455 (line 1180) 51456* __satfracttahq: Fixed-point fractional library routines. 51457 (line 1177) 51458* __satfracttaqq: Fixed-point fractional library routines. 51459 (line 1176) 51460* __satfracttasa2: Fixed-point fractional library routines. 51461 (line 1181) 51462* __satfracttasq: Fixed-point fractional library routines. 51463 (line 1178) 51464* __satfracttauda: Fixed-point fractional library routines. 51465 (line 1193) 51466* __satfracttaudq: Fixed-point fractional library routines. 51467 (line 1188) 51468* __satfracttauha: Fixed-point fractional library routines. 51469 (line 1190) 51470* __satfracttauhq: Fixed-point fractional library routines. 51471 (line 1185) 51472* __satfracttauqq: Fixed-point fractional library routines. 51473 (line 1183) 51474* __satfracttausa: Fixed-point fractional library routines. 51475 (line 1192) 51476* __satfracttausq: Fixed-point fractional library routines. 51477 (line 1186) 51478* __satfracttauta: Fixed-point fractional library routines. 51479 (line 1195) 51480* __satfracttida: Fixed-point fractional library routines. 51481 (line 1479) 51482* __satfracttidq: Fixed-point fractional library routines. 51483 (line 1476) 51484* __satfracttiha: Fixed-point fractional library routines. 51485 (line 1477) 51486* __satfracttihq: Fixed-point fractional library routines. 51487 (line 1474) 51488* __satfracttiqq: Fixed-point fractional library routines. 51489 (line 1473) 51490* __satfracttisa: Fixed-point fractional library routines. 51491 (line 1478) 51492* __satfracttisq: Fixed-point fractional library routines. 51493 (line 1475) 51494* __satfracttita: Fixed-point fractional library routines. 51495 (line 1480) 51496* __satfracttiuda: Fixed-point fractional library routines. 51497 (line 1488) 51498* __satfracttiudq: Fixed-point fractional library routines. 51499 (line 1484) 51500* __satfracttiuha: Fixed-point fractional library routines. 51501 (line 1486) 51502* __satfracttiuhq: Fixed-point fractional library routines. 51503 (line 1482) 51504* __satfracttiuqq: Fixed-point fractional library routines. 51505 (line 1481) 51506* __satfracttiusa: Fixed-point fractional library routines. 51507 (line 1487) 51508* __satfracttiusq: Fixed-point fractional library routines. 51509 (line 1483) 51510* __satfracttiuta: Fixed-point fractional library routines. 51511 (line 1489) 51512* __satfractudada: Fixed-point fractional library routines. 51513 (line 1358) 51514* __satfractudadq: Fixed-point fractional library routines. 51515 (line 1353) 51516* __satfractudaha: Fixed-point fractional library routines. 51517 (line 1355) 51518* __satfractudahq: Fixed-point fractional library routines. 51519 (line 1351) 51520* __satfractudaqq: Fixed-point fractional library routines. 51521 (line 1349) 51522* __satfractudasa: Fixed-point fractional library routines. 51523 (line 1357) 51524* __satfractudasq: Fixed-point fractional library routines. 51525 (line 1352) 51526* __satfractudata: Fixed-point fractional library routines. 51527 (line 1359) 51528* __satfractudaudq: Fixed-point fractional library routines. 51529 (line 1367) 51530* __satfractudauha2: Fixed-point fractional library routines. 51531 (line 1369) 51532* __satfractudauhq: Fixed-point fractional library routines. 51533 (line 1363) 51534* __satfractudauqq: Fixed-point fractional library routines. 51535 (line 1361) 51536* __satfractudausa2: Fixed-point fractional library routines. 51537 (line 1371) 51538* __satfractudausq: Fixed-point fractional library routines. 51539 (line 1365) 51540* __satfractudauta2: Fixed-point fractional library routines. 51541 (line 1373) 51542* __satfractudqda: Fixed-point fractional library routines. 51543 (line 1282) 51544* __satfractudqdq: Fixed-point fractional library routines. 51545 (line 1277) 51546* __satfractudqha: Fixed-point fractional library routines. 51547 (line 1279) 51548* __satfractudqhq: Fixed-point fractional library routines. 51549 (line 1274) 51550* __satfractudqqq: Fixed-point fractional library routines. 51551 (line 1272) 51552* __satfractudqsa: Fixed-point fractional library routines. 51553 (line 1281) 51554* __satfractudqsq: Fixed-point fractional library routines. 51555 (line 1275) 51556* __satfractudqta: Fixed-point fractional library routines. 51557 (line 1284) 51558* __satfractudquda: Fixed-point fractional library routines. 51559 (line 1296) 51560* __satfractudquha: Fixed-point fractional library routines. 51561 (line 1292) 51562* __satfractudquhq2: Fixed-point fractional library routines. 51563 (line 1288) 51564* __satfractudquqq2: Fixed-point fractional library routines. 51565 (line 1286) 51566* __satfractudqusa: Fixed-point fractional library routines. 51567 (line 1294) 51568* __satfractudqusq2: Fixed-point fractional library routines. 51569 (line 1290) 51570* __satfractudquta: Fixed-point fractional library routines. 51571 (line 1298) 51572* __satfractuhada: Fixed-point fractional library routines. 51573 (line 1310) 51574* __satfractuhadq: Fixed-point fractional library routines. 51575 (line 1305) 51576* __satfractuhaha: Fixed-point fractional library routines. 51577 (line 1307) 51578* __satfractuhahq: Fixed-point fractional library routines. 51579 (line 1302) 51580* __satfractuhaqq: Fixed-point fractional library routines. 51581 (line 1300) 51582* __satfractuhasa: Fixed-point fractional library routines. 51583 (line 1309) 51584* __satfractuhasq: Fixed-point fractional library routines. 51585 (line 1303) 51586* __satfractuhata: Fixed-point fractional library routines. 51587 (line 1312) 51588* __satfractuhauda2: Fixed-point fractional library routines. 51589 (line 1324) 51590* __satfractuhaudq: Fixed-point fractional library routines. 51591 (line 1320) 51592* __satfractuhauhq: Fixed-point fractional library routines. 51593 (line 1316) 51594* __satfractuhauqq: Fixed-point fractional library routines. 51595 (line 1314) 51596* __satfractuhausa2: Fixed-point fractional library routines. 51597 (line 1322) 51598* __satfractuhausq: Fixed-point fractional library routines. 51599 (line 1318) 51600* __satfractuhauta2: Fixed-point fractional library routines. 51601 (line 1326) 51602* __satfractuhqda: Fixed-point fractional library routines. 51603 (line 1231) 51604* __satfractuhqdq: Fixed-point fractional library routines. 51605 (line 1228) 51606* __satfractuhqha: Fixed-point fractional library routines. 51607 (line 1229) 51608* __satfractuhqhq: Fixed-point fractional library routines. 51609 (line 1226) 51610* __satfractuhqqq: Fixed-point fractional library routines. 51611 (line 1225) 51612* __satfractuhqsa: Fixed-point fractional library routines. 51613 (line 1230) 51614* __satfractuhqsq: Fixed-point fractional library routines. 51615 (line 1227) 51616* __satfractuhqta: Fixed-point fractional library routines. 51617 (line 1232) 51618* __satfractuhquda: Fixed-point fractional library routines. 51619 (line 1242) 51620* __satfractuhqudq2: Fixed-point fractional library routines. 51621 (line 1237) 51622* __satfractuhquha: Fixed-point fractional library routines. 51623 (line 1239) 51624* __satfractuhquqq2: Fixed-point fractional library routines. 51625 (line 1233) 51626* __satfractuhqusa: Fixed-point fractional library routines. 51627 (line 1241) 51628* __satfractuhqusq2: Fixed-point fractional library routines. 51629 (line 1235) 51630* __satfractuhquta: Fixed-point fractional library routines. 51631 (line 1244) 51632* __satfractunsdida: Fixed-point fractional library routines. 51633 (line 1841) 51634* __satfractunsdidq: Fixed-point fractional library routines. 51635 (line 1837) 51636* __satfractunsdiha: Fixed-point fractional library routines. 51637 (line 1839) 51638* __satfractunsdihq: Fixed-point fractional library routines. 51639 (line 1835) 51640* __satfractunsdiqq: Fixed-point fractional library routines. 51641 (line 1834) 51642* __satfractunsdisa: Fixed-point fractional library routines. 51643 (line 1840) 51644* __satfractunsdisq: Fixed-point fractional library routines. 51645 (line 1836) 51646* __satfractunsdita: Fixed-point fractional library routines. 51647 (line 1842) 51648* __satfractunsdiuda: Fixed-point fractional library routines. 51649 (line 1856) 51650* __satfractunsdiudq: Fixed-point fractional library routines. 51651 (line 1850) 51652* __satfractunsdiuha: Fixed-point fractional library routines. 51653 (line 1852) 51654* __satfractunsdiuhq: Fixed-point fractional library routines. 51655 (line 1846) 51656* __satfractunsdiuqq: Fixed-point fractional library routines. 51657 (line 1844) 51658* __satfractunsdiusa: Fixed-point fractional library routines. 51659 (line 1854) 51660* __satfractunsdiusq: Fixed-point fractional library routines. 51661 (line 1848) 51662* __satfractunsdiuta: Fixed-point fractional library routines. 51663 (line 1858) 51664* __satfractunshida: Fixed-point fractional library routines. 51665 (line 1793) 51666* __satfractunshidq: Fixed-point fractional library routines. 51667 (line 1789) 51668* __satfractunshiha: Fixed-point fractional library routines. 51669 (line 1791) 51670* __satfractunshihq: Fixed-point fractional library routines. 51671 (line 1787) 51672* __satfractunshiqq: Fixed-point fractional library routines. 51673 (line 1786) 51674* __satfractunshisa: Fixed-point fractional library routines. 51675 (line 1792) 51676* __satfractunshisq: Fixed-point fractional library routines. 51677 (line 1788) 51678* __satfractunshita: Fixed-point fractional library routines. 51679 (line 1794) 51680* __satfractunshiuda: Fixed-point fractional library routines. 51681 (line 1808) 51682* __satfractunshiudq: Fixed-point fractional library routines. 51683 (line 1802) 51684* __satfractunshiuha: Fixed-point fractional library routines. 51685 (line 1804) 51686* __satfractunshiuhq: Fixed-point fractional library routines. 51687 (line 1798) 51688* __satfractunshiuqq: Fixed-point fractional library routines. 51689 (line 1796) 51690* __satfractunshiusa: Fixed-point fractional library routines. 51691 (line 1806) 51692* __satfractunshiusq: Fixed-point fractional library routines. 51693 (line 1800) 51694* __satfractunshiuta: Fixed-point fractional library routines. 51695 (line 1810) 51696* __satfractunsqida: Fixed-point fractional library routines. 51697 (line 1767) 51698* __satfractunsqidq: Fixed-point fractional library routines. 51699 (line 1763) 51700* __satfractunsqiha: Fixed-point fractional library routines. 51701 (line 1765) 51702* __satfractunsqihq: Fixed-point fractional library routines. 51703 (line 1761) 51704* __satfractunsqiqq: Fixed-point fractional library routines. 51705 (line 1760) 51706* __satfractunsqisa: Fixed-point fractional library routines. 51707 (line 1766) 51708* __satfractunsqisq: Fixed-point fractional library routines. 51709 (line 1762) 51710* __satfractunsqita: Fixed-point fractional library routines. 51711 (line 1768) 51712* __satfractunsqiuda: Fixed-point fractional library routines. 51713 (line 1782) 51714* __satfractunsqiudq: Fixed-point fractional library routines. 51715 (line 1776) 51716* __satfractunsqiuha: Fixed-point fractional library routines. 51717 (line 1778) 51718* __satfractunsqiuhq: Fixed-point fractional library routines. 51719 (line 1772) 51720* __satfractunsqiuqq: Fixed-point fractional library routines. 51721 (line 1770) 51722* __satfractunsqiusa: Fixed-point fractional library routines. 51723 (line 1780) 51724* __satfractunsqiusq: Fixed-point fractional library routines. 51725 (line 1774) 51726* __satfractunsqiuta: Fixed-point fractional library routines. 51727 (line 1784) 51728* __satfractunssida: Fixed-point fractional library routines. 51729 (line 1818) 51730* __satfractunssidq: Fixed-point fractional library routines. 51731 (line 1815) 51732* __satfractunssiha: Fixed-point fractional library routines. 51733 (line 1816) 51734* __satfractunssihq: Fixed-point fractional library routines. 51735 (line 1813) 51736* __satfractunssiqq: Fixed-point fractional library routines. 51737 (line 1812) 51738* __satfractunssisa: Fixed-point fractional library routines. 51739 (line 1817) 51740* __satfractunssisq: Fixed-point fractional library routines. 51741 (line 1814) 51742* __satfractunssita: Fixed-point fractional library routines. 51743 (line 1819) 51744* __satfractunssiuda: Fixed-point fractional library routines. 51745 (line 1830) 51746* __satfractunssiudq: Fixed-point fractional library routines. 51747 (line 1825) 51748* __satfractunssiuha: Fixed-point fractional library routines. 51749 (line 1827) 51750* __satfractunssiuhq: Fixed-point fractional library routines. 51751 (line 1822) 51752* __satfractunssiuqq: Fixed-point fractional library routines. 51753 (line 1820) 51754* __satfractunssiusa: Fixed-point fractional library routines. 51755 (line 1829) 51756* __satfractunssiusq: Fixed-point fractional library routines. 51757 (line 1823) 51758* __satfractunssiuta: Fixed-point fractional library routines. 51759 (line 1832) 51760* __satfractunstida: Fixed-point fractional library routines. 51761 (line 1870) 51762* __satfractunstidq: Fixed-point fractional library routines. 51763 (line 1865) 51764* __satfractunstiha: Fixed-point fractional library routines. 51765 (line 1867) 51766* __satfractunstihq: Fixed-point fractional library routines. 51767 (line 1862) 51768* __satfractunstiqq: Fixed-point fractional library routines. 51769 (line 1860) 51770* __satfractunstisa: Fixed-point fractional library routines. 51771 (line 1869) 51772* __satfractunstisq: Fixed-point fractional library routines. 51773 (line 1863) 51774* __satfractunstita: Fixed-point fractional library routines. 51775 (line 1872) 51776* __satfractunstiuda: Fixed-point fractional library routines. 51777 (line 1886) 51778* __satfractunstiudq: Fixed-point fractional library routines. 51779 (line 1880) 51780* __satfractunstiuha: Fixed-point fractional library routines. 51781 (line 1882) 51782* __satfractunstiuhq: Fixed-point fractional library routines. 51783 (line 1876) 51784* __satfractunstiuqq: Fixed-point fractional library routines. 51785 (line 1874) 51786* __satfractunstiusa: Fixed-point fractional library routines. 51787 (line 1884) 51788* __satfractunstiusq: Fixed-point fractional library routines. 51789 (line 1878) 51790* __satfractunstiuta: Fixed-point fractional library routines. 51791 (line 1888) 51792* __satfractuqqda: Fixed-point fractional library routines. 51793 (line 1207) 51794* __satfractuqqdq: Fixed-point fractional library routines. 51795 (line 1202) 51796* __satfractuqqha: Fixed-point fractional library routines. 51797 (line 1204) 51798* __satfractuqqhq: Fixed-point fractional library routines. 51799 (line 1199) 51800* __satfractuqqqq: Fixed-point fractional library routines. 51801 (line 1197) 51802* __satfractuqqsa: Fixed-point fractional library routines. 51803 (line 1206) 51804* __satfractuqqsq: Fixed-point fractional library routines. 51805 (line 1200) 51806* __satfractuqqta: Fixed-point fractional library routines. 51807 (line 1209) 51808* __satfractuqquda: Fixed-point fractional library routines. 51809 (line 1221) 51810* __satfractuqqudq2: Fixed-point fractional library routines. 51811 (line 1215) 51812* __satfractuqquha: Fixed-point fractional library routines. 51813 (line 1217) 51814* __satfractuqquhq2: Fixed-point fractional library routines. 51815 (line 1211) 51816* __satfractuqqusa: Fixed-point fractional library routines. 51817 (line 1219) 51818* __satfractuqqusq2: Fixed-point fractional library routines. 51819 (line 1213) 51820* __satfractuqquta: Fixed-point fractional library routines. 51821 (line 1223) 51822* __satfractusada: Fixed-point fractional library routines. 51823 (line 1334) 51824* __satfractusadq: Fixed-point fractional library routines. 51825 (line 1331) 51826* __satfractusaha: Fixed-point fractional library routines. 51827 (line 1332) 51828* __satfractusahq: Fixed-point fractional library routines. 51829 (line 1329) 51830* __satfractusaqq: Fixed-point fractional library routines. 51831 (line 1328) 51832* __satfractusasa: Fixed-point fractional library routines. 51833 (line 1333) 51834* __satfractusasq: Fixed-point fractional library routines. 51835 (line 1330) 51836* __satfractusata: Fixed-point fractional library routines. 51837 (line 1335) 51838* __satfractusauda2: Fixed-point fractional library routines. 51839 (line 1345) 51840* __satfractusaudq: Fixed-point fractional library routines. 51841 (line 1341) 51842* __satfractusauha2: Fixed-point fractional library routines. 51843 (line 1343) 51844* __satfractusauhq: Fixed-point fractional library routines. 51845 (line 1338) 51846* __satfractusauqq: Fixed-point fractional library routines. 51847 (line 1336) 51848* __satfractusausq: Fixed-point fractional library routines. 51849 (line 1339) 51850* __satfractusauta2: Fixed-point fractional library routines. 51851 (line 1347) 51852* __satfractusqda: Fixed-point fractional library routines. 51853 (line 1255) 51854* __satfractusqdq: Fixed-point fractional library routines. 51855 (line 1250) 51856* __satfractusqha: Fixed-point fractional library routines. 51857 (line 1252) 51858* __satfractusqhq: Fixed-point fractional library routines. 51859 (line 1248) 51860* __satfractusqqq: Fixed-point fractional library routines. 51861 (line 1246) 51862* __satfractusqsa: Fixed-point fractional library routines. 51863 (line 1254) 51864* __satfractusqsq: Fixed-point fractional library routines. 51865 (line 1249) 51866* __satfractusqta: Fixed-point fractional library routines. 51867 (line 1256) 51868* __satfractusquda: Fixed-point fractional library routines. 51869 (line 1268) 51870* __satfractusqudq2: Fixed-point fractional library routines. 51871 (line 1262) 51872* __satfractusquha: Fixed-point fractional library routines. 51873 (line 1264) 51874* __satfractusquhq2: Fixed-point fractional library routines. 51875 (line 1260) 51876* __satfractusquqq2: Fixed-point fractional library routines. 51877 (line 1258) 51878* __satfractusqusa: Fixed-point fractional library routines. 51879 (line 1266) 51880* __satfractusquta: Fixed-point fractional library routines. 51881 (line 1270) 51882* __satfractutada: Fixed-point fractional library routines. 51883 (line 1385) 51884* __satfractutadq: Fixed-point fractional library routines. 51885 (line 1380) 51886* __satfractutaha: Fixed-point fractional library routines. 51887 (line 1382) 51888* __satfractutahq: Fixed-point fractional library routines. 51889 (line 1377) 51890* __satfractutaqq: Fixed-point fractional library routines. 51891 (line 1375) 51892* __satfractutasa: Fixed-point fractional library routines. 51893 (line 1384) 51894* __satfractutasq: Fixed-point fractional library routines. 51895 (line 1378) 51896* __satfractutata: Fixed-point fractional library routines. 51897 (line 1387) 51898* __satfractutauda2: Fixed-point fractional library routines. 51899 (line 1401) 51900* __satfractutaudq: Fixed-point fractional library routines. 51901 (line 1395) 51902* __satfractutauha2: Fixed-point fractional library routines. 51903 (line 1397) 51904* __satfractutauhq: Fixed-point fractional library routines. 51905 (line 1391) 51906* __satfractutauqq: Fixed-point fractional library routines. 51907 (line 1389) 51908* __satfractutausa2: Fixed-point fractional library routines. 51909 (line 1399) 51910* __satfractutausq: Fixed-point fractional library routines. 51911 (line 1393) 51912* __splitstack_find: Miscellaneous routines. 51913 (line 15) 51914* __ssaddda3: Fixed-point fractional library routines. 51915 (line 74) 51916* __ssadddq3: Fixed-point fractional library routines. 51917 (line 69) 51918* __ssaddha3: Fixed-point fractional library routines. 51919 (line 71) 51920* __ssaddhq3: Fixed-point fractional library routines. 51921 (line 67) 51922* __ssaddqq3: Fixed-point fractional library routines. 51923 (line 65) 51924* __ssaddsa3: Fixed-point fractional library routines. 51925 (line 73) 51926* __ssaddsq3: Fixed-point fractional library routines. 51927 (line 68) 51928* __ssaddta3: Fixed-point fractional library routines. 51929 (line 75) 51930* __ssashlda3: Fixed-point fractional library routines. 51931 (line 409) 51932* __ssashldq3: Fixed-point fractional library routines. 51933 (line 405) 51934* __ssashlha3: Fixed-point fractional library routines. 51935 (line 407) 51936* __ssashlhq3: Fixed-point fractional library routines. 51937 (line 403) 51938* __ssashlsa3: Fixed-point fractional library routines. 51939 (line 408) 51940* __ssashlsq3: Fixed-point fractional library routines. 51941 (line 404) 51942* __ssashlta3: Fixed-point fractional library routines. 51943 (line 410) 51944* __ssdivda3: Fixed-point fractional library routines. 51945 (line 268) 51946* __ssdivdq3: Fixed-point fractional library routines. 51947 (line 263) 51948* __ssdivha3: Fixed-point fractional library routines. 51949 (line 265) 51950* __ssdivhq3: Fixed-point fractional library routines. 51951 (line 261) 51952* __ssdivqq3: Fixed-point fractional library routines. 51953 (line 259) 51954* __ssdivsa3: Fixed-point fractional library routines. 51955 (line 267) 51956* __ssdivsq3: Fixed-point fractional library routines. 51957 (line 262) 51958* __ssdivta3: Fixed-point fractional library routines. 51959 (line 269) 51960* __ssmulda3: Fixed-point fractional library routines. 51961 (line 200) 51962* __ssmuldq3: Fixed-point fractional library routines. 51963 (line 195) 51964* __ssmulha3: Fixed-point fractional library routines. 51965 (line 197) 51966* __ssmulhq3: Fixed-point fractional library routines. 51967 (line 193) 51968* __ssmulqq3: Fixed-point fractional library routines. 51969 (line 191) 51970* __ssmulsa3: Fixed-point fractional library routines. 51971 (line 199) 51972* __ssmulsq3: Fixed-point fractional library routines. 51973 (line 194) 51974* __ssmulta3: Fixed-point fractional library routines. 51975 (line 201) 51976* __ssnegda2: Fixed-point fractional library routines. 51977 (line 323) 51978* __ssnegdq2: Fixed-point fractional library routines. 51979 (line 320) 51980* __ssnegha2: Fixed-point fractional library routines. 51981 (line 321) 51982* __ssneghq2: Fixed-point fractional library routines. 51983 (line 318) 51984* __ssnegqq2: Fixed-point fractional library routines. 51985 (line 317) 51986* __ssnegsa2: Fixed-point fractional library routines. 51987 (line 322) 51988* __ssnegsq2: Fixed-point fractional library routines. 51989 (line 319) 51990* __ssnegta2: Fixed-point fractional library routines. 51991 (line 324) 51992* __sssubda3: Fixed-point fractional library routines. 51993 (line 136) 51994* __sssubdq3: Fixed-point fractional library routines. 51995 (line 131) 51996* __sssubha3: Fixed-point fractional library routines. 51997 (line 133) 51998* __sssubhq3: Fixed-point fractional library routines. 51999 (line 129) 52000* __sssubqq3: Fixed-point fractional library routines. 52001 (line 127) 52002* __sssubsa3: Fixed-point fractional library routines. 52003 (line 135) 52004* __sssubsq3: Fixed-point fractional library routines. 52005 (line 130) 52006* __sssubta3: Fixed-point fractional library routines. 52007 (line 137) 52008* __subda3: Fixed-point fractional library routines. 52009 (line 114) 52010* __subdf3: Soft float library routines. 52011 (line 30) 52012* __subdq3: Fixed-point fractional library routines. 52013 (line 101) 52014* __subha3: Fixed-point fractional library routines. 52015 (line 111) 52016* __subhq3: Fixed-point fractional library routines. 52017 (line 99) 52018* __subqq3: Fixed-point fractional library routines. 52019 (line 97) 52020* __subsa3: Fixed-point fractional library routines. 52021 (line 113) 52022* __subsf3: Soft float library routines. 52023 (line 29) 52024* __subsq3: Fixed-point fractional library routines. 52025 (line 100) 52026* __subta3: Fixed-point fractional library routines. 52027 (line 115) 52028* __subtf3: Soft float library routines. 52029 (line 31) 52030* __subuda3: Fixed-point fractional library routines. 52031 (line 121) 52032* __subudq3: Fixed-point fractional library routines. 52033 (line 109) 52034* __subuha3: Fixed-point fractional library routines. 52035 (line 117) 52036* __subuhq3: Fixed-point fractional library routines. 52037 (line 105) 52038* __subuqq3: Fixed-point fractional library routines. 52039 (line 103) 52040* __subusa3: Fixed-point fractional library routines. 52041 (line 119) 52042* __subusq3: Fixed-point fractional library routines. 52043 (line 107) 52044* __subuta3: Fixed-point fractional library routines. 52045 (line 123) 52046* __subvdi3: Integer library routines. 52047 (line 122) 52048* __subvsi3: Integer library routines. 52049 (line 121) 52050* __subxf3: Soft float library routines. 52051 (line 33) 52052* __truncdfsf2: Soft float library routines. 52053 (line 75) 52054* __trunctfdf2: Soft float library routines. 52055 (line 72) 52056* __trunctfsf2: Soft float library routines. 52057 (line 74) 52058* __truncxfdf2: Soft float library routines. 52059 (line 71) 52060* __truncxfsf2: Soft float library routines. 52061 (line 73) 52062* __ucmpdi2: Integer library routines. 52063 (line 92) 52064* __ucmpti2: Integer library routines. 52065 (line 93) 52066* __udivdi3: Integer library routines. 52067 (line 52) 52068* __udivmoddi4: Integer library routines. 52069 (line 59) 52070* __udivmodti4: Integer library routines. 52071 (line 61) 52072* __udivsi3: Integer library routines. 52073 (line 50) 52074* __udivti3: Integer library routines. 52075 (line 54) 52076* __udivuda3: Fixed-point fractional library routines. 52077 (line 252) 52078* __udivudq3: Fixed-point fractional library routines. 52079 (line 246) 52080* __udivuha3: Fixed-point fractional library routines. 52081 (line 248) 52082* __udivuhq3: Fixed-point fractional library routines. 52083 (line 242) 52084* __udivuqq3: Fixed-point fractional library routines. 52085 (line 240) 52086* __udivusa3: Fixed-point fractional library routines. 52087 (line 250) 52088* __udivusq3: Fixed-point fractional library routines. 52089 (line 244) 52090* __udivuta3: Fixed-point fractional library routines. 52091 (line 254) 52092* __umoddi3: Integer library routines. 52093 (line 69) 52094* __umodsi3: Integer library routines. 52095 (line 67) 52096* __umodti3: Integer library routines. 52097 (line 71) 52098* __unorddf2: Soft float library routines. 52099 (line 172) 52100* __unordsf2: Soft float library routines. 52101 (line 171) 52102* __unordtf2: Soft float library routines. 52103 (line 173) 52104* __usadduda3: Fixed-point fractional library routines. 52105 (line 91) 52106* __usaddudq3: Fixed-point fractional library routines. 52107 (line 85) 52108* __usadduha3: Fixed-point fractional library routines. 52109 (line 87) 52110* __usadduhq3: Fixed-point fractional library routines. 52111 (line 81) 52112* __usadduqq3: Fixed-point fractional library routines. 52113 (line 79) 52114* __usaddusa3: Fixed-point fractional library routines. 52115 (line 89) 52116* __usaddusq3: Fixed-point fractional library routines. 52117 (line 83) 52118* __usadduta3: Fixed-point fractional library routines. 52119 (line 93) 52120* __usashluda3: Fixed-point fractional library routines. 52121 (line 427) 52122* __usashludq3: Fixed-point fractional library routines. 52123 (line 421) 52124* __usashluha3: Fixed-point fractional library routines. 52125 (line 423) 52126* __usashluhq3: Fixed-point fractional library routines. 52127 (line 417) 52128* __usashluqq3: Fixed-point fractional library routines. 52129 (line 415) 52130* __usashlusa3: Fixed-point fractional library routines. 52131 (line 425) 52132* __usashlusq3: Fixed-point fractional library routines. 52133 (line 419) 52134* __usashluta3: Fixed-point fractional library routines. 52135 (line 429) 52136* __usdivuda3: Fixed-point fractional library routines. 52137 (line 286) 52138* __usdivudq3: Fixed-point fractional library routines. 52139 (line 280) 52140* __usdivuha3: Fixed-point fractional library routines. 52141 (line 282) 52142* __usdivuhq3: Fixed-point fractional library routines. 52143 (line 276) 52144* __usdivuqq3: Fixed-point fractional library routines. 52145 (line 274) 52146* __usdivusa3: Fixed-point fractional library routines. 52147 (line 284) 52148* __usdivusq3: Fixed-point fractional library routines. 52149 (line 278) 52150* __usdivuta3: Fixed-point fractional library routines. 52151 (line 288) 52152* __usmuluda3: Fixed-point fractional library routines. 52153 (line 218) 52154* __usmuludq3: Fixed-point fractional library routines. 52155 (line 212) 52156* __usmuluha3: Fixed-point fractional library routines. 52157 (line 214) 52158* __usmuluhq3: Fixed-point fractional library routines. 52159 (line 208) 52160* __usmuluqq3: Fixed-point fractional library routines. 52161 (line 206) 52162* __usmulusa3: Fixed-point fractional library routines. 52163 (line 216) 52164* __usmulusq3: Fixed-point fractional library routines. 52165 (line 210) 52166* __usmuluta3: Fixed-point fractional library routines. 52167 (line 220) 52168* __usneguda2: Fixed-point fractional library routines. 52169 (line 337) 52170* __usnegudq2: Fixed-point fractional library routines. 52171 (line 332) 52172* __usneguha2: Fixed-point fractional library routines. 52173 (line 334) 52174* __usneguhq2: Fixed-point fractional library routines. 52175 (line 329) 52176* __usneguqq2: Fixed-point fractional library routines. 52177 (line 327) 52178* __usnegusa2: Fixed-point fractional library routines. 52179 (line 336) 52180* __usnegusq2: Fixed-point fractional library routines. 52181 (line 330) 52182* __usneguta2: Fixed-point fractional library routines. 52183 (line 339) 52184* __ussubuda3: Fixed-point fractional library routines. 52185 (line 154) 52186* __ussubudq3: Fixed-point fractional library routines. 52187 (line 148) 52188* __ussubuha3: Fixed-point fractional library routines. 52189 (line 150) 52190* __ussubuhq3: Fixed-point fractional library routines. 52191 (line 144) 52192* __ussubuqq3: Fixed-point fractional library routines. 52193 (line 142) 52194* __ussubusa3: Fixed-point fractional library routines. 52195 (line 152) 52196* __ussubusq3: Fixed-point fractional library routines. 52197 (line 146) 52198* __ussubuta3: Fixed-point fractional library routines. 52199 (line 156) 52200* abort: Portability. (line 20) 52201* abs: Arithmetic. (line 200) 52202* abs and attributes: Expressions. (line 83) 52203* absence_set: Processor pipeline description. 52204 (line 223) 52205* absM2 instruction pattern: Standard Names. (line 879) 52206* absolute value: Arithmetic. (line 200) 52207* ABSU_EXPR: Unary and Binary Expressions. 52208 (line 6) 52209* ABS_EXPR: Unary and Binary Expressions. 52210 (line 6) 52211* access to operands: Accessors. (line 6) 52212* access to special operands: Special Accessors. (line 6) 52213* accessors: Accessors. (line 6) 52214* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 48) 52215* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 140) 52216* ACCUM_TYPE_SIZE: Type Layout. (line 87) 52217* acosM2 instruction pattern: Standard Names. (line 966) 52218* ADA_LONG_TYPE_SIZE: Type Layout. (line 25) 52219* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 52220 (line 6) 52221* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 14) 52222* addM3 instruction pattern: Standard Names. (line 436) 52223* addMODEcc instruction pattern: Standard Names. (line 1589) 52224* addptrM3 instruction pattern: Standard Names. (line 469) 52225* address constraints: Simple Constraints. (line 162) 52226* addressing modes: Addressing Modes. (line 6) 52227* address_operand: Machine-Independent Predicates. 52228 (line 62) 52229* address_operand <1>: Simple Constraints. (line 166) 52230* addr_diff_vec: Side Effects. (line 314) 52231* addr_diff_vec, length of: Insn Lengths. (line 26) 52232* ADDR_EXPR: Storage References. (line 6) 52233* addr_vec: Side Effects. (line 309) 52234* addr_vec, length of: Insn Lengths. (line 26) 52235* addvM4 instruction pattern: Standard Names. (line 452) 52236* ADJUST_FIELD_ALIGN: Storage Layout. (line 212) 52237* ADJUST_INSN_LENGTH: Insn Lengths. (line 41) 52238* ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 22) 52239* aggregates as return values: Aggregate Return. (line 6) 52240* alias: Alias analysis. (line 6) 52241* allocate_stack instruction pattern: Standard Names. (line 1956) 52242* ALL_REGS: Register Classes. (line 17) 52243* alternate entry points: Insns. (line 146) 52244* analyzer: Static Analyzer. (line 6) 52245* analyzer, debugging: Debugging the Analyzer. 52246 (line 6) 52247* analyzer, internals: Analyzer Internals. (line 6) 52248* anchored addresses: Anchored Addresses. (line 6) 52249* and: Arithmetic. (line 158) 52250* and and attributes: Expressions. (line 50) 52251* and, canonicalization of: Insn Canonicalizations. 52252 (line 67) 52253* andM3 instruction pattern: Standard Names. (line 442) 52254* ANNOTATE_EXPR: Unary and Binary Expressions. 52255 (line 6) 52256* annotations: Annotations. (line 6) 52257* APPLY_RESULT_SIZE: Scalar Return. (line 112) 52258* ARGS_GROW_DOWNWARD: Frame Layout. (line 30) 52259* argument passing: Interface. (line 36) 52260* arguments in registers: Register Arguments. (line 6) 52261* arguments on stack: Stack Arguments. (line 6) 52262* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 207) 52263* ARG_POINTER_REGNUM: Frame Registers. (line 40) 52264* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 52265* arg_pointer_rtx: Frame Registers. (line 104) 52266* arithmetic library: Soft float library routines. 52267 (line 6) 52268* arithmetic shift: Arithmetic. (line 173) 52269* arithmetic shift with signed saturation: Arithmetic. (line 173) 52270* arithmetic shift with unsigned saturation: Arithmetic. (line 173) 52271* arithmetic, in RTL: Arithmetic. (line 6) 52272* ARITHMETIC_TYPE_P: Types for C++. (line 59) 52273* array: Types. (line 6) 52274* ARRAY_RANGE_REF: Storage References. (line 6) 52275* ARRAY_REF: Storage References. (line 6) 52276* ARRAY_TYPE: Types. (line 6) 52277* ashift: Arithmetic. (line 173) 52278* ashift and attributes: Expressions. (line 83) 52279* ashiftrt: Arithmetic. (line 190) 52280* ashiftrt and attributes: Expressions. (line 83) 52281* ashlM3 instruction pattern: Standard Names. (line 828) 52282* ashrM3 instruction pattern: Standard Names. (line 840) 52283* asinM2 instruction pattern: Standard Names. (line 960) 52284* ASM_APP_OFF: File Framework. (line 76) 52285* ASM_APP_ON: File Framework. (line 69) 52286* ASM_COMMENT_START: File Framework. (line 64) 52287* ASM_DECLARE_COLD_FUNCTION_NAME: Label Output. (line 136) 52288* ASM_DECLARE_COLD_FUNCTION_SIZE: Label Output. (line 151) 52289* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 108) 52290* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 123) 52291* ASM_DECLARE_OBJECT_NAME: Label Output. (line 164) 52292* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 192) 52293* ASM_FINAL_SPEC: Driver. (line 81) 52294* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 200) 52295* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 426) 52296* asm_fprintf: Instruction Output. (line 150) 52297* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 160) 52298* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 410) 52299* asm_input: Side Effects. (line 296) 52300* asm_input and /v: Flags. (line 65) 52301* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 80) 52302* asm_noperands: Insns. (line 327) 52303* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 59) 52304* asm_operands and /v: Flags. (line 65) 52305* asm_operands, RTL sharing: Sharing. (line 48) 52306* asm_operands, usage: Assembler. (line 6) 52307* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 8) 52308* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 25) 52309* ASM_OUTPUT_ALIGN: Alignment Output. (line 66) 52310* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 45) 52311* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 29) 52312* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 36) 52313* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 89) 52314* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 82) 52315* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 71) 52316* ASM_OUTPUT_ASCII: Data Output. (line 60) 52317* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 50) 52318* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 37) 52319* ASM_OUTPUT_COMMON: Uninitialized Data. (line 9) 52320* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 398) 52321* ASM_OUTPUT_DEF: Label Output. (line 447) 52322* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 454) 52323* ASM_OUTPUT_DWARF_DATAREL: DWARF. (line 110) 52324* ASM_OUTPUT_DWARF_DELTA: DWARF. (line 89) 52325* ASM_OUTPUT_DWARF_OFFSET: DWARF. (line 98) 52326* ASM_OUTPUT_DWARF_PCREL: DWARF. (line 105) 52327* ASM_OUTPUT_DWARF_TABLE_REF: DWARF. (line 115) 52328* ASM_OUTPUT_DWARF_VMS_DELTA: DWARF. (line 93) 52329* ASM_OUTPUT_EXTERNAL: Label Output. (line 327) 52330* ASM_OUTPUT_FDESC: Data Output. (line 69) 52331* ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 16) 52332* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 27) 52333* ASM_OUTPUT_LABEL: Label Output. (line 8) 52334* ASM_OUTPUT_LABELREF: Label Output. (line 349) 52335* ASM_OUTPUT_LABEL_REF: Label Output. (line 371) 52336* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 69) 52337* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 75) 52338* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 51) 52339* ASM_OUTPUT_OPCODE: Instruction Output. (line 35) 52340* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 118) 52341* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 82) 52342* ASM_OUTPUT_REG_POP: Instruction Output. (line 206) 52343* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 201) 52344* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 45) 52345* ASM_OUTPUT_SKIP: Alignment Output. (line 53) 52346* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 83) 52347* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 93) 52348* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 364) 52349* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 98) 52350* ASM_OUTPUT_WEAKREF: Label Output. (line 259) 52351* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 473) 52352* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 66) 52353* ASM_SPEC: Driver. (line 73) 52354* ASM_STABD_OP: DBX Options. (line 34) 52355* ASM_STABN_OP: DBX Options. (line 41) 52356* ASM_STABS_OP: DBX Options. (line 28) 52357* ASM_WEAKEN_DECL: Label Output. (line 251) 52358* ASM_WEAKEN_LABEL: Label Output. (line 238) 52359* assembler format: File Framework. (line 6) 52360* assembler instructions in RTL: Assembler. (line 6) 52361* ASSEMBLER_DIALECT: Instruction Output. (line 172) 52362* assemble_name: Label Output. (line 8) 52363* assemble_name_raw: Label Output. (line 27) 52364* assigning attribute values to insns: Tagging Insns. (line 6) 52365* ASSUME_EXTENDED_UNWIND_CONTEXT: Frame Registers. (line 163) 52366* asterisk in template: Output Statement. (line 29) 52367* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 88) 52368* atan2M3 instruction pattern: Standard Names. (line 1061) 52369* atanM2 instruction pattern: Standard Names. (line 972) 52370* atomic: GTY Options. (line 197) 52371* atomic_addMODE instruction pattern: Standard Names. (line 2380) 52372* atomic_add_fetchMODE instruction pattern: Standard Names. (line 2409) 52373* atomic_andMODE instruction pattern: Standard Names. (line 2380) 52374* atomic_and_fetchMODE instruction pattern: Standard Names. (line 2409) 52375* atomic_bit_test_and_complementMODE instruction pattern: Standard Names. 52376 (line 2437) 52377* atomic_bit_test_and_resetMODE instruction pattern: Standard Names. 52378 (line 2437) 52379* atomic_bit_test_and_setMODE instruction pattern: Standard Names. 52380 (line 2437) 52381* atomic_compare_and_swapMODE instruction pattern: Standard Names. 52382 (line 2316) 52383* atomic_exchangeMODE instruction pattern: Standard Names. (line 2368) 52384* atomic_fetch_addMODE instruction pattern: Standard Names. (line 2394) 52385* atomic_fetch_andMODE instruction pattern: Standard Names. (line 2394) 52386* atomic_fetch_nandMODE instruction pattern: Standard Names. (line 2394) 52387* atomic_fetch_orMODE instruction pattern: Standard Names. (line 2394) 52388* atomic_fetch_subMODE instruction pattern: Standard Names. (line 2394) 52389* atomic_fetch_xorMODE instruction pattern: Standard Names. (line 2394) 52390* atomic_loadMODE instruction pattern: Standard Names. (line 2347) 52391* atomic_nandMODE instruction pattern: Standard Names. (line 2380) 52392* atomic_nand_fetchMODE instruction pattern: Standard Names. (line 2409) 52393* atomic_orMODE instruction pattern: Standard Names. (line 2380) 52394* atomic_or_fetchMODE instruction pattern: Standard Names. (line 2409) 52395* atomic_storeMODE instruction pattern: Standard Names. (line 2357) 52396* atomic_subMODE instruction pattern: Standard Names. (line 2380) 52397* atomic_sub_fetchMODE instruction pattern: Standard Names. (line 2409) 52398* atomic_test_and_set instruction pattern: Standard Names. (line 2426) 52399* atomic_xorMODE instruction pattern: Standard Names. (line 2380) 52400* atomic_xor_fetchMODE instruction pattern: Standard Names. (line 2409) 52401* attr: Expressions. (line 163) 52402* attr <1>: Tagging Insns. (line 54) 52403* attribute expressions: Expressions. (line 6) 52404* attribute specifications: Attr Example. (line 6) 52405* attribute specifications example: Attr Example. (line 6) 52406* attributes: Attributes. (line 6) 52407* attributes, defining: Defining Attributes. 52408 (line 6) 52409* attributes, target-specific: Target Attributes. (line 6) 52410* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 194) 52411* attr_flag: Expressions. (line 138) 52412* autoincrement addressing, availability: Portability. (line 20) 52413* autoincrement/decrement addressing: Simple Constraints. (line 30) 52414* automata_option: Processor pipeline description. 52415 (line 304) 52416* automaton based pipeline description: Processor pipeline description. 52417 (line 6) 52418* automaton based pipeline description <1>: Processor pipeline description. 52419 (line 49) 52420* automaton based scheduler: Processor pipeline description. 52421 (line 6) 52422* avgM3_ceil instruction pattern: Standard Names. (line 860) 52423* avgM3_floor instruction pattern: Standard Names. (line 848) 52424* AVOID_CCMODE_COPIES: Values in Registers. 52425 (line 148) 52426* backslash: Output Template. (line 46) 52427* barrier: Insns. (line 176) 52428* barrier and /f: Flags. (line 135) 52429* barrier and /v: Flags. (line 33) 52430* BASE_REG_CLASS: Register Classes. (line 111) 52431* basic block: Basic Blocks. (line 6) 52432* Basic Statements: Basic Statements. (line 6) 52433* basic-block.h: Control Flow. (line 6) 52434* basic_block: Basic Blocks. (line 6) 52435* BASIC_BLOCK: Basic Blocks. (line 14) 52436* BB_HEAD, BB_END: Maintaining the CFG. 52437 (line 76) 52438* bb_seq: GIMPLE sequences. (line 72) 52439* BIGGEST_ALIGNMENT: Storage Layout. (line 179) 52440* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 205) 52441* BImode: Machine Modes. (line 22) 52442* BIND_EXPR: Unary and Binary Expressions. 52443 (line 6) 52444* BINFO_TYPE: Classes. (line 6) 52445* bit-fields: Bit-Fields. (line 6) 52446* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 428) 52447* BITS_BIG_ENDIAN: Storage Layout. (line 11) 52448* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 52449* BITS_PER_UNIT: Machine Modes. (line 440) 52450* BITS_PER_WORD: Storage Layout. (line 50) 52451* bitwise complement: Arithmetic. (line 154) 52452* bitwise exclusive-or: Arithmetic. (line 168) 52453* bitwise inclusive-or: Arithmetic. (line 163) 52454* bitwise logical-and: Arithmetic. (line 158) 52455* BIT_AND_EXPR: Unary and Binary Expressions. 52456 (line 6) 52457* BIT_IOR_EXPR: Unary and Binary Expressions. 52458 (line 6) 52459* BIT_NOT_EXPR: Unary and Binary Expressions. 52460 (line 6) 52461* BIT_XOR_EXPR: Unary and Binary Expressions. 52462 (line 6) 52463* BLKmode: Machine Modes. (line 185) 52464* BLKmode, and function return values: Calls. (line 23) 52465* blockage instruction pattern: Standard Names. (line 2156) 52466* Blocks: Blocks. (line 6) 52467* BLOCK_FOR_INSN, gimple_bb: Maintaining the CFG. 52468 (line 28) 52469* BLOCK_REG_PADDING: Register Arguments. (line 238) 52470* BND32mode: Machine Modes. (line 210) 52471* BND64mode: Machine Modes. (line 210) 52472* bool: Misc. (line 958) 52473* BOOLEAN_TYPE: Types. (line 6) 52474* BOOL_TYPE_SIZE: Type Layout. (line 43) 52475* branch prediction: Profile information. 52476 (line 24) 52477* BRANCH_COST: Costs. (line 104) 52478* break_out_memory_refs: Addressing Modes. (line 134) 52479* BREAK_STMT: Statements for C++. (line 6) 52480* BSS_SECTION_ASM_OP: Sections. (line 67) 52481* bswap: Arithmetic. (line 246) 52482* bswapM2 instruction pattern: Standard Names. (line 868) 52483* btruncM2 instruction pattern: Standard Names. (line 1078) 52484* build0: Macros and Functions. 52485 (line 16) 52486* build1: Macros and Functions. 52487 (line 17) 52488* build2: Macros and Functions. 52489 (line 18) 52490* build3: Macros and Functions. 52491 (line 19) 52492* build4: Macros and Functions. 52493 (line 20) 52494* build5: Macros and Functions. 52495 (line 21) 52496* build6: Macros and Functions. 52497 (line 22) 52498* builtin_longjmp instruction pattern: Standard Names. (line 2054) 52499* builtin_setjmp_receiver instruction pattern: Standard Names. 52500 (line 2044) 52501* builtin_setjmp_setup instruction pattern: Standard Names. (line 2033) 52502* BYTES_BIG_ENDIAN: Storage Layout. (line 23) 52503* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 229) 52504* byte_mode: Machine Modes. (line 458) 52505* C statements for assembler output: Output Statement. (line 6) 52506* cache: GTY Options. (line 127) 52507* call: Flags. (line 230) 52508* call <1>: Side Effects. (line 92) 52509* call instruction pattern: Standard Names. (line 1709) 52510* call usage: Calls. (line 10) 52511* call, in call_insn: Flags. (line 129) 52512* call, in mem: Flags. (line 70) 52513* call-clobbered register: Register Basics. (line 35) 52514* call-clobbered register <1>: Register Basics. (line 50) 52515* call-clobbered register <2>: Register Basics. (line 58) 52516* call-clobbered register <3>: Register Basics. (line 76) 52517* call-saved register: Register Basics. (line 35) 52518* call-saved register <1>: Register Basics. (line 50) 52519* call-saved register <2>: Register Basics. (line 58) 52520* call-saved register <3>: Register Basics. (line 76) 52521* call-used register: Register Basics. (line 35) 52522* call-used register <1>: Register Basics. (line 50) 52523* call-used register <2>: Register Basics. (line 58) 52524* call-used register <3>: Register Basics. (line 76) 52525* calling conventions: Stack and Calling. (line 6) 52526* calling functions in RTL: Calls. (line 6) 52527* CALL_EXPR: Unary and Binary Expressions. 52528 (line 6) 52529* call_insn: Insns. (line 95) 52530* call_insn and /c: Flags. (line 129) 52531* call_insn and /f: Flags. (line 135) 52532* call_insn and /i: Flags. (line 120) 52533* call_insn and /j: Flags. (line 175) 52534* call_insn and /s: Flags. (line 38) 52535* call_insn and /s <1>: Flags. (line 162) 52536* call_insn and /u: Flags. (line 28) 52537* call_insn and /u <1>: Flags. (line 115) 52538* call_insn and /u or /i: Flags. (line 125) 52539* call_insn and /v: Flags. (line 33) 52540* CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 52541* call_pop instruction pattern: Standard Names. (line 1737) 52542* CALL_POPS_ARGS: Stack Arguments. (line 138) 52543* CALL_REALLY_USED_REGISTERS: Register Basics. (line 49) 52544* CALL_USED_REGISTERS: Register Basics. (line 34) 52545* call_used_regs: Register Basics. (line 102) 52546* call_value instruction pattern: Standard Names. (line 1729) 52547* call_value_pop instruction pattern: Standard Names. (line 1737) 52548* canadian: Configure Terms. (line 6) 52549* canonicalization of instructions: Insn Canonicalizations. 52550 (line 6) 52551* canonicalize_funcptr_for_compare instruction pattern: Standard Names. 52552 (line 1888) 52553* can_create_pseudo_p: Standard Names. (line 75) 52554* can_fallthru: Basic Blocks. (line 67) 52555* caret: Multi-Alternative. (line 53) 52556* caret <1>: Guidelines for Diagnostics. 52557 (line 159) 52558* casesi instruction pattern: Standard Names. (line 1830) 52559* CASE_VECTOR_MODE: Misc. (line 26) 52560* CASE_VECTOR_PC_RELATIVE: Misc. (line 39) 52561* CASE_VECTOR_SHORTEN_MODE: Misc. (line 30) 52562* cbranchMODE4 instruction pattern: Standard Names. (line 1698) 52563* cc0: Regs and Memory. (line 329) 52564* cc0 <1>: CC0 Condition Codes. 52565 (line 6) 52566* cc0, RTL sharing: Sharing. (line 30) 52567* cc0_rtx: Regs and Memory. (line 355) 52568* CC1PLUS_SPEC: Driver. (line 63) 52569* CC1_SPEC: Driver. (line 55) 52570* CCmode: Machine Modes. (line 178) 52571* CCmode <1>: MODE_CC Condition Codes. 52572 (line 6) 52573* cc_status: CC0 Condition Codes. 52574 (line 6) 52575* CC_STATUS_MDEP: CC0 Condition Codes. 52576 (line 16) 52577* CC_STATUS_MDEP_INIT: CC0 Condition Codes. 52578 (line 22) 52579* CDImode: Machine Modes. (line 204) 52580* ceilM2 instruction pattern: Standard Names. (line 1097) 52581* CEIL_DIV_EXPR: Unary and Binary Expressions. 52582 (line 6) 52583* CEIL_MOD_EXPR: Unary and Binary Expressions. 52584 (line 6) 52585* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 239) 52586* CFG verification: Maintaining the CFG. 52587 (line 116) 52588* CFG, Control Flow Graph: Control Flow. (line 6) 52589* cfghooks.h: Maintaining the CFG. 52590 (line 6) 52591* cgraph_finalize_function: Parsing pass. (line 51) 52592* chain_circular: GTY Options. (line 160) 52593* chain_next: GTY Options. (line 160) 52594* chain_prev: GTY Options. (line 160) 52595* change_address: Standard Names. (line 47) 52596* CHAR_TYPE_SIZE: Type Layout. (line 38) 52597* check_raw_ptrsM instruction pattern: Standard Names. (line 330) 52598* check_stack instruction pattern: Standard Names. (line 1974) 52599* check_war_ptrsM instruction pattern: Standard Names. (line 349) 52600* CHImode: Machine Modes. (line 204) 52601* class definitions, register: Register Classes. (line 6) 52602* class preference constraints: Class Preferences. (line 6) 52603* class, scope: Classes. (line 6) 52604* classes of RTX codes: RTL Classes. (line 6) 52605* CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 52606* CLASSTYPE_HAS_MUTABLE: Classes. (line 82) 52607* CLASSTYPE_NON_POD_P: Classes. (line 87) 52608* CLASS_MAX_NREGS: Register Classes. (line 531) 52609* CLASS_TYPE_P: Types for C++. (line 63) 52610* Cleanups: Cleanups. (line 6) 52611* CLEANUP_DECL: Statements for C++. (line 6) 52612* CLEANUP_EXPR: Statements for C++. (line 6) 52613* CLEANUP_POINT_EXPR: Unary and Binary Expressions. 52614 (line 6) 52615* CLEANUP_STMT: Statements for C++. (line 6) 52616* clear_cache instruction pattern: Standard Names. (line 2543) 52617* CLEAR_INSN_CACHE: Trampolines. (line 151) 52618* CLEAR_RATIO: Costs. (line 225) 52619* clobber: Side Effects. (line 106) 52620* clrsb: Arithmetic. (line 215) 52621* clrsbM2 instruction pattern: Standard Names. (line 1170) 52622* clz: Arithmetic. (line 222) 52623* clzM2 instruction pattern: Standard Names. (line 1186) 52624* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 338) 52625* cmpmemM instruction pattern: Standard Names. (line 1389) 52626* cmpstrM instruction pattern: Standard Names. (line 1368) 52627* cmpstrnM instruction pattern: Standard Names. (line 1355) 52628* code generation RTL sequences: Expander Definitions. 52629 (line 6) 52630* code iterators in .md files: Code Iterators. (line 6) 52631* codes, RTL expression: RTL Objects. (line 47) 52632* code_label: Insns. (line 125) 52633* CODE_LABEL: Basic Blocks. (line 50) 52634* code_label and /i: Flags. (line 48) 52635* code_label and /v: Flags. (line 33) 52636* CODE_LABEL_NUMBER: Insns. (line 125) 52637* COImode: Machine Modes. (line 204) 52638* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 52639* COLLECT_EXPORT_LIST: Misc. (line 864) 52640* COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 52641 (line 43) 52642* COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 52643 (line 32) 52644* command-line options, guidelines for: Guidelines for Options. 52645 (line 6) 52646* commit_edge_insertions: Maintaining the CFG. 52647 (line 104) 52648* compare: Arithmetic. (line 46) 52649* compare, canonicalization of: Insn Canonicalizations. 52650 (line 36) 52651* COMPARE_MAX_PIECES: Costs. (line 220) 52652* comparison_operator: Machine-Independent Predicates. 52653 (line 110) 52654* compiler passes and files: Passes. (line 6) 52655* complement, bitwise: Arithmetic. (line 154) 52656* COMPLEX_CST: Constant expressions. 52657 (line 6) 52658* COMPLEX_EXPR: Unary and Binary Expressions. 52659 (line 6) 52660* complex_mode: Machine Modes. (line 302) 52661* COMPLEX_TYPE: Types. (line 6) 52662* COMPONENT_REF: Storage References. (line 6) 52663* Compound Expressions: Compound Expressions. 52664 (line 6) 52665* Compound Lvalues: Compound Lvalues. (line 6) 52666* COMPOUND_EXPR: Unary and Binary Expressions. 52667 (line 6) 52668* COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 52669 (line 6) 52670* COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 52671 (line 392) 52672* COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 52673 (line 392) 52674* computed jump: Edges. (line 127) 52675* computing the length of an insn: Insn Lengths. (line 6) 52676* concat: Regs and Memory. (line 407) 52677* concatn: Regs and Memory. (line 413) 52678* cond: Comparisons. (line 90) 52679* cond and attributes: Expressions. (line 37) 52680* condition code register: Regs and Memory. (line 329) 52681* condition code status: Condition Code. (line 6) 52682* condition codes: Comparisons. (line 20) 52683* conditional execution: Conditional Execution. 52684 (line 6) 52685* Conditional Expressions: Conditional Expressions. 52686 (line 6) 52687* conditions, in patterns: Patterns. (line 55) 52688* cond_addMODE instruction pattern: Standard Names. (line 1596) 52689* cond_andMODE instruction pattern: Standard Names. (line 1596) 52690* cond_divMODE instruction pattern: Standard Names. (line 1596) 52691* cond_exec: Side Effects. (line 254) 52692* COND_EXPR: Unary and Binary Expressions. 52693 (line 6) 52694* cond_fmaMODE instruction pattern: Standard Names. (line 1634) 52695* cond_fmsMODE instruction pattern: Standard Names. (line 1634) 52696* cond_fnmaMODE instruction pattern: Standard Names. (line 1634) 52697* cond_fnmsMODE instruction pattern: Standard Names. (line 1634) 52698* cond_iorMODE instruction pattern: Standard Names. (line 1596) 52699* cond_modMODE instruction pattern: Standard Names. (line 1596) 52700* cond_mulMODE instruction pattern: Standard Names. (line 1596) 52701* cond_smaxMODE instruction pattern: Standard Names. (line 1596) 52702* cond_sminMODE instruction pattern: Standard Names. (line 1596) 52703* cond_subMODE instruction pattern: Standard Names. (line 1596) 52704* cond_udivMODE instruction pattern: Standard Names. (line 1596) 52705* cond_umaxMODE instruction pattern: Standard Names. (line 1596) 52706* cond_uminMODE instruction pattern: Standard Names. (line 1596) 52707* cond_umodMODE instruction pattern: Standard Names. (line 1596) 52708* cond_xorMODE instruction pattern: Standard Names. (line 1596) 52709* configuration file: Filesystem. (line 6) 52710* configuration file <1>: Host Misc. (line 6) 52711* configure terms: Configure Terms. (line 6) 52712* CONJ_EXPR: Unary and Binary Expressions. 52713 (line 6) 52714* const: Constants. (line 212) 52715* const0_rtx: Constants. (line 21) 52716* CONST0_RTX: Constants. (line 230) 52717* const1_rtx: Constants. (line 21) 52718* CONST1_RTX: Constants. (line 230) 52719* const2_rtx: Constants. (line 21) 52720* CONST2_RTX: Constants. (line 230) 52721* constant attributes: Constant Attributes. 52722 (line 6) 52723* constant definitions: Constant Definitions. 52724 (line 6) 52725* constants in constraints: Simple Constraints. (line 68) 52726* CONSTANT_ADDRESS_P: Addressing Modes. (line 28) 52727* CONSTANT_P: Addressing Modes. (line 35) 52728* CONSTANT_POOL_ADDRESS_P: Flags. (line 19) 52729* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 74) 52730* constm1_rtx: Constants. (line 21) 52731* constraint modifier characters: Modifiers. (line 6) 52732* constraint, matching: Simple Constraints. (line 140) 52733* constraints: Constraints. (line 6) 52734* constraints, defining: Define Constraints. (line 6) 52735* constraints, machine specific: Machine Constraints. 52736 (line 6) 52737* constraints, testing: C Constraint Interface. 52738 (line 6) 52739* constraint_num: C Constraint Interface. 52740 (line 30) 52741* constraint_satisfied_p: C Constraint Interface. 52742 (line 42) 52743* CONSTRUCTOR: Unary and Binary Expressions. 52744 (line 6) 52745* constructors, automatic calls: Collect2. (line 15) 52746* constructors, output of: Initialization. (line 6) 52747* CONST_DECL: Declarations. (line 6) 52748* const_double: Constants. (line 37) 52749* const_double, RTL sharing: Sharing. (line 32) 52750* CONST_DOUBLE_LOW: Constants. (line 54) 52751* const_double_operand: Machine-Independent Predicates. 52752 (line 20) 52753* const_fixed: Constants. (line 93) 52754* const_int: Constants. (line 8) 52755* const_int and attribute tests: Expressions. (line 47) 52756* const_int and attributes: Expressions. (line 10) 52757* const_int, RTL sharing: Sharing. (line 23) 52758* const_int_operand: Machine-Independent Predicates. 52759 (line 15) 52760* const_poly_int: Constants. (line 100) 52761* const_poly_int, RTL sharing: Sharing. (line 25) 52762* const_string: Constants. (line 184) 52763* const_string and attributes: Expressions. (line 20) 52764* const_true_rtx: Constants. (line 31) 52765* const_vector: Constants. (line 107) 52766* const_vector, RTL sharing: Sharing. (line 35) 52767* CONST_WIDE_INT: Constants. (line 67) 52768* CONST_WIDE_INT_ELT: Constants. (line 89) 52769* CONST_WIDE_INT_NUNITS: Constants. (line 84) 52770* CONST_WIDE_INT_VEC: Constants. (line 80) 52771* container: Containers. (line 6) 52772* CONTINUE_STMT: Statements for C++. (line 6) 52773* contributors: Contributors. (line 6) 52774* controlling register usage: Register Basics. (line 116) 52775* controlling the compilation driver: Driver. (line 6) 52776* conventions, run-time: Interface. (line 6) 52777* conversions: Conversions. (line 6) 52778* CONVERT_EXPR: Unary and Binary Expressions. 52779 (line 6) 52780* copysignM3 instruction pattern: Standard Names. (line 1142) 52781* copy_rtx: Addressing Modes. (line 189) 52782* copy_rtx_if_shared: Sharing. (line 67) 52783* cosM2 instruction pattern: Standard Names. (line 931) 52784* costs of instructions: Costs. (line 6) 52785* CPLUSPLUS_CPP_SPEC: Driver. (line 50) 52786* CPP_SPEC: Driver. (line 43) 52787* CPSImode: Machine Modes. (line 204) 52788* cpymemM instruction pattern: Standard Names. (line 1244) 52789* CP_INTEGRAL_TYPE: Types for C++. (line 55) 52790* cp_namespace_decls: Namespaces. (line 49) 52791* CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 52792* CP_TYPE_CONST_P: Types for C++. (line 24) 52793* cp_type_quals: Types for C++. (line 6) 52794* cp_type_quals <1>: Types for C++. (line 16) 52795* CP_TYPE_RESTRICT_P: Types for C++. (line 30) 52796* CP_TYPE_VOLATILE_P: Types for C++. (line 27) 52797* CQImode: Machine Modes. (line 204) 52798* cross compilation and floating point: Floating Point. (line 6) 52799* CROSSING_JUMP_P: Flags. (line 10) 52800* crtl->args.pops_args: Function Entry. (line 111) 52801* crtl->args.pretend_args_size: Function Entry. (line 117) 52802* crtl->outgoing_args_size: Stack Arguments. (line 48) 52803* CRTSTUFF_T_CFLAGS: Target Fragment. (line 15) 52804* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 19) 52805* CRT_CALL_STATIC_FUNCTION: Sections. (line 125) 52806* CSImode: Machine Modes. (line 204) 52807* cstoreMODE4 instruction pattern: Standard Names. (line 1659) 52808* CTImode: Machine Modes. (line 204) 52809* ctrapMM4 instruction pattern: Standard Names. (line 2125) 52810* ctz: Arithmetic. (line 230) 52811* ctzM2 instruction pattern: Standard Names. (line 1201) 52812* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 339) 52813* CUMULATIVE_ARGS: Register Arguments. (line 137) 52814* current_function_is_leaf: Leaf Functions. (line 50) 52815* current_function_uses_only_leaf_regs: Leaf Functions. (line 50) 52816* current_insn_predicate: Conditional Execution. 52817 (line 27) 52818* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 136) 52819* c_register_pragma: Misc. (line 440) 52820* c_register_pragma_with_expansion: Misc. (line 442) 52821* DAmode: Machine Modes. (line 154) 52822* data bypass: Processor pipeline description. 52823 (line 105) 52824* data bypass <1>: Processor pipeline description. 52825 (line 196) 52826* data dependence delays: Processor pipeline description. 52827 (line 6) 52828* Data Dependency Analysis: Dependency analysis. 52829 (line 6) 52830* data structures: Per-Function Data. (line 6) 52831* DATA_ABI_ALIGNMENT: Storage Layout. (line 263) 52832* DATA_ALIGNMENT: Storage Layout. (line 250) 52833* DATA_SECTION_ASM_OP: Sections. (line 52) 52834* DBR_OUTPUT_SEQEND: Instruction Output. (line 133) 52835* dbr_sequence_length: Instruction Output. (line 133) 52836* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 100) 52837* DBX_CONTIN_CHAR: DBX Options. (line 63) 52838* DBX_CONTIN_LENGTH: DBX Options. (line 53) 52839* DBX_DEBUGGING_INFO: DBX Options. (line 8) 52840* DBX_FUNCTION_FIRST: DBX Options. (line 94) 52841* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 106) 52842* DBX_NO_XREFS: DBX Options. (line 47) 52843* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 8) 52844* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 33) 52845* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 52846 (line 41) 52847* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 8) 52848* DBX_REGISTER_NUMBER: All Debuggers. (line 8) 52849* DBX_REGPARM_STABS_CODE: DBX Options. (line 84) 52850* DBX_REGPARM_STABS_LETTER: DBX Options. (line 89) 52851* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 79) 52852* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 70) 52853* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 75) 52854* DBX_USE_BINCL: DBX Options. (line 112) 52855* DCmode: Machine Modes. (line 199) 52856* DDmode: Machine Modes. (line 93) 52857* De Morgan's law: Insn Canonicalizations. 52858 (line 67) 52859* dead_or_set_p: define_peephole. (line 65) 52860* DEBUGGER_ARG_OFFSET: All Debuggers. (line 35) 52861* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 27) 52862* debug_expr: Debug Information. (line 22) 52863* DEBUG_EXPR_DECL: Declarations. (line 6) 52864* debug_implicit_ptr: Debug Information. (line 27) 52865* debug_insn: Insns. (line 247) 52866* debug_marker: Debug Information. (line 37) 52867* debug_parameter_ref: Debug Information. (line 34) 52868* DEBUG_SYMS_TEXT: DBX Options. (line 24) 52869* decimal float library: Decimal float library routines. 52870 (line 6) 52871* declaration: Declarations. (line 6) 52872* declarations, RTL: RTL Declarations. (line 6) 52873* DECLARE_LIBRARY_RENAMES: Library Calls. (line 8) 52874* DECL_ALIGN: Declarations. (line 6) 52875* DECL_ANTICIPATED: Functions for C++. (line 42) 52876* DECL_ARGUMENTS: Function Basics. (line 36) 52877* DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 52878* DECL_ARTIFICIAL: Working with declarations. 52879 (line 24) 52880* DECL_ARTIFICIAL <1>: Function Basics. (line 6) 52881* DECL_ARTIFICIAL <2>: Function Properties. 52882 (line 47) 52883* DECL_ASSEMBLER_NAME: Function Basics. (line 6) 52884* DECL_ASSEMBLER_NAME <1>: Function Basics. (line 19) 52885* DECL_ATTRIBUTES: Attributes. (line 21) 52886* DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 52887* DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 52888* DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 52889* DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 52890* DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 52891* DECL_CONTEXT: Namespaces. (line 31) 52892* DECL_CONV_FN_P: Functions for C++. (line 105) 52893* DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 52894* DECL_DESTRUCTOR_P: Functions for C++. (line 95) 52895* DECL_EXTERNAL: Declarations. (line 6) 52896* DECL_EXTERNAL <1>: Function Properties. 52897 (line 25) 52898* DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 52899* DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 52900* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6) 52901* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties. 52902 (line 61) 52903* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6) 52904* DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Properties. 52905 (line 55) 52906* DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 52907* DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 52908* DECL_INITIAL: Declarations. (line 6) 52909* DECL_INITIAL <1>: Function Basics. (line 51) 52910* DECL_LINKONCE_P: Functions for C++. (line 50) 52911* DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 52912* DECL_MAIN_P: Functions for C++. (line 34) 52913* DECL_NAME: Working with declarations. 52914 (line 7) 52915* DECL_NAME <1>: Function Basics. (line 6) 52916* DECL_NAME <2>: Function Basics. (line 9) 52917* DECL_NAME <3>: Namespaces. (line 20) 52918* DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 52919* DECL_NAMESPACE_STD_P: Namespaces. (line 45) 52920* DECL_NONCONVERTING_P: Functions for C++. (line 80) 52921* DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 52922* DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 52923* DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 52924* DECL_PURE_P: Function Properties. 52925 (line 40) 52926* DECL_RESULT: Function Basics. (line 41) 52927* DECL_SAVED_TREE: Function Basics. (line 44) 52928* DECL_SIZE: Declarations. (line 6) 52929* DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 52930* DECL_STMT: Statements for C++. (line 6) 52931* DECL_STMT_DECL: Statements for C++. (line 6) 52932* DECL_THUNK_P: Functions for C++. (line 116) 52933* DECL_VIRTUAL_P: Function Properties. 52934 (line 44) 52935* DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 52936* default: GTY Options. (line 90) 52937* default_file_start: File Framework. (line 8) 52938* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 17) 52939* DEFAULT_INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 199) 52940* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34) 52941* DEFAULT_SIGNED_CHAR: Type Layout. (line 117) 52942* define_address_constraint: Define Constraints. (line 113) 52943* define_asm_attributes: Tagging Insns. (line 73) 52944* define_attr: Defining Attributes. 52945 (line 6) 52946* define_automaton: Processor pipeline description. 52947 (line 53) 52948* define_bypass: Processor pipeline description. 52949 (line 196) 52950* define_code_attr: Code Iterators. (line 6) 52951* define_code_iterator: Code Iterators. (line 6) 52952* define_cond_exec: Conditional Execution. 52953 (line 13) 52954* define_constants: Constant Definitions. 52955 (line 6) 52956* define_constraint: Define Constraints. (line 45) 52957* define_cpu_unit: Processor pipeline description. 52958 (line 68) 52959* define_c_enum: Constant Definitions. 52960 (line 49) 52961* define_delay: Delay Slots. (line 25) 52962* define_enum: Constant Definitions. 52963 (line 118) 52964* define_enum_attr: Defining Attributes. 52965 (line 83) 52966* define_enum_attr <1>: Constant Definitions. 52967 (line 136) 52968* define_expand: Expander Definitions. 52969 (line 11) 52970* define_insn: Patterns. (line 6) 52971* define_insn example: Example. (line 6) 52972* define_insn_and_rewrite: Insn Splitting. (line 236) 52973* define_insn_and_split: Insn Splitting. (line 190) 52974* define_insn_reservation: Processor pipeline description. 52975 (line 105) 52976* define_int_attr: Int Iterators. (line 6) 52977* define_int_iterator: Int Iterators. (line 6) 52978* define_memory_constraint: Define Constraints. (line 80) 52979* define_mode_attr: Substitutions. (line 6) 52980* define_mode_iterator: Defining Mode Iterators. 52981 (line 6) 52982* define_peephole: define_peephole. (line 6) 52983* define_peephole2: define_peephole2. (line 6) 52984* define_predicate: Defining Predicates. 52985 (line 6) 52986* define_query_cpu_unit: Processor pipeline description. 52987 (line 90) 52988* define_register_constraint: Define Constraints. (line 26) 52989* define_reservation: Processor pipeline description. 52990 (line 185) 52991* define_special_memory_constraint: Define Constraints. (line 99) 52992* define_special_predicate: Defining Predicates. 52993 (line 6) 52994* define_split: Insn Splitting. (line 32) 52995* define_subst: Define Subst. (line 6) 52996* define_subst <1>: Define Subst Example. 52997 (line 6) 52998* define_subst <2>: Define Subst Pattern Matching. 52999 (line 6) 53000* define_subst <3>: Define Subst Output Template. 53001 (line 6) 53002* define_subst <4>: Define Subst. (line 14) 53003* define_subst <5>: Subst Iterators. (line 6) 53004* define_subst_attr: Subst Iterators. (line 6) 53005* define_subst_attr <1>: Subst Iterators. (line 26) 53006* defining attributes and their values: Defining Attributes. 53007 (line 6) 53008* defining constraints: Define Constraints. (line 6) 53009* defining jump instruction patterns: Jump Patterns. (line 6) 53010* defining looping instruction patterns: Looping Patterns. (line 6) 53011* defining peephole optimizers: Peephole Definitions. 53012 (line 6) 53013* defining predicates: Defining Predicates. 53014 (line 6) 53015* defining RTL sequences for code generation: Expander Definitions. 53016 (line 6) 53017* delay slots, defining: Delay Slots. (line 6) 53018* deletable: GTY Options. (line 134) 53019* DELETE_IF_ORDINARY: Filesystem. (line 79) 53020* Dependent Patterns: Dependent Patterns. (line 6) 53021* desc: GTY Options. (line 90) 53022* descriptors for nested functions: Trampolines. (line 6) 53023* destructors, output of: Initialization. (line 6) 53024* deterministic finite state automaton: Processor pipeline description. 53025 (line 6) 53026* deterministic finite state automaton <1>: Processor pipeline description. 53027 (line 304) 53028* DFmode: Machine Modes. (line 76) 53029* diagnostics guidelines, fix-it hints: Guidelines for Diagnostics. 53030 (line 320) 53031* diagnostics, actionable: Guidelines for Diagnostics. 53032 (line 15) 53033* diagnostics, false positive: Guidelines for Diagnostics. 53034 (line 39) 53035* diagnostics, guidelines for: Guidelines for Diagnostics. 53036 (line 5) 53037* diagnostics, locations: Guidelines for Diagnostics. 53038 (line 159) 53039* diagnostics, true positive: Guidelines for Diagnostics. 53040 (line 39) 53041* digits in constraint: Simple Constraints. (line 128) 53042* DImode: Machine Modes. (line 45) 53043* directory options .md: Including Patterns. (line 47) 53044* DIR_SEPARATOR: Filesystem. (line 18) 53045* DIR_SEPARATOR_2: Filesystem. (line 19) 53046* disabling certain registers: Register Basics. (line 116) 53047* dispatch table: Dispatch Tables. (line 8) 53048* div: Arithmetic. (line 116) 53049* div and attributes: Expressions. (line 83) 53050* division: Arithmetic. (line 116) 53051* division <1>: Arithmetic. (line 130) 53052* division <2>: Arithmetic. (line 136) 53053* divM3 instruction pattern: Standard Names. (line 442) 53054* divmodM4 instruction pattern: Standard Names. (line 808) 53055* dollar sign: Multi-Alternative. (line 57) 53056* DOLLARS_IN_IDENTIFIERS: Misc. (line 485) 53057* doloop_begin instruction pattern: Standard Names. (line 1879) 53058* doloop_end instruction pattern: Standard Names. (line 1867) 53059* DONE: Expander Definitions. 53060 (line 77) 53061* DONE <1>: Insn Splitting. (line 61) 53062* DONE <2>: define_peephole2. (line 76) 53063* DONT_USE_BUILTIN_SETJMP: Exception Region Output. 53064 (line 78) 53065* DOUBLE_TYPE_SIZE: Type Layout. (line 52) 53066* DO_BODY: Statements for C++. (line 6) 53067* DO_COND: Statements for C++. (line 6) 53068* DO_STMT: Statements for C++. (line 6) 53069* DQmode: Machine Modes. (line 118) 53070* driver: Driver. (line 6) 53071* DRIVER_SELF_SPECS: Driver. (line 8) 53072* dump examples: Dump examples. (line 6) 53073* dump setup: Dump setup. (line 6) 53074* dump types: Dump types. (line 6) 53075* dump verbosity: Dump output verbosity. 53076 (line 6) 53077* DUMPFILE_FORMAT: Filesystem. (line 67) 53078* dump_basic_block: Dump types. (line 29) 53079* dump_generic_expr: Dump types. (line 31) 53080* dump_gimple_stmt: Dump types. (line 33) 53081* dump_printf: Dump types. (line 6) 53082* DWARF2_ASM_LINE_DEBUG_INFO: DWARF. (line 45) 53083* DWARF2_ASM_VIEW_DEBUG_INFO: DWARF. (line 51) 53084* DWARF2_DEBUGGING_INFO: DWARF. (line 8) 53085* DWARF2_FRAME_INFO: DWARF. (line 25) 53086* DWARF2_FRAME_REG_OUT: Frame Registers. (line 149) 53087* DWARF2_UNWIND_INFO: Exception Region Output. 53088 (line 39) 53089* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 146) 53090* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 53091 (line 90) 53092* DWARF_FRAME_REGISTERS: Frame Registers. (line 109) 53093* DWARF_FRAME_REGNUM: Frame Registers. (line 141) 53094* DWARF_LAZY_REGISTER_VALUE: Frame Registers. (line 170) 53095* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134) 53096* DWARF_ZERO_REG: Frame Layout. (line 157) 53097* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 84) 53098* E in constraint: Simple Constraints. (line 87) 53099* earlyclobber operand: Modifiers. (line 25) 53100* edge: Edges. (line 6) 53101* edge in the flow graph: Edges. (line 6) 53102* edge iterators: Edges. (line 15) 53103* edge splitting: Maintaining the CFG. 53104 (line 104) 53105* EDGE_ABNORMAL: Edges. (line 127) 53106* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171) 53107* EDGE_ABNORMAL, EDGE_EH: Edges. (line 95) 53108* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 121) 53109* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 85) 53110* EDOM, implicit usage: Library Calls. (line 59) 53111* EH_FRAME_SECTION_NAME: Exception Region Output. 53112 (line 9) 53113* EH_FRAME_THROUGH_COLLECT2: Exception Region Output. 53114 (line 19) 53115* eh_return instruction pattern: Standard Names. (line 2060) 53116* EH_RETURN_DATA_REGNO: Exception Handling. (line 6) 53117* EH_RETURN_HANDLER_RTX: Exception Handling. (line 38) 53118* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 21) 53119* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 53120 (line 29) 53121* EH_USES: Function Entry. (line 162) 53122* ei_edge: Edges. (line 43) 53123* ei_end_p: Edges. (line 27) 53124* ei_last: Edges. (line 23) 53125* ei_next: Edges. (line 35) 53126* ei_one_before_end_p: Edges. (line 31) 53127* ei_prev: Edges. (line 39) 53128* ei_safe_safe: Edges. (line 47) 53129* ei_start: Edges. (line 19) 53130* ELIMINABLE_REGS: Elimination. (line 34) 53131* ELSE_CLAUSE: Statements for C++. (line 6) 53132* Embedded C: Fixed-point fractional library routines. 53133 (line 6) 53134* Empty Statements: Empty Statements. (line 6) 53135* EMPTY_CLASS_EXPR: Statements for C++. (line 6) 53136* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 341) 53137* Emulated TLS: Emulated TLS. (line 6) 53138* enabled: Disable Insn Alternatives. 53139 (line 6) 53140* ENDFILE_SPEC: Driver. (line 155) 53141* endianness: Portability. (line 20) 53142* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 10) 53143* entry_value: Debug Information. (line 30) 53144* enum reg_class: Register Classes. (line 70) 53145* ENUMERAL_TYPE: Types. (line 6) 53146* enumerations: Constant Definitions. 53147 (line 49) 53148* epilogue: Function Entry. (line 6) 53149* epilogue instruction pattern: Standard Names. (line 2098) 53150* EPILOGUE_USES: Function Entry. (line 156) 53151* eq: Comparisons. (line 52) 53152* eq and attributes: Expressions. (line 83) 53153* equal: Comparisons. (line 52) 53154* eq_attr: Expressions. (line 104) 53155* EQ_EXPR: Unary and Binary Expressions. 53156 (line 6) 53157* errno, implicit usage: Library Calls. (line 71) 53158* EXACT_DIV_EXPR: Unary and Binary Expressions. 53159 (line 6) 53160* examining SSA_NAMEs: SSA. (line 182) 53161* exception handling: Edges. (line 95) 53162* exception handling <1>: Exception Handling. (line 6) 53163* exception_receiver instruction pattern: Standard Names. (line 2025) 53164* exclamation point: Multi-Alternative. (line 48) 53165* exclusion_set: Processor pipeline description. 53166 (line 223) 53167* exclusive-or, bitwise: Arithmetic. (line 168) 53168* EXIT_EXPR: Unary and Binary Expressions. 53169 (line 6) 53170* EXIT_IGNORE_STACK: Function Entry. (line 144) 53171* exp10M2 instruction pattern: Standard Names. (line 995) 53172* exp2M2 instruction pattern: Standard Names. (line 1002) 53173* expander definitions: Expander Definitions. 53174 (line 6) 53175* expm1M2 instruction pattern: Standard Names. (line 985) 53176* expM2 instruction pattern: Standard Names. (line 978) 53177* expression: Expression trees. (line 6) 53178* expression codes: RTL Objects. (line 47) 53179* EXPR_FILENAME: Working with declarations. 53180 (line 14) 53181* EXPR_LINENO: Working with declarations. 53182 (line 20) 53183* expr_list: Insns. (line 568) 53184* EXPR_STMT: Statements for C++. (line 6) 53185* EXPR_STMT_EXPR: Statements for C++. (line 6) 53186* extendMN2 instruction pattern: Standard Names. (line 1447) 53187* extensible constraints: Simple Constraints. (line 171) 53188* extract_last_M instruction pattern: Standard Names. (line 543) 53189* EXTRA_SPECS: Driver. (line 182) 53190* extv instruction pattern: Standard Names. (line 1538) 53191* extvM instruction pattern: Standard Names. (line 1483) 53192* extvmisalignM instruction pattern: Standard Names. (line 1493) 53193* extzv instruction pattern: Standard Names. (line 1556) 53194* extzvM instruction pattern: Standard Names. (line 1507) 53195* extzvmisalignM instruction pattern: Standard Names. (line 1510) 53196* F in constraint: Simple Constraints. (line 92) 53197* FAIL: Expander Definitions. 53198 (line 83) 53199* FAIL <1>: Insn Splitting. (line 68) 53200* FAIL <2>: define_peephole2. (line 83) 53201* fall-thru: Edges. (line 68) 53202* false positive: Guidelines for Diagnostics. 53203 (line 39) 53204* FATAL_EXIT_CODE: Host Misc. (line 6) 53205* FDL, GNU Free Documentation License: GNU Free Documentation License. 53206 (line 6) 53207* features, optional, in system conventions: Run-time Target. 53208 (line 59) 53209* ffs: Arithmetic. (line 210) 53210* ffsM2 instruction pattern: Standard Names. (line 1157) 53211* FIELD_DECL: Declarations. (line 6) 53212* files and passes of the compiler: Passes. (line 6) 53213* files, generated: Files. (line 6) 53214* file_end_indicate_exec_stack: File Framework. (line 39) 53215* final_absence_set: Processor pipeline description. 53216 (line 223) 53217* FINAL_PRESCAN_INSN: Instruction Output. (line 60) 53218* final_presence_set: Processor pipeline description. 53219 (line 223) 53220* final_sequence: Instruction Output. (line 144) 53221* FIND_BASE_TERM: Addressing Modes. (line 117) 53222* finite state automaton minimization: Processor pipeline description. 53223 (line 304) 53224* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 113) 53225* FINI_SECTION_ASM_OP: Sections. (line 98) 53226* FIRST_PARM_OFFSET: Frame Layout. (line 59) 53227* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 53228* FIRST_PSEUDO_REGISTER: Register Basics. (line 8) 53229* FIRST_STACK_REG: Stack Registers. (line 26) 53230* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 53231* fix: Conversions. (line 66) 53232* fix-it hints: Guidelines for Diagnostics. 53233 (line 320) 53234* fixed register: Register Basics. (line 15) 53235* fixed-point fractional library: Fixed-point fractional library routines. 53236 (line 6) 53237* FIXED_CONVERT_EXPR: Unary and Binary Expressions. 53238 (line 6) 53239* FIXED_CST: Constant expressions. 53240 (line 6) 53241* FIXED_POINT_TYPE: Types. (line 6) 53242* FIXED_REGISTERS: Register Basics. (line 14) 53243* fixed_regs: Register Basics. (line 102) 53244* fixed_size_mode: Machine Modes. (line 305) 53245* fixMN2 instruction pattern: Standard Names. (line 1414) 53246* fixunsMN2 instruction pattern: Standard Names. (line 1423) 53247* fixuns_truncMN2 instruction pattern: Standard Names. (line 1438) 53248* fix_truncMN2 instruction pattern: Standard Names. (line 1434) 53249* FIX_TRUNC_EXPR: Unary and Binary Expressions. 53250 (line 6) 53251* flags in RTL expression: Flags. (line 6) 53252* float: Conversions. (line 58) 53253* floating point and cross compilation: Floating Point. (line 6) 53254* floatMN2 instruction pattern: Standard Names. (line 1406) 53255* floatunsMN2 instruction pattern: Standard Names. (line 1410) 53256* FLOAT_EXPR: Unary and Binary Expressions. 53257 (line 6) 53258* float_extend: Conversions. (line 33) 53259* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 32) 53260* FLOAT_STORE_FLAG_VALUE: Misc. (line 320) 53261* float_truncate: Conversions. (line 53) 53262* FLOAT_TYPE_SIZE: Type Layout. (line 48) 53263* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 41) 53264* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 53265 (line 234) 53266* floorM2 instruction pattern: Standard Names. (line 1069) 53267* FLOOR_DIV_EXPR: Unary and Binary Expressions. 53268 (line 6) 53269* FLOOR_MOD_EXPR: Unary and Binary Expressions. 53270 (line 6) 53271* flow-insensitive alias analysis: Alias analysis. (line 6) 53272* flow-sensitive alias analysis: Alias analysis. (line 6) 53273* fma: Arithmetic. (line 112) 53274* fmaM4 instruction pattern: Standard Names. (line 478) 53275* fmaxM3 instruction pattern: Standard Names. (line 509) 53276* fminM3 instruction pattern: Standard Names. (line 509) 53277* fmodM3 instruction pattern: Standard Names. (line 901) 53278* fmsM4 instruction pattern: Standard Names. (line 485) 53279* fnmaM4 instruction pattern: Standard Names. (line 491) 53280* fnmsM4 instruction pattern: Standard Names. (line 497) 53281* fold_extract_last_M instruction pattern: Standard Names. (line 550) 53282* fold_left_plus_M instruction pattern: Standard Names. (line 558) 53283* FORCE_CODE_SECTION_ALIGN: Sections. (line 149) 53284* force_reg: Standard Names. (line 36) 53285* FOR_BODY: Statements for C++. (line 6) 53286* FOR_COND: Statements for C++. (line 6) 53287* FOR_EXPR: Statements for C++. (line 6) 53288* FOR_INIT_STMT: Statements for C++. (line 6) 53289* FOR_STMT: Statements for C++. (line 6) 53290* for_user: GTY Options. (line 82) 53291* fractional types: Fixed-point fractional library routines. 53292 (line 6) 53293* fractMN2 instruction pattern: Standard Names. (line 1456) 53294* fractunsMN2 instruction pattern: Standard Names. (line 1471) 53295* fract_convert: Conversions. (line 82) 53296* FRACT_TYPE_SIZE: Type Layout. (line 67) 53297* frame layout: Frame Layout. (line 6) 53298* FRAME_ADDR_RTX: Frame Layout. (line 108) 53299* FRAME_GROWS_DOWNWARD: Frame Layout. (line 26) 53300* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 53301 (line 69) 53302* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 225) 53303* frame_pointer_needed: Function Entry. (line 42) 53304* FRAME_POINTER_REGNUM: Frame Registers. (line 13) 53305* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 53306 (line 74) 53307* frame_pointer_rtx: Frame Registers. (line 104) 53308* frame_related: Flags. (line 238) 53309* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 53310 (line 135) 53311* frame_related, in mem: Flags. (line 74) 53312* frame_related, in reg: Flags. (line 102) 53313* frame_related, in symbol_ref: Flags. (line 179) 53314* frequency, count, BB_FREQ_BASE: Profile information. 53315 (line 30) 53316* ftruncM2 instruction pattern: Standard Names. (line 1429) 53317* function: Functions. (line 6) 53318* function <1>: Functions for C++. (line 6) 53319* function call conventions: Interface. (line 6) 53320* function entry and exit: Function Entry. (line 6) 53321* function entry point, alternate function entry point: Edges. 53322 (line 180) 53323* function properties: Function Properties. 53324 (line 6) 53325* function-call insns: Calls. (line 6) 53326* functions, leaf: Leaf Functions. (line 6) 53327* FUNCTION_ARG_REGNO_P: Register Arguments. (line 261) 53328* FUNCTION_BOUNDARY: Storage Layout. (line 176) 53329* FUNCTION_DECL: Functions. (line 6) 53330* FUNCTION_DECL <1>: Functions for C++. (line 6) 53331* FUNCTION_MODE: Misc. (line 375) 53332* FUNCTION_PROFILER: Profiling. (line 8) 53333* FUNCTION_TYPE: Types. (line 6) 53334* FUNCTION_VALUE: Scalar Return. (line 52) 53335* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78) 53336* fundamental type: Types. (line 6) 53337* G in constraint: Simple Constraints. (line 96) 53338* g in constraint: Simple Constraints. (line 118) 53339* garbage collector, invocation: Invoking the garbage collector. 53340 (line 6) 53341* garbage collector, troubleshooting: Troubleshooting. (line 6) 53342* gather_loadMN instruction pattern: Standard Names. (line 232) 53343* GCC and portability: Portability. (line 6) 53344* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 53345* gcov_type: Profile information. 53346 (line 41) 53347* ge: Comparisons. (line 72) 53348* ge and attributes: Expressions. (line 83) 53349* gencodes: RTL passes. (line 18) 53350* general_operand: Machine-Independent Predicates. 53351 (line 104) 53352* GENERAL_REGS: Register Classes. (line 22) 53353* generated files: Files. (line 6) 53354* generating assembler output: Output Statement. (line 6) 53355* generating insns: RTL Template. (line 6) 53356* GENERIC: Parsing pass. (line 6) 53357* GENERIC <1>: GENERIC. (line 6) 53358* generic predicates: Machine-Independent Predicates. 53359 (line 6) 53360* genflags: RTL passes. (line 18) 53361* GEN_ERRNO_RTX: Library Calls. (line 71) 53362* get_attr: Expressions. (line 99) 53363* get_attr_length: Insn Lengths. (line 52) 53364* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 430) 53365* GET_CODE: RTL Objects. (line 47) 53366* get_insns: Insns. (line 34) 53367* get_last_insn: Insns. (line 34) 53368* GET_MODE: Machine Modes. (line 377) 53369* GET_MODE_ALIGNMENT: Machine Modes. (line 417) 53370* GET_MODE_BITSIZE: Machine Modes. (line 401) 53371* GET_MODE_CLASS: Machine Modes. (line 391) 53372* GET_MODE_FBIT: Machine Modes. (line 408) 53373* GET_MODE_IBIT: Machine Modes. (line 404) 53374* GET_MODE_MASK: Machine Modes. (line 412) 53375* GET_MODE_NAME: Machine Modes. (line 388) 53376* GET_MODE_NUNITS: Machine Modes. (line 426) 53377* GET_MODE_SIZE: Machine Modes. (line 398) 53378* GET_MODE_UNIT_SIZE: Machine Modes. (line 420) 53379* GET_MODE_WIDER_MODE: Machine Modes. (line 394) 53380* GET_RTX_CLASS: RTL Classes. (line 6) 53381* GET_RTX_FORMAT: RTL Classes. (line 136) 53382* GET_RTX_LENGTH: RTL Classes. (line 133) 53383* get_thread_pointerMODE instruction pattern: Standard Names. 53384 (line 2477) 53385* geu: Comparisons. (line 72) 53386* geu and attributes: Expressions. (line 83) 53387* GE_EXPR: Unary and Binary Expressions. 53388 (line 6) 53389* GGC: Type Information. (line 6) 53390* ggc_collect: Invoking the garbage collector. 53391 (line 6) 53392* GIMPLE: Parsing pass. (line 13) 53393* GIMPLE <1>: Gimplification pass. 53394 (line 6) 53395* GIMPLE <2>: GIMPLE. (line 6) 53396* gimple: Tuple representation. 53397 (line 14) 53398* GIMPLE API: GIMPLE API. (line 6) 53399* GIMPLE class hierarchy: Class hierarchy of GIMPLE statements. 53400 (line 6) 53401* GIMPLE Exception Handling: GIMPLE Exception Handling. 53402 (line 6) 53403* GIMPLE instruction set: GIMPLE instruction set. 53404 (line 6) 53405* GIMPLE sequences: GIMPLE sequences. (line 6) 53406* GIMPLE statement iterators: Basic Blocks. (line 78) 53407* GIMPLE statement iterators <1>: Maintaining the CFG. 53408 (line 33) 53409* gimple_addresses_taken: Manipulating GIMPLE statements. 53410 (line 89) 53411* GIMPLE_ASM: GIMPLE_ASM. (line 6) 53412* gimple_asm_clobber_op: GIMPLE_ASM. (line 39) 53413* gimple_asm_input_op: GIMPLE_ASM. (line 23) 53414* gimple_asm_nclobbers: GIMPLE_ASM. (line 20) 53415* gimple_asm_ninputs: GIMPLE_ASM. (line 14) 53416* gimple_asm_noutputs: GIMPLE_ASM. (line 17) 53417* gimple_asm_output_op: GIMPLE_ASM. (line 31) 53418* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 43) 53419* gimple_asm_set_input_op: GIMPLE_ASM. (line 27) 53420* gimple_asm_set_output_op: GIMPLE_ASM. (line 35) 53421* gimple_asm_set_volatile: GIMPLE_ASM. (line 54) 53422* gimple_asm_string: GIMPLE_ASM. (line 47) 53423* gimple_asm_volatile_p: GIMPLE_ASM. (line 51) 53424* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 53425* gimple_assign_cast_p: Logical Operators. (line 158) 53426* gimple_assign_cast_p <1>: GIMPLE_ASSIGN. (line 104) 53427* gimple_assign_lhs: GIMPLE_ASSIGN. (line 62) 53428* gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 65) 53429* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 68) 53430* gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 71) 53431* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 75) 53432* gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 78) 53433* gimple_assign_rhs3: GIMPLE_ASSIGN. (line 82) 53434* gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 85) 53435* gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 56) 53436* gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 52) 53437* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 89) 53438* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 92) 53439* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 96) 53440* gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 100) 53441* gimple_bb: Manipulating GIMPLE statements. 53442 (line 17) 53443* GIMPLE_BIND: GIMPLE_BIND. (line 6) 53444* gimple_bind_add_seq: GIMPLE_BIND. (line 34) 53445* gimple_bind_add_stmt: GIMPLE_BIND. (line 31) 53446* gimple_bind_append_vars: GIMPLE_BIND. (line 18) 53447* gimple_bind_block: GIMPLE_BIND. (line 39) 53448* gimple_bind_body: GIMPLE_BIND. (line 22) 53449* gimple_bind_set_block: GIMPLE_BIND. (line 44) 53450* gimple_bind_set_body: GIMPLE_BIND. (line 26) 53451* gimple_bind_set_vars: GIMPLE_BIND. (line 14) 53452* gimple_bind_vars: GIMPLE_BIND. (line 11) 53453* gimple_block: Manipulating GIMPLE statements. 53454 (line 20) 53455* gimple_build: GIMPLE API. (line 34) 53456* gimple_build <1>: GIMPLE API. (line 36) 53457* gimple_build <2>: GIMPLE API. (line 38) 53458* gimple_build <3>: GIMPLE API. (line 41) 53459* gimple_build <4>: GIMPLE API. (line 44) 53460* gimple_build <5>: GIMPLE API. (line 47) 53461* gimple_build_debug_begin_stmt: GIMPLE_DEBUG. (line 72) 53462* gimple_build_debug_inline_entry: GIMPLE_DEBUG. (line 82) 53463* gimple_build_nop: GIMPLE_NOP. (line 6) 53464* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 6) 53465* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 6) 53466* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 6) 53467* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 6) 53468* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 53469 (line 13) 53470* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 53471 (line 6) 53472* GIMPLE_CALL: GIMPLE_CALL. (line 6) 53473* gimple_call_arg: GIMPLE_CALL. (line 67) 53474* gimple_call_arg_ptr: GIMPLE_CALL. (line 71) 53475* gimple_call_chain: GIMPLE_CALL. (line 58) 53476* gimple_call_copy_skip_args: GIMPLE_CALL. (line 92) 53477* gimple_call_fn: GIMPLE_CALL. (line 39) 53478* gimple_call_fndecl: GIMPLE_CALL. (line 47) 53479* gimple_call_lhs: GIMPLE_CALL. (line 30) 53480* gimple_call_lhs_ptr: GIMPLE_CALL. (line 33) 53481* gimple_call_noreturn_p: GIMPLE_CALL. (line 89) 53482* gimple_call_num_args: GIMPLE_CALL. (line 64) 53483* gimple_call_return_type: GIMPLE_CALL. (line 55) 53484* gimple_call_set_arg: GIMPLE_CALL. (line 76) 53485* gimple_call_set_chain: GIMPLE_CALL. (line 61) 53486* gimple_call_set_fn: GIMPLE_CALL. (line 43) 53487* gimple_call_set_fndecl: GIMPLE_CALL. (line 52) 53488* gimple_call_set_lhs: GIMPLE_CALL. (line 36) 53489* gimple_call_set_tail: GIMPLE_CALL. (line 81) 53490* gimple_call_tail_p: GIMPLE_CALL. (line 86) 53491* GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 53492* gimple_catch_handler: GIMPLE_CATCH. (line 19) 53493* gimple_catch_set_handler: GIMPLE_CATCH. (line 26) 53494* gimple_catch_set_types: GIMPLE_CATCH. (line 23) 53495* gimple_catch_types: GIMPLE_CATCH. (line 12) 53496* gimple_catch_types_ptr: GIMPLE_CATCH. (line 15) 53497* gimple_code: Manipulating GIMPLE statements. 53498 (line 14) 53499* GIMPLE_COND: GIMPLE_COND. (line 6) 53500* gimple_cond_code: GIMPLE_COND. (line 20) 53501* gimple_cond_false_label: GIMPLE_COND. (line 59) 53502* gimple_cond_lhs: GIMPLE_COND. (line 29) 53503* gimple_cond_make_false: GIMPLE_COND. (line 63) 53504* gimple_cond_make_true: GIMPLE_COND. (line 66) 53505* gimple_cond_rhs: GIMPLE_COND. (line 37) 53506* gimple_cond_set_code: GIMPLE_COND. (line 24) 53507* gimple_cond_set_false_label: GIMPLE_COND. (line 54) 53508* gimple_cond_set_lhs: GIMPLE_COND. (line 33) 53509* gimple_cond_set_rhs: GIMPLE_COND. (line 41) 53510* gimple_cond_set_true_label: GIMPLE_COND. (line 49) 53511* gimple_cond_true_label: GIMPLE_COND. (line 45) 53512* gimple_convert: GIMPLE API. (line 50) 53513* gimple_copy: Manipulating GIMPLE statements. 53514 (line 146) 53515* GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 53516* GIMPLE_DEBUG_BEGIN_STMT: GIMPLE_DEBUG. (line 6) 53517* GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 53518* gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 46) 53519* gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 50) 53520* gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 43) 53521* gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 68) 53522* gimple_debug_bind_p: Logical Operators. (line 162) 53523* gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 64) 53524* gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 59) 53525* gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 55) 53526* GIMPLE_DEBUG_INLINE_ENTRY: GIMPLE_DEBUG. (line 6) 53527* gimple_def_ops: Manipulating GIMPLE statements. 53528 (line 93) 53529* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 53530* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 18) 53531* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 27) 53532* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 22) 53533* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 11) 53534* gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 14) 53535* gimple_eh_must_not_throw_fndecl: GIMPLE_EH_FILTER. (line 32) 53536* gimple_eh_must_not_throw_set_fndecl: GIMPLE_EH_FILTER. (line 36) 53537* gimple_expr_code: Manipulating GIMPLE statements. 53538 (line 30) 53539* gimple_expr_type: Manipulating GIMPLE statements. 53540 (line 23) 53541* GIMPLE_GOTO: GIMPLE_GOTO. (line 6) 53542* gimple_goto_dest: GIMPLE_GOTO. (line 9) 53543* gimple_goto_set_dest: GIMPLE_GOTO. (line 12) 53544* gimple_has_mem_ops: Manipulating GIMPLE statements. 53545 (line 71) 53546* gimple_has_ops: Manipulating GIMPLE statements. 53547 (line 68) 53548* gimple_has_volatile_ops: Manipulating GIMPLE statements. 53549 (line 133) 53550* GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 53551* gimple_label_label: GIMPLE_LABEL. (line 10) 53552* gimple_label_set_label: GIMPLE_LABEL. (line 13) 53553* gimple_loaded_syms: Manipulating GIMPLE statements. 53554 (line 121) 53555* gimple_locus: Manipulating GIMPLE statements. 53556 (line 41) 53557* gimple_locus_empty_p: Manipulating GIMPLE statements. 53558 (line 47) 53559* gimple_modified_p: Manipulating GIMPLE statements. 53560 (line 129) 53561* GIMPLE_NOP: GIMPLE_NOP. (line 6) 53562* gimple_nop_p: GIMPLE_NOP. (line 9) 53563* gimple_no_warning_p: Manipulating GIMPLE statements. 53564 (line 50) 53565* gimple_num_ops: Logical Operators. (line 76) 53566* gimple_num_ops <1>: Manipulating GIMPLE statements. 53567 (line 74) 53568* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 53569 (line 6) 53570* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 53571 (line 16) 53572* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 53573 (line 24) 53574* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 53575 (line 12) 53576* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 53577 (line 20) 53578* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 53579 (line 6) 53580* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 53581 (line 11) 53582* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 53583 (line 15) 53584* gimple_omp_body: GIMPLE_OMP_PARALLEL. 53585 (line 23) 53586* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 53587 (line 6) 53588* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 53589 (line 12) 53590* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 53591 (line 17) 53592* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 53593 (line 26) 53594* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 53595 (line 31) 53596* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 53597 (line 21) 53598* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 53599 (line 35) 53600* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 53601 (line 6) 53602* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 53603 (line 12) 53604* gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 53605 (line 16) 53606* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 53607 (line 21) 53608* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 53609* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 17) 53610* gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 20) 53611* gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 80) 53612* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 48) 53613* gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 51) 53614* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 58) 53615* gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 61) 53616* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 28) 53617* gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 31) 53618* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 38) 53619* gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 41) 53620* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 67) 53621* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 23) 53622* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 76) 53623* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 54) 53624* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 64) 53625* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 34) 53626* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 44) 53627* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 71) 53628* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 53629* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 53630* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 53631 (line 6) 53632* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 53633 (line 42) 53634* gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 53635 (line 47) 53636* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 53637 (line 30) 53638* gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 53639 (line 33) 53640* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 53641 (line 15) 53642* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 53643 (line 56) 53644* gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 53645 (line 61) 53646* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 53647 (line 52) 53648* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 53649 (line 37) 53650* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 53651 (line 19) 53652* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 53653 (line 65) 53654* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 53655* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 13) 53656* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 10) 53657* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 53658* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 53659 (line 6) 53660* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 53661 (line 29) 53662* gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 53663 (line 32) 53664* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 53665 (line 16) 53666* gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 53667 (line 20) 53668* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 53669 (line 35) 53670* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 53671 (line 24) 53672* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 11) 53673* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 15) 53674* gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 53675 (line 26) 53676* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 53677* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 13) 53678* gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 16) 53679* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 19) 53680* gimple_op: Logical Operators. (line 79) 53681* gimple_op <1>: Manipulating GIMPLE statements. 53682 (line 80) 53683* gimple_ops: Logical Operators. (line 82) 53684* gimple_ops <1>: Manipulating GIMPLE statements. 53685 (line 77) 53686* gimple_op_ptr: Manipulating GIMPLE statements. 53687 (line 83) 53688* GIMPLE_PHI: GIMPLE_PHI. (line 6) 53689* gimple_phi_arg: GIMPLE_PHI. (line 24) 53690* gimple_phi_arg <1>: SSA. (line 62) 53691* gimple_phi_arg_def: SSA. (line 68) 53692* gimple_phi_arg_edge: SSA. (line 65) 53693* gimple_phi_capacity: GIMPLE_PHI. (line 6) 53694* gimple_phi_num_args: GIMPLE_PHI. (line 10) 53695* gimple_phi_num_args <1>: SSA. (line 58) 53696* gimple_phi_result: GIMPLE_PHI. (line 15) 53697* gimple_phi_result <1>: SSA. (line 55) 53698* gimple_phi_result_ptr: GIMPLE_PHI. (line 18) 53699* gimple_phi_set_arg: GIMPLE_PHI. (line 28) 53700* gimple_phi_set_result: GIMPLE_PHI. (line 21) 53701* gimple_plf: Manipulating GIMPLE statements. 53702 (line 64) 53703* GIMPLE_RESX: GIMPLE_RESX. (line 6) 53704* gimple_resx_region: GIMPLE_RESX. (line 12) 53705* gimple_resx_set_region: GIMPLE_RESX. (line 15) 53706* GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 53707* gimple_return_retval: GIMPLE_RETURN. (line 9) 53708* gimple_return_set_retval: GIMPLE_RETURN. (line 12) 53709* gimple_seq_add_seq: GIMPLE sequences. (line 30) 53710* gimple_seq_add_stmt: GIMPLE sequences. (line 24) 53711* gimple_seq_alloc: GIMPLE sequences. (line 61) 53712* gimple_seq_copy: GIMPLE sequences. (line 65) 53713* gimple_seq_deep_copy: GIMPLE sequences. (line 36) 53714* gimple_seq_empty_p: GIMPLE sequences. (line 69) 53715* gimple_seq_first: GIMPLE sequences. (line 43) 53716* gimple_seq_init: GIMPLE sequences. (line 58) 53717* gimple_seq_last: GIMPLE sequences. (line 46) 53718* gimple_seq_reverse: GIMPLE sequences. (line 39) 53719* gimple_seq_set_first: GIMPLE sequences. (line 53) 53720* gimple_seq_set_last: GIMPLE sequences. (line 49) 53721* gimple_seq_singleton_p: GIMPLE sequences. (line 78) 53722* gimple_set_block: Manipulating GIMPLE statements. 53723 (line 38) 53724* gimple_set_def_ops: Manipulating GIMPLE statements. 53725 (line 96) 53726* gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 53727 (line 136) 53728* gimple_set_locus: Manipulating GIMPLE statements. 53729 (line 44) 53730* gimple_set_op: Manipulating GIMPLE statements. 53731 (line 86) 53732* gimple_set_plf: Manipulating GIMPLE statements. 53733 (line 60) 53734* gimple_set_use_ops: Manipulating GIMPLE statements. 53735 (line 103) 53736* gimple_set_vdef_ops: Manipulating GIMPLE statements. 53737 (line 117) 53738* gimple_set_visited: Manipulating GIMPLE statements. 53739 (line 53) 53740* gimple_set_vuse_ops: Manipulating GIMPLE statements. 53741 (line 110) 53742* gimple_simplify: GIMPLE API. (line 6) 53743* gimple_simplify <1>: GIMPLE API. (line 8) 53744* gimple_simplify <2>: GIMPLE API. (line 10) 53745* gimple_simplify <3>: GIMPLE API. (line 12) 53746* gimple_simplify <4>: GIMPLE API. (line 14) 53747* gimple_simplify <5>: GIMPLE API. (line 16) 53748* gimple_statement_with_ops: Tuple representation. 53749 (line 96) 53750* gimple_stored_syms: Manipulating GIMPLE statements. 53751 (line 125) 53752* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 53753* gimple_switch_default_label: GIMPLE_SWITCH. (line 41) 53754* gimple_switch_index: GIMPLE_SWITCH. (line 24) 53755* gimple_switch_label: GIMPLE_SWITCH. (line 31) 53756* gimple_switch_num_labels: GIMPLE_SWITCH. (line 14) 53757* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 45) 53758* gimple_switch_set_index: GIMPLE_SWITCH. (line 27) 53759* gimple_switch_set_label: GIMPLE_SWITCH. (line 36) 53760* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 19) 53761* GIMPLE_TRY: GIMPLE_TRY. (line 6) 53762* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 19) 53763* gimple_try_cleanup: GIMPLE_TRY. (line 26) 53764* gimple_try_eval: GIMPLE_TRY. (line 22) 53765* gimple_try_kind: GIMPLE_TRY. (line 15) 53766* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 30) 53767* gimple_try_set_cleanup: GIMPLE_TRY. (line 38) 53768* gimple_try_set_eval: GIMPLE_TRY. (line 34) 53769* gimple_use_ops: Manipulating GIMPLE statements. 53770 (line 100) 53771* gimple_vdef_ops: Manipulating GIMPLE statements. 53772 (line 114) 53773* gimple_visited_p: Manipulating GIMPLE statements. 53774 (line 57) 53775* gimple_vuse_ops: Manipulating GIMPLE statements. 53776 (line 107) 53777* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 53778 (line 10) 53779* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 53780 (line 17) 53781* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 53782 (line 13) 53783* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 53784 (line 20) 53785* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 53786 (line 6) 53787* gimplification: Parsing pass. (line 13) 53788* gimplification <1>: Gimplification pass. 53789 (line 6) 53790* gimplifier: Parsing pass. (line 13) 53791* gimplify_assign: GIMPLE_ASSIGN. (line 41) 53792* gimplify_expr: Gimplification pass. 53793 (line 18) 53794* gimplify_function_tree: Gimplification pass. 53795 (line 18) 53796* GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 53797* global_regs: Register Basics. (line 102) 53798* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 90) 53799* greater than: Comparisons. (line 60) 53800* greater than <1>: Comparisons. (line 64) 53801* greater than <2>: Comparisons. (line 72) 53802* gsi_after_labels: Sequence iterators. (line 74) 53803* gsi_bb: Sequence iterators. (line 82) 53804* gsi_commit_edge_inserts: Sequence iterators. (line 193) 53805* gsi_commit_edge_inserts <1>: Maintaining the CFG. 53806 (line 104) 53807* gsi_commit_one_edge_insert: Sequence iterators. (line 188) 53808* gsi_end_p: Sequence iterators. (line 59) 53809* gsi_end_p <1>: Maintaining the CFG. 53810 (line 48) 53811* gsi_for_stmt: Sequence iterators. (line 156) 53812* gsi_insert_after: Sequence iterators. (line 145) 53813* gsi_insert_after <1>: Maintaining the CFG. 53814 (line 60) 53815* gsi_insert_before: Sequence iterators. (line 134) 53816* gsi_insert_before <1>: Maintaining the CFG. 53817 (line 66) 53818* gsi_insert_on_edge: Sequence iterators. (line 173) 53819* gsi_insert_on_edge <1>: Maintaining the CFG. 53820 (line 104) 53821* gsi_insert_on_edge_immediate: Sequence iterators. (line 183) 53822* gsi_insert_seq_after: Sequence iterators. (line 152) 53823* gsi_insert_seq_before: Sequence iterators. (line 141) 53824* gsi_insert_seq_on_edge: Sequence iterators. (line 177) 53825* gsi_last: Sequence iterators. (line 49) 53826* gsi_last <1>: Maintaining the CFG. 53827 (line 44) 53828* gsi_last_bb: Sequence iterators. (line 55) 53829* gsi_link_after: Sequence iterators. (line 113) 53830* gsi_link_before: Sequence iterators. (line 103) 53831* gsi_link_seq_after: Sequence iterators. (line 108) 53832* gsi_link_seq_before: Sequence iterators. (line 97) 53833* gsi_move_after: Sequence iterators. (line 159) 53834* gsi_move_before: Sequence iterators. (line 164) 53835* gsi_move_to_bb_end: Sequence iterators. (line 169) 53836* gsi_next: Sequence iterators. (line 65) 53837* gsi_next <1>: Maintaining the CFG. 53838 (line 52) 53839* gsi_one_before_end_p: Sequence iterators. (line 62) 53840* gsi_prev: Sequence iterators. (line 68) 53841* gsi_prev <1>: Maintaining the CFG. 53842 (line 56) 53843* gsi_remove: Sequence iterators. (line 88) 53844* gsi_remove <1>: Maintaining the CFG. 53845 (line 72) 53846* gsi_replace: Sequence iterators. (line 128) 53847* gsi_seq: Sequence iterators. (line 85) 53848* gsi_split_seq_after: Sequence iterators. (line 118) 53849* gsi_split_seq_before: Sequence iterators. (line 123) 53850* gsi_start: Sequence iterators. (line 39) 53851* gsi_start <1>: Maintaining the CFG. 53852 (line 40) 53853* gsi_start_bb: Sequence iterators. (line 45) 53854* gsi_stmt: Sequence iterators. (line 71) 53855* gsi_stmt_ptr: Sequence iterators. (line 79) 53856* gt: Comparisons. (line 60) 53857* gt and attributes: Expressions. (line 83) 53858* gtu: Comparisons. (line 64) 53859* gtu and attributes: Expressions. (line 83) 53860* GTY: Type Information. (line 6) 53861* GT_EXPR: Unary and Binary Expressions. 53862 (line 6) 53863* guidelines for diagnostics: Guidelines for Diagnostics. 53864 (line 6) 53865* guidelines for options: Guidelines for Options. 53866 (line 6) 53867* guidelines, user experience: User Experience Guidelines. 53868 (line 6) 53869* H in constraint: Simple Constraints. (line 96) 53870* HAmode: Machine Modes. (line 146) 53871* HANDLER: Statements for C++. (line 6) 53872* HANDLER_BODY: Statements for C++. (line 6) 53873* HANDLER_PARMS: Statements for C++. (line 6) 53874* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 475) 53875* hard registers: Regs and Memory. (line 9) 53876* HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 57) 53877* HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 50) 53878* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 19) 53879* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 10) 53880* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 53881 (line 21) 53882* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 53883 (line 39) 53884* HARD_REGNO_RENAME_OK: Values in Registers. 53885 (line 113) 53886* HAS_INIT_SECTION: Macros for Initialization. 53887 (line 18) 53888* HAS_LONG_COND_BRANCH: Misc. (line 8) 53889* HAS_LONG_UNCOND_BRANCH: Misc. (line 17) 53890* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 53891* HAVE_POST_DECREMENT: Addressing Modes. (line 11) 53892* HAVE_POST_INCREMENT: Addressing Modes. (line 10) 53893* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 17) 53894* HAVE_POST_MODIFY_REG: Addressing Modes. (line 23) 53895* HAVE_PRE_DECREMENT: Addressing Modes. (line 9) 53896* HAVE_PRE_INCREMENT: Addressing Modes. (line 8) 53897* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 16) 53898* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 22) 53899* HCmode: Machine Modes. (line 199) 53900* HFmode: Machine Modes. (line 61) 53901* high: Constants. (line 220) 53902* HImode: Machine Modes. (line 29) 53903* HImode, in insn: Insns. (line 291) 53904* HONOR_REG_ALLOC_ORDER: Allocation Order. (line 36) 53905* host configuration: Host Config. (line 6) 53906* host functions: Host Common. (line 6) 53907* host hooks: Host Common. (line 6) 53908* host makefile fragment: Host Fragment. (line 6) 53909* HOST_BIT_BUCKET: Filesystem. (line 51) 53910* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 53911* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 11) 53912* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 43) 53913* HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 15) 53914* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 24) 53915* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 53916* HOST_LONG_FORMAT: Host Misc. (line 45) 53917* HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 53918* HOST_OBJECT_SUFFIX: Filesystem. (line 40) 53919* HOST_PTR_PRINTF: Host Misc. (line 49) 53920* HOT_TEXT_SECTION_NAME: Sections. (line 42) 53921* HQmode: Machine Modes. (line 110) 53922* i in constraint: Simple Constraints. (line 68) 53923* I in constraint: Simple Constraints. (line 79) 53924* identifier: Identifiers. (line 6) 53925* IDENTIFIER_LENGTH: Identifiers. (line 22) 53926* IDENTIFIER_NODE: Identifiers. (line 6) 53927* IDENTIFIER_OPNAME_P: Identifiers. (line 27) 53928* IDENTIFIER_POINTER: Identifiers. (line 17) 53929* IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 53930* IEEE 754-2008: Decimal float library routines. 53931 (line 6) 53932* IFCVT_MACHDEP_INIT: Misc. (line 601) 53933* IFCVT_MODIFY_CANCEL: Misc. (line 595) 53934* IFCVT_MODIFY_FINAL: Misc. (line 589) 53935* IFCVT_MODIFY_INSN: Misc. (line 583) 53936* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 575) 53937* IFCVT_MODIFY_TESTS: Misc. (line 565) 53938* IF_COND: Statements for C++. (line 6) 53939* IF_STMT: Statements for C++. (line 6) 53940* if_then_else: Comparisons. (line 80) 53941* if_then_else and attributes: Expressions. (line 32) 53942* if_then_else usage: Side Effects. (line 56) 53943* IMAGPART_EXPR: Unary and Binary Expressions. 53944 (line 6) 53945* Immediate Uses: SSA Operands. (line 258) 53946* immediate_operand: Machine-Independent Predicates. 53947 (line 10) 53948* IMMEDIATE_PREFIX: Instruction Output. (line 153) 53949* include: Including Patterns. (line 6) 53950* INCLUDE_DEFAULTS: Driver. (line 331) 53951* inclusive-or, bitwise: Arithmetic. (line 163) 53952* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 188) 53953* INCOMING_REGNO: Register Basics. (line 129) 53954* INCOMING_REG_PARM_STACK_SPACE: Stack Arguments. (line 73) 53955* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 133) 53956* INCOMING_STACK_BOUNDARY: Storage Layout. (line 171) 53957* INDEX_REG_CLASS: Register Classes. (line 140) 53958* indirect_jump instruction pattern: Standard Names. (line 1826) 53959* indirect_operand: Machine-Independent Predicates. 53960 (line 70) 53961* INDIRECT_REF: Storage References. (line 6) 53962* initialization routines: Initialization. (line 6) 53963* INITIAL_ELIMINATION_OFFSET: Elimination. (line 68) 53964* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 75) 53965* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 106) 53966* INIT_CUMULATIVE_ARGS: Register Arguments. (line 158) 53967* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 186) 53968* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 180) 53969* INIT_ENVIRONMENT: Driver. (line 309) 53970* INIT_EXPANDERS: Per-Function Data. (line 36) 53971* INIT_EXPR: Unary and Binary Expressions. 53972 (line 6) 53973* init_machine_status: Per-Function Data. (line 42) 53974* init_one_libfunc: Library Calls. (line 15) 53975* INIT_SECTION_ASM_OP: Sections. (line 90) 53976* INIT_SECTION_ASM_OP <1>: Macros for Initialization. 53977 (line 9) 53978* inlining: Target Attributes. (line 103) 53979* insert_insn_on_edge: Maintaining the CFG. 53980 (line 104) 53981* insn: Insns. (line 63) 53982* insn and /f: Flags. (line 135) 53983* insn and /j: Flags. (line 171) 53984* insn and /s: Flags. (line 38) 53985* insn and /s <1>: Flags. (line 162) 53986* insn and /u: Flags. (line 28) 53987* insn and /v: Flags. (line 33) 53988* insn attributes: Insn Attributes. (line 6) 53989* insn canonicalization: Insn Canonicalizations. 53990 (line 6) 53991* insn includes: Including Patterns. (line 6) 53992* insn lengths, computing: Insn Lengths. (line 6) 53993* insn notes, notes: Basic Blocks. (line 52) 53994* insn splitting: Insn Splitting. (line 6) 53995* insn-attr.h: Defining Attributes. 53996 (line 34) 53997* insns: Insns. (line 6) 53998* insns, generating: RTL Template. (line 6) 53999* insns, recognizing: RTL Template. (line 6) 54000* INSN_ANNULLED_BRANCH_P: Flags. (line 28) 54001* INSN_CODE: Insns. (line 318) 54002* INSN_DELETED_P: Flags. (line 33) 54003* INSN_FROM_TARGET_P: Flags. (line 38) 54004* insn_list: Insns. (line 568) 54005* INSN_REFERENCES_ARE_DELAYED: Misc. (line 502) 54006* INSN_SETS_ARE_DELAYED: Misc. (line 491) 54007* INSN_UID: Insns. (line 23) 54008* INSN_VAR_LOCATION: Insns. (line 247) 54009* instruction attributes: Insn Attributes. (line 6) 54010* instruction latency time: Processor pipeline description. 54011 (line 6) 54012* instruction latency time <1>: Processor pipeline description. 54013 (line 105) 54014* instruction latency time <2>: Processor pipeline description. 54015 (line 196) 54016* instruction patterns: Patterns. (line 6) 54017* instruction splitting: Insn Splitting. (line 6) 54018* insv instruction pattern: Standard Names. (line 1562) 54019* insvM instruction pattern: Standard Names. (line 1514) 54020* insvmisalignM instruction pattern: Standard Names. (line 1524) 54021* int iterators in .md files: Int Iterators. (line 6) 54022* INT16_TYPE: Type Layout. (line 210) 54023* INT32_TYPE: Type Layout. (line 211) 54024* INT64_TYPE: Type Layout. (line 212) 54025* INT8_TYPE: Type Layout. (line 209) 54026* INTEGER_CST: Constant expressions. 54027 (line 6) 54028* INTEGER_TYPE: Types. (line 6) 54029* inter-procedural optimization passes: IPA passes. (line 6) 54030* Interdependence of Patterns: Dependent Patterns. (line 6) 54031* interfacing to GCC output: Interface. (line 6) 54032* interlock delays: Processor pipeline description. 54033 (line 6) 54034* intermediate representation lowering: Parsing pass. (line 13) 54035* INTMAX_TYPE: Type Layout. (line 186) 54036* INTPTR_TYPE: Type Layout. (line 233) 54037* introduction: Top. (line 6) 54038* INT_FAST16_TYPE: Type Layout. (line 226) 54039* INT_FAST32_TYPE: Type Layout. (line 227) 54040* INT_FAST64_TYPE: Type Layout. (line 228) 54041* INT_FAST8_TYPE: Type Layout. (line 225) 54042* INT_LEAST16_TYPE: Type Layout. (line 218) 54043* INT_LEAST32_TYPE: Type Layout. (line 219) 54044* INT_LEAST64_TYPE: Type Layout. (line 220) 54045* INT_LEAST8_TYPE: Type Layout. (line 217) 54046* INT_TYPE_SIZE: Type Layout. (line 11) 54047* INVOKE__main: Macros for Initialization. 54048 (line 50) 54049* in_struct: Flags. (line 254) 54050* in_struct, in code_label and note: Flags. (line 48) 54051* in_struct, in insn and jump_insn and call_insn: Flags. (line 38) 54052* in_struct, in insn, call_insn, jump_insn and jump_table_data: Flags. 54053 (line 162) 54054* in_struct, in subreg: Flags. (line 201) 54055* ior: Arithmetic. (line 163) 54056* ior and attributes: Expressions. (line 50) 54057* ior, canonicalization of: Insn Canonicalizations. 54058 (line 67) 54059* iorM3 instruction pattern: Standard Names. (line 442) 54060* IPA passes: IPA passes. (line 6) 54061* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 44) 54062* is_a: Machine Modes. (line 347) 54063* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 129) 54064* is_gimple_addressable: Logical Operators. (line 113) 54065* is_gimple_asm_val: Logical Operators. (line 117) 54066* is_gimple_assign: Logical Operators. (line 149) 54067* is_gimple_call: Logical Operators. (line 152) 54068* is_gimple_call_addr: Logical Operators. (line 120) 54069* is_gimple_constant: Logical Operators. (line 128) 54070* is_gimple_debug: Logical Operators. (line 155) 54071* is_gimple_ip_invariant: Logical Operators. (line 137) 54072* is_gimple_ip_invariant_address: Logical Operators. (line 142) 54073* is_gimple_mem_ref_addr: Logical Operators. (line 124) 54074* is_gimple_min_invariant: Logical Operators. (line 131) 54075* is_gimple_omp: Logical Operators. (line 166) 54076* is_gimple_val: Logical Operators. (line 107) 54077* iterators in .md files: Iterators. (line 6) 54078* IV analysis on GIMPLE: Scalar evolutions. (line 6) 54079* IV analysis on RTL: loop-iv. (line 6) 54080* JMP_BUF_SIZE: Exception Region Output. 54081 (line 83) 54082* jump: Flags. (line 295) 54083* jump instruction pattern: Standard Names. (line 1704) 54084* jump instruction patterns: Jump Patterns. (line 6) 54085* jump instructions and set: Side Effects. (line 56) 54086* jump, in call_insn: Flags. (line 175) 54087* jump, in insn: Flags. (line 171) 54088* jump, in mem: Flags. (line 59) 54089* Jumps: Jumps. (line 6) 54090* JUMP_ALIGN: Alignment Output. (line 8) 54091* jump_insn: Insns. (line 73) 54092* jump_insn and /f: Flags. (line 135) 54093* jump_insn and /j: Flags. (line 10) 54094* jump_insn and /s: Flags. (line 38) 54095* jump_insn and /s <1>: Flags. (line 162) 54096* jump_insn and /u: Flags. (line 28) 54097* jump_insn and /v: Flags. (line 33) 54098* JUMP_LABEL: Insns. (line 80) 54099* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 155) 54100* jump_table_data: Insns. (line 166) 54101* jump_table_data and /s: Flags. (line 162) 54102* jump_table_data and /v: Flags. (line 33) 54103* LABEL_ALIGN: Alignment Output. (line 42) 54104* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 21) 54105* LABEL_ALTERNATE_NAME: Edges. (line 180) 54106* LABEL_ALT_ENTRY_P: Insns. (line 146) 54107* LABEL_DECL: Declarations. (line 6) 54108* LABEL_KIND: Insns. (line 146) 54109* LABEL_NUSES: Insns. (line 142) 54110* LABEL_PRESERVE_P: Flags. (line 48) 54111* label_ref: Constants. (line 199) 54112* label_ref and /v: Flags. (line 54) 54113* label_ref, RTL sharing: Sharing. (line 38) 54114* LABEL_REF_NONLOCAL_P: Flags. (line 54) 54115* language-dependent trees: Language-dependent trees. 54116 (line 6) 54117* language-independent intermediate representation: Parsing pass. 54118 (line 13) 54119* lang_hooks.gimplify_expr: Gimplification pass. 54120 (line 18) 54121* lang_hooks.parse_file: Parsing pass. (line 6) 54122* large return values: Aggregate Return. (line 6) 54123* LAST_STACK_REG: Stack Registers. (line 30) 54124* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 54125* late IPA passes: Late IPA passes. (line 6) 54126* lceilMN2: Standard Names. (line 1137) 54127* LCSSA: LCSSA. (line 6) 54128* LDD_SUFFIX: Macros for Initialization. 54129 (line 121) 54130* ldexpM3 instruction pattern: Standard Names. (line 922) 54131* LD_FINI_SWITCH: Macros for Initialization. 54132 (line 28) 54133* LD_INIT_SWITCH: Macros for Initialization. 54134 (line 24) 54135* le: Comparisons. (line 76) 54136* le and attributes: Expressions. (line 83) 54137* leaf functions: Leaf Functions. (line 6) 54138* leaf_function_p: Standard Names. (line 1788) 54139* LEAF_REGISTERS: Leaf Functions. (line 23) 54140* LEAF_REG_REMAP: Leaf Functions. (line 37) 54141* left rotate: Arithmetic. (line 195) 54142* left shift: Arithmetic. (line 173) 54143* LEGITIMATE_PIC_OPERAND_P: PIC. (line 31) 54144* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 150) 54145* length: GTY Options. (line 47) 54146* less than: Comparisons. (line 68) 54147* less than or equal: Comparisons. (line 76) 54148* leu: Comparisons. (line 76) 54149* leu and attributes: Expressions. (line 83) 54150* LE_EXPR: Unary and Binary Expressions. 54151 (line 6) 54152* lfloorMN2: Standard Names. (line 1132) 54153* LIB2FUNCS_EXTRA: Target Fragment. (line 11) 54154* LIBCALL_VALUE: Scalar Return. (line 56) 54155* libgcc.a: Library Calls. (line 6) 54156* LIBGCC2_CFLAGS: Target Fragment. (line 8) 54157* LIBGCC2_GNU_PREFIX: Type Layout. (line 102) 54158* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 1047) 54159* LIBGCC_SPEC: Driver. (line 115) 54160* library subroutine names: Library Calls. (line 6) 54161* LIBRARY_PATH_ENV: Misc. (line 543) 54162* LIB_SPEC: Driver. (line 107) 54163* LIMIT_RELOAD_CLASS: Register Classes. (line 296) 54164* LINK_COMMAND_SPEC: Driver. (line 240) 54165* LINK_EH_SPEC: Driver. (line 142) 54166* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 232) 54167* LINK_LIBGCC_SPECIAL_1: Driver. (line 227) 54168* LINK_SPEC: Driver. (line 100) 54169* list: Containers. (line 6) 54170* Liveness representation: Liveness information. 54171 (line 6) 54172* load address instruction: Simple Constraints. (line 162) 54173* LOAD_EXTEND_OP: Misc. (line 80) 54174* load_multiple instruction pattern: Standard Names. (line 136) 54175* Local Register Allocator (LRA): RTL passes. (line 187) 54176* LOCAL_ALIGNMENT: Storage Layout. (line 284) 54177* LOCAL_CLASS_P: Classes. (line 70) 54178* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 321) 54179* LOCAL_INCLUDE_DIR: Driver. (line 316) 54180* LOCAL_LABEL_PREFIX: Instruction Output. (line 151) 54181* LOCAL_REGNO: Register Basics. (line 143) 54182* location information: Guidelines for Diagnostics. 54183 (line 159) 54184* log10M2 instruction pattern: Standard Names. (line 1026) 54185* log1pM2 instruction pattern: Standard Names. (line 1016) 54186* log2M2 instruction pattern: Standard Names. (line 1033) 54187* logbM2 instruction pattern: Standard Names. (line 1040) 54188* Logical Operators: Logical Operators. (line 6) 54189* logical-and, bitwise: Arithmetic. (line 158) 54190* LOGICAL_OP_NON_SHORT_CIRCUIT: Costs. (line 294) 54191* logM2 instruction pattern: Standard Names. (line 1009) 54192* LOG_LINKS: Insns. (line 337) 54193* longjmp and automatic variables: Interface. (line 52) 54194* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 92) 54195* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 57) 54196* LONG_FRACT_TYPE_SIZE: Type Layout. (line 72) 54197* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 97) 54198* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 77) 54199* LONG_LONG_TYPE_SIZE: Type Layout. (line 32) 54200* LONG_TYPE_SIZE: Type Layout. (line 21) 54201* Loop analysis: Loop representation. 54202 (line 6) 54203* Loop manipulation: Loop manipulation. (line 6) 54204* Loop querying: Loop querying. (line 6) 54205* Loop representation: Loop representation. 54206 (line 6) 54207* Loop-closed SSA form: LCSSA. (line 6) 54208* looping instruction patterns: Looping Patterns. (line 6) 54209* LOOP_ALIGN: Alignment Output. (line 29) 54210* LOOP_EXPR: Unary and Binary Expressions. 54211 (line 6) 54212* lowering, language-dependent intermediate representation: Parsing pass. 54213 (line 13) 54214* lo_sum: Arithmetic. (line 25) 54215* lrintMN2: Standard Names. (line 1122) 54216* lroundMN2: Standard Names. (line 1127) 54217* lshiftrt: Arithmetic. (line 190) 54218* lshiftrt and attributes: Expressions. (line 83) 54219* LSHIFT_EXPR: Unary and Binary Expressions. 54220 (line 6) 54221* lshrM3 instruction pattern: Standard Names. (line 840) 54222* lt: Comparisons. (line 68) 54223* lt and attributes: Expressions. (line 83) 54224* LTGT_EXPR: Unary and Binary Expressions. 54225 (line 6) 54226* lto: LTO. (line 6) 54227* ltrans: LTO. (line 6) 54228* ltu: Comparisons. (line 68) 54229* LT_EXPR: Unary and Binary Expressions. 54230 (line 6) 54231* m in constraint: Simple Constraints. (line 17) 54232* machine attributes: Target Attributes. (line 6) 54233* machine description macros: Target Macros. (line 6) 54234* machine descriptions: Machine Desc. (line 6) 54235* machine mode conversions: Conversions. (line 6) 54236* machine mode wrapper classes: Machine Modes. (line 286) 54237* machine modes: Machine Modes. (line 6) 54238* machine specific constraints: Machine Constraints. 54239 (line 6) 54240* machine-independent predicates: Machine-Independent Predicates. 54241 (line 6) 54242* machine_mode: Machine Modes. (line 6) 54243* MACH_DEP_SECTION_ASM_FLAG: Sections. (line 120) 54244* macros, target description: Target Macros. (line 6) 54245* maddMN4 instruction pattern: Standard Names. (line 761) 54246* makefile fragment: Fragments. (line 6) 54247* makefile targets: Makefile. (line 6) 54248* MAKE_DECL_ONE_ONLY: Label Output. (line 281) 54249* make_safe_from: Expander Definitions. 54250 (line 151) 54251* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 190) 54252* Manipulating GIMPLE statements: Manipulating GIMPLE statements. 54253 (line 6) 54254* marking roots: GGC Roots. (line 6) 54255* maskloadMN instruction pattern: Standard Names. (line 396) 54256* maskstoreMN instruction pattern: Standard Names. (line 403) 54257* mask_fold_left_plus_M instruction pattern: Standard Names. (line 564) 54258* mask_gather_loadMN instruction pattern: Standard Names. (line 249) 54259* MASK_RETURN_ADDR: Exception Region Output. 54260 (line 35) 54261* mask_scatter_storeMN instruction pattern: Standard Names. (line 272) 54262* Match and Simplify: Match and Simplify. (line 6) 54263* matching constraint: Simple Constraints. (line 140) 54264* matching operands: Output Template. (line 49) 54265* match_dup: RTL Template. (line 73) 54266* match_dup <1>: define_peephole2. (line 28) 54267* match_dup and attributes: Insn Lengths. (line 16) 54268* match_operand: RTL Template. (line 16) 54269* match_operand and attributes: Expressions. (line 55) 54270* match_operator: RTL Template. (line 95) 54271* match_op_dup: RTL Template. (line 163) 54272* match_parallel: RTL Template. (line 172) 54273* match_par_dup: RTL Template. (line 219) 54274* match_scratch: RTL Template. (line 58) 54275* match_scratch <1>: define_peephole2. (line 28) 54276* match_test and attributes: Expressions. (line 64) 54277* math library: Soft float library routines. 54278 (line 6) 54279* math, in RTL: Arithmetic. (line 6) 54280* matherr: Library Calls. (line 59) 54281* MATH_LIBRARY: Misc. (line 536) 54282* maxM3 instruction pattern: Standard Names. (line 503) 54283* MAX_BITSIZE_MODE_ANY_INT: Machine Modes. (line 444) 54284* MAX_BITSIZE_MODE_ANY_MODE: Machine Modes. (line 450) 54285* MAX_BITS_PER_WORD: Storage Layout. (line 54) 54286* MAX_CONDITIONAL_EXECUTE: Misc. (line 558) 54287* MAX_FIXED_MODE_SIZE: Storage Layout. (line 466) 54288* MAX_MOVE_MAX: Misc. (line 127) 54289* MAX_OFILE_ALIGNMENT: Storage Layout. (line 228) 54290* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42) 54291* MAX_STACK_ALIGNMENT: Storage Layout. (line 222) 54292* maybe_undef: GTY Options. (line 141) 54293* may_trap_p, tree_could_trap_p: Edges. (line 114) 54294* mcount: Profiling. (line 12) 54295* MD_EXEC_PREFIX: Driver. (line 271) 54296* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 93) 54297* MD_HANDLE_UNWABI: Exception Handling. (line 112) 54298* MD_STARTFILE_PREFIX: Driver. (line 299) 54299* MD_STARTFILE_PREFIX_1: Driver. (line 304) 54300* mem: Regs and Memory. (line 396) 54301* mem and /c: Flags. (line 70) 54302* mem and /f: Flags. (line 74) 54303* mem and /j: Flags. (line 59) 54304* mem and /u: Flags. (line 78) 54305* mem and /v: Flags. (line 65) 54306* mem, RTL sharing: Sharing. (line 43) 54307* memory model: Memory model. (line 6) 54308* memory reference, nonoffsettable: Simple Constraints. (line 254) 54309* memory references in constraints: Simple Constraints. (line 17) 54310* memory_barrier instruction pattern: Standard Names. (line 2172) 54311* memory_blockage instruction pattern: Standard Names. (line 2163) 54312* MEMORY_MOVE_COST: Costs. (line 53) 54313* memory_operand: Machine-Independent Predicates. 54314 (line 57) 54315* MEM_ADDR_SPACE: Special Accessors. (line 48) 54316* MEM_ALIAS_SET: Special Accessors. (line 9) 54317* MEM_ALIGN: Special Accessors. (line 45) 54318* MEM_EXPR: Special Accessors. (line 19) 54319* MEM_KEEP_ALIAS_SET_P: Flags. (line 59) 54320* MEM_NOTRAP_P: Flags. (line 70) 54321* MEM_OFFSET: Special Accessors. (line 31) 54322* MEM_OFFSET_KNOWN_P: Special Accessors. (line 27) 54323* MEM_POINTER: Flags. (line 74) 54324* MEM_READONLY_P: Flags. (line 78) 54325* MEM_REF: Storage References. (line 6) 54326* MEM_SIZE: Special Accessors. (line 39) 54327* MEM_SIZE_KNOWN_P: Special Accessors. (line 35) 54328* mem_thread_fence instruction pattern: Standard Names. (line 2462) 54329* MEM_VOLATILE_P: Flags. (line 65) 54330* METHOD_TYPE: Types. (line 6) 54331* MINIMUM_ALIGNMENT: Storage Layout. (line 334) 54332* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 198) 54333* minM3 instruction pattern: Standard Names. (line 503) 54334* minus: Arithmetic. (line 38) 54335* minus and attributes: Expressions. (line 83) 54336* minus, canonicalization of: Insn Canonicalizations. 54337 (line 27) 54338* MINUS_EXPR: Unary and Binary Expressions. 54339 (line 6) 54340* MIN_UNITS_PER_WORD: Storage Layout. (line 64) 54341* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 54342* miscellaneous register hooks: Miscellaneous Register Hooks. 54343 (line 6) 54344* mnemonic attribute: Mnemonic Attribute. (line 6) 54345* mod: Arithmetic. (line 136) 54346* mod and attributes: Expressions. (line 83) 54347* mode classes: Machine Modes. (line 226) 54348* mode iterators in .md files: Mode Iterators. (line 6) 54349* mode switching: Mode Switching. (line 6) 54350* MODE_ACCUM: Machine Modes. (line 256) 54351* MODE_BASE_REG_CLASS: Register Classes. (line 116) 54352* MODE_BASE_REG_REG_CLASS: Register Classes. (line 122) 54353* MODE_CC: Machine Modes. (line 271) 54354* MODE_CC <1>: MODE_CC Condition Codes. 54355 (line 6) 54356* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 129) 54357* MODE_COMPLEX_FLOAT: Machine Modes. (line 267) 54358* MODE_COMPLEX_INT: Machine Modes. (line 264) 54359* MODE_DECIMAL_FLOAT: Machine Modes. (line 244) 54360* MODE_FLOAT: Machine Modes. (line 240) 54361* MODE_FRACT: Machine Modes. (line 248) 54362* MODE_INT: Machine Modes. (line 232) 54363* MODE_PARTIAL_INT: Machine Modes. (line 236) 54364* MODE_POINTER_BOUNDS: Machine Modes. (line 276) 54365* MODE_RANDOM: Machine Modes. (line 281) 54366* MODE_UACCUM: Machine Modes. (line 260) 54367* MODE_UFRACT: Machine Modes. (line 252) 54368* modifiers in constraints: Modifiers. (line 6) 54369* MODIFY_EXPR: Unary and Binary Expressions. 54370 (line 6) 54371* modM3 instruction pattern: Standard Names. (line 442) 54372* modulo scheduling: RTL passes. (line 123) 54373* MOVE_MAX: Misc. (line 122) 54374* MOVE_MAX_PIECES: Costs. (line 210) 54375* MOVE_RATIO: Costs. (line 149) 54376* movM instruction pattern: Standard Names. (line 11) 54377* movmemM instruction pattern: Standard Names. (line 1281) 54378* movmisalignM instruction pattern: Standard Names. (line 125) 54379* movMODEcc instruction pattern: Standard Names. (line 1576) 54380* movstr instruction pattern: Standard Names. (line 1317) 54381* movstrictM instruction pattern: Standard Names. (line 119) 54382* msubMN4 instruction pattern: Standard Names. (line 784) 54383* mulhisi3 instruction pattern: Standard Names. (line 737) 54384* mulM3 instruction pattern: Standard Names. (line 442) 54385* mulqihi3 instruction pattern: Standard Names. (line 741) 54386* mulsidi3 instruction pattern: Standard Names. (line 741) 54387* mult: Arithmetic. (line 93) 54388* mult and attributes: Expressions. (line 83) 54389* mult, canonicalization of: Insn Canonicalizations. 54390 (line 27) 54391* mult, canonicalization of <1>: Insn Canonicalizations. 54392 (line 107) 54393* MULTIARCH_DIRNAME: Target Fragment. (line 173) 54394* MULTILIB_DEFAULTS: Driver. (line 256) 54395* MULTILIB_DIRNAMES: Target Fragment. (line 44) 54396* MULTILIB_EXCEPTIONS: Target Fragment. (line 70) 54397* MULTILIB_EXTRA_OPTS: Target Fragment. (line 135) 54398* MULTILIB_MATCHES: Target Fragment. (line 63) 54399* MULTILIB_OPTIONS: Target Fragment. (line 24) 54400* MULTILIB_OSDIRNAMES: Target Fragment. (line 142) 54401* MULTILIB_REQUIRED: Target Fragment. (line 82) 54402* MULTILIB_REUSE: Target Fragment. (line 103) 54403* multiple alternative constraints: Multi-Alternative. (line 6) 54404* MULTIPLE_SYMBOL_SPACES: Misc. (line 515) 54405* multiplication: Arithmetic. (line 93) 54406* multiplication with signed saturation: Arithmetic. (line 93) 54407* multiplication with unsigned saturation: Arithmetic. (line 93) 54408* MULT_EXPR: Unary and Binary Expressions. 54409 (line 6) 54410* MULT_HIGHPART_EXPR: Unary and Binary Expressions. 54411 (line 6) 54412* mulvM4 instruction pattern: Standard Names. (line 458) 54413* n in constraint: Simple Constraints. (line 73) 54414* name: Identifiers. (line 6) 54415* named address spaces: Named Address Spaces. 54416 (line 6) 54417* named patterns and conditions: Patterns. (line 61) 54418* names, pattern: Standard Names. (line 6) 54419* namespace, scope: Namespaces. (line 6) 54420* NAMESPACE_DECL: Declarations. (line 6) 54421* NAMESPACE_DECL <1>: Namespaces. (line 6) 54422* NATIVE_SYSTEM_HEADER_COMPONENT: Driver. (line 326) 54423* ne: Comparisons. (line 56) 54424* ne and attributes: Expressions. (line 83) 54425* nearbyintM2 instruction pattern: Standard Names. (line 1106) 54426* neg: Arithmetic. (line 82) 54427* neg and attributes: Expressions. (line 83) 54428* neg, canonicalization of: Insn Canonicalizations. 54429 (line 27) 54430* NEGATE_EXPR: Unary and Binary Expressions. 54431 (line 6) 54432* negation: Arithmetic. (line 82) 54433* negation with signed saturation: Arithmetic. (line 82) 54434* negation with unsigned saturation: Arithmetic. (line 82) 54435* negM2 instruction pattern: Standard Names. (line 872) 54436* negMODEcc instruction pattern: Standard Names. (line 1645) 54437* negvM3 instruction pattern: Standard Names. (line 875) 54438* nested functions, support for: Trampolines. (line 6) 54439* nested_ptr: GTY Options. (line 149) 54440* next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks. (line 25) 54441* NEXT_INSN: Insns. (line 30) 54442* NEXT_OBJC_RUNTIME: Library Calls. (line 86) 54443* NE_EXPR: Unary and Binary Expressions. 54444 (line 6) 54445* nil: RTL Objects. (line 73) 54446* NM_FLAGS: Macros for Initialization. 54447 (line 110) 54448* nondeterministic finite state automaton: Processor pipeline description. 54449 (line 304) 54450* nonimmediate_operand: Machine-Independent Predicates. 54451 (line 100) 54452* nonlocal goto handler: Edges. (line 171) 54453* nonlocal_goto instruction pattern: Standard Names. (line 1998) 54454* nonlocal_goto_receiver instruction pattern: Standard Names. 54455 (line 2015) 54456* nonmemory_operand: Machine-Independent Predicates. 54457 (line 96) 54458* nonoffsettable memory reference: Simple Constraints. (line 254) 54459* NON_LVALUE_EXPR: Unary and Binary Expressions. 54460 (line 6) 54461* nop instruction pattern: Standard Names. (line 1821) 54462* NOP_EXPR: Unary and Binary Expressions. 54463 (line 6) 54464* normal predicates: Predicates. (line 31) 54465* not: Arithmetic. (line 154) 54466* not and attributes: Expressions. (line 50) 54467* not equal: Comparisons. (line 56) 54468* not, canonicalization of: Insn Canonicalizations. 54469 (line 27) 54470* note: Insns. (line 183) 54471* note and /i: Flags. (line 48) 54472* note and /v: Flags. (line 33) 54473* NOTE_INSN_BASIC_BLOCK: Basic Blocks. (line 50) 54474* NOTE_INSN_BASIC_BLOCK <1>: Basic Blocks. (line 52) 54475* NOTE_INSN_BEGIN_STMT: Insns. (line 233) 54476* NOTE_INSN_BLOCK_BEG: Insns. (line 208) 54477* NOTE_INSN_BLOCK_END: Insns. (line 208) 54478* NOTE_INSN_DELETED: Insns. (line 198) 54479* NOTE_INSN_DELETED_LABEL: Insns. (line 203) 54480* NOTE_INSN_EH_REGION_BEG: Insns. (line 214) 54481* NOTE_INSN_EH_REGION_END: Insns. (line 214) 54482* NOTE_INSN_FUNCTION_BEG: Insns. (line 221) 54483* NOTE_INSN_INLINE_ENTRY: Insns. (line 238) 54484* NOTE_INSN_VAR_LOCATION: Insns. (line 225) 54485* NOTE_LINE_NUMBER: Insns. (line 183) 54486* NOTE_SOURCE_FILE: Insns. (line 183) 54487* NOTE_VAR_LOCATION: Insns. (line 225) 54488* NOTICE_UPDATE_CC: CC0 Condition Codes. 54489 (line 30) 54490* notMODEcc instruction pattern: Standard Names. (line 1652) 54491* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 25) 54492* NO_DBX_FUNCTION_END: DBX Hooks. (line 19) 54493* NO_DBX_GCC_MARKER: File Names and DBX. (line 27) 54494* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 22) 54495* NO_DOLLAR_IN_LABEL: Label Output. (line 64) 54496* NO_DOT_IN_LABEL: Label Output. (line 70) 54497* NO_FUNCTION_CSE: Costs. (line 289) 54498* NO_PROFILE_COUNTERS: Profiling. (line 27) 54499* NO_REGS: Register Classes. (line 17) 54500* Number of iterations analysis: Number of iterations. 54501 (line 6) 54502* NUM_MACHINE_MODES: Machine Modes. (line 383) 54503* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 54504* NUM_POLY_INT_COEFFS: Overview of poly_int. 54505 (line 24) 54506* N_REG_CLASSES: Register Classes. (line 81) 54507* o in constraint: Simple Constraints. (line 23) 54508* OACC_CACHE: OpenACC. (line 6) 54509* OACC_DATA: OpenACC. (line 6) 54510* OACC_DECLARE: OpenACC. (line 6) 54511* OACC_ENTER_DATA: OpenACC. (line 6) 54512* OACC_EXIT_DATA: OpenACC. (line 6) 54513* OACC_HOST_DATA: OpenACC. (line 6) 54514* OACC_KERNELS: OpenACC. (line 6) 54515* OACC_LOOP: OpenACC. (line 6) 54516* OACC_PARALLEL: OpenACC. (line 6) 54517* OACC_SERIAL: OpenACC. (line 6) 54518* OACC_UPDATE: OpenACC. (line 6) 54519* OBJC_GEN_METHOD_LABEL: Label Output. (line 482) 54520* OBJC_JBLEN: Misc. (line 1042) 54521* OBJECT_FORMAT_COFF: Macros for Initialization. 54522 (line 96) 54523* offsettable address: Simple Constraints. (line 23) 54524* OFFSET_TYPE: Types. (line 6) 54525* OImode: Machine Modes. (line 51) 54526* OMP_ATOMIC: OpenMP. (line 6) 54527* OMP_CLAUSE: OpenMP. (line 6) 54528* OMP_CONTINUE: OpenMP. (line 6) 54529* OMP_CRITICAL: OpenMP. (line 6) 54530* OMP_FOR: OpenMP. (line 6) 54531* OMP_MASTER: OpenMP. (line 6) 54532* OMP_ORDERED: OpenMP. (line 6) 54533* OMP_PARALLEL: OpenMP. (line 6) 54534* OMP_RETURN: OpenMP. (line 6) 54535* OMP_SECTION: OpenMP. (line 6) 54536* OMP_SECTIONS: OpenMP. (line 6) 54537* OMP_SINGLE: OpenMP. (line 6) 54538* one_cmplM2 instruction pattern: Standard Names. (line 1241) 54539* operand access: Accessors. (line 6) 54540* Operand Access Routines: SSA Operands. (line 116) 54541* operand constraints: Constraints. (line 6) 54542* Operand Iterators: SSA Operands. (line 116) 54543* operand predicates: Predicates. (line 6) 54544* operand substitution: Output Template. (line 6) 54545* Operands: Operands. (line 6) 54546* operands: SSA Operands. (line 6) 54547* operands <1>: Patterns. (line 67) 54548* operator predicates: Predicates. (line 6) 54549* optc-gen.awk: Options. (line 6) 54550* OPTGROUP_ALL: Optimization groups. 54551 (line 28) 54552* OPTGROUP_INLINE: Optimization groups. 54553 (line 15) 54554* OPTGROUP_IPA: Optimization groups. 54555 (line 9) 54556* OPTGROUP_LOOP: Optimization groups. 54557 (line 12) 54558* OPTGROUP_OMP: Optimization groups. 54559 (line 18) 54560* OPTGROUP_OTHER: Optimization groups. 54561 (line 24) 54562* OPTGROUP_VEC: Optimization groups. 54563 (line 21) 54564* optimization dumps: Optimization info. (line 6) 54565* optimization groups: Optimization groups. 54566 (line 6) 54567* optimization info file names: Dump files and streams. 54568 (line 6) 54569* Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 54570* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 8) 54571* option specification files: Options. (line 6) 54572* optional hardware or system features: Run-time Target. (line 59) 54573* options, directory search: Including Patterns. (line 47) 54574* options, guidelines for: Guidelines for Options. 54575 (line 6) 54576* OPTION_DEFAULT_SPECS: Driver. (line 25) 54577* opt_mode: Machine Modes. (line 322) 54578* order of register allocation: Allocation Order. (line 6) 54579* ordered_comparison_operator: Machine-Independent Predicates. 54580 (line 115) 54581* ORDERED_EXPR: Unary and Binary Expressions. 54582 (line 6) 54583* Ordering of Patterns: Pattern Ordering. (line 6) 54584* ORIGINAL_REGNO: Special Accessors. (line 53) 54585* other register constraints: Simple Constraints. (line 171) 54586* outgoing_args_size: Stack Arguments. (line 48) 54587* OUTGOING_REGNO: Register Basics. (line 136) 54588* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 79) 54589* output of assembler code: File Framework. (line 6) 54590* output statements: Output Statement. (line 6) 54591* output templates: Output Template. (line 6) 54592* output_asm_insn: Output Statement. (line 52) 54593* OUTPUT_QUOTED_STRING: File Framework. (line 105) 54594* OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 20) 54595* OVERLOAD: Functions for C++. (line 6) 54596* OVERRIDE_ABI_FORMAT: Register Arguments. (line 150) 54597* OVL_CURRENT: Functions for C++. (line 6) 54598* OVL_NEXT: Functions for C++. (line 6) 54599* p in constraint: Simple Constraints. (line 162) 54600* PAD_VARARGS_DOWN: Register Arguments. (line 230) 54601* parallel: Side Effects. (line 210) 54602* parameters, c++ abi: C++ ABI. (line 6) 54603* parameters, d abi: D Language and ABI. (line 6) 54604* parameters, miscellaneous: Misc. (line 6) 54605* parameters, precompiled headers: PCH Target. (line 6) 54606* parity: Arithmetic. (line 242) 54607* parityM2 instruction pattern: Standard Names. (line 1228) 54608* PARM_BOUNDARY: Storage Layout. (line 150) 54609* PARM_DECL: Declarations. (line 6) 54610* PARSE_LDD_OUTPUT: Macros for Initialization. 54611 (line 125) 54612* pass dumps: Passes. (line 6) 54613* passes and files of the compiler: Passes. (line 6) 54614* passing arguments: Interface. (line 36) 54615* pass_duplicate_computed_gotos: Edges. (line 161) 54616* PATH_SEPARATOR: Filesystem. (line 31) 54617* PATTERN: Insns. (line 307) 54618* pattern conditions: Patterns. (line 55) 54619* pattern names: Standard Names. (line 6) 54620* Pattern Ordering: Pattern Ordering. (line 6) 54621* patterns: Patterns. (line 6) 54622* pc: Regs and Memory. (line 383) 54623* pc and attributes: Insn Lengths. (line 20) 54624* pc, RTL sharing: Sharing. (line 28) 54625* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 360) 54626* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 64) 54627* PC_REGNUM: Register Basics. (line 150) 54628* pc_rtx: Regs and Memory. (line 388) 54629* PDImode: Machine Modes. (line 40) 54630* peephole optimization, RTL representation: Side Effects. (line 244) 54631* peephole optimizer definitions: Peephole Definitions. 54632 (line 6) 54633* per-function data: Per-Function Data. (line 6) 54634* percent sign: Output Template. (line 6) 54635* PHI nodes: SSA. (line 31) 54636* PIC: PIC. (line 6) 54637* PIC_OFFSET_TABLE_REGNUM: PIC. (line 15) 54638* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 25) 54639* pipeline hazard recognizer: Processor pipeline description. 54640 (line 6) 54641* pipeline hazard recognizer <1>: Processor pipeline description. 54642 (line 53) 54643* Plugins: Plugins. (line 6) 54644* plus: Arithmetic. (line 14) 54645* plus and attributes: Expressions. (line 83) 54646* plus, canonicalization of: Insn Canonicalizations. 54647 (line 27) 54648* PLUS_EXPR: Unary and Binary Expressions. 54649 (line 6) 54650* Pmode: Misc. (line 363) 54651* pmode_register_operand: Machine-Independent Predicates. 54652 (line 34) 54653* pointer: Types. (line 6) 54654* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 76) 54655* POINTER_DIFF_EXPR: Unary and Binary Expressions. 54656 (line 6) 54657* POINTER_PLUS_EXPR: Unary and Binary Expressions. 54658 (line 6) 54659* POINTER_SIZE: Storage Layout. (line 70) 54660* POINTER_TYPE: Types. (line 6) 54661* polynomial integers: poly_int. (line 6) 54662* poly_int: poly_int. (line 6) 54663* poly_int, invariant range: Overview of poly_int. 54664 (line 31) 54665* poly_int, main typedefs: Overview of poly_int. 54666 (line 46) 54667* poly_int, runtime value: Overview of poly_int. 54668 (line 6) 54669* poly_int, template parameters: Overview of poly_int. 54670 (line 24) 54671* poly_int, use in target-independent code: Consequences of using poly_int. 54672 (line 32) 54673* poly_int, use in target-specific code: Consequences of using poly_int. 54674 (line 40) 54675* POLY_INT_CST: Constant expressions. 54676 (line 6) 54677* popcount: Arithmetic. (line 238) 54678* popcountM2 instruction pattern: Standard Names. (line 1216) 54679* pops_args: Function Entry. (line 111) 54680* pop_operand: Machine-Independent Predicates. 54681 (line 87) 54682* portability: Portability. (line 6) 54683* position independent code: PIC. (line 6) 54684* POSTDECREMENT_EXPR: Unary and Binary Expressions. 54685 (line 6) 54686* POSTINCREMENT_EXPR: Unary and Binary Expressions. 54687 (line 6) 54688* post_dec: Incdec. (line 25) 54689* post_inc: Incdec. (line 30) 54690* POST_LINK_SPEC: Driver. (line 236) 54691* post_modify: Incdec. (line 33) 54692* post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks. 54693 (line 34) 54694* POWI_MAX_MULTS: Misc. (line 927) 54695* powM3 instruction pattern: Standard Names. (line 1054) 54696* pragma: Misc. (line 420) 54697* PREDECREMENT_EXPR: Unary and Binary Expressions. 54698 (line 6) 54699* predefined macros: Run-time Target. (line 6) 54700* predicates: Predicates. (line 6) 54701* predicates and machine modes: Predicates. (line 31) 54702* predication: Conditional Execution. 54703 (line 6) 54704* predict.def: Profile information. 54705 (line 24) 54706* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 40) 54707* PREFERRED_RELOAD_CLASS: Register Classes. (line 249) 54708* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 164) 54709* prefetch: Side Effects. (line 324) 54710* prefetch and /v: Flags. (line 92) 54711* prefetch instruction pattern: Standard Names. (line 2140) 54712* PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 92) 54713* PREINCREMENT_EXPR: Unary and Binary Expressions. 54714 (line 6) 54715* presence_set: Processor pipeline description. 54716 (line 223) 54717* preserving SSA form: SSA. (line 74) 54718* pretend_args_size: Function Entry. (line 117) 54719* prev_active_insn: define_peephole. (line 60) 54720* PREV_INSN: Insns. (line 26) 54721* pre_dec: Incdec. (line 8) 54722* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 126) 54723* pre_inc: Incdec. (line 22) 54724* pre_modify: Incdec. (line 52) 54725* PRINT_OPERAND: Instruction Output. (line 95) 54726* PRINT_OPERAND_ADDRESS: Instruction Output. (line 122) 54727* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 115) 54728* probe_stack instruction pattern: Standard Names. (line 1990) 54729* probe_stack_address instruction pattern: Standard Names. (line 1983) 54730* processor functional units: Processor pipeline description. 54731 (line 6) 54732* processor functional units <1>: Processor pipeline description. 54733 (line 68) 54734* processor pipeline description: Processor pipeline description. 54735 (line 6) 54736* product: Arithmetic. (line 93) 54737* profile feedback: Profile information. 54738 (line 14) 54739* profile representation: Profile information. 54740 (line 6) 54741* PROFILE_BEFORE_PROLOGUE: Profiling. (line 34) 54742* PROFILE_HOOK: Profiling. (line 22) 54743* profiling, code generation: Profiling. (line 6) 54744* program counter: Regs and Memory. (line 384) 54745* prologue: Function Entry. (line 6) 54746* prologue instruction pattern: Standard Names. (line 2079) 54747* PROMOTE_MODE: Storage Layout. (line 87) 54748* pseudo registers: Regs and Memory. (line 9) 54749* PSImode: Machine Modes. (line 32) 54750* PTRDIFF_TYPE: Type Layout. (line 157) 54751* purge_dead_edges: Edges. (line 103) 54752* purge_dead_edges <1>: Maintaining the CFG. 54753 (line 81) 54754* push address instruction: Simple Constraints. (line 162) 54755* pushM1 instruction pattern: Standard Names. (line 429) 54756* PUSH_ARGS: Stack Arguments. (line 17) 54757* PUSH_ARGS_REVERSED: Stack Arguments. (line 25) 54758* push_operand: Machine-Independent Predicates. 54759 (line 80) 54760* push_reload: Addressing Modes. (line 176) 54761* PUSH_ROUNDING: Stack Arguments. (line 31) 54762* PUT_CODE: RTL Objects. (line 47) 54763* PUT_MODE: Machine Modes. (line 380) 54764* PUT_REG_NOTE_KIND: Insns. (line 369) 54765* QCmode: Machine Modes. (line 199) 54766* QFmode: Machine Modes. (line 57) 54767* QImode: Machine Modes. (line 25) 54768* QImode, in insn: Insns. (line 291) 54769* QQmode: Machine Modes. (line 106) 54770* qualified type: Types. (line 6) 54771* qualified type <1>: Types for C++. (line 6) 54772* querying function unit reservations: Processor pipeline description. 54773 (line 90) 54774* question mark: Multi-Alternative. (line 42) 54775* quotient: Arithmetic. (line 116) 54776* r in constraint: Simple Constraints. (line 64) 54777* RDIV_EXPR: Unary and Binary Expressions. 54778 (line 6) 54779* READONLY_DATA_SECTION_ASM_OP: Sections. (line 62) 54780* real operands: SSA Operands. (line 6) 54781* REALPART_EXPR: Unary and Binary Expressions. 54782 (line 6) 54783* REAL_CST: Constant expressions. 54784 (line 6) 54785* REAL_LIBGCC_SPEC: Driver. (line 124) 54786* REAL_NM_FILE_NAME: Macros for Initialization. 54787 (line 105) 54788* REAL_TYPE: Types. (line 6) 54789* REAL_VALUE_ABS: Floating Point. (line 58) 54790* REAL_VALUE_ATOF: Floating Point. (line 39) 54791* REAL_VALUE_FIX: Floating Point. (line 31) 54792* REAL_VALUE_ISINF: Floating Point. (line 49) 54793* REAL_VALUE_ISNAN: Floating Point. (line 52) 54794* REAL_VALUE_NEGATE: Floating Point. (line 55) 54795* REAL_VALUE_NEGATIVE: Floating Point. (line 46) 54796* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 153) 54797* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 151) 54798* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 152) 54799* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 149) 54800* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 150) 54801* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 148) 54802* REAL_VALUE_TYPE: Floating Point. (line 25) 54803* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 34) 54804* recognizing insns: RTL Template. (line 6) 54805* recog_data.operand: Instruction Output. (line 54) 54806* RECORD_TYPE: Types. (line 6) 54807* RECORD_TYPE <1>: Classes. (line 6) 54808* redirect_edge_and_branch: Profile information. 54809 (line 71) 54810* redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 54811 (line 89) 54812* reduc_and_scal_M instruction pattern: Standard Names. (line 535) 54813* reduc_ior_scal_M instruction pattern: Standard Names. (line 536) 54814* reduc_plus_scal_M instruction pattern: Standard Names. (line 530) 54815* reduc_smax_scal_M instruction pattern: Standard Names. (line 520) 54816* reduc_smin_scal_M instruction pattern: Standard Names. (line 520) 54817* reduc_umax_scal_M instruction pattern: Standard Names. (line 525) 54818* reduc_umin_scal_M instruction pattern: Standard Names. (line 525) 54819* reduc_xor_scal_M instruction pattern: Standard Names. (line 537) 54820* reference: Types. (line 6) 54821* REFERENCE_TYPE: Types. (line 6) 54822* reg: Regs and Memory. (line 9) 54823* reg and /f: Flags. (line 102) 54824* reg and /i: Flags. (line 97) 54825* reg and /v: Flags. (line 106) 54826* reg, RTL sharing: Sharing. (line 17) 54827* register allocation order: Allocation Order. (line 6) 54828* register class definitions: Register Classes. (line 6) 54829* register class preference constraints: Class Preferences. (line 6) 54830* register pairs: Values in Registers. 54831 (line 65) 54832* Register Transfer Language (RTL): RTL. (line 6) 54833* register usage: Registers. (line 6) 54834* registers arguments: Register Arguments. (line 6) 54835* registers in constraints: Simple Constraints. (line 64) 54836* REGISTER_MOVE_COST: Costs. (line 9) 54837* REGISTER_NAMES: Instruction Output. (line 8) 54838* register_operand: Machine-Independent Predicates. 54839 (line 29) 54840* REGISTER_PREFIX: Instruction Output. (line 150) 54841* REGISTER_TARGET_PRAGMAS: Misc. (line 420) 54842* REGMODE_NATURAL_SIZE: Regs and Memory. (line 191) 54843* REGMODE_NATURAL_SIZE <1>: Regs and Memory. (line 268) 54844* REGMODE_NATURAL_SIZE <2>: Values in Registers. 54845 (line 46) 54846* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 172) 54847* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 150) 54848* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 160) 54849* REGNO_OK_FOR_BASE_P: Register Classes. (line 146) 54850* REGNO_OK_FOR_INDEX_P: Register Classes. (line 186) 54851* REGNO_REG_CLASS: Register Classes. (line 105) 54852* regs_ever_live: Function Entry. (line 29) 54853* regular expressions: Processor pipeline description. 54854 (line 6) 54855* regular expressions <1>: Processor pipeline description. 54856 (line 105) 54857* regular IPA passes: Regular IPA passes. (line 6) 54858* REG_ALLOC_ORDER: Allocation Order. (line 8) 54859* REG_BR_PRED: Insns. (line 541) 54860* REG_BR_PROB: Insns. (line 533) 54861* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 54862 (line 82) 54863* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 54864 (line 52) 54865* REG_CALL_NOCF_CHECK: Insns. (line 557) 54866* REG_CC_SETTER: Insns. (line 505) 54867* REG_CC_USER: Insns. (line 505) 54868* reg_class_contents: Register Basics. (line 102) 54869* REG_CLASS_CONTENTS: Register Classes. (line 91) 54870* reg_class_for_constraint: C Constraint Interface. 54871 (line 48) 54872* REG_CLASS_NAMES: Register Classes. (line 86) 54873* REG_DEAD: Insns. (line 380) 54874* REG_DEAD, REG_UNUSED: Liveness information. 54875 (line 32) 54876* REG_DEP_ANTI: Insns. (line 527) 54877* REG_DEP_OUTPUT: Insns. (line 523) 54878* REG_DEP_TRUE: Insns. (line 520) 54879* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 109) 54880* REG_EQUAL: Insns. (line 434) 54881* REG_EQUIV: Insns. (line 434) 54882* REG_EXPR: Special Accessors. (line 58) 54883* REG_FRAME_RELATED_EXPR: Insns. (line 547) 54884* REG_FUNCTION_VALUE_P: Flags. (line 97) 54885* REG_INC: Insns. (line 396) 54886* reg_label and /v: Flags. (line 54) 54887* REG_LABEL_OPERAND: Insns. (line 410) 54888* REG_LABEL_TARGET: Insns. (line 419) 54889* reg_names: Register Basics. (line 102) 54890* reg_names <1>: Instruction Output. (line 107) 54891* REG_NONNEG: Insns. (line 402) 54892* REG_NOTES: Insns. (line 344) 54893* REG_NOTE_KIND: Insns. (line 369) 54894* REG_OFFSET: Special Accessors. (line 62) 54895* REG_OK_STRICT: Addressing Modes. (line 99) 54896* REG_PARM_STACK_SPACE: Stack Arguments. (line 58) 54897* REG_PARM_STACK_SPACE, and TARGET_FUNCTION_ARG: Register Arguments. 54898 (line 49) 54899* REG_POINTER: Flags. (line 102) 54900* REG_SETJMP: Insns. (line 428) 54901* REG_UNUSED: Insns. (line 389) 54902* REG_USERVAR_P: Flags. (line 106) 54903* REG_VALUE_IN_UNWIND_CONTEXT: Frame Registers. (line 156) 54904* REG_WORDS_BIG_ENDIAN: Storage Layout. (line 35) 54905* relative costs: Costs. (line 6) 54906* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 266) 54907* reloading: RTL passes. (line 170) 54908* reload_completed: Standard Names. (line 1788) 54909* reload_in instruction pattern: Standard Names. (line 98) 54910* reload_in_progress: Standard Names. (line 57) 54911* reload_out instruction pattern: Standard Names. (line 98) 54912* remainder: Arithmetic. (line 136) 54913* remainderM3 instruction pattern: Standard Names. (line 908) 54914* reorder: GTY Options. (line 175) 54915* representation of RTL: RTL. (line 6) 54916* reservation delays: Processor pipeline description. 54917 (line 6) 54918* restore_stack_block instruction pattern: Standard Names. (line 1904) 54919* restore_stack_function instruction pattern: Standard Names. 54920 (line 1904) 54921* restore_stack_nonlocal instruction pattern: Standard Names. 54922 (line 1904) 54923* rest_of_decl_compilation: Parsing pass. (line 51) 54924* rest_of_type_compilation: Parsing pass. (line 51) 54925* RESULT_DECL: Declarations. (line 6) 54926* return: Side Effects. (line 72) 54927* return instruction pattern: Standard Names. (line 1762) 54928* return values in registers: Scalar Return. (line 6) 54929* returning aggregate values: Aggregate Return. (line 6) 54930* returning structures and unions: Interface. (line 10) 54931* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 64) 54932* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 127) 54933* RETURN_ADDR_OFFSET: Exception Handling. (line 59) 54934* RETURN_ADDR_RTX: Frame Layout. (line 116) 54935* RETURN_EXPR: Statements for C++. (line 6) 54936* RETURN_STMT: Statements for C++. (line 6) 54937* return_val: Flags. (line 283) 54938* return_val, in call_insn: Flags. (line 120) 54939* return_val, in reg: Flags. (line 97) 54940* return_val, in symbol_ref: Flags. (line 216) 54941* reverse probability: Profile information. 54942 (line 66) 54943* REVERSE_CONDITION: MODE_CC Condition Codes. 54944 (line 92) 54945* REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 54946 (line 77) 54947* right rotate: Arithmetic. (line 195) 54948* right shift: Arithmetic. (line 190) 54949* rintM2 instruction pattern: Standard Names. (line 1114) 54950* RISC: Processor pipeline description. 54951 (line 6) 54952* RISC <1>: Processor pipeline description. 54953 (line 223) 54954* roots, marking: GGC Roots. (line 6) 54955* rotate: Arithmetic. (line 195) 54956* rotate <1>: Arithmetic. (line 195) 54957* rotatert: Arithmetic. (line 195) 54958* rotlM3 instruction pattern: Standard Names. (line 840) 54959* rotrM3 instruction pattern: Standard Names. (line 840) 54960* roundM2 instruction pattern: Standard Names. (line 1087) 54961* ROUND_DIV_EXPR: Unary and Binary Expressions. 54962 (line 6) 54963* ROUND_MOD_EXPR: Unary and Binary Expressions. 54964 (line 6) 54965* ROUND_TYPE_ALIGN: Storage Layout. (line 457) 54966* RSHIFT_EXPR: Unary and Binary Expressions. 54967 (line 6) 54968* rsqrtM2 instruction pattern: Standard Names. (line 888) 54969* RTL addition: Arithmetic. (line 14) 54970* RTL addition with signed saturation: Arithmetic. (line 14) 54971* RTL addition with unsigned saturation: Arithmetic. (line 14) 54972* RTL classes: RTL Classes. (line 6) 54973* RTL comparison: Arithmetic. (line 46) 54974* RTL comparison operations: Comparisons. (line 6) 54975* RTL constant expression types: Constants. (line 6) 54976* RTL constants: Constants. (line 6) 54977* RTL declarations: RTL Declarations. (line 6) 54978* RTL difference: Arithmetic. (line 38) 54979* RTL expression: RTL Objects. (line 6) 54980* RTL expressions for arithmetic: Arithmetic. (line 6) 54981* RTL format: RTL Classes. (line 73) 54982* RTL format characters: RTL Classes. (line 78) 54983* RTL function-call insns: Calls. (line 6) 54984* RTL insn template: RTL Template. (line 6) 54985* RTL integers: RTL Objects. (line 6) 54986* RTL memory expressions: Regs and Memory. (line 6) 54987* RTL object types: RTL Objects. (line 6) 54988* RTL postdecrement: Incdec. (line 6) 54989* RTL postincrement: Incdec. (line 6) 54990* RTL predecrement: Incdec. (line 6) 54991* RTL preincrement: Incdec. (line 6) 54992* RTL register expressions: Regs and Memory. (line 6) 54993* RTL representation: RTL. (line 6) 54994* RTL side effect expressions: Side Effects. (line 6) 54995* RTL strings: RTL Objects. (line 6) 54996* RTL structure sharing assumptions: Sharing. (line 6) 54997* RTL subtraction: Arithmetic. (line 38) 54998* RTL subtraction with signed saturation: Arithmetic. (line 38) 54999* RTL subtraction with unsigned saturation: Arithmetic. (line 38) 55000* RTL sum: Arithmetic. (line 14) 55001* RTL vectors: RTL Objects. (line 6) 55002* RTL_CONST_CALL_P: Flags. (line 115) 55003* RTL_CONST_OR_PURE_CALL_P: Flags. (line 125) 55004* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 129) 55005* RTL_PURE_CALL_P: Flags. (line 120) 55006* RTX (See RTL): RTL Objects. (line 6) 55007* RTX codes, classes of: RTL Classes. (line 6) 55008* RTX_FRAME_RELATED_P: Flags. (line 135) 55009* run-time conventions: Interface. (line 6) 55010* run-time target specification: Run-time Target. (line 6) 55011* s in constraint: Simple Constraints. (line 100) 55012* SAD_EXPR: Vectors. (line 6) 55013* same_type_p: Types. (line 86) 55014* SAmode: Machine Modes. (line 150) 55015* satfractMN2 instruction pattern: Standard Names. (line 1464) 55016* satfractunsMN2 instruction pattern: Standard Names. (line 1477) 55017* satisfies_constraint_M: C Constraint Interface. 55018 (line 36) 55019* sat_fract: Conversions. (line 90) 55020* SAVE_EXPR: Unary and Binary Expressions. 55021 (line 6) 55022* save_stack_block instruction pattern: Standard Names. (line 1904) 55023* save_stack_function instruction pattern: Standard Names. (line 1904) 55024* save_stack_nonlocal instruction pattern: Standard Names. (line 1904) 55025* SBSS_SECTION_ASM_OP: Sections. (line 75) 55026* Scalar evolutions: Scalar evolutions. (line 6) 55027* scalars, returned as values: Scalar Return. (line 6) 55028* scalar_float_mode: Machine Modes. (line 293) 55029* scalar_int_mode: Machine Modes. (line 290) 55030* scalar_mode: Machine Modes. (line 296) 55031* scalbM3 instruction pattern: Standard Names. (line 915) 55032* scatter_storeMN instruction pattern: Standard Names. (line 255) 55033* SCHED_GROUP_P: Flags. (line 162) 55034* SCmode: Machine Modes. (line 199) 55035* scratch: Regs and Memory. (line 320) 55036* scratch operands: Regs and Memory. (line 320) 55037* scratch, RTL sharing: Sharing. (line 38) 55038* scratch_operand: Machine-Independent Predicates. 55039 (line 49) 55040* SDATA_SECTION_ASM_OP: Sections. (line 57) 55041* sdiv_pow2M3 instruction pattern: Standard Names. (line 614) 55042* sdiv_pow2M3 instruction pattern <1>: Standard Names. (line 615) 55043* SDmode: Machine Modes. (line 88) 55044* sdot_prodM instruction pattern: Standard Names. (line 569) 55045* search options: Including Patterns. (line 47) 55046* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 391) 55047* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 457) 55048* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 392) 55049* SECONDARY_RELOAD_CLASS: Register Classes. (line 390) 55050* SELECT_CC_MODE: MODE_CC Condition Codes. 55051 (line 6) 55052* sequence: Side Effects. (line 259) 55053* Sequence iterators: Sequence iterators. (line 6) 55054* set: Side Effects. (line 15) 55055* set and /f: Flags. (line 135) 55056* setmemM instruction pattern: Standard Names. (line 1328) 55057* SETUP_FRAME_ADDRESSES: Frame Layout. (line 94) 55058* SET_ASM_OP: Label Output. (line 451) 55059* SET_ASM_OP <1>: Label Output. (line 462) 55060* set_attr: Tagging Insns. (line 31) 55061* set_attr_alternative: Tagging Insns. (line 49) 55062* set_bb_seq: GIMPLE sequences. (line 75) 55063* SET_DEST: Side Effects. (line 69) 55064* SET_IS_RETURN_P: Flags. (line 171) 55065* SET_LABEL_KIND: Insns. (line 146) 55066* set_optab_libfunc: Library Calls. (line 15) 55067* SET_RATIO: Costs. (line 237) 55068* SET_SRC: Side Effects. (line 69) 55069* set_thread_pointerMODE instruction pattern: Standard Names. 55070 (line 2477) 55071* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6) 55072* SET_TYPE_STRUCTURAL_EQUALITY <1>: Types. (line 81) 55073* SFmode: Machine Modes. (line 69) 55074* sharing of RTL components: Sharing. (line 6) 55075* shift: Arithmetic. (line 173) 55076* SHIFT_COUNT_TRUNCATED: Misc. (line 134) 55077* SHLIB_SUFFIX: Macros for Initialization. 55078 (line 133) 55079* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 82) 55080* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 62) 55081* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 108) 55082* SHORT_TYPE_SIZE: Type Layout. (line 15) 55083* shrink-wrapping separate components: Shrink-wrapping separate components. 55084 (line 6) 55085* sibcall_epilogue instruction pattern: Standard Names. (line 2111) 55086* sibling call: Edges. (line 121) 55087* SIBLING_CALL_P: Flags. (line 175) 55088* signal-to-noise ratio (metaphorical usage for diagnostics): Guidelines for Diagnostics. 55089 (line 39) 55090* signed division: Arithmetic. (line 116) 55091* signed division with signed saturation: Arithmetic. (line 116) 55092* signed maximum: Arithmetic. (line 141) 55093* signed minimum: Arithmetic. (line 141) 55094* significandM2 instruction pattern: Standard Names. (line 1047) 55095* sign_extend: Conversions. (line 23) 55096* sign_extract: Bit-Fields. (line 8) 55097* sign_extract, canonicalization of: Insn Canonicalizations. 55098 (line 103) 55099* SIG_ATOMIC_TYPE: Type Layout. (line 208) 55100* SImode: Machine Modes. (line 37) 55101* simple constraints: Simple Constraints. (line 6) 55102* simple_return: Side Effects. (line 86) 55103* simple_return instruction pattern: Standard Names. (line 1777) 55104* sincosM3 instruction pattern: Standard Names. (line 943) 55105* sinM2 instruction pattern: Standard Names. (line 937) 55106* SIZETYPE: Type Layout. (line 147) 55107* SIZE_ASM_OP: Label Output. (line 33) 55108* SIZE_TYPE: Type Layout. (line 131) 55109* skip: GTY Options. (line 76) 55110* SLOW_BYTE_ACCESS: Costs. (line 117) 55111* small IPA passes: Small IPA passes. (line 6) 55112* smax: Arithmetic. (line 141) 55113* smin: Arithmetic. (line 141) 55114* sms, swing, software pipelining: RTL passes. (line 123) 55115* smulhrsM3 instruction pattern: Standard Names. (line 604) 55116* smulhsM3 instruction pattern: Standard Names. (line 594) 55117* smulM3_highpart instruction pattern: Standard Names. (line 753) 55118* soft float library: Soft float library routines. 55119 (line 6) 55120* source code, location information: Guidelines for Diagnostics. 55121 (line 159) 55122* special: GTY Options. (line 238) 55123* special predicates: Predicates. (line 31) 55124* SPECS: Target Fragment. (line 194) 55125* speculation_barrier instruction pattern: Standard Names. (line 2178) 55126* speed of instructions: Costs. (line 6) 55127* splitting instructions: Insn Splitting. (line 6) 55128* split_block: Maintaining the CFG. 55129 (line 96) 55130* SQmode: Machine Modes. (line 114) 55131* sqrt: Arithmetic. (line 206) 55132* sqrtM2 instruction pattern: Standard Names. (line 882) 55133* square root: Arithmetic. (line 206) 55134* SSA: SSA. (line 6) 55135* ssaddM3 instruction pattern: Standard Names. (line 442) 55136* ssadM instruction pattern: Standard Names. (line 578) 55137* ssashlM3 instruction pattern: Standard Names. (line 828) 55138* SSA_NAME_DEF_STMT: SSA. (line 184) 55139* SSA_NAME_VERSION: SSA. (line 189) 55140* ssdivM3 instruction pattern: Standard Names. (line 442) 55141* ssmaddMN4 instruction pattern: Standard Names. (line 776) 55142* ssmsubMN4 instruction pattern: Standard Names. (line 800) 55143* ssmulM3 instruction pattern: Standard Names. (line 442) 55144* ssnegM2 instruction pattern: Standard Names. (line 872) 55145* sssubM3 instruction pattern: Standard Names. (line 442) 55146* ss_abs: Arithmetic. (line 200) 55147* ss_ashift: Arithmetic. (line 173) 55148* ss_div: Arithmetic. (line 116) 55149* ss_minus: Arithmetic. (line 38) 55150* ss_mult: Arithmetic. (line 93) 55151* ss_neg: Arithmetic. (line 82) 55152* ss_plus: Arithmetic. (line 14) 55153* ss_truncate: Conversions. (line 43) 55154* stack arguments: Stack Arguments. (line 6) 55155* stack frame layout: Frame Layout. (line 6) 55156* stack smashing protection: Stack Smashing Protection. 55157 (line 6) 55158* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 41) 55159* STACK_BOUNDARY: Storage Layout. (line 156) 55160* STACK_CHECK_BUILTIN: Stack Checking. (line 31) 55161* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83) 55162* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74) 55163* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90) 55164* STACK_CHECK_MOVING_SP: Stack Checking. (line 53) 55165* STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 45) 55166* STACK_CHECK_PROTECT: Stack Checking. (line 62) 55167* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 38) 55168* STACK_DYNAMIC_OFFSET: Frame Layout. (line 67) 55169* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 55170 (line 83) 55171* STACK_GROWS_DOWNWARD: Frame Layout. (line 8) 55172* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 89) 55173* STACK_POINTER_OFFSET: Frame Layout. (line 51) 55174* STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 55175 (line 93) 55176* STACK_POINTER_REGNUM: Frame Registers. (line 8) 55177* STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 55178 (line 83) 55179* stack_pointer_rtx: Frame Registers. (line 104) 55180* stack_protect_combined_set instruction pattern: Standard Names. 55181 (line 2487) 55182* stack_protect_combined_test instruction pattern: Standard Names. 55183 (line 2517) 55184* stack_protect_set instruction pattern: Standard Names. (line 2503) 55185* stack_protect_test instruction pattern: Standard Names. (line 2534) 55186* STACK_PUSH_CODE: Frame Layout. (line 12) 55187* STACK_REGS: Stack Registers. (line 19) 55188* STACK_REG_COVER_CLASS: Stack Registers. (line 22) 55189* STACK_SAVEAREA_MODE: Storage Layout. (line 473) 55190* STACK_SIZE_MODE: Storage Layout. (line 484) 55191* STACK_SLOT_ALIGNMENT: Storage Layout. (line 305) 55192* standard pattern names: Standard Names. (line 6) 55193* STANDARD_STARTFILE_PREFIX: Driver. (line 278) 55194* STANDARD_STARTFILE_PREFIX_1: Driver. (line 285) 55195* STANDARD_STARTFILE_PREFIX_2: Driver. (line 292) 55196* STARTFILE_SPEC: Driver. (line 147) 55197* Statement and operand traversals: Statement and operand traversals. 55198 (line 6) 55199* Statement Sequences: Statement Sequences. 55200 (line 6) 55201* Statements: Statements. (line 6) 55202* statements: Function Properties. 55203 (line 6) 55204* statements <1>: Statements for C++. (line 6) 55205* static analysis: Static Analyzer. (line 6) 55206* static analyzer: Static Analyzer. (line 6) 55207* static analyzer, debugging: Debugging the Analyzer. 55208 (line 5) 55209* static analyzer, internals: Analyzer Internals. (line 5) 55210* Static profile estimation: Profile information. 55211 (line 24) 55212* static single assignment: SSA. (line 6) 55213* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 77) 55214* STATIC_CHAIN_REGNUM: Frame Registers. (line 76) 55215* stdarg.h and register arguments: Register Arguments. (line 44) 55216* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 384) 55217* STMT_EXPR: Unary and Binary Expressions. 55218 (line 6) 55219* STMT_IS_FULL_EXPR_P: Statements for C++. (line 22) 55220* storage layout: Storage Layout. (line 6) 55221* STORE_FLAG_VALUE: Misc. (line 235) 55222* STORE_MAX_PIECES: Costs. (line 215) 55223* store_multiple instruction pattern: Standard Names. (line 159) 55224* strcpy: Storage Layout. (line 258) 55225* STRICT_ALIGNMENT: Storage Layout. (line 355) 55226* strict_low_part: RTL Declarations. (line 9) 55227* strict_memory_address_p: Addressing Modes. (line 186) 55228* STRING_CST: Constant expressions. 55229 (line 6) 55230* STRING_POOL_ADDRESS_P: Flags. (line 179) 55231* strlenM instruction pattern: Standard Names. (line 1399) 55232* structure value address: Aggregate Return. (line 6) 55233* structures, returning: Interface. (line 10) 55234* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 347) 55235* subM3 instruction pattern: Standard Names. (line 442) 55236* SUBOBJECT: Statements for C++. (line 6) 55237* SUBOBJECT_CLEANUP: Statements for C++. (line 6) 55238* subreg: Regs and Memory. (line 97) 55239* subreg and /s: Flags. (line 201) 55240* subreg and /u: Flags. (line 194) 55241* subreg and /u and /v: Flags. (line 184) 55242* subreg, in strict_low_part: RTL Declarations. (line 9) 55243* SUBREG_BYTE: Regs and Memory. (line 311) 55244* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 184) 55245* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 194) 55246* SUBREG_PROMOTED_VAR_P: Flags. (line 201) 55247* SUBREG_REG: Regs and Memory. (line 311) 55248* subst iterators in .md files: Subst Iterators. (line 6) 55249* subvM4 instruction pattern: Standard Names. (line 458) 55250* SUCCESS_EXIT_CODE: Host Misc. (line 12) 55251* support for nested functions: Trampolines. (line 6) 55252* SUPPORTS_INIT_PRIORITY: Macros for Initialization. 55253 (line 57) 55254* SUPPORTS_ONE_ONLY: Label Output. (line 290) 55255* SUPPORTS_WEAK: Label Output. (line 264) 55256* SWITCHABLE_TARGET: Run-time Target. (line 160) 55257* SWITCH_BODY: Statements for C++. (line 6) 55258* SWITCH_COND: Statements for C++. (line 6) 55259* SWITCH_STMT: Statements for C++. (line 6) 55260* symbolic label: Sharing. (line 20) 55261* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 117) 55262* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 99) 55263* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 92) 55264* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 113) 55265* SYMBOL_FLAG_LOCAL: Special Accessors. (line 95) 55266* SYMBOL_FLAG_SMALL: Special Accessors. (line 104) 55267* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 108) 55268* symbol_ref: Constants. (line 189) 55269* symbol_ref and /f: Flags. (line 179) 55270* symbol_ref and /i: Flags. (line 216) 55271* symbol_ref and /u: Flags. (line 19) 55272* symbol_ref and /v: Flags. (line 220) 55273* symbol_ref, RTL sharing: Sharing. (line 20) 55274* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 117) 55275* SYMBOL_REF_BLOCK: Special Accessors. (line 130) 55276* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 135) 55277* SYMBOL_REF_CONSTANT: Special Accessors. (line 78) 55278* SYMBOL_REF_DATA: Special Accessors. (line 82) 55279* SYMBOL_REF_DECL: Special Accessors. (line 67) 55280* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 99) 55281* SYMBOL_REF_FLAG: Flags. (line 220) 55282* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 289) 55283* SYMBOL_REF_FLAGS: Special Accessors. (line 86) 55284* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 92) 55285* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 113) 55286* SYMBOL_REF_LOCAL_P: Special Accessors. (line 95) 55287* SYMBOL_REF_SMALL_P: Special Accessors. (line 104) 55288* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 108) 55289* SYMBOL_REF_USED: Flags. (line 211) 55290* SYMBOL_REF_WEAK: Flags. (line 216) 55291* sync_addMODE instruction pattern: Standard Names. (line 2232) 55292* sync_andMODE instruction pattern: Standard Names. (line 2232) 55293* sync_compare_and_swapMODE instruction pattern: Standard Names. 55294 (line 2192) 55295* sync_iorMODE instruction pattern: Standard Names. (line 2232) 55296* sync_lock_releaseMODE instruction pattern: Standard Names. (line 2297) 55297* sync_lock_test_and_setMODE instruction pattern: Standard Names. 55298 (line 2271) 55299* sync_nandMODE instruction pattern: Standard Names. (line 2232) 55300* sync_new_addMODE instruction pattern: Standard Names. (line 2264) 55301* sync_new_andMODE instruction pattern: Standard Names. (line 2264) 55302* sync_new_iorMODE instruction pattern: Standard Names. (line 2264) 55303* sync_new_nandMODE instruction pattern: Standard Names. (line 2264) 55304* sync_new_subMODE instruction pattern: Standard Names. (line 2264) 55305* sync_new_xorMODE instruction pattern: Standard Names. (line 2264) 55306* sync_old_addMODE instruction pattern: Standard Names. (line 2247) 55307* sync_old_andMODE instruction pattern: Standard Names. (line 2247) 55308* sync_old_iorMODE instruction pattern: Standard Names. (line 2247) 55309* sync_old_nandMODE instruction pattern: Standard Names. (line 2247) 55310* sync_old_subMODE instruction pattern: Standard Names. (line 2247) 55311* sync_old_xorMODE instruction pattern: Standard Names. (line 2247) 55312* sync_subMODE instruction pattern: Standard Names. (line 2232) 55313* sync_xorMODE instruction pattern: Standard Names. (line 2232) 55314* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 176) 55315* SYSROOT_SUFFIX_SPEC: Driver. (line 171) 55316* SYSTEM_IMPLICIT_EXTERN_C: Misc. (line 415) 55317* t-TARGET: Target Fragment. (line 6) 55318* table jump: Basic Blocks. (line 67) 55319* tablejump instruction pattern: Standard Names. (line 1850) 55320* tag: GTY Options. (line 90) 55321* tagging insns: Tagging Insns. (line 6) 55322* tail calls: Tail Calls. (line 6) 55323* TAmode: Machine Modes. (line 158) 55324* tanM2 instruction pattern: Standard Names. (line 954) 55325* target attributes: Target Attributes. (line 6) 55326* target description macros: Target Macros. (line 6) 55327* target functions: Target Structure. (line 6) 55328* target hooks: Target Structure. (line 6) 55329* target makefile fragment: Target Fragment. (line 6) 55330* target specifications: Run-time Target. (line 6) 55331* targetm: Target Structure. (line 6) 55332* targets, makefile: Makefile. (line 6) 55333* TARGET_ABSOLUTE_BIGGEST_ALIGNMENT: Storage Layout. (line 185) 55334* TARGET_ADDITIONAL_ALLOCNO_CLASS_P: Register Classes. (line 639) 55335* TARGET_ADDRESS_COST: Costs. (line 344) 55336* TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 55337 (line 42) 55338* TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 55339 (line 89) 55340* TARGET_ADDR_SPACE_DEBUG: Named Address Spaces. 55341 (line 99) 55342* TARGET_ADDR_SPACE_DIAGNOSE_USAGE: Named Address Spaces. 55343 (line 103) 55344* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 55345 (line 59) 55346* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 55347 (line 67) 55348* TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 55349 (line 36) 55350* TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 55351 (line 74) 55352* TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 55353 (line 48) 55354* TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID: Named Address Spaces. 55355 (line 83) 55356* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 432) 55357* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 807) 55358* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 1064) 55359* TARGET_ALWAYS_STRIP_DOTDOT: Driver. (line 250) 55360* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 92) 55361* TARGET_ARM_EABI_UNWINDER: Exception Region Output. 55362 (line 133) 55363* TARGET_ARRAY_MODE: Register Arguments. (line 373) 55364* TARGET_ARRAY_MODE_SUPPORTED_P: Register Arguments. (line 388) 55365* TARGET_ASAN_SHADOW_OFFSET: Misc. (line 1092) 55366* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 11) 55367* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 7) 55368* TARGET_ASM_ALIGNED_PDI_OP: Data Output. (line 10) 55369* TARGET_ASM_ALIGNED_PSI_OP: Data Output. (line 8) 55370* TARGET_ASM_ALIGNED_PTI_OP: Data Output. (line 12) 55371* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9) 55372* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 13) 55373* TARGET_ASM_ASSEMBLE_UNDEFINED_DECL: Label Output. (line 231) 55374* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 301) 55375* TARGET_ASM_BYTE_OP: Data Output. (line 6) 55376* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 209) 55377* TARGET_ASM_CLOSE_PAREN: Data Output. (line 139) 55378* TARGET_ASM_CODE_END: File Framework. (line 57) 55379* TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 55380 (line 68) 55381* TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 177) 55382* TARGET_ASM_DECL_END: Data Output. (line 44) 55383* TARGET_ASM_DESTRUCTOR: Macros for Initialization. 55384 (line 82) 55385* TARGET_ASM_ELF_FLAGS_NUMERIC: File Framework. (line 120) 55386* TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 89) 55387* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 82) 55388* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 70) 55389* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 337) 55390* TARGET_ASM_FILE_END: File Framework. (line 35) 55391* TARGET_ASM_FILE_START: File Framework. (line 8) 55392* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 16) 55393* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 29) 55394* TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 82) 55395* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 67) 55396* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 61) 55397* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 73) 55398* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 18) 55399* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 225) 55400* TARGET_ASM_FUNCTION_SECTION: File Framework. (line 132) 55401* TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework. 55402 (line 142) 55403* TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC: Sections. (line 184) 55404* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 222) 55405* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 213) 55406* TARGET_ASM_INIT_SECTIONS: Sections. (line 164) 55407* TARGET_ASM_INTEGER: Data Output. (line 31) 55408* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 380) 55409* TARGET_ASM_LTO_END: File Framework. (line 52) 55410* TARGET_ASM_LTO_START: File Framework. (line 47) 55411* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 343) 55412* TARGET_ASM_MERGEABLE_RODATA_PREFIX: Sections. (line 233) 55413* TARGET_ASM_NAMED_SECTION: File Framework. (line 112) 55414* TARGET_ASM_OPEN_PAREN: Data Output. (line 138) 55415* TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 48) 55416* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 42) 55417* TARGET_ASM_OUTPUT_DWARF_DTPREL: DWARF. (line 121) 55418* TARGET_ASM_OUTPUT_IDENT: File Framework. (line 99) 55419* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 167) 55420* TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 91) 55421* TARGET_ASM_POST_CFI_STARTPROC: Dispatch Tables. (line 61) 55422* TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY: Function Entry. (line 9) 55423* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 173) 55424* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 218) 55425* TARGET_ASM_RELOC_RW_MASK: Sections. (line 173) 55426* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 242) 55427* TARGET_ASM_SELECT_SECTION: Sections. (line 191) 55428* TARGET_ASM_SHOULD_RESTORE_CFA_STATE: Dispatch Tables. (line 107) 55429* TARGET_ASM_TM_CLONE_TABLE_SECTION: Sections. (line 238) 55430* TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 81) 55431* TARGET_ASM_TTYPE: Exception Region Output. 55432 (line 127) 55433* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 18) 55434* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 14) 55435* TARGET_ASM_UNALIGNED_PDI_OP: Data Output. (line 17) 55436* TARGET_ASM_UNALIGNED_PSI_OP: Data Output. (line 15) 55437* TARGET_ASM_UNALIGNED_PTI_OP: Data Output. (line 19) 55438* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 16) 55439* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 20) 55440* TARGET_ASM_UNIQUE_SECTION: Sections. (line 213) 55441* TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 96) 55442* TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 102) 55443* TARGET_ATOMIC_ALIGN_FOR_MODE: Misc. (line 1111) 55444* TARGET_ATOMIC_ASSIGN_EXPAND_FENV: Misc. (line 1117) 55445* TARGET_ATOMIC_TEST_AND_SET_TRUEVAL: Misc. (line 1102) 55446* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 10) 55447* TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 17) 55448* TARGET_BINDS_LOCAL_P: Sections. (line 320) 55449* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 281) 55450* TARGET_BUILTIN_DECL: Misc. (line 637) 55451* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 261) 55452* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 101) 55453* TARGET_CALLEE_COPIES: Register Arguments. (line 124) 55454* TARGET_CALL_ARGS: Varargs. (line 123) 55455* TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS: Miscellaneous Register Hooks. 55456 (line 6) 55457* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 234) 55458* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 871) 55459* TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P: Register Classes. (line 610) 55460* TARGET_CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 55461 (line 55) 55462* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 302) 55463* TARGET_CAN_CHANGE_MODE_CLASS: Register Classes. (line 543) 55464* TARGET_CAN_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 55465 (line 294) 55466* TARGET_CAN_ELIMINATE: Elimination. (line 58) 55467* TARGET_CAN_FOLLOW_JUMP: Misc. (line 793) 55468* TARGET_CAN_INLINE_P: Target Attributes. (line 173) 55469* TARGET_CAN_USE_DOLOOP_P: Misc. (line 757) 55470* TARGET_CASE_VALUES_THRESHOLD: Misc. (line 46) 55471* TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 55472 (line 120) 55473* TARGET_CHECK_BUILTIN_CALL: Misc. (line 669) 55474* TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 26) 55475* TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 119) 55476* TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 499) 55477* TARGET_CLASS_MAX_NREGS: Register Classes. (line 515) 55478* TARGET_COMMUTATIVE_P: Misc. (line 800) 55479* TARGET_COMPARE_BY_PIECES_BRANCH_RATIO: Costs. (line 200) 55480* TARGET_COMPARE_VERSION_PRIORITY: Misc. (line 701) 55481* TARGET_COMPATIBLE_VECTOR_TYPES_P: Register Arguments. (line 350) 55482* TARGET_COMPUTE_FRAME_LAYOUT: Elimination. (line 74) 55483* TARGET_COMPUTE_PRESSURE_CLASSES: Register Classes. (line 655) 55484* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 25) 55485* TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 102) 55486* TARGET_CONSTANT_ALIGNMENT: Storage Layout. (line 271) 55487* TARGET_CONST_ANCHOR: Misc. (line 1075) 55488* TARGET_CONST_NOT_OK_FOR_DEBUG_P: Addressing Modes. (line 230) 55489* TARGET_CONVERT_TO_TYPE: Misc. (line 1022) 55490* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 8) 55491* TARGET_CSTORE_MODE: Register Classes. (line 647) 55492* TARGET_CUSTOM_FUNCTION_DESCRIPTORS: Trampolines. (line 39) 55493* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 86) 55494* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 37) 55495* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 61) 55496* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 24) 55497* TARGET_CXX_DECL_MANGLING_CONTEXT: C++ ABI. (line 92) 55498* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 52) 55499* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 17) 55500* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 11) 55501* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 6) 55502* TARGET_CXX_IMPLICIT_EXTERN_C: Misc. (line 407) 55503* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 28) 55504* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 42) 55505* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 68) 55506* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 73) 55507* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 79) 55508* TARGET_C_EXCESS_PRECISION: Storage Layout. (line 109) 55509* TARGET_C_PREINCLUDE: Misc. (line 395) 55510* TARGET_DEBUG_UNWIND_INFO: DWARF. (line 32) 55511* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 537) 55512* TARGET_DECLSPEC: Target Attributes. (line 72) 55513* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 479) 55514* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 123) 55515* TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 55) 55516* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 465) 55517* TARGET_DELAY_SCHED2: DWARF. (line 77) 55518* TARGET_DELAY_VARTRACK: DWARF. (line 81) 55519* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 221) 55520* TARGET_DIFFERENT_ADDR_DISPLACEMENT_P: Register Classes. (line 603) 55521* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55) 55522* TARGET_DOLOOP_COST_FOR_ADDRESS: Misc. (line 746) 55523* TARGET_DOLOOP_COST_FOR_GENERIC: Misc. (line 735) 55524* TARGET_DWARF_CALLING_CONVENTION: DWARF. (line 12) 55525* TARGET_DWARF_FRAME_REG_MODE: Exception Region Output. 55526 (line 113) 55527* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 165) 55528* TARGET_DWARF_POLY_INDETERMINATE_VALUE: Frame Layout. (line 177) 55529* TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 55530 (line 104) 55531* TARGET_D_CPU_VERSIONS: D Language and ABI. (line 6) 55532* TARGET_D_CRITSEC_SIZE: D Language and ABI. (line 17) 55533* TARGET_D_OS_VERSIONS: D Language and ABI. (line 13) 55534* TARGET_EDOM: Library Calls. (line 59) 55535* TARGET_EMPTY_RECORD_P: Aggregate Return. (line 86) 55536* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 67) 55537* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 18) 55538* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 23) 55539* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 44) 55540* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 35) 55541* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 62) 55542* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 48) 55543* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 55) 55544* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 40) 55545* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 30) 55546* TARGET_ENCODE_SECTION_INFO: Sections. (line 263) 55547* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 55548 (line 82) 55549* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 127) 55550* TARGET_END_CALL_ARGS: Varargs. (line 137) 55551* TARGET_ENUM_VA_LIST_P: Register Arguments. (line 285) 55552* TARGET_ESTIMATED_POLY_VALUE: Costs. (line 425) 55553* TARGET_EXCEPT_UNWIND_INFO: Exception Region Output. 55554 (line 46) 55555* TARGET_EXECUTABLE_SUFFIX: Misc. (line 858) 55556* TARGET_EXPAND_BUILTIN: Misc. (line 647) 55557* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 64) 55558* TARGET_EXPAND_DIVMOD_LIBFUNC: Scheduling. (line 461) 55559* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 543) 55560* TARGET_EXPR: Unary and Binary Expressions. 55561 (line 6) 55562* TARGET_EXTRA_INCLUDES: Misc. (line 937) 55563* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 20) 55564* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 944) 55565* TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 55566 (line 105) 55567* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 540) 55568* target_flags: Run-time Target. (line 51) 55569* TARGET_FLAGS_REGNUM: MODE_CC Condition Codes. 55570 (line 133) 55571* TARGET_FLOATN_BUILTIN_P: Register Arguments. (line 438) 55572* TARGET_FLOATN_MODE: Register Arguments. (line 420) 55573* TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P: Run-time Target. 55574 (line 179) 55575* TARGET_FNTYPE_ABI: Register Basics. (line 58) 55576* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 297) 55577* TARGET_FOLD_BUILTIN: Misc. (line 684) 55578* TARGET_FORMAT_TYPES: Misc. (line 965) 55579* TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 8) 55580* TARGET_FUNCTION_ARG: Register Arguments. (line 10) 55581* TARGET_FUNCTION_ARG_ADVANCE: Register Arguments. (line 195) 55582* TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 248) 55583* TARGET_FUNCTION_ARG_OFFSET: Register Arguments. (line 206) 55584* TARGET_FUNCTION_ARG_PADDING: Register Arguments. (line 214) 55585* TARGET_FUNCTION_ARG_ROUND_BOUNDARY: Register Arguments. (line 254) 55586* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 101) 55587* TARGET_FUNCTION_INCOMING_ARG: Register Arguments. (line 64) 55588* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 6) 55589* TARGET_FUNCTION_VALUE: Scalar Return. (line 9) 55590* TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 96) 55591* TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc. (line 717) 55592* TARGET_GEN_CCMP_FIRST: Misc. (line 890) 55593* TARGET_GEN_CCMP_NEXT: Misc. (line 901) 55594* TARGET_GET_DRAP_RTX: Misc. (line 1058) 55595* TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc. (line 710) 55596* TARGET_GET_MULTILIB_ABI_NAME: Register Basics. (line 99) 55597* TARGET_GET_PCH_VALIDITY: PCH Target. (line 6) 55598* TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 81) 55599* TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 76) 55600* TARGET_GET_VALID_OPTION_VALUES: Stack Smashing Protection. 55601 (line 39) 55602* TARGET_GIMPLE_FOLD_BUILTIN: Misc. (line 694) 55603* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 307) 55604* TARGET_GOACC_DIM_LIMIT: Addressing Modes. (line 540) 55605* TARGET_GOACC_FORK_JOIN: Addressing Modes. (line 544) 55606* TARGET_GOACC_REDUCTION: Addressing Modes. (line 555) 55607* TARGET_GOACC_VALIDATE_DIMS: Addressing Modes. (line 527) 55608* TARGET_HANDLE_C_OPTION: Run-time Target. (line 73) 55609* TARGET_HANDLE_GENERIC_ATTRIBUTE: Target Attributes. (line 93) 55610* TARGET_HANDLE_OPTION: Run-time Target. (line 59) 55611* TARGET_HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 76) 55612* TARGET_HARD_REGNO_MODE_OK: Values in Registers. 55613 (line 54) 55614* TARGET_HARD_REGNO_NREGS: Values in Registers. 55615 (line 10) 55616* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 55617 (line 139) 55618* TARGET_HAS_IFUNC_P: Misc. (line 1106) 55619* TARGET_HAS_NO_HW_DIVIDE: Library Calls. (line 52) 55620* TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 884) 55621* TARGET_HAVE_COUNT_REG_DECR_P: Misc. (line 731) 55622* TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 55623 (line 63) 55624* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 150) 55625* TARGET_HAVE_SPECULATION_SAFE_VALUE: Misc. (line 1189) 55626* TARGET_HAVE_SRODATA_SECTION: Sections. (line 309) 55627* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 155) 55628* TARGET_HAVE_TLS: Sections. (line 329) 55629* TARGET_INIT_BUILTINS: Misc. (line 621) 55630* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 55631 (line 119) 55632* TARGET_INIT_LIBFUNCS: Library Calls. (line 15) 55633* TARGET_INIT_PIC_REG: Register Arguments. (line 88) 55634* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 80) 55635* TARGET_INSN_CALLEE_ABI: Register Basics. (line 65) 55636* TARGET_INSN_COST: Costs. (line 380) 55637* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 551) 55638* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 989) 55639* TARGET_INVALID_BINARY_OP: Misc. (line 1008) 55640* TARGET_INVALID_CONVERSION: Misc. (line 995) 55641* TARGET_INVALID_UNARY_OP: Misc. (line 1001) 55642* TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 774) 55643* TARGET_IN_SMALL_DATA_P: Sections. (line 305) 55644* TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: Register Classes. (line 570) 55645* TARGET_KEEP_LEAF_WHEN_PROFILED: Profiling. (line 39) 55646* TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 48) 55647* TARGET_LEGITIMATE_COMBINED_INSN: Misc. (line 788) 55648* TARGET_LEGITIMATE_CONSTANT_P: Addressing Modes. (line 213) 55649* TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 129) 55650* TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: Register Classes. (line 618) 55651* TARGET_LIBCALL_VALUE: Scalar Return. (line 65) 55652* TARGET_LIBC_HAS_FAST_FUNCTION: Library Calls. (line 82) 55653* TARGET_LIBC_HAS_FUNCTION: Library Calls. (line 77) 55654* TARGET_LIBFUNC_GNU_PREFIX: Library Calls. (line 24) 55655* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 493) 55656* TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P: Register Arguments. 55657 (line 412) 55658* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 136) 55659* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 499) 55660* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 42) 55661* TARGET_LOAD_BOUNDS_FOR_ARG: Varargs. (line 153) 55662* TARGET_LOAD_RETURNED_BOUNDS: Varargs. (line 172) 55663* TARGET_LOOP_UNROLL_ADJUST: Misc. (line 918) 55664* TARGET_LRA_P: Register Classes. (line 577) 55665* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 606) 55666* TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 356) 55667* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 253) 55668* TARGET_MANGLE_TYPE: Storage Layout. (line 555) 55669* TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 38) 55670* TARGET_MAX_NOCE_IFCVT_SEQ_COST: Costs. (line 390) 55671* TARGET_MD_ASM_ADJUST: Misc. (line 524) 55672* TARGET_MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 445) 55673* TARGET_MEMMODEL_CHECK: Misc. (line 1097) 55674* TARGET_MEMORY_MOVE_COST: Costs. (line 79) 55675* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 107) 55676* TARGET_MEM_REF: Storage References. (line 6) 55677* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 45) 55678* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 37) 55679* TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 32) 55680* TARGET_MIN_ARITHMETIC_PRECISION: Misc. (line 63) 55681* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 112) 55682* TARGET_MODES_TIEABLE_P: Values in Registers. 55683 (line 123) 55684* TARGET_MODE_AFTER: Mode Switching. (line 57) 55685* TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 196) 55686* TARGET_MODE_EMIT: Mode Switching. (line 42) 55687* TARGET_MODE_ENTRY: Mode Switching. (line 64) 55688* TARGET_MODE_EXIT: Mode Switching. (line 71) 55689* TARGET_MODE_NEEDED: Mode Switching. (line 50) 55690* TARGET_MODE_PRIORITY: Mode Switching. (line 78) 55691* TARGET_MODE_REP_EXTENDED: Misc. (line 197) 55692* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 509) 55693* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 57) 55694* TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments. 55695 (line 49) 55696* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 438) 55697* TARGET_NOCE_CONVERSION_PROFITABLE_P: Costs. (line 409) 55698* TARGET_NO_REGISTER_ALLOCATION: DWARF. (line 85) 55699* TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P: Costs. (line 415) 55700* TARGET_N_FORMAT_TYPES: Misc. (line 970) 55701* TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 88) 55702* TARGET_OBJC_DECLARE_CLASS_DEFINITION: Run-time Target. (line 109) 55703* TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target. 55704 (line 104) 55705* TARGET_OBJECT_SUFFIX: Misc. (line 853) 55706* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 45) 55707* TARGET_OFFLOAD_OPTIONS: Misc. (line 1140) 55708* TARGET_OMIT_STRUCT_RETURN_REG: Scalar Return. (line 117) 55709* TARGET_OMP_DEVICE_KIND_ARCH_ISA: Addressing Modes. (line 519) 55710* TARGET_OPTAB_SUPPORTED_P: Costs. (line 299) 55711* TARGET_OPTF: Misc. (line 952) 55712* TARGET_OPTION_FUNCTION_VERSIONS: Target Attributes. (line 165) 55713* TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 156) 55714* TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 142) 55715* TARGET_OPTION_OVERRIDE: Target Attributes. (line 152) 55716* TARGET_OPTION_POST_STREAM_IN: Target Attributes. (line 133) 55717* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 145) 55718* TARGET_OPTION_PRINT: Target Attributes. (line 139) 55719* TARGET_OPTION_RESTORE: Target Attributes. (line 127) 55720* TARGET_OPTION_SAVE: Target Attributes. (line 120) 55721* TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 108) 55722* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 41) 55723* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 974) 55724* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 980) 55725* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 984) 55726* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 126) 55727* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 112) 55728* TARGET_PCH_VALID_P: PCH Target. (line 11) 55729* TARGET_POSIX_IO: Misc. (line 550) 55730* TARGET_PREDICT_DOLOOP_P: Misc. (line 724) 55731* TARGET_PREFERRED_ELSE_VALUE: Addressing Modes. (line 563) 55732* TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 284) 55733* TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 213) 55734* TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 201) 55735* TARGET_PREPARE_PCH_SAVE: PCH Target. (line 34) 55736* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 144) 55737* TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 313) 55738* TARGET_PROMOTED_TYPE: Misc. (line 1014) 55739* TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 126) 55740* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 10) 55741* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 250) 55742* TARGET_RECORD_OFFLOAD_SYMBOL: Misc. (line 1135) 55743* TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 318) 55744* TARGET_REGISTER_MOVE_COST: Costs. (line 31) 55745* TARGET_REGISTER_PRIORITY: Register Classes. (line 582) 55746* TARGET_REGISTER_USAGE_LEVELING_P: Register Classes. (line 593) 55747* TARGET_RELAYOUT_FUNCTION: Target Attributes. (line 180) 55748* TARGET_RESET_LOCATION_VIEW: DWARF. (line 57) 55749* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 658) 55750* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 15) 55751* TARGET_RETURN_IN_MSB: Scalar Return. (line 124) 55752* TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 98) 55753* TARGET_RTX_COSTS: Costs. (line 313) 55754* TARGET_RUN_TARGET_SELFTESTS: Misc. (line 1226) 55755* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 334) 55756* TARGET_SCHED_ADJUST_COST: Scheduling. (line 35) 55757* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 50) 55758* TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 294) 55759* TARGET_SCHED_CAN_SPECULATE_INSN: Scheduling. (line 354) 55760* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 309) 55761* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 101) 55762* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 255) 55763* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 172) 55764* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 156) 55765* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 165) 55766* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 144) 55767* TARGET_SCHED_DISPATCH: Scheduling. (line 370) 55768* TARGET_SCHED_DISPATCH_DO: Scheduling. (line 375) 55769* TARGET_SCHED_EXPOSED_PIPELINE: Scheduling. (line 379) 55770* TARGET_SCHED_FINISH: Scheduling. (line 122) 55771* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 137) 55772* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 235) 55773* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 223) 55774* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 55775 (line 179) 55776* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 55777 (line 207) 55778* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 240) 55779* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 250) 55780* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 245) 55781* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 229) 55782* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 313) 55783* TARGET_SCHED_FUSION_PRIORITY: Scheduling. (line 389) 55784* TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 335) 55785* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 289) 55786* TARGET_SCHED_INIT: Scheduling. (line 111) 55787* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 161) 55788* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 153) 55789* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 129) 55790* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 298) 55791* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 11) 55792* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 267) 55793* TARGET_SCHED_MACRO_FUSION_P: Scheduling. (line 87) 55794* TARGET_SCHED_MACRO_FUSION_PAIR_P: Scheduling. (line 91) 55795* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 328) 55796* TARGET_SCHED_REASSOCIATION_WIDTH: Scheduling. (line 384) 55797* TARGET_SCHED_REORDER: Scheduling. (line 58) 55798* TARGET_SCHED_REORDER2: Scheduling. (line 75) 55799* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 305) 55800* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 347) 55801* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 361) 55802* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 316) 55803* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 22) 55804* TARGET_SECONDARY_MEMORY_NEEDED: Register Classes. (line 447) 55805* TARGET_SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 466) 55806* TARGET_SECONDARY_RELOAD: Register Classes. (line 312) 55807* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 160) 55808* TARGET_SELECT_EARLY_REMAT_MODES: Register Classes. (line 488) 55809* TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P: Misc. (line 223) 55810* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 71) 55811* TARGET_SET_CURRENT_FUNCTION: Misc. (line 835) 55812* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 33) 55813* TARGET_SET_UP_BY_PROLOGUE: Tail Calls. (line 29) 55814* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 160) 55815* TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB: Shrink-wrapping separate components. 55816 (line 36) 55817* TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS: Shrink-wrapping separate components. 55818 (line 43) 55819* TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS: Shrink-wrapping separate components. 55820 (line 54) 55821* TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS: Shrink-wrapping separate components. 55822 (line 50) 55823* TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS: Shrink-wrapping separate components. 55824 (line 27) 55825* TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS: Shrink-wrapping separate components. 55826 (line 58) 55827* TARGET_SIMD_CLONE_ADJUST: Addressing Modes. (line 506) 55828* TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN: Addressing Modes. 55829 (line 498) 55830* TARGET_SIMD_CLONE_USABLE: Addressing Modes. (line 510) 55831* TARGET_SIMT_VF: Addressing Modes. (line 516) 55832* TARGET_SLOW_UNALIGNED_ACCESS: Costs. (line 132) 55833* TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments. 55834 (line 448) 55835* TARGET_SPECULATION_SAFE_VALUE: Misc. (line 1208) 55836* TARGET_SPILL_CLASS: Register Classes. (line 632) 55837* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 269) 55838* TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE: Stack Checking. 55839 (line 97) 55840* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 55841 (line 16) 55842* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 55843 (line 6) 55844* TARGET_STACK_PROTECT_RUNTIME_ENABLED_P: Stack Smashing Protection. 55845 (line 25) 55846* TARGET_STARTING_FRAME_OFFSET: Frame Layout. (line 34) 55847* TARGET_STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 55848 (line 74) 55849* TARGET_STATIC_CHAIN: Frame Registers. (line 90) 55850* TARGET_STATIC_RTX_ALIGNMENT: Storage Layout. (line 243) 55851* TARGET_STORE_BOUNDS_FOR_ARG: Varargs. (line 163) 55852* TARGET_STORE_RETURNED_BOUNDS: Varargs. (line 177) 55853* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 107) 55854* TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 114) 55855* TARGET_STRIP_NAME_ENCODING: Sections. (line 300) 55856* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44) 55857* TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection. 55858 (line 30) 55859* TARGET_SUPPORTS_WEAK: Label Output. (line 272) 55860* TARGET_SUPPORTS_WIDE_INT: Misc. (line 1148) 55861* TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 55862 (line 98) 55863* TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 127) 55864* TARGET_TRAMPOLINE_INIT: Trampolines. (line 107) 55865* TARGET_TRANSLATE_MODE_ATTRIBUTE: Register Arguments. (line 325) 55866* TARGET_TRULY_NOOP_TRUNCATION: Misc. (line 184) 55867* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 826) 55868* TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 55869 (line 73) 55870* TARGET_UNWIND_WORD_MODE: Storage Layout. (line 505) 55871* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 1054) 55872* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 123) 55873* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 53) 55874* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 248) 55875* TARGET_USE_BLOCKS_FOR_DECL_P: Addressing Modes. (line 255) 55876* TARGET_USE_BY_PIECES_INFRASTRUCTURE_P: Costs. (line 165) 55877* TARGET_USE_PSEUDO_PIC_REG: Register Arguments. (line 84) 55878* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 66) 55879* TARGET_VALID_POINTER_MODE: Register Arguments. (line 313) 55880* TARGET_VECTORIZE_ADD_STMT_COST: Addressing Modes. (line 461) 55881* TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES: Addressing Modes. 55882 (line 376) 55883* TARGET_VECTORIZE_BUILTIN_GATHER: Addressing Modes. (line 484) 55884* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 266) 55885* TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION: Addressing Modes. 55886 (line 344) 55887* TARGET_VECTORIZE_BUILTIN_SCATTER: Addressing Modes. (line 491) 55888* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 55889 (line 292) 55890* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 55891 (line 336) 55892* TARGET_VECTORIZE_DESTROY_COST_DATA: Addressing Modes. (line 479) 55893* TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE: Addressing Modes. 55894 (line 445) 55895* TARGET_VECTORIZE_FINISH_COST: Addressing Modes. (line 472) 55896* TARGET_VECTORIZE_GET_MASK_MODE: Addressing Modes. (line 433) 55897* TARGET_VECTORIZE_INIT_COST: Addressing Modes. (line 452) 55898* TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 361) 55899* TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT: Addressing Modes. 55900 (line 298) 55901* TARGET_VECTORIZE_RELATED_MODE: Addressing Modes. (line 407) 55902* TARGET_VECTORIZE_SPLIT_REDUCTION: Addressing Modes. (line 368) 55903* TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. 55904 (line 351) 55905* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 55906 (line 310) 55907* TARGET_VECTORIZE_VEC_PERM_CONST: Addressing Modes. (line 316) 55908* TARGET_VECTOR_ALIGNMENT: Storage Layout. (line 298) 55909* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 345) 55910* TARGET_VERIFY_TYPE_CONTEXT: Misc. (line 1029) 55911* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 303) 55912* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 297) 55913* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 286) 55914* TARGET_WANT_DEBUG_PUB_SECTIONS: DWARF. (line 72) 55915* TARGET_WARN_FUNC_RETURN: Tail Calls. (line 35) 55916* TARGET_WARN_PARAMETER_PASSING_ABI: Aggregate Return. (line 90) 55917* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 308) 55918* TCmode: Machine Modes. (line 199) 55919* TDmode: Machine Modes. (line 97) 55920* TEMPLATE_DECL: Declarations. (line 6) 55921* Temporaries: Temporaries. (line 6) 55922* termination routines: Initialization. (line 6) 55923* testing constraints: C Constraint Interface. 55924 (line 6) 55925* TEXT_SECTION_ASM_OP: Sections. (line 37) 55926* TFmode: Machine Modes. (line 101) 55927* The Language: The Language. (line 6) 55928* THEN_CLAUSE: Statements for C++. (line 6) 55929* THREAD_MODEL_SPEC: Driver. (line 162) 55930* THROW_EXPR: Unary and Binary Expressions. 55931 (line 6) 55932* THUNK_DECL: Declarations. (line 6) 55933* THUNK_DELTA: Declarations. (line 6) 55934* TImode: Machine Modes. (line 48) 55935* TImode, in insn: Insns. (line 291) 55936* TLS_COMMON_ASM_OP: Sections. (line 80) 55937* TLS_SECTION_ASM_FLAG: Sections. (line 85) 55938* tm.h macros: Target Macros. (line 6) 55939* TQFmode: Machine Modes. (line 65) 55940* TQmode: Machine Modes. (line 122) 55941* trampolines for nested functions: Trampolines. (line 6) 55942* TRAMPOLINE_ALIGNMENT: Trampolines. (line 101) 55943* TRAMPOLINE_SECTION: Trampolines. (line 92) 55944* TRAMPOLINE_SIZE: Trampolines. (line 97) 55945* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 163) 55946* trap instruction pattern: Standard Names. (line 2121) 55947* tree: Tree overview. (line 6) 55948* tree <1>: Macros and Functions. 55949 (line 6) 55950* Tree SSA: Tree SSA. (line 6) 55951* TREE_CHAIN: Macros and Functions. 55952 (line 6) 55953* TREE_CODE: Tree overview. (line 6) 55954* tree_fits_shwi_p: Constant expressions. 55955 (line 6) 55956* tree_fits_uhwi_p: Constant expressions. 55957 (line 6) 55958* TREE_INT_CST_ELT: Constant expressions. 55959 (line 6) 55960* tree_int_cst_equal: Constant expressions. 55961 (line 6) 55962* TREE_INT_CST_LOW: Constant expressions. 55963 (line 6) 55964* tree_int_cst_lt: Constant expressions. 55965 (line 6) 55966* TREE_INT_CST_NUNITS: Constant expressions. 55967 (line 6) 55968* TREE_LIST: Containers. (line 6) 55969* TREE_OPERAND: Expression trees. (line 6) 55970* TREE_PUBLIC: Function Basics. (line 6) 55971* TREE_PUBLIC <1>: Function Properties. 55972 (line 28) 55973* TREE_PURPOSE: Containers. (line 6) 55974* TREE_READONLY: Function Properties. 55975 (line 37) 55976* tree_size: Macros and Functions. 55977 (line 13) 55978* TREE_STATIC: Function Properties. 55979 (line 31) 55980* TREE_STRING_LENGTH: Constant expressions. 55981 (line 6) 55982* TREE_STRING_POINTER: Constant expressions. 55983 (line 6) 55984* TREE_THIS_VOLATILE: Function Properties. 55985 (line 34) 55986* tree_to_shwi: Constant expressions. 55987 (line 6) 55988* tree_to_uhwi: Constant expressions. 55989 (line 6) 55990* TREE_TYPE: Macros and Functions. 55991 (line 6) 55992* TREE_TYPE <1>: Types. (line 6) 55993* TREE_TYPE <2>: Working with declarations. 55994 (line 11) 55995* TREE_TYPE <3>: Expression trees. (line 6) 55996* TREE_TYPE <4>: Expression trees. (line 17) 55997* TREE_TYPE <5>: Function Basics. (line 47) 55998* TREE_TYPE <6>: Types for C++. (line 6) 55999* TREE_VALUE: Containers. (line 6) 56000* TREE_VEC: Containers. (line 6) 56001* TREE_VEC_ELT: Containers. (line 6) 56002* TREE_VEC_LENGTH: Containers. (line 6) 56003* true positive: Guidelines for Diagnostics. 56004 (line 39) 56005* truncate: Conversions. (line 38) 56006* truncMN2 instruction pattern: Standard Names. (line 1442) 56007* TRUNC_DIV_EXPR: Unary and Binary Expressions. 56008 (line 6) 56009* TRUNC_MOD_EXPR: Unary and Binary Expressions. 56010 (line 6) 56011* TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 56012 (line 6) 56013* TRUTH_AND_EXPR: Unary and Binary Expressions. 56014 (line 6) 56015* TRUTH_NOT_EXPR: Unary and Binary Expressions. 56016 (line 6) 56017* TRUTH_ORIF_EXPR: Unary and Binary Expressions. 56018 (line 6) 56019* TRUTH_OR_EXPR: Unary and Binary Expressions. 56020 (line 6) 56021* TRUTH_XOR_EXPR: Unary and Binary Expressions. 56022 (line 6) 56023* TRY_BLOCK: Statements for C++. (line 6) 56024* TRY_HANDLERS: Statements for C++. (line 6) 56025* TRY_STMTS: Statements for C++. (line 6) 56026* Tuple specific accessors: Tuple specific accessors. 56027 (line 6) 56028* tuples: Tuple representation. 56029 (line 6) 56030* type: Types. (line 6) 56031* type declaration: Declarations. (line 6) 56032* TYPENAME_TYPE: Types for C++. (line 6) 56033* TYPENAME_TYPE_FULLNAME: Types. (line 6) 56034* TYPENAME_TYPE_FULLNAME <1>: Types for C++. (line 6) 56035* TYPEOF_TYPE: Types for C++. (line 6) 56036* TYPE_ALIGN: Types. (line 6) 56037* TYPE_ALIGN <1>: Types. (line 30) 56038* TYPE_ALIGN <2>: Types for C++. (line 6) 56039* TYPE_ALIGN <3>: Types for C++. (line 44) 56040* TYPE_ARG_TYPES: Types. (line 6) 56041* TYPE_ARG_TYPES <1>: Types for C++. (line 6) 56042* TYPE_ASM_OP: Label Output. (line 76) 56043* TYPE_ATTRIBUTES: Attributes. (line 24) 56044* TYPE_BINFO: Classes. (line 6) 56045* TYPE_BUILT_IN: Types for C++. (line 66) 56046* TYPE_CANONICAL: Types. (line 6) 56047* TYPE_CANONICAL <1>: Types. (line 41) 56048* TYPE_CONTEXT: Types. (line 6) 56049* TYPE_CONTEXT <1>: Types for C++. (line 6) 56050* TYPE_DECL: Declarations. (line 6) 56051* TYPE_FIELDS: Types. (line 6) 56052* TYPE_FIELDS <1>: Types for C++. (line 6) 56053* TYPE_FIELDS <2>: Classes. (line 6) 56054* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 93) 56055* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 78) 56056* TYPE_HAS_MUTABLE_P: Classes. (line 83) 56057* TYPE_HAS_NEW_OPERATOR: Classes. (line 90) 56058* TYPE_MAIN_VARIANT: Types. (line 6) 56059* TYPE_MAIN_VARIANT <1>: Types. (line 19) 56060* TYPE_MAIN_VARIANT <2>: Types for C++. (line 6) 56061* TYPE_MAX_VALUE: Types. (line 6) 56062* TYPE_METHOD_BASETYPE: Types. (line 6) 56063* TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 56064* TYPE_MIN_VALUE: Types. (line 6) 56065* TYPE_NAME: Types. (line 6) 56066* TYPE_NAME <1>: Types. (line 33) 56067* TYPE_NAME <2>: Types for C++. (line 6) 56068* TYPE_NAME <3>: Types for C++. (line 47) 56069* TYPE_NOTHROW_P: Functions for C++. (line 154) 56070* TYPE_OFFSET_BASETYPE: Types. (line 6) 56071* TYPE_OFFSET_BASETYPE <1>: Types for C++. (line 6) 56072* TYPE_OPERAND_FMT: Label Output. (line 87) 56073* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 101) 56074* TYPE_OVERLOADS_ARROW: Classes. (line 104) 56075* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 97) 56076* TYPE_POLYMORPHIC_P: Classes. (line 74) 56077* TYPE_PRECISION: Types. (line 6) 56078* TYPE_PRECISION <1>: Types for C++. (line 6) 56079* TYPE_PTRDATAMEM_P: Types for C++. (line 6) 56080* TYPE_PTRDATAMEM_P <1>: Types for C++. (line 69) 56081* TYPE_PTRFN_P: Types for C++. (line 76) 56082* TYPE_PTROBV_P: Types for C++. (line 6) 56083* TYPE_PTROB_P: Types for C++. (line 79) 56084* TYPE_PTR_P: Types for C++. (line 72) 56085* TYPE_QUAL_CONST: Types. (line 6) 56086* TYPE_QUAL_CONST <1>: Types for C++. (line 6) 56087* TYPE_QUAL_RESTRICT: Types. (line 6) 56088* TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 56089* TYPE_QUAL_VOLATILE: Types. (line 6) 56090* TYPE_QUAL_VOLATILE <1>: Types for C++. (line 6) 56091* TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 56092* TYPE_SIZE: Types. (line 6) 56093* TYPE_SIZE <1>: Types. (line 25) 56094* TYPE_SIZE <2>: Types for C++. (line 6) 56095* TYPE_SIZE <3>: Types for C++. (line 39) 56096* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 56097* TYPE_STRUCTURAL_EQUALITY_P <1>: Types. (line 77) 56098* TYPE_UNQUALIFIED: Types. (line 6) 56099* TYPE_UNQUALIFIED <1>: Types for C++. (line 6) 56100* TYPE_VFIELD: Classes. (line 6) 56101* uaddvM4 instruction pattern: Standard Names. (line 461) 56102* uavgM3_ceil instruction pattern: Standard Names. (line 860) 56103* uavgM3_floor instruction pattern: Standard Names. (line 848) 56104* UDAmode: Machine Modes. (line 170) 56105* udiv: Arithmetic. (line 130) 56106* udivM3 instruction pattern: Standard Names. (line 442) 56107* udivmodM4 instruction pattern: Standard Names. (line 825) 56108* udot_prodM instruction pattern: Standard Names. (line 570) 56109* UDQmode: Machine Modes. (line 138) 56110* UHAmode: Machine Modes. (line 162) 56111* UHQmode: Machine Modes. (line 130) 56112* UINT16_TYPE: Type Layout. (line 214) 56113* UINT32_TYPE: Type Layout. (line 215) 56114* UINT64_TYPE: Type Layout. (line 216) 56115* UINT8_TYPE: Type Layout. (line 213) 56116* UINTMAX_TYPE: Type Layout. (line 197) 56117* UINTPTR_TYPE: Type Layout. (line 234) 56118* UINT_FAST16_TYPE: Type Layout. (line 230) 56119* UINT_FAST32_TYPE: Type Layout. (line 231) 56120* UINT_FAST64_TYPE: Type Layout. (line 232) 56121* UINT_FAST8_TYPE: Type Layout. (line 229) 56122* UINT_LEAST16_TYPE: Type Layout. (line 222) 56123* UINT_LEAST32_TYPE: Type Layout. (line 223) 56124* UINT_LEAST64_TYPE: Type Layout. (line 224) 56125* UINT_LEAST8_TYPE: Type Layout. (line 221) 56126* umaddMN4 instruction pattern: Standard Names. (line 772) 56127* umax: Arithmetic. (line 149) 56128* umaxM3 instruction pattern: Standard Names. (line 442) 56129* umin: Arithmetic. (line 149) 56130* uminM3 instruction pattern: Standard Names. (line 442) 56131* umod: Arithmetic. (line 136) 56132* umodM3 instruction pattern: Standard Names. (line 442) 56133* umsubMN4 instruction pattern: Standard Names. (line 796) 56134* umulhisi3 instruction pattern: Standard Names. (line 744) 56135* umulhrsM3 instruction pattern: Standard Names. (line 605) 56136* umulhsM3 instruction pattern: Standard Names. (line 595) 56137* umulM3_highpart instruction pattern: Standard Names. (line 758) 56138* umulqihi3 instruction pattern: Standard Names. (line 744) 56139* umulsidi3 instruction pattern: Standard Names. (line 744) 56140* umulvM4 instruction pattern: Standard Names. (line 466) 56141* unchanging: Flags. (line 307) 56142* unchanging, in call_insn: Flags. (line 115) 56143* unchanging, in jump_insn, call_insn and insn: Flags. (line 28) 56144* unchanging, in mem: Flags. (line 78) 56145* unchanging, in subreg: Flags. (line 184) 56146* unchanging, in subreg <1>: Flags. (line 194) 56147* unchanging, in symbol_ref: Flags. (line 19) 56148* UNEQ_EXPR: Unary and Binary Expressions. 56149 (line 6) 56150* UNGE_EXPR: Unary and Binary Expressions. 56151 (line 6) 56152* UNGT_EXPR: Unary and Binary Expressions. 56153 (line 6) 56154* unions, returning: Interface. (line 10) 56155* UNION_TYPE: Types. (line 6) 56156* UNION_TYPE <1>: Classes. (line 6) 56157* UNITS_PER_WORD: Storage Layout. (line 60) 56158* UNKNOWN_TYPE: Types. (line 6) 56159* UNKNOWN_TYPE <1>: Types for C++. (line 6) 56160* UNLE_EXPR: Unary and Binary Expressions. 56161 (line 6) 56162* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 48) 56163* UNLT_EXPR: Unary and Binary Expressions. 56164 (line 6) 56165* UNORDERED_EXPR: Unary and Binary Expressions. 56166 (line 6) 56167* unshare_all_rtl: Sharing. (line 61) 56168* unsigned division: Arithmetic. (line 130) 56169* unsigned division with unsigned saturation: Arithmetic. (line 130) 56170* unsigned greater than: Comparisons. (line 64) 56171* unsigned greater than <1>: Comparisons. (line 72) 56172* unsigned less than: Comparisons. (line 68) 56173* unsigned less than <1>: Comparisons. (line 76) 56174* unsigned minimum and maximum: Arithmetic. (line 149) 56175* unsigned_fix: Conversions. (line 77) 56176* unsigned_float: Conversions. (line 62) 56177* unsigned_fract_convert: Conversions. (line 97) 56178* unsigned_sat_fract: Conversions. (line 103) 56179* unspec: Side Effects. (line 299) 56180* unspec <1>: Constant Definitions. 56181 (line 111) 56182* unspec_volatile: Side Effects. (line 299) 56183* unspec_volatile <1>: Constant Definitions. 56184 (line 99) 56185* untyped_call instruction pattern: Standard Names. (line 1747) 56186* untyped_return instruction pattern: Standard Names. (line 1810) 56187* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 56188* update_ssa: SSA. (line 74) 56189* update_stmt: Manipulating GIMPLE statements. 56190 (line 140) 56191* update_stmt <1>: SSA Operands. (line 6) 56192* update_stmt_if_modified: Manipulating GIMPLE statements. 56193 (line 143) 56194* UQQmode: Machine Modes. (line 126) 56195* usaddM3 instruction pattern: Standard Names. (line 442) 56196* usadM instruction pattern: Standard Names. (line 579) 56197* USAmode: Machine Modes. (line 166) 56198* usashlM3 instruction pattern: Standard Names. (line 828) 56199* usdivM3 instruction pattern: Standard Names. (line 442) 56200* use: Side Effects. (line 168) 56201* used: Flags. (line 325) 56202* used, in symbol_ref: Flags. (line 211) 56203* user: GTY Options. (line 245) 56204* user experience guidelines: User Experience Guidelines. 56205 (line 6) 56206* user gc: User GC. (line 6) 56207* USER_LABEL_PREFIX: Instruction Output. (line 152) 56208* USE_C_ALLOCA: Host Misc. (line 19) 56209* USE_LD_AS_NEEDED: Driver. (line 135) 56210* USE_LOAD_POST_DECREMENT: Costs. (line 254) 56211* USE_LOAD_POST_INCREMENT: Costs. (line 249) 56212* USE_LOAD_PRE_DECREMENT: Costs. (line 264) 56213* USE_LOAD_PRE_INCREMENT: Costs. (line 259) 56214* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 205) 56215* USE_STORE_POST_DECREMENT: Costs. (line 274) 56216* USE_STORE_POST_INCREMENT: Costs. (line 269) 56217* USE_STORE_PRE_DECREMENT: Costs. (line 284) 56218* USE_STORE_PRE_INCREMENT: Costs. (line 279) 56219* USING_STMT: Statements for C++. (line 6) 56220* usmaddMN4 instruction pattern: Standard Names. (line 780) 56221* usmsubMN4 instruction pattern: Standard Names. (line 804) 56222* usmulhisi3 instruction pattern: Standard Names. (line 748) 56223* usmulM3 instruction pattern: Standard Names. (line 442) 56224* usmulqihi3 instruction pattern: Standard Names. (line 748) 56225* usmulsidi3 instruction pattern: Standard Names. (line 748) 56226* usnegM2 instruction pattern: Standard Names. (line 872) 56227* USQmode: Machine Modes. (line 134) 56228* ussubM3 instruction pattern: Standard Names. (line 442) 56229* usubvM4 instruction pattern: Standard Names. (line 466) 56230* us_ashift: Arithmetic. (line 173) 56231* us_minus: Arithmetic. (line 38) 56232* us_mult: Arithmetic. (line 93) 56233* us_neg: Arithmetic. (line 82) 56234* us_plus: Arithmetic. (line 14) 56235* us_truncate: Conversions. (line 48) 56236* UTAmode: Machine Modes. (line 174) 56237* UTQmode: Machine Modes. (line 142) 56238* V in constraint: Simple Constraints. (line 43) 56239* values, returned by functions: Scalar Return. (line 6) 56240* varargs implementation: Varargs. (line 6) 56241* variable: Declarations. (line 6) 56242* Variable Location Debug Information in RTL: Debug Information. 56243 (line 6) 56244* VAR_DECL: Declarations. (line 6) 56245* var_location: Debug Information. (line 14) 56246* vashlM3 instruction pattern: Standard Names. (line 844) 56247* vashrM3 instruction pattern: Standard Names. (line 844) 56248* VA_ARG_EXPR: Unary and Binary Expressions. 56249 (line 6) 56250* vcondeqMN instruction pattern: Standard Names. (line 385) 56251* vcondMN instruction pattern: Standard Names. (line 372) 56252* vconduMN instruction pattern: Standard Names. (line 382) 56253* vcond_mask_MN instruction pattern: Standard Names. (line 392) 56254* vector: Containers. (line 6) 56255* vector operations: Vector Operations. (line 6) 56256* VECTOR_CST: Constant expressions. 56257 (line 6) 56258* VECTOR_STORE_FLAG_VALUE: Misc. (line 327) 56259* vec_cmpeqMN instruction pattern: Standard Names. (line 365) 56260* vec_cmpMN instruction pattern: Standard Names. (line 355) 56261* vec_cmpuMN instruction pattern: Standard Names. (line 362) 56262* vec_concat: Vector Operations. (line 29) 56263* VEC_COND_EXPR: Vectors. (line 6) 56264* vec_duplicate: Vector Operations. (line 34) 56265* vec_duplicateM instruction pattern: Standard Names. (line 298) 56266* VEC_DUPLICATE_EXPR: Vectors. (line 6) 56267* vec_extractMN instruction pattern: Standard Names. (line 282) 56268* vec_initMN instruction pattern: Standard Names. (line 291) 56269* vec_load_lanesMN instruction pattern: Standard Names. (line 165) 56270* VEC_LSHIFT_EXPR: Vectors. (line 6) 56271* vec_mask_load_lanesMN instruction pattern: Standard Names. (line 189) 56272* vec_mask_store_lanesMN instruction pattern: Standard Names. 56273 (line 219) 56274* vec_merge: Vector Operations. (line 11) 56275* vec_packs_float_M instruction pattern: Standard Names. (line 670) 56276* vec_packu_float_M instruction pattern: Standard Names. (line 670) 56277* VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 56278* VEC_PACK_FLOAT_EXPR: Vectors. (line 6) 56279* VEC_PACK_SAT_EXPR: Vectors. (line 6) 56280* vec_pack_sbool_trunc_M instruction pattern: Standard Names. 56281 (line 647) 56282* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 663) 56283* vec_pack_ssat_M instruction pattern: Standard Names. (line 656) 56284* VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 56285* vec_pack_trunc_M instruction pattern: Standard Names. (line 640) 56286* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 663) 56287* vec_pack_usat_M instruction pattern: Standard Names. (line 656) 56288* vec_permM instruction pattern: Standard Names. (line 410) 56289* vec_permM instruction pattern <1>: Addressing Modes. (line 330) 56290* VEC_RSHIFT_EXPR: Vectors. (line 6) 56291* vec_select: Vector Operations. (line 19) 56292* vec_series: Vector Operations. (line 41) 56293* vec_seriesM instruction pattern: Standard Names. (line 308) 56294* VEC_SERIES_EXPR: Vectors. (line 6) 56295* vec_setM instruction pattern: Standard Names. (line 277) 56296* vec_shl_insert_M instruction pattern: Standard Names. (line 621) 56297* vec_shl_M instruction pattern: Standard Names. (line 628) 56298* vec_shr_M instruction pattern: Standard Names. (line 634) 56299* vec_store_lanesMN instruction pattern: Standard Names. (line 206) 56300* vec_unpacks_float_hi_M instruction pattern: Standard Names. 56301 (line 700) 56302* vec_unpacks_float_lo_M instruction pattern: Standard Names. 56303 (line 700) 56304* vec_unpacks_hi_M instruction pattern: Standard Names. (line 677) 56305* vec_unpacks_lo_M instruction pattern: Standard Names. (line 677) 56306* vec_unpacks_sbool_hi_M instruction pattern: Standard Names. 56307 (line 691) 56308* vec_unpacks_sbool_lo_M instruction pattern: Standard Names. 56309 (line 691) 56310* vec_unpacku_float_hi_M instruction pattern: Standard Names. 56311 (line 700) 56312* vec_unpacku_float_lo_M instruction pattern: Standard Names. 56313 (line 700) 56314* vec_unpacku_hi_M instruction pattern: Standard Names. (line 684) 56315* vec_unpacku_lo_M instruction pattern: Standard Names. (line 684) 56316* VEC_UNPACK_FIX_TRUNC_HI_EXPR: Vectors. (line 6) 56317* VEC_UNPACK_FIX_TRUNC_LO_EXPR: Vectors. (line 6) 56318* VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 56319* VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 56320* VEC_UNPACK_HI_EXPR: Vectors. (line 6) 56321* VEC_UNPACK_LO_EXPR: Vectors. (line 6) 56322* vec_unpack_sfix_trunc_hi_M instruction pattern: Standard Names. 56323 (line 709) 56324* vec_unpack_sfix_trunc_lo_M instruction pattern: Standard Names. 56325 (line 709) 56326* vec_unpack_ufix_trunc_hi_M instruction pattern: Standard Names. 56327 (line 709) 56328* vec_unpack_ufix_trunc_lo_M instruction pattern: Standard Names. 56329 (line 709) 56330* VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 56331* VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 56332* vec_widen_smult_even_M instruction pattern: Standard Names. 56333 (line 719) 56334* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 719) 56335* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 719) 56336* vec_widen_smult_odd_M instruction pattern: Standard Names. (line 719) 56337* vec_widen_sshiftl_hi_M instruction pattern: Standard Names. 56338 (line 730) 56339* vec_widen_sshiftl_lo_M instruction pattern: Standard Names. 56340 (line 730) 56341* vec_widen_umult_even_M instruction pattern: Standard Names. 56342 (line 719) 56343* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 719) 56344* vec_widen_umult_lo_M instruction pattern: Standard Names. (line 719) 56345* vec_widen_umult_odd_M instruction pattern: Standard Names. (line 719) 56346* vec_widen_ushiftl_hi_M instruction pattern: Standard Names. 56347 (line 730) 56348* vec_widen_ushiftl_lo_M instruction pattern: Standard Names. 56349 (line 730) 56350* verify_flow_info: Maintaining the CFG. 56351 (line 116) 56352* virtual operands: SSA Operands. (line 6) 56353* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 56354* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 56355* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 56356* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 56357* VLIW: Processor pipeline description. 56358 (line 6) 56359* VLIW <1>: Processor pipeline description. 56360 (line 223) 56361* vlshrM3 instruction pattern: Standard Names. (line 844) 56362* VMS: Filesystem. (line 37) 56363* VMS_DEBUGGING_INFO: VMS Debug. (line 8) 56364* VOIDmode: Machine Modes. (line 192) 56365* VOID_TYPE: Types. (line 6) 56366* volatil: Flags. (line 339) 56367* volatil, in insn, call_insn, jump_insn, code_label, jump_table_data, barrier, and note: Flags. 56368 (line 33) 56369* volatil, in label_ref and reg_label: Flags. (line 54) 56370* volatil, in mem, asm_operands, and asm_input: Flags. (line 65) 56371* volatil, in reg: Flags. (line 106) 56372* volatil, in subreg: Flags. (line 184) 56373* volatil, in subreg <1>: Flags. (line 194) 56374* volatil, in symbol_ref: Flags. (line 220) 56375* volatile memory references: Flags. (line 340) 56376* volatile, in prefetch: Flags. (line 92) 56377* voting between constraint alternatives: Class Preferences. (line 6) 56378* vrotlM3 instruction pattern: Standard Names. (line 844) 56379* vrotrM3 instruction pattern: Standard Names. (line 844) 56380* walk_dominator_tree: SSA. (line 195) 56381* walk_gimple_op: Statement and operand traversals. 56382 (line 30) 56383* walk_gimple_seq: Statement and operand traversals. 56384 (line 47) 56385* walk_gimple_stmt: Statement and operand traversals. 56386 (line 10) 56387* WCHAR_TYPE: Type Layout. (line 165) 56388* WCHAR_TYPE_SIZE: Type Layout. (line 173) 56389* which_alternative: Output Statement. (line 58) 56390* WHILE_BODY: Statements for C++. (line 6) 56391* WHILE_COND: Statements for C++. (line 6) 56392* WHILE_STMT: Statements for C++. (line 6) 56393* while_ultMN instruction pattern: Standard Names. (line 320) 56394* whopr: LTO. (line 6) 56395* widen_ssumM3 instruction pattern: Standard Names. (line 587) 56396* widen_usumM3 instruction pattern: Standard Names. (line 588) 56397* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 110) 56398* window_save instruction pattern: Standard Names. (line 2092) 56399* WINT_TYPE: Type Layout. (line 178) 56400* WORDS_BIG_ENDIAN: Storage Layout. (line 28) 56401* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 225) 56402* word_mode: Machine Modes. (line 458) 56403* WORD_REGISTER_OPERATIONS: Misc. (line 53) 56404* wpa: LTO. (line 6) 56405* X in constraint: Simple Constraints. (line 122) 56406* x-HOST: Host Fragment. (line 6) 56407* XCmode: Machine Modes. (line 199) 56408* XCOFF_DEBUGGING_INFO: DBX Options. (line 12) 56409* XEXP: Accessors. (line 6) 56410* XFmode: Machine Modes. (line 82) 56411* XImode: Machine Modes. (line 54) 56412* XINT: Accessors. (line 6) 56413* xm-MACHINE.h: Filesystem. (line 6) 56414* xm-MACHINE.h <1>: Host Misc. (line 6) 56415* xor: Arithmetic. (line 168) 56416* xor, canonicalization of: Insn Canonicalizations. 56417 (line 94) 56418* xorM3 instruction pattern: Standard Names. (line 442) 56419* xorsignM3 instruction pattern: Standard Names. (line 1149) 56420* XSTR: Accessors. (line 6) 56421* XVEC: Accessors. (line 38) 56422* XVECEXP: Accessors. (line 45) 56423* XVECLEN: Accessors. (line 41) 56424* XWINT: Accessors. (line 6) 56425* zero_extend: Conversions. (line 28) 56426* zero_extendMN2 instruction pattern: Standard Names. (line 1452) 56427* zero_extract: Bit-Fields. (line 30) 56428* zero_extract, canonicalization of: Insn Canonicalizations. 56429 (line 103) 56430 56431 56432 56433Tag Table: 56434Node: Top1789 56435Node: Contributing5163 56436Node: Portability5893 56437Node: Interface7681 56438Node: Libgcc10722 56439Node: Integer library routines12549 56440Node: Soft float library routines19517 56441Node: Decimal float library routines31455 56442Node: Fixed-point fractional library routines47213 56443Node: Exception handling routines147609 56444Node: Miscellaneous routines148716 56445Node: Languages150836 56446Node: Source Tree152383 56447Node: Configure Terms152965 56448Node: Top Level155921 56449Node: gcc Directory159506 56450Node: Subdirectories160458 56451Node: Configuration162626 56452Node: Config Fragments163346 56453Node: System Config164571 56454Node: Configuration Files165507 56455Node: Build168123 56456Node: Makefile168535 56457Ref: Makefile-Footnote-1175310 56458Ref: Makefile-Footnote-2175457 56459Node: Library Files175531 56460Node: Headers176093 56461Node: Documentation178176 56462Node: Texinfo Manuals179035 56463Node: Man Page Generation181364 56464Node: Miscellaneous Docs183277 56465Node: Front End184664 56466Node: Front End Directory188343 56467Node: Front End Config189659 56468Node: Front End Makefile192495 56469Node: Back End196263 56470Node: Testsuites201149 56471Node: Test Idioms202138 56472Node: Test Directives205536 56473Node: Directives206063 56474Node: Selectors217436 56475Node: Effective-Target Keywords218792 56476Ref: arm_fp_ok230743 56477Ref: arm_fp_dp_ok230910 56478Ref: arm_neon_ok232022 56479Ref: arm_neon_ok_no_float_abi232191 56480Ref: arm_neonv2_ok232358 56481Ref: arm_fp16_ok232525 56482Ref: arm_neon_fp16_ok232867 56483Ref: arm_vfp3_ok233799 56484Ref: arm_arch_v8a_hard_ok233942 56485Ref: arm_v8_1a_neon_ok234692 56486Ref: arm_v8_2a_fp16_scalar_ok235120 56487Ref: arm_v8_2a_fp16_neon_ok235571 56488Ref: arm_v8_2a_dotprod_neon_ok236046 56489Ref: arm_fp16fml_neon_ok236466 56490Ref: arm_coproc1_ok238966 56491Ref: arm_coproc2_ok239092 56492Ref: arm_coproc3_ok239320 56493Ref: arm_simd32_ok239687 56494Ref: arm_qbit_ok239865 56495Ref: arm_softfp_ok240057 56496Ref: arm_hard_ok240130 56497Ref: stack_size_et252038 56498Node: Add Options254431 56499Ref: arm_fp16_ieee255669 56500Ref: arm_fp16_alternative255924 56501Ref: stack_size_ao258319 56502Node: Require Support258681 56503Node: Final Actions261583 56504Node: Ada Tests270423 56505Node: C Tests271586 56506Node: LTO Testing275958 56507Node: gcov Testing277601 56508Node: profopt Testing280571 56509Node: compat Testing282286 56510Node: Torture Tests286526 56511Node: GIMPLE Tests288160 56512Node: RTL Tests289402 56513Node: Options290708 56514Node: Option file format291149 56515Node: Option properties298138 56516Node: Passes314301 56517Node: Parsing pass315174 56518Node: Gimplification pass318702 56519Node: Pass manager320535 56520Node: IPA passes322376 56521Node: Small IPA passes323269 56522Node: Regular IPA passes326706 56523Node: Late IPA passes331768 56524Node: Tree SSA passes332727 56525Node: RTL passes354267 56526Node: Optimization info366531 56527Node: Dump setup367350 56528Node: Optimization groups368479 56529Node: Dump files and streams369458 56530Node: Dump output verbosity370656 56531Node: Dump types371712 56532Node: Dump examples374054 56533Node: poly_int375535 56534Node: Overview of poly_int377015 56535Node: Consequences of using poly_int379619 56536Node: Comparisons involving poly_int381254 56537Node: Comparison functions for poly_int382892 56538Node: Properties of the poly_int comparisons384099 56539Node: Comparing potentially-unordered poly_ints386541 56540Node: Comparing ordered poly_ints387452 56541Node: Checking for a poly_int marker value389476 56542Node: Range checks on poly_ints390325 56543Node: Sorting poly_ints392979 56544Node: Arithmetic on poly_ints393752 56545Node: Using poly_int with C++ arithmetic operators394553 56546Node: wi arithmetic on poly_ints396084 56547Node: Division of poly_ints396936 56548Node: Other poly_int arithmetic398443 56549Node: Alignment of poly_ints399849 56550Node: Computing bounds on poly_ints403126 56551Node: Converting poly_ints404515 56552Node: Miscellaneous poly_int routines408062 56553Node: Guidelines for using poly_int408702 56554Node: GENERIC413634 56555Node: Deficiencies415456 56556Node: Tree overview415697 56557Node: Macros and Functions419821 56558Node: Identifiers420646 56559Node: Containers422255 56560Node: Types423412 56561Node: Declarations435486 56562Node: Working with declarations435981 56563Node: Internal structure441585 56564Node: Current structure hierarchy441969 56565Node: Adding new DECL node types444062 56566Node: Attributes448346 56567Node: Expression trees449590 56568Node: Constant expressions451344 56569Node: Storage References457436 56570Node: Unary and Binary Expressions460955 56571Node: Vectors481857 56572Node: Statements488761 56573Node: Basic Statements489293 56574Node: Blocks493920 56575Node: Statement Sequences495621 56576Node: Empty Statements495954 56577Node: Jumps496528 56578Node: Cleanups497181 56579Node: OpenMP499222 56580Node: OpenACC505067 56581Node: Functions506184 56582Node: Function Basics506655 56583Node: Function Properties510339 56584Node: Language-dependent trees513120 56585Node: C and C++ Trees514007 56586Node: Types for C++516892 56587Node: Namespaces521862 56588Node: Classes524968 56589Node: Functions for C++529876 56590Node: Statements for C++536127 56591Node: C++ Expressions544180 56592Node: GIMPLE545685 56593Node: Tuple representation549350 56594Node: Class hierarchy of GIMPLE statements556310 56595Node: GIMPLE instruction set561298 56596Node: GIMPLE Exception Handling562930 56597Node: Temporaries564842 56598Ref: Temporaries-Footnote-1566160 56599Node: Operands566225 56600Node: Compound Expressions566986 56601Node: Compound Lvalues567220 56602Node: Conditional Expressions567982 56603Node: Logical Operators568641 56604Node: Manipulating GIMPLE statements575988 56605Node: Tuple specific accessors581924 56606Node: GIMPLE_ASM582703 56607Node: GIMPLE_ASSIGN585086 56608Node: GIMPLE_BIND589790 56609Node: GIMPLE_CALL591604 56610Node: GIMPLE_CATCH595747 56611Node: GIMPLE_COND596897 56612Node: GIMPLE_DEBUG599692 56613Node: GIMPLE_EH_FILTER604290 56614Node: GIMPLE_LABEL605853 56615Node: GIMPLE_GOTO606466 56616Node: GIMPLE_NOP606989 56617Node: GIMPLE_OMP_ATOMIC_LOAD607351 56618Node: GIMPLE_OMP_ATOMIC_STORE608347 56619Node: GIMPLE_OMP_CONTINUE609046 56620Node: GIMPLE_OMP_CRITICAL610525 56621Node: GIMPLE_OMP_FOR611519 56622Node: GIMPLE_OMP_MASTER614935 56623Node: GIMPLE_OMP_ORDERED615313 56624Node: GIMPLE_OMP_PARALLEL615707 56625Node: GIMPLE_OMP_RETURN618476 56626Node: GIMPLE_OMP_SECTION619121 56627Node: GIMPLE_OMP_SECTIONS619781 56628Node: GIMPLE_OMP_SINGLE621391 56629Node: GIMPLE_PHI622337 56630Node: GIMPLE_RESX623616 56631Node: GIMPLE_RETURN624335 56632Node: GIMPLE_SWITCH624909 56633Node: GIMPLE_TRY626784 56634Node: GIMPLE_WITH_CLEANUP_EXPR628556 56635Node: GIMPLE sequences629435 56636Node: Sequence iterators632641 56637Node: Adding a new GIMPLE statement code641098 56638Node: Statement and operand traversals642443 56639Node: Tree SSA645035 56640Node: Annotations646823 56641Node: SSA Operands647228 56642Node: SSA661307 56643Node: Alias analysis671013 56644Node: Memory model674787 56645Node: RTL676146 56646Node: RTL Objects678334 56647Node: RTL Classes682218 56648Node: Accessors687517 56649Node: Special Accessors689690 56650Node: Flags695477 56651Node: Machine Modes710740 56652Node: Constants728146 56653Node: Regs and Memory739535 56654Node: Arithmetic758787 56655Node: Comparisons768962 56656Node: Bit-Fields773254 56657Node: Vector Operations774805 56658Node: Conversions776909 56659Node: RTL Declarations781407 56660Node: Side Effects782251 56661Node: Incdec799260 56662Node: Assembler802596 56663Node: Debug Information804141 56664Node: Insns806068 56665Node: Calls833924 56666Node: Sharing836517 56667Node: Reading RTL839712 56668Node: Control Flow840703 56669Node: Basic Blocks842471 56670Node: Edges847925 56671Node: Profile information856544 56672Node: Maintaining the CFG861228 56673Node: Liveness information866996 56674Node: Loop Analysis and Representation869122 56675Node: Loop representation870158 56676Node: Loop querying877524 56677Node: Loop manipulation880345 56678Node: LCSSA882681 56679Node: Scalar evolutions884750 56680Node: loop-iv887994 56681Node: Number of iterations889916 56682Node: Dependency analysis893997 56683Node: Machine Desc900348 56684Node: Overview902911 56685Node: Patterns904951 56686Node: Example909918 56687Node: RTL Template911379 56688Node: Output Template922035 56689Node: Output Statement926216 56690Node: Predicates930555 56691Node: Machine-Independent Predicates933473 56692Node: Defining Predicates938417 56693Node: Constraints944380 56694Node: Simple Constraints945849 56695Node: Multi-Alternative958689 56696Node: Class Preferences961898 56697Node: Modifiers962790 56698Node: Machine Constraints967523 56699Node: Disable Insn Alternatives1029627 56700Node: Define Constraints1033119 56701Node: C Constraint Interface1040513 56702Node: Standard Names1043640 56703Ref: shift patterns1079884 56704Ref: prologue instruction pattern1134664 56705Ref: window_save instruction pattern1135157 56706Ref: epilogue instruction pattern1135434 56707Node: Pattern Ordering1157410 56708Node: Dependent Patterns1158646 56709Node: Jump Patterns1160266 56710Ref: Jump Patterns-Footnote-11162411 56711Node: Looping Patterns1162459 56712Node: Insn Canonicalizations1168098 56713Node: Expander Definitions1173305 56714Node: Insn Splitting1181519 56715Node: Including Patterns1196549 56716Node: Peephole Definitions1198333 56717Node: define_peephole1199586 56718Node: define_peephole21205916 56719Node: Insn Attributes1210005 56720Node: Defining Attributes1211187 56721Ref: define_enum_attr1214679 56722Node: Expressions1215715 56723Node: Tagging Insns1222465 56724Node: Attr Example1226818 56725Node: Insn Lengths1229191 56726Node: Constant Attributes1232599 56727Node: Mnemonic Attribute1233775 56728Node: Delay Slots1235294 56729Node: Processor pipeline description1238517 56730Ref: Processor pipeline description-Footnote-11257329 56731Node: Conditional Execution1257653 56732Node: Define Subst1261136 56733Node: Define Subst Example1263171 56734Node: Define Subst Pattern Matching1266166 56735Node: Define Subst Output Template1267392 56736Node: Constant Definitions1269715 56737Ref: define_enum1273497 56738Node: Iterators1273985 56739Node: Mode Iterators1274630 56740Node: Defining Mode Iterators1275608 56741Node: Substitutions1277102 56742Node: Examples1279344 56743Node: Code Iterators1280792 56744Node: Int Iterators1283922 56745Node: Subst Iterators1286368 56746Node: Parameterized Names1288088 56747Node: Target Macros1292106 56748Node: Target Structure1295169 56749Node: Driver1297661 56750Node: Run-time Target1316631 56751Node: Per-Function Data1326164 56752Node: Storage Layout1328928 56753Node: Type Layout1356427 56754Node: Registers1369768 56755Node: Register Basics1370742 56756Node: Allocation Order1378304 56757Node: Values in Registers1380788 56758Node: Leaf Functions1388264 56759Node: Stack Registers1391123 56760Node: Register Classes1392395 56761Node: Stack and Calling1427177 56762Node: Frame Layout1427783 56763Node: Exception Handling1439618 56764Node: Stack Checking1445828 56765Node: Frame Registers1451453 56766Node: Elimination1460004 56767Node: Stack Arguments1463860 56768Node: Register Arguments1471056 56769Node: Scalar Return1495917 56770Node: Aggregate Return1502373 56771Node: Caller Saves1506927 56772Node: Function Entry1507669 56773Node: Profiling1519221 56774Node: Tail Calls1521331 56775Node: Shrink-wrapping separate components1523241 56776Node: Stack Smashing Protection1526282 56777Node: Miscellaneous Register Hooks1528771 56778Node: Varargs1529636 56779Node: Trampolines1539036 56780Node: Library Calls1547859 56781Node: Addressing Modes1552749 56782Node: Anchored Addresses1581756 56783Node: Condition Code1584399 56784Node: CC0 Condition Codes1586726 56785Node: MODE_CC Condition Codes1589972 56786Node: Costs1596798 56787Node: Scheduling1618169 56788Node: Sections1642091 56789Node: PIC1658310 56790Node: Assembler Format1660369 56791Node: File Framework1661507 56792Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1669106 56793Node: Data Output1672376 56794Node: Uninitialized Data1680664 56795Node: Label Output1685678 56796Node: Initialization1710289 56797Node: Macros for Initialization1716250 56798Node: Instruction Output1722969 56799Node: Dispatch Tables1733598 56800Node: Exception Region Output1739059 56801Node: Alignment Output1746141 56802Node: Debugging Info1749828 56803Node: All Debuggers1750482 56804Node: DBX Options1753254 56805Node: DBX Hooks1758692 56806Node: File Names and DBX1760001 56807Node: DWARF1762105 56808Node: VMS Debug1767920 56809Node: Floating Point1768499 56810Node: Mode Switching1771254 56811Node: Target Attributes1775691 56812Node: Emulated TLS1785107 56813Node: MIPS Coprocessors1788497 56814Node: PCH Target1789656 56815Node: C++ ABI1791498 56816Node: D Language and ABI1796290 56817Node: Named Address Spaces1797335 56818Node: Misc1803262 56819Ref: TARGET_SHIFT_TRUNCATION_MASK1811133 56820Node: Host Config1866467 56821Node: Host Common1867536 56822Node: Filesystem1869910 56823Node: Host Misc1874025 56824Node: Fragments1876474 56825Node: Target Fragment1877669 56826Node: Host Fragment1888481 56827Node: Collect21888721 56828Node: Header Dirs1891357 56829Node: Type Information1892780 56830Node: GTY Options1896056 56831Node: Inheritance and GTY1907314 56832Ref: Inheritance and GTY-Footnote-11908879 56833Node: User GC1909149 56834Node: GGC Roots1912888 56835Node: Files1913601 56836Node: Invoking the garbage collector1916308 56837Node: Troubleshooting1917813 56838Node: Plugins1918888 56839Node: Plugins loading1920017 56840Node: Plugin API1921116 56841Node: Plugins pass1928842 56842Node: Plugins GC1930813 56843Node: Plugins description1932530 56844Node: Plugins attr1933066 56845Node: Plugins recording1935346 56846Node: Plugins gate1936196 56847Node: Plugins tracking1936787 56848Node: Plugins building1937375 56849Node: LTO1940876 56850Node: LTO Overview1941748 56851Node: LTO object file layout1947575 56852Node: IPA1952205 56853Node: WHOPR1961255 56854Node: Internal flags1965815 56855Node: Match and Simplify1967226 56856Node: GIMPLE API1968188 56857Node: The Language1970983 56858Node: Static Analyzer1982958 56859Node: Analyzer Internals1983223 56860Node: Debugging the Analyzer1998867 56861Node: User Experience Guidelines2001478 56862Node: Guidelines for Diagnostics2002414 56863Ref: input_location_example2009475 56864Node: Guidelines for Options2019158 56865Node: Funding2019335 56866Node: GNU Project2021842 56867Node: Copying2022491 56868Node: GNU Free Documentation License2060002 56869Node: Contributors2085123 56870Node: Option Index2126099 56871Node: Concept Index2126976 56872 56873End Tag Table 56874